Как я построил ML-пайплайн для поиска подозрительных транзакций и почему одной классификации оказалось мало

С ростом числа финансовых операций аналитикам всё сложнее вручную разбирать срабатывания систем финмониторинга — а большинство из них ложные.

Привет! Меня зовут Максим Коцюба, я старший инженер по данным с опытом в финсекторе — ВТБ и Сбер, выпускник онлайн-магистратуры «Инженерия данных» НИУ ВШЭ и Нетологии. В выпускной работе я взялся за эту задачу и собрал сквозной ML/MLOps-пайплайн, который не просто классифицирует операции, а ранжирует их по степени риска. Расскажу, что получилось и почему одной классификации оказалось мало.

Максим Коцюба

Довёл диплом до рабочего кода · @MaxKots

Почему нужен именно сквозной пайплайн, а не просто модель

Когда я изучал предметную область, стало понятно, что масштаб проблемы за последние 15 лет вырос. С 2010 по 2025 год объём операций по картам увеличился в 23 раза — с 3,1 до 72,7 млрд, при этом число действующих кредитных организаций сократилось почти на 67% — с 1058 до 353. В пересчёте на одну организацию нагрузка выросла примерно в 70 раз — с 2,9 до 206 млн операций на субъект.

При этом действующие rule-based системы, на которых обычно строится комплаенс-мониторинг, работают крайне неточно: более 90% их срабатываний оказываются ложными, и разбор этого потока пустых сигналов съедает бóльшую часть рабочего времени аналитиков.

Какие ещё варианты рассматривались на этапе постановки задачи, объясняет научный руководитель проекта, доцент ФКН НИУ ВШЭ Салех Хади Мухаммед:

В частности, оценивали существующие rule-based механизмы, готовые коммерческие AML-платформы, такие как SAS AML и NICE Actimize, а также вариант разработки решения силами самого банка.

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

Речь не о том, чтобы просто заменить rule-based систему ML-моделью. Правила в финансовом мониторинге по-прежнему необходимы, в том числе из-за их прозрачности и возможности контролировать отдельные сценарии. Основной вопрос был в другом: как организовать работу с ML-моделью после её появления — обучение, сравнение версий, развёртывание, мониторинг и повторное обучение.

Но одной модели тут недостаточно. Нужны пайплайны подготовки данных, трекинг экспериментов, мониторинг качества модели во времени и механизм её обновления. Кроме того, санкционные ограничения усиливают потребность в локально разворачиваемых решениях. Здесь я имею в виду не прямой запрет на использование конкретных зарубежных AML-продуктов, а ограничения на доступность и сопровождение зарубежного ПО и инфраструктуры. Например, прекращение или ограничение поставок, лицензирования, обновлений и технической поддержки, а также риски зависимости от внешних поставщиков.

Поэтому я решил смотреть не только на саму модель, а на весь процесс целиком: от подготовки данных и обучения до применения и мониторинга. Так появился сквозной ML/MLOps-пайплайн: на нём можно воспроизводимо обучать модели и использовать их для оценки риска финансовых операций.

Почему ранжирование, а не бинарная классификация

Изначально в постановке задачи рассматривались два варианта: бинарная классификация и риск-ориентированное ранжирование. Систему с самого начала проектировали для риск-скоринга и предварительной приоритизации операций, поэтому в требования к результату сразу заложили интерпретируемость и список значимых признаков. Но именно эксперименты показали, какой из подходов работает лучше. При сильном дисбалансе классов доля подозрительных операций в использованной выборке датасета SAML-D составила всего 0,119%. Метрики ранжирования вроде Precision@k и Lift@k оказались куда показательнее метрик классификации. А порог классификации 0,5 просто непригоден для эксплуатации: в реальности его должны определять допустимая нагрузка на аналитиков и требуемая полнота выявления.

Ключевой вывод: модель полезнее всего не как инструмент окончательного решения, а как механизм риск-ориентированного ранжирования. Она формирует риск-скор, на основе которого операции упорядочиваются по степени потенциального риска, что позволяет формировать приоритетную очередь для дальнейшего анализа. Вместо бинарного ответа на выходе получается риск-очередь для аналитика, позволяющая в первую очередь работать с операциями, имеющими наиболее высокий оценочный риск. Особенно заметно это на датасете SAML-D. Если для топ-100 обе модели показали Precision@100 = 1,00, то для топ-500 показатели закономерно снижаются: Precision@500 у LightGBM составил 0,322, у XGBoost — 0,310. Чем шире очередь, которую разбирает аналитик, тем ниже в среднем концентрация реального риска в ней, что логично и ожидаемо.

