← All work
Production G-Man Auto Parts · 2025–2026

AI semantic search for auto parts

Buyers and suppliers needed to find the exact part for an exact car by typing plain words in their own language. I built the search end to end, and a test suite that proved it reached the 95% accuracy a government R&D program required.

My role
The only AI/ML engineer. I owned the design, the embeddings, entity recognition, the LLM steps, the evaluation, and production operation.
Result
95%+ accuracy on the 3,000-part test of a government R&D program. The project was approved.
Stack
Python, Django REST Framework, Weaviate, spaCy, OpenAI API (GPT-4o-mini), Celery, PostgreSQL, AWS S3
Scale
A catalog of 2M+ part records, and 300K+ listings on sale and searchable, for Kia, Hyundai, SsangYong, and Chevrolet cars

The problem

People describe the same part in many ways: “headlight” or “head lamp”, informal names, or other languages. But the right answer is one part number for one exact car: brand, model, year, fuel, transmission, generation, and side (left or right, front or rear).

Rigid keyword filters could not handle this. The company needed a search that understands plain language and returns the right part almost every time. The search was also part of a project submitted to a government R&D program. To be approved, it had to reach 95% accuracy on a fixed test of 3,000 parts.

How a query flows

  1. Language check A small language detector runs first, so the LLM is only called when it is needed.
  2. LLM normalization Non-English queries are translated and cleaned up (GPT-4o-mini).
  3. Entity extraction spaCy NER finds brand, model, year, fuel, transmission, part name, side, and generation.
  4. Filtered vector search The entities become exact filters on top of a semantic search in Weaviate.
  5. LLM re-ranking An LLM post-filter drops clearly wrong results and re-orders the rest.
  6. Results Product search for buyers, or catalog matching for suppliers.
  • Django REST APIServes both search modes to the store and admin tools
  • Accuracy test suiteRuns the same pipeline on a fixed test set
  • S3 reportsEvery test run is saved and survives redeploys
The production search pipeline. The dashed step runs only for non-English queries.

Example: one query, step by step

  1. The query, typed in Korean 현대 쏘나타 2019 왼쪽 헤드라이트
  2. After the LLM normalization Hyundai Sonata 2019 left headlight
  3. Entities, used as exact filters
    • brand: Hyundai
    • model: Sonata
    • year: 2019
    • side: left
    • part: headlight
    The alias list turns “headlight” into the catalog name Head Lamp Assembly.
  4. Results after vector search and LLM re-ranking
    • Head Lamp Assembly · Left ranked first
    • Fog Lamp · Left dropped by the LLM
A made-up query, shown to illustrate the steps.

What I built

  • Vector search core. I embedded the parts catalog in Weaviate and built the search service in Django REST Framework. I chose what text gets embedded for each part, such as field labels, the side, the car year, and curated synonyms, so that more of the right parts are found.
  • Entities as hard filters. spaCy pulls structured facts out of a free-text query and turns them into exact filters. The vector search handles the wording, and the filters make sure the car and the side are right.
  • Two search modes. Buyers get product search. Suppliers get auto-matching: when they upload a part, the search matches it to catalog records, and each distinct part number becomes its own result.
  • Multilingual queries. An LLM translates and cleans up non-English queries. Moving it from GPT-3.5-Turbo to GPT-4o-mini gave better quality at a lower cost, and the language check keeps the number of LLM calls low.
  • Relevance tuning. An LLM re-ranker removes clearly wrong results. An alias list maps everyday words to catalog names, so “headlight” finds Head Lamp Assembly. That raised accuracy on everyday wording.
  • Frontend wiring. I connected the online store and the admin tools to the search APIs. The page filters feed the query, a match fills in the supplier's form, and results are sorted by relevance and cut off below a certainty threshold.

Measuring accuracy

Accuracy had to be measured, not guessed. I built an internal testing page that runs the same pipeline as production search on a fixed, curated test set.

  • Metrics: accuracy@1 and accuracy@3, precision, recall, F1, a confusion matrix, and cross-validation.
  • Repeatable runs: automated or manual. Each run records who ran it and whether the LLM step was on.
  • Safe by design: test data lives in separate collections, with guards so a test can never touch production data.
  • Error analysis: when a query returned nothing, I traced the cause, such as a stale test record, a listing that did not match its catalog entry, two entity patterns that clashed, or a body color in the query, and fixed each one.

Results

  • 95%+accuracy on the government program's 3,000-part test
  • Approvedthe R&D project, after it passed the test
  • 300K+listings on sale and searchable, from a catalog of 2M+ part records

The search went live in production for both buyers and suppliers. I also ran the automated accuracy tests in production and fixed the issues they found.

This page leaves out employer code, internal data, and private URLs.