Рекомендательная система становится сложной не в момент обучения модели, а там, где нужно быстро сузить каталог, оценить кандидатов и уложиться в жёсткий бюджет задержек на пользовательском запросе.
Глава связывает быстрый отбор кандидатов, признаки пользователя и объекта, каскад ранжирования, план деградации и обратную связь от пользователей в одну рабочую архитектуру.
В интервью и инженерных обсуждениях этот кейс полезен тем, что показывает, умеете ли вы одновременно говорить о качестве рекомендаций, стоимости расчёта, свежести сигналов и влиянии продукта на архитектуру.
Генерация кандидатов
Важно заранее определить, какие источники кандидатов дают ширину каталога, а какие отвечают за персональную точность и быстрый отклик.
Бюджет ранжирования
Чем тяжелее модель, тем жёстче нужно делить задержку между отбором кандидатов, вычислением признаков и финальным ранжированием.
Свежесть сигналов
Нужно решить, какие пользовательские действия должны попадать в выдачу почти сразу, а где допустима более медленная синхронизация.
План деградации
При сбое хранилища признаков, индекса приближённого поиска соседей или тяжёлого ранжирования система должна уметь перейти на более простой, но безопасный режим.
Связанная глава
Machine Learning System Design
Фреймворк для ML-кейсов: постановка задачи, метрики, данные и продакшн-риски.
Рекомендательная система — это кейс не про одну «умную модель», а про то, как быстро сузить каталог, оценить кандидатов и уложиться в жёсткий бюджет задержек. На интервью важно показать, как система раскладывается на , и финальный слой правил, а затем связать эти этапы с метриками продукта вроде , удержания и конверсии.
Функциональные требования
- Формировать персонализированные рекомендации для главной страницы и персональной ленты.
- Поддерживать быстрый отбор кандидатов, ранжирование и финальную доводку списка с учётом бизнес-правил.
- Учитывать неявные сигналы пользователя: просмотры, лайки, досмотры, клики и пропуски.
- Давать понятное объяснение, почему рекомендация была показана пользователю.
Нефункциональные требования
- Укладываться в 95-й перцентиль меньше 200 мс на пользовательском запросе.
- Обновлять модели без простоя и проверять качество на отложенных контрольных группах.
- Держать под контролем стоимость вычислений и хранения признаков по мере роста аудитории.
- Иметь безопасный резервный сценарий при сбое сервинга модели или хранилища признаков.
Масштаб и предположения
Для персональных лент и витрин система почти всегда работает в режиме . По мере роста это быстро превращается в высокий поток на самом чувствительном пользовательском сценарии.
| Параметр | Оценка | Почему важно |
|---|---|---|
| Ежедневная аудитория | 12M | Платформа с крупной ежедневной аудиторией и персональной лентой. |
| Пиковая нагрузка на рекомендации | 180k запросов/с | Пики утренних и вечерних сессий, а также высокая нагрузка на несколько поверхностей выдачи. |
| Каталог кандидатов | 10M+ объектов | Большой каталог контента/товаров с быстрым обновлением доступности. |
| Окно обновления признаков | 1-5 минут | Сценарии, где недавний интерес пользователя заметно влияет на релевантность. |
| Доступность | 99.95% | Рекомендации влияют на ключевую конверсию и удержание. |
Высокоуровневая архитектура
Архитектурный контур
Онлайн-путь + контур данных
Рекомендательная система держится на двух скоростях: быстрый пользовательский путь отвечает за сотни миллисекунд, а контур данных постепенно обновляет признаки, модели и индексы.
Онлайн-выдача
синхронный путь пользовательского запроса
Запрос пользователя
Поверхность, контекст, устройство и свежие сигналы сессии.
Генерация кандидатов
Популярное, похожее, подписки, ANN-индекс и ручные приоритеты.
Ранжирование
Модель оценивает кандидатов по признакам пользователя, объекта и контекста.
Правила и ответ
Диверсификация, фильтры безопасности, частотные ограничения и итоговая выдача.
Что связывает контуры
На схеме пользовательский запрос идёт по синхронному пути выдачи, а пользовательские события асинхронно попадают в потоковую шину, обновляют , а слой достаёт кандидатов, считает оценки и собирает итоговый список после фильтров и правил.
Если в системе есть векторный слой похожести, генерация кандидатов часто опирается на , чтобы не перебирать весь каталог целиком.
Если продукту нужны мгновенные подсказки по брендам, категориям или коллекциям, рядом с основным контуром рекомендаций часто держат , чтобы быстро находить нужные начала строк без полного прохода по каталогу.
Важные компромиссы и архитектурные развилки
В рекомендательной системе постоянно сталкиваются краткосрочный отклик, , и нужная .
Свежесть сигналов и стабильность
Чем быстрее обновляются признаки и модель, тем точнее система ловит недавнее намерение пользователя, но тем выше риск колебаний качества и операционная нагрузка.
Открытие нового и опора на уже известное
Сильный упор на уже проверенные объекты поднимает краткосрочную кликабельность, но обедняет каталог. Контролируемое знакомство с новым контентом помогает не замыкать пользователя в узком пузыре.
Качество модели, задержка и стоимость
Более тяжёлая модель может улучшить выдачу, но легко выбивает бюджет задержек и стоимость вычислений. Поэтому систему обычно строят каскадом из дешёвых и дорогих этапов.
Персонализация и объяснимость
Чем глубже персонализация, тем труднее объяснить пользователю и бизнесу, почему он видит именно эти рекомендации. На финальном слое помогают явные причины показа и дополнительные правила.
Типичные антипаттерны
На практике рекомендательные системы чаще рвутся не из-за одной неудачной формулы ранжирования, а из-за отсутствия и мониторинга .
Один тяжёлый ранжировщик без предварительного отбора кандидатов, который ломает бюджет задержек на пике.
Обучение только на кликах без учёта отложенных метрик: удержания, длительных досмотров и отписок.
Отсутствие резервных сценариев: при сбое хранилища признаков рекомендации исчезают полностью.
Отсутствие мониторинга сдвига распределения, когда офлайн-метрики хорошие, а онлайн-показатели деградируют неделями.
Что проговорить на интервью
Полезно заранее развести офлайн-метрики качества ранжирования, например и , и онлайн-метрики вроде доли кликов, глубины просмотра и конверсии. Если в системе есть векторный слой похожести, стоит отдельно проговорить, как ведёт себя и как система деградирует при его недоступности.
- Как выглядит рабочий путь от события или запроса пользователя до итогового списка рекомендаций, и где находится самый дорогой компонент?
- Какие офлайн- и онлайн-метрики вы выберете для этой системы и почему?
- Как вы решаете холодный старт для новых пользователей и новых объектов каталога?
- Как деградирует система при недоступности хранилища признаков, индекса приближённого поиска ближайших соседей или слоя сервинга модели?
Связанные материалы
- Deep Neural Networks for YouTube Recommendations - Классическая работа про двухэтапную архитектуру: быстрый отбор кандидатов и более дорогое ранжирование.
- Netflix Tech Blog - Практические тексты о том, как рекомендательная платформа меняется по мере роста продукта.
Связанные главы
- Search System - Показывает похожее разделение на быстрый отбор кандидатов и более дорогой этап ранжирования.
- Twitter/X - Показывает, как рекомендации упираются в ленту, массовое распространение контента и персонализацию под высокой нагрузкой.
- Платформа A/B-тестирования - Как проверять качество рекомендаций в экспериментах и держать под контролем защитные метрики продукта.
- Точность и полнота - Помогает аккуратно обсуждать метрики качества выдачи и компромисс между точным попаданием и лишним шумом.