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

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

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

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

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

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

Можем ли мы автоматически отслеживать модель машинного обучения для обнаружения мошенничества в режиме реального времени без меток транзакций?

Мошеннические атаки, всплески активности и проблемы с данными

Чтобы лучше проиллюстрировать вариант использования Feedzai, давайте рассмотрим (фиктивный) пример нескольких транзакций:

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

Следующая гистограмма показывает разницу в распределении до и во время атаки:

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

SAMM - Потоковая система для автоматического мониторинга моделей

На рисунке ниже представлен схематический обзор нашей системы: SAMM.

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

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

В нашей системе смещение распределения оценок фиксируется сигналом (S), который мы изображаем на нижнем графике рисунка. Сигнал обеспечивает меру сходства между распределением оценок модели в целевом окне T (самые последние примеры покрыты желтым окном на верхнем графике) и в справочном окне R (зеленое окно на верхнем графике), непосредственно перед T. Мы выбираем базисный период, близкий к целевому, потому что мы хотим обнаруживать внезапные отклонения. Первый аномальный период состоит из мошеннической атаки, которую модель машинного обучения не смогла заблокировать. То же самое относится к атакам мошенничества, которые модель машинного обучения способна правильно блокировать, как показано во втором аномальном периоде светло-красным цветом на среднем графике. Оповещение об атаках, известных модели, также полезно, поскольку они могут перегрузить систему.

Если S превышает заданный порог, срабатывает сигнал тревоги. Для каждого сигнала тревоги мы запускаем вспомогательный процесс, чтобы предоставить объяснение . В этом процессе другая модель машинного обучения обучается задаче поиска шаблона, который лучше всего отличает примеры в T от примеров в R. Выходные оценка смещения и важность функции смещения этой вспомогательной модели машинного обучения затем используются для обобщения характеристик сигнала тревоги и создания отчета для специалиста по данным или данных. аналитик. Давайте рассмотрим каждый компонент SAMM более подробно.

Сигнал

Сигналом является число от 0 до 1, которое измеряет несходство между гистограммой оценок модели в контрольном окне R и гистограммой оценок модели в целевом окне T. Это несходство измеряется с помощью Дивергенции Дженсена-Шеннона (JSD). Если сигнал слабый, это означает, что опорное и целевое окна очень похожи. Если оно близко к 1, эталонное и целевое окна сильно различаются. Целевое окно содержит самые последние события (например, за последние 6 часов). Контрольное окно содержит события за контрольный период (например, за 3 дня до целевого окна) и определяет недавнее нормальное поведение. На схеме ниже представлена ​​эта конфигурация. Оба окна сдвигаются вправо при обработке нового события в потоке данных.

В принципе, для сравнения двух окон можно использовать другие показатели. Однако у JSD есть хорошее свойство теории информации. Если мы помечаем события в целевом окне цифрой 1, а события в контрольном окне - 0 и смешиваем их все, то JSD будет взаимной информацией между оценками модели смеси и соответствующими двоичными метками. Следовательно, когда окна сильно различаются, наблюдение за модельной оценкой события дает хорошее представление об окне, из которого оно возникло. Это также дает мотивацию для нашей стратегии отчетов о тревогах (обсуждается ниже).

Порог

В стационарной среде простейшие процедуры для определения значений выбросов для сигнала включают оценку процентилей распределения прошлых значений сигнала (например, отметку новых значений выше 95-го процентиля как выбросов). Таким образом, для вычисления порога на основе процентилей нам нужен надежный, легкий и гибкий метод для оценки процентилей в сценариях потоковой передачи. В нашей статье мы предлагаем SPEAR (S прослеживающий P эрцентили E стим A to R) - метод стохастической аппроксимации для оценки кумулятивной функции распределения, который можно использовать для получения любого процентиля за один проход по данным (см. нашу статью для получения дополнительной информации).

Кроме того, мы знаем, что наш поток данных на самом деле очень нестационарный. Поэтому оценка распределения сигнала, скажем, в ноябре 2019 года со всеми значениями сигналов с начала года может быть не очень хорошей идеей. (например, если в середине года была развернута новая модель, то нормальный «шумовой» уровень сигнала мог измениться). Таким образом, мы также представили AdaSPEAR, адаптивную версию SPEAR с коэффициентом забвения, который подавляет старые значения сигналов (при сохранении низкой вычислительной сложности алгоритма). Вот классная анимация эволюции позиций процентилей для реального набора данных:

С оцененными процентилями порог SAMM использует определение выброса на основе забора Тьюки, метода, который фокусируется на ширине центральной части распределения прошлых значений сигнала. Мы определяем голый порог Тьюки как

T=Q3+K(Q3−Q1)

где Q1 и Q 3 соответствуют, соответственно, 25-му и 75-му процентилям распределения значений сигнала. K определяет, насколько консервативным является порог.

Отчет о тревоге

После срабатывания будильника пользователи могут естественно спросить «Что вызвало срабатывание будильника?». Сам по себе сигнал не сообщает нам, какое подмножество событий в окне T вызвало тревогу, ни их характеристики. Поэтому мы генерируем автоматический отчет на основе машинного обучения , который пытается дать объяснение для сигнала тревоги. В отчете события ранжируются по шкале T в зависимости от того, насколько вероятно, что они объясняют сигнал тревоги.

