Соавторы Анураг Бхатия, Саурабх

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

Изложение выводов

Конвейер вывода должен поддерживать как исторический (т. е. пакетный), так и оперативный (т. е. онлайн) вывод.

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

Разработка стратегии оценки

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

Стандартные показатели

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

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

Затраченные шаги

Шаг 1. Определите подходящую продолжительность lead_time (т. е. промежуток времени между отметкой времени модельного сигнала тревоги и временем простоя — если он есть — после сигнала тревоги) в зависимости от задействованного варианта использования.

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

Шаг 2.Классифицируйте каждый сигнал тревоги (т. е. аномалию) по полезности.

True Positive: Тревога, за которой последовало фактическое время простоя в пределах lead_time. Это также можно назвать «правильными тревогами».

Ложное срабатывание: сигнал тревоги, за которым не последовало фактическое время простоя в рамках lead_time. Это также можно назвать «ложными тревогами».

Шаг 3.Категоризируйте каждый сбой (т. е. время простоя) в соответствии с тем, был ли он заранее обнаружен предсказанием модели (тревога) или нет (пропущен).

True Negative: Случай, когда не было ни простоя, ни соответствующего модельного аварийного сигнала с самого начала.

Ложноотрицательный: ситуация, когда время простоя действительно произошло, но модель не смогла его поймать (т. Е. Предыдущий сигнал тревоги не сработал).

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

  • Матрица путаницы
  • Точность
  • Отзывать
  • f1-счет

Пользовательские показатели

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

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

а) Какую именно дополнительную ценность дает внедряемое решение? (например, какой процент от общего числа простоев в месяц модель могла предсказать заранее? Соответственно, сколько она пропустила?)

Вывод: если модель не учитывает достаточное количество простоев, то она не добавляет ценности с самого начала.

б) Какова стоимость этой добавленной стоимости?

Чтобы быть более конкретным, сколько раз инженеру по техническому обслуживанию необходимо выходить в день (например), чтобы отреагировать на каждый аварийный сигнал?

Подразумеваемое:

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

Предположим, что lead_time составляет 5 дней, и в этом случае количество срабатываний в день должно быть ‹ 0,2 (т. е. ⅕), чтобы это было лучше, чем просто случайное предположение.

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

Вот методы оптимизации для таких результатов

Настраиваемая метрика «количество сигналов тревоги в день» необходима, но не всегда достаточна во всех ситуациях. Даже если общее среднее количество срабатываний будильника невелико (что хорошо), частота срабатывания будильника может быть непропорционально высокой в ​​некоторые дни и отсутствовать в большинстве других дней:

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

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

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

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

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

Заключение

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