Разработка системы визуального поиска товаров с AI

Почему визуальный поиск по фото не находит товар

Пользователь наводит камеру на товар или загружает скриншот — и вместо нужной позиции получает пустую выдачу либо десяток карточек из другой категории. Технически визуальный поиск при этом отработал: снимок принят, векторное представление посчитано, ответ отдан за доли секунды. Сбой не в скорости, а в смысле — система ищет похожую картинку, а не тот же товар в вашем каталоге.

Первая причина — модель считает вектор по общему набору изображений, где обувь, сумки и мебель лежат вперемешку. На ваших карточках товаров она уверенно находит «что-то обувное», но не различает модель, цвет и материал, поэтому релевантность каталога падает уже на первом шаге.

Вторая — качество самих карточек. Одно студийное фото на белом фоне не покрывает ракурсы, в которых покупатель снимает товар: под углом, при жёлтом свете, с фоном полки. Если в каталоге нет снимков с разных сторон, поиску по фото просто не с чем сравнивать.

Третья — индекс. Пока он пересобирается вручную раз в неделю, новые позиции в выдаче не появляются вовсе. Доля пустых выдач растёт, покупатель возвращается к текстовому поиску или уходит к конкуренту — и это уже потерянные продажи, а не техническая мелочь.

Разбираем, как это закрывается: дообучение на своих карточках, требования к съёмке и переиндексация по событию, а не по расписанию.

Что меняется в метриках после запуска визуального поиска

Метрики визуального поиска считаем от базовой линии, снятой на историческом трафике: доля пустых выдач, переход в карточку товара, возвраты, обращения в поддержку, время ответа на запрос. Без зафиксированной точки отсчёта любой рост выглядит заслугой поиска, поэтому замер снимаем до включения и повторяем на той же выборке запросов.

Доля пустых выдач — главный индикатор. Текстовый поиск не закрывает запросы вроде «такое же, но с другим принтом»: пользователь уходит, так и не дойдя до каталога. Векторный индекс на FAISS ищет по эмбеддингу фото, а не по совпадению слов, поэтому выдача наполняется даже при формулировке без точных терминов, и доля пустых результатов падает в разы, а не на проценты.

Возвраты и поддержка реагируют следом. Когда покупатель ориентируется на фото товара, а не на текстовое описание, реже случается «не то, что ожидал», и доля таких возвратов снижается. Типовые обращения «помогите подобрать похожее» перехватывает сама выдача — нагрузка на первую линию поддержки падает.

Скорость ответа держим предсказуемой: эмбеддинги каталога считаются заранее, при обновлении позиции пересчитывается только изменённая часть, а на живом запросе работает готовый индекс. Время ответа укладывается в доли секунды на каталогах в сотни тысяч позиций — поиск не становится узким местом при пиковой нагрузке.

Сравнение режимов подбора: по фото, по ссылке, с камеры

Режимы отличаются не интерфейсом, а тем, что попадает на вход: загрузка фото даёт готовый кадр, съёмка с камеры — поток смазанных и дублирующихся снимков, ссылка — чужую карточку с водяными знаками и обрезанным товаром. Один и тот же индекс векторов в этих условиях ведёт себя по-разному, поэтому ограничения режимов закладывают в архитектуру заранее, а не выясняют на живой выдаче.

Общая часть одна: выделение объекта и кадрирование, нормализация фона, извлечение вектора и поиск ближайших соседей в индексе с последующим переранжированием. Различия — в предобработке и порогах: для съёмки с камеры добавляют оценку резкости и дедупликацию кадров, для ссылки — вырезание элементов чужой вёрстки, для загрузки фото — проверку, что объект вообще распознан.

Комбинация режимов — норма: камеру ставят на сценарий «здесь и сейчас», галерею — на повторный поиск, ссылку — на товары вне каталога. Выбор делаем по доле таких запросов и по тому, какие атрибуты вообще есть в вашей карточке.

Порядок работ: аудит каталога, схема индекса, проверка качества

