AI-персоналізація стрічки: баланс релевантності та різноманітності

Чому персоналізація новинної стрічки ламається на масштабі

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

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

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

Глибина сесії при цьому падає: користувач гортає три-чотири картки й іде, бо нічого несподіваного в стрічці вже немає.

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

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

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

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

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

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

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

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

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

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

Режими видачі: правила, модель і гібридна схема

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

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

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

Перед запуском схему проганяють на історичних даних і порівнюють із поточною видачею за часом сесії, часткою дочитувань і повторними поверненнями. Так видно поведінку читача, а не красу звіту.

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

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

1. Аудит даних і подій. Дивимося, які сигнали вже збираються, де пропуски, дублі та затримка надходження. На виході — карта подій і список ознак, які рахуються надійно.
2. Проєктування схеми. Визначаємо, як рахується релевантність, де вмикається різноманітність і які правила не дають стрічці згорнутися в одну тему. Тут же фіксуємо метрики успіху.
3. Прототип на історичних даних. Навчання й перевірка на минулому трафіку, без ризику для користувачів. Окремо йде перевірка якості моделі: холодний старт, нові автори, рідкісні теми.
4. Контрольне порівняння варіантів. Нова видача йде проти поточної на рівних частках трафіку. Дивимося не лише середнє зростання, а й просідання за сегментами.
5. Поступове виведення на трафік. Частка користувачів зростає ступенями, на кожній — стоп-умови: падіння дочитувань, зростання скарг, зниження різноманітності.
6. Відкат змін. Перемикач повертає попередню схему ранжування за хвилини, без перезбирання: версія моделі та конфігурація зберігаються.
7. Передача й навчання команди. Документація за схемою, панелі метрик, регламент перенавчання та розбір інцидентів.

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

Що передаємо команді замовника: артефакти й регламенти

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

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

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

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

Проєкт — регіональне медіа Городские Новости з щоденним порядком денним: стрічка головної збиралася з історії переглядів і свіжості матеріалів.

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

Що показували метрики до перебудови

Частка нових для читача матеріалів у видачі трималася на рівні 6–8%: стрічка працювала як повтор уже прочитаного. Матеріали поза топовими рубриками втрачали охоплення, і автори поза ядром аудиторії отримували помітно менше показів.

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

Що змінили в ранжуванні

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

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

Результати впровадження

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

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

Чим відрізняється фільтрація від ранжування і що вибрати

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

У фільтр іде все, що не повинно дійти до стрічки: дублі та майже однакові передруки, матеріали за вікном актуальності, уже прочитане, недоступні джерела, порожні картки.

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

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

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

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

Сумніви перед стартом: розбираємо технічні питання

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

Рідкісні рубрики просядуть?

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

Як зрозуміти, що стало гірше, а не «по-іншому»?

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

Чи можна добудувати поверх поточної системи?

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

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

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

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

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

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