Начать нужно с одного места показа и одного измеримого результата: например, блока «С этим покупают» в карточке товара и доли заказов, в которые добавили рекомендованный товар. Первая версия строится не на нейросети, а на правилах и простых подсчётах: что берут вместе, что популярно в категории, что похоже по каталогу. Модель машинного обучения подключается, когда эти варианты проверены и упёрлись в потолок. Польза проверяется дважды: на истории, которую модель не видела, и в работе, на части пользователей рядом с контрольной группой.
Причина такого порядка в том, что рекомендации легко сделать «красивыми» и трудно сделать полезными. Простые варианты иногда дают тот же результат, а сложная модель без проверки может уводить показы в то, что и так купили бы. Подробнее о нашей услуге написано на странице «Разработка рекомендательных систем», здесь только порядок первых шагов.
Сначала вопрос: что, кому, где и по какому сигналу
Слово «рекомендации» прячет несколько разных задач. Для каждой свой набор данных, свой способ показа и свой способ проверки, поэтому первым шагом выбирается одна из них. Выбор записывается в виде короткой карточки: что показываем, где, кому и что считаем успехом.
| Задача | Что рекомендуем и где | Сигнал успеха | Типичная ловушка |
|---|---|---|---|
| С этим покупают | Товары к тому, что в карточке или в корзине | Добавление рекомендованного товара в заказ | Рекомендуют аксессуар, который покупатель и так берёт; прирост кажется, а выручка не меняется |
| Похожее | Альтернативы товару, которого нет или который не подошёл | Переход и покупка похожего вместо ухода | Показывают слишком похожее: пять почти одинаковых вариантов вместо выбора |
| Для вас | Персональная подборка на главной или в рассылке | Возврат пользователя и покупка из подборки | Подборка повторяет то, что человек уже видел или купил |
| Следующий шаг | Статья, курс, документ, раздел для пользователя сервиса | Дочитал, открыл следующий раздел, вернулся | Награждают клик, а не пользу: заманивают заголовком, после которого человек уходит |
| Подсказка сотруднику | Похожие обращения или решения в рабочем интерфейсе | Сотрудник принял подсказку и закрыл дело | Подсказка есть, но она не вписана в рабочий порядок, и ею не пользуются |
Два вопроса отсекают половину неудачных проектов. Что изменится в поведении пользователя, если рекомендация сработает? Что мы будем считать успехом через месяц после запуска? Если ответа нет, сначала нужен ответ, а не модель.
Какие данные нужны и когда их достаточно
Рекомендательной системе нужны три вещи: перечень того, что рекомендуется (каталог), перечень тех, кому рекомендуется (пользователи или сессии), и записи о взаимодействиях между ними. Основа — взаимодействия: просмотры, добавления в корзину, покупки, прочтения, закрытые обращения. Чем сильнее сигнал, тем он надёжнее, но тем реже встречается.
| Данные | Для чего нужны | С чего хватит начать | Что обычно мешает |
|---|---|---|---|
| Покупки и заказы | Самый надёжный сигнал: человек заплатил | Выгрузка из учёта за период, где есть номер заказа, товар и дата | Заказы одного покупателя разбросаны по нескольким карточкам, гостевые заказы не связаны с пользователем |
| Просмотры и клики | Сигнал интереса, когда покупок мало | События сайта или приложения с идентификатором сессии | События пишутся не везде, боты и случайные клики попадают в данные |
| Описание каталога | Нужно для «похожего» и для новых позиций | Категория, бренд, атрибуты, текст описания | Атрибуты заполнены неровно, одинаковые товары лежат под разными названиями |
| Наличие и цена | Не рекомендовать то, чего нет | Остатки и цены на момент показа, а не на момент выгрузки | Остатки приходят с задержкой, рекомендации ведут на отсутствующий товар |
Простая проверка достаточности: возьмите случайного активного пользователя и посмотрите, сколько у него взаимодействий. Если у большинства одно-два, персональная подборка почти ничего не узнает о человеке, и уместнее рекомендации по товару («с этим покупают») и по популярному в категории. Как проверить выгрузку до начала работ, описано в статье «Как подготовить данные для ИИ-пилота».
Три ступени: правила, похожесть, модель
Идти стоит снизу вверх. Каждая следующая ступень дороже и сложнее в сопровождении, поэтому переходить на неё нужно только после того, как предыдущая проверена и по цифрам упёрлась в потолок.
| Ступень | Как работает | Когда хватает | Когда не хватит |
|---|---|---|---|
| Правила | Популярное в категории, новинки, недавно купленное другими, ручные подборки | Небольшой каталог, мало данных о пользователях, нужен быстрый запуск и понятное объяснение «почему это показали» | Каталог велик, интересы людей сильно различаются, нужно учитывать историю конкретного человека |
| Похожесть по покупкам | Считаем, какие товары берут вместе, и показываем соседей по корзине | Достаточно заказов с несколькими позициями, нужны рекомендации «с этим покупают» | Товары новые и покупок по ним мало, корзины почти всегда из одной позиции |
| Похожесть по описанию | Сравниваем товары по атрибутам и тексту описания | Новые позиции без истории, нужен блок «похожее» | Описания бедные, а похожий по тексту товар не подходит по смыслу (другой размер, другая совместимость) |
| Модель машинного обучения | Обученная на истории взаимодействий модель ранжирует кандидатов для конкретного человека | Данных много, правила и похожесть проверены и упёрлись в потолок, есть кому сопровождать модель | Мало истории, нет места для переобучения и мониторинга, нужно объяснять каждую рекомендацию |
На практике итоговая система часто остаётся гибридом: модель предлагает кандидатов, а правила отсекают недоступное, повторы и запрещённое. Если простая ступень проверена и равна модели по результату, остаётся простая: её проще понять и вести. О том, как выпустить модель в работу так, чтобы за ней следили, написано на странице «MLOps и развёртывание моделей».
Как проверить пользу до запуска: проверка на истории
До показа реальным людям версию проверяют на прошлом. Берут период, который модель не видела: обучение и построение правил идёт на более раннем времени, оценка на более позднем. Для каждого пользователя из позднего периода смотрят, угадала ли система то, что он потом выбрал. Перемешивание всех записей и случайное деление портят проверку: будущее подсказывает прошлому, и цифры получаются завышенными.
Какие метрики смотреть
- Попадание в короткий список. Доля случаев, когда реально выбранный товар оказался среди первых нескольких рекомендаций (в литературе это называют точностью и полнотой на первых позициях).
- Охват каталога. Какая доля позиций вообще когда-либо рекомендуется. Если вся система рекомендует десяток хитов, прирост кажется, а польза маленькая.
- Разнообразие. Насколько отличаются друг от друга позиции в одной подборке.
- Качество по группам. Отдельно для новых и давних пользователей, для разных категорий: средняя цифра прячет провалы.
Главное сравнение — с простым вариантом. Новая версия оценивается не сама по себе, а против правила «популярное в категории» на тех же данных. Если разница мала, сложная ступень не нужна.
Ограничение у такой проверки одно: история показывает, что люди выбирали при тех рекомендациях, которые им показывали. Товары, которые не показывали, выглядят невыбранными, хотя могли бы подойти. Поэтому проверка на истории отсеивает слабые версии, но не доказывает пользу сильных.
Как проверить пользу после запуска: часть пользователей и контрольная группа
Настоящий ответ даёт только работа. Версию включают для части пользователей, остальным показывают старый вариант (или ничего) и сравнивают итог по заранее выбранному сигналу. Долю и срок выбирают так, чтобы выявить разницу, которая важна бизнесу, и срок покрывал нормальный цикл покупки: у редких покупок он длиннее.
| Что решаем до запуска | Почему важно | Как делаем |
|---|---|---|
| Единица деления | Если один человек видит то рекомендации, то нет, сравнение теряет смысл | Делим по пользователю или по устройству и фиксируем деление |
| Главный показатель | Выбранный после теста показатель всегда найдёт улучшение | Записываем его до запуска: доля заказов с рекомендованным товаром, выручка на заказ или возврат пользователя |
| Срок | Остановка на первой «победе» даёт случайный результат | Срок и число пользователей определяем заранее и не заканчиваем раньше |
| Защитные показатели | Рекомендации могут двигать главный показатель в ущерб другим | Следим за отказами от заказа, возвратами и жалобами рядом с главным показателем |
| Каннибализация | Рекомендованное могли бы купить и без подсказки | Сравниваем итог по группам, а не только долю кликов по блоку |
Клики по блоку рекомендаций — показатель опасный. Блок может собрать много кликов и ничего не добавить в заказ, если человек купил бы то же самое через каталог. Поэтому смотрят итог по всему заказу или сессии в сравнении с контрольной группой, а не только то, что случилось внутри блока.
Правила бизнеса, которые модель не знает
Любая рекомендательная система нуждается в слое правил поверх модели. Часть из них очевидна, часть всплывает уже после запуска.
- Наличие. Не рекомендовать то, чего нет на складе или что нельзя доставить пользователю.
- Уже купленное. Не предлагать то, что человек только что получил, кроме расходных товаров, которые покупают повторно.
- Ограничения по категориям. Товары с возрастными, юридическими или совместимыми ограничениями показываются только там, где допустимо.
- Приоритеты бизнеса. Маржинальность, остатки, договорённости с поставщиками. Их лучше записывать явно, чем прятать в модель, чтобы можно было включить, выключить и объяснить.
- Персональные данные. Что из поведения пользователя допустимо использовать и хранить: этот вопрос решает юрист заказчика, а система должна уметь исключать нежелательные поля.
Для сервисов с подпиской и закрытыми данными добавляется требование, чтобы рекомендации не раскрывали чужое: подсказка «другие сотрудники смотрели этот документ» может показать, что документ существует, кому его видеть нельзя. Права на объект проверяются так же, как в самом сервисе.
Холодный старт: новые товары и новые пользователи
У новой позиции нет покупок, у нового пользователя нет истории. Модель, обученная на истории, о них ничего не знает, и это нужно решить отдельно, потому что именно новое часто важно для бизнеса.
- Новая позиция. Показываем по описанию и категории рядом с похожими, а также в специальном блоке новинок с ограниченной долей показов. По мере накопления данных переводим на обычный расчёт.
- Новый пользователь. Начинаем с популярного в выбранной категории или в регионе, затем быстро переключаем на то, что человек сам открыл в этой сессии. Сессионные сигналы сильнее долгой истории, которой ещё нет.
- Редкий пользователь. Достраиваем картину по похожим людям, но осторожно: «похожие» на малых данных ошибаются чаще.
Если новых позиций много (например, каталог обновляется каждую неделю), доля холодного старта становится главной характеристикой системы, и проверка на истории должна оценивать её отдельно.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один сценарий показа и одну систему данных, 350 000 ₽ и 3–4 недели, если данные лежат в нескольких системах: учёте, сайте, CRM. На выходе карточка задачи (место показа, сигнал успеха), оценка данных, версия на правилах как база сравнения и вилка бюджета на следующие ступени. Сумма вычитается из первого этапа, если продолжаете с нами. Цены по ступеням открыты на странице «Тарифы».
Дальше лёгкий пилот (150 000–400 000 ₽, 2–8 недель) с проверкой на истории и запуском на части пользователей, затем при необходимости тяжёлый пилот (400 000–1 200 000 ₽) с моделью и мониторингом. На любой ступени можно остановиться: исходники лежат в вашем репозитории с первого коммита. Мы делаем рекомендации для вашего каталога, сайта или сервиса. Мы не строим маркетплейсы, не продвигаем сервис и не обещаем прирост заранее: его показывает контрольная группа. Похожий метод проверки на истории применяется в прогнозировании спроса, а общий порядок разработки моделей описан на странице «Разработка модели машинного обучения».
Частые вопросы
С чего начать рекомендательную систему?
С одного места показа и одного сигнала успеха, записанных до работы. Затем собирается версия на правилах: популярное в категории, что берут вместе, похожее по каталогу. Она нужна и как первый результат, и как база, с которой сравнивается любая модель.
Нужна ли нейросеть для рекомендаций?
Не всегда. Для небольшого каталога и малого числа данных о пользователях правила и подсчёт совместных покупок часто дают тот же результат при меньших затратах на сопровождение. Модель нужна, когда она обыграла простой вариант на периоде, которого не видела.
Сколько данных нужно для рекомендательной системы?
Жёсткого числа нет. Смотрят на то, сколько взаимодействий приходится на пользователя и на товар: если у большинства их одно-два, персональные подборки слабы, и уместнее рекомендации по товару и по категории. Точный ответ даёт выгрузка и проверка на истории.
Как понять, что рекомендации приносят пользу?
Сравнить итог по всему заказу или сессии у пользователей с рекомендациями и контрольной группы без них. Клики по блоку не доказывают пользы: человек мог купить то же и без подсказки. Главный показатель и срок записываются до запуска.
Чем проверка на истории отличается от теста на пользователях?
Проверка на истории быстрая и дешёвая, она отсеивает слабые версии, но показывает выбор людей при прошлых рекомендациях. Тест на пользователях медленнее и даёт ответ о реальной пользе. Нужны оба шага, в таком порядке.
Что делать с новыми товарами, у которых нет покупок?
Показывать по описанию и категории рядом с похожими и в отдельном блоке новинок с ограниченной долей показов. Когда накопятся данные, позицию переводят на обычный расчёт. Долю холодного старта оценивают отдельно.
Нужно ли учитывать правила бизнеса?
Да, слой правил поверх модели нужен всегда: наличие, ограничения по категориям, уже купленное, приоритеты. Лучше задавать его явно, чем прятать в модель, чтобы правила можно было включать, отключать и объяснять.
Сколько стоит разработка рекомендательной системы?
Обследование — 200 000 ₽ за один сценарий и 350 000 ₽ за несколько систем, оно вычитается из первого этапа. Лёгкий пилот стоит 150 000–400 000 ₽ за 2–8 недель, тяжёлый — 400 000–1 200 000 ₽ за 2–3 месяца. Вывод в эксплуатацию — от 1 500 000 ₽ этапами по 300 000–700 000 ₽.