От бинарной классификации к риск-скорингу: как строить ML-пайплайны для финмониторинга
В условиях экспоненциального роста объема транзакций традиционные rule-based системы финмониторинга теряют эффективность, выдавая до 90% ложных срабатываний. Решение в разработке сквозного инженерного контура, который не просто классифицирует операции как «подозрительные» или «безопасные», а ранжирует их по вероятности риска, позволяя аналитикам фокусироваться на критических случаях.
# Когда одной классификации недостаточно
Объем операций по картам в мире за последние 15 лет вырос в 23 раза, в то время как число банковских организаций сократилось на две трети. Это означает, что нагрузка на одного финансового учреждения возросла примерно в 70 раз. В такой среде традиционные системы комплаенс-мониторинга, основанные на жестких правилах (rule-based), демонстрируют критическую неэффективность: более 90% их сигналов оказываются ложноположительными. Разбор этого потока пустых данных съедает основную часть рабочего времени аналитиков.
Проблема усугубляется санкционными ограничениями, которые делают невозможным использование некоторых зарубежных коммерческих платформ без риска потери поддержки. Возникает потребность в локально разворачиваемых, воспроизводимых решениях, способных адаптироваться к новым схемам мошенничества без длительных циклов разработки.
Почему риск-скоринг лучше бинарной классификации
Ключевым выводом из анализа является необходимость перехода от бинарного ответа («да/нет») к риск-ориентированному ранжированию. В датасетах с сильной дисбалансом классов доля подозрительных операций может составлять менее 0,12%. В таких условиях порог классификации 0,5 бессмысленен. Гораздо показательнее метрики ранжирования, такие как Precision@k и Lift@k.
Эксперименты на датасете SAML-D показали, что модель, формирующая риск-скор, позволяет выстроить приоритетную очередь для аналитиков. Если для первых 100 операций в очереди концентрация реальных рисков может достигать 70–77%, то при расширении списка до 500 операций эта эффективность закономерно снижается. Следовательно, ценность модели заключается не в окончательном решении, а в правильном упорядочивании событий по степени потенциального вреда.
Архитектура воспроизводимого ML/MLOps-контура
Для реализации такого подхода недостаточно просто обучить модель. Требуется создание сквозного контура, охватывающего все этапы: от подготовки данных и обучения до развёртывания, мониторинга и повторного обучения. В качестве основы выбран модульный и контейнеризированный стек, что обеспечивает возможность замены отдельных компонентов и масштабирования без переработки всей системы.
Оркестрация и трекинг Центральное место в архитектуре занимают Apache Airflow и MLflow. Airflow управляет пайплайнами (DAG), автоматизируя процессы обучения, бенчмарки и проверку на дрейф данных. MLflow отвечает за трекинг экспериментов: он фиксирует параметры, метрики и артефакты, обеспечивая полную прозрачность и воспроизводимость каждого запуска. В случае сбоев в регистрации моделей система продолжает работу, сохраняя результаты, что предотвращает остановку всего процесса.
Хранение данных и интерфейсы Архитектура разделяет типы данных: сырые и обработанные данные, а также артефакты хранятся в объектном хранилище MinIO. Метаданные и схема датасетов размещаются в PostgreSQL, а логи и артефакты — локально. Пользовательский слой взаимодействует с системой через REST API (реализованный на FastAPI), поддерживающий как поштучный скоринг в реальном времени, так и пакетную обработку. Для визуализации результатов и запуска сценариев используется дашборд на Streamlit.
Методология и результаты экспериментов
Процесс реализации разбит на три независимых DAG'а в Airflow: аml_training_dag для обучения, aml_benchmark_dag для сравнения версий и aml_drift_dag для мониторинга изменений в данных. Последний запускается автоматически, в то время как обучение и бенчмарки могут быть инициированы вручную.
В ходе исследований было подтверждено, что расширение признакового пространства в данном случае не оправдывает дополнительных вычислительных затрат: время обучения увеличилось почти в два раза, а метрики качества (ROC-AUC, PR-AUC) остались на прежнем уровне. Это подчеркивает важность осознанного выбора методов фич-инжиниринга.
Мониторинг дрейфа данных также доказал свою практическую ценность. Система обнаружила изменения в распределении признаков «возраст клиента» и производного признака, связанного с активностью email. Хотя автоматическое переобучение не является прямой задачей мониторинга, обнаруженные сдвиги служат сигналом для анализа причин и принятия решения о необходимости корректировки модели.
Таким образом, современный ML/MLOps-подход в финансовом секторе смещает фокус с поиска идеальной бинарной метки на построение надежного, объяснимого и поддерживаемого процесса оценки рисков.