Скоринг риска — один из лучших ML-кейсов для системного дизайна, потому что здесь качество модели сразу упирается в цену ошибки и жёсткий бюджет задержки.
Глава помогает связать выбор порогов, запаздывающие метки, ручную проверку и резервные сценарии в одну рабочую систему.
Для интервью это особенно полезно там, где важно показать связь между ML-метриками, архитектурой решения и бизнес-последствиями.
Практическая польза главы
Цена решения
Связать оценку модели с действием продукта и реальной ценой ошибочного решения.
Онлайн-контур
Спроектировать скоринг, пороги и резервные сценарии под жёсткий бюджет задержки.
Запаздывающие метки
Учитывать обратную связь, которая приходит слишком поздно для наивной онлайновой схемы.
Материал для интервью
Получить конкретный кейс риск-системы вместо общих разговоров про ML.
Связанная глава
Точность (precision) и полнота (recall) на пальцах
База для разговора о выборе порога и цене ошибок в системах оценки риска.
— это классический ML-кейс, где цена ошибки чувствуется сразу: слишком мягкая система пропускает потери, слишком жёсткая режет конверсию и доверие пользователей. На интервью важно показать, как вы связываете , скоринг в реальном времени, и ручную проверку в один рабочий контур.
Функциональные требования
- Вычислять оценку риска для платежей, логинов, переводов и новых событий устройств почти в реальном времени.
- Поддерживать политику решения: одобрить, запросить дополнительную проверку, отправить на ручной разбор или заблокировать операцию в зависимости от уровня риска.
- Использовать признаки из истории пользователя, графа устройств, географических паттернов, проверок частоты операций и внешних сигналов риска.
- Собирать запаздывающие метки из возвратов платежей, подтверждённого мошенничества, ручной проверки и клиентских оспариваний.
Нефункциональные требования
- Задержка по 95-му перцентилю (p95) должна оставаться ниже 120 мс на синхронном критичном пути.
- Система должна переживать деградацию внешних провайдеров и хранилища признаков за счёт резервных сценариев и безопасных значений порогов по умолчанию.
- Нужен полный след аудита: какие признаки, какая модель и какой порог привели к решению.
- Система должна поддерживать частую перекалибровку и обновление порогов без полного пересчёта всего контура.
Масштаб и предположения
Транзакций в день
250M+
Высокий поток событий требует дешёвого пути скоринга и потокового обновления признаков.
Пиковый QPS скоринга (запросов в секунду)
75k
Пики совпадают с маркетинговыми кампаниями, днями выплат и праздничными периодами.
Задержка меток
дни и недели
Возвраты платежей и подтверждённое мошенничество становятся известны заметно позже момента решения.
Цена ложного срабатывания
очень высокая
Излишняя блокировка операций бьёт по конверсии, доверию пользователей и нагрузке на поддержку.
Референсная архитектура
Систему удобно разложить на слои, чтобы развести то, что живёт на горячем пути решения, и то, что работает в фоне: от входящих сигналов и плоскости признаков до ручной проверки и контура следующей настройки.
Что держать под контролем
Такую систему полезно смотреть не только как поток запросов, но и как баланс цены ошибки, ограничений рабочего контура и скорости следующей настройки.
Цена ошибки
Рабочие ограничения
Контур улучшений
Ниже отдельно показаны путь чтения и путь записи: синхронный путь принятия решения и путь поздней обратной связи, который двигает метки, калибровку и следующий выпуск.
Как система читает и записывает сигналы риска
Сравнение синхронного пути решения и пути поздней обратной связи
Интерактивный прогон
Шаг
Синхронный путь принятия решения
Активный шаг
1. Событие и первичная проверка
Система получает событие, проверяет обязательные поля и решает, можно ли пустить его в критический путь.
Связанная глава
Выпуск моделей, калибровка и контуры экспериментов
Как задержка меток меняет интерпретацию первых дней после релиза модели.
Запаздывающие метки: обучение на неполной правде
Решение принимается за миллисекунды, а правда о нём приходит через дни и недели. — не досадная деталь, а главное проектное ограничение контура обучения: модель всегда видит неполную картину, и наивное «переобучимся на вчерашних данных» систематически занижает оценку риска.
Очередь ручного ревью
часы — дни
Самая быстрая «почти правда»: решение аналитика точное, но покрывает только трафик, который модель сама отправила на проверку.
Жалобы и оспаривания клиентов
дни — недели
Сигнал приходит раньше формального возврата платежа, но шумный: часть обращений — не мошенничество, а недопонимание или забытая подписка.
Возвратный платёж (чарджбэк) от банка-эмитента
до 120 дней
Правила Visa и Mastercard дают держателю карты до 120 дней на оспаривание, поэтому финальная метка может «дозреть» спустя четыре месяца после решения.
Подтверждения платёжных сетей и партнёров
недели
Списки скомпрометированных карт и подтверждённый фрод приходят пачками и задним числом — их нужно уметь накатывать на уже собранные обучающие срезы.
Двухскоростной контур меток
Прокси-метки — решение аналитика, ранние оспаривания, отклонённая дополнительная проверка — дают быстрый, но смещённый сигнал для оперативного дообучения. Полная модель переобучается на метках, созревших за окно чарджбэка. Один контур не заменяет другой: быстрый ловит новые атаки, медленный исправляет смещение быстрого.
Окно созревания меток
Честная выборка для обучения и сравнения моделей — транзакции старше окна созревания, обычно 90–120 дней. Цена: модель опаздывает за свежими паттернами атак, поэтому быстрый контур на прокси-метках обязателен, а не опционален.
Коррекция смещения: importance weighting
Если обучаться на свежих данных, положительные примеры систематически недопредставлены: часть фрода ещё не помечена и выглядит как «хорошая» транзакция. Классический приём — моделировать задержку метки отдельной моделью и перевзвешивать примеры (importance weighting), как в работе Chapelle о задержанных конверсиях (KDD 2014).
Валидация со срезом по времени
Прогон на исторических данных обязан использовать только метки, известные на момент скоринга, иначе оценка качества получает информацию из будущего. Сравнивать модели честно можно только на периодах, где метки уже созрели; «качество за последний месяц» — всегда оптимистичная оценка.
Проблема селективных меток
Заблокированные транзакции не получают метку вовсе: нельзя узнать, был ли это фрод. Без контрольной доли рискованного трафика, которую пропускают намеренно, или контрфактической оценки модель учится только на собственных пропусках — и каждое поколение видит всё более искажённую картину.
Самая коварная часть — селективные метки: система сама определяет, какие транзакции получат правду. Заблокированное событие исчезает из выборки, поэтому без контрольного трафика и каждое следующее поколение модели обучается на всё более искажённой картине мира.
Выбор модели: GBDT, нейросети и ансамбль
Фрод-признаки — классические табличные данные: счётчики, суммы, категории, агрегаты по окнам. Поэтому разговор о выборе модели начинается не с архитектуры нейросети, а с сильного на градиентном бустинге и честного ответа, какую проблему не решает GBDT.
GBDT: XGBoost / LightGBM
Механизм: Ансамбль деревьев с градиентным бустингом поверх табличных признаков: суммы, счётчики, категории, агрегаты по окнам, веер связей по графу.
Компромисс: Деревья устойчивы к неинформативным признакам и легко выучивают «ступенчатые» зависимости, характерные для фрода, но плохо поддерживают инкрементальное дообучение и совместное обучение с эмбеддингами.
Когда выбирать: Базлайн по умолчанию: на табличных данных малого и среднего размера ансамбли деревьев до сих пор обыгрывают нейросети (бенчмарк Grinsztajn et al., NeurIPS 2022) при заметно меньшей цене обучения, тюнинга и сервинга.
Нейросети
Механизм: DNN поверх тех же табличных признаков плюс эмбеддинги категорий, последовательностей событий и графовых сущностей; единый стек для дообучения и переиспользования представлений.
Компромисс: Лучше масштабируются по объёму данных и темпу переобучения, но требуют больше данных и дисциплины мониторинга, а выигрыш в качестве не гарантирован: Stripe при миграции Radar с ансамбля Wide & Deep на чистую DNN сначала воспроизвёл вклад XGBoost внутри новой архитектуры — иначе терялось 1.5 п.п. полноты.
Когда выбирать: Когда выборка велика, признаки включают последовательности и эмбеддинги, а узким местом стала скорость переобучения и масштабирование ансамбля, а не качество базлайна.
Ансамбль со специализированными моделями
Механизм: Глобальная модель оценивает общий риск, а специализированные — отдельные классы атак: захват аккаунта, тестирование карт, фрод мерчантов. Поверх оценок работает политика решения и правила.
Компромисс: Сегментные модели точнее в своих нишах, но умножают стоимость владения: каждой нужна своя калибровка, мониторинг, контур переобучения и план отката.
Когда выбирать: Когда классы атак имеют разную экономику ошибок и разные признаки, а единая модель систематически проседает на нишевых, но дорогих сегментах.
Калибровка вероятностей под бизнес-пороги
- Сырые оценки GBDT и нейросетей — не вероятности. После обучения добавляйте калибровку (Platt scaling или изотоническую регрессию), иначе бизнес-порог «блокировать при p выше 0.9» не означает ничего стабильного между релизами.
- Порог — это экономика, а не магическое число: блокировать стоит, когда p, умноженное на ожидаемую потерю от фрода, превышает цену ложного срабатывания, взвешенную на (1 − p). Для разных сумм, продуктов и сегментов рабочая точка разная.
- При доле фрода ниже одного процента площадь под ROC-кривой (ROC-AUC) выглядит оптимистично почти у любой модели. Смотрите на площадь под кривой точность-полнота (AUPRC) и полноту при фиксированной точности в рабочей точке порога — это метрики, которые чувствуют дисбаланс классов.
- Перекалибровка нужна чаще переобучения: распределение оценок дрейфует вместе с трафиком, и тот же порог через месяц означает другую долю блокировок и другую нагрузку на ручное ревью.
Именно связывает модель с политикой решения: пока оценка не интерпретируется как вероятность, нельзя выводить из экономики ошибок — его остаётся только подбирать вслепую.
Графовые признаки и фрод-кольца
Организованный фрод — это не аномальные транзакции, а аномальные связи: десятки аккаунтов на одном устройстве, одна карта на сотне профилей, общие адреса доставки. Граф устройство — карта — аккаунт превращает эти связи в признаки трёх уровней зрелости — от дешёвых счётчиков до и графовых эмбеддингов.
Счётчики веера связей (один шаг по графу)
Механизм: Степень узла в графе устройство — карта — аккаунт: сколько карт видело это устройство за 30 дней, сколько аккаунтов делят e-mail или адрес доставки, сколько устройств у одной карты.
Компромисс: Дёшево в сервинге: предрассчитанные счётчики читаются из онлайн-хранилища по ключу за миллисекунды, но видят только ближайших соседей и не замечают структуру кольца целиком.
Когда применять: База любой фрод-модели: аномальный веер связей — один из самых устойчивых сигналов «фабрики» аккаунтов и перебора краденых карт.
Сообщества и фрод-кольца
Механизм: Офлайн-поиск плотных кластеров (connected components, Louvain): фрод-кольца выглядят как изолированные сообщества умеренного размера, отделённые от гигантской компоненты легитимных пользователей. Метка подтверждённого фрода распространяется на соседей по сообществу.
Компромисс: Пересчёт пакетный, раз в часы или сутки: новое кольцо станет видно только после следующего прогона. Зато в онлайне остаётся дешёвый поиск идентификатора сообщества и его риск-статуса по ключу.
Когда применять: Против организованных колец, мулов-посредников и общих идентификаторов: каждый аккаунт по отдельности выглядит безобидно, аномалия видна только в структуре связей.
Графовые эмбеддинги и GNN
Механизм: Эмбеддинги узлов (FastRP, node2vec) или графовые нейросети кодируют структурную роль узла в вектор, который подаётся в основную модель вместе с табличными признаками.
Компромисс: Самый выразительный уровень и самый дорогой: пересчёт эмбеддингов, их версионирование и объяснимость для аналитиков заметно сложнее, чем у счётчиков и сообществ.
Когда применять: Когда счётчики и сообщества выжаты, а кольца научились дробить связи так, чтобы не пересекать простые пороги веера связей.
Цена в реальном времени: полный обход графа в синхронном пути не укладывается в бюджет 120 мс при 75k . Рабочее правило — в онлайне только чтение по ключу предрассчитанных значений из ; вся глубина обхода уходит в пакетный и потоковый пересчёт. Компромисс этого правила — : чем глубже признак смотрит в граф, тем дольше он отстаёт от реальности.
Связанная глава
Redis: база данных в памяти и архитектура
Структуры данных и компромиссы горячего хранилища, в котором живут velocity-счётчики.
Velocity-признаки: окна, хранение, консистентность
Velocity-счётчики — «сколько событий за окно» — самые сильные признаки реального времени и одновременно самые требовательные к инфраструктуре: их нужно инкрементировать на каждом событии, читать на каждом скоринге и точно воспроизводить в обучении. Окна считаются разной длины — и каждая длина ловит свой класс атак.
Окно
5 минут
Число попыток оплаты с одной карты, доля неуспешных авторизаций, новые карты на устройстве.
Ловит: Тестирование краденых карт мелкими суммами и взрывные бот-атаки.
Окно
1 час
Сумма трат по карте и аккаунту, число уникальных получателей и мерчантов.
Ловит: Быстрый вынос средств сразу после захвата аккаунта.
Окно
24 часа
Число карт на устройство, гео-скачки, отношение трат к среднему за неделю.
Ловит: Фермы устройств и распределённые атаки, размазанные по времени.
Окно
7–30 дней
Отклонение от профиля трат, доля новых получателей, частота смены устройств.
Ловит: Медленный фрод, дропы-посредники и постепенный вынос средств небольшими порциями.
Точные скользящие окна
Sorted set в Redis на каждый счётчик даёт точное окно, но платит памятью за каждое событие и логарифмической сложностью на операцию — при 75 тыс. запросов в секунду (QPS) на скоринге это десятки миллионов операций в минуту только на velocity-признаки.
Суб-бакеты вместо точных окон
Суточное окно собирается из 24 часовых бакетов со временем жизни (TTL): погрешность на границе бакета в обмен на предсказуемую память и дешёвый инкремент. Для большинства velocity-признаков такой точности достаточно — порог всё равно выбирается с запасом.
Кто инкрементирует счётчик
Потоковый процессор (Kafka → Flink) дешевле и не трогает критичный путь, но счётчик отстаёт на лаг пайплайна — ровно в момент бёрст-атаки, когда он нужнее всего. Синхронный инкремент на пути скоринга закрывает эту дыру ценой дополнительной записи в горячее хранилище на каждое событие.
Консистентность train/serve
Офлайн-пересчёт окон по сырым логам почти никогда не совпадает с тем, что видел онлайн-счётчик: поздние события, ретраи, лаг материализации. Надёжный паттерн — логировать вектор признаков, использованный при скоринге, и обучаться на этом логе, а не пересобирать признаки задним числом.
Главный невидимый риск здесь — : признак с одинаковым именем в офлайне и онлайне может означать разные вещи. Логирование вектора признаков в момент скоринга решает это надёжнее, чем любые попытки добиться пересчётом сырых событий задним числом.
Adversarial-динамика: противник адаптируется
В рекомендациях дрейф — это смена вкусов аудитории, в антифроде — , который активно создаёт противник. Поэтому рабочий контур проектируется в логике : любой выпуск модели — ход в игре, на который последует ответ.
Дрейф как стратегия противника
Каждый заблокированный паттерн обучает атакующего: мошенники прощупывают пороги мелкими суммами и меняют тактику после первой блокировки. Дрейф концепций здесь быстрее, чем в обычных ML-системах, поэтому распределение оценок и доля блокировок по сегментам мониторятся ежедневно, а не в ретроспективе квартала.
Champion / challenger
Чемпион обслуживает основной трафик, претенденты считают оценки в теневом режиме на той же выборке. Решение о продвижении принимается по созревшим меткам, а не по первым дням: иначе побеждает модель, которая лучше выглядит на неполной правде.
Правила как быстрый ответ и резерв
Аналитик выкатывает блокирующее правило за часы, переобучение и выпуск модели занимают дни — правила закрывают новую атаку, пока модель догоняет. Тот же консервативный набор правил служит резервным сценарием при деградации модели или недоступности онлайн-признаков.
Очередь ревью как источник разметки
Пропускная способность аналитиков — жёсткий лимит всей системы. Очередь приоритизируется по неопределённости оценки и ожидаемой стоимости ошибки, а не по FIFO. В разметку подмешивают случайные пропущенные транзакции, иначе обучающая выборка смещается к тому, что текущая модель уже умеет ловить.
Претендентов выгодно держать в постоянно, а не только перед релизом: это даёт раннюю диагностику дрейфа и готовый кандидат на замену, когда чемпион деградирует. А правила остаются последним , который обязан работать, даже когда не работает всё остальное ML.
Ключевые компромиссы
- Низкий порог уменьшает потери от мошенничества, но увеличивает ложноположительные срабатывания и лишнее трение для легитимных пользователей.
- Больше признаков в реальном времени повышает качество, но усложняет требования к свежести данных, отладку и резервный путь.
- Одна глобальная модель проще в эксплуатации, но сегментированные модели часто точнее для разных рынков и продуктов.
- Жёсткая блокировка на высоком значении оценки снижает риск потерь, но повышает цену ошибочного решения и давление на поддержку.
- Глубокие графовые признаки сильнее ловят кольца, но полный обход графа не укладывается в бюджет задержки — глубину приходится выносить в офлайн-пересчёт ценой свежести.
- Синхронный инкремент velocity-счётчиков закрывает бёрст-атаки, но добавляет запись в горячее хранилище на каждый скоринг; асинхронный путь дешевле, но отстаёт ровно тогда, когда нужен сильнее всего.
Частые ошибки
Рекомендации
Что стоит проговорить на интервью
- Как вы выберете порог и кто должен решать цену ложноположительного и ложноотрицательного срабатывания?
- Как вы устроите путь скоринга, если метки приходят через недели после транзакции?
- Что произойдёт при недоступности онлайновых признаков или внешнего провайдера риска?
- Как вы покажете аналитику и команде поддержки, почему система приняла то или иное решение?
- Почему GBDT остаётся сильным базлайном для табличных фрод-признаков и в какой момент оправдан переход к нейросетям или ансамблю специализированных моделей?
- Как вы посчитаете velocity-признаки так, чтобы значения в обучении совпадали со значениями на пути скоринга?
- Как честно оценивать модель, если заблокированные транзакции никогда не получают метку?
Источники
- How we built it: Stripe Radar — Эволюция модели Radar: от логистической регрессии и XGBoost через ансамбль Wide & Deep к чистой DNN со скорингом за ~100 мс.
- Stripe Radar: a primer on machine learning for fraud detection — Признаки, метрики качества и продуктовая логика порогов в промышленной антифрод-системе.
- Chapelle. Modeling Delayed Feedback in Display Advertising (KDD 2014) — Классическая работа о коррекции смещения при отложенных метках: отдельная модель задержки и importance weighting.
- Grinsztajn et al. Why do tree-based models still outperform deep learning on typical tabular data? (NeurIPS 2022) — Бенчмарк на 45 табличных датасетах: почему ансамбли деревьев остаются сильнейшим подходом на табличных данных среднего размера.
- Neo4j: graph-based approach to financial fraud detection — Граф транзакций, карт, устройств и адресов: признаки веера связей, выделение сообществ и распространение меток подтверждённого фрода.
- Visa chargeback time limits (Chargebacks911) — Окна оспаривания по правилам Visa: стандартные 120 дней и расширенные сроки для отложенной доставки.
- Redis: real-time fraud detection tutorial — Структуры данных для velocity-счётчиков: sorted sets, бакеты со временем жизни (TTL) и профили риска в горячем хранилище.
Связанные главы
- Точность (precision) и полнота (recall) на пальцах - Базовый язык для разговора о порогах, ложноположительных и ложноотрицательных срабатываниях.
- ML Ops Pipeline - Как собрать полный рабочий контур: выпуск, наблюдение, обратную связь и следующий цикл обучения.
- Feature Store & Model Serving - Как устроить онлайновый путь признаков, согласованность данных и резервные сценарии для скоринга.
- Человек в контуре (human-in-the-loop), качество данных и операционный контур AI - Как ручная проверка и запаздывающие метки становятся частью рабочего контура системы.
- ML-платформа в Т-Банке - Платформенный взгляд на эксплуатацию ML-систем и стандартизацию путей разработки и выпуска.