← Все проекты
В продакшене G-Man Auto Parts · 2025–2026

Семантический ИИ-поиск автозапчастей

Покупателям и поставщикам нужно было находить ту самую деталь для конкретного автомобиля, набирая запрос обычными словами на своём языке. Я создал поиск от начала до конца, а также набор тестов. Тесты доказали, что поиск достиг точности 95%, которую требовала государственная R&D-программа.

Моя роль
Единственный AI/ML-инженер. Я отвечал за архитектуру, эмбеддинги, распознавание сущностей, этапы с LLM, оценку качества и работу в продакшене.
Результат
Точность 95%+ на тесте из 3000 деталей в рамках государственной R&D-программы. Проект одобрен.
Стек
Python, Django REST Framework, Weaviate, spaCy, OpenAI API (GPT-4o-mini), Celery, PostgreSQL, AWS S3
Масштаб
Каталог из более чем 2 млн записей о запчастях и более 300 тыс. объявлений в продаже, доступных для поиска, — всё для автомобилей Kia, Hyundai, SsangYong и Chevrolet

Задача

Люди называют одну и ту же деталь по-разному: «headlight» или «head lamp», разговорными названиями или на других языках. Но правильный ответ — один номер детали для одного конкретного автомобиля: марка, модель, год, топливо, коробка передач, поколение и сторона (левая или правая, передняя или задняя).

Жёсткие фильтры по ключевым словам с этим не справлялись. Компании был нужен поиск, который понимает обычный язык и почти всегда возвращает нужную деталь. Кроме того, поиск был частью проекта, поданного в государственную R&D-программу. Чтобы проект одобрили, поиск должен был показать точность 95% на фиксированном тесте из 3000 деталей.

Как обрабатывается запрос

  1. Определение языка Сначала работает небольшой детектор языка, чтобы LLM вызывалась только при необходимости.
  2. Нормализация через LLM Запросы не на английском переводятся и очищаются (GPT-4o-mini).
  3. Извлечение сущностей spaCy NER находит марку, модель, год, топливо, коробку передач, название детали, сторону и поколение.
  4. Векторный поиск с фильтрами Сущности становятся точными фильтрами поверх семантического поиска в Weaviate.
  5. Переранжи­рование через LLM LLM-постфильтр отбрасывает явно неверные результаты и переупорядочивает остальные.
  6. Результаты Поиск товаров для покупателей или сопоставление с каталогом для поставщиков.
  • Django REST APIОтдаёт оба режима поиска магазину и админ-инструментам
  • Тесты точностиЗапускают тот же пайплайн на фиксированном тестовом наборе
  • Отчёты в S3Каждый прогон тестов сохраняется и переживает повторные деплои
Поисковый пайплайн в продакшене. Пунктиром отмечен шаг, который выполняется только для запросов не на английском.

Пример: один запрос шаг за шагом

  1. Запрос, набранный по-корейски 현대 쏘나타 2019 왼쪽 헤드라이트
  2. После нормализации через LLM Hyundai Sonata 2019 left headlight
  3. Сущности, которые становятся точными фильтрами
    • brand: Hyundai
    • model: Sonata
    • year: 2019
    • side: left
    • part: headlight
    Словарь синонимов превращает «headlight» в название из каталога — Head Lamp Assembly.
  4. Результаты после векторного поиска и переранжирования через LLM
    • Head Lamp Assembly · Left на первом месте
    • Fog Lamp · Left отсеян LLM
Запрос выдуман: он показывает шаги на примере.

Что я сделал

  • Ядро векторного поиска. Я загрузил эмбеддинги каталога запчастей в Weaviate и построил поисковый сервис на Django REST Framework. Я сам выбрал, какой текст превращается в эмбеддинг для каждой детали: названия полей, сторону, год выпуска автомобиля и отобранные синонимы, чтобы поиск находил больше нужных деталей.
  • Сущности как жёсткие фильтры. spaCy извлекает структурированные факты из запроса в свободной форме и превращает их в точные фильтры. Векторный поиск справляется с формулировками, а фильтры гарантируют, что автомобиль и сторона указаны верно.
  • Два режима поиска. Покупатели получают поиск товаров. Поставщики получают автосопоставление: когда они загружают деталь, поиск сопоставляет её с записями каталога, и каждый отдельный номер детали становится отдельным результатом.
  • Многоязычные запросы. LLM переводит и очищает запросы не на английском. Переход с GPT-3.5-Turbo на GPT-4o-mini дал более высокое качество при меньшей стоимости, а определение языка сводит число вызовов LLM к минимуму.
  • Настройка релевантности. LLM-реранкер убирает явно неверные результаты. Словарь синонимов сопоставляет повседневные слова с названиями из каталога, поэтому по запросу «headlight» находится Head Lamp Assembly. Это повысило точность на повседневных формулировках.
  • Интеграция с фронтендом. Я подключил интернет-магазин и админ-инструменты к поисковым API. Фильтры на странице попадают в запрос, найденное совпадение заполняет форму поставщика, а результаты сортируются по релевантности и отсекаются ниже порога уверенности.

Измерение точности

Точность нужно было измерять, а не угадывать. Я сделал внутреннюю страницу тестирования, которая запускает тот же пайплайн, что и поиск в продакшене, на фиксированном, вручную отобранном тестовом наборе.

  • Метрики: accuracy@1 и accuracy@3, precision, recall, F1, матрица ошибок и кросс-валидация.
  • Воспроизводимые прогоны: автоматические или ручные. Каждый прогон фиксирует, кто его запустил и был ли включён этап с LLM.
  • Безопасность заложена в архитектуру: тестовые данные хранятся в отдельных коллекциях, а защитные проверки не дают тестам затронуть данные продакшена.
  • Анализ ошибок: когда запрос ничего не возвращал, я находил причину — устаревшую тестовую запись, объявление, которое не совпадало со своей записью в каталоге, два конфликтующих шаблона сущностей или цвет кузова в запросе — и устранял каждую.

Результаты

  • 95%+точность на тесте из 3000 деталей в рамках государственной программы
  • ОдобренR&D-проект — после того как поиск прошёл тест
  • 300 000+объявлений в продаже, доступных для поиска, из каталога с более чем 2 млн записей о запчастях

Поиск заработал в продакшене — и для покупателей, и для поставщиков. Я также запускал автоматические тесты точности в продакшене и исправлял найденные ими проблемы.

На этой странице нет кода работодателя, внутренних данных и закрытых URL.