Создание лучших систем машинного обучения. Глава 4. Развертывание модели и дальнейшие шаги.

Мастерство в создании лучших систем машинного обучения Глава 4 - Развертывание модели и дальнейшие шаги.

О развертывании, мониторинге, сбоях в распределении данных, обновлениях модели и тестировании в производстве.

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

Когда проект МО подходит к этапу производства, в него вовлекается все больше людей: бэкенд-инженеры, фронтенд-инженеры, инженеры данных, DevOps-инженеры, инженеры инфраструктуры…

Они выбирают хранилища данных, вводят рабочие процессы и конвейеры, интегрируют сервис в кодовую базу бэкенда и пользовательский интерфейс, автоматизируют релизы, создают резервные копии и откаты, выбирают вычислительные инстанции, настраивают мониторинг и уведомления… Сегодня, буквально никто не ожидает, что ученый-практик / инженер МО сделает все самостоятельно. Даже в маленьком стартапе люди специализируются до некоторой степени.

“Почему ученому-практику / инженеру МО надо знать о производстве?” — вы можете спросить.

• API доступа к данным через таблицы Data Lake без сложностей
• Анализ социальных сетей с помощью NetworkX Предисловие
• Что, если мы могли бы легко объяснить чрезмерно сложные модели?

Вот мой ответ:

Наличие модели в производстве не означает, что мы закончили все задачи, связанные с МО. Ха! Далеко не так. Теперь приходится решать целый ряд новых вызовов: как оценить модель в производстве и контролировать, чтобы ее точность оставалась приемлемой, как обнаруживать изменения в распределении данных и справляться с ними, с какой периодичностью переобучать модель и как убедиться, что новая обученная модель лучше предыдущей. Есть способы, и мы собираемся их подробно обсудить.

В этой статье я специально сосредоточусь только на темах МО и не буду касаться многих инженерных концепций или обсуждать их поверхностно — чтобы сделать ее понятной для людей с разным уровнем опыта.

Это завершение серии статей «Построение лучших систем МО». Цель серии — помочь вам овладеть искусством, наукой и (иногда) магией разработки и создания систем машинного обучения. В предыдущих главах мы уже обсудили планирование проекта и его бизнес-ценность (Глава 1); сбор, разметку и проверку данных (Глава 2); разработку модели, отслеживание экспериментов и оффлайн-оценку… (Глава 3). Если вы пропустили предыдущие статьи, рекомендую прочитать их перед или после этой.

Развертывание

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

1. Должна ли модель возвращать прогнозы в реальном времени?
2. Может ли модель быть развернута в облаке?

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

Реальное время vs. групповой вывод

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

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

Запуск реального времени вывода значительно сложнее и дороже, чем групповой вывод. Это связано с тем, что модель должна быть всегда доступной и возвращать прогнозы с низкой задержкой. Это требует умной инфраструктуры и настройки мониторинга, которая может быть уникальной даже для разных проектов в одной компании. Поэтому, если мгновенное предсказание не критично для бизнеса, придерживайтесь группового вывода и будьте счастливы.

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

Для получения более подробной информации о реальном времени и пакетном выводе, ознакомьтесь с этими статьями: – Развертывание моделей машинного обучения в производственных средах от Microsoft – Пакетный вывод против Интернет-вывода от Луиджи Патруно

Облачные вычисления против вычислений на устройстве

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

Стриминговые сервисы, такие как Netflix и YouTube, обычно работают со своими рекомендательными системами в облаке. Их приложения и веб-сайты отправляют пользовательские данные на серверы для получения рекомендаций. Облачные вычисления относительно легко настраиваются, и вы можете масштабировать вычислительные ресурсы практически без ограничений (или, по крайней мере, до тех пор, пока это экономически разумно). Однако облачная инфраструктура сильно зависит от стабильного подключения к Интернету, и чувствительные пользовательские данные не должны передаваться через Интернет.

