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

Модель – это код плюс данные плюс веса

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

Практически это значит: веса и препроцессинг лежат в системе хранения с неизменяемыми тегами, обучающие выборки фиксируются хешем и версией, а сборка артефакта проходит через CI так же, как обычный сервис. Для госсектора добавляется требование к стеку: ориентир на реестр отечественного ПО и открытые библиотеки без лицензионных рисков. Мы писали об этом в материале про приоритет российского софта в закупках – на ML-проектах это касается не только СУБД, но и среды исполнения моделей.

Данные дрейфуют, и модель тихо деградирует

Код после деплоя не меняется сам. Модель – меняется, точнее меняется мир вокруг неё. Распределение входных данных уезжает от обучающего: появляются новые категории клиентов, меняется сезонность, поставщик правит формат выгрузки. Метрика на тесте по-прежнему 0.92, а в бою модель уже месяц ошибается, и никто не знает.

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

Откат, контроль доступа и канал поставки

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

Отдельный вопрос – безопасность канала, по которому модель и зависимости попадают в контур. Атака через цепочку поставок, как в случае NotPetya, бьёт ровно по слабому звену: обновление, которому слепо доверяют. Артефакты моделей и пакеты ML-стека требуют тех же проверок целостности и подписей, что и остальной код. И последнее: не путайте инженерную зрелость с маркетингом. Реальная ценность ML-проекта – в работающем процессе эксплуатации, а не в громком названии технологии. Эту трезвость мы уже разбирали на примере хайпа вокруг ICO.

Вывод

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