Ограничения открытых данных мы учли при проектировании и оценке, а практический фокус сместился от бинарной классификации к ранжированию по риску. Решение успешно прошло экспериментальную проверку, а исходный код и MVP проекта опубликованы на GitHub.

Как контур вписывается в процесс финансового мониторинга

Прежде чем рисовать схемы, я расписал для себя, кто вообще будет трогать эту систему. Аналитик смотрит на риск-скор и объяснение, почему модель посчитала операцию подозрительной. Дата-сайентист ставит эксперименты и обучает модели. MLOps-инженер разворачивает контур и следит за непрерывностью работы системы. А в это время в систему поступают данные из внутренних источников организации. Все они завязаны на самом контуре, который тянется через весь цикл: от загрузки данных до обновления и дообучения модели.

Контур расставляет приоритеты и следит, чтобы модели можно было воспроизводимо поддерживать, а не обучить один раз и забыть, — что в банковской среде критично, учитывая, как быстро меняется картина мошенничества.

Что внутри

Моей целью было не провести исчерпывающее сравнение промышленных архитектур или выбрать «лучший» технологический стек, а проверить гипотезу о том, что можно построить воспроизводимый сквозной ML/MLOps-контур для финансового мониторинга и экспериментально оценить его работу. Поэтому при выборе компонентов я ориентировался прежде всего на их достаточность для этой цели, открытость, возможность локального развёртывания и простоту воспроизведения экспериментов. Так получился достаточно простой и модульный стек.

Систему я спроектировал как контейнеризированный модульный контур, а не как единое монолитное приложение. У этого было две практические причины. Во-первых, необходимо было обеспечить воспроизводимость экспериментов: одинаковые входные данные, параметры и версия компонентов должны приводить к сопоставимому результату, а сам запуск — быть повторяемым. Во-вторых, компоненты должны оставаться связанными, но настолько, чтобы отдельные элементы контура можно было заменять или масштабировать без существенной переработки всей системы. Это особенно важно для исследовательского прототипа, который не должен быть жёстко привязан к инфраструктуре конкретного банка и должен допускать дальнейшую адаптацию к различным источникам данных, хранилищам и вычислительным средам.

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

Далее идёт оркестрация. Тут два инструмента, и они не дублируют друг друга. За автоматизацию процессов отвечает Apache Airflow. Он управляет пайплайнами (DAG), которые запускают обучение моделей, бенчмарки и проверки на дрейф данных (data drift). Запуск можно производить как вручную через веб-интерфейс, так и автоматизированно через API.

Параллельно MLflow используется для трекинга экспериментов: сохраняет параметры, метрики и артефакты запусков, позволяя сопоставить результаты с конкретной конфигурацией и версией модели.

Финальные предсказания отдаются через REST API на базе FastAPI. Сервис поддерживает два режима работы: поштучный скоринг (в реальном времени) и пакетную обработку данных (batch scoring).

Ядро — вычислительный слой: тут данные грузятся, валидируются, строятся признаки, модель учится и считает инференс, а SHAP объясняет, почему модель решила именно так. Здесь же живёт мониторинг дрейфа.

Хранилище я тоже не стал делать одним на всё. Локально лежат артефакты и логи. В PostgreSQL поместил метаданные и схему датасетов. А MinIO хранит «сырые» и обработанные данные, плюс артефакты, по сути, объектное хранилище для всего тяжёлого.

Компоненты взаимодействуют через явно определённые интерфейсы: пользовательский слой обращается к API для получения предсказаний, Airflow оркестрирует вычислительные сценарии, а вычислительный слой взаимодействует с источниками и хранилищами данных. В результате получился локально разворачиваемый модульный контур, отдельные компоненты которого можно заменять и расширять без переработки всей системы.

Курс «Дата-инженер»:
3 трека и 6+ проектов в портфолио

Стройте конвейеры и витрины данных, работайте с облаком, Spark, Kafka и Airflow, обучайте ML-модели. Есть трек для специалистов с опытом в ИТ.

Посмотреть программу →

На старте требования были довольно простыми. Модель должна была не просто отвечать «да» или «нет», а ранжировать операции по уровню риска. При этом нужно было уметь объяснить, какие признаки повлияли на оценку и почему операция оказалась выше или ниже в очереди.

Отдельный вопрос был с данными. Они могли приходить из разных источников: CSV-файлов, базы данных, объектного хранилища или API. Поэтому хотелось сделать единую точку входа, через которую с ними можно было бы работать независимо от источника.

Ещё одна важная часть — воспроизводимость. Результат запуска не должен зависеть от того, на каком компьютере и в каких условиях всё выполнялось. Плюс нужно было замечать дрейф данных и понимать, когда пора переобучать.

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

