Чому каталог не продає: розробка рекомендаційної системи
Каталог на сотні тисяч позицій програє не асортименту, а видачі. Новий гість і постійний клієнт бачать однаковий перший екран: ті самі категорії, ті самі добірки, той самий порядок карток. Конверсія карток падає не через товар, а через те, що його показано не тому, хто готовий купити.
Поки персоналізація каталогу тримається на ручних правилах, її стеля задана їх кількістю. Правила нашаровуються, конфліктують між собою, і кожна зміна вимагає релізу.
Після пів сотні умов уже ніхто не скаже, чому конкретна картка опинилася першою, а перевірка нової гіпотези розтягується на тижні.
Паралельно в системі лежать невикористані дані про поведінку: перегляди, пошукові запити, додавання в обране, час на картці, відмови після переходу. Це готовий сигнал про намір, але на видачу він не впливає — максимум іде у звіт. Замкнене коло: слабка видача дає мало кліків, а на слабких даних модель не вчиться.
Робоча схема — двохбаштова модель (Two-Tower): одна частина рахує вектор клієнта за його історією, друга — вектор товару за атрибутами та текстом. Обидва вектори лежать в одному просторі, тому видача збирається не перебором каталогу, а пошуком найближчих позицій через FAISS.
Такий підбір вкладається в бюджет відповіді сторінки і перераховується на свіжих подіях, а не раз на добу. Ручні правила при цьому залишаються верхнім шаром: промо, стоп-листи та залишки обмежують видачу моделі, а не замінюють її.
Нижче розбираємо, як це закривається: від збору сигналу та валідації моделі до контролю якості й відкату на попередню версію.
Що змінюється після впровадження: ефект у вимірюваних метриках
Персоналізація зсуває метрики не за рахунок косметики в інтерфейсі, а за рахунок зміни логіки ранжування. Раніше порядок видачі будувався за популярністю та свіжістю — його отримували всі однаковий.
Після впровадження кожен користувач бачить послідовність, пораховану під його історію, тому частка цільових дій зростає без зростання трафіку.
Технічно працюють дві башти: одна рахує представлення користувача, друга — представлення об'єкта.
Близькість шукається векторним пошуком за індексом FAISS, звідти береться короткий список кандидатів, який потім переранжовується з урахуванням наявності, доставки та обмежень каталогу.
Час відповіді видачі тримається за рахунок попереднього розрахунку: представлення оновлюються за подіями, а не в момент запиту. Вітрина віддає готові блоки з кешу, тому навантаження на неї падає — замість важких вибірок на кожен показ працюють короткі читання за ключем.
Окремо знімається клас відмов, який раніше ламав видачу: холодний старт нового користувача, сплеск на розпродажі, товар без історії. На такі випадки є фолбек — популярне в сегменті, обмеження пулу кандидатів, поступове донавчання.
Ефект персоналізації стає передбачуваним: частка цільових дій і глибина перегляду зростають, час відповіді видачі залишається рівним під навантаженням, а вітрина перестає бути вузьким місцем.
Порівняння підходів до рекомендацій: правила, моделі, гібрид
Кожна схема видачі виграє на своєму профілі даних і ламається на чужому.
Ручні правила та блок популярного дають передбачуваний запуск, але не враховують інтерес конкретного користувача; колаборативна фільтрація спирається на поведінку схожих користувачів і вимагає щільного потоку подій; контентні ознаки працюють за описом самого об'єкта і не залежать від історії.
На практиці вибір визначають три речі: скільки взаємодій накопичено, як швидко оновлюється каталог і наскільки критичний холодний старт.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Правила та блок популярного | Запуск з нуля, рідкісні події, потрібна пояснювана видача | Не персоналізує, швидко впирається в стелю залученості |
| Колаборативна фільтрація | Є історія взаємодій і стабільний потік подій | Нові користувачі та нові об'єкти не отримують видачі, доки не накопичать дані |
| Контентні ознаки | Багатий опис каталогу, часті зміни асортименту | Показує схоже на вже переглянуте, не виводить за межі сформованого смаку |
| Гібридна схема | Бойовий контур з різнорідним трафіком і вимогою до стійкості | Дорожча в підтримці: перерахунок ознак, розмітка, контроль якості видачі |
Гібрид зазвичай збирають не «на все одразу», а пошарово: колаборативний сигнал відповідає за основну видачу, контентний підстраховує нові об'єкти, правила обмежують небажані поєднання.
Ми починаємо з аудиту даних і метрики якості — лише після цього фіксуємо схему, інакше порівняння підходів залишається теоретичним.
Етапи впровадження: від аудиту даних до передачі моделі
Розробка рекомендаційної системи починається не з моделі, а з даних: кожен наступний крок спирається на перевірений попередній. Спочатку рахуємо, яких сигналів бракує для персоналізації, і лише потім фіксуємо схему. Такий порядок економить тижні на переробках.
Маршрут впровадження
- Аудит даних. Дивимося склад подій, глибину історії, частку анонімних сесій і розрідженість взаємодій за каталогом. Фіксуємо, яких сигналів бракує і що потрібно добудувати у зборі логів.
- Схема рішення. Розділяємо систему на два контури: швидкий відбір кандидатів з усього каталогу та точне ранжування відібраного за ознаками користувача і товару. Тут же визначаємо перелік ознак і частоту їх оновлення.
- Налаштування видачі. Збираємо навчальні пари з історії, балансуємо популярне та нове, додаємо правила-виключення: вже куплене, обмеження за наявністю, виключення за брендом.
- Перевірка якості. Оцінюємо на відкладеному за часом відрізку, а не на випадковій вибірці, — інакше метрики завищені. Потім виводимо частину трафіку на нову видачу і порівнюємо з контрольною групою.
- Передача рішення. Віддаємо конфігурації контурів, схему ознак, регламент перенавчання та порядок відкату на попередню версію видачі. Проводимо навчання команди і залишаємося на зв'язку на період самостійної експлуатації.
Артефакти передачі: схеми, конфігурації, регламенти перенавчання
Передаємо не «працюючий сервіс під ключ», а комплект, за яким ваша команда зможе супроводжувати систему без нас: запустити, перенавчити, відкотити, розширити ознаки. Нижче — що фізично залишається в репозиторії та в базі знань після здачі.
-
Схеми інтеграції — куди рекомендаційний сервіс підключається: отримання каталогу та профілю користувача, видача списку на фронтенд і в розсилки, таймаути та поведінка за недоступності джерела даних.
-
Конфігурації навчання та видачі — параметри моделі, розмірності представлень, правила відбору кандидатів і переранжування. Усе у файлах конфігурації, а не в коді: зміна налаштувань не вимагає релізу.
-
Регламент перенавчання — тригери (за розкладом, за притоком нових позицій, за падінням метрик), порядок прогонки, критерії приймання нової версії та процедура повернення до попередньої.
-
Розмежування доступу — ролі на навчальні дані, на сервіс видачі та на запуск перенавчання, хто має право викотити модель, журналювання дій.
-
Документація рішення — архітектура, словник ознак, призначення компонентів, відомі обмеження та обхідні шляхи для кожного.
-
Набір перевірок — офлайн-метрики якості, контрольні вибірки, тести на холодний старт і на просідання інтересу до позиції.
-
Контроль у роботі — які показники знімаються постійно, пороги спрацювання, точки, де дивитися причину розходження між навчанням і видачею.
-
Інструкції з експлуатації — підйом з нуля, перезбирання векторного індексу, відновлення після збою, типові звернення та відповіді на них.
Кожен пункт звіряємо на прийманні: ваші інженери проходять по ньому руками і підтверджують, що схема читається, конфігурація запускається, регламент зрозумілий без дзвінка нам.
Кейс: персоналізація видачі в каталозі маркетплейсу
Каталог — сотні тисяч позицій, а видача трималася на правилах: популярність, свіжість, наявність. Покупець отримував той самий порядок незалежно від того, що дивився і купував раніше, тому перші екрани займали товари повз його інтерес.
Переходи в цільову дію майже не зростали разом із трафіком — вузьке місце було не в асортименті, а в тому, як його подають.
Зібрали двохбаштову модель: одна частина кодує користувача за історією переглядів і замовлень, друга — товар за атрибутами та текстами. Близькість рахується за векторним індексом FAISS, тому персональний порядок будується на льоту, а не нічним перерахунком.
Поверх скорингу залишили переранжування: наявність, умови доставки та маржа, як і раніше, вирішують, що потрапить у топ.
Що показали заміри
| Метрика | До | Після |
|---|---|---|
| Порядок видачі | єдиний, за правилами | персональний для авторизованих |
| Переходи в цільову дію зі стрічки | базова лінія | +27% на зіставному трафіку |
| Глибина сесії | 4 картки | 6,4 картки |
| Відгук видачі в години пік | просідання | рівний, учетверо швидший |
| Новий товар у стрічці | лише за загальними правилами | включається за хвилини |
Окремо перевірили стійкість: за недоступності моделі видача відкочується на попередні правила, і каталог не залишається порожнім. Повторні заміри через місяць трималися на тому самому рівні — зростання дала персоналізація, а не сезонна хвиля.
Як бути, якщо даних для навчання майже немає: холодний старт
Коли даних мало, холодний старт — це не відсутність логів взагалі, а брак історії за конкретним користувачем або об'єктом. Новий відвідувач приходить без профілю, новий товар — без показів, молодий проєкт — без накопичених взаємодій.
Матриця формально є, але розріджена: майже всі пари «користувач–об'єкт» порожні, і модель вивчає середнє за каталогом.
Перший контур будуємо не на поведінці, а на вмісті: об'єкти та користувачі описуються ознаками — категорія, бренд, атрибути, текст опису, склад поточної сесії.
З них збираються вектори, на яких навчається двохбаштова модель: одна башта кодує користувача, друга — об'єкт, близькість шукається векторним пошуком. Такий контур сходиться вже на десятках тисяч подій.
Далі — розігрів видачі: не чекаємо повної історії, а поступово підмішуємо поведінку до контенту. Вага поведінкової частини зростає разом із кількістю взаємодій користувача й об'єкта, тому свіжий профіль не переважує статистику за схожими.
Частину показів віддаємо під дослідження — навмисно різноманітну видачу для збору зворотного зв'язку за невивченими позиціями.
Слабкі сигнали розводимо за рівнями впевненості: показ, клік, доперегляд, додавання в список. Звалювати їх в один лічильник не можна — випадковий показ почне вважатися інтересом, тому кожному рівню задається вага.
Холодний старт закрито не тоді, коли модель навчилася, а коли частка персональних слотів у видачі зростає, покриття каталогу розширюється, а новий користувач отримує релевантний показ за меншу кількість кроків. Тому контентний контур ми залишаємо постійним шаром, а не заглушкою до накопичення логів.
Розбір сумнівів: якість даних, навантаження, підтримка
Якість даних ми перевіряємо до навчання, а не після. Подієвий лог фільтруємо від дублів, ботів та аномальних сплесків, биті записи не видаляємо, а позначаємо: за ними видно, де втрачається передача подій з фронту.
На виході — відтворюваний набір, на якому метрики зіставні між запусками і не «пливуть» від прогону до прогону.
Навантаження рахуємо заздалегідь: підбір рекомендацій віддає окремий сервіс, а перерахунок профілів і векторний пошук не конкурують із основною базою за ресурси.
Пошук найближчих представлень на FAISS іде в пам'яті, тому видача вкладається в загальний бюджет відповіді сторінки, а за зростання каталогу масштабується додаванням вузлів без переписування логіки.
Що робити, якщо даних на старті мало?
Перші тижні система працює на ознаках контенту та правилах схожості — вони дають осмислену видачу без історії користувача. Далі вага поступово зміщується на поведінкові сигнали в міру накопичення подій, і холодний старт перестає бути вузьким місцем.
Як ви помічаєте деградацію якості?
На контрольному зрізі рахуємо частку успішних взаємодій та охоплення каталогу; падіння за поріг піднімає оповіщення. Модель при цьому не «їде» непомітно: попередній знімок зберігається, і відкат на нього займає хвилини, а не окремий цикл навчання.
Чи зможемо донавчати модель самі?
Ми передаємо регламент перенавчання, скрипти підготовки даних і перевірку на тіньовому потоці перед викаткою — донавчання стає штатною процедурою, а не разовою акцією. Супровід моделі описуємо в документації, щоб цим займався ваш інженер.
Обговоримо задачу: які дані та доступи потрібні для оцінки
Щоб повернутися з оцінкою, а не з уточнювальними питаннями, нам потрібен доступ до фактичних даних: за ними видно, чи вистачить історії для навчання моделі або її спершу доведеться накопичувати. Нижче мінімальний набір, який закриває цей етап.
- Вивантаження подій за 3–6 місяців: перегляди, пошукові запити, додавання в кошик, покупки — з ідентифікатором користувача, ідентифікатором товару та міткою часу.
- Схему каталогу: атрибути, категорії, залишки, доступність, зв'язки між товарами.
- Тестовий доступ до API каталогу та замовлень у режимі читання — перевіримо повноту історії та частоту подій.
- Опис інфраструктури: де плануєте рахувати рекомендації — у своєму контурі чи в хмарі, які мережеві доступи для цього потрібні.
- Матрицю ролей: хто з боку бізнесу погоджує склад даних і хто відповідає за викатку на боці ваших систем.
- Поточні метрики: конверсія в покупку, частка повторних замовлень, глибина перегляду — точка відліку, з якою будемо порівнювати результат.
- Обмеження: що заборонено використовувати (персональні дані, платіжна інформація), вимоги до строків зберігання.
Далі ми рахуємо обсяг вибірки, перевіряємо дані на розрідженість і розриви, після чого надсилаємо план впровадження: етапи, точки контролю та те, який ефект ви побачите на кожному з них.
