Ваша модель обнаружения аномалий умнее, чем вы думаете

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

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

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

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

«Мне нужен рецепт: скажите, что мне делать, чтобы предотвратить неудачу».

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

• Настройте среду Jupyter в облаке с помощью Amazon SageMaker,
• Скопировано репозиторий GitHub, содержащий весь код, необходимый для этой статьи.
• Определил хороший набор данных, скачал и изучил его
• Обучил модель обнаружения аномалий с помощью Amazon Lookout for Equipment (управляемый сервис от AWS, предназначенный для обнаружения аномалий).
• Визуализируйте необработанные результаты вашей модели обнаружения аномалий.
• Постобработка результатов для получения более значимых выводов

Итак, приступим к первому шагу!

Давайте устроимся поудобнее: подготовка вашей среды!

Я рекомендую вам следить за этой записью в блоге, перейдя на GitHub, чтобы получить эту серию сопутствующих блокнотов Jupyter. Вы можете использовать обычную среду Jupyter или запустить ее с помощью Amazon SageMaker.

• Если вы хотите использовать свою обычную среду Jupyter, у вас уже есть обученная модель обнаружения аномалий и вы протестировали ее на некоторых тестовых данных, чтобы получить хорошие результаты. перейти к следующему абзацу!
• Если вы хотите использовать свою обычную среду Jupyter, иметь некоторые данные и хотите попробовать Amazon Lookout for Equipment для обучения модели обнаружения аномалий, вам потребуется создать учетную запись AWS и убедиться, что учетные данные вашей учетной записи доступны из вашей среды.
• Если вы хотите остаться в среде AWS, вы можете создать учетную запись AWS, запустить среду Amazon SageMaker и предоставить ей доступ к Amazon Lookout for Equipment API. Вы можете использовать тот же набор данных, что и в этой статье, или принести свой собственный.

Теперь я буду считать, что ваша среда готова: первый шаг — клонировать в нее этот репозиторий GitHub:

git clone https://github.com/michaelhoarau/smarter-anomaly-detection.git

Блокноты из этого репозитория проведут вас через весь процесс от подготовки данных до постобработки результатов. Вы можете начать с первого 1_data_preparation.ipynb.

Обзор данных

Подождите минутку... Что ВЫ называете аномалией?

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

• Форма интересующих вас аномалий
• Как они накапливают сверхурочную работу
• Что происходит при их срабатывании

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

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

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

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

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

Теперь, когда мы выровняли поле с точки зрения определения, давайте применим это на практике, взглянув на реальный промышленный многомерный набор данных…

Обзор набора данных

Поиск промышленного многомерного набора данных временных рядов с аннотированными аномалиями и достаточным количеством исторических данных сам по себе является сложной задачей. Единственный общедоступный набор данных с соответствующими аномалиями, который я видел, — это набор данных о промышленных водяных насосах, доступный на Kaggle. Вы можете скачать этот набор данных по этой ссылке. Этот набор данных содержит 52 датчика за период с 1 апреля 2018 г. по 31 августа 2018 г. (5 месяцев) с частотой дискретизации 1 минута. Однако, поскольку с этим набором данных не связана лицензия, вы не можете использовать его в каких-либо коммерческих целях.

Чтобы помочь вам начать работу, первая записная книжка (synthetic_0_data_generation.ipynb) в репозитории, упомянутом ранее, сгенерирует синтетический многомерный набор данных временных рядов и добавит в него различные типы аномалий: это не похоже на реальную вещь, но она будет достаточно близкой, чтобы раскрыть мои здесь мыслительный процесс. Я создал набор данных с 20 сигналами, данными за 1 год и частотой дискретизации 10 минут.

Давайте загрузим эти данные и посмотрим на несколько сигналов:

• Определите время отказа (красные точки ниже)
• Выделите периоды (желтым цветом ниже), в течение которых этот виртуальный актив был сломан или восстанавливался после сбоя:

Использование этого набора данных за первые пять месяцев для обучения модели (с января 2021 г. по май 2021 г.) даст нам как минимум 2 аномальных диапазона для оценки нашей модели.

• Одна из них — желтая полоса, видимая в ноябре 2021 года.
• Другим будет странный всплеск, видимый на зеленом сигнале в начале сентября 2021 года.

Давайте построим ленточную диаграмму для этих 20 временных рядов:

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

• Низкие значения сигнала зеленые
• Средние значения оранжевые
• И высокие значения красные

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

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

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

Для создания ленточных диаграмм я использовал свой пакет tsia (pip install tsia), а затем следующий код:

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

После создания синтетического набора данных вы можете использовать второй сопутствующий блокнот (synthetic_1_data_preparation.ipynb) для подготовки данных для Amazon Lookout for Equipment. Не стесняйтесь обновлять его, чтобы подготовить данные к формату, подходящему для вашей собственной модели обнаружения аномалий. Вы готовы обучать свою модель!

Обучение модели обнаружения аномалий

