Единицы
1. Искусственный интеллект в машинном обучении: роль, границы, проверка и ответственность 2. Конвейер данных: сбор, очистка, маркировка и управление версиями 3. Обучение и оценка модели: точные метрики, честный бенчмаркинг 4. Заявление на получение степени LLM: ответы на основе ваших собственных данных с помощью RAG 5. Приложение LLM: агенты, инструменты и безопасная автоматизация 6. Основа тонкой настройки: когда, как и с каким риском 7. MLOps и развертывание: перемещение модели из лаборатории в производство 8. Оценка и мониторинг: знание того, что модель действительно делает в производстве 9. Безопасность и конфиденциальность: защита систем искусственного интеллекта 10. Предвзятость, этика и стоимость: ответственная и устойчивая разработка искусственного интеллекта 11. Воспроизводимость и сквозной проект: объединение всего
Единица 7 / 11

MLOps и развертывание: перемещение модели из лаборатории в производство

Прибыль:

  • Способность распознавать особые проблемы машинного обучения, связанные с трио и пакетом «код-данные-модель», и представлять модель онлайн или в пакетном режиме в соответствии с потребностями бизнеса.
  • Возможность реализовать шаблоны постепенного и откатного развертывания (теневое, канареечное, A/B, откат) и добавить проверенный план отката к каждому развертыванию.
  • Возможность отслеживать связь данных, кода и метрики модели, запущенной в производство, с помощью CI/CD с пороговым значением оценки и реестра моделей.

Получить модель, обеспечивающую точность 95% в ноутбуке, — это только половина дела. Другая половина (часто самая сложная) — предоставить эту модель реальным пользователям надежным, масштабируемым и удобным в обслуживании способом. MLOps (Операции машинного обучения: дисциплина внедрения, эксплуатации и поддержки моделей ML в производство) сочетает в себе методы разработки программного обеспечения DevOps с уникальными задачами ML. В этом разделе мы рассмотрим этапы перевода модели в производство и то, как искусственный интеллект помогает в этом процессе.

Чем ML отличается от обычного программного обеспечения?

В обычном программном обеспечении поведение заложено в коде; Если код не меняется, поведение не меняется. В ML поведение зависит как от кода, данных, так и от модели. Эти три аспекта создают дополнительные проблемы MLOps:

  • Дрейф данных: данные в рабочей среде со временем отдаляются от данных в процессе обучения; модель устаревает.
  • Вам необходимо версионировать три вещи: код, данные и модель — все три.
  • Тихий сбой: модель может потерпеть неудачу без сбоя и ошибок, просто выдавая неверные прогнозы. Чтобы выявить это, требуется мониторинг.

Вот почему существует большая разница между «рабочей моделью» и «готовой к производству моделью».

Упаковка и презентация модели

Первым шагом при запуске модели в производство является ее упаковка: файл модели, необходимые библиотеки, код предварительной обработки и информация о версии вместе в воспроизводимое целое. Контейнеризация (например, Docker: помещение приложения в изолированный блок со всеми его зависимостями) здесь является стандартной; Это устраняет проблему «на моей машине все работало».

Два основных шаблона обслуживания модели:

  • Онлайн/в режиме реального времени (онлайн): модель использует API, возвращая мгновенный прогноз для каждого входящего запроса. Низкая задержка имеет решающее значение.
  • Пакетная обработка: модель периодически обрабатывает большие наборы данных (например, ночью генерирует оценки для всех клиентов). Задержка не имеет значения, важна эффективность.

Какой из них правильный, зависит от потребностей бизнеса: мгновенная рекомендация онлайн, ежемесячная пакетная оценка рисков.

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

Стратегии безопасного распространения

