Как собрать feature pipeline, batch scoring и мониторинг
Данные casino-продукта лежат в хранилище и приходят через очередь сообщений. Нужно регулярно обновлять признаки и скорить пользователей. Как спроектировать production pipeline?
Короткий ответ
Нужен event ingestion из очереди, слой агрегатов/feature store, регулярный batch scoring, таблица score/history для sales и мониторинг freshness, ошибок пайплайна, drift и бизнес-метрик.
Полный разбор
Архитектуру удобно разложить на слои. Первый слой - события: регистрация, депозит, ставка, сессия, бонус, withdrawal. Они попадают в очередь и далее в raw/event storage. Второй слой - feature aggregation: регулярные jobs считают признаки за окна 1h/24h/7d, обновляют feature table и контролируют freshness.
Третий слой - scoring. Для такой задачи часто достаточно batch inference раз в час или раз в ночь, если бизнес-действие не real-time. Scoring job берет актуальные признаки, применяет модель, пишет score, сегмент, версию модели и timestamp в таблицу для CRM/sales. Если нужен near-real-time, можно добавить online scoring для новых важных событий, например крупного первого депозита.
Мониторинг: статус jobs, latency/freshness фичей, процент пропусков, schema changes, распределение score, drift ключевых признаков, размер top-K очереди, precision по отложенным label, business uplift от контактов. Также нужны backfill, версионирование feature definitions и rollback модели.
Теория
Production ML case проверяет не только модель, но и способность собрать надежный контур данных, инференса и наблюдаемости. Для batch-scoring важно не потерять freshness и lineage.
Типичные ошибки
- Описать только модель и не сказать, где живут фичи и score.
- Не мониторить freshness и падения jobs.
- Не хранить версию модели и timestamp скоринга.
Как отвечать на собеседовании
- Говори слоями: events -> features -> scoring -> action -> monitoring.
- Отдельно упомяни, что batch может быть достаточно хорош, если sales действует не мгновенно.