Как встроить модель возврата в продукт
Модель уже умеет предсказывать вероятность возврата. Как ее применить в продукте и где хранить признаки?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Если решение принимается раз в день или неделю, проще batch scoring: пересчитать признаки, посчитать score, записать аудиторию для CRM/push-сервиса. Online endpoint нужен только если решение зависит от свежего действия пользователя.
Полный разбор
Нужно отделить две вещи: где считается score и где принимается бизнес-действие. Для недельной кампании достаточно batch-пайплайна: обновить признаки, применить модель, выбрать пользователей выше порога и передать список в сервис коммуникаций. Такой путь дешевле, проще мониторится и не добавляет latency в пользовательский запрос.
Признаки лучше держать рядом с ML-пайплайном или в feature store, где есть offline/online консистентность. Если push-сервису нужен только финальный флаг или score, не надо гонять через сеть большой feature vector. Если же решение должно реагировать на свежую сессию, нужен online store с TTL и endpoint, который быстро достает последние признаки.
После запуска обязательно нужен A/B тест: не только uplift по покупкам, но и стоимость скидок, отписки, жалобы, fatigue от коммуникаций и стабильность latency/ошибок пайплайна.
Теория
Serving-архитектура выбирается по freshness и SLA. Batch scoring часто лучше, когда действие не обязано быть мгновенным.
Типичные ошибки
- Делать online endpoint там, где достаточно разового batch scoring.
- Передавать тяжелые признаки между сервисами вместо финального score.
- Не считать стоимость промо как часть online-метрики.