Открытие новой модели напрямую для всего трафика рискованно; Если это неправильно, это затронет всех. Безопасные схемы распространения:

  • Теневое развертывание: новая модель получает производственный трафик, но ее прогнозы не отображаются пользователю, а только записываются. Ее сравнивают со старой моделью, чтобы увидеть, безопасна ли она в реальных данных.
  • Канарское развертывание: новая модель сначала развертывается для небольшого процента трафика (например, 5%); Если проблем нет, ее увеличивают постепенно.
  • A/B-тестирование. Реальному пользователю параллельно представляются две модели и сравниваются бизнес-показатели (конверсии, клики).
  • Откат: Возможность быстрого возврата к старой версии, если новая модель окажется плохой. Каждое развертывание должно иметь план отката.
Внимание! Развертывание без плана отката не является завершенным. Возможность вернуться к старой версии в течение нескольких минут защищает пользователя, когда новая модель ведет себя неожиданно в производстве. Проверьте это перед развертыванием.

Слабый подход/Сильный подход

Слабое: «Модель хорошо прошла тестирование, мы запустили ее в эксплуатацию, открыли ее всем».

Гючлю: «Мы поместили модель в контейнер, обозначили ее как версию. Сначала мы запускали ее в теневом режиме с производственным трафиком в течение 3 дней, сравнивая прогнозы со старой моделью — отклонение было приемлемым. Затем мы открыли ее с 5% canary, отслеживали показатели пропускной способности и задержки. Когда проблем не было, мы постепенно увеличили ее до 100%. Мы заранее протестировали команду отката».

Разница: сильный подход является постепенным, размеренным и обратимым. Риск ограничен на каждом этапе.

CI/CD и автоматизация

CI/CD (непрерывная интеграция/непрерывное развертывание: конвейер автоматического тестирования и выпуска изменений кода) в ML охватывает не только код, но также этапы данных и модели. Хороший конвейер ML CI/CD: запускает тесты при изменении кода, выполняет проверку данных, переобучает модель (при необходимости), проверяет пороговые значения оценки и продвигает развертывание только в том случае, если пороговые значения соблюдаются. Принцип «обучение автоматическое, развертывание пороговое» предотвращает незаметное попадание плохой модели в производство.

ИИ очень полезен при настройке этих конвейеров: написании черновиков файлов конфигурации (YAML), тестовых примеров, сценариев развертывания. Но вы сами определяете пороги распределения (любая метрика превышает опубликованное значение) и политику отката; это решения о бизнес-рисках.

Инфраструктура воспроизводимости

Чтобы воспроизвести поведение модели в производстве, используется реестр моделей: запись, в которой хранится, какая модель была обучена с использованием каких данных и кода и какие метрики она получила. Для каждой производственной модели необходимо отслеживать следующее: версию обучающих данных, версию кода (git commit), гиперпараметры, оценки оценки и дату развертывания. Когда возникает проблема, вы должны быть в состоянии ответить на вопрос: «Какая модель дала этот прогноз, с какими данными?» в течение нескольких минут. Мы углубим это в модуле 11.

три мини-кейса

Случай 1. Проблема, связанная с распределением теней. Рекомендательная модель превзошла старую в тестировании. Было обнаружено, что запуск его с производственным трафиком в теневом режиме дает очень плохие рекомендации для определенного сегмента пользователей (новых пользователей) — тестовые данные были недостаточно репрезентативными для этого сегмента. Модель была исправлена, но не отображалась пользователю. Если бы его открыли напрямую, новый пользовательский интерфейс был бы нарушен.

Случай 2 – Безотзывное распределение. Команда внедрила новую модель ценообразования для всего трафика без планов отката. Модель неожиданно стоила очень дешево на некоторые товары. Возврат к старой версии занял несколько часов, поскольку процесс не был готов. Произошла серьезная потеря дохода. Впоследствии к каждому развертыванию было добавлено обязательное тестирование отката.

Случай 3. Тихий дрейф данных. Схема мошенничества проявлялась месяцами без каких-либо ошибок. Но тактика мошенников изменилась (дрейф данных) и отзыв модели незаметно упал. Никто не заметил, потому что не было мониторинга. После того как была создана группа по мониторингу распределения прогнозов, дрейф стал заметен рано. Мы рассмотрим мониторинг в разделе 8.

