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. Зіставлення йде за близькістю векторів, тому знаходиться річ, не описана жодним тегом.

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

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

Питання, які ставлять перед стартом проєкту

Перед стартом нас частіше питають не про модель, а про дані: чи вистачить каталогу і що робити з різнорідними атрибутами постачальників.

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

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

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

Як бути з різнорідними атрибутами постачальників?

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

Як перевіряєте якість до запуску?

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

Хто підтримує модель після впровадження?

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

Як забезпечується конфіденційність?

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

Обговорімо задачу: як ми почнемо роботу над системою

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

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

Що потрібно з вашого боку:

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

Натомість повертаємо:

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

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