На датасете SAML-D доля подозрительных операций составляет 0,119%. Один подозрительный случай примерно на 840 обычных. Модель, которая бинарно отделяет мошенничество от честных операций, при таком соотношении либо тонет в ложных срабатываниях, либо пропускает редкие события. Старший инженер по данным Максим Коцюба собрал в выпускной работе сквозной ML/MLOps-пайплайн, где вместо метки «подозрительно/чисто» модель выдаёт риск-скор, а операции выстраиваются в очередь по приоритету для аналитика. Ниже разбор: из чего собран контур, какие метрики показали себя лучше классификационных и что осталось за рамками прототипа.
Почему бинарная классификация не справляется с поиском подозрительных операций
С 2010 по 2025 год объём операций по картам увеличился в 23 раза, с 3,1 до 72,7 млрд. Число действующих кредитных организаций сократилось почти на 67%, с 1058 до 353. Нагрузка на одну организацию выросла примерно в 70 раз: с 2,9 до 206 млн операций на субъект. Транзакций становится больше, а проверяющих рук меньше. Разбор кейса начинается именно с этих цифр.
Более 90% срабатываний действующих rule-based систем комплаенс-мониторинга оказываются ложными. Разбор потока пустых сигналов съедает большую часть рабочего времени аналитиков.
Дисбаланс классов: 0,119% подозрительных операций в SAML-D
Модель, которая всегда предсказывает «всё чисто», получит accuracy около 99,9%. Метрика выглядит отлично и не значит ничего: такая модель не найдёт ни одной подозрительной операции.
Бинарная классификация при таком дисбалансе упирается в две стены. Порог можно сдвинуть так, чтобы ловить больше редких событий, и тогда вырастет число ложных срабатываний, которые аналитик разгребает вручную. Либо порог остаётся строгим, и тогда редкие подозрительные операции проходят мимо. Accuracy, F1 и ROC-AUC при этом могут выглядеть прилично и не отражать практическую пользу.
Полезнее смотреть на метрики ранжирования. На датасете SAML-D Precision@k и Lift@k оказались показательнее классификационных.
Почему правила всё ещё нужны, но их недостаточно
Правила в финансовом мониторинге по-прежнему нужны. Их сильные стороны: прозрачность и возможность контролировать отдельные сценарии. Правило можно прочитать, объяснить регулятору и точечно поправить. Слабое место того же подхода: адаптация к новым схемам занимает время, а срабатывания дают более 90% ложных сигналов.
ML-ранжирование не отменяет правила. Правила формируют сигналы и фиксируют обязательные сценарии, модель оценивает операции риск-скором и выстраивает приоритетную очередь, а аналитик берёт верхушку очереди. Правила отвечают за контроль и объяснимость, модель - за сортировку там, где сигналов слишком много, чтобы разбирать их вручную.
Одной модели для такой системы мало. Нужны пайплайны подготовки данных, трекинг экспериментов, мониторинг качества во времени и механизм обновления. На этом строится проект.
Что такое риск-ориентированное ранжирование и как оно меняет работу аналитика
Ранжирование меняет постановку задачи. Модель не отвечает на вопрос «мошенничество или нет», она выдаёт риск-скор для каждой операции. По скору операции сортируются, и наверху оказываются самые подозрительные.
Что это даёт аналитику на практике. Вместо разбора всех срабатываний правил по порядку он открывает очередь сверху вниз. В верхней части концентрация подозрительных операций выше, чем в среднем по потоку, поэтому первые часы работы приносят больше найденных кейсов.
Precision@k и Lift@k: метрики, которые отражают реальную пользу
Precision@k - доля истинно подозрительных операций среди первых k в очереди по риск-скору. Lift@k показывает, во сколько раз эта доля выше базовой. Базовая доля для SAML-D равна 0,119%.
Пример: если Lift@1000 равен 50, то среди первых 1000 операций концентрация подозрительных в 50 раз выше, чем в случайной выборке из потока. Аналитик тратит время на 1000 операций и получает в 50 раз больше смысла, чем при случайном разборе.
Эти метрики ближе к бизнес-задаче, чем accuracy или F1. Аналитик физически не может разобрать весь поток, ему нужен приоритет. На датасете SAML-D с долей подозрительных 0,119% Precision@k и Lift@k оказались показательнее классификационных метрик.
Роль SHAP в интерпретируемости риск-скора
SHAP используется для интерпретируемости. Аналитик видит, какие признаки подняли или опустили риск-скор конкретной операции. Это помогает понять логику модели и объяснить решение, когда его придётся защищать.
Ограничение здесь честное: интерпретируемость не заменяет кейс-менеджмент. Она объясняет, почему операция оказалась наверху очереди, но не ведёт сам разбор. В стеке SHAP закрывает слой объяснений, а не рабочий процесс.
Архитектура сквозного ML/MLOps-пайплайна: из каких компонентов собран контур
Стек собран из открытых и локально разворачиваемых компонентов: Airflow для оркестрации, MLflow для трекинга экспериментов, FastAPI для инференса, Streamlit для дашборда, PostgreSQL и MinIO для хранения, SHAP для интерпретируемости.
Поток данных выглядит так: пайплайны подготовки данных и обучения запускаются по расписанию, эксперименты и версии моделей фиксируются в MLflow, модель отдаёт риск-скор через FastAPI, результаты скоринга попадают в базу, аналитик видит очередь в Streamlit, артефакты лежат в объектном хранилище.
Airflow и MLflow: оркестрация и трекинг экспериментов
Airflow отвечает за оркестрацию. Он запускает подготовку данных, обучение и обновление модели по расписанию, связывает шаги в единый граф и повторяет упавшие задачи.
MLflow трекает эксперименты: версии моделей, параметры, метрики. Без этого невозможно сравнивать подходы между собой и откатываться к предыдущей версии, когда новая модель работает хуже. Подробный разбор инструмента есть в руководстве по MLflow: логирование метрик, версионирование в Model Registry и автоматизация оценки.
FastAPI и Streamlit: инференс и дашборд для аналитика
FastAPI обслуживает инференс. Модель получает признаки операции и возвращает риск-скор. Streamlit показывает дашборд, где операции отсортированы по скору.
Дашборд - точка входа для аналитика, но у прототипа есть граница. В нём нет кейс-менеджмента: нельзя назначить ответственного, оставить комментарий, сменить статус или закрыть кейс. Очередь видно, вести по ней работу - нет.
PostgreSQL и MinIO: хранение данных и артефактов
PostgreSQL хранит структурированные данные: признаки операций, результаты скоринга, метаданные. MinIO держит объекты: модели, датасеты, логи. Разделение на реляционное и объектное хранилище - обычная практика в MLOps, потому что модели и датасеты плохо ложатся в таблицы.
Результаты на SAML-D: что показали эксперименты
Проверка шла на датасете SAML-D с долей подозрительных операций 0,119%. Метрики ранжирования Precision@k и Lift@k оказались показательнее классификационных, а расширение признакового пространства не дало прироста качества.
Почему расширение признаков не дало прироста
Расширение признакового пространства привело к почти двукратному росту времени обучения без улучшения качества. Дополнительные признаки не добавили полезной информации для ранжирования, но увеличили вычислительную нагрузку. Вывод простой: признаки проверяют на вклад через трекинг экспериментов, а не добавляют пачкой в надежде на улучшение.
Мониторинг дрейфа и механизм обновления модели
Мошеннические схемы меняются, а вместе с ними распределение данных. То, на чём модель училась год назад, сегодня может выглядеть иначе. Поэтому в контур заложены мониторинг дрейфа и механизм обновления: Airflow перезапускает пайплайн на свежих данных, MLflow фиксирует новую версию.
В прототипе нет автоматического решения о переобучении. Пайплайн умеет переобучать, но триггер остаётся ручным, и это зона для развития.
Ограничения прототипа: что осталось за рамками
Проект остаётся прототипом. Кейс-менеджмент, разграничение прав доступа и аудиторский след в него не входят.
Кейс-менеджмент: почему без него пайплайн неполный
Кейс-менеджмент - это работа с подозрительной операцией: назначить аналитика, оставить комментарий, выставить статус, эскалировать при необходимости. В прототипе его нет: дашборд показывает очередь, но не позволяет вести кейс. Для реальной работы это обязательный элемент, иначе непонятно, кто и на каком этапе разбирает операцию.
Разграничение прав доступа и аудиторский след
Разграничение прав доступа нужно, чтобы аналитик видел только свои кейсы, а доступ к данным был ограничен ролью. Аудиторский след фиксирует, кто, когда и почему принял решение. Без этого не пройти проверку регулятора: невозможно доказать, почему операция была признана подозрительной или нет.
Прототип показывает, что контур на открытых компонентах собрать реально, но к продакшену без этих трёх блоков его не выкатить.
Почему выбран стек из открытых и локально разворачиваемых компонентов
На этапе постановки задачи рассматривались три варианта: rule-based механизмы, готовые коммерческие AML-платформы (SAS AML, NICE Actimize) и разработка силами банка.
Сравнение с SAS AML и NICE Actimize
Готовые платформы дают зрелость и поддержку. Их минус в закрытости: сложно исследовать и менять внутреннюю логику, а значит трудно подстроить систему под свои сценарии. Разработка силами банка даёт контроль, но упирается в ресурсы: ручной и неавтоматизированный процесс обучения моделей быстро становится узким местом.
Открытый стек даёт контроль над каждым компонентом. Плата за это - сборка и поддержка на своей стороне. Выбор зависит от задач и ограничений организации: готовое решение быстрее стартует, открытый контур гибче.
Санкционные ограничения как драйвер локальных решений
Санкционные ограничения усиливают потребность в локально разворачиваемых решениях. Компоненты вроде Airflow, MLflow, FastAPI, PostgreSQL и MinIO можно поднять на своих серверах без зависимости от внешних поставщиков. Это снижает риск блокировок и упрощает соответствие требованиям безопасности.
Как воспроизвести подобный пайплайн: практические шаги
Собрать похожий контур можно поэтапно. Минимальный набор закрывает базовую ценность, остальное добавляется по мере необходимости.
- Определить задачу и метрики. При высоком дисбалансе классов ориентир - Precision@k и Lift@k, а не accuracy.
- Подготовить данные: SAML-D или аналогичный датасет с признаками операций.
- Обучить модель ранжирования, которая выдаёт риск-скор.
- Развернуть инференс через FastAPI.
- Собрать дашборд на Streamlit с очередью по скору.
- Настроить хранение: PostgreSQL для данных, MinIO для артефактов.
- Добавить SHAP для интерпретируемости.
- Подключить Airflow для оркестрации и MLflow для трекинга.
- Настроить мониторинг дрейфа и механизм обновления модели.
С чего начать: минимальный жизнеспособный пайплайн
Минимальный набор: подготовка данных, модель ранжирования, инференс через FastAPI, простой дашборд. Airflow и MLflow можно добавить следующим шагом, когда появится что сравнивать и перезапускать. Главное - стартовать с метрик, которые отражают практическую пользу.
Типичные ошибки при сборке MLOps-контура
- Смотреть на accuracy при сильном дисбалансе. При доле 0,119% красивая цифра ничего не говорит о пользе.
- Добавлять признаки без проверки вклада. Расширение признакового пространства в этом кейсе не дало прироста при почти двукратном росте времени обучения.
- Игнорировать мониторинг дрейфа. Схемы меняются, и модель без обновления теряет качество.
- Считать модель центром системы. Без пайплайнов подготовки данных, трекинга и механизма обновления она устареет.
Для команд, которые только выстраивают ML-процессы, полезны пять выводов за 8,5 лет в ML про терпение, команду и выбор проекта: модель не спасает без процесса вокруг неё. А когда дело дойдёт до оценки качества в production, пригодится разбор методологии оценки на опыте Databricks.
Для продакшена к контуру нужно добавить кейс-менеджмент, разграничение прав доступа и аудиторский след. Без них технически работающий пайплайн остаётся демонстрацией, а не рабочим инструментом финмониторинга.