Архитектура оценки антифрода: как Авито внедрил единую метрику MES для сотен ML-моделей

Архитектура оценки антифрода: как Авито внедрил единую метрику MES для сотен ML-моделей

В масштабном классифайде защита от мошенничества давно перестала быть монолитным сервисом с единственным классификатором. В реальном промышленном контуре Авито антифрод представляет собой распределенную экосистему из десятков микросервисов и сотен моделей машинного обучения (Machine Learning, ML). Одни алгоритмы вычисляют числовой скор подозрительности пользователя, другие выставляют флаги нарушений, третьи инициируют запросы на ограничения или биометрические проверки, а последующие сервисы оценивают результаты верификации и принимают решения о блокировке профилей.

Когда в системе параллельно работают сотни алгоритмов разных команд, возникает ключевой архитектурный вопрос: как объективно определить, какие модели приносят реальную пользу безопасности платформы, а какие лишь дублируют соседние решения, создают нагрузку на инфраструктуру и раздражают добросовестных пользователей лишними проверками?

Почему классический ROC-AUC не работает в реальном проде

В теории машинного обучения стандартным критерием качества бинарных моделей выступает ROC-AUC — статистическая метрика, оценивающая способность алгоритма разделять классы при варьировании порога. Однако при переносе алгоритмов в реальную эксплуатацию этот показатель теряет прикладную ценность.

Главное ограничение ROC-AUC — потребность в эталонной истинной разметке (ground truth), то есть точном знании того, являлся ли конкретный субъект нарушителем. В боевом потоке транзакций готовой разметки нет, а ручной аудит силами аналитиков и модераторов стоит дорого и формируется с большой задержкой.

В результате модель с высоким качеством на исторических выборках в боевой среде может оказаться бесполезной:

• алгоритм генерирует предупреждения, которые отсекаются бизнес-правилами и не доходят до санкций;
• проверка накладывается на добросовестных клиентов, которые успешно подтверждают личность, увеличивая долю ложных срабатываний;
• срабатывание полностью дублирует более легкую эвристику соседней команды.

Для регулярного мониторинга требовался переход от теоретических метрик к оценке сквозных продуктовых последствий каждого срабатывания.

Разорванные логи и скрытые дубли: проблемы прежней архитектуры

Исторически данные антифрода накапливались изолированно. Предсказания моделей сохранялись в одних таблицах, запросы на санкции отправлялись в другие базы, а механизмы «обеления» (whitelisting — защитная отмена санкции, если активность признана легитимной) фиксировались в третьих.

В ряде сервисов логирование велось с агрегацией по пользователю: если алгоритм срабатывал на аккаунте десять раз за сутки, в базу попадала одна запись, что делало невозможным расчет точной воронки конверсий.

Аналитики вручную сопоставляли события по временным меткам, тратя недели на аудит одного сервиса. При этом две разные модели, сработавшие на одном подозрительном профиле, выглядели одинаково успешными, даже если одна полностью повторяла другую. Отсутствие единого ключа разрывало причинно-следственную цепочку между прогнозом модели и финальным результатом для безопасности платформы.

Архитектурный фундамент: сквозной punisher_request_id и 7 витрин DWH

Команда бизнес-аналитики (BI) начала трансформацию с фундаментальной реорганизации слоя данных.

Первым шагом стало внедрение идентификатора punisher_request_id — уникального сквозного UUID, который создается в момент формирования запроса на санкцию и передается через всю цепочку: от исходного скоринга до обеления, интерфейса проверки и финального статуса аккаунта.

Параллельно была переработана схема логирования скоринговых сервисов с фиксацией полной структуры контекста: ID пользователя, версия модели, скор или флаг, признак тестового режима (shadow mode), тип санкции, сквозной punisher_request_id и точная временная метка.

Для консолидации данных в корпоративном хранилище (DWH — Data Warehouse) на базе распределенного SQL-движка Trino были развернуты 7 специализированных витрин данных:

1. af_user_model_predictions: нормализованные прогнозы и скоры моделей обновленного сервиса;
2. af_user_model_actions: санкционные решения от алгоритмов сервиса;
3. antifraud_scores: сводные оценки скоринговых компонентов по пользователям, объявлениям и чатам;
4. antifraud_model_actions: реестр санкций от моделей смежных сервисов;
5. punisher_requests: первичные запросы на наложение ограничений в подсистеме санкций и обелений;
6. punisher_requests_params: детализированные параметры запрошенных мер;
7. punisher_requests_settings: конфигурации и правила применения санкционных сценариев.

