Почему ваша рекомендательная система уже мертва
Вы обучили модель. Метрики бьют рекорды. Выкатываете в продакшн. И через неделю получаете письмо от бизнеса: "Пользователи жалуются на рекомендации. Конверсия упала". Знакомо? Добро пожаловать в ад рекомендательных систем.
Проблема в том, что большинство инженеров фокусируются на алгоритмах. На нейросетях. На fancy архитектурах. А потом удивляются, почему их система не работает в реальном мире. Алгоритм — это лишь 20% успеха. Остальные 80% — это проектирование системы, которая этот алгоритм будет кормить данными, валидировать, обновлять и не давать ему сойти с ума.
Именно для этого нужен MLSD — ML System Design. Это не очередной модный акроним. Это карта выживания в джунглях ML-продакшна.
Универсальный план MLSD: что делать, когда не знаешь, что делать
Представьте, что вы строите дом. Вы же не начинаете с выбора обоев? Сначала фундамент, потом стены, потом крыша. С MLSD та же история — есть последовательность, нарушив которую вы обрекаете проект на провал.
1 Определите, какую боль вы лечите
Самый частый провал — начать с технологии. "Давайте внедрим нейросеть для рекомендаций!". Стоп. Сначала ответьте на вопросы:
- Какую бизнес-метрику мы улучшаем? (CTR, конверсия, retention)
- Что именно мы рекомендуем? (товары, статьи, видео, друзей)
- Кому рекомендуем? (новым пользователям, постоянным, сегментам)
- Как будем измерять успех? (оффлайн метрики ≠ онлайн результаты)
Ошибка номер один: запускать AB-тест без четкого критерия остановки. "Давайте посмотрим, что получится" — это путь к месячным экспериментам с нулевым результатом.
2 Соберите данные и создайте признаки — но правильно
Признаки — это топливо для ML-двигателя. Заправите плохим бензином — двигатель заглохнет. В рекомендательных системах есть две большие категории:
| Тип признаков | Что включает | Главная опасность |
|---|---|---|
| Пользовательские | Возраст, пол, локация, история просмотров, сессионные фичи | Утечка будущего (data leakage) |
| Контентные | Категория товара, цена, теги, эмбеддинги текста/изображений | Холодный старт для нового контента |
| Контекстные | Время суток, день недели, устройство | Избыточная сложность |
Самая коварная проблема — data leakage. Вы используете для предсказания в момент времени T данные, которые стали известны только после T. Пример: используете общую сумму заказа как признак пользователя, но сумма становится известна только после покупки. Модель научится "предсказывать" уже случившееся.
3 Разделите оффлайн и онлайн мир — это разные вселенные
Оффлайн-валидация говорит: "Модель идеальна, accuracy = 95%". Онлайн-A/B тест говорит: "Конверсия упала на 3%". Почему?
Потому что оффлайн вы тестируете на исторических данных, где уже известен "правильный" ответ. В онлайне модель влияет на будущие данные — создает петлю обратной связи. Пользователь кликает на рекомендованный товар → модель думает "отлично, этот товар нравится" → рекомендует его еще чаще → пользователь устает от однообразия → уходит.
4 Постройте pipeline, который не сломается завтра
Ваша модель обучилась вчера на свежих данных. Сегодня в логах появился новый признак "is_vip_user". Завтра инженеры поменяли формат логов. Послезавтра Kafka упала на 5 минут.
ML pipeline должен быть:
- Идемпотентным — повторный запуск не сломает данные
- Восстанавливаемым — можно перезапустить с места падения
- Мониторируемым — вы видите не только accuracy, но и распределение признаков, дрифт данных, latency
- Версионируемым — данные, код модели, признаки, гиперпараметры — все имеет версии
Если вы не знаете, как настроить ML-песочницу для экспериментов, посмотрите мой гайд по построению ML-песочницы на k8s и Docker. Без нормальной инфраструктуры все эксперименты превращаются в хаос.
Пять смертных грехов рекомендательных систем
Даже с идеальным MLSD вы можете наломать дров в конкретике RecSys. Вот что ломается чаще всего.
1. Проблема холодного старта: как рекомендовать новому пользователю?
Пользователь зашел впервые. У него нет истории. Ваша нейросеть с 1000 слоев бесполезна. Решения:
- Популярное — топ товаров/контента
- Демографическое — если знаем пол/возраст/локацию
- Случайное — да, иногда лучше чем ничего
- Контент-базированное — по первым нескольким взаимодействиям
Но главное — не забыть переключить пользователя на "умную" модель, как только наберется достаточно данных.
2. Фильтровальный пузырь: когда система рекомендует только одно и то же
Пользователь посмотрел один фильм ужасов → система рекомендует только ужасы → пользователь думает "здесь только ужасы" → уходит. Разбавляйте рекомендации:
- Добавляйте случайный шум (epsilon-greedy)
- Внедряйте exploration/exploitation стратегии
- Используйте multi-armed bandit для баланса
- Внедряйте "серендипити" — неожиданные, но релевантные рекомендации
3. Проблема долгосрочной ценности: клик ≠ счастье
Модель оптимизирована под CTR. Пользователь кликает на кликбейт → получает разочарование → уходит навсегда. CTR вырос, retention упал. Нужно оптимизировать под долгосрочные метрики:
- Добавляйте penalty за "плохой" контент (возвраты, низкий рейтинг)
- Используйте reinforcement learning с долгосрочной наградой
- Создайте surrogate-метрики, коррелирующие с долгосрочным успехом
4. Скалируемость: когда 100 пользователей превращаются в 10 миллионов
На локальном ноутбуке модель отвечает за 10 мс. В продакшне на реальной нагрузке — 500 мс. Пользователи не ждут. Что делать:
- Кэшируйте рекомендации для популярных запросов
- Используйте приближенный поиск (approximate nearest neighbors)
- Разделяйте тяжелые оффлайн вычисления и легкие онлайн инференсы
- Рассмотрите специализированные фреймворки для инференса
5. AB-тестирование: когда статистика лжет
Запустили AB-тест. Группа B показывает +0.5% конверсии. Статистически значимо? Возможно. Практически значимо? Вопрос.
Типичные ошибки AB-тестов в ML:
- Не учитывают сезонность (понедельник vs пятница)
- Не проверяют равномерность распределения трафика
- Останавливают тест слишком рано (peeking problem)
- Не учитывают network effects (рекомендации одного пользователя влияют на другого)
Практический план: от нуля до продакшна за 12 недель
Теория — это хорошо, но давайте смотреть на календарь. Как реально построить систему?
| Неделя | Что делаем | Критерий успеха |
|---|---|---|
| 1-2 | Сбор требований + прототип baseline (популярное) | Есть работающий прототип с dummy-данными |
| 3-4 | Паipeline данных + feature store | Признаки вычисляются для всех исторических данных |
| 5-6 | Первая ML модель (collaborative filtering) | Оффлайн метрики лучше baseline на 10%+ |
| 7-8 | Онлайн сервис + A/B тест фреймворк | Модель отвечает за <100мс на p95 |
| 9-10 | A/B тест на 5% трафика | Статистически значимый результат (или его отсутствие) |
| 11-12 | Мониторинг + alerting + документирование | Настроены алерты на дрифт данных и падение метрик |
Что делать, когда всё уже сломалось
Вы запустили систему. Первые дни всё хорошо. Потом метрики начинают падать. Пользователи жалуются. Где искать проблему?
- Проверьте данные — нет ли разрыва в логах? Не изменился ли формат?
- Проверьте признаки — не появились ли NaN или бесконечности?
- Проверьте модель — не переобучилась ли? Не забыли ли обновлять?
- Проверьте инфраструктуру — не кончилась ли память? Не упал ли кэш?
- Проверьте бизнес-контекст — не было ли рекламной кампании, которая привела новых пользователей?
Самый полезный инструмент — shadow mode. Запустите новую модель параллельно со старой, но не показывайте её рекомендации пользователям. Сравнивайте предсказания. Если они сильно расходятся — ищите причину.
FAQ: вопросы, которые задают после прочтения
Как выбрать между простой и сложной моделью?
Всегда начинайте с самой простой модели, которая может решить задачу. Линейная регрессия? Отлично. Если она работает плохо — усложняйте. Но помните: каждая сложность — это дополнительные точки отказа, latency, стоимость обслуживания.
Нужен ли нам векторный поиск?
Если у вас больше 1 миллиона товаров/контента и вы используете эмбеддинги — да. Для меньших масштабов часто хватает простого инвертированного индекса. Не усложняйте без необходимости.
Как часто переобучать модель?
Зависит от скорости изменения данных. Новостной портал — ежедневно. E-commerce с сезонностью — еженедельно. Социальная сеть — возможно, ежечасно. Но главное правило: автоматизируйте переобучение и проверку перед деплоем.
Что важнее: точность модели или скорость ответа?
Пользователь не будет ждать. Если модель отвечает дольше 200 мс, вы уже теряете пользователей. Иногда лучше быстрый ответ с чуть меньшей точностью, чем идеальный ответ через 2 секунды.
И последнее: MLSD — это не разовое действие, а образ мышления
Вы не "внедряете MLSD" и не "завершаете MLSD проект". Вы начинаете думать в парадигме MLSD. Каждое решение — от выбора базы данных до формата логов — рассматриваете через призму: "Как это повлияет на обучение модели? На инференс? На мониторинг?".
Рекомендательные системы особенно чувствительны к этой дисциплине. Они живут в петле обратной связи, где каждое предсказание меняет будущие данные. Одна ошибка в проектировании — и система начинает рекомендовать пользователям то, что им не нравится, но на что они всё равно кликают (потому что так устроен интерфейс).
Начните с малого. Автоматизируйте одну часть. Задокументируйте одно решение. Постройте один мониторинг. ML-системы не ломаются мгновенно. Они деградируют постепенно. И ваша задача — заметить деградацию раньше, чем это сделают пользователи.
