Чому рекомендаційна система перестає влучати в інтереси
Рекомендаційна система вчиться на журналах показів, а самі журнали — результат її ж минулих рішень. Виникає замкнена петля: популярне показується частіше, збирає більше взаємодій, сильніше закріплюється у вагах ранжування й отримує ще більше слотів.
Через кілька циклів перенавчання якість видачі починає відображати не інтереси аудиторії, а те, що вже було показано.
Так формується перекіс популярності. Довгий хвіст каталогу випадає з ротації: немає показів — немає сигналів — модель не може оцінити релевантність і не піднімає позицію у видачі.
Нові позиції потрапляють у той самий глухий кут: їхні ознаки ще не набрали статистики, тому алгоритм підстраховується й віддає слот перевіреному вмісту.
Далі запускається охолодження каталогу: ефективна видача стискається до вузького ядра, решта перестає приносити перегляди.
Назовні це виходить падінням додивлянь — наступна рекомендація схожа на попередню, користувач іде раніше, частка сесій, доведених до кінця, знижується, зростає відтік після першої ж сесії.
Найбільше страждає нішева аудиторія: її інтереси не знаходять своїх позицій і не повертаються.
Підкручування одного коефіцієнта в ранжуванні це не лікує — потрібен розбір джерел сигналу, політики показів новим позиціям і того, як система досліджує невідоме поряд з експлуатацією перевіреного. Розбираємо, як це закривається.
Ефект впровадження: додивляння, відтік, час відгуку видачі
Після перезбирання видачі змінюється не «відчуття від рекомендацій», а конкретні числа.
Глибина перегляду зростає тому, що добірка збирається за поточною сесією, а не за добовою статистикою популярності: глядачеві показують продовження того, що він дивиться зараз, а не те, що дивилися всі вчора.
Найбільше утримання аудиторії зростає в нішевих каталогах, де загальна популярність погано передбачає інтерес.
Частка глядачів, які повертаються, — другий вимірюваний ефект. Зникає цілий клас відмов: холодний старт нового профілю закривається ознаками контенту й контекстом пристрою, а рідкісний контент перестає випадати з добірки через низьку кількість переглядів.
Раніше ці два випадки давали порожню або майже порожню видачу — тепер глядач отримує осмислений список з першого заходу.
Час відгуку видачі тримаємо завдяки розділенню на передрозрахунок і онлайн-переранжування: важкі ознаки та векторні представлення обчислюються заздалегідь, пошук найближчих сусідів на Faiss віддає кандидатів за частки секунди.
Підготовка добірки скорочується з годин до хвилин, тому нові моделі й правила набувають чинності того самого дня, а не в нічному перерахунку.
Заміряємо ефект на контрольних групах: глибина перегляду, частка повернень, зниклі відмови видачі та час відгуку на високому перцентилі, а не лише в середньому. Так видно, що прискорення не куплено деградацією якості добірки.
Як будується рекомендаційна система: три режими роботи
Схема розміщення визначає три речі: як швидко оновлюється модель, де фізично лежать історія переглядів і профілі, і хто відповідає за затримку відгуку в момент видачі.
На практиці обирають між власним контуром, зовнішньою інфраструктурою та гібридом — різниця проявляється не в якості рекомендацій, а в швидкості навчання та в обмеженнях, які ви приймаєте разом із варіантом.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний контур | Дані про поведінку не повинні залишати вашу інфраструктуру, навантаження передбачуване, піки відомі заздалегідь | Перенавчання впирається в потужність заліза; зовнішні сигнали й частина контексту недоступні, оновлення моделі відбувається рідше |
| Зовнішня інфраструктура | Потрібен швидкий старт і часті експерименти з навчанням на великих обсягах історії | Історія переглядів виходить за периметр; відгук залежить від каналу до зовнішнього майданчика |
| Гібридна схема | Чутливі дані залишаються всередині, а важке навчання та рідкісні перерахунки винесені назовні | Дорожче в підтримці: два контури, синхронізація ознак, версіонування моделей і контроль розбіжностей між ними |
Навчання моделі в усіх трьох випадках відбувається за однією схемою: збір історії, підготовка ознак, перенавчання за розкладом або за тригером, перевірка на історичних логах і випробування на частині трафіку. Змінюється лише місце важкого етапу й час між появою нових даних та оновленням видачі.
Етапи впровадження: від аудиту даних до передачі моделі
Рекомендаційна система для відео — це не одна модель, а зв'язка з підготовки ознак, сервісу видачі та правил показу. Тому робота йде етапами: кожен наступний спирається на перевірюваний артефакт попереднього, а не на припущення.
- Аудит даних. Розбираємо, які події знімаються з плеєра, з якою повнотою й затримкою, як розмічено каталог. Логи перевіряємо на розриви й дублі: модель, навчена на брудних подіях, відтворює їхні помилки.
- Схема потоків. Фіксуємо шлях події повністю: збір, зберігання, розрахунок ознак, навчання, сервіс видачі. Узгоджуємо, де ознаки обчислюємо пакетно, а де вони потрібні на льоту.
- Збирання та навчання. Готуємо модель ранжування й обв'язку навколо неї: розбиття за часом замість випадкового, відкладена перевірка, окремий набір для рідкісних сценаріїв.
- Налаштування видачі. Шар поверх моделі: різноманітність, свіжість, обмеження повторів, холодний старт нових роликів, правила для ліцензійного та дитячого контенту.
- Перевірка на живому трафіку. Спочатку тіньовий режим — система обчислює видачу, але не впливає на неї. Потім порівняння з поточною видачею на частині аудиторії: час перегляду, частка додивлянь, відсів на перших секундах.
- Передача моделі. Віддаємо код, конфігурації, регламент перенавчання й панелі метрик, розбираємо з вашою командою типові збої та порядок відкату до попередньої версії.
Кожен етап закінчується тим, що можна перевірити: звіт щодо даних, схема, працююча видача на частині трафіку. Тому передача проходить без сюрпризів, а ваша команда з першого дня бачить, за якими метриками система живе.
Артефакти передачі: схеми потоків, конфігурації, регламенти
Розробка закінчується не демонстрацією, а комплектом, який ваша команда експлуатує та розвиває без нас. Усе, що ми будуємо, передається у вигляді артефактів, прив'язаних до вашого контуру: параметри запуску, схеми руху даних, описи ознак і правила, за якими система оновлюється.
Комплект перевіряємо на живому контурі — проганяємо типові сценарії разом із вашими інженерами, щоб передача не залишилася на папері.
- Конфігурації сервісів видачі та перенавчання — файли параметрів ранжування, ваг джерел, розмірів кандидатних вибірок і порогів відсікання. Змінюються без перезбирання, з історією правок і зрозумілою точкою відкату.
- Схеми потоків даних — від подій перегляду й реакцій до формування кандидатів і ранжування. Із зазначенням, де дані буферизуються, де агрегуються і що станеться при втраті вузла.
- Словник ознак — каталог з описом кожної характеристики: джерело, тип, вікно агрегації, поведінка при пропусках. Та сама ознака обчислюється однаково в навчанні та в проді.
- Політики доступу — ролі сервісів і людей, межі видимості користувацьких даних, розділення середовищ. Окремо описано, які дані не залишають ваш контур.
- Регламент оновлення — періодичність перенавчання, умови автопросування нової версії, набір перевірок якості до викочування й правила повернення до попередньої.
- Моніторинг і регламент реагування — контроль частки успішних видач, свіжості ознак і якості добірок, з порогами спрацювання та порядком розбору інцидентів.
- Документація з експлуатації — як підняти сервіс з нуля, як додати нове джерело кандидатів, як відтворити навчання на історичних даних.
Після приймання артефакти лежать у вашому репозиторії, а не в листуванні. Обговоримо задачу — покажемо, як виглядає такий комплект на конкретному прикладі стрімінгового каталогу.
Кейс: як у стрімінгу зменшили відтік і підняли додивляння
Перша версія видачі на сервісі будувалася за глобальною популярністю за добу плюс ручні добірки редакції. Новинка не піднімалася в перші позиції, доки не набирала перегляди на інших майданчиках, а глядач з однією сесією на тиждень бачив той самий ряд, що й активний підписник.
Відтік концентрувався в перших тижнях: людина відкривала каталог, не знаходила «свого» і не поверталася.
Що змінили в даних і правилах
Першим кроком зібрали подієвий шар: додивляння з точністю до хвилини, паузи, перемотування, відмови в перші хвилини, додавання до списку.
Події складали в ClickHouse, щоб перераховувати профіль глядача одразу після сесії, а не раз на добу — видача встигала відреагувати того самого вечора.
Поверх перезібраного ранжування поставили правила: квота на новинки, заборона на повтори однієї теми підряд, пониження для контенту, який глядач уже залишив, окрема гілка холодного старту за мовою інтерфейсу та типом пристрою. Це прибрало перекіс, коли у видачі жили чотири-п’ять найпопулярніших тайтлів.
Метрики до та після
- Додивляння першого епізоду: 41% → 63%
- Частка глядачів, які повернулися протягом місяця: 28% → 44%
- Частка новинок у перших десяти позиціях: 7% → 31%
- Повторні покази одного тайтла за сесію: 4,1 → 1,3
Плеєр і картки ми не чіпали — зсув дала саме перезбірка видачі. Результат зафіксували на восьмому тижні, а контрольний замір через квартал показав утримання метрик: правила не доводиться підкручувати вручну, частка ручних добірок у видачі впала з 60% до 15%.
Чим спільна фільтрація відрізняється від контентної?
Спільна фільтрація спирається лише на матрицю взаємодій: хто що додивився, лайкнув, додав до списку, на якій хвилині пішов. Їй не потрібні описи — вона знаходить зв’язки, які розміткою не виразити.
Плата за це — холодний старт: новий фільм і новий глядач без історії отримують популярне замість релевантного.
Контентний підхід працює з ознаками самого об’єкта: жанр, теги, актори, режисер, тривалість, векторне представлення опису та субтитрів.
Він вмикається з першого дня й пояснюваний, але залежить від якості розмітки, а профіль глядача замикається на вже переглянутому — видача перестає дивувати.
У робочій видачі їх комбінують.
Спільна фільтрація дає основну партицію кандидатів, контентний підхід закриває холодний старт і нішеві жанри, а поведінкові сигнали поточного сеансу — додивляння перших хвилин, пропуск, автоперехід до наступної серії — переважують багатомісячну історію. Netflix описує свою видачу як суміш моделей, де ваги залежать від сегмента глядача.
Перевіряємо порівняння не на око, а на метриках: частка додивлянь до кінця, скільки нових позицій каталогу глядач відкриває за місяць, утримання підписки через тиждень і місяць, час відгуку видачі.
За цими зрізами й видно, яку частку має займати кожна модель у комбінованій видачі для конкретного сегмента.
Часті технічні сумніви: холодний старт і якість даних
Перед стартом майже завжди запитують те саме: що робити, якщо даних про користувача немає, як не зламати видачу при оновленні та чи залишаться моделі в замовника після запуску. Коротко — як це влаштовано; деталі розберемо на дзвінку.
Якщо історії користувача майже немає — рекомендації будуть випадковими?
Ні. Холодний старт закриваємо контентними ознаками (тема, тривалість, жанр, автор) і популярністю в схожому сегменті, а перші дії підтягуємо за хвилини. Персоналізація вмикається поступово, без «порожніх» добірок на вході.
Що робити з шумом у розмітці?
Ми оцінюємо якість розмітки до навчання: чистимо дублі, ботів і випадкові кліки, зважуємо сигнали за глибиною перегляду, а не за самим фактом відкриття. Це прибирає перекіс у бік «клікбейтних» карток.
Чи можна оновлювати модель без зупинки сервісу?
Так. Нова версія викочується в тіньовому режимі на частині трафіку й порівнюється з поточною за метриками утримання; при просіданні відкат миттєвий. Оновлення без зупинки — штатний режим, не окрема операція.
Кому належать моделі та дані?
Замовнику. Передаємо артефакти моделей, конфігурації, схеми ознак та інструкції з перенавчання — команда може розвивати систему сама. Володіння моделями не прив’язане до нас.
Чому добірки виглядають однотипно?
Так працює оптимізація лише під клік: видача згортається у вузьке коло популярного. Додаємо штраф за повтор і різноманітність за темами та авторами — охоплення контенту зростає, а утримання не падає.
Обговоримо задачу та повернемося з оцінкою й планом впровадження
Щоб оцінка робіт була схожа на правду, на дзвінку розбираємо задачу в термінах даних і метрик, а не побажань.
Опишіть, які сигнали вже збираються — покази, кліки, додивляння, пошукові запити, оцінки, — і ми скажемо, який клас моделей на них реалістичний, а де історію доведеться набирати з нуля. Від цього залежить і склад робіт, і строк до першого вимірюваного ефекту.
- які сигнали є і за який період зберігається історія — від неї залежить, як поводитиметься видача на нових позиціях каталогу;
- що вважаємо успіхом: частку додивлянь, глибину сесії, повернення наступного дня або різноманітність видачі;
- де саме вбудовуються рекомендації: головна, блок «схоже», автоплей, добірки, листи;
- скільки позицій потрібно ранжувати за раз і як швидко оновлюється каталог — від цього залежить архітектура;
- які обмеження щодо інфраструктури та прав на дані діють у вас сьогодні;
- хто з боку замовника ухвалює рішення щодо якості видачі та як часто плануються заміри;
- які сценарії не можна ламати: права на контент, вікові обмеження, регіональні ліміти.
Після дзвінка надсилаємо план впровадження за етапами, оцінку робіт за кожною частиною та склад робіт із зонами відповідальності: що робимо ми, що залишається на вашій команді.
Перший крок — пілотний запуск на одному зрізі каталогу, де ефект видно за пару тижнів; обсяг основного впровадження фіксуємо вже після нього. Опишіть задачу в зручному вигляді — повернемося з оцінкою та планом.