При этом production-функции AML сознательно не включались в текущую версию. Кейс-менеджмент, ролевой доступ, аудиторский след и другие функции полноценного AML-контура требуют отдельного объёма работ и были оставлены в качестве направлений дальнейшего развития.

Как происходила реализация 

Весь процесс обучения и проверки моделей я не стал заворачивать в один большой скрипт. Получилось три независимых DAG'а в Airflow:

• aml_training_dag — обучение моделей;

• aml_benchmark_dag — прогон экспериментов и сравнение результатов;

• aml_drift_dag — проверка дрейфа данных. Единственный из трёх, который крутится по расписанию, каждый день. Остальные два запускаются вручную, когда нужно.

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

Что происходит внутри обучающего DAG

Airflow отвечает за оркестрацию и состояние выполнения DAG, обучающий пайплайн — за сам процесс обучения, а MLflow — за фиксацию параметров, метрик и артефактов эксперимента.

По шагам это выглядит так ↓

1. Сначала Airflow запускает DAG и тут же фиксирует его начальный статус, чтобы потом можно было посмотреть, что вообще случилось с этим прогоном. Дальше обучающий пайплайн выполняет сам сценарий обучения. Параллельно MLflow создаёт запись эксперимента и логирует, какие данные использовались, какие гиперпараметры, когда всё началось.

2. После обучения сохраняются два файла: feature_spec.yaml, где описано, на каких признаках училась модель, и training_summary.json — сводка по обучению. Дальше пайплайн сравнивает модели-кандидаты между собой по конкретной метрике valid PR-AUC и выбирает лучшую версию.

3. Из неё собирается рабочий файл production_bundle.joblib, готовый к инференсу. И вот здесь есть развилка, которая мне самому нравится больше всего в этой схеме: контур пытается зарегистрировать модель в MLflow Registry. Если получилось, то версия фиксируется. Если не получилось, ничего страшного, результаты всё равно сохраняются, просто без пометки «зарегистрировано». Контур не падает целиком из-за того, что одна регистрация не прошла. В конце Airflow обновляет статус выполнения и сохраняет логи и на этом прогон завершается.

4. Шаг с регистрацией — хорошая иллюстрация того, о чём я говорил в разделе про архитектуру: система не должна разваливаться из-за сбоя в одном месте. Здесь этот принцип работает не абстрактно, а буквально, на уровне одного конкретного if/else.

Как устроены сами эксперименты

За эксперименты отвечает отдельный DAG — aml_benchmark_dag. В нём заранее описан набор сценариев, которые можно воспроизводимо запускать и сравнивать между собой.

Базовый сценарий — Base. Здесь модели обучаются и проверяются на базовом датасете. Для него предусмотрены два варианта: исходный набор признаков (raw) и расширенный набор, полученный после feature engineering (engineered). Это позволяет проверить, даёт ли усложнение признаков реальный прирост качества.

Отдельно запускаются Variant I и Variant II. В обоих случаях модель обучается на базовом наборе, а затем проверяется на внешнем датасете. Ещё один сценарий — SAML-D, где пайплайн тестируется на отдельном датасете, подготовленном для задач противодействия отмыванию денег.

Каждый сценарий прогоняется на двух моделях — LightGBM и XGBoost. Для каждого запуска автоматически сохраняются метрики, результаты сравнения и обученная модель. После завершения всех прогонов DAG собирает общие таблицы по экспериментам и отдельно измеряет время инференса.

И здесь важен не столько выбор конкретных алгоритмов, сколько сам принцип работы. Эксперименты можно повторить: параметры сценариев зафиксированы в DAG, а результаты собираются автоматически. Поэтому, если через некоторое время понадобится заново проверить модели, не нужно вручную пересобирать таблицы и пересчитывать метрики.

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

Как считали

Каждый сценарий запускали на двух моделях и оценивали результат сразу с нескольких сторон. Качество оценивали по нескольким группам метрик: ROC-AUC и PR-AUC — для общей оценки качества ранжирования положительного класса, Precision и Recall — для оценки качества классификационных решений при заданном пороге. Дополнительно оценивали долю ложноположительных срабатываний (FPR) и долю операций, попадающих в очередь на проверку (alert rate).

Поскольку одна из ключевых задач проекта — не просто классифицировать операции, а правильно выстраивать их по степени риска, отдельно проверяли качество моделей в верхней части риск-очереди. Для первых 100 и 500 операций рассчитывали top-k метрики Precision, Recall и Lift. В конце измеряли производительность самого решения: отдельно фиксировали время обучения моделей и время инференса.

Усложнение признаков себя не оправдало

Первое, что решил проверить: а стоит ли вообще заморачиваться с расширенным набором признаков или исходных вполне достаточно?

