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

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

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

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

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

Схожі категорії — оверсайз-сорочка, туніка, подовжена блуза — розходяться в ознаках незначно й зливаються в одну видачу.

Якість видачі каталогу визначається не «розумом» алгоритму, а розміткою та порогом відсікання.

Якщо в каталозі є перевірені пари «фото — еталон», можна вимірювати частку запитів, де потрібний товар потрапив у перші п’ять карток, і піднімати її ітераціями, а не перезбиранням усієї системи.

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

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

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

Частка запитів, закритих з першого показу

Векторні представлення фото й карток товару обчислює одна модель, тому зіставлення йде за силуетом, кроєм і фактурою, а не за тегами.

Частка сесій, де товар іде в кошик із першої видачі, зростає — це видно й у загальній конверсії каталогу, а кількість уточнювальних дій падає з чотирьох-п’яти до одної-двох. Працюємо на CLIP-подібній архітектурі: дообучаємо модель на каталозі замовника, без збору датасету з нуля.

Порожні видачі та швидкість підбору

Раніше частка запитів без результату трималася високою: текстовий опис погано передає принт, крій або відтінок. Візуальний індекс відповідає завжди — за слабкого збігу віддає найближчі аналоги за формою й кольором.

Частка порожніх видач падає до одиниць відсотків, а швидкість підбору товару скорочується до частки секунди на запит.

Повернення та навантаження на розмітку

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

Паралельно знімається навантаження з ручної розмітки — атрибути проставляються автоматично, а нові позиції потрапляють у пошук у день публікації.

Підходи до розпізнавання: порівняння варіантів

Підбір за фото розв’язується трьома принципово різними схемами, і вибір між ними визначається не складністю моделі, а тим, наскільки каталог схожий на дані, на яких модель навчалася.

Готова модель тримає прийнятну точність на масових категоріях — базовий трикотаж, джинси, кросівки. Свій крій, рідкісні принти й предмети ручної роботи вона плутає.

Дообучення на каталозі знімає більшу частину промахів, але потребує розмічених пар «фото — товар» і перенавчання за великої зміни колекції.

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

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

Етапи впровадження системи підбору за зображенням

Візуальний пошук ламається не на моделі, а на каталозі: дублі карток, різні ракурси однієї речі за різного світла, атрибути без єдиного правила заповнення. Тому етапи впровадження системи йдуть від даних до моделі — спочатку аудит каталогу, потім налаштування пошуку.

1. Аудит каталогу. Рахуємо обсяг і структуру: частка дублів і майже-дублів, які категорії знято в кількох ракурсах, де фон заважає зіставленню. На виході — список товарів, які потрібно перезняти або виключити з індексу.
2. Схема рішення та метрики релевантності. Фіксуємо, що має знаходити пошук: ті самі моделі, схожі фасони, комплект «річ + аксесуар». Частку потраплянь у топ видачі та точність за категорією узгоджуємо до налаштування — інакше результат нічим приймати.
3. Підготовка навчальної вибірки. Збираємо пари «зображення → правильний товар», чистимо дублі, позначаємо складні випадки: однотонний одяг, ракурс зі спини. Ділимо дані на навчання, валідацію та відкладений набір, який модель не побачить до приймання.
4. Налаштування пошуку. Налаштовуємо вилучення ознак і структуру індексу, підбираємо пороги відсікання: коли показувати близькі збіги, а коли чесніше повернути порожню видачу.
5. Перевірка на відкладеній вибірці. Проганяємо сценарії, рахуємо метрики релевантності, розбираємо помилки за категоріями. Якщо провалюється ціла група товарів — повертаємося до розмітки, а не «докручуємо» пороги.
6. Приймання та передача. Віддаємо документацію, доступи, регламент переіндексації при поповненні каталогу й звіт за метриками. Команду замовника вчимо запускати оновлення й читати зріз помилок самостійно.

Що передаємо після впровадження: склад постачання

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

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

Кожен пункт закриваємо питанням «чи зможе ваша команда зробити це сама». Якщо відповідь «ні» — дописуємо інструкцію, а не залишаємо знання в себе.

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

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

Діагностика показала три причини.

Індекс будувався однією моделлю на весь каталог без фільтра за категорією, тому сукня шукала сумки зі схожою текстурою; ембедінги рахувалися за вихідним кадром без вирізання об’єкта, і фон важив більше, ніж сам товар; поріг відсікання стояв так, що система воліла показати хоч щось замість чесного «не знайдено».

Що змінили: вирізання об’єкта під час обробки запиту, класифікатор категорії як обов’язковий фільтр до ранжування, перезбирання індексу на векторних представленнях, перерахованих за розміченими реальними запитами, і новий поріг відсікання.

Спочатку викотили на частку трафіку поряд зі старою видачею й порівняли на живих запитах — відкат під флагом залишався однією командою.

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

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

Чим відрізняється підбір за фото від підбору за тегами?

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

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

Обмеження тут не в акуратності розмітників, а в природі мітки. На межах двоє фахівців розходяться: один ставить «оверсайз», другий — «вільний крій», і товар перестає знаходитися за обома запитами.

Кожна нова вісь опису розширює словник і обсяг роботи, але фактура, характер принта й посадка на фігурі в нього не вміщаються.

Підбір за фото порівнює не слова, а представлення зображень. Модель будує вектор, у якому одночасно закодовано силует, крій, фактуру й рисунок, — словник для цього не потрібен.

Схожість рахується як відстань між векторами, а векторний індекс віддає найближчі позиції за частки секунди на каталозі в десятки тисяч товарів. Стійкість до фону й світла дає навчання на парах знімків одного товару.

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

Теги не викидаємо: вони тримають жорсткі фільтри за розміром, категорією та наявністю. Фото відповідає за «схоже», теги звужують до того, що можна замовити.

Технічні сумніви та відповіді інженерів

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

Схожі моделі будуть плутатися між собою?

Система віддає ранжований список, а не одну відповідь, тому близькі силуети — очікуваний результат. Розділяти їх допомагає розмітка пар «схоже / різне»: за нею налаштовуємо, на які ознаки спиратися — крій, довжину, фактуру.

Що з новими колекціями, яких не було в індексі?

Індекс оновлюється в міру вивантаження каталогу, тому нові позиції з’являються у видачі після публікації карток — перенавчання не потрібне. Сезонні хвилі закриваємо регламентом оновлення: до дати старту продажів товар уже шукається.

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

Перевіряємо на контрольній вибірці: міняємо фон, світло й позу на старих картках, дивимося, чи утримує товар місце у видачі. За просадки доіндексовуємо зйомку — підбір відновлюється без перезбирання.

Як контролювати якість підбору після передачі?

Залишаємо набір контрольних запитів з еталонною видачею й проганяємо за розкладом. Звіт показує частку потраплянь у топ — деградація видна до скарг покупців, а не після.

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

Щоб повернутися з оцінкою та планом робіт, а не із загальними міркуваннями, нам потрібен доступ до ваших даних і розуміння сценаріїв.

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

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

Опишіть задачу й надішліть доступ до вивантаження — повернемося з оцінкою та планом робіт за етапами.