Разрыв между ML-экспериментом и производственной системой
Почему машинное обучение в jupyter-ноутбуке и машинное обучение в работающем продукте - это разные задачи с разными требованиями.
Компании, которые начинают работать с машинным обучением, проходят через предсказуемый сценарий. Нанимается специалист по данным или привлекается подрядчик. Проводится эксперимент: берутся исторические данные, строится модель, модель показывает хорошие результаты на тестовой выборке. Все довольны.
Потом начинается этап "а теперь запустим это в работу" - и выясняется, что от эксперимента до работающей системы дистанция значительно длиннее, чем казалось.
Я видел этот сценарий достаточно часто, чтобы относиться к нему не как к ошибке конкретной команды, а как к системной проблеме в том, как организации понимают ML-проекты.
В чём разница между экспериментом и системой
Эксперимент по машинному обучению отвечает на вопрос: "Можно ли в принципе решить эту задачу с помощью ML, и насколько хорошо?" Это ценный вопрос. Ответ на него - необходимое, но недостаточное условие для продукта.
Производственная система отвечает на другой набор вопросов:
- Как модель будет получать новые данные в реальном времени или по расписанию?
- Как отслеживать, что качество предсказаний не деградирует со временем?
- Что происходит, когда модель ошибается - кто замечает и что делает?
- Как обновлять модель при изменении данных или задачи?
- Как система ведёт себя при нагрузке, недоступности источника данных, аномальных входных значениях?
Ни один из этих вопросов не стоит на этапе эксперимента. Все они стоят в полный рост при эксплуатации.
Три типичных разрыва
Разрыв в данных. Эксперимент проводился на исторической выгрузке - чистой, подготовленной, без пропусков. В продакшене данные приходят из живых систем: с задержками, с иногда пропущенными полями, с форматами, которые меняются без предупреждения. Модель, обученная на "идеальных" данных, может заметно хуже работать на реальном потоке.
Разрыв в мониторинге. На этапе эксперимента качество модели измеряется один раз - на тестовой выборке. В продакшене данные меняются, поведение пользователей меняется, бизнес-условия меняются. Модель, которая работала хорошо полгода назад, может тихо деградировать - и никто не узнает, пока это не станет заметно по бизнес-метрикам.
Разрыв в ответственности. Эксперимент сделан - кто отвечает за систему в продакшене? Специалист по данным написал модель, но у него нет опыта эксплуатации. Разработчики развернули приложение, но не понимают логику модели. Ops-команда поддерживает инфраструктуру, но не знает, что считать нормальным поведением для этой системы.
Что это значит для владельца продукта
ML-проект нельзя оценивать по результатам эксперимента. Эксперимент - это исследование. Продукт - это отдельная работа.
При оценке бюджета и сроков ML-проекта я рекомендую закладывать три фазы явно: исследование (может ли это работать), инженерия (как это будет работать в продакшене) и эксплуатация (как это будет поддерживаться и улучшаться). Обычно на практике закладывается только первая.
Вопросы для оценки зрелости проекта
Если вам показывают результаты ML-эксперимента и предлагают запустить в продакшен, несколько вопросов помогут понять, насколько серьёзно проработана инженерная часть:
- Как модель будет получать данные для предсказаний - откуда и в каком формате?
- Как будет отслеживаться качество предсказаний после запуска?
- Кто будет отвечать за систему в случае проблем?
- Что произойдёт, если источник данных временно недоступен?
- Когда и как планируется переобучение модели?
Если уверенных ответов нет - проект находится в стадии эксперимента, а не в стадии готовности к запуску.