Вычисления на устройстве разрабатываются для преодоления ограничений облачных вычислений и способны работать там, где облачные вычисления не могут. Система самокат Aipower работает на самокате, поэтому она может работать быстро даже без стабильного интернет-подключения. Системы аутентификации смартфонов (например, FaceID на iPhone) работают на смартфонах, потому что передача чувствительных пользовательских данных через Интернет не является хорошей идеей, и пользователи должны иметь возможность разблокировать свои телефоны без подключения к Интернету. Однако для эффективной работы вычисления на устройстве необходимо, чтобы устройство было достаточно мощным, или, в качестве альтернативы, модель должна быть легкой и быстрой. Это привело к методам сжатия модели, таким как низкоранговое приближение, усвоение знаний, обрезка и квантование. Если вы хотите узнать больше о сжатии модели, вот отличное место, чтобы начать: – Потрясающие методы сжатия модели машинного обучения.

Для более подробного изучения облачных и устройственных вычислений прочтите эти статьи: – В чем разница между вычислениями устройств и облачными вычислениями? от NVIDIA – Вычисления на устройствах против облачных вычислений: основные различия от Муника Наранг

Простое развертывание и демо

“Производство – это спектр. Для некоторых команд производство означает создание красивых графиков на основе результатов работы в блокноте, чтобы показать команде бизнеса. Для других команд производство означает поддержание работы ваших моделей для миллионов пользователей каждый день.” Чип Хуен, Почему специалистам по обработке данных не нужно знать Kubernetes

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

Однако иногда вам все-таки придется развернуть систему в одиночку. Возможно, вы работаете над собственным или исследовательским проектом и хотите создать демо. Возможно, вы являетесь первым специалистом по обработке данных/машинному обучению в компании, и вам нужно принести некоторую деловую ценность, прежде чем компания решит масштабировать команду по обработке данных. Возможно, все ваши коллеги настолько заняты своими задачами, что вы задаете себе вопрос, проще ли вам развернуть систему самостоятельно, не дожидаясь поддержки. Вы не первый и, безусловно, не последний, кто сталкивается с такими трудностями, и существуют решения, которые помогут вам.

Для развертывания модели вам понадобится сервер (экземпляр), на котором будет работать модель, API для взаимодействия с моделью (отправлять входные данные, получать прогнозы) и (по желанию) пользовательский интерфейс для приема входных данных от пользователей и отображения им прогнозов.

Google Colab – это доработанный блокнот Jupyter. Это отличный инструмент для создания демонстраций, которыми можно поделиться. Его использование не требует установки специального программного обеспечения от пользователей, он предлагает бесплатные серверы с графическим процессором для выполнения кода, и вы можете легко настроить его для приема любого ввода от пользователей (текстовые файлы, изображения, видео). Он очень популярен среди студентов и исследователей в области машинного обучения (вот как исследователи DeepMind используют его). Если вас интересует узнать больше о Google Colab, начните здесь.

FastAPI – это фреймворк для создания API на языке Python. Вы, возможно, слышали о Flask, FastAPI похож на него, но проще в написании кода, более специализирован под API и работает быстрее. Для получения более подробной информации ознакомьтесь с официальной документацией. Для практических примеров прочитайте статью APIs for Model Serving от Goku Mohandas.

Streamlit – это простой инструмент для создания веб-приложений. Он действительно прост в использовании. И приложения оказываются красивыми и интерактивными – с изображениями, графиками, окнами ввода, кнопками, ползунками… Streamlit предлагает Community Cloud, где вы можете бесплатно публиковать свои приложения. Чтобы начать, ознакомьтесь с официальным руководством.

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

Если вы хотите узнать больше, вот ресурсы для ознакомления: – Развертывание ваших проектов масштаба таких, что это практически ничто от Alex Olivier – Развертывание моделей для вывода от Amazon – Развертывание модели на конечную точку от Google

Мониторинг

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

Технически, мониторинг означает сбор логов, вычисление метрик на их основе, отображение этих метрик на панелях инструментов, таких как Grafana, а также настройку оповещений, когда метрики выходят за пределы ожидаемых диапазонов.

Какие метрики следует мониторить? Поскольку система машинного обучения является подклассом программной системы, начните с операционных метрик. Примеры таких метрик: использование процессора / графического процессора, объем памяти и дискового пространства машины; количество запросов, отправленных в приложение, и время отклика, коэффициент ошибок; сетевое подключение. Чтобы более детально изучить мониторинг операционных метрик, обратитесь к статье Введение в метрики, мониторинг и оповещение от Justin Ellingwood.

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

