m@ksim.pro
К списку статей
ИИ 3 мин чтения

Машинное обучение в продакшене: разрыв между пилотом и масштабом

Почему ML-пилоты часто не превращаются в рабочие системы, и что нужно сделать иначе с самого начала.

В последние пару лет я наблюдаю один и тот же паттерн. Компания проводит пилотный проект по машинному обучению - предиктивная аналитика, рекомендательная система, классификатор. Пилот показывает хорошие результаты в тестовой среде. Руководство впечатлено. Принимается решение масштабировать.

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

Почему пилот - это не маленький продакшн

Пилотный проект по ML решает конкретную исследовательскую задачу: можно ли вообще построить работающую модель для этой задачи, с этими данными, с этим уровнем точности? Это важный вопрос. Но ответ "да" не означает, что система готова к промышленной эксплуатации.

В продакшене модель - это не конечный продукт. Это компонент в системе, которая должна:

  • получать свежие данные регулярно и в предсказуемом формате;
  • обнаруживать деградацию качества модели (data drift, concept drift);
  • переобучаться по расписанию или по триггеру;
  • иметь версионирование и возможность откатиться на предыдущую версию;
  • логировать предсказания и результаты для последующего анализа;
  • обрабатывать аномалии во входных данных, а не падать.

Ничего из этого не нужно в пилоте. Всё это нужно в продакшене.

Откуда берётся разрыв

Главная причина разрыва - это то, что пилот и продуктивное решение строятся с разными целями и часто разными людьми.

Data scientist в пилоте оптимизирует метрику модели. Он работает с Jupyter ноутбуками, статическими наборами данных, локальной средой. Его цель - показать, что решение возможно.

Переход в продакшен требует другого мышления и других компетенций: инженерии данных, DevOps, мониторинга, поддержки. В компаниях, которые не думали об этом заранее, получается ситуация, когда ноутбук data scientist становится "production системой" - без контроля версий, без мониторинга, без процессов.

Что нужно спроектировать с самого начала

Если вы запускаете ML-пилот с намерением довести его до продакшена, несколько вещей стоит решить в самом начале:

Инфраструктура данных. Откуда берутся данные для обучения и для предсказаний? Это автоматизированный пайплайн или ручная выгрузка? Как будет выглядеть этот процесс через год?

Ответственность за качество модели. Кто следит за тем, что модель продолжает работать правильно? Какие метрики качества отслеживаются и кем?

Процесс переобучения. Как часто, кем и при каких условиях модель обновляется? Кто принимает решение о деплое новой версии?

Интеграция. Как результаты модели попадают в бизнес-процессы? Кто принимает решение на основе предсказаний и как?

Вопросы до запуска пилота

  1. Есть ли у нас план того, кто будет поддерживать эту систему, если пилот окажется успешным?
  2. Есть ли у нас инфраструктура для автоматизированной подачи данных в модель - или мы рассчитываем на ручные выгрузки?
  3. Кто будет владельцем системы со стороны бизнеса - не ИТ, а именно бизнеса?
  4. Как мы узнаем, что модель деградировала - что является сигналом, и кто его увидит?
  5. Какова цена ошибки модели в этом конкретном применении - и как мы обрабатываем плохие предсказания?

Хорошо построенный пилот - это не просто хорошая модель. Это пилот, который отвечает на все эти вопросы ещё до того, как принято решение о масштабировании.

К списку статей
Контакт

Если эта статья отозвалась - напишите. Я отвечаю лично.

Telegram