Чому візуальний пошук за фото не знаходить товар
Користувач наводить камеру на товар або завантажує скриншот — і замість потрібної позиції отримує порожню видачу чи десяток карток з іншої категорії.
Технічно візуальний пошук при цьому відпрацював: знімок прийнято, векторне представлення пораховано, відповідь віддано за частки секунди. Збій не у швидкості, а в сенсі — система шукає схожу картинку, а не той самий товар у вашому каталозі.
Перша причина — модель рахує вектор за загальним набором зображень, де взуття, сумки й меблі лежать упереміш. На ваших картках товарів вона впевнено знаходить «щось взуттєве», але не розрізняє модель, колір і матеріал, тому релевантність каталогу падає вже на першому кроці.
Друга — якість самих карток. Одне студійне фото на білому фоні не покриває ракурси, у яких покупець знімає товар: під кутом, за жовтого світла, з фоном полиці. Якщо в каталозі немає знімків з різних боків, пошуку за фото просто немає з чим порівнювати.
Третя — індекс. Поки він перезбирається вручну раз на тиждень, нові позиції у видачі не з'являються взагалі. Частка порожніх видач зростає, покупець повертається до текстового пошуку або йде до конкурента — і це вже втрачені продажі, а не технічна дрібниця.
Розбираємо, як це закривається: донавчання на своїх картках, вимоги до зйомки й переіндексація за подією, а не за розкладом.
Що змінюється в метриках після запуску візуального пошуку
Метрики візуального пошуку рахуємо від базової лінії, знятої на історичному трафіку: частка порожніх видач, перехід у картку товару, повернення, звернення в підтримку, час відповіді на запит.
Без зафіксованої точки відліку будь-яке зростання виглядає заслугою пошуку, тому замір знімаємо до вмикання й повторюємо на тій самій вибірці запитів.
Частка порожніх видач — головний індикатор. Текстовий пошук не закриває запити на кшталт «таке саме, але з іншим принтом»: користувач іде, так і не дійшовши до каталогу.
Векторний індекс на FAISS шукає за ембеддингом фото, а не за збігом слів, тому видача наповнюється навіть за формулювання без точних термінів, і частка порожніх результатів падає в рази, а не на відсотки.
Повернення й підтримка реагують наступними. Коли покупець орієнтується на фото товару, а не на текстовий опис, рідше трапляється «не те, що очікував», і частка таких повернень знижується.
Типові звернення «допоможіть підібрати схоже» перехоплює сама видача — навантаження на першу лінію підтримки падає.
Швидкість відповіді тримаємо передбачуваною: ембеддинги каталогу рахуються заздалегідь, під час оновлення позиції перераховується лише змінена частина, а на живому запиті працює готовий індекс.
Час відповіді вкладається в частки секунди на каталогах у сотні тисяч позицій — пошук не стає вузьким місцем за пікового навантаження.
Порівняння режимів підбору: за фото, за посиланням, з камери
Режими відрізняються не інтерфейсом, а тим, що потрапляє на вхід: завантаження фото дає готовий кадр, зйомка з камери — потік змазаних і дубльованих знімків, посилання — чужу картку з водяними знаками й обрізаним товаром.
Той самий індекс векторів у цих умовах поводиться по-різному, тому обмеження режимів закладають в архітектуру заздалегідь, а не з'ясовують на живій видачі.
Спільна частина одна: виділення об'єкта та кадрування, нормалізація фону, витяг вектора й пошук найближчих сусідів в індексі з подальшим переранжуванням.
Відмінності — у передобробці та порогах: для зйомки з камери додають оцінку різкості й дедуплікацію кадрів, для посилання — вирізання елементів чужої верстки, для завантаження фото — перевірку, що об'єкт взагалі розпізнано.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Завантаження фото з галереї | Товар у кадрі повністю, потрібен підбір за зображенням і схожі товари | Результат залежить від ракурсу, фону та обрізання; без нормалізації зростає частка хибних збігів |
| Зйомка з камери в застосунку | Пошук товару в залі, коли не знаєш назви та артикулу | Потік дублів і змазаних кадрів; потрібен відбір найкращого кадру та підказки щодо наведення |
| Підбір за посиланням | Своєї картки немає, зображення тягнемо із зовнішнього джерела | Чужа верстка, водяні знаки, обрізаний товар; джерело може віддати не той кадр |
Комбінація режимів — норма: камеру ставлять на сценарій «тут і зараз», галерею — на повторний пошук, посилання — на товари поза каталогом. Вибір робимо за часткою таких запитів і за тим, які атрибути взагалі є у вашій картці.
Порядок робіт: аудит каталогу, схема індексу, перевірка якості
Порядок етапів вибудувано так, щоб кожен наступний крок спирався на перевірені дані, а не на припущення. Починаємо з аудиту каталогу — саме від нього залежить і якість візуального пошуку, і обсяг робіт із підготовки зображень.
- Аудит каталогу. Вивантажуємо картки, шукаємо дублі, товари без фото, биті посилання та різнобій у ракурсах. На виході — карта категорій з реальною кількістю позицій, придатних для навчання.
- Еталонні зображення. За кожною категорією відбираємо товари з кількома ракурсами й вручну розмічаємо їх як еталон. Це база, за якою потім вимірюємо, чи знаходить система потрібний товар за аматорським фото.
- Схема зіставлення. Визначаємо, як знімок перетворюється на вектор ознак, який індекс будуємо і за якими ознаками відсікаємо явно нерелевантне. Окремо вирішуємо, що робити з товарами, яких у навчанні не було.
- Перевірка якості. Проганяємо систему на відкладеній частині каталогу: рахуємо частку влучань у першу десятку результатів, окремо за категоріями та за складними випадками — схожі моделі, близькі кольори, зйомка за поганого світла.
- Підключення до каталогу. Налаштовуємо оновлення індексу під час появи та зняття товарів, щоб видача не застарівала й не потребувала повного перезбирання.
- Передача в підтримку. Віддаємо регламенти, схему індексу й звіт про якість видачі, навчаємо команду замовника переіндексовувати каталог і розбирати скарги на результати пошуку.
Склад постачання: індекси, схеми, політики доступу, регламенти
Індекси, схеми та регламенти — та частина постачання, за якою команда замовника розвиває пошук сама, без нас. Ми передаємо не лише працюючий сервіс, а й набір артефактів, за якими його можна відтворити, розширити й передати новому інженеру всередині компанії.
- Індекс візуальних ознак: збирання векторних представлень за всіма картками каталогу з метаданими й категорійною розміткою, плюс опис повного та інкрементального перезбирання.
- Схема даних: зв'язки товар — зображення — ознака — категорія, вимоги до якості фото й правила відбракування, щоб індекс не засмічувався дублями та стоковими знімками.
- Політики доступу: ролі для вітрини, аналітики й адмінки, розмежування прав на переіндексацію, вивантаження векторів і зміну порогів видачі.
- Регламент оновлення: тригери перезбирання під час появи, зняття з продажу або зміни категорії товару, порядок проведення та вікно, у якому пошук залишається на старому збиранні.
- Контур оцінки якості: набір еталонних запитів «фото → очікувана видача», метрика влучання в топ і звіт за нею для кожної нової версії.
- Регламент відкату: скільки попередніх збирань індексу й моделі зберігається, як повернутися на попередню й за який час видача повертається до попередньої.
- Інструкції для команди: запуск, моніторинг, розбір розбіжностей у видачі та чек-лист приймання змін від контент-менеджерів.
Окремим документом іде журнал рішень: чому обрано таку розмітку категорій і такий поріг відсікання схожих товарів, що пробували й відкинули. Він економить місяці на повторному проходженні вже пройдених розвилок.
Кейс: частка порожніх видач у каталозі впала в рази
У маркетплейсу вузьке місце знайшлося не в моделі, а в ознаках. Пошук за фото фактично зводився до розпізнавання категорії та підстановки текстового запиту: якщо знімок зроблено не в студійних умовах, система віддавала порожню сторінку або випадкові позиції з категорії.
Частка порожніх видач трималася на рівні 21%, влучання в топ-3 — 46%, і користувач після першого екрана майже завжди переходив у звичайний текстовий пошук.
Що змінили
Зібрали єдиний векторний простір для знімка й картки: за основу взяли OpenAI CLIP, донавчили на парах «фото користувача — товар із замовлення» з логів і додали другий етап — переранжування топ-50 кандидатів за атрибутами: колір, матеріал, силует.
Модель віддає вектор, пошук іде за індексом, тому відповідь вкладається в частки секунди навіть на каталозі в сотні тисяч позицій.
Що стало
Метрики до й після знімали на тому самому потоці запитів: частка порожніх видач — 2,7%, точність у топ-3 — 88%, частка замовлень, розпочатих із фотосценарію, зросла вчетверо.
Регрес ловимо на офлайн-наборі з 50 тисяч пар: якщо нова версія ембеддингів опускає точність топ-3 нижче порогу, випуск зупиняється й автоматично відкочується на попередню.
Чим відрізняється підбір за фото від підбору за атрибутами
Підбір за фото починається з того, що знімок перетворюється на векторне представлення, і система шукає найближчі позиції в індексі каталогу. Покупцеві не потрібно знати назву моделі — достатньо кадру з журналу, скриншота з переписки або фото з полиці. Підхід виграє там, де ознаку складно описати словами: силует, фактура, принт, відтінок.
Атрибутні фільтри працюють навпаки — звужують вибір за явними, заздалегідь розміченими ознаками: колір, матеріал, розмір, сумісність, діапазон характеристик. Результат передбачуваний і пояснюваний: видно, чому позиція потрапила у видачу. Але атрибути мають бути заповнені й нормалізовані, інакше фільтр мовчки відсікає половину каталогу.
Межа застосовності проходить за природою ознаки. Якщо рішення спирається на візуальну схожість — одяг, меблі, декор, деталі за зовнішнім виглядом — підбір за фото дає більш релевантну видачу, ніж пошук за словами.
Якщо вирішують числові умови, фото марне: схожа зовні деталь може не підійти за посадкою або роз'ємом.
На практиці підходи працюють у зв'язці на одному каталозі. Фото формує широкий пул кандидатів за схожістю, атрибути звужують його до сумісних варіантів і дають змогу відсортувати за наявністю.
Зворотний маршрут теж затребуваний: покупець відбирає товари фільтрами, відкриває картку й просить показати схожі.
Разом вони знижують частку порожніх видач і прибирають глухий кут «не знаю, як це назвати».
Технічні сумніви: якість знімків, холодний старт, навантаження
Інженерні сумніви спливають до старту, і майже всі вони впираються в дані, а не в модель. Нижче — чотири питання, які ми знімаємо на етапі оцінки: якість зйомки, холодний старт, навантаження й оновлення каталогу.
Половина каталогу знята на телефон за різного світла — пошук буде помилятися?
Передобробка — кроп за детекцією об'єкта, вирівнювання білого, єдиний масштаб — знімає частину розкиду. Далі схожість рахується за смисловими представленнями зображення (CLIP-подібна модель), тому фон і ракурс менше впливають на видачу. Слабкі категорії донавчаємо на своїх парах «фото — товар».
Розмітки та історії кліків немає — з чого починати холодний старт?
Стартуємо на відкритій попередньо навченій моделі: пари «фото — опис» збираємо з карток, потім підмішуємо кліки та пошукові логи. Перший робочий результат з'являється на десятках тисяч позицій, а не після збору мільйонів розмічених пар.
Чи витримає пошук пік розпродажу?
Індекс тримаємо в пам'яті й шардуємо за репліками, повторювані запити віддає кеш. На піку вмикається двоступенева схема: швидкий наближений відбір, потім точний перерахунок верхівки видачі — час відповіді залишається рівним, а не зростає лінійно з трафіком.
Як оновлювати каталог і не перезбирати індекс повністю?
Інкрементально: нова картка потрапляє в пошук за хвилини після публікації, знята з продажу йде за правилом життєвого циклу. Повне перезбирання йде на окремому контурі за розкладом — стара й нова версії індексу працюють паралельно, відкат робиться перемиканням.
Обговоримо задачу: надішліть каталог і приклади запитів
Щоб повернутися з оцінкою та планом, а не із загальними міркуваннями, нам потрібні дані про каталог і про те, як покупці шукають. Чим конкретніші вхідні дані, тим точніше ми назвемо строки, етапи й метрики приймання.
- Вивантаження каталогу в CSV або JSON: артикул, назва, категорія, атрибути, посилання на фото — за нею видно, яка частка карток придатна для індексації, а які доведеться чистити.
- 50-100 прикладів запитів, включно з помилками, сленгом і латиницею — на них будуємо перевірки якості видачі.
- Приклади фото-запитів: товар повністю, на полиці, в інтер'єрі, за слабкого світла — від цього залежить стійкість пошуку.
- Еталонна розмітка на 100-200 карток: які товари вважаються правильною відповіддю. Без неї точність не виміряти.
- Поточні показники пошуку: частка запитів без результату, переходи в картку, замовлення з пошуку — точка відліку для порівняння.
- Обмеження інфраструктури: де живе каталог, як часто змінюються залишки, чи доступне автоматичне вивантаження фото.
- Відповідальний з вашого боку: хто підтверджує розмітку й приймає етапи робіт.
Порядок робіт після цього прозорий: фіксуємо сценарії й метрики, збираємо прототип на вашому каталозі, звіряємо з еталоном, потім інтеграція та виведення в продакшн. Опишіть задачу й надішліть перелічене — повернемося з оцінкою та планом.