Точность – самая важная вещь, на которую мы обращаем внимание. Это означает, что модель может продолжать выдавать предсказания, но эти предсказания могут быть полностью ошибочными, и вы не поймете это, пока не оцените модель. Если вам повезло работать в области, где естественные метки быстро становятся доступными (как в системах рекомендаций), просто собирайте эти метки по мере их получения, оценивайте модель и продолжайте этот процесс. Однако во многих областях метки могут приходить либо через длительное время, либо вообще не приходить. В таких случаях полезно мониторить что-то, что может косвенно указывать на потенциальное снижение точности.

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

Для автоматического обнаружения сдвига в данных (это также называется «сдвиг распределения данных») непрерывно мониторьте входы и выходы модели. Входы в модель должны быть согласованы с использованными во время обучения; для табличных данных это означает, что имена столбцов, а также среднее значение и дисперсия признаков должны быть одинаковыми. Также полезно отслеживать распределение предсказаний модели. В задачах классификации, например, вы можете отслеживать долю предсказаний для каждого класса. Если происходит заметное изменение, например, если модель, которая ранее классифицировала 5% экземпляров как Класс А, теперь классифицирует 20% таких экземпляров, это явный признак того, что что-то произошло. Чтобы узнать больше о сдвиге в данных, ознакомьтесь с этим отличным постом от Чип Хуена: Data Distribution Shifts and Monitoring.

О мониторинге есть еще многое, о чем стоит сказать, но мы должны продолжить. Если вам нужно больше информации, вы можете прочитать эти посты:- Monitoring Machine Learning Systems от Гоку Мохандаса- Полное руководство о том, как мониторить ваши модели в производстве от Стефана Оладеле

Обновление модели

Если вы развернули модель в производство и ничего с ней не делаете, ее точность с течением времени уменьшается. В большинстве случаев это объясняется сдвигами в распределении данных. Входные данные могут меняться форматом. Поведение пользователей постоянно меняется без весомых причин. Эпидемии, кризисы и войны могут внезапно произойти и нарушить все правила и предположения, которые ранее работали. «Изменение – это единственная постоянная вещь». – Гераклит.

Вот почему производственные модели должны регулярно обновляться. Существуют два типа обновлений: обновление модели и обновление данных. Во время обновления модели изменяется алгоритм или стратегия обучения. Обновление модели не требуется проводить регулярно, обычно это делается по мере необходимости: при изменении бизнес-задачи, обнаружении ошибки или наличии свободного времени для исследований. В отличие от этого, обновление данных происходит, когда на тех же данных обучается тот же алгоритм. Регулярное обновление данных – обязательное условие для любой системы машинного обучения.

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

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

Как только инфраструктура настроена, частота обновлений – это всего лишь значение, которое нужно настроить в конфигурационном файле. Как часто модель должна обновляться новыми данными? Ответ: так часто, как это возможно и экономически разумно. Если увеличение частоты обновлений приносит больше ценности, чем затраты, то определенно следует увеличить частоту. Однако в некоторых сценариях обучение каждый час может быть невозможным, даже если это было бы очень прибыльно. Например, если модель зависит от аннотаций человека, этот процесс может стать узким местом.

Обучать с нуля или выполнять тонкую настройку только на новых данных? Это не бинарное решение, а скорее смесь обоих подходов. Частое выполнение тонкой настройки модели имеет смысл, поскольку это более экономически эффективно и быстрее, чем обучение с нуля. Однако иногда необходимо также обучать с нуля. Важно понимать, что тонкая настройка в первую очередь является оптимизацией стоимости и времени. Обычно компании начинают с простого подхода обучения с нуля в начале проекта и внедряют тонкую настройку по мере расширения и развития проекта.

Чтобы узнать больше о обновлениях моделей, ознакомьтесь с этим постом: Переобучать или нет? Давайте аналитически рассмотрим обновления моделей машинного обучения от Эмели Драл и др.

Тестирование в производстве

