Чому GNN-рекомендації точніші на розріджених даних
Розрідженість — головна причина, через яку рекомендації вироджуються в «показуємо те, що й так куплять». У типовому каталозі в більшості користувачів історія — дві-три дії: перегляд, додавання в кошик, рідкісна покупка.
Матриця взаємодій заповнена на частки відсотка, і чим ширший каталог, тим швидше падає щільність відомих зв'язків.
Класичні методи — колаборативна фільтрація та факторизація матриці — спираються на спільні появи товарів в історіях. Коли історії майже порожні, спільних пар мало: вектори користувачів і товарів залишаються недоученими, і модель чесно йде в популярне.
У топі осідають бестселери, довгий хвіст каталогу не показується взагалі, а нові позиції не набирають статистику — коло замикається.
Графові нейромережі змінюють постановку задачі: користувачі й товари — вершини одного двочасткового графа, дії — ребра, а ознаки позиції (категорія, бренд, атрибути) додають зв'язки між схожими товарами.
Агрегація сусідів на два-три кроки збирає сигнал там, де прямих взаємодій немає: користувач пов'язаний з товаром через категорію або через схожих за поведінкою людей.
Саме тому на розріджених даних і в холодному старті якість рекомендацій тримається: новому користувачеві вистачає однієї-двох дій, новій позиції — кількох показів, щоб отримати осмислений вектор. Нижче — як цей ефект вимірюється та переноситься в робочу видачу.
Вимірюваний ефект графових моделей: швидкість, повнота, стійкість
Перший замір після переходу на графовий підхід — частка попадань у топ. Колаборативна видача спирається на частоту спільних покупок, тому рідкісні позиції у верхні рядки не прориваються, а довгий хвіст каталогу простоює без показів.
Метрики рекомендацій знімаємо пошарово: окремо за активними користувачами, окремо за рідкісними сегментами. Середній показник інакше маскує провал на ніші, а саме він визначає, чи побачить покупець щось, крім бестселерів. Граф додає до пар «користувач — товар» ребра за атрибутами, категоріями та спільними переглядами.
Повнота видачі зростає на хвості, а точність у голові каталогу не падає. Помітніше за все це на нових позиціях каталогу: у LightGCN і гібридних схемах холодний товар отримує вектор зі зв'язків, а не з накопиченої статистики продажів.
Час між публікацією картки та першим показом стискається з днів до годин — запуск колекції не чекає, поки за нею набереться історія покупок.
Окремо перевіряємо стійкість моделі. Граф зібраний з кількох типів зв'язків, тому обрив одного джерела сигналів не обнуляє видачу. Тестуємо навмисно: вимикаємо потік, дивимося просідання частки попадань у топ і час повернення до попередніх значень.
Підходи до побудови графових моделей: порівняння
Представлення даних задає стелю якості для GNN-рекомендацій сильніше, ніж сама архітектура.
Якщо в системі є лише події, працює граф взаємодій; якщо каталог розмічено зв'язками між товарами — підключають граф знань; гібридна модель використовує обидва джерела, а ознаки об'єктів залишаються базовим рівнем, що не потребує побудови ребер.
Обирають не за «сучасністю», а за щільністю даних і вартістю підтримки: кожне додаткове джерело підвищує віддачу й водночас ускладнює підготовку та розбір помилок. Нижче — порівняння підходів з умовами застосовності.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Лише граф взаємодій | щільний трафік, багато повторних дотиків до одних і тих самих позицій | холодний старт: нові користувачі та товари без історії не отримують зв'язків |
| Лише граф знань | каталог із вираженими зв'язками, подій мало | не відображає смаки конкретної аудиторії, потребує вивіреної онтології |
| Гібридна модель: взаємодії плюс знання про товар | обидва джерела заповнені, є довгий хвіст позицій | дорожча в підготовці даних, складніше пояснювати причину видачі |
| Ознаки об'єктів без графа | розріджені дані, потрібно швидко запустити базовий рівень | упирається в стелю, не вловлює спільні покупки |
На практиці майже завжди починають з ознак об'єктів і графа взаємодій — цей шар дає робочу видачу й стабільно вимірюється. Ребра знань підключають, коли з'являється довгий хвіст і нові позиції без натискань: зв'язки між товарами компенсують відсутність історії.
Міграція відбувається поступово, а не переписуванням. Додаткове джерело підключається поряд, метрики порівнюються на одній і тій самій вибірці, і лише після стійкого приросту стара гілка вимикається — зі збереженням можливості відкату, якщо якість на живому трафіку просяде.
Як ми будуємо GNN-рекомендації: етапи впровадження
Впровадження графової моделі починається не з вибору архітектури, а з даних. Поки не описано зв'язки між користувачами, об'єктами та контекстом, будь-яка модель вчиться на шумі.
Тому етапи розробки йдуть від логів до продукту, і на кожному є артефакт, який можна перевірити до переходу далі.
- Розбір логів і подій. Зводимо перегляди, додавання в кошик і відмови в єдину часову шкалу, чистимо ботів і дублі. На виході — розуміння, яких зв'язків у даних не вистачає для графа.
- Схема зв'язків. Фіксуємо типи вузлів і ребер, їхні ваги та напрямок, окремо позначаємо розріджені ділянки. Схема узгоджується до навчання — інакше якість видачі нема з чим порівнювати.
- Складання вітрин. Готуємо навчальні та перевірні набори за часом: минуле — для навчання, пізніший зріз — для контролю. Так виключаємо витік майбутніх подій в ознаки.
- Навчання моделі. Навчаємо представлення вузлів, стежимо за перенавчанням на рідкісних об'єктах і підбираємо глибину поширення ребрами. Холодні об'єкти підстраховуємо контентними ознаками.
- Перевірка якості. Рахуємо попадання в топ, різноманітність видачі та покриття каталогу. Головний критерій — відкладений період: якість на подіях, яких модель під час навчання не бачила.
- Передача в продукт. Віддаємо сервіс видачі з версіонуванням моделей, логуванням і відкатом на попередню збірку. Після релізу стежимо за зміщенням даних і дообучаємо за розкладом.
Порядок етапів послідовний, але не лінійний: якщо перевірка якості провалилася, ми повертаємося до схеми зв'язків або вітрин, а не перенавчаємо модель наосліп.
Артефакти проєкту: схеми графа, вітрини ознак, регламенти
Модель на графі живе не сама по собі: її поведінка визначається тим, як описано зв'язки та ознаки.
Тому проєкт закривається не демонстрацією метрики, а передачею робочого контуру — команда замовника повинна вміти перезібрати граф, перенавчити модель і розібрати інцидент без нашої допомоги.
- Схема графа. Типи вузлів і ребер, напрямок зв'язків, ваги, правила злиття дублів. Схема версіонується: додавання нового типу ребра не ламає вже навчені моделі.
- Опис складання зв'язків. З яких подій формується ребро, яке вікно спостереження береться, як відсікаються випадкові та накручені взаємодії.
- Вітрина ознак. Вузлові та реброві ознаки з джерелом кожної, розклад перезбирання, перевірки на зміщення розподілу між вітринами.
- Регламент перенавчання. Тригери запуску — накопичення нових взаємодій або просідання метрик ранжування; порядок валідації, критерій приймання та відкат на попередню версію.
- Правила доступу. Ролі, рівні знеособлення, розмежування вітрин за чутливістю, журнал звернень до даних про поведінку користувачів.
- Контроль якості. Набори перевірок вхідних даних, тести цілісності графа, метрики якості видачі та порядок розбору інцидентів із зазначенням відповідальних.
- Документація та передача. Інструкції із запуску й навчання, конфігурації середовищ, схема розгортання, розбір архітектури з вашою командою.
Кожен артефакт приймається за формальною ознакою: його можна відкрити, запустити й змінити без нас. Якщо пункт не проходить цю перевірку — він залишається в роботі, а не у звіті.
Кейс: як графова модель підняла попадання в топ видачі
Каталог — це довгий хвіст: більшість позицій отримує поодинокі взаємодії, а топ-1% товарів збирає основну частку переглядів.
Класична колаборативна фільтрація на таких об'єктах майже не навчається — вектор для товару з двома-трьома подіями будується на шумі, і у видачу прориваються лише розкручені позиції.
Що змінили в моделі
Ми перебудували дані в граф: вузли — користувачі, товари, категорії та атрибути, ребра — взаємодії та зв'язки між атрибутами.
За основу взяли графову нейромережу LightGCN — вона поширює сигнал ребрами й витягує розріджені позиції завдяки сусідам, — а зверху додали ребра з бази знань: сумісність, бренд, серія. Навчання йшло на семпльованих негативах, інакше модель вивчає «популярне = релевантне».
Метрики до і після
Частка попадань у топ-10 зросла приблизно в 1,8 раза, а товари поза топ-1% за популярністю стали отримувати помітно більше показів — 26% проти 7%.
Пішли три класи помилок: зациклення видачі на одній категорії, дублікати варіантів однієї моделі в межах екрана та рекомендації позицій, недоступних для замовлення.
Перевіряли не лише офлайн на відкладеному періоді, а й на частині трафіку — ефект тримався весь тиждень спостереження без просідання за конверсією в ключових категоріях.
Версії моделі та ваги зберігаються, тому повернення до попередньої видачі займає хвилини, якщо експеримент потрібно буде згорнути.
Чим відрізняється граф знань від графа взаємодій?
Граф взаємодій збирається з логів: вузли — користувачі та об'єкти, ребра — перегляд, клік, додавання в кошик, покупка, у кожного ребра вага й мітка часу.
Така структура щільна й швидко застаріває, зате відповідає на питання «що схоже за поведінкою» з точністю, недосяжною для атрибутів. Слабке місце — холодний старт: у нового об'єкта та в нового користувача ребер просто немає.
Граф знань описує предметну область, а не поведінку: об'єкт, його властивості, категорію, бренд, сумісність, обмеження. Ребра тут типізовані — «входить до», «аналог», «потребує», «замінює» — і задають зв'язок об'єктів за смислом, а не за частотою спільних дій.
Він розріджений і змінюється повільно, але дає пояснюваність: видно, через який ланцюжок зв'язків об'єкт потрапив у добірку.
Різниця підходів — у джерелі істини та в горизонті. Взаємодії точні на теплій аудиторії, але сліпі поза нею; знання покривають рідкісні категорії та перший візит, але не знають поточного попиту. Жоден із графів окремо не закриває одразу і підбір, і пояснення.
Тому на практиці частіше збирають обидва й пов'язують: спільні сутності — користувач, об'єкт, категорія — стають містками між графами. Представлення вузлів з обох джерел приводяться в один простір, а шар уваги вирішує, який граф зважувати сильніше для конкретного запиту.
Ми проєктуємо зв'язку так, щоб вимкнення одного джерела погіршувало видачу поступово, а не обвалювало її: так простіше порівнювати варіанти та відкочуватися.
Технічні сумніви: дані, якість, пояснюваність
Технічний керівник перед стартом ставить одні й ті самі питання: чи вистачить історії, як модель наздоганяє зміни каталогу, чим довести перевагу над поточною видачею і як пояснити результат. Нижче — короткі відповіді.
Чи вистачить обсягу історії?
Дивимося не на довжину логу, а на зв'язність: скільки взаємодій припадає на активний товар і яка частка холодних позицій.
Якщо в половини каталогу менше десятка подій, стартуємо з гібрида — контентні ознаки та правила доповнюють графові ембедінги, інакше модель рекомендує лише хіти.
Як переживає щоденні правки каталогу?
Нові й товари, що пішли, не ламають видачу: вузли графа оновлюються інкрементально, а зв'язки перераховуються за подіями, що надійшли. Для позицій без історії підмішуються контентні ембедінги — товар отримує осмислену видачу з першого дня, а не через місяць накопичення кліків.
Чим доведете, що граф кращий за поточну видачу?
Офлайн-замір на відкладеному періоді: порівнюємо recall і NDCG на рівній кількості позицій, окремо рахуємо частку холодних товарів у топі. Фінальне слово за онлайн-тестом на частині трафіку — офлайн не показує, як користувачі реагують на нову видачу.
Як часто перенавчаєте модель?
Ембедінги оновлюються за розкладом і на потоці нових взаємодій, тяжке перенавчання — рідше, у разі накопичення достатнього обсягу даних. Кожна версія фіксується разом з метриками, тому відкат на попередню займає хвилини.
Що покажете в поясненні рекомендації?
Не одну причину, а шлях у графі: сусідів за взаємодіями, товари-«мости» між інтересами, внесок контентних ознак. Віддаємо це окремим полем у відповіді — підтримка й категорійні менеджери бачать, на чому побудована видача, і можуть оспорити її предметно.
Обговоримо задачу: що надіслати для оцінки
Чим точніші вхідні дані, тим менше припущень у плані робіт. На етапі обговорення задачі нам не потрібен доступ до робочого контуру — достатньо вибірки логів, опису каталогу та поточної логіки видачі.
Нижче список того, що надіслати, щоб оцінка проєкту спиралася на ваші факти, а не на середні значення по ринку.
- Продукт і сценарій: що і де рекомендуємо — головна, картка об'єкта, розсилки; який об'єкт рекомендації і наскільки великий каталог.
- Поточна видача: правила, «популярне», колаборативна фільтрація — що працює зараз, які метрики вже збираєте і чим результат не влаштовує.
- Логи взаємодій: вивантаження подій за період із типом дії, міткою часу, ідентифікаторами користувача й об'єкта; частка анонімного трафіку та глибина історії.
- Зв'язки об'єктів: категорії, атрибути, бренди, постачальники, спільні покупки — усе, з чого будуються ребра графа, і в якому вигляді це зберігається.
- Цільові метрики: повнота на перших K позиціях, частка переходів, конверсія; як заміряєте зміни і чи є контрольна група.
- Обмеження: час відповіді сервісу рекомендацій, частота перенавчання, вимоги до пояснюваності видачі, правила роботи з персональними даними.
- Інфраструктура та ролі: де рахуються моделі, хто відповідає за дані й доступи, як виходять оновлення — чи можна змінювати видачу без релізу застосунку.
За цим набором ми розкладемо план робіт на етапи: підготовка даних і графа, базова графова модель, гібридна схема зі зв'язками предметної області, замір у робочому контурі. Повернемося з оцінкою строків і переліком того, що знадобиться від вашої команди.