Мы используем стратегию, которая использует возможности вспомогательной модели машинного обучения, которая использует как функции, так и оценку риска модели. Для каждого сигнала тревоги мы создаем новую целевую двоичную метку со значением 1 для событий в T и значением 0 для событий в R, а затем обучаем вспомогательную модель машинного обучения, чтобы узнать, как для разделения событий в двух окнах. Это очень естественный подход, учитывая, что наш сигнал (JSD) является мерой информации между этой двоичной меткой, которая идентифицирует окна, и распределением оценок смеси. Для этой цели мы используем модель дерева принятия решений с градиентным усилением (GBDT). Это позволяет нам: 1) получить оценку отклонения сигналов тревоги, которую можно использовать для ранжирования событий в T (более высокая оценка отклонения → более важно для объяснения сигнала тревоги → ближе к вверху) и 2) напрямую получить меру важности функции, которая хорошо справляется с коррелированными функциями, помогая пользователю понять, какие функции наиболее важны для объяснения сигнала тревоги.

В наших экспериментах мы проверили, насколько успешно этот метод может изучить шаблон для тревоги (то есть момент времени с большим сигналом) по сравнению с впадиной (то есть момент времени с низким сигналом). Сначала мы изучили соответствующие кривые ROC с помощью перекрестной проверки:

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

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

Синие точки проверочной кривой - это значения сигналов с использованием R в качестве эталона, но T с удаленными верхними k событиями . Для сравнения мы определяем вторую кривую (оранжевую), где для каждой точки мы случайным образом удаляем k событий из T. Эта случайная процедура не должна снижать значение сигнала. Для истинной тревоги синяя кривая опускается ниже оранжевой кривой (как показано на левом графике), тогда как для впадины (или ложной тревоги) этого не происходит (см. График справа). Мы нашли этот шаг проверки очень полезным и информативным.

Наконец, вот фиктивный пример отчета о тревоге:

Он содержит следующую информацию:

  • Информация об окне с отметками времени начала и окончания;
  • Усеченный список ранжирования важности функций (например, топ-10) - обратите внимание, что в этом примере мы используем фиктивные имена функций, такие как F1 и F5;
  • Кривая валидации, чтобы увидеть, насколько хорошо ранжирование может снизить сигнал;
  • Таблица первых N (например, 100) событий, которые объясняют тревогу, со столбцами, упорядоченными слева направо на основе ранжирования важности функции.

Эксперименты

Для оценки SAMM мы использовали два набора данных с более чем 20 миллионами онлайн-транзакций. Каждый набор данных включает несколько регионов, и для каждого региона существует модель машинного обучения, отвечающая за оценку транзакций. Мы разработали эксперимент, в котором у нас было по два специалиста по данным для каждого региона набора данных. Мы сгенерировали 100 тревожных отчетов (по 20 на каждую область набора данных). Каждый специалист по данным получил для анализа список из 10 тревожных отчетов. Для каждого сигнала тревоги исследователям данных было предложено оценить от 1 до 5 следующие вопросы:

  1. Пожалуйста, укажите оценку от 1 до 5, отражающую вашу уверенность в том, что этот отчет соответствует истинной тревоге (1: полностью уверен, что это ложь, 5: полностью уверен, что это правда);
  2. Укажите балл от 1 до 5, отражающий, насколько четко вы можете видеть закономерность в сделках в представленном отчете (1: никакого паттерна нет, 5: очень четкого паттерна);
  3. Посмотрев на график проверки, дайте новый ответ на Q1 относительно этой новой информации (график проверки был скрыт от пользователя для Q1 и Q2).

В ходе эксперимента мы смешали набор отчетов, основанных на сигналах тревоги, с отчетами, основанными на впадинах. Распределение сигналов тревоги и впадин было задано случайным образом переменной Бернулли с p = 0,5 (равная вероятность выбрать сигнал тревоги или впадину). В ходе этого процесса было выбрано 52 отчета на основе сигналов тревоги и 48 отчетов на основе долин. Мы предположили, что отчеты, основанные на сигналах тревоги, будут иметь более высокие баллы по трем вопросам, которые задают каждому специалисту по анализу данных. Статистический анализ результатов проводился с использованием U-критерия Манна-Уитни с поправкой Холма-Бонферрони для множественных сравнений. Во всех тестах альфа-уровень для нулевой гипотезы о том, что нет разницы между сигналами тревоги и впадинами, составлял 0,05.

Полученные результаты

Таким образом, результаты наших экспериментов показали более высокие баллы для отчетов о тревогах для вопросов 1 и 3 (по сравнению с отчетами для долин). Различия были статистически значимыми по обоим вопросам. Эти результаты подтверждают способность SAMM успешно обнаруживать аномальные события. Некоторые из сигналов тревоги были связаны с атаками ботов, мошенническими атаками, проблемами с данными, которые повлияли на модель, среди прочего.

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

Заключение и следующие шаги

Мы предложили SAMM, систему для мониторинга моделей машинного обучения для потоков данных, которая обнаруживает смещение концепций неконтролируемым образом. SAMM эффективно вычисляет сигнал и порог (алгоритмы SPEAR и AdaSPEAR) и предлагает объяснение в виде отчета о тревоге, который рассматривается полезно для экспертов в предметной области.

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