Основные выводы:

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

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

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

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

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

Мы видели две распространенные реакции на нехватку данных:

  1. Грубая сила: пригласите «передовых» специалистов по данным, чтобы помочь развязать узлы.
  2. Отложите боль: создайте озеро данных, чтобы хранить «все», разработайте политики для осмысления этих данных и попытайтесь развязать узлы позже.

Оба подхода имеют недостатки.

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

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

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

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

Наш подход к PPO называется Clue. Разрежьте узел.