Предсказание выбытия насосов или как я вошел в data science

Введение

Всем привет, меня зовут Богдан. В ML я начал свое посвящение осенью 2023 года и за этот год успел поработать над таким неоднозначным проектом как "Предсказание выбытия насосов". На данную тему на Хабре уже есть несколько статей, которые я в своё время нашел и опыт которых я пытался перенести в свой учебный big data пет проект :)
ссылки на других ребят тут: ссылка 1 и ссылка 2

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

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

В общем и целом такие насосы используют для добычи нефти и на них установлены датчики, которые замеряют текущие показатели телеметрии. Суммарно в зависимости от комплектации количество датчиков меняется до 40+ параметров.
Таким образом в идеале хотелось бы смотреть на эти датчики и по ним предсказывать ожидаемую наработку на отказ.
Когда я попал в небольшую команду ребят, которым выпало удовольствие 18 карат невезения заниматься в рамках нашей учебной программы этой темой, я и подумать не мог что через пару месяцев начну жестко погружаться в ML и осваивать базу. Плюсом было то, что эти ребята к моему приходу в проект уже выиграли конкурс и получили небольшую поддержку на реализацию стартапа, которую по умному реализовали в покупку курса по ML.

Датасет представляет из себя набор исторических данных на 80 гб. 800+ фичей и почти десяток тысяч скважин. Временной шаг- 1 день. Среди фичей можно выделить ту самую телеметрию, заметки работников на промысле о причинах выбытия и осложнениях, а также расчет геологов и замеры, которые недропользователь делает "ручками". Например такой параметр как дебит нефти не замеряется напрямую, поскольку при добыче нефти добывается и вода. По факту для расчета дебита нефти надо:

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

Когда catboost не all the things

Поговорим немного о всех подходах которые были рассмотрены и я сюда добавлю немного критики в свою сторону, потому что финальное решение хоть и действительно является чем-то новым в рамках данной задачи как минимум в РФ, однако есть другие подходы, которые возможно у кого то сработают из коробки, занижая интерпретируемость, но зато дешево и быстро работая. Перед тем как строить финальную модель из датасета была выбрана идеализированная выжимка, по которой минимум пропусков в данных и замеры велись почти по всем датчикам. Так решалась проблема большого объема данных. А идея заключалась в том, что если на это кусочке данных модель выдаст хороший score, то можно её масштабировать дальше.

• Регрессия.
  Здесь были рассмотрены дефолтные алгоритмы деревьев решений от обычных до ансамблей и проблема заключается вот в чем: временные ряды данных и действительная размеченная наработка на отказ скоррелированы очень слабо и подбор таких гиперпараметров, при которых условный catboost выдаст вам хороший score по MSE, MAE и MSLE (логарифмическая ошибка) на train и test сложная и для меня оказалась невыполнимая задача. Есть гипотеза о том, что можно поставить Gridsearch на неделю и возможно достичь заветных 70% на условном R2 по test и train и надеяться, что это не будет переобучением, но ставку я на это делать не стал.
  В реальности же проблема заключалась в том что нужно логарифмировать целевую переменную и сделать overfitting по MSLE, что выдавало по ней относительно неплохой score, но всегда повышая качество одной из метрик, другая значительно страдала. Попытка добавить фичи из TS Fresh внесла доп шум и снизила итак плохие метрики.

• Классификация
  Аналогичая история, но уже лучше. Accuracy иногда выдавала высокий score, но большее внимание уделялось метрикам F1 и Roc auc, поскольку дисбаланс классов был значительным. Классификатор строился как и на несколько последних дней работы скважины, для большего баланса, так и суммарно на весь цикл жизни. F1 был низкий, порядка 0.03, что говорило о том, что catboost и его собратья меньшие тут не помогут.

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

  Ищем Аномалии

  

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

  

  В итоге попробовав isolation forest я убедился в том, что аномалий много и надо с этим что то делать.

  

  В действительности для данной выборки аномалий было порядка 200 (реальное выбытие), обнаружено в 6 раза больше.
  Здесь начинается самое интересное. Нужно было найти такую модель, которая минимизирует аномалии пока скважина работает и поймет, что с ней что то не так перед выбытием и желательно заранее.
  То есть надо выбрать некоторое временно окно, когда явно есть эти аномалии. Изначально была гипотеза о том, что это окно составляет 15 дней до выбытия, но затем оно сдвинулось на 30 дней до выбытия.
  Посмотрим на несколько графиков

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

Автоэнкодер all the things

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

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

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

На графике видно что чувствительность модели можно крутить, а значит выбирать некоторый оптимальный сценарий, при котором оператор на месторождении спит спокойно и не бегает от каждого сигнала, а также не пропускает то самое аномальное окно.
Действительно такой результат явно можно назвать неплохим, однако можно лучше, правда?
Есть мнение что лучше построить такую модель, которая будет реагировать на любое отклонение, чтобы точно уследить за скважиной. Если скважин мало такой подход действительно может иметь право на жизнь, но если у оператора 100+ скважин дали тревогу, то скорее всего он просто пойдет пить чай :D (шутка)
Он просто физически не успеет за один день оббежать такое количество скважин и алгоритм будет бесполезен, потому что вера в него будет под вопросом.
Значит надо использовать методы предобработки даннных, причем такие, которые можно будет объяснить бизнесу.
Сюда изначально рассматривался метод SVD на 2-х и 3-х мерное представление, однако затем выбор пал на быстрое преобразование Фурье. Это заметно повысило качество временных рядов с одной стороны и минимализировало непонемание с другой.

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

О чудо, модель практически идеально смогла уловить суть нормальных данных, при разделении: train=0.5, val=0.25 и test=0.25.

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

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

Типичная зависимость интенсивности отказов от времени:

 —  𝐼 период приработки и отказов некачественных изделий; 

 — 𝐼𝐼 период нормальной эксплуатации, интенсивность отказов приблизительно постоянна; 

 — 𝐼𝐼𝐼 период старения (отказы вызваны износом деталей и/или старением материалов)
ссылка на источник

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

Как было сказано выше решающий плюс автоэкнодера - возможность изучить проблемные параметры.

Действительно в данных есть расхождение между тем, что ожидает увидеть модель и тем, что происходит в реальности. На основе набора этих расхождений (а именно MSE по всем фичам) делается вывод об аномальности данных.

В итоге я завернул все это решение в приложение на streamlit и закинул на облако того же стримлита.

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

Заключение

Для себя по итогу я увидел в этой задаче хороший pet проект, который позволил мне поступить в совместную магистратуру AI Talent Hub и ИТМО, а также получить первый серьезный оффер, выступить на Data Fest и показать там себя, пусть и в онлайн формате.
Оглядываясь назад в самое начало я и представить не мог, что захочу пойти в ML, связать с этим свою жизнь и что это будет действительно интересно и увлекательно.

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