Я буду использовать Amazon Lookout for Equipment для обучения модели обнаружения аномалий на предыдущем наборе данных. Для этого вам потребуется учетная запись AWS. Затем в уже упомянутом репозитории GitHub вы можете запустить третий сопутствующий блокнот (тот, который называется synthetic_2_model_training.ipynb): это отправит данные в Amazon S3 (сервис блочного хранилища AWS, который большинство управляемых сервисов AWS AI/ML используют для входных наборов данных) , принимать данные и обучать модель обнаружения аномалий.

Если вы хотите узнать больше об Amazon Lookout for Equipment, в моей книге «Анализ временных рядов на AWS» этому сервису посвящено шесть глав:

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

Процесс обучения включает в себя оценку ретроспективных данных на исторических данных, где вы можете определить события, которые служба обнаружила бы, если бы она работала в то время. Как и другие модели обнаружения аномалий, необработанные результаты Amazon Lookout for Equipment выглядят следующим образом:

Вверху я нанес временные ряды для некоторых датчиков. Ниже зеленым цветом показаны известные периоды, когда виртуальный актив восстанавливался после сбоя. Внизу красным цветом показаны события, обнаруженные Lookout for Equipment. Увидев эти результаты, кто-то может указать, что:

«Есть несколько ложных срабатываний, у меня нет времени расследовать каждое событие!»

«Ваша модель обнаруживает аномалии только тогда, когда они уже произошли, это бесполезно!»

«У меня сотни датчиков: когда ваша модель обнаруживает аномалию, мне все равно приходится исследовать все свои операции, я не экономлю здесь время!»

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

Постобработка необработанных выходных данных модели

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

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

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

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

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

Измерение частоты событий

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

Исходя из этого, вы можете решить уведомлять оператора только после того, как ежедневная частота событий достигнет не менее 200 в день. Это позволит вам реагировать только на 3 события из 41, обнаруженных за этот период. Моя модель обнаружения аномалий выводит кадр данных со статусом для каждой отметки времени (0, если ничего не обнаружено, и 1, если обнаружена аномалия). Мои данные имеют частоту дискретизации 5 минут, поэтому, если я использовал скользящее окно более 12 x 24 = 288 periods, я покрываю данные за полный день:

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

Давайте теперь попробуем решить последнюю проблему, связанную с потерей времени из-за недостаточной точности моделей обнаружения аномалий, когда дело доходит до помощи в анализе первопричин…

Измерение и построение вкладов переменных

Многие модели обнаружения аномалий также дают некоторые детали объяснимости, такие как вклад каждой переменной в любое обнаруженное событие. Amazon Lookout for Equipment ничем не отличается, и результаты каждой модели будут включать следующее поле в выходные данные JSON для каждого обнаруженного события:

'predicted_ranges': [
    {
        'start': '2019-08-08T00:42:00.000000',
        'end': '2019-08-08T01:48:00.000000',
        'diagnostics': [
            {'name': 'synthetic\\signal_00', 'value': 0.052},
            {'name': 'synthetic\\signal_01', 'value': 0.023},
            {'name': 'synthetic\\signal_02', 'value': 0.038},
            {'name': 'synthetic\\signal_03', 'value': 0.023},
            ...
            {'name': 'synthetic\\signal_17', 'value': 0.049},
            {'name': 'synthetic\\signal_18', 'value': 0.033},
            {'name': 'synthetic\\signal_19', 'value': 0.046},
            {'name': 'synthetic\\signal_20', 'value': 0.044}
        ]
    },
    ...
]

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

Теперь вместо частоты событий давайте построим график изменения важности переменной во времени:

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

Это немного лучше, мы действительно можем лучше отслеживать тенденции и определять, что несколько сигналов могут быть наиболее важными для данного события. Однако, пытаясь понять «самые важные», нам не нужно отображать все 50+ сигналов. Давайте просто попробуем сосредоточиться на топ-5 и объединить все остальные в категорию «Другие сигналы»:

Это быстрее для построения и намного читабельнее. При 20 сигналах, если бы каждый сигнал вносил одинаковый вклад в данное событие, вклад каждого сигнала составлял бы 5 %, а вклад 5 сигналов — 25 %. Выше мы видим, что первые 5 датчиков постоянно достигают вклада от 30% до 60%, а это означает, что это может быть весьма интересно для дальнейшего изучения…

Теперь давайте добавим несколько сигналов и событий (известных или обнаруженных) для некоторого дополнительного контекста вокруг этой гистограммы:

Все подробные коды вы найдете в synthetic_3_model_evaluation.ipynb блокноте. Из расширенного кадра данных результатов, показанного выше (назовем его df), предыдущая гистограмма создается с помощью следующего кода:

Что дальше?

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

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

Я надеюсь, что вы нашли эту статью полезной: не стесняйтесь оставлять мне комментарии здесь и не стесняйтесь подписываться на мою рассылку по электронной почте Medium, если вы не хотите пропустить мои будущие публикации! Хотите поддержать меня и будущую работу? Присоединяйтесь к Medium по моей реферальной ссылке: