Почему пилоты умирают: 7 инженерных причин, по которым ML не доезжает до прода

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

А потом — ничего. Модель остаётся в Jupyter-ноутбуке или на изолированном сервере. Бизнес возвращается к Excel-таблицам и ручным процессам. Через полгода проект тихо закрывают, а команда данных — уже на следующем пилоте, который, скорее всего, ждёт та же судьба.

По разным оценкам, от 60 до 85% ML-проектов в enterprise не доходят до полноценного продакшена. И проблема почти никогда не в модели. Алгоритмы, фреймворки и данные — это самая «понятная» часть. Проблема — в отсутствии инженерной, организационной и процессной инфраструктуры вокруг модели. ML-проект — это не «обучить модель», а «встроить решение в процесс и держать его живым».

Ниже — семь конкретных причин, по которым это не происходит. Не абстрактных «нужна культура данных», а инженерных — с понятными симптомами, последствиями и тем, что можно сделать иначе.

* * *

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

Кто принимает решение на основе этого числа? Менеджер по закупкам? CRM-система автоматически? Оператор колл-центра? Как это решение встраивается в ежедневную работу — через интерфейс, через уведомление, через автоматическое правило? Что меняется в реальном процессе?

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

Что с этим делать. До начала любого ML-проекта определите decision point: кто, когда и как будет использовать выход модели. Если на этот вопрос нет чёткого ответа — проект не готов к старту. Это не бюрократия, это базовая гигиена, которая экономит месяцы работы команды.

* * *

Команда данных оптимизирует AUC, F1, MAPE, NDCG — метрики, которые понятны внутри ML-сообщества и важны для валидации модели. Бизнес хочет совсем другого: «меньше списаний на складе», «выше конверсия в покупку», «быстрее обработка заявок», «меньше ручной работы».

Между этими двумя мирами — пропасть. Улучшение AUC на 2 процентных пункта может не дать ничего в деньгах. А может дать много — но никто не посчитал. В результате DS-команда показывает «мы улучшили MAPE с 18% до 14%», а финансовый директор спрашивает: «и что?» — и у обеих сторон есть основания для фрустрации.

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

Что с этим делать. До запуска проекта постройте «value model» — грубую, но честную оценку: «если модель ошибается на X% меньше, это даёт Y рублей / часов / процентов конверсии». Это же потом становится критерием go/no-go для прода. Если связь между ML-метрикой и бизнес-результатом не прослеживается — стоит вернуться к постановке задачи.

* * *

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

В проде всё иначе. Данные приходят с задержками. Поля, которые были заполнены в пилотном датасете, в реальных системах пусты в 30% случаев. Форматы меняются после обновления ERP. Появляются новые категории товаров, которых не было в трейне. Один из источников данных внезапно перестаёт отвечать на два дня. И модель, которая «летала» на пилоте, начинает выдавать мусор — или, что ещё опаснее, выдаёт правдоподобный, но систематически неверный результат.

Это не «редкий случай». Это норма. Разрыв между качеством данных в пилоте и качеством данных в проде — одна из главных причин, по которым модель деградирует сразу после внедрения.

Что с этим делать. Ещё на этапе пилота закладывайте «грязные» сценарии. Что будет, если данные не пришли вовремя? Если формат поменялся? Если 20% значений — пропуски? Если появился новый сегмент, которого не было в обучении? Это не перфекционизм — это минимальная инженерная гигиена, без которой переход в прод превращается в лотерею.

* * *

Модель запустили. DS-команда выдохнула, отметила и перешла на следующий проект. Через три месяца данные начали дрейфовать: сменился сезон, изменился ассортимент, прошла рекламная кампания, которая сдвинула поведение пользователей. Модель по-прежнему работает, но качество тихо падает — неделю за неделей, процент за процентом.

Никто не смотрит. Никто не перетренирует. Часто вообще непонятно, кто отвечает за эту модель «после запуска». DS-команда считает, что их работа закончена. IT думает, что это «чёрный ящик», в который лучше не лезть. Бизнес замечает проблему, только когда клиенты жалуются или KPI проседают — к этому моменту доверие к «этому вашему ML» уже подорвано.

