Розробка рекомендаційної системи для маркетплейсу

Чому рекомендаційна система маркетплейсу втрачає точність

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

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

Новинка з хорошою маржею так і не виходить на робочі позиції — попри те що формально алгоритм навчено й звітні метрики виглядають рівно.

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

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

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

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

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

Що змінюється після впровадження: конверсія, покриття, повторні замовлення

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

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

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

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

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

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

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

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

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

Підходи до побудови видачі: порівняння варіантів

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

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

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

Етапи впровадження: від аудиту даних до передачі в експлуатацію

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

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

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

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

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

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

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

Що передаємо на руки: конфігурації, схеми потоків, регламенти

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

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

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

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

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

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

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

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

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

Добір перевели на автоматичне масштабування з пріоритетом свіжих онлайн-ознак, а навантажувальні прогони ганяємо на історичних піках до викату. Частка порожніх показів упала з 31% до 6%: добір перестав «мовчати» на рідкісних категоріях і нових позиціях.

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

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

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

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

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

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

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

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

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

Технічні сумніви: холодний старт, розмітка, якість даних

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

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

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

Тому до старту робіт ми рахуємо частку аномальних подій і звіряємо її зі звітами бізнесу: розходження в 10–15% означає, що спочатку лагодимо збір, а потім будуємо модель.

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

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

Як відстежуєте якість видачі після запуску?

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

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

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

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

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