Разработка AI-системы персонализации контента для сайта

Почему персонализация контента упирается в ручные правила

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

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

Второе узкое место — контекст страницы. Блок настраивается на шаблон целиком, поэтому одна и та же подборка материалов на сайте висит и на обзоре, и на карточке, и в разделе с доставкой. Персонализация контента в таком виде отвечает на вопрос «кто пришёл», но не на вопрос «зачем он на этой странице».

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

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

Что меняется после внедрения ИИ-подбора материалов

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

Что фиксируем замерами через несколько недель после запуска:

• Доля переходов вглубь сайта. До внедрения на первом материале сессию заканчивали около 80% посетителей, после — каждый третий уходит на второй и третий материал.
• Глубина просмотра. 2,1 страницы на сессию превращаются в 3,2–3,5: вовлечённость посетителей растёт за счёт релевантных связок, а не всплывающих баннеров.
• Время подготовки подборок. Часы ручной работы над блоком «читайте также» сокращаются до 10–15 минут: редакция только подтверждает или снимает предложенное системой.
• Класс отказов «всем показываем одно и то же». Витрина перестаёт быть статичной: новый посетитель видит популярное, вернувшийся — продолжение темы, а не тот же список.
• Разгрузка редакции. Освободившиеся часы уходят в новые материалы, а не в ручную перелинковку разделов.

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

Сценарии подбора: правила, модели, гибридная схема

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

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

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

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

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

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

2. Цель и схема признаков. Фиксируем, что оптимизируем — клик, глубину просмотра или заявку, — и разделяем признаки по времени доступности, чтобы в обучение не попали данные из будущего.

3. Сборка и обучение. Готовим витрину, обучаем несколько вариантов и сравниваем их на отложенном периоде. Берём не лучший на одном всплеске, а устойчивый на нескольких срезах.

4. Теневой запуск модели. Система считает рекомендации на живом трафике, но посетители видят прежнюю логику. Смотрим долю расхождений и оцениваем, насколько предложения модели релевантнее текущих.

5. Контрольная группа. Делим трафик на контроль и тест и проверяем прирост по целевой метрике вместе с отсутствием просадки по остальным. Это отделяет реальный эффект от сезонных колебаний.

6. Поэтапное включение. Доля трафика растёт ступенями, с автоматическим откатом на прежнюю логику, если метрики выходят за заданные границы.

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

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

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

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

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

Что было и что изменили

Редакция собирала блоки «читайте также» вручную: дежурный редактор раз в смену проставлял по 5–6 ссылок к каждому материалу, на подборки уходило 3–4 часа. Глубина просмотра держалась на 1,8 страницы, в связанные материалы уходило 6% переходов, а на длинных лентах связки повторялись — читатель упирался в одни и те же тексты.

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

Метрики на контрольной группе

Замеры вели на контрольной группе: 10% трафика две недели получали прежние ручные подборки, остальные — персональные. Глубина просмотра выросла с 1,8 до 3,1 страницы, доля переходов в связанные материалы — с 6% до 19%, возвраты в течение суток — на треть. Сборка подборок сократилась с 3–4 часов в смену до 20–30 минут: редактор только подтверждает или снимает предложенные связки.

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

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

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

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

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

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

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

Частые вопросы по данным, моделям и нагрузке

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

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

Как система обходится с персональными данными?

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

Встроится ли это в текущий сайт и не замедлит его?

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

Как убедиться, что персонализация работает?

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

Что входит в сопровождение после запуска?

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

Обсудим задачу и вернёмся с планом внедрения

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

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

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

Опишите задачу и пришлите то, что уже есть, — вернёмся с оценкой и планом внедрения.