Порядок этапов выстроен так, чтобы каждый следующий шаг опирался на проверенные данные, а не на предположения. Начинаем с аудита каталога — именно от него зависит и качество визуального поиска, и объём работ по подготовке изображений.

1. Аудит каталога. Выгружаем карточки, ищем дубли, товары без фото, битые ссылки и разнобой в ракурсах. На выходе — карта категорий с реальным количеством позиций, пригодных для обучения.
2. Эталонные изображения. По каждой категории отбираем товары с несколькими ракурсами и вручную размечаем их как эталон. Это база, по которой затем измеряем, находит ли система нужный товар по любительскому фото.
3. Схема сопоставления. Определяем, как снимок превращается в вектор признаков, какой индекс строим и по каким признакам отсекаем заведомо нерелевантное. Отдельно решаем, что делать с товарами, которых в обучении не было.
4. Проверка качества. Прогоняем систему на отложенной части каталога: считаем долю попаданий в первую десятку результатов, отдельно по категориям и по сложным случаям — похожие модели, близкие цвета, съёмка при плохом свете.
5. Подключение к каталогу. Настраиваем обновление индекса при появлении и снятии товаров, чтобы выдача не устаревала и не требовала полной пересборки.
6. Передача в поддержку. Отдаём регламенты, схему индекса и отчёт по качеству выдачи, обучаем команду заказчика переиндексировать каталог и разбирать жалобы на результаты поиска.

Состав поставки: индексы, схемы, политики доступа, регламенты

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

• Индекс визуальных признаков: сборка векторных представлений по всем карточкам каталога с метаданными и категорийной разметкой, плюс описание полной и инкрементальной пересборки.
• Схема данных: связи товар — изображение — признак — категория, требования к качеству фото и правила отбраковки, чтобы индекс не засорялся дублями и стоковыми снимками.
• Политики доступа: роли для витрины, аналитики и админки, разграничение прав на переиндексацию, выгрузку векторов и изменение порогов выдачи.
• Регламент обновления: триггеры пересборки при появлении, снятии с продажи или смене категории товара, порядок проведения и окно, в которое поиск остаётся на старой сборке.
• Контур оценки качества: набор эталонных запросов «фото → ожидаемая выдача», метрика попадания в топ и отчёт по ней для каждой новой версии.
• Регламент отката: сколько предыдущих сборок индекса и модели хранится, как вернуться на предыдущую и за какое время выдача возвращается к прежней.
• Инструкции для команды: запуск, мониторинг, разбор расхождений в выдаче и чек-лист приёма изменений от контент-менеджеров.

Отдельным документом идёт журнал решений: почему выбрана такая разметка категорий и такой порог отсечения похожих товаров, что пробовали и отвергли. Он экономит месяцы на повторном прохождении уже пройденных развилок.

Кейс: доля пустых выдач в каталоге упала в разы

У маркетплейса узкое место нашлось не в модели, а в признаках. Поиск по фото фактически сводился к распознаванию категории и подстановке текстового запроса: если снимок сделан не в студийных условиях, система отдавала пустую страницу или случайные позиции из категории. Доля пустых выдач держалась на уровне 21%, попадание в топ-3 — 46%, и пользователь после первого экрана почти всегда уходил в обычный текстовый поиск.

Что изменили

Собрали единое векторное пространство для снимка и карточки: за основу взяли OpenAI CLIP, дообучили на парах «фото пользователя — товар из заказа» из логов и добавили второй этап — переранжирование топ-50 кандидатов по атрибутам: цвет, материал, силуэт. Модель отдаёт вектор, поиск идёт по индексу, поэтому ответ укладывается в доли секунды даже на каталоге в сотни тысяч позиций.

Что стало

Метрики до и после снимали на одном и том же потоке запросов: доля пустых выдач — 2,7%, точность в топ-3 — 88%, доля заказов, начатых с фотосценария, выросла вчетверо. Регресс ловим на офлайн-наборе из 50 тысяч пар: если новая версия эмбеддингов опускает точность топ-3 ниже порога, выкат останавливается и автоматически откатывается на предыдущую.

Чем отличается подбор по фото от подбора по атрибутам