Сравнил модели на сырых признаках и на доработанных и обнаружил, что время обучения выросло почти вдвое: у LightGBM с 23,9 до 41,7 секунды, у XGBoost с 24,4 до 48,4. При этом качество осталось почти таким же: у XGBoost на raw-признаках ROC-AUC составил 0,894, PR-AUC — 0,201. У LightGBM — 0,892 и 0,198. 

Вывод оказался достаточно однозначным: в данном эксперименте расширение признакового пространства не оправдало дополнительных вычислительных затрат.

Дрейф данных — не абстрактная угроза, а то, что реально ловится

Контур сравнивает распределение признаков в новых данных с тем, что было раньше, и показывает, где что изменилось. В одном из отчётов проверили 64 признака и нашли дрейф в двух — это чуть больше 3%. Оба численные: возраст клиента и производный признак, связанный с датой рождения и количеством email за последние 4 недели. У первого PSI (метрика сдвига распределения) составил 0,49, это заметный сдвиг. У второго, наоборот, слабее — 0,12.

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

Модель концентрирует подозрительные операции в верхней части очереди

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

В сценариях Variant I и Variant II значение Precision@100 составило от 0,70 до 0,77. Иными словами, среди первых 100 операций риск-очереди положительный класс составлял 70–77% наблюдений.

Чтобы понять, насколько такой результат лучше случайного отбора, использовали метрику Lift. Она показывает, насколько плотнее положительные объекты концентрируются в верхней части списка по сравнению со случайной выборкой.

Для Lift@100 значения составили от 63,5 до 68,9. Иными словами, в первых 100 операциях риск-очереди положительные объекты встречались примерно в 64-69 раз чаще, чем при случайном отборе. Для Lift@500 результат составил от 47,7 до 53,7.

Отдельно выделяется сценарий SAML-D, в котором пайплайн проверяли на датасете для AML-задач. Здесь Precision@100 достиг 1,00, а Lift@100 — 840,1. Такой высокий Lift связан с крайне редким положительным классом: при его низкой исходной доле концентрация положительных объектов в верхней части очереди даёт особенно заметный эффект. Поэтому эту метрику корректно рассматривать вместе с Precision@k и базовой долей положительного класса, а не изолированно.

Модель объясняет себя, а не просто выдаёт цифру

Отдельно смотрел на интерпретируемость, для этого использовал SHAP — метод, который показывает вклад каждого признака в конкретное предсказание. Он позволяет увидеть, какие признаки внесли наибольший вклад в конкретный прогноз и в каком направлении они изменили значение модельного скора. Кроме того, анализ SHAP помогает выявлять потенциально неочевидные или нежелательные зависимости, которые модель использует при формировании прогноза.

Тут важно не путать: SHAP — не финальное решение, а объяснение к нему. Он даёт понимание, почему конкретная операция получила такой скор, а также возможность контролировать, что вообще происходит внутри модели.

Главное — не модель, а контур вокруг неё

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

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

При этом проект пока остаётся прототипом. В нём ещё нет ряда функций, которые понадобились бы для полноценного использования в банковской среде: кейс-менеджмента, разграничения прав доступа и аудиторского следа. Их реализация потребовала бы дальнейшей доработки системы.

Развивать проект дальше я планирую, но не в сторону полноценной AML-платформы. Часть production-функций логичнее реализовывать в существующем корпоративном AML-контуре банка, с которым должен взаимодействовать ML/MLOps-слой. В приоритете масштабирование обработки данных, более полноценное управление версиями моделей и признаков, автоматизация переобучения и мониторинг деградации качества модели после внедрения. Также хочу продолжить работу над риск-ориентированной очередью, в частности, исследовать настройку её объёма с учётом ограничений на аналитическую обработку.

Проект вырос из выпускной квалификационной работы на программе «Инженерия данных» НИУ ВШЭ и Нетологии, тема и архитектура обсуждались с научным руководителем ещё на этапе постановки задачи.

Код и MVP выложены на GitHub →

Требования к специалистам в данных и ML растут, а входить в тему проще шаг за шагом. Если хотите попробовать, начните с бесплатного:

➊ записи мастер-класса «Искусственный интеллект в разработке» → разобраться, какие ИИ-инструменты есть у инженера: от написания кода до код-ревью;

➋ практического курса «Аналитика и ИИ: как принимают решения в реальном бизнесе» → понять, как на данных принимают решения в реальном бизнесе;

➌ вебинара «Какие профессии в ИТ будут востребованы в 2030 году» → узнать, куда движется рынок и что стоит учить;

➍ демодоступа к Базе знаний Нетологии → получать точечные свежие знания по интересующим темам, когда и где вам удобно.

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