Скоринг риска — один из лучших ML-кейсов для системного дизайна, потому что здесь качество модели сразу упирается в цену ошибки и жёсткий бюджет задержки.
Глава помогает связать выбор порогов, запаздывающие метки, ручную проверку и резервные сценарии в одну рабочую систему.
Для интервью это особенно полезно там, где важно показать связь между ML-метриками, архитектурой решения и бизнес-последствиями.
Практическая польза главы
Цена решения
Связать оценку модели с действием продукта и реальной ценой ошибочного решения.
Онлайн-контур
Спроектировать скоринг, пороги и резервные сценарии под жёсткий бюджет задержки.
Запаздывающие метки
Учитывать обратную связь, которая приходит слишком поздно для наивной онлайновой схемы.
Материал для интервью
Получить конкретный кейс риск-системы вместо общих разговоров про ML.
Связанная глава
Precision и recall на пальцах
База для разговора о выборе порога и цене ошибок в системах оценки риска.
Fraud / Risk Scoring ML System — это классический ML-кейс, где цена ошибки чувствуется сразу: слишком мягкая система пропускает потери, слишком жёсткая режет конверсию и доверие пользователей. На интервью важно показать, как вы связываете , скоринг в реальном времени, и ручную проверку в один рабочий контур.
Функциональные требования
- Вычислять оценку риска для платежей, логинов, переводов и новых событий устройств почти в реальном времени.
- Поддерживать политику решения: одобрить, запросить дополнительную проверку, отправить на ручной разбор или заблокировать операцию в зависимости от уровня риска.
- Использовать признаки из истории пользователя, графа устройств, географических паттернов, проверок частоты операций и внешних сигналов риска.
- Собирать запаздывающие метки из возвратов платежей, подтверждённого мошенничества, ручной проверки и клиентских оспариваний.
Нефункциональные требования
- Задержка p95 должна оставаться ниже 120 мс на синхронном критичном пути.
- Система должна переживать деградацию внешних провайдеров и хранилища признаков за счёт резервных сценариев и безопасных значений порогов по умолчанию.
- Нужен полный след аудита: какие признаки, какая модель и какой порог привели к решению.
- Система должна поддерживать частую перекалибровку и обновление порогов без полного пересчёта всего контура.
Масштаб и предположения
Транзакций в день
250M+
Высокий поток событий требует дешёвого пути скоринга и потокового обновления признаков.
Пиковый QPS скоринга
75k
Пики совпадают с маркетинговыми кампаниями, днями выплат и праздничными периодами.
Задержка меток
дни и недели
Возвраты платежей и подтверждённое мошенничество становятся известны заметно позже момента решения.
Цена ложного срабатывания
очень высокий
Излишняя блокировка операций бьёт по конверсии, доверию пользователей и нагрузке на поддержку.
Референсная архитектура
Удобно смотреть на такую систему как на стек слоёв: от входящих сигналов и плоскости признаков до ручной проверки и контура следующей настройки.
Что держать под контролем
Такую систему полезно смотреть не только как поток запросов, но и как баланс цены ошибки, ограничений рабочего контура и скорости следующей настройки.
Цена ошибки
Рабочие ограничения
Контур улучшений
Ниже отдельно показаны путь чтения и путь записи: синхронный путь принятия решения и путь поздней обратной связи, который двигает метки, калибровку и следующий выпуск.
Как система читает и записывает сигналы риска
Сравнение синхронного пути решения и пути поздней обратной связи
Интерактивный прогон
Шаг
Синхронный путь принятия решения
Активный шаг
1. Событие и первичная проверка
Система получает событие, проверяет обязательные поля и решает, можно ли пустить его в критический путь.
Ключевые компромиссы
- Низкий порог уменьшает потери от мошенничества, но увеличивает ложноположительные срабатывания и лишнее трение для легитимных пользователей.
- Больше признаков в реальном времени повышает качество, но усложняет требования к свежести данных, отладку и резервный путь.
- Одна глобальная модель проще в эксплуатации, но сегментированные модели часто точнее для разных рынков и продуктов.
- Жёсткая блокировка на высоком значении оценки снижает риск потерь, но повышает цену ошибочного решения и давление на поддержку.
Частые ошибки
Рекомендации
Что стоит проговорить на интервью
- Как вы выберете порог и кто должен решать цену ложноположительного и ложноотрицательного срабатывания?
- Как вы устроите путь скоринга, если метки приходят через недели после транзакции?
- Что произойдёт при недоступности онлайновых признаков или внешнего провайдера риска?
- Как вы покажете аналитику и команде поддержки, почему система приняла то или иное решение?
Связанные главы
- Precision и recall на пальцах - Базовый язык для разговора о порогах, ложноположительных и ложноотрицательных срабатываниях.
- ML Ops Pipeline - Как собрать полный рабочий контур: выпуск, наблюдение, обратную связь и следующий цикл обучения.
- Feature Store & Model Serving - Как устроить онлайновый путь признаков, согласованность данных и резервные сценарии для скоринга.
- Human-in-the-loop, data quality и операционный контур AI - Как ручная проверка и запаздывающие метки становятся частью рабочего контура системы.
- ML-платформа в Т-Банке - Платформенный взгляд на эксплуатацию ML-систем и стандартизацию путей разработки и выпуска.