Что с этим делать. У каждой модели в проде должен быть владелец — человек или команда, ответственные за мониторинг качества, периодическое переобучение и реагирование на инциденты. Это не должна быть «дополнительная нагрузка» — это часть продакшена, такая же обязательная, как SLA на доступность сервиса. Модель без владельца — это не продукт, а одноразовый эксперимент.

* * *

Даже когда мониторинг формально есть, он часто сводится к одной метрике, которую кто-то проверяет раз в месяц или реже. «AUC на тесте — 0.82, значит всё ок.» А между тем входные данные уже давно сместились, распределение предсказаний изменилось, и модель систематически перескоривает один сегмент и недоскоривает другой.

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

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

* * *

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

«После пилота» обычно не наступает. IT-команда загружена. API не согласован с внутренними стандартами. Формат данных модели не совпадает с форматом, который ожидает принимающая система. Безопасность не пропускает новый сервис в продуктивный контур. В результате между «модель работает» и «модель используется» проходят месяцы — или дистанция не преодолевается вовсе.

Это особенно болезненно в enterprise-среде, где любой новый компонент в продуктивном контуре — это согласования с ИБ, инфраструктурной командой, архитектурным комитетом. Если эти процессы не запущены параллельно с разработкой модели, они становятся блокирующим фактором, а не техническим упражнением.

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

* * *

Модель работает в проде. Но никто точно не знает, какая именно версия сейчас запущена, на каких данных она обучена, какие у неё известные ограничения и когда она последний раз перетренировывалась. Документация — пара абзацев в Confluence, написанных полгода назад. Воспроизвести обучение с нуля не может никто, потому что пайплайн зависел от конкретного ноутбука конкретного аналитика, который уже в другой компании.

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

Model governance — это не про бюрократию и не про «заполните 50-страничный документ». Это про базовый набор артефактов, который должен быть у любой модели в проде: версия и её связь с данными и кодом, описание того, что модель делает и что не делает, известные ограничения, владелец, дата последнего переобучения и план следующего.

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

* * *

Если посмотреть на эти семь причин вместе, они складываются в простую картину: модель сама по себе — это 20–30% успеха. Остальное — данные, интеграция, процессы, люди и governance. И всё это нужно закладывать не «потом», а с самого начала.

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

Discovery. До начала разработки: определяем бизнес-задачу, decision point, value model. Кто будет использовать результат, как именно и сколько это стоит в деньгах. Если связка «модель → решение → бизнес-эффект» не прослеживается — проект не стартует.

MVP. Минимальная модель плюс минимальная интеграция, чтобы проверить, что решение вообще работает в реальном процессе. Не «идеальная модель», а «достаточная модель, встроенная в достаточный процесс». Здесь же — первая проверка на «грязные» данные и нештатные сценарии.

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

Production rollout. Полная интеграция в целевую систему. Мониторинг на трёх уровнях (данные, модель, бизнес). Назначен владелец. Определены SLA. Есть rollback plan. Есть паспорт модели. Есть playbook на случай деградации.

Operations. Регулярное переобучение, drift monitoring, incident response, периодический пересмотр. Модель — это не «запустили и забыли», а живой компонент системы, который требует ухода, как любой другой продуктивный сервис.

Ключевая идея: каждый этап имеет quality gates — критерии, которые должны быть выполнены для перехода на следующий. Если критерии не выполнены — проект не двигается дальше. Это не замедляет, а ускоряет: лучше остановиться на discovery и переформулировать задачу, чем через полгода обнаружить, что модель в проде никому не нужна.

* * *

Когда компания говорит «мы внедряем ML», это почти всегда звучит как «мы обучаем модель». На самом деле внедрение ML — это строительство инженерной системы, в которой модель — важный, но не единственный и даже не главный компонент.

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

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

Первое: перед следующим ML-проектом определите decision point до начала разработки. Кто будет использовать модель, как именно и что конкретно изменится в процессе. Если ответа нет — проект не готов.

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

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

Модель — это гипотеза, записанная в коде. Чтобы она превратилась в работающую систему, нужны данные, интеграция, процессы, люди и governance. Все семь причин, которые мы разобрали, — это не «теоретические риски», а ежедневная реальность enterprise AI. И хорошая новость в том, что каждую из них можно предотвратить — не гениальным алгоритмом, а инженерной дисциплиной и здравым смыслом.