Подбор по фото начинается с того, что снимок превращается в векторное представление, и система ищет ближайшие позиции в индексе каталога. Покупателю не нужно знать название модели — достаточно кадра из журнала, скриншота из переписки или фото с полки. Подход выигрывает там, где признак сложно описать словами: силуэт, фактура, принт, оттенок.

Атрибутные фильтры работают наоборот — сужают выбор по явным, заранее размеченным признакам: цвет, материал, размер, совместимость, диапазон характеристик. Результат предсказуем и объясним: видно, почему позиция попала в выдачу. Но атрибуты должны быть заполнены и нормализованы, иначе фильтр молча отсекает половину каталога.

Граница применимости проходит по природе признака. Если решение опирается на визуальное сходство — одежда, мебель, декор, детали по внешнему виду — подбор по фото даёт более релевантную выдачу, чем поиск по словам. Если решают числовые условия, фото бесполезно: похожая внешне деталь может не подойти по посадке или разъёму.

На практике подходы работают в связке на одном каталоге. Фото формирует широкий пул кандидатов по похожести, атрибуты сужают его до совместимых вариантов и позволяют отсортировать по наличию. Обратный маршрут тоже востребован: покупатель отбирает товары фильтрами, открывает карточку и просит показать похожие.

Вместе они снижают долю пустых выдач и убирают тупик «не знаю, как это назвать».

Технические сомнения: качество снимков, холодный старт, нагрузка

Инженерные сомнения всплывают до старта, и почти все они упираются в данные, а не в модель. Ниже — четыре вопроса, которые мы снимаем на этапе оценки: качество съёмки, холодный старт, нагрузка и обновление каталога.

Разметки и истории кликов нет — с чего начинать холодный старт?

Стартуем на открытой предобученной модели: пары «фото — описание» собираем из карточек, затем подмешиваем клики и поисковые логи. Первый рабочий результат появляется на десятках тысяч позиций, а не после сбора миллионов размеченных пар.

Выдержит ли поиск пик распродажи?

Индекс держим в памяти и шардируем по репликам, повторяющиеся запросы отдаёт кэш. На пике включается двухступенчатая схема: быстрый приближённый отбор, затем точный пересчёт верхушки выдачи — время ответа остаётся ровным, а не растёт линейно с трафиком.

Как обновлять каталог и не пересобирать индекс целиком?

Инкрементально: новая карточка попадает в поиск через минуты после публикации, снятая с продажи уходит по правилу жизненного цикла. Полная пересборка идёт на отдельном контуре по расписанию — старая и новая версии индекса работают параллельно, откат делается переключением.

Обсудим задачу: пришлите каталог и примеры запросов

Чтобы вернуться с оценкой и планом, а не с общими соображениями, нам нужны данные о каталоге и о том, как покупатели ищут. Чем конкретнее вводные, тем точнее мы назовём сроки, этапы и метрики приёмки.

• Выгрузка каталога в CSV или JSON: артикул, название, категория, атрибуты, ссылки на фото — по ней видно, какая доля карточек пригодна для индексации, а какие придётся чистить.
• 50-100 примеров запросов, включая опечатки, сленг и латиницу — на них строим проверки качества выдачи.
• Примеры фото-запросов: товар целиком, на полке, в интерьере, при слабом свете — от этого зависит устойчивость поиска.
• Эталонная разметка на 100-200 карточек: какие товары считаются верным ответом. Без неё точность не измерить.
• Текущие показатели поиска: доля запросов без результата, переходы в карточку, заказы из поиска — точка отсчёта для сравнения.
• Ограничения инфраструктуры: где живёт каталог, как часто меняются остатки, доступна ли автоматическая выгрузка фото.
• Ответственный с вашей стороны: кто подтверждает разметку и принимает этапы работ.

Порядок работ после этого прозрачный: фиксируем сценарии и метрики, собираем прототип на вашем каталоге, сверяем с эталоном, затем интеграция и вывод в продуктив. Опишите задачу и пришлите перечисленное — вернёмся с оценкой и планом.