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

Почему рекомендательная система маркетплейса теряет точность

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

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

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

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

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

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

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

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

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

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

Подходы к построению выдачи: сравнение вариантов

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

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

Этапы внедрения: от аудита данных до передачи в эксплуатацию

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

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

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

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

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

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

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

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

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

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

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

Кейс: доля заказов из блока подбора на маркетплейсе выросла втрое

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

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

Сезонные всплески спроса оказались главной проверкой: в пиковые дни нагрузка на подбор росла в разы, и прежняя схема деградировала — блок начинал отдавать заранее посчитанные подборки вместо персональных. Подбор перевели на автоматическое масштабирование с приоритетом свежих онлайн-признаков, а нагрузочные прогоны гоняем на исторических пиках до выката. Доля пустых показов упала с 31% до 6%: подбор перестал «молчать» на редких категориях и новых позициях.

Чем правила и ручные подборки отличаются от обучаемых моделей

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

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

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

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

Технические сомнения: холодный старт, разметка, качество данных

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

Качество событий задаёт потолок выдачи сильнее, чем архитектура. Дубли в логах, разрывы при недоставке, боты и тестовые аккаунты раздувают выборку и смещают веса. Поэтому до старта работ мы считаем долю аномальных событий и сверяем её с отчётами бизнеса: расхождение в 10–15% означает, что сначала чиним сбор, а потом строим модель.

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

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

Как отслеживаете качество выдачи после запуска?

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

Обсудим задачу: какой каталог и какой поток событий у вас сейчас

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

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

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