AI-система подбора образа: CV и граф знаний

AI подбор одежды: почему рекомендации не попадают в цель

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

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

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

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

Что меняется, когда подбор образа опирается на данные

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

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

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

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

Способы реализации: готовый сервис, своя модель, гибрид

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

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

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

Порядок работ: от аудита данных до передачи в эксплуатацию

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

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

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

Артефакты проекта: граф знаний, схема данных, регламенты

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

• Обученная модель — веса, карточка метрик по срезам (категория, тип фигуры, качество фото) и скрипт воспроизведения обучения, чтобы результат повторялся на новых данных.
• Граф знаний — товары, признаки, стили и категории как узлы, совместимость и взаимозаменяемость как связи с весами; отдельный запрос достаёт «что подходит к этой вещи» без переобучения.
• Схема признаков — для каждого признака источник, способ нормализации и поведение при пропуске, плюс тестовые наборы, на которых видно, что схема не разошлась с моделью.
• Схема обработки запроса — путь от фото пользователя до выдачи: где считается вектор изображения, где отсекаются чужие категории, в какой момент подключается граф.
• Документация модели — ограничения, известные классы ошибок, требования к входным снимкам и порог уверенности, ниже которого система честно просит второе фото.
• Роли доступа — кто читает витрину, кто правит граф, кто выкатывает модель; правки связей и переобучение разделены по контурам, чтобы изменение ассортимента не ломало выдачу.
• Регламент обновления — триггеры переобучения (дрейф выдачи, новые категории), проверка регресса на отложенной выборке и порядок выката с откатом на предыдущую версию графа и модели.

Кейс: как выросла точность рекомендаций после перезапуска

Кейс внедрения: сеть одежды Mode Line с каталогом в десятки тысяч позиций. До перезапуска подбор опирался на фильтры и статистику продаж категории — пользователь задавал размер и цвет, система возвращала популярные позиции. Точность подбора не превышала 41%: больше половины предложенных образов человек менял вручную, а варианта приходилось ждать 4–5 секунд.

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

Метрики до и после

• точность подбора: 41% → 78% на отложенной выборке сессий;
• время выдачи варианта: 4–5 секунд → менее секунды;
• доля возвратов по подобранным образам: 24% → 11%;
• доля заказов с комплектом из двух и более вещей: 18% → 34%.

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

Чем отличается рекомендация по фото от фильтров каталога?

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

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

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

Вопросы, которые задают перед стартом проекта

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

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

Как быть с разнородными атрибутами поставщиков?

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

Как проверяете качество до запуска?

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

Кто поддерживает модель после внедрения?

Модель стареет вместе с ассортиментом: меняются коллекции, названия оттенков, поставщики. Регламент включает переобучение на новом срезе данных, контроль метрик и разбор спорных подборок; новые категории подключаем этапами.

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

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

Обсудим задачу: как мы начнём работу над системой

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

Что нужно от вашей стороны:

• Выгрузка каталога в текущем виде: артикулы, категории, атрибуты, размерные сетки, доступность по регионам.
• Фото товаров и, если есть, снимки покупателей — по ним видно, насколько условия съёмки отличаются от студийных.
• Описание текущего пути покупателя: где он ищет образ, на каком шаге уходит, кто консультирует сейчас.
• Ограничения предметной области: стоп-листы, несовместимые сочетания, сезонность, правила выкладки.
• Тестовый контур каталога или регулярная выгрузка — чтобы прототип работал на живых данных.
• Ответственный с вашей стороны и метрика, по которой вы будете считать пилот успешным.

Взамен возвращаем:

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

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