MrBit: ML System Design

Сначала фиксируем бизнес-действие: кого sales будет обрабатывать и когда. Target можно определить как достижение VIP-threshold по депозитам/обороту за окно, например 30/60/90 дней, а модель запускать на ранних срезах жизни игрока.

Хороший ответ начинается не с модели, а с решения, которое будет принято по score. Например: sales-команда получает список новых игроков с высокой вероятностью стать VIP и решает, кому дать персональное внимание, бонус или коммуникацию. Поэтому нужны ограничения: как рано нужен прогноз, сколько клиентов sales может обработать, какая цена false positive и false negative.

Target можно задать как бинарную классификацию: игрок достигнет публичных VIP-threshold по депозитам и обороту за следующие 30/60/90 дней. Важно зафиксировать момент наблюдения: прогноз на 1-й, 3-й, 7-й день после регистрации или после первого депозита. Для каждого момента строим срез признаков только из прошлого.

Метрики лучше связывать с action: precision@K для команды продаж, recall по будущим VIP, lift относительно baseline, calibration score, business uplift от обработки top сегмента. ROC-AUC сам по себе слабый ответ, потому что sales работает с ограниченной очередью клиентов.

Нужно обучить/оценить модели на разных observation windows: 1 день, 3 дня, 7 дней, 14 дней. Для каждого окна смотреть precision@K, lift, calibration и business value, а потом выбрать самый ранний момент, где сигнал окупает действие.

Практичный подход - сделать несколько временных срезов датасета. Для каждого игрока формируем признаки, доступные только к моменту T: через 1 день после регистрации, через 3 дня, через 7 дней, через 14 дней. Target один и тот же: станет ли игрок VIP в будущем окне.

Дальше сравниваем качество по T. Если на 1-й день precision@top-100 слишком низкий, sales потратит ресурс зря. Если ждать 30 дней, можно упустить момент раннего воздействия. Поэтому выбираем не максимальное качество, а лучший trade-off между ранностью и полезностью.

Важно проверять calibration: если модель дает score 0.8, примерно 80% таких игроков должны стать VIP. Для action-листа часто важнее lift в top-K и expected value: сколько будущих VIP мы ловим на один контакт sales-команды.

Ранние признаки: первый депозит, средний депозит, скорость повторного депозита, оборот, размер ставок, число сессий, регулярность, разнообразие игр, тренд активности, device/geo/channel и реакция на бонусы.

Фичи лучше группировать по смыслу. Деньги: первый депозит, сумма депозитов за первые N часов/дней, средний депозит, время до второго депозита, отношение депозита к ставкам, withdrawal поведение. Активность: число сессий, длительность, частота возвращения, recency/frequency, рост или спад активности.

Игровые паттерны: количество игр, типы игр, доля high-volatility игр, средний размер ставки, оборот, распределение ставок, возвращение к конкретным играм. Маркетинг и контекст: канал привлечения, бонусы, страна/регион, устройство, язык, платежный метод, KYC-сигналы, если их можно использовать законно и этично.

Важно не превращать список в leakage. Если VIP определяется оборотом за 90 дней, нельзя брать признаки, которые уже содержат будущий 90-day turnover. Все фичи должны быть доступны на момент scoring.

Нужен 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 модели.