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