Девен Навани, стажер по машинному обучению летом 2019 г.

Каков правильный подход к выявлению аномалий в данных многомерных временных рядов?

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

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

Наш подход к созданию службы обнаружения аномалий для службы ML API Splunk Cloud мотивировался двумя соображениями:

  1. Доступность для пользователей
  2. Проверенные и опробованные методы машинного обучения

В следующих двух разделах я опишу наш подход и поделюсь некоторыми мыслями относительно его реализации.

Доступность для пользователей

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

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

Параметр чувствительности - это действительное число от 0 до 1, исключая. Если пользователь Splunk укажет большее значение чувствительности, наш сервис вернет больше аномалий. В некотором смысле более высокая чувствительность означает, что точку «легче» обозначить как аномалию. Значение чувствительности нашего алгоритма по умолчанию - 0,15 (подробнее об этом позже).

Изюминкой здесь является то, что мы значительно сократили объем входных данных, имеющихся в распоряжении наших пользователей. В рамках Machine Learning Toolkit (MLTK), отдельной службы, которая является расширением машинного обучения для Splunk Enterprise, пользователи должны запускать команды, как показано на изображении ниже:

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

  1. Указание модели (например, LocalOutlierFactor) - какая модель лучше всего подходит для данных пользователя? Как мы упомянем ниже, математика, лежащая в основе алгоритма, делает его подходящим для конкретных сценариев.
  2. Настройка гиперпараметров. Каким образом пользователь должен установить гиперпараметры после выбора модели? Например, если пользователь хочет более чувствительного обнаружения аномалий, как он или она должен манипулировать параметром leaf_size в конструкторе LocalOutlierFactor?

Теперь в MLTK есть команда обнаружение аномалии, и ее создание было очень мотивировано доступностью для пользователей. Однако мозг этой команды - единственный алгоритм - DensityFunction. Хотя эта работа отвечает нашему первому требованию, в ней не совсем используются самые последние исследования по обнаружению аномалий.

Наука

Я не использовал фразу «современный», потому что это подразумевает превосходную производительность. Как мы обсуждали выше, производительность при обнаружении аномалий сложно измерить. В наборах данных нет точек, которые по своей сути являются аномалиями.

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

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

Популярность ансамблевого обучения для обнаружения аномалий возросла после публикации в 2017 году книги Чару К. Аггарвал и Сакет Сате Ансамбли выбросов - Введение.

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

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

Наш окончательный алгоритм подробно описан на диаграмме ниже:

Каждая строка в таблице слева представляет событие в наборе данных. Числа в первых четырех столбцах таблицы представляют оценки аномалий, которые мы нормализовали до диапазона [0,1]. Оценки аномалий - это мера того, насколько аномальным является событие - чем ближе к 1, тем аномальнее. Последний столбец таблицы содержит средние значения этих аномалий.

Мы сравниваем эти средние значения с порогом, который мы определили как 1 - чувствительность. Поскольку чувствительность по умолчанию составляет 0,15, пороговое значение по умолчанию составляет 0,85. Мы получаем 0,15 по умолчанию, настраивая параметр чувствительности до тех пор, пока средние показатели производительности (f1 / точность / точность / отзыв) не будут максимизированы для всех наших доступных помеченных наборов данных. Чтобы событие было помечено как аномалия, его средний балл за аномалию должен превышать пороговое значение. С математической точки зрения это имеет смысл - если пользователю нужна более чувствительная служба обнаружения аномалий, пороговое значение для события, которое будет помечено как аномалия, должно быть ниже.

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

Реализация

Сначала несколько определений. Рабочий процесс - это многократно используемая конфигурация задач, а сборка - это выполнение задач рабочего процесса для определенного набора данных. Наше доказательство концепции работает путем параллельного запуска четырех рабочих процессов ML API (по одному для каждого алгоритма). Вот как это выглядит для алгоритма LocalOutlierFactor с использованием Python SDK для ML API:

#### LOF ####
LOF_OUTPUTSOURCE = 'dnavani-lof'
LOF_events_output = OutputData(kind='Events', destination=Events(sourcetype=SOURCETYPE, source=LOF_OUTPUTSOURCE))
LOF_task = FitTask(algorithm='LocalOutlierFactor', fields=Fields(features=features_to_use), parameters={})
workflow = Workflow(tasks=[LOF_task])
LOF_workflow = custom_scloud.ml.create_workflow(workflow=workflow)
wfbuild = WorkflowBuild(input=spl_input, output = LOF_events_output)
LOF_wfbuild = custom_scloud.ml.create_workflow_build(id=LOF_workflow.id, workflow_build=wfbuild)
#### LOF ####

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

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

def scoring_system(row):
    if row['average'] > scoring_system_threshold:
        return 1
    return -1
scoring_system_threshold = 1 - SENSITIVITY
scores['average'] = scores.mean(axis=1) # create avg. scores column
predictions = scores.apply(lambda x: scoring_system(x), axis=1)
print(predictions)

Однако для полной интеграции со службой MLAPI Splunk Cloud требуется еще несколько шагов. Мы не хотим, чтобы нашим пользователям приходилось создавать четыре отдельных рабочих процесса. Наша техника ансамбля лучше всего работает с четырьмя задачами в рамках единого рабочего процесса.

По мере продолжения разработки MLAPI и выхода продукта из бета-версии рабочие процессы будут поддерживать логику графа ,, а не только одну задачу или список задач. В нашем случае логика нашего рабочего процесса будет функционировать как вычислительный граф MapReduce, с нашими четырьмя подалгоритмами в качестве «преобразователей» и нашим этапом усреднения / ансамбля в качестве «редуктора». Нашим пользователям нужно будет создать только один рабочий процесс.

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

Девен Навани - стажер по машинному обучению в группе MLAPI Splunk в SCP. Он учится на втором курсе M.E.T. Калифорнийского университета в Беркли. по программе EECS и Business.