Копируемые шаблоны

Напишите черновой план развертывания этой модели. Модель: [что он делает], использование: [онлайн или пакетный?] Должно включать: 1) Упаковка (контейнер, управление версиями) 2) Стратегию поэтапного развертывания (теневое/canary/A-B) и почему 3) Метрики для отслеживания (бизнес + технические + задержка) 4) План отката и способы тестирования 5) Пороги развертывания (какой показатель должен превышать какое значение)

Проверьте этот конвейер ML CI/CD: 1) Выполняется ли проверка данных? 2) Может ли развертывание продолжиться без сохранения порога оценки (не должно ли это быть)? 3) Автоматический ли откат? 4) Отслеживаются ли данные + код + метрики в реестре модели? Конфигурация Pline: [config]

Помогите определиться, подойдет ли для этой модели онлайн-презентация или пакетная презентация. Как долго будет использоваться результат: [мгновенный/минута/час/день]Ожидаемый объем запроса: [число]Существует ли ограничение задержки: [мс]Какой из них вы бы порекомендовали с точки зрения стоимости и сложности и почему?

Напишите процедуру отката для этой модели. – Какой показатель/порог вызывает низкую производительность? – Каковы шаги отката? – Сколько времени должен занять откат (цель)? – Как протестировать эту процедуру перед началом производства?

Таблица шаблонов представления

критерий

Онлайн (в реальном времени)

Пакетный

задержка

Критический (мс)

незначительный

Использование

Требуется мгновенный ответ

Периодический счет

Стоимость

высокий

низкий

сложность

высокий

низкий

пример

Живая рекомендация, лохотрон

Ежемесячная оценка риска

Распространенные ошибки

  • Распространение без плана поиска. Неправильная модель бьет по всему пользователю.
  • Открытие сразу 100% трафика. Ограничьте риск с помощью шахматного распределения.
  • Не установление мониторинга. Модель выдает ошибки молча, без ошибок.
  • Избыточная презентация в реальном времени. Хотя пакетной обработки достаточно, стоимость и сложность растут.
  • Не связывать версии кода данных модели. Вы не можете воспроизвести проблему.
  • Автоматический выпуск без порога распространения. Плохая модель пробирается молча.

В заключение

Перемещение модели в производство — это другая и зачастую более сложная инженерная задача, чем ее обучение. ML требует дополнительной дисциплины, поскольку оно зависит от трио «код-данные-модель»: упаковка и управление версиями, шаблон доставки (онлайн/пакетный), соответствующий потребностям бизнеса, постепенное и обратимое развертывание, CI/CD с пороговым управлением и регистрация модели. Искусственный интеллект — мощный помощник в создании кода и конфигурации этой инфраструктуры; но пороги распределения, политика возврата и решения о рисках остаются за вами. Распространение без плана отката не является полным.

Задача приложения

Контейнеризируйте (Docker) модель и пометьте ее версию. Решите, будете ли вы предлагать онлайн или пакетное предложение, исходя из потребностей вашего бизнеса, и напишите обоснование. Задокументируйте план поэтапного развертывания (теневое или канареечное) и проверенную процедуру отката. Обязательно запишите версию данных, фиксацию кода и оценки оценки в реестре модели.

контрольный список

  • [ ] Модель упакована и имеет версии (контейнер + этикетка).
  • [ ] Форма представления (онлайн/пакетная) была выбрана в соответствии с потребностями бизнеса.
  • [ ] Реализована стратегия поэтапного развертывания (теневое/канарейское).
  • [ ] Процедура отката написана и протестирована.
  • [ ] CI/CD не продвигает развертывание до достижения порога оценки.
  • [ ] Реестр модели содержит ссылку данные+код+метрика.