Лет 5 назад эту историю с насосами пытались решить в некоторых нефтегазовых компаниях, тогда хайп по машинному обучению не был таким высоким как сейчас, да и разнообразия выбора алгоритмов тоже не было.
В итоге у кого то это решение сейчас в тестовом режиме, большинство от него просто отказались и остались на старом износе, его проблема в том, что вы просто статистику насоса считаете , а хотелось бы посмотреть на датчик и сказать что скоро произойдет поломка, как вы и сказали.
Мечта для недропользователя - это знать количество дней через которое насос сломается (задача регрессии), однако у нас такое не получилось провернуть, поэтому перешли к задаче поиска аномалий
Эта модель как раз таки строит некоторое мат ожидание относительно параметра телеметрии, например того же ток пэд, дебита жидкости, температуры на входе в уэцн и сопротивления изоляции. Ещё есть такой прекрасный параметр как частота самого тока, но в наших данных его было очень мало, поэтому от данного параметра пришлось оказаться, хотя он своего рода killer feature.
Так вот построив мат ожидание мы смотрим на разницу между тем что выдала модель и что происходит в реальности, на основе этой разницы, если разница небольшая, то все окей, если она превышает установленный порог, то скорее всего это аномалия и скорее всего скоро произойдет поломка.
Тех кто в курсе насколько это возможно мы спрашивали, на сам промысел нас, естественно, никто не звал.
В принципе те параметры которые были выбраны исходили как раз таки из экспертного мнения разработчиков и это тоже была отдельная история по тому как подобрать модель чтоб что-то заработало с одной стороны и с другой было адекватным
1)Строить лес по одному насосу отдельно на самом деле процесс сомнительный, по крайней мере в рамках нашего датасета. 1 цикл жизни это от 200 до 1000 дней (иногда больше, иногда меньше), временной шаг 1 день, насосов суммарно 9 тысяч, выжимка на которой он изначально строился это около 100 скважин (насосов) в одной группе. Ясное дело что метрики будут выше и алгоритм заработает, вопрос эффективно ли делать на каждый насос на большом месторождении отдельную модель? Если у вас 20 насосов, естественно можно навесить изолирующий лес на каждый, или вообще взять авто ML в виде Etna или Prophet для каждого из них и спокойно пить чай. Собственно поэтому переход к Автоэнкодеру и был произведен. Наверное лучше 6 часов один раз потратить на train одной модели (автоэнкодера) и фиксировать её эффективность, чем плодить множество моделей и думать как это все объеденять потом.
LOF не пробовал и вряд-ли снова же его результат будет значительно отличаться от его собратьев. Аномалий в данных много и если алгоритм реагирует на любой чих, то это приводит к ложному срабатыванию, если оно произошло, а условный оператор заказал новый насос, потому что поверил, то этот насос просто будет стоять на складе впустую еще какое-то время до действительной поломки, что не очень хорошо, потому что эти насосы берут в аренду, как правило. Тогда оператор просто перестанет верить в алгоритм и он станет просто не нужным.
Также к этому я приводил пример с cusum на единичной скважине, решение выдает ложные срабатывания:
Переходя к этой задаче я попробовал такой метод как cusum и получил интересный результат. Аномалии явно происходят чаще чем в день выбытия, что объясняло то, почему классификатор не работал. На протяжении всего цикла жизни скважины можно заметить, резкие падения амплитуды, они вызваны геолого-техническими мероприятиями, сменой режима работы скважины и рядом других процессов в ходе эксплуатации.Иногда эта смена режима и есть то самое выбытие и пройзойти оно может действительно заранее.
Cusum (фактический день выбытия 386)
2) Нормализация данных перед обучением Автоэнкодера это Min Max scaler, естественно, а разведочный анализ проводился суммарно сначала на наличие выбросов и пропусков, которых было много, поэтому финальный датасет это уже не 9, а примерно 5,8 тыс. скважин. Потом проводились поиски коррелирующих параметров относительно целевой наработки на отказ, или же самого отказа (F-test, Pearson, Mutual info). Также на единичных скважинах чтобы лучше понять данные и как меняется амплитуда какого-либо параметра перед выбытием
3) Gridsearch в данной задаче это единственный возможный вариант найти оптимальные гиперпараметры, потому что наугад тут не подкрутишь. Естественно набор гиперпараметров был не настолько большим, чтобы проводить его в несколько дней, поэтому как я отметил есть вероятность, что человек со стремлением решить эту задачу через classic ML, запустив gridsearch на много времени получит какой-то адекватный результат. Задавшись вопросом нужен ли мне такой gridsearch я и перешел к Автоэнкодеру. На удивление обучить нейронку просто быстрее, чем перебирать оптимальные гиперпараметры, а еще эмбеддинги от автоэнкодера можно использовать дальше и перейти от них к более простым решениям, что в принципе тоже должно сработать, возможно тот же LOF тут будет к месту.
В первой статье (https://habr.com/ru/articles/800999/) как раз таки об этом и шла речь, 50 признаков в сумме, пытаемся разделить планеты на кандидатов и не кандидатов, в датасете есть начальная разметка данных, а более подробно о признаках можно прочитать здесь: https://exoplanetarchive.ipac.caltech.edu/docs/API_kepcandidate_columns.html поскольку данная статья рассматривалась больше в ключе ML и соответственно призвана выполнять следующее: Определить исходя из отобранных признаков является ли небесное тело, которую обнаружили по спутнику Kepler кандидатом в экзопланету, или же нет. Соответственно подробное рассмотрение признаков в этой статье предусмотрено не было, а ссылка на их описание может помочь тем, кто действительно готов потратить на это своё время и возможно добавить что то от себя.
В будущем обязательно проверим эффективность данного метода, в сравнении с наработанным baseline, спасибо за идею.
Спасибо ☺️
Лет 5 назад эту историю с насосами пытались решить в некоторых нефтегазовых компаниях, тогда хайп по машинному обучению не был таким высоким как сейчас, да и разнообразия выбора алгоритмов тоже не было.
В итоге у кого то это решение сейчас в тестовом режиме, большинство от него просто отказались и остались на старом износе, его проблема в том, что вы просто статистику насоса считаете , а хотелось бы посмотреть на датчик и сказать что скоро произойдет поломка, как вы и сказали.
Мечта для недропользователя - это знать количество дней через которое насос сломается (задача регрессии), однако у нас такое не получилось провернуть, поэтому перешли к задаче поиска аномалий
Эта модель как раз таки строит некоторое мат ожидание относительно параметра телеметрии, например того же ток пэд, дебита жидкости, температуры на входе в уэцн и сопротивления изоляции. Ещё есть такой прекрасный параметр как частота самого тока, но в наших данных его было очень мало, поэтому от данного параметра пришлось оказаться, хотя он своего рода killer feature.
Так вот построив мат ожидание мы смотрим на разницу между тем что выдала модель и что происходит в реальности, на основе этой разницы, если разница небольшая, то все окей, если она превышает установленный порог, то скорее всего это аномалия и скорее всего скоро произойдет поломка.
Тех кто в курсе насколько это возможно мы спрашивали, на сам промысел нас, естественно, никто не звал.
В принципе те параметры которые были выбраны исходили как раз таки из экспертного мнения разработчиков и это тоже была отдельная история по тому как подобрать модель чтоб что-то заработало с одной стороны и с другой было адекватным
Сразу видно нефтяники вошли в чат, поменяю на схему
1)Строить лес по одному насосу отдельно на самом деле процесс сомнительный, по крайней мере в рамках нашего датасета. 1 цикл жизни это от 200 до 1000 дней (иногда больше, иногда меньше), временной шаг 1 день, насосов суммарно 9 тысяч, выжимка на которой он изначально строился это около 100 скважин (насосов) в одной группе.
Ясное дело что метрики будут выше и алгоритм заработает, вопрос эффективно ли делать на каждый насос на большом месторождении отдельную модель?
Если у вас 20 насосов, естественно можно навесить изолирующий лес на каждый, или вообще взять авто ML в виде Etna или Prophet для каждого из них и спокойно пить чай.
Собственно поэтому переход к Автоэнкодеру и был произведен.
Наверное лучше 6 часов один раз потратить на train одной модели (автоэнкодера) и фиксировать её эффективность, чем плодить множество моделей и думать как это все объеденять потом.
LOF не пробовал и вряд-ли снова же его результат будет значительно отличаться от его собратьев. Аномалий в данных много и если алгоритм реагирует на любой чих, то это приводит к ложному срабатыванию, если оно произошло, а условный оператор заказал новый насос, потому что поверил, то этот насос просто будет стоять на складе впустую еще какое-то время до действительной поломки, что не очень хорошо, потому что эти насосы берут в аренду, как правило. Тогда оператор просто перестанет верить в алгоритм и он станет просто не нужным.
Также к этому я приводил пример с cusum на единичной скважине, решение выдает ложные срабатывания:
2) Нормализация данных перед обучением Автоэнкодера это Min Max scaler, естественно, а разведочный анализ проводился суммарно сначала на наличие выбросов и пропусков, которых было много, поэтому финальный датасет это уже не 9, а примерно 5,8 тыс. скважин. Потом проводились поиски коррелирующих параметров относительно целевой наработки на отказ, или же самого отказа (F-test, Pearson, Mutual info). Также на единичных скважинах чтобы лучше понять данные и как меняется амплитуда какого-либо параметра перед выбытием
3) Gridsearch в данной задаче это единственный возможный вариант найти оптимальные гиперпараметры, потому что наугад тут не подкрутишь. Естественно набор гиперпараметров был не настолько большим, чтобы проводить его в несколько дней, поэтому как я отметил есть вероятность, что человек со стремлением решить эту задачу через classic ML, запустив gridsearch на много времени получит какой-то адекватный результат.
Задавшись вопросом нужен ли мне такой gridsearch я и перешел к Автоэнкодеру. На удивление обучить нейронку просто быстрее, чем перебирать оптимальные гиперпараметры, а еще эмбеддинги от автоэнкодера можно использовать дальше и перейти от них к более простым решениям, что в принципе тоже должно сработать, возможно тот же LOF тут будет к месту.
В первой статье (https://habr.com/ru/articles/800999/) как раз таки об этом и шла речь, 50 признаков в сумме, пытаемся разделить планеты на кандидатов и не кандидатов, в датасете есть начальная разметка данных, а более подробно о признаках можно прочитать здесь:
https://exoplanetarchive.ipac.caltech.edu/docs/API_kepcandidate_columns.html
поскольку данная статья рассматривалась больше в ключе ML и соответственно призвана выполнять следующее:
Определить исходя из отобранных признаков является ли небесное тело, которую обнаружили по спутнику Kepler кандидатом в экзопланету, или же нет.
Соответственно подробное рассмотрение признаков в этой статье предусмотрено не было, а ссылка на их описание может помочь тем, кто действительно готов потратить на это своё время и возможно добавить что то от себя.