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
- Language check A small language detector runs first, so the LLM is only called when it is needed.
- LLM normalization Non-English queries are translated and cleaned up (GPT-4o-mini).
- Entity extraction spaCy NER finds brand, model, year, fuel, transmission, part name, side, and generation.
- Filtered vector search The entities become exact filters on top of a semantic search in Weaviate.
- LLM re-ranking An LLM post-filter drops clearly wrong results and re-orders the rest.
- 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
Example: one query, step by step
- The query, typed in Korean 현대 쏘나타 2019 왼쪽 헤드라이트
-
After the LLM normalization
Hyundai Sonata 2019 left headlight -
Entities, used as exact filters
brand: Hyundaimodel: Sonatayear: 2019side: leftpart: headlight
-
Results after vector search and LLM re-ranking
-
Head Lamp Assembly · Leftranked first -
Fog Lamp · Leftdropped by the LLM
-
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.