Разработка рекомендательной системы для новостного портала

Рекомендательная система новостного портала: где ломается выдача

Первое, что умирает на новостном портале, — единая выдача. Главная страница отдаёт всем один и тот же блок: у модели просто нет признака, по которому пользователей развели бы на группы, и она ранжирует по общему счётчику кликов. Читатель с другим городом, другой рубрикой и другим ритмом чтения получает чужой интерес — персонализация выдачи существует формально, а падение вовлечённости списывают на сезонность.

Второй сбой тише: свежие материалы тонут. У статьи, опубликованной час назад, нет накопленной истории взаимодействий, и она проигрывает заметке недельной давности с большим запасом сигналов. Формально система работает корректно, фактически новостной повод выдаётся в момент, когда он уже неактуален, а лента выглядит как архив.

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

Дальше появляется редакционный костыль. Дежурный вручную двигает материалы на первые позиции, чтобы вытащить трафик к вечернему пику, и держит это на себе каждый день. Разбираем, как это закрывается: какие сигналы пересобираются, как разводятся потоки «свежее» и «по интересу» и что мерить, чтобы видеть эффект.

Измеримый эффект: удержание, дочитывания и нагрузка на редакцию

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

Главная сложность — отделить рост от сезонности и от новостной повестки. Контрольную группу держим на прежней, неслучайной выдаче и сравниваем сопоставимые по «температуре» дня, а не просто «до и после». Параллельно считаем индекс органики по всему порталу: если растут все каналы сразу, приписывать эффект рекомендациям нельзя.

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

Исследования Reuters Institute показывают, что устойчивость медиа держат именно возвращающиеся читатели, а не разовые всплески трафика, поэтому в отчёте мы отдельно фиксируем долю повторных визитов по когортам. Пилот запускаем на части трафика, а метрики и правило их подсчёта согласуем до старта — тогда рост виден в цифрах, а не в интерпретации.

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

Схему выдачи выбирают по плотности данных, а не по «продвинутости» алгоритма. Коллаборативная фильтрация в том виде, как её применяют в Netflix, опирается на накопленную историю чтений: пока матрица «читатель — материал» разрежена, блок рекомендаций показывает случайные ссылки. Контентные признаки стартуют сразу — текст, рубрика, теги, свежесть публикации, — но быстро дают перекос в одну тему.

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

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

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

Как мы внедряем: аудит логов, схема, настройка, проверка

Порядок шагов здесь не случаен: пока не ясно, какие события действительно доходят до хранилища, любая модель строится на песке. Поэтому начинаем с логов, а не с выбора алгоритма, и только потом фиксируем схему обмена и способ проверки.

1. Аудит логов. Разбираем, что именно пишется: показы, клики, дочитывания, подписки, поисковые запросы. Проверяем полноту, дубли, задержку доставки и склейку событий с профилем читателя. На выходе — перечень пробелов: где теряется идентификатор, какие поля заполняются не всегда.
2. Разметка событий. Согласуем словарь: имя события, момент времени, источник, вес действия. Дочитывание весит больше клика, случайный переход — меньше. Единый словарь позволяет переобучать модель и корректно сравнивать периоды между собой.
3. Схема интеграции. Решаем, как подборки попадают на страницу: серверная отдача, отдельный сервис выдачи или подготовленный кэш. Фиксируем поведение при недоступности сервиса — читатель должен видеть осмысленный список, а не пустой блок.
4. Проверка на истории трафика. Прогоняем модель на накопленных логах: восстанавливаем сессии по времени, отдаём рекомендации и смотрим, попали бы они в фактические действия. Ошибки видны до первого показа живому читателю.
5. Онлайн-эксперимент. Включаем выдачу на части трафика рядом с текущим механизмом: наблюдаем глубину сессии, долю дочитываний, отклик страницы. Раскатка идёт долями, откат — одним переключением.
6. Приёмка результата. Сверяем метрики с зафиксированными до старта, проверяем поведение на пиковой нагрузке, холодном профиле и неполных данных. Передаём команде регламент переобучения, мониторинг и разбор типовых сбоев.

Что остаётся у команды портала после сдачи проекта

Сдача проекта — это не демонстрация работающего сервиса, а передача контура, который команда портала дальше ведёт своими силами. Поэтому на руки уходит не только код, но и всё, что нужно, чтобы менять правила ранжирования, переобучать модель и разбирать сбой без нас.

Приёмка идёт по списку, а не по презентации: каждый артефакт проверяем на стороне заказчика — поднимают окружение на своём стенде, прогоняют переобучение, откатывают версию.

