Как мы довели поиск товаров по изображению до 98% совпадений: FastAPI, DINOv2, Qdrant и поиск на фото полки

В сфере искусственного интеллекта произошло заметное событие. ksrepin 33 минуты назад Как мы довели поиск товаров по изображению до 98% совпадений: FastAPI, DINOv2, Qdrant и поиск на фото полки 6 мин 1. 4K Блог компании Fix Price Проектирование API * Поисковые технологии * PostgreSQL * Кейс Поиск товара по изображению кажется простой задачей — ровно до момента, пока не сталкиваешься с реальным каталогом. В теории все выглядит аккуратно: берем фото, считаем embedding, ищем ближайшие вектора, возвращаем совпадения.

На практике начинаются нюансы: у товара несколько изображений, ракурсы отличаются, фон мешает, каталог обновляется постоянно, а бизнес ждет не исследовательский прототип, а сервис, который можно поставить в production. С вами старший программист в Fix Price Константин Репин. И в этом материале разберу, как мы строили сервис визуального поиска товаров, какие инженерные решения реально повлияли на качество и почему текущий результат в 98% совпадений получился не из-за одной удачной модели, а из-за правильно собранного пайплайна.

Технические детали

Что нужно было построитьЗадача была прикладная: по изображению найти соответствующий товар в каталоге. Дополнительно хотелось закрыть еще один сценарий: определить, присутствует ли конкретный SKU на фотографии полки. По сути, у нас было два связанных кейса:1.

"image-to-catalog search" Пользователь загружает изображение товара, сервис возвращает наиболее релевантные позиции каталога. "SKU-on-shelf detection" Пользователь загружает фото полки и передает SKU, а сервис отвечает, есть ли этот товар на изображении и где именно он находится. Оба сценария используют одно ядро: визуальные эмбеддинги и векторный поиск.

Но требования к пайплайну у них разные, и это сильно повлияло на архитектуру. Как устроено решениеСервис построен на "FastAPI" и состоит из трех основных слоев:- "PostgreSQL" хранит карточки товаров и метаданные. - "Qdrant" хранит векторный индекс изображений.

Отраслевые последствия

- "DINOv2" строит embedding по изображению. Схема работы для обычного поиска выглядит так:1. API получает изображение файлом или по URL.

Энкодер преобразует его в embedding. Qdrant ищет ближайшие вектора по cosine similarity. Результаты группируются по товару.

Из PostgreSQL подтягиваются данные карточек. Клиент получает готовую выдачу. На этом уровне система уже рабочая.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.