AI-система визуального поиска одежды и аксессуаров

Визуальный поиск одежды: где ломается выдача

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

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

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

Качество выдачи каталога определяется не «умом» алгоритма, а разметкой и порогом отсечения. Если в каталоге есть проверенные пары «фото — эталон», можно измерять долю запросов, где нужный товар попал в первые пять карточек, и поднимать её итерациями, а не пересборкой всей системы.

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

Визуальный подбор по фото: измеримые эффекты

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

Доля запросов, закрытых с первого показа

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

Пустые выдачи и скорость подбора

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

Возвраты и нагрузка на разметку

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

Подходы к распознаванию: сравнение вариантов

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

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

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

Этапы внедрения системы подбора по изображению

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

1. Аудит каталога. Считаем объём и структуру: доля дублей и почти-дублей, какие категории сняты в нескольких ракурсах, где фон мешает сопоставлению. На выходе — список товаров, которые нужно переснять или исключить из индекса.
2. Схема решения и метрики релевантности. Фиксируем, что должен находить поиск: те же модели, похожие фасоны, комплект «вещь + аксессуар». Долю попаданий в топ выдачи и точность по категории согласуем до настройки — иначе результат нечем принимать.
3. Подготовка обучающей выборки. Собираем пары «изображение → верный товар», чистим дубли, помечаем сложные случаи: однотонную одежду, ракурс со спины. Делим данные на обучение, валидацию и отложенный набор, который модель не увидит до приёмки.
4. Настройка поиска. Настраиваем извлечение признаков и структуру индекса, подбираем пороги отсечения: когда показывать близкие совпадения, а когда честнее вернуть пустую выдачу.
5. Проверка на отложенной выборке. Прогоняем сценарии, считаем метрики релевантности, разбираем ошибки по категориям. Если проваливается целая группа товаров — возвращаемся к разметке, а не «докручиваем» пороги.
6. Приёмка и передача. Отдаём документацию, доступы, регламент переиндексации при пополнении каталога и отчёт по метрикам. Команду заказчика учим запускать обновление и читать срез ошибок самостоятельно.

Что передаём после внедрения: состав поставки

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

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

Каждый пункт закрываем вопросом «сможет ли ваша команда сделать это сама». Если ответ «нет» — дописываем инструкцию, а не оставляем знание у себя.

Кейс: как выросла релевантность выдачи

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

Диагностика показала три причины. Индекс строился одной моделью на весь каталог без фильтра по категории, поэтому платье искало сумки с похожей текстурой; эмбеддинги считались по исходному кадру без вырезания объекта, и фон весил больше, чем сам товар; порог отсечения стоял так, что система предпочитала показать хоть что-то вместо честного «не найдено».

Что изменили: вырезание объекта при обработке запроса, классификатор категории как обязательный фильтр до ранжирования, пересборка индекса на векторных представлениях, пересчитанных по размеченным реальным запросам, и новый порог отсечения. Сначала выкатили на долю трафика рядом со старой выдачей и сравнили на живых запросах — откат под флагом оставался одной командой.

Результат: доля релевантных показов в топ-10 выросла с 61% до 89%, доля пустых выдач упала с 8,4% до 1,2%, время подбора товара сократилось с трёх минут до сорока секунд, обращений в поддержку «не нашёл по фото» стало меньше в пять раз. Просадку релевантности теперь ловит ежедневный контроль: если доля пустых выдач уходит выше порога, трафик автоматически возвращается на предыдущий индекс.

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

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

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

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

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

Технические сомнения и ответы инженеров

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

Похожие модели будут путаться между собой?

Система отдаёт ранжированный список, а не один ответ, поэтому близкие силуэты — ожидаемый результат. Разделять их помогает разметка пар «похоже / разное»: по ней настраиваем, на какие признаки опираться — крой, длину, фактуру.

Что с новыми коллекциями, которых не было в индексе?

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

Каталог пересняли в другом стиле — качество просядет?

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

Как контролировать качество подбора после передачи?

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

Обсудим задачу и вернёмся с планом

Чтобы вернуться с оценкой и планом работ, а не с общими соображениями, нам нужен доступ к вашим данным и понимание сценариев. Визуальный поиск строится вокруг каталога и того, как покупатель им пользуется: одна и та же модель даст разное качество на каталоге в 500 позиций с ровными съёмками и на 200 тысячах карточек с разным светом и фоном. Ниже — что запрашиваем на первом разговоре.

• Выгрузка каталога. Дамп в привычном для вас формате или доступ к базе в режиме чтения: артикул, категория и подкатегория, цвет, материал, сезон, ссылка на изображения, наличие размеров. Этого хватает, чтобы оценить пригодность снимков и объём работы по их нормализации.
• Примеры неудачных подборов. 15–30 живых запросов или фото, где поиск по вашему ощущению промахивается. Они становятся проверочным набором: на нём видно, растёт ли точность после каждой итерации, а не «стало лучше на глаз».
• Объём коллекций и темп обновления. Сколько позиций сейчас, сколько добавляется за сезон, как часто меняются фото и уходят модели из продажи. От этого зависят стратегия переиндексации и то, как система ведёт себя на новинках.
• Сценарии использования. Где именно покупатель столкнётся с поиском: подбор похожих в карточке, поиск по фото со смартфона, подбор комплекта к выбранной вещи, витрина для продавца. У каждого сценария своя логика выдачи и своя планка точности.
• Точки интеграции. Сайт, мобильное приложение, каталог, поиск, рекомендательный блок, панель менеджера — со схемой потоков и владельцем на вашей стороне. Здесь же фиксируем тестовый контур и ограничения по нагрузке.
• Критерий успеха. Договариваемся заранее, что считаем удачным подбором: попадание в категорию, в цвет, в конкретную вещь. Одна метрика на старте избавляет от споров на приёмке.

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