ML модели ломаются в продакшене: виноват не алгоритм, а пайплайн данных

---

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

Независимый эксперт в области ИТ и информационной безопасности Андрей Бирюков, преподаватель и автор книг, опубликовал на Хабре подробный разбор того, почему ML модели разваливаются после деплоя. Его главный тезис: индустрия до сих пор живёт с заблуждением, что успех проекта определяется только качеством самой модели. На практике между Jupyter Notebook и работающим продуктом лежит пропасть, которую закрывает не data science, а инженерия данных.

Notebook против реального мира: в чём разрыв?

В Jupyter Notebook (среда, где data-сайентисты обучают и проверяют модели) данные статичны, чисты и загружены в память. Вы контролируете версии библиотек, порядок выполнения ячеек. Модель обучается один раз, метрика измеряется на отложенной выборке. Это, по словам Бирюкова, «стерильный мир».

В продуктивной среде всё иначе:

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

Бирюков приводит конкретный кейс. Команда обучила ML модель прогнозирования оттока клиентов телеком-оператора. Метрика ROC-AUC (показывает, насколько хорошо модель ранжирует положительные примеры выше отрицательных) составила 0.92. Модель выкатили в продакшен.

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

Исправление потребовало пересборки всего пайплайна признаков и переобучения модели.

Аргументы за: инженерия важнее алгоритма

Бирюков выделяет два системных врага любой ML модели в продакшене.

Сдвиг данных (Data Drift): распределение входных признаков меняется, но связь между признаками и целевой переменной (тем, что модель предсказывает) сохраняется. Пример из источника: модель кредитного скоринга банка обучена на клиентах Москвы и Санкт-Петербурга. После региональной экспансии в потоке появились заявки из малых городов. Распределение признака «средний доход» сместилось влево, «возраст» сместился вправо. Предсказания стали менее уверенными, доля отказов выросла. Тест Колмогорова-Смирнова (статистический метод обнаружения различий между распределениями) показал p-value для «дохода» ниже 0.01. Решение: переобучение с региональными данными и новый признак «тип населённого пункта».

Сдвиг понятия (Concept Drift): меняется сама зависимость между признаками и тем, что модель предсказывает. Пример: сеть продуктовых магазинов прогнозировала спрос на основе истории продаж, дня недели, погоды и промоакций. MAPE (средняя абсолютная процентная ошибка) держалась около 8%. В марте 2020 года началась пандемия. Признаки остались теми же, но люди перестали ходить в магазин каждый день и начали закупаться раз в неделю крупными партиями. MAPE выросла до 35% за неделю. Никакой статистический тест на входных признаках этого не поймал бы: сдвинулось само понятие «спрос». Решение: экстренное переобучение на свежих данных и добавление признака «локдаун в регионе».

Дополнительный аргумент: CI/CD (непрерывная интеграция и доставка) в классической разработке означает автоматическое тестирование кода при каждом коммите. В ML артефактов больше: код, данные, модель, конфигурация окружения. Бирюков описывает случай, когда в MLflow (платформа управления жизненным циклом ML) было настроено автоматическое сравнение новой версии модели с текущей по метрике F1. Инженер случайно обучил модель без учёта сезонности, F1 упал с 0.81 до 0.74. CI/CD заблокировал деплой, проблему обнаружили до того, как она добралась до пользователей.

Аргументы против: модель всё-таки центральна

Противники «инженерного» взгляда справедливо указывают: без сильной модели инженерия не спасёт. Если алгоритм изначально не выучил закономерность, никакой Feature Store (централизованное хранилище признаков, гарантирующее, что при обучении и при предсказании используются одни и те же данные) и пайплайн мониторинга не сделают предсказания полезными.

Кроме того, далеко не каждая команда может позволить себе полноценную MLOps-инфраструктуру. Для стартапа или небольшого отдела аналитики затраты на CI/CD для моделей, мониторинг дрифта и Feature Store могут превышать выгоду от автоматизации.

Наконец, часть проблем, которые Бирюков описывает, это не специфика ML, а стандартные ошибки при работе с данными. Утечка данных (Data Leakage, когда модель при обучении видит информацию, недоступную в момент предсказания) относится к культуре работы с данными, а не к «инженерии продакшена».

Подавляющее большинство моделей, показавших блестящие результаты в Jupyter Notebook, либо никогда не доходят до пользователя, либо деградируют в течение нескольких недель после запуска. И причина здесь кроется не в алгоритмах, а в инженерии. : Андрей Бирюков, независимый эксперт в области ИТ и ИБ

Что делать с этим прямо сейчас, по ролям?

Автору Дзена, который пишет про технологии. Кейсы из этого разбора (телеком-отток, банковский скоринг, ритейл-спрос) готовые сюжеты для контента. Тема «почему ИИ ошибается» стабильно собирает аудиторию, и теперь у вас есть конкретные примеры с российской спецификой.

Маркетологу. Если ваша компания использует ML модели для скоринга, рекомендаций или прогнозирования спроса, спросите у технической команды: как часто модель переобучается и есть ли мониторинг сдвига данных. Кампания удержания из примера Бирюкова работала хуже случайного обзвона именно потому, что никто не проверял, как модель ведёт себя через две недели.

Предпринимателю в РФ. Примеры Бирюкова напрямую из российской практики: банковский скоринг с региональной экспансией, ритейл с пандемийными сдвигами. Если вы внедряете или покупаете ML-решение, в договоре с подрядчиком должны быть прописаны не только метрики на тесте, но и условия мониторинга и переобучения после запуска.

Разбор Бирюкова фиксирует простую вещь: ML модели будут ломаться в продакшене и дальше, потому что реальный мир не стоит на месте. Выиграют те команды, которые заложат в бюджет проекта не только обучение модели, но и инфраструктуру, которая поймает деградацию до того, как бизнес заметит потери.