Да, все верно, теперь понял Вашу мысль! Замечу, что у нас, к сожалению, нет информации о том, замеряются ли данные для разных трансформаторов или за разные периоды времени. Было бы полезно иметь признак id трансформатора, а также время работы с момента запуска. Еще полезны в таких случаях данные о ППР и значительных ремонтных работах, чтобы учитывать время с последнего ремонта.
По поводу обобщающей способности модели: если у нас есть в выборке данные с трансформаторов с разным периодом эксплуатации на момент записи данных, то модель как раз и может выучить "закон" деградации, то есть, например, разная степень загрязнения изоляторов по-разному отражается в данных, и модель учится определять. Конечно, скорость деградации может меняться (наверно, Вы это и имеете в виду), тогда нам помогут нелинейные модели типа градиентного бустинга.
Конечно, лучше было бы иметь такую историю как вы говорите, а также информацию о длительности эксплуатации, тогда построить честно модель для всего срока эксплуатации трансформаторов и (самое главное!) оценить ее честно, было бы возможно. Сейчас действительно без знаний о периодах сбора данных и идентификации единиц оборудования делать это сложно.
Здесь данных все-таки 2100 файлов по 420 записей. То есть 420 записей используются для одного инференса (расчета) модели и прогнозировании (вычислении) одного числа. В продуктивной среде это может реализоваться как "искусственное" нарезание окна в 420 точек для прогноза из более длительного временного ряда. Можно и обучить модель заново на другом количестве точек, например, на большем. В принципе можно проверить гипотезу о применении этой модели на большем числе точек, то есть выделение того же набора признаков, требующегося на вход модели, можно производить и для большего (>420 точек) датасета.
Спасибо за комментарий! Отличное дополнение к посту с точки зрения технической экспертизы, которой мне в этой узкой области может не хватать!
Эта задача действительно идет последовательно после задачи определения типа дефекта, что уже указывает на конкретный тип развивающейся аномалии. Но для указания коренной причины (если вы имеете в виду, говоря про причину) требуется дополнительная информация и доменная экспертиза. Обычно дата сайентисты формируют имеющуюся информацию о дефекте (сигналы, по которым зарегистрирован, локализация, если возможно и др.), а далее совместно с техническим персоналом или диагностами происходит анализ информации и выход на коренную причину, если ее возможно установить. В любом случае решение описанной в статье задачи может являться советчиком для диагностов, а при наличии дополнительных данных (здесь их, к сожалению, нет) решение может быть углублено для автоматизации диагностирования и упрощения работы специалистов.
Кстати, о решении задачи поиска и классификации аномалий можете прочитать в этой статье. Был бы рад обратной связи!
PS Добавил важный дисклеймер, который должен пояснить уровень детализации написанного в статье.
Спасибо за комментарий! Конечно, о прорыве (в рамках поста) речь не идет, это очевидно. Пост скорее о кейсе решения задачи с помощью МЛ с ссылкой на код и данные, что можно использовать в своих исследованиях, работе, обучении и тд. То есть речь о популяризации МЛ в промышленности.
Комментарии справедливые, но важно понимать, что материал для начального/среднего уровня специалистов. Для тех кто хочет познакомиться с МЛ в промышленных приложениях, для тех, кто разбирается в технической стороне задачи, но хочет начать решать типичные задачи диагностики с помощью МЛ, наконец, для тех, кто учится МЛ. И действительно, мне стоит добавить дисклеймер с указанием аудитории, согласен. Здорово, что вы сравниваете с Титаником, ведь цель такая и была - снизить порог входа и сделать понятный блокнот типа Титаника, чтобы дальше каждый сам мог углубиться, сравниваясь с представленными мной подходами и полученными метриками. Как я и сказал в конце, у нас при решении этой задачи на чуть более глубоком уровне результат был в несколько раз лучше.
Кстати о рекламе канала, про работу с пропусками и грязными данными вы можете найти материал в моем канале (я серьезно), в дальнейшем будут детальные посты на эти темы, так как опыта с промышленными данными немало, даже целый доклад можете посмотреть (он без кода и конкретики по методам обработки, но это все еще будет в канале), вдруг найдете, чем его дополнить, было бы отлично!
Честно говоря, не знаю, как решается вопрос с определением остаточного ресурса, наверно, для такого оборудования становится оправдано строить полноценные физ модели, а оттуда и данные можно нагенерировать для обучения моделей, и отклонение состояния от модели находить, и ресурс считать. Аномалии в таком случае (маленькая статистика отказов, уникальность оборудования), кстати, ищутся на основе построения моделей нормального режима работы (физические, математические, статистические и тд), а после детектируется отклонение от нормального режима работы.
Согласен в целом, а по поводу мультиагентного обучения затрудняюсь ответить - не специалист, в целом RL очень мало в промышленности, знаю всего несколько кейсов, например, Северсталь [youtube], [Arxiv]. Проблемы, насколько я знаю, в объеме и качестве данных, трудоемкости подходов с RL (тут и низкая квалификация дата сайентистов часто), а также невозможности проводить какие-то эксперименты с оборудованием для сбора большего числа данных и тестирования подходов в разных режимах.
Кстати, изнутри не знаю об успехах DS в телекоме, а ориентируюсь на активность компаний в DS сообществе (треки на конференциях, доклады с кейсами, хакатоны и тд), вот несколько примеров:
Интересно Ваше мнение, с какими из представленных проблем он борется (или какие недостатки убирает), потому что в первую очередь мне он знаком как метод снижения размерности
К сожалению, встречал кейсы, когда данные вообще не хранились, либо сохранялись только после каких-то преобразований. По опыту: чем выше уровень автоматизации и цифровизации, тем чаще хранятся сырые данные и вообще стратегия работы с данными становится осмысленнее и лучше с точки зрения машинного обучения и data science.
Речь в статье идет скорее о промышленных производствах и других менее "опасных" и "закрытых" объектах промышленности, а не о реакторах или АЭС в целом.
Не могу ничего, к сожалению, сказать про данные на реакторах)
Да, все верно, теперь понял Вашу мысль! Замечу, что у нас, к сожалению, нет информации о том, замеряются ли данные для разных трансформаторов или за разные периоды времени. Было бы полезно иметь признак id трансформатора, а также время работы с момента запуска. Еще полезны в таких случаях данные о ППР и значительных ремонтных работах, чтобы учитывать время с последнего ремонта.
По поводу обобщающей способности модели: если у нас есть в выборке данные с трансформаторов с разным периодом эксплуатации на момент записи данных, то модель как раз и может выучить "закон" деградации, то есть, например, разная степень загрязнения изоляторов по-разному отражается в данных, и модель учится определять. Конечно, скорость деградации может меняться (наверно, Вы это и имеете в виду), тогда нам помогут нелинейные модели типа градиентного бустинга.
Конечно, лучше было бы иметь такую историю как вы говорите, а также информацию о длительности эксплуатации, тогда построить честно модель для всего срока эксплуатации трансформаторов и (самое главное!) оценить ее честно, было бы возможно. Сейчас действительно без знаний о периодах сбора данных и идентификации единиц оборудования делать это сложно.
Здесь данных все-таки 2100 файлов по 420 записей. То есть 420 записей используются для одного инференса (расчета) модели и прогнозировании (вычислении) одного числа. В продуктивной среде это может реализоваться как "искусственное" нарезание окна в 420 точек для прогноза из более длительного временного ряда. Можно и обучить модель заново на другом количестве точек, например, на большем. В принципе можно проверить гипотезу о применении этой модели на большем числе точек, то есть выделение того же набора признаков, требующегося на вход модели, можно производить и для большего (>420 точек) датасета.
Спасибо за комментарий! Отличное дополнение к посту с точки зрения технической экспертизы, которой мне в этой узкой области может не хватать!
Эта задача действительно идет последовательно после задачи определения типа дефекта, что уже указывает на конкретный тип развивающейся аномалии. Но для указания коренной причины (если вы имеете в виду, говоря про причину) требуется дополнительная информация и доменная экспертиза. Обычно дата сайентисты формируют имеющуюся информацию о дефекте (сигналы, по которым зарегистрирован, локализация, если возможно и др.), а далее совместно с техническим персоналом или диагностами происходит анализ информации и выход на коренную причину, если ее возможно установить. В любом случае решение описанной в статье задачи может являться советчиком для диагностов, а при наличии дополнительных данных (здесь их, к сожалению, нет) решение может быть углублено для автоматизации диагностирования и упрощения работы специалистов.
Кстати, о решении задачи поиска и классификации аномалий можете прочитать в этой статье. Был бы рад обратной связи!
PS Добавил важный дисклеймер, который должен пояснить уровень детализации написанного в статье.
Спасибо за комментарий! Конечно, о прорыве (в рамках поста) речь не идет, это очевидно. Пост скорее о кейсе решения задачи с помощью МЛ с ссылкой на код и данные, что можно использовать в своих исследованиях, работе, обучении и тд. То есть речь о популяризации МЛ в промышленности.
Комментарии справедливые, но важно понимать, что материал для начального/среднего уровня специалистов. Для тех кто хочет познакомиться с МЛ в промышленных приложениях, для тех, кто разбирается в технической стороне задачи, но хочет начать решать типичные задачи диагностики с помощью МЛ, наконец, для тех, кто учится МЛ. И действительно, мне стоит добавить дисклеймер с указанием аудитории, согласен. Здорово, что вы сравниваете с Титаником, ведь цель такая и была - снизить порог входа и сделать понятный блокнот типа Титаника, чтобы дальше каждый сам мог углубиться, сравниваясь с представленными мной подходами и полученными метриками. Как я и сказал в конце, у нас при решении этой задачи на чуть более глубоком уровне результат был в несколько раз лучше.
Кстати о рекламе канала, про работу с пропусками и грязными данными вы можете найти материал в моем канале (я серьезно), в дальнейшем будут детальные посты на эти темы, так как опыта с промышленными данными немало, даже целый доклад можете посмотреть (он без кода и конкретики по методам обработки, но это все еще будет в канале), вдруг найдете, чем его дополнить, было бы отлично!
Честно говоря, не знаю, как решается вопрос с определением остаточного ресурса, наверно, для такого оборудования становится оправдано строить полноценные физ модели, а оттуда и данные можно нагенерировать для обучения моделей, и отклонение состояния от модели находить, и ресурс считать. Аномалии в таком случае (маленькая статистика отказов, уникальность оборудования), кстати, ищутся на основе построения моделей нормального режима работы (физические, математические, статистические и тд), а после детектируется отклонение от нормального режима работы.
Согласен в целом, а по поводу мультиагентного обучения затрудняюсь ответить - не специалист, в целом RL очень мало в промышленности, знаю всего несколько кейсов, например, Северсталь [youtube], [Arxiv]. Проблемы, насколько я знаю, в объеме и качестве данных, трудоемкости подходов с RL (тут и низкая квалификация дата сайентистов часто), а также невозможности проводить какие-то эксперименты с оборудованием для сбора большего числа данных и тестирования подходов в разных режимах.
Кстати, изнутри не знаю об успехах DS в телекоме, а ориентируюсь на активность компаний в DS сообществе (треки на конференциях, доклады с кейсами, хакатоны и тд), вот несколько примеров:
https://ods.ai/tracks/megafon-df2020
https://ods.ai/tracks/mts-recsys-df2020
https://ods.ai/competitions/mtsmlcup (прямо сейчас идет)
поэтому очень интересно было прочитать такие детали, спасибо за комментарий!
Спасибо за пояснение! Интересно.
Интересно Ваше мнение, с какими из представленных проблем он борется (или какие недостатки убирает), потому что в первую очередь мне он знаком как метод снижения размерности
Спасибо за дополнения и ответы на вопросы, а также за полезные материалы!
К сожалению, встречал кейсы, когда данные вообще не хранились, либо сохранялись только после каких-то преобразований. По опыту: чем выше уровень автоматизации и цифровизации, тем чаще хранятся сырые данные и вообще стратегия работы с данными становится осмысленнее и лучше с точки зрения машинного обучения и data science.
Речь в статье идет скорее о промышленных производствах и других менее "опасных" и "закрытых" объектах промышленности, а не о реакторах или АЭС в целом.
Не могу ничего, к сожалению, сказать про данные на реакторах)