В этой статье я расскажу, как в одиночку за 3 месяца спроектировал, обучил и довёл до промышленной эксплуатации систему раннего выявления прихватов бурильной колонны. Кода и весов моделей здесь не будет из-за NDA, но я подробно разберу физику предметной области, жёсткие ограничения объекта, реальный факап с железом перед запуском и архитектурные компромиссы, благодаря которым софт прямо сейчас работает на 5 реальных скважинах.

Бизнес-эффект, который мы хотим получить

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

Главная особенность борьбы с прихватами — критическая нехватка времени на реакцию. Как отмечают специалисты ЮРГПУ (НПИ) им. М.И. Платова А.Я. Третьяк, Ю.М. Рыбальченко, С.И. Лубянова и Ю.Ю. Турунтаев в работе «Способы борьбы с дифференциальными прихватами» («Время колтюбинга», № 3 (057), 2016):

«По статистике, в 50% всех случаев прихваченную колонну удается освободить в течение первых четырех часов после возникновения прихвата, в то время как по истечении первых четырех часов этот показатель снижается до 10%».

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

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

Почему важно определить именно тип прихвата

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

  • Дифференциальный (колонну прижимает перепадом давлений к фильтрационной корке на стенке скважины).

  • Механический (заклинивание шламом или обвалившейся породой).

  • Геометрический (заклинивание компоновки на сложных искривлённых участках ствола).

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

Ограничения: изолированный контур, 3 месяца и сюрприз с железом

Архитектуру системы диктовали ограничения реального объекта:

  • Полная изоляция и слабая инфраструктура. Система внедрялась на буровых в развивающемся регионе за пределами РФ, где промышленная и телекоммуникационная инфраструктура заметно слабее. Стабильного интернета на точках зачастую нет в принципе — в лучшем случае спасает нестабильный USB-модем, а чаще всего объект живёт в полной изоляции. Никаких облаков, внешних API и удалённого мониторинга.

  • Жёсткий Time-to-Market (3 месяца на всё). От получения первых сырых логов до запуска в эксплуатацию у меня было ровно 3 месяца. Львиную долю времени съела самая важная часть — работа с физикой бурения, разметка исторических данных и обучение моделей. На обвязку, инфраструктуру и интерфейсы оставался минимум времени.

  • Нет права на ложную тревогу. Цена ошибки на буровой несимметрична. Если система пропустит самое начало прихвата сейчас, но уверенно поймает его через пару минут на следующем окне — по физике процесса это допустимо. Но если она хотя бы раз закричит впустую, бригада потеряет доверие к инструменту и внедрение можно считать проваленным. Поэтому за красивыми цифрами MAE или F1-score я не гнался — единственной главной метрикой стало ноль ложных срабатываний (FPR = 0).

Версия 1.0 и внезапный даунгрейд железа перед стартом

Изначально заказчик дал вводные, что на объектах будут стоять вполне бодрые рабочие станции с дискретными видеокартами уровня GTX на 4 ГБ VRAM. Под эти ожидания я собрал версию 1.0: туда вошли парсер телеметрии, ML-детектор, локальный векторный поиск (RAG) и максимально квантованная локальная Llama для генерации текстовых инструкций оператору.

Но перед запуском "оказалось", что спецификацию на местах "немного спутали": вместо GTX на 4 ГБ внутри ноутбуков под управлением Windows и с 8 ГБ оперативной памяти стояли офисные видеозатычки уровня начальных MX всего на 2 ГБ VRAM.

В связке с самой Windows, фоновым софтом и браузером попытки крутить там квантованную Llama и RAG превращались в борьбу с нехваткой памяти и падениями. Пришлось прямо перед стартом принимать жёсткое решение — вырезать из контура и Llama, и векторную базу. Вместо генеративной модели в версии 1.0 остался детерминированный словарь эвристик со ссылкой на нужный раздел локального PDF-регламента (если прихват дифференциальный, то смотри инструкцию которая лежит по адресу такому-то). Система мгновенно перестала зависеть от видеопамяти и начала работать стабильно.

Решение: как устроена архитектура V2.0

Вся архитектура строилась вокруг главного принципа: если узла нет, он не сломается и его не нужно поддерживать.

Интеграция: WITS-0 по Ethernet (и кабель от принтера)

На буровых работают разные подрядчики со своими станциями геолого-технологических исследований (ГТИ). Современный стандарт WITSML поддерживается далеко не везде и требует настройки XML-схем. Старый текстовый WITS-0 умеет отдавать любая станция. Я сознательно выбрал наименьший общий знаменатель: WITSML может не оказаться, а WITS-0 будет всегда.

От последовательных интерфейсов и переходников USB–COM я отказался сразу — это вероятная точка отказа, потому что ЗИП есть не всегда и не у всех. Поток забирается по TCP/IP через обычный кабель Ethernet. Если патч-корд перебьют, буровой мастер или технолог просто выдернет провод из соседнего офисного принтера и воткнет в компьютер — и система продолжит работу без перенастройки.

Отказоустойчивый парсер: лучше пропустить строчку, чем упасть

Поток WITS-0 в реальных полевых условиях далёк от стерильности: в сокет периодически прилетают обрывки пакетов, битые символы или невалидные значения. Парсер спроектирован по принципу Fail-Safe (Skip-on-Error): он не пытается героически восстановить битую строку и не падает с исключением, а просто отбрасывает кривой пакет и мгновенно переходит к следующему. Потеря одной секунды телеметрии никак не влияет на детекцию прихвата, зато аптайм сервиса остаётся стопроцентным.

Кольцевой буфер в памяти

