Production-архитектура рекомендаций в корзине
После baseline и ranker нужно объяснить production: где считаются кандидаты, где хранятся фичи, как часто пересчитывать рекомендации при изменении корзины?
Короткий ответ
Offline считаем item-item neighbors, item/user/category features и обучаем ranker. Online при изменении корзины достаем candidates, обогащаем cached features, скорим ranker и возвращаем top-K с throttling/cache.
Полный разбор
Архитектура обычно двухконтурная. Offline: ETL собирает события, заказы, каталог и availability; считает item-item candidates, popular lists, user/item/category features; обучает ranker и публикует артефакты.
Online: cart service вызывает recommendation service при значимом изменении корзины. Сервис берет товары корзины, достает candidates из low-latency storage, фильтрует unavailable/already-in-cart, обогащает признаками из feature store/cache, скорит ranker и возвращает top-K.
Нужны latency budget, throttling и cache: не пересчитывать каждую секунду, а пересчитывать на add/remove item, смену магазина/адреса или через короткий TTL. Мониторинг: latency, empty response rate, fallback share, CTR, conversion, revenue, drift фичей и freshness каталога.
Теория
Production RecSys — это не только модель, а контур данных, storage candidates/features, online serving, fallback policy и monitoring.
Типичные ошибки
- Считать тяжелые co-occurrence или ranker features синхронно на запросе.
- Не обсудить latency и cache.
- Забыть про availability и freshness каталога.
Как отвечать на собеседовании
- Раздели offline и online контуры.
- Назови триггеры пересчета: add/remove, context change, TTL.