Архитектура системы

В основе решения лежит двухконтурная схема. Первый контур — офлайн-обучение: здесь работают XGBoost и CatBoost, обучаются на накопленных исторических данных и генерируют модели. Второй контур — онлайн-инференс: лёгкий сервис на Flask принимает параметры скважины и возвращает расчётный объём жидкости глушения в реальном времени.

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

Асимметричная функция потерь

Одно из ключевых решений проекта — отказ от стандартного .fit() с дефолтной функцией потерь в пользу так называемого K-метода. Это асимметричная loss-функция, которая по-разному штрафует модель за два типа ошибок: недолить жидкость глушения и перелить её.

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

CatBoost против XGBoost

Обе библиотеки дали сравнимые метрики на тестовой выборке, однако в работе они ведут себя по-разному. CatBoost оказался удобнее при работе с «сырыми» категориальными признаками — скважинные данные содержат много категорий (тип породы, конструкция скважины и т.п.), и CatBoost обрабатывает их нативно без предварительного кодирования.

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

Малые данные и нестабильность метрик

Пожалуй, самый нетривиальный вызов проекта — крайне малый объём обучающей выборки: около 350 строк. При таком размере случайное разбиение на train/test-выборки начинает существенно влиять на результат: метрики скачут от сида к сиду, и невозможно однозначно оценить качество модели.

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

Воспроизводимость и автоматизация

Весь пайплайн — от подбора гиперпараметров до прогона K-сетки с асимметричными потерями — завёрнут в Apache Airflow. Это гарантирует воспроизводимость: каждый запуск обучения задокументирован, шаги выполняются в фиксированном порядке, а новые данные не приводят к расхождению между тем, что обучалось вчера и сегодня.

Все эксперименты и логи метрик сохраняются в MLflow. Это стандартный инструмент трекинга ML-экспериментов (отслеживания параметров, метрик и артефактов моделей), который позволяет сравнивать прогоны между собой и откатываться к предыдущим версиям модели при необходимости. Связка Airflow + MLflow — осознанный выбор в пользу надёжности промышленного внедрения, а не скорости разработки.