• Код обучения и выдачи — репозиторий с конфигурациями, закреплёнными зависимостями и инструкцией подъёма окружения с нуля.
• Схемы интеграции — путь событий от показа до хранилища: форматы сообщений, повторная доставка, точки отказа, задержка обновления признаков.
• Регламент обновления моделей — периодичность переобучения, контрольные срезы, порог выката новой версии и порядок отката на предыдущую.
• Политики доступа — роли на чтение данных, разделение рабочего и тестового контуров, журналирование обращений к персональным данным.
• Набор автопроверок — доля попаданий в топ, разнообразие выдачи, поведение на новых пользователях; считается после каждого переобучения.
• Памятка по инцидентам — что смотреть первым делом при просадке метрик, как откатить версию и как вернуть прошлый набор данных.

Передача команде идёт отдельным этапом: на двух-трёх сессиях инженеры заказчика сами переобучают модель и выпускают версию в выдачу. Дальше контур живёт без нашего участия — мы остаёмся на связи, но правки идут своими силами.

Кейс: как выросла глубина чтения на новостном портале

Портал жил на хронологической ленте: материалы вставали по времени публикации, и всё решало, попадёт ли заметка в первые экраны главной. Глубина чтения держалась на 1,3 статьи за визит, больше половины посетителей уходили с главной, не открыв ни одного материала. Базу зафиксировали по 30-дневному окну до внедрения — чтобы после сравнивать на тех же метриках.

Что изменили

Ленту собрали гибридной моделью под коллаборативная фильтрация: история чтения конкретного посетителя, поведение читателей с похожими интересами, свежесть материала и рубричный вес от редакции. Выдача пересчитывается при каждом обновлении страницы, для новых посетителей её наполняет популярное в рубрике за последние часы, а приоритетные материалы редакция держит в начале отдельным списком.

Ограничения остались, и мы их не прячем. Посетителям без согласия на персонализацию отдаём редакционную выдачу — это около четверти аудитории. Модель переобучается раз в сутки, поэтому на резкий новостной повод реагирует не мгновенно — в такие дни вес свежести поднимается вручную.

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

Чем поведенческая подборка отличается от редакционной?

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

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

Слабые места зеркальны. Алгоритм без достаточной истории просмотров замыкается на самом популярном, вытягивает броские заголовки и постепенно сужает тематику до пары рубрик. Редактор не масштабируется: один порядок на всех, ручная правка не успевает за потоком новостей, а субъективность решения сложно проверить метрикой.

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

Сомнения по качеству данных и холодному старту

Возражения перед стартом звучат почти одинаково: разметки нет, новым материалам рекомендации не нужны, прошлогодние предпочтения не отражают интереса аудитории. Отвечаем по существу.

Начинаем не с модели, а с ревизии данных: логи показов и кликов, доля автоматического трафика, глубина сессии, полнота рубрикатора. Где истории мало, работает близость по тексту и тегам — подборка собирается с первого дня, персональные веса подтягиваются по мере событий.

Как оцениваете качество подборки?

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

Что со свежестью новостей?

Вес свежести — отдельный параметр выдачи, а не переобучение всей модели. Материал поднимается в первые часы, дальше уступает тем, что удерживают внимание. Окно настраивается по рубрикам: у срочных новостей короче, у аналитики длиннее.

Как часто переобучаете модели и можно ли откатиться?

Переобучение идёт по расписанию и по триггеру деградации метрик. Веса обновляются без остановки выдачи, предыдущая версия сохранена для отката, включение — после прогона на теневом трафике.

Обсудим задачу: что нужно знать перед стартом

Чтобы обсудить задачу предметно, нам не нужен полный доступ к продакшену — хватит описания портала и выгрузок. Чем точнее входные данные, тем быстрее вернёмся с оценкой и планом работ: разложим объём по этапам, укажем, что делаем на нашей стороне, а какие данные и решения нужны от вашей команды перед стартом проекта.

• Профиль контента и объёмы: сколько материалов публикуется в сутки, какая доля новых против архива, как часто обновляются рубрики и как долго материал живёт в лентах.
• Доступы к аналитике: выгрузка событий за 3–6 месяцев — показы, клики, дочитывания, возвраты, поиск внутри портала. Обезличенные идентификаторы читателя и метка времени достаточно, персональные данные не нужны.
• Разметка материалов: есть ли теги, рубрики, сущности, эмбеддинги в вашем хранилище — или их предстоит собрать из текстов на нашей стороне.
• Точки выдачи: где рекомендации должны появиться — главная лента, блок «похожее» внутри статьи, рассылки, мобильное приложение. Для каждой точки важен свой набор сигналов.
• Ограничения инфраструктуры: где работает прод, какой отклик выдачи считается приемлемым и какой запас по нагрузке нужен на пиковых часах.
• Правила редакции: что нельзя рекомендовать, сколько ручных промо нужно оставлять в ленте, есть ли требования по разнообразию рубрик.
• Метрики успеха: что считаем результатом — долю дочитываний, глубину сессии, возвраты на следующий день. От них зависит схема сравнения с текущей лентой.
• Кто принимает решение: человек со стороны редакции и со стороны продукта, который подтверждает приёмку этапов.

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