Дополнительно в поток кликстрима (ClickStream) внедрили событие, фиксирующее каждую попытку отправки на санкцию независимо от ее исхода. Это исключило ошибку выжившего, когда в аналитику попадали только завершенные операции.

Формула MES: 6 компонентов комплексной оценки эффективности

На базе витрин данных команда разработала композитную метрику эффективности — Model Effectiveness Score (MES). Она рассчитывается как взвешенное среднее из шести компонентов:

MES = (C_sanction * 1 + C_nonpass * 2 + C_block * 1 + C_fpr * 1 + C_uniq * 0.5 + C_collab * 0.5) / 6

Знаменатель равен 6 — сумме весов всех показателей. Компоненты оценивают разные аспекты работы модели:

1. Конверсия в санкцию (вес 1): число наложенных санкций / общее число срабатываний. Показывает, насколько часто прогнозы доходят до реальных мер, а не отсеиваются как фоновый шум.
2. Непрохождение санкции (вес 2): 1 - (число прошедших проверку / число наложенных санкций). Ключевой барьерный индикатор с максимальным весом. Отражает долю пользователей, не сумевших подтвердить легитимность профиля.
3. Конверсия в блокировку за 7 дней (вес 1): 1 - 2 * (число заблокированных / число прошедших проверку). Штрафует модель, если прошедший проверку аккаунт в течение недели блокируется за нарушения. Множитель 2 компенсирует малый масштаб конверсии.
4. Защита от избыточных наказаний (вес 1): 1 - False Positive Rate (FPR). Метрика учета ложноположительных срабатываний для защиты добросовестных пользователей.
5. Уникальность срабатываний (вес 0,5): число уникальных срабатываний / все срабатывания. Доля случаев, когда нарушение зафиксировала только данная модель без дублирования другими алгоритмами.
6. Совместная работа (вес 0,5): 1 - (совместные срабатывания / все срабатывания) / n. Оценивает степень пересечения с ансамблем моделей, нормированную на число соседей n.

Такой баланс предотвращает накрутку: модель не может получить высокий балл только за счет валового объема срабатываний или агрессивной блокировки всех пользователей подряд.

Дашборды в Redash и практические результаты внедрения

Слой мониторинга реализован в BI-системе Redash как комплекс из 10 дашбордов. Он включает сводную панель с фильтрами по сервисам и подразделениям, сквозную воронку санкций, доску уникальности в окне ±24 часа и панели покрытия Proxy Fraud 2.0. По внутреннему индексу Health Score отчет достиг зеленой зоны (выше 80 баллов) с оценкой пользователей 5,0 из 5,0.

Внедрение архитектуры принесло прямой эффект:

• Выявлено 8 неэффективных моделей: 4 алгоритма отключены или отправлены на переработку, 1 взята на оптимизацию порогов, по остальным сформирован план доработок;
• Время исследования полезности моделей сократилось с недель ручного сбора данных до минут в интерфейсе;
• 7 витрин DWH стали стандартом для обучения новых ML-алгоритмов безопасности.

Формула MES не универсальна для всей индустрии: веса и временные окна откалиброваны под бизнес-процессы Авито и при переносе требуют адаптации под локальную цену ошибок.

Чек-лист для команд: как построить сквозную оценку

1. Описать путь события от генерации скора до бизнес-результата (проверки, санкции, обеления, блокировки).
2. Внедрить сквозной UUID до передачи запроса между сервисами и прокинуть его во все связанные логи.
3. Зафиксировать формат логирования с обязательными атрибутами (ID сущности, версия модели, скор, тестовый режим, тип действия, параметры и таймстемп).
4. Гарантировать сохранение всех повторных срабатываний и логирование попыток вызова санкций независимо от исхода операции.
5. Развернуть оптимизированные витрины данных в DWH до начала разработки метрик и визуализации.
6. Учитывать компоненты уникальности и защиты от ложных срабатываний, не подменяя ценность модели частотой ее вызова.
7. Отображать в интерфейсах как итоговый балл, так и все исходные слагаемые формулы с параметрами фильтрации.
8. Утвердить регламент действий при низких оценках — от калибровки порогов до вывода неэффективных моделей из эксплуатации.