Перед развертыванием модели в производство ее необходимо тщательно оценить. Мы уже обсуждали оценку до развертывания (офлайн оценка) в предыдущем посте (см. раздел «Оценка модели»). Однако вы никогда не знаете, как модель будет работать в производстве, пока ее не развернете. Вот почему возникло тестирование в производстве, также называемое онлайн-оценкой.

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

A/B-тестирование является самым популярным подходом в отрасли. При этом методе трафик случайным образом делится между существующими и новыми моделями в определенной пропорции. Существующие и новые модели дают прогнозы для реальных пользователей, прогнозы сохраняются и затем тщательно проверяются. Полезно сравнивать не только точность модели, но и некоторые бизнес-метрики, такие как конверсия или выручка, которые иногда могут быть отрицательно коррелированы с точностью.

A/B-тестирование сильно зависит от статистического гипотезного тестирования. Если вы хотите узнать больше об этом, вот пост для вас: A/B-тестирование: полное руководство по статистическому тестированию, автор Франческо Казаленьо. Для инженерной реализации A/B-тестов обратитесь к шаблону онлайн A/B-тестов.

Теневой релиз – самый безопасный способ тестирования модели. Идея заключается в том, чтобы отправлять весь трафик на существующую модель и возвратить ее прогнозы конечному пользователю обычным способом, и в то же время отправлять весь трафик на новую (теневую) модель. Прогнозы теневой модели не используются нигде, они сохраняются только для будущего анализа.

Канареечная реализация. Вы можете представить ее как “динамическое” A/B-тестирование. Новая модель развертывается параллельно с существующей. Вначале только малая часть трафика направляется на новую модель, например, 1%; остальные 99% обрабатываются существующей моделью. Если новая модель показывает достаточно хорошие результаты, ее доля трафика постепенно увеличивается и снова оценивается, затем увеличивается и оценивается, пока весь трафик не будет обрабатываться новой моделью. Если на каком-то этапе новая модель не показывает хороших результатов, она удаляется из продакшена и весь трафик направляется обратно на существующую модель.

Здесь есть пост, который немного раскрывает эту тему: Теневой выпуск против релиза в стиле канареек моделей машинного обучения, автор Бартош Микульский.

Заключение

В этой главе мы узнали о целом ряде вызовов, возникающих после развертывания модели в производство. Операционные и связанные с машинным обучением метрики модели должны быть непрерывно отслеживаемы, чтобы быстро обнаруживать и исправлять ошибки, если они возникают. Модель должна регулярно обучаться на более новых данных, поскольку ее точность со временем снижается прежде всего из-за изменения распределения данных. Мы обсудили высокоуровневые решения, которые необходимо принять перед развертыванием модели – мгновенный или пакетный вывод и облачные или реберные вычисления, каждое из них имеет свои преимущества и ограничения. Мы рассмотрели инструменты для простого развертывания и демонстрации, когда в редких случаях вам придется делать это самостоятельно. Мы узнали, что модель должна быть оценена в производственной среде, в дополнение к оффлайн-оценкам на статических наборах данных. Вы никогда не знаете, как будет работать модель в производстве, пока вы ее действительно не выпустите. Эта проблема породила «безопасные» и контролируемые тесты в производстве – A/B-тесты, теневые развертывания и канареек.

Это также была последняя глава серии «Построение лучших систем машинного обучения». Если вы со мной с самого начала, вы теперь знаете, что система машинного обучения – это гораздо больше, чем просто модный алгоритм. Я искренне надеюсь, что эта серия была полезной, расширила ваши горизонты и научила вас создавать лучшие системы машинного обучения.

Спасибо за чтение!

В случае, если вы пропустили предыдущие главы, вот полный список:

Построение лучших систем машинного обучения. Глава 1: Каждый проект должен начинаться с плана.

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

towardsdatascience.com

Построение лучших ML-систем. Глава 2: Приручение Хаоса Данных.

О дата-центричном AI, обучающих данных, маркировке и очистке данных, синтетических данных и немного Data Engineering и…

towardsdatascience.com

Построение лучших ML-систем — Глава 3: Моделирование. Пусть начнется веселье

О базовых показателях, отслеживании экспериментов, правильных тестовых наборах и метриках. О том, как заставить алгоритм работать.

towardsdatascience.com