В системе нет никакой базы данных — ни PostgreSQL, ни ClickHouse, ни записи логов на диск. Валидные строки WITS-0 парсятся на лету в обычные JSON-структуры прямо в оперативной памяти, образуя классический кольцевой буфер:

  • История хранится ровно в виде двух скользящих окон по 20 минут.

  • Как только второе окно заполняется, старые 20 минут безжалостно забываются.

  • В любой момент времени система держит в памяти максимум последние 40 минут бурения — этого с запасом хватает для расчёта признаков.

Почему XGBoost и как подружить его с физическим baseline

В качестве ядра детекции я выбрал XGBoost. На то было три причины:

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

  2. Стабильность: веса модели жёстко заморожены — никакого онлайн-дообучения на буровой нет, чтобы случайные выбросы датчиков не сломали логику.

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

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

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

Гипотетически если спросить бустинг «почему ты решил, что сейчас прихват?», он выдаст сухие вероятности, которые бурильщику ни о чём не говорят. Поэтому задачи были разделены так: факт прихвата определяет XGBoost, а объясняет причины человеку — наложенный поверх бейзлайн, который раскладывает ситуацию на понятные физические признаки и баллы по типам осложнений:

🔗 ПРИХВАТ ОБНАРУЖЕН
⏱️ Время: 2025-06-27T15:50:00
📍 Глубина: 752 м
⚖️ Вес на крюке: 47500 кг
📋 Тип прихвата: Дифференциальный (баллы: 4)
🧮 Баллы по типам: {
  "Механический": 2,
  "Дифференциальный": 4,
  "Геометрический": 2
}

📌 Признаки подозрения на прихват:
 - 📌 глубина не меняется
 - 📌 не вращается (низкий rpm)
 - 📌 нет нагрузки на долото (wob ≈ 0)
 - 📌 нет крутящего момента (torque ≈ 0)
 - 📌 есть циркуляция

📌 Аргументы по типу прихвата:
 - ⏸ колонна стояла → мех+2, диф+2
 - ⛔️ колонна не идет вниз
 - 🚫 не вращается
 - 💧 циркуляция свободная → диф+2, геом+2

Человек видит не абстрактный «риск 0.94», а конкретную физическую картину: колонна стояла, циркуляция свободная, значит с высокой вероятностью это дифференциальный прихват — и сразу получает инструкцию, что делать.

Три модели, Excel с Drill-off Test рядом с .exe и бумажка про F5

Внутри софта зашиты 3 обученные модели XGBoost с разными весами под три разных месторождения (в пределах одного месторождения работает одна конкретная модель). Для локальной подстройки под геологию конкретной скважины в кусте реализована калибровочная надстройка по Drill-off Test (тестам буримости).

Мастер вручную берёт данные по геологическому разрезу (из аналогов РТК) и результаты дрил-тестов и заносит их в простую Excel-таблицу. Никаких коэффициентов коррекции риска мастер туда не вписывает — надстройка сама считывает физические параметры из таблицы и внутри себя корректирует скор.

Софт сделан максимально кондово в угоду скорости:

  • Софт отдаётся на обычной флешке и копируется на локальный диск строго по инструкции в одну и ту же папку на всех компьютерах.

  • В коде пути жёстко захардкожены: если рядом с .exe положили Excel-файл с дрил-тестами — надстройка включается, если не положили — система не падает и спокойно работает на базовой модели. Удобство настройки сознательно принесли в жертву Time-to-Market.

  • Интерфейс оператора сделан на FastAPI + Plotly и открывается в штатном браузере. Дизайнерской красоты здесь нет — только 8 ключевых графиков и статусы режима работы (на скриншоте ниже приведён реальный вид интерфейса на синтетических данных на русском языке):

У связки Plotly + браузер была одна известная особенность: при непрерывной отрисовке потоковых графиков вкладка за несколько часов начинала подъедать оперативную память. Вместо того чтобы тратить недели на переписывание фронтенда, проблему решили самым надёжным способом — распечатанной бумажкой над рабочим местом с инструкцией нажимать F5 каждый час. Фоновый процесс .exe при этом не прерывается, браузер мгновенно сбрасывает память, и система работает сутками без единого сбоя.

Итоги, реальные метрики и что с развитием в On-Premise

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

За время эксплуатации (2 месяца пока что) на этих объектах произошло 7 реальных инцидентов с прихватами. Результаты работы системы на проде:

  • 5 из 7 прихватов модель определила строго вовремя — в рамках целевого 5-минутного окна от начала развития осложнения.

  • Оставшиеся 2 прихвата система поймала в пределах 10-минутного окна.

  • Ложных срабатываний за всё время — ноль.

Но главный бизнес-эффект проявился в скорости реакции бригады. До внедрения системы у смены уходило до 1 часа на то, чтобы осознать факт прихвата, разобраться в его природе по графикам и начать правильные действия по освобождению колонны. С подсказками и разбором признаков от системы это время сократилось минимум вдвое — до 30 минут максимум. Учитывая, что шансы освободить инструмент максимальны именно в первые часы, такой выигрыш в скорости реакции заметно повышает вероятность спасти колонну и избежать многомиллионных убытков от простоев и перебура.

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

Изначально у меня были планы развивать архитектуру дальше и переносить её в полноценный серверный On-Premise контур с базой данных, мониторингом и автоматическим дообучением. Но в реальной индустрии сработало главное правило: «работает — не трогай». Заказчика полностью устраивает текущая версия, система крутится автономно и не требует поддержки, поэтому переезд в красивый On-Premise отложен на неопределённое «когда-нибудь». А простое и надёжное решение V1 продолжает делать свою работу в полях прямо сейчас.