По данным Gartner, из пилота в эксплуатацию доходят 54% ИИ-проектов. Остальные застревают на ответственности и мониторинге, а не на обучении. Гайд по MLOps.
Содержание9 разделов
Откуда взялись 87%
Число «87% моделей машинного обучения не доходят до эксплуатации» встретится вам почти в каждой презентации на эту тему. Взялось оно из статьи VentureBeat 2019 года, где пересказана цифра, которую руководитель назвал на панельной дискуссии. Никакого исследования за этим не стоит, и методика нигде не описана. Процитируете - и рано или поздно у вас спросят источник, а его нет. Ближайшая цифра с методикой есть у Gartner: в опросе 699 организаций из пилота в эксплуатацию дошли 54% ИИ-проектов (Gartner, 2022).
Если убрать число, остаётся верное наблюдение: модели, которые не дошли до эксплуатации, почти никогда не проваливаются из-за точности. Их губит то, что за них никто не отвечает, к данным нет доступа и никому не поручено запускать их в следующем квартале. Ограничение операционное, а не техническое.
Три типичные ситуации, объясняющие провалы внедрений:
- Обучали на данных, не совпадающих с эксплуатацией. Точность в ноутбуке была высокой, в эксплуатации она заметно ниже. Модель не видела реального входа.
- За внедрение никто не отвечает. Исследователь, построивший модель, не имеет доступа к эксплуатации. У службы эксплуатации нет контекста машинного обучения. Модель месяцами лежит в ноутбуке.
- Успех измеряли по точности на отложенной выборке, а не по бизнес-показателю. Площадь под кривой выросла, бизнес-показатель не изменился, и проект списывают как очередную «AI-инициативу».
Поэтому порядок нужен обратный: сначала каркас развёртывания, потом модель.
Пять частей каркаса MLOps
До обучения постройте эти пять компонентов. Без них модель никогда не выйдет в эксплуатацию.
| Компонент | Что делает | Когда строить |
|---|---|---|
| Конвейер признаков | Считает признаки одинаково при обучении и обслуживании | До обучения |
| Реестр моделей | Версионирует, хранит и загружает веса | До первого запуска |
| Инфраструктура обслуживания | Принимает запрос, прогоняет через модель, возвращает ответ | До первого запуска |
| Мониторинг | Следит за отклонением входов и предсказаний и за точностью | До первого запуска |
| Откат | Переключается на предыдущую версию за 60 секунд | До первого запуска |
Если хотя бы одной части нет в первый день, при первой поломке внедрению не на что опереться. Постройте все пять до того, как тратить неделю на настройку гиперпараметров.
Расхождение обучения и обслуживания: сбой, который не падает
Расхождение данных обучения и обслуживания - частая причина, по которой модель, прошедшая проверку, ломается в эксплуатации: она видит разные данные при обучении и при обслуживании, потому что подготовка признаков происходит дважды - в двух конвейерах, написанных двумя командами.
Реальные примеры из разбора:
- При обучении возраст считается из даты рождения в формате месяц/день/год. В эксплуатации - в формате день/месяц/год. Половина возрастов неправильная.
- При обучении одиннадцать категорий товаров кодируются в виде вектора нулей и единиц. В эксплуатации появляется двенадцатая, и кодирование молча выдаёт нулевой вектор.
- При обучении пропуски заполняются медианой по обучающему набору. В эксплуатации - скользящей медианой за прошлый час, и распределения расходятся.
Лечится это устройством системы: один конвейер признаков работает одинаково при обучении и при обслуживании. Tecton, Feast, Hopsworks существуют именно для этого. Если команда не готова к хранилищу признаков, запасной вариант - брать обучающие данные прямо из журналов эксплуатации, а не из синтетических выборок.
Мониторинг, ловящий реальное отклонение
Без мониторинга деградация никуда не девается, её просто не видно. Модель по расписанию возвращает предсказания, ничего не падает, только предсказания хуже, чем были, и первым это обычно замечает клиент. Случай не редкий: на 32 наборах данных и четырёх типах моделей качество со временем падало в 91% пар «модель - набор данных» (Vela et al., 2022).
Три сигнала мониторинга в том порядке, в каком их стоит строить:
-
Отклонение распределения входов. Статистики признаков (среднее, дисперсия, главные категориальные значения) смещаются относительно обучающего распределения. Автоматизируется в Evidently, Whylogs, Arize.
-
Отклонение распределения предсказаний. Доли выходных классов или распределения оценок меняются без причин на входе. Часто сигнализирует о порче данных выше по конвейеру.
-
Точность по подтверждённым меткам. Когда реальные метки становятся доступны (часто с задержкой в дни-недели), предсказания сверяют с ними. Ловит тонкие проблемы, которые первые два пропускают.
Без всех трёх вы летите вслепую. У большинства команд только первые два. Сигнал точности дорогой - требует конвейера разметки, - но только он ловит дрейф концепции (concept drift), когда признаки выглядят одинаково, а связь с целью изменилась.
Ритм переобучения
Три варианта по возрастающей зрелости:
Запланированное (еженедельно или ежемесячно). Его просто настроить, но для устойчивых моделей это расточительно, а для быстро меняющихся распределений слишком медленно. Годится как отправная точка, но не как конечное состояние.
По отклонению. Следим за отклонением, переобучаем при превышении порога, проверяем, выкатываем с одобрением человека. Для большинства моделей в эксплуатации это и есть правильное конечное состояние.
Непрерывное обучение в реальном времени. Модель обновляется из эксплуатационных данных почти в реальном времени. Хорошо смотрится в докладах на конференциях, но оправдано лишь в узких задачах вроде рекомендательных систем и ранжирования рекламы. Большинству команд браться за него не стоит.
Сколько это стоит: большая часть уходит не на обучение
AWS, которая продаёт железо для инференса, пишет, что до 90% расходов на инфраструктуру для разработки и работы ML-приложений часто уходит на инференс (AWS, EC2 Inf1, 10.2026). Инженеры Google ещё в 2015 году сказали то же о трудозатратах: за быстрые победы машинного обучения платят скрытым долгом сопровождения, и живёт он в системе вокруг модели, а не в самой модели (Sculley et al., 2015).
Одержимость «стоимостью видеокарт» в 2024-2025 годах была ошибочной. Дорого обходятся инфраструктура обслуживания, цену которой задают требования к задержке, и время инженеров, которое зависит от сложности внедрения. Инструменты, сокращающие время инженеров, окупаются лучше, чем инструменты, сокращающие стоимость обучения.
План MLOps на 30 дней для первой модели в эксплуатации
Неделя 1. Постройте каркас внедрения: конвейер признаков (пакетный и в реальном времени), реестр моделей, заглушку обслуживания, которая возвращает константу, мониторинг на заглушке и проверенный путь отката. Запустите заглушку в эксплуатацию.
Неделя 2. Обучите базовую модель (логистическая регрессия или мелкое дерево). Замените заглушку. Проверьте, что эксплуатационные предсказания совпадают с предсказаниями на отложенной выборке на том же входе. Поставьте мониторинг отклонений.
Неделя 3. Запустите базовую модель на 100% реального потока запросов. Следите за отклонением, задержкой, долей ошибок. Поставьте оповещения.
Неделя 4. Теперь обучите настоящую модель. Замените ею базовую, только если она обходит базовую по бизнес-показателю, а не только по площади под кривой. Опишите процедуру отката.
К тридцатому дню у вас одна работающая модель с мониторингом, обнаружением отклонений, откатом и базовой моделью для отката. Следующие модели получают этот каркас готовым. Как считать окупаемость - в материале «Измерение окупаемости ИИ».
Что отклонять
При оценке предложений по MLOps или поставщиков отказывайтесь от следующего:
- «Платформа автоматического машинного обучения» в которой нет мониторинга и обнаружения отклонений.
- Только инструменты обучения, без обслуживания и мониторинга.
- «Точность модели» как главный показатель успеха - без бизнес-показателя.
- Обещания «развернём за дни» без имени человека, у которого есть доступ к эксплуатации.
- Поставщики, которые не могут показать своё обнаружение отклонений на реальных данных клиентов.
Итог
Машинное обучение в эксплуатации в основном состоит не из машинного обучения, а из конвейеров признаков, мониторинга, путей отката и понятной ответственности: кому звонить, когда что-то ломается. До эксплуатации доходят проекты, где такой каркас построили первым. Провалившиеся тратят три месяца на настройку модели в ноутбуке, прежде чем подумать о внедрении. Если вы можете запустить в эксплуатацию заглушку с константным предсказанием на первой неделе проекта, вы среди тех, кто дойдёт. Если команда обсуждает архитектуру модели до того, как появился каркас внедрения, - среди тех, кто застрянет.
Дальше: Интеграция ИИ в бизнес 2026 · Предсказательная аналитика, которая предсказывает.
Часто задаваемые вопросы
Почему большинство проектов машинного обучения не доходят до эксплуатации?
Три причины: модель обучалась на данных, не совпадающих с эксплуатационным распределением, и поэтому проваливается на реальном входе; за инфраструктуру развёртывания никто не отвечает, а у исследователя, построившего модель, нет доступа к эксплуатации; успех измеряли по точности на отложенной выборке, а не по бизнес-показателю, который модель должна была изменить. Решение - сначала строить каркас развёртывания, потом модель.
В чём разница между обучением и обслуживанием в MLOps?
Обучение - получение весов модели из обучающих данных, обычно как пакетная задача. Обслуживание - приём запроса, прогон через модель и возврат предсказания с задержкой меньше двухсот миллисекунд. Это разные системы с разными требованиями. Обучение оптимизирует точность; обслуживание оптимизирует задержку, стоимость и доступность. В большинстве провалившихся внедрений их путают.
Как обнаруживать отклонение модели в эксплуатации?
Три сигнала: отклонение распределения входов, когда статистики признаков смещаются относительно обучающего распределения; отклонение распределения предсказаний - доли выходных классов меняются; точность по подтверждённым меткам, когда они становятся доступны. Инструменты Evidently, Whylogs, Arize автоматизируют первые два; третий требует конвейера разметки. Если хотя бы одного сигнала нет, модель тихо стареет.
Переобучать еженедельно, ежемесячно или по отклонению?
По отклонению с ручным одобрением. Запланированное переобучение тратит вычислительные мощности на устойчивые модели и слишком медленно для быстро меняющихся распределений. Подход: следим за отклонением, запускаем переобучение при превышении порога, проверяем на отложенной выборке, человек одобряет выкат.
Что такое расхождение данных обучения и обслуживания, и почему его трудно заметить?
Расхождение возникает, когда данные, которые модель видит в эксплуатации, отличаются от тех, на которых она обучалась - обычно потому, что подготовка признаков происходит по-разному в двух конвейерах. Например, при обучении дату разбирают как UTC, а при обслуживании как местное время, или в категориальном признаке появляется категория, которой при обучении не было. Модель возвращает мусор, но не падает. Решение - общий конвейер признаков и обучающие данные, собранные из журналов эксплуатации, а не из синтетических выборок.
