Внедрение моделей в производство - сложное дело

Вступление

Самая большая проблема, с которой сталкивается машинное обучение, - как запустить систему в производство. Системы машинного обучения отличаются от традиционного программного обеспечения по двум фундаментальным причинам:

  • Машинное обучение никогда не бывает полностью детерминированным; следовательно, производительность системы машинного обучения не может быть оценена по строгим спецификациям. Вместо этого его всегда следует сравнивать с метриками, зависящими от приложения (ложные срабатывания / отрицательные результаты, уровень оттока, продажи).
  • Поведение системы машинного обучения определяется больше данными, используемыми для обучения, чем моделью, используемой для вывода. Таким образом, сбор данных, обработка данных, управление конвейером, повторное обучение модели и развертывание модели - это задачи, которые никогда не исчезнут.

На приведенной выше диаграмме показана концептуальная структура для различных компонентов системы машинного обучения:

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

Чтобы концептуализировать эту структуру, существует важный документ от Google под названием Оценка ML Test Score - критерий готовности производства и сокращения технического долга, который представляет собой исчерпывающую основу / контрольный список от специалистов-практиков Google. Это продолжение предыдущей работы Google, такой как (1) Скрытый технический долг в системах машинного обучения, (2) ML: кредитная карта с высокой процентной ставкой технического долга и (3) Правила ML: Лучшие практики машинного обучения машинного обучения .

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

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

Недавно я посетил Учебный курс Full-Stack Deep Learning Bootcamp в кампусе Калифорнийского университета в Беркли, который является прекрасным курсом, который учит глубокому обучению full-stack production. Одна из лекций, прочитанных Сергеем Караевым, прекрасно освещала тестирование и развертывание моделей. В этом сообщении в блоге я хотел бы поделиться лучшими практиками из лекции, которые позволяют максимально эффективно развертывать модели машинного обучения в производственной среде.

1 - Тестирование и непрерывная интеграция

В этом разделе рассматриваются две связанные темы:

  • Модульные тесты и интеграционные тесты - тесты для конкретных функций модуля и всей системы, соответственно.
  • Непрерывная интеграция - среда, в которой тесты запускаются каждый раз, когда новый код помещается в репозиторий перед развертыванием обновленной модели.

Модульное и интеграционное тестирование

Модульные и интеграционные тесты предназначены для обучающей системы и системы прогнозирования. Вот конкретные показатели, которые рекомендует Google:

  • Весь входной код функции тестируется. Ошибки в функциях может быть практически невозможно обнаружить после того, как они вошли в процесс создания данных, особенно если они представлены как в обучающих, так и в тестовых данных.
  • Каждая спецификация модели проходит проверку кода и регистрируется в репозитории. Надлежащий контроль версий спецификации модели может помочь сделать обучение доступным для аудита и улучшить воспроизводимость.
  • Показатели офлайн-прокси коррелируют с фактическими показателями онлайн-воздействия: необходимо четкое понимание взаимосвязи между этими офлайн-метриками прокси и реальными показателями влияния, чтобы гарантировать, что лучшая модель оценки приведет к лучшей производственной системе.
  • Качество модели достаточное для всех основных срезов данных: изучение срезов данных позволяет избежать мелких проблем с качеством, маскируемых глобальной сводной метрикой. Этот класс проблем часто возникает из-за сбоя при сборе обучающих данных, из-за которого важный набор обучающих данных теряется или задерживается.
  • Обучение воспроизводимо. Обучение модели часто невозможно воспроизвести на практике, особенно при работе с невыпуклыми методами, такими как глубокое обучение или даже случайные леса. Это может проявляться как изменение агрегированных показателей по всему набору данных или, даже если агрегированная производительность остается неизменной от запуска к запуску, как изменения в отдельных примерах. Ваши тесты должны быть в состоянии устранить эту недетерминированную природу процесса обучения модели.
  • Код спецификации модели проходит модульное тестирование: модульные тесты должны выполняться быстро и не требовать внешних зависимостей, но обучение модели часто является длительным процессом, который включает сбор большого количества данных из многих источников. У вас должно быть как минимум два вида модельных тестов: тесты использования API и тесты алгоритмической корректности.
  • Полный конвейер машинного обучения протестирован на интеграцию: должен быть полностью автоматизированный тест, который запускается регулярно и проверяет весь конвейер машинного обучения, проверяя, могут ли данные и код успешно проходить через каждый этап и что полученная модель работает хорошо. .
  • Качество модели проверяется перед попыткой ее обслуживания: после обучения модели, но до того, как она повлияет на реальный трафик, автоматизированная система должна проверить ее и убедиться, что ее качество достаточно; эта система должна либо благословить модель, либо наложить вето на нее, прекратив ее доступ в производственную среду.

Непрерывная интеграция

В современной программной инженерии непрерывная интеграция является неотъемлемой частью передовой практики систематического управления жизненным циклом разработки. С помощью механизма CI этот метод требует от разработчиков частой интеграции / фиксации своего кода в общем репозитории. Каждая фиксация запускает автоматическую сборку системы с последующим запуском заранее определенного набора тестов. Инженер получает сигнал прохождения / сбоя от каждой фиксации, что гарантирует, что каждая фиксация, получившая сигнал прохождения, удовлетворяет свойствам, необходимым для развертывания продукта.

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

Быстрый обзор инструментов непрерывной интеграции дает несколько вариантов: CircleCI, Travis CI, Jenkins и Buildkite.

  • И CircleCI, и TravisCI - это продукты SaaS для непрерывной интеграции, которые можно интегрировать с вашим репозиторием. Каждое нажатие запускает облачное задание, которое может быть определено как команды в контейнере Docker (который обсуждается ниже) и может сохранять результаты для последующего просмотра. Графические процессоры не поддерживаются.
  • Jenkins и Buildkite - удобные варианты для непрерывной интеграции на вашем оборудовании, в облаке или их комбинации. Это очень гибкие варианты запланированного тренировочного теста, которые позволяют использовать ваши графические процессоры.

2 - Контейнеризация

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

  • Несогласованные среды среди членов команды
  • Потраченное время на настройку библиотек Python
  • Потерянное время на настройку системных пакетов
  • Дополнительные вычислительные ресурсы доступны не всем инженерам
  • Каждое новое взаимодействие - это новый проект, начинающийся с нуля, который требует времени на настройку.
  • Локальная среда разработки не соответствует производственной среде клиентов, что приводит к непредвиденным проблемам на поздних этапах цикла поставки.

На помощь приходит Docker! Это компьютерная программа, которая выполняет виртуализацию на уровне операционной системы, также известную как контейнеризация. Вы спросите, что такое контейнер? Это стандартизированная единица полностью упакованного программного обеспечения, используемого для локальной разработки, доставки кода и развертывания системы. Лучший способ описать это интуитивно - представить процесс, окруженный его файловой системой. Вы запускаете один или несколько связанных процессов, и они видят целую файловую систему, никем не разделяемую. Это делает контейнеры чрезвычайно портативными, поскольку они отделены от базового оборудования и платформы, на которой они работают; они очень легкие, поскольку необходимо включать минимальный объем данных, и они безопасны, поскольку открытая поверхность для атаки контейнера чрезвычайно мала.

Обратите внимание, что контейнеры отличаются от виртуальных машин.

  • Виртуальным машинам требуется гипервизор для виртуализации полного аппаратного стека. Также существует несколько гостевых операционных систем, что делает их большими и более расширенными для загрузки. Вот что такое облачные экземпляры AWS / GCP / Azure.
  • С другой стороны, контейнеры не требуют гипервизора / аппаратной виртуализации. Все контейнеры используют одно и то же ядро ​​хоста. Существуют выделенные изолированные среды пользовательского пространства, что делает их намного меньше по размеру и ускоряет загрузку.

Контейнеры далеко не новые; Google уже много лет использует свою контейнерную технологию. Другие контейнерные технологии Linux существуют уже много лет. Так почему же Docker внезапно набирает обороты?

  1. Сроки. Впервые он был выпущен в 2013 году, в разгар повального увлечения DevOps, когда на рынок выходит все больше и больше инженеров-программистов.
  2. UX: у него лучший на сегодняшний день уровень абстракции для разработчиков. Платформа Dockerfile и образов Docker упрощает воспроизводимость.
  3. Экосистема. В нем есть DockerHub для изображений, предоставленных сообществом. Невероятно легко искать изображения, которые соответствуют вашим потребностям, готовые к использованию и практически без изменений.
  4. Маркетинг. Аналогию с контейнеровозом легко понять. Кроме того, кто не любит кита Докера? :)

Вкратце, вам следует ознакомиться со следующими основными понятиями: (1) Dockerfile определяет, как создать образ, (2) Образ - это собранная упакованная среда, (3) Контейнер - это место, где изображения запускаются внутри, (4) Репозиторий содержит различные версии образа и (5) Реестр - это набор репозиториев. . Если вы хотите глубже изучить Docker, я бы порекомендовал прочитать эту статью от Preethi Kasireddy и this cheatsheet от Aymen El Amri.

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

3 - Веб-развертывание

Чтобы развернуть любую систему прогнозирования в обслуживающей системе, вы должны убедиться, что:

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

В частности, для веб-развертывания вы должны быть знакомы с концепцией REST API. Это означает обслуживание прогнозов в ответ на запросы HTTP в каноническом формате. Затем веб-сервер может запустить и вызвать систему прогнозирования. У вас есть несколько вариантов для этого:

  • Вы можете развернуть код на виртуальных машинах, а затем масштабировать, добавляя экземпляры.
  • Вы можете развернуть код как контейнеры, а затем масштабировать с помощью оркестрации.
  • Вы можете развернуть код как «бессерверную функцию».
  • Или вы можете развернуть код с помощью решения для обслуживания моделей.

Развертывание кода в экземплярах облака

Идея здесь в том, что вы отправляете свой код на виртуальные машины, такие как экземпляры EC2 или Google Cloud Platform. Каждый экземпляр должен быть снабжен зависимостями и кодом приложения. Количество экземпляров регулируется вручную или с помощью автоматического масштабирования. Наконец, балансировщик нагрузки отправляет пользовательский трафик экземплярам. У этого подхода есть два минуса:

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

Развертывание контейнеров Docker в экземплярах облака

Идея здесь в том, что код приложения и зависимости упакованы в контейнеры Docker. Затем Kubernetes или альтернативы (AWS Fargate) оркестрируют контейнеры (DB / worker / webservers / и т. Д.). Минус в том, что вы все еще управляете своими серверами и платите за время безотказной работы, а не за время вычислений.

Развертывание бессерверных функций

Идея здесь в том, что код приложения и зависимости упакованы в файлы .zip с единой функцией точки входа. Затем все основные облачные провайдеры, такие как AWS Lambda, Google Cloud Functions или Azure Functions, будут управлять всем остальным: мгновенным масштабированием до 10 000+ запросов в секунду, балансировкой нагрузки и т. Д.

  • Хорошо то, что вы платите только за время вычислений. Кроме того, такой подход снижает нагрузку на DevOps, поскольку у вас нет серверов.
  • Компромисс заключается в том, что вам придется работать с жесткими ограничениями: (1) весь ваш пакет развертывания должен умещаться в пределах 500 МБ, ‹5 минут выполнения,‹ 3 ГБ памяти на AWS Lambda; (2) Вы можете выполнять только CPU.
  • Вы также можете использовать канарейку, что упрощает использование двух версий лямбда-функций и отправку небольшого объема трафика в одну.
  • Вы также можете выполнить откат, что упрощает возврат к предыдущей версии функции.

Развертывание с помощью обслуживания модели

Это варианты веб-развертывания, специализированные для моделей машинного обучения: TensorFlow Serving от Google, Model Server for MXNet от Amazon, Clipper от Berkeley RISE Lab и решения SaaS, такие как Algorithmia. В общем, наиболее важной особенностью является их способность пакетных запросов для вывода графического процессора.

  • Обслуживание Tensorflow по существу позволяет обслуживать прогнозы Tensorflow с высокой пропускной способностью. Он используется Google и его универсальными предложениями машинного обучения (например, Google Cloud API). Это, вероятно, излишнее решение, если вы не знаете, что вам нужно использовать графический процессор для вывода.
  • MXNet Model Server - это ответ Amazon на обслуживание Tensorflow, которое является частью их универсального предложения машинного обучения SageMaker.
  • Clipper - это модель с открытым исходным кодом, обслуживающая REST с использованием Docker. Вдобавок к основам есть несколько полезных вещей, например, «современные бандитские и ансамблевые методы для разумного выбора и комбинирования прогнозов». Этот проект, вероятно, еще слишком рано, чтобы быть полезным (если вы не знаете, зачем он вам нужен).
  • Некоторые стартапы обещают простое обслуживание моделей, например, Algorithmia. Во-первых, вы тренируете свои модели на выбранной вами структуре. Затем простой git push в слой AI делает вашу модель готовой к масштабированию. Наконец, уровень AI управляет оборудованием и делает модель доступной в виде API. Это включает в себя несколько вещей, таких как лямбда-функция и балансировщик нагрузки.

Вот основные выводы:

  • Если вы делаете вывод о ЦП, вы можете обойтись без масштабирования, запустив больше серверов (Docker) или отказавшись от сервера (AWS Lambda).
  • Если вы используете вывод графического процессора, такие вещи, как TF Serving и Clipper, становятся полезными с такими функциями, как адаптивное пакетирование.

4 - Аппаратное и мобильное развертывание

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

  • Встроенные и мобильные устройства имеют низкий процессор с небольшим объемом памяти, что делает процесс медленным и дорогостоящим для вычислений. Часто мы можем попробовать некоторые уловки, такие как уменьшение размера сети, квантование весов и обобщение знаний.
  • Встроенные и мобильные инфраструктуры PyTorch / TensorFlow менее полнофункциональны, чем полные инфраструктуры PyTorch / TensorFlow. Следовательно, мы должны быть осторожны с архитектурой модели. Альтернативный вариант - использование формата обмена.

Давайте рассмотрим некоторые из этих подходов более подробно:

Мобильные платформы

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

  • Tensorflow Lite предоставляет основу для сжатия обученной модели TensorFlow и развертывания в мобильном или встроенном приложении. Взаимодействуя с Интерпретатором TensorFlow Lite, приложение может затем использовать для своих целей потенциал предварительно обученной модели для создания логических выводов. Таким образом, TensorFlow Lite работает как дополнение к TensorFlow. Вычислительно затратный процесс обучения может по-прежнему выполняться TensorFlow в наиболее подходящей для него среде (персональный сервер, облако, разогнанный компьютер). Затем TensorFlow Lite принимает полученную модель (замороженный график, SavedModel или модель HDF5) в качестве входных данных, пакеты, развертывает и затем интерпретирует его в клиентском приложении, попутно обрабатывая оптимизацию с сохранением ресурсов.

  • PyTorch Mobile - это относительно новый фреймворк, помогающий разработчикам мобильных приложений и инженерам по машинному обучению встраивать модели PyTorch на устройства. В настоящее время он позволяет запускать любую модель TorchScript непосредственно в приложениях iOS и Android. Первоначальный выпуск PyTorch Mobile поддерживает множество различных методов квантования, которые уменьшают размеры модели без значительного снижения производительности. PyTorch Mobile также позволяет разработчикам напрямую преобразовывать модель PyTorch в формат для мобильных устройств без необходимости работать с другими инструментами / фреймворками. Учитывая, что фреймворк все еще находится в экспериментальной сборке, существует несколько заметных ограничений: (1) медленный для средних и больших моделей, (2) отсутствие поддержки графического процессора и (3) требует, чтобы разработчики писали на Objective C или C ++.
  • Core ML был выпущен Apple еще в 2017 году. Он оптимизирован для работы на устройстве, что сводит к минимуму объем памяти и энергопотребление модели. Работа строго на устройстве также обеспечивает безопасность пользовательских данных, а приложение работает даже при отсутствии сетевого подключения. Вообще говоря, его легко использовать, достаточно всего нескольких строк кода, чтобы интегрировать полную модель машинного обучения в ваше устройство. Обратной стороной является то, что вы можете сделать только вывод модели, поскольку обучение модели невозможно.

  • ML Kit был анонсирован Google Firebase в 2018 году. Он позволяет разработчикам использовать ML в мобильных приложениях либо с (1) выводом в облаке через API, либо (2) выводом на устройстве (например, Core ML). Для первого варианта ML Kit предлагает шесть базовых API-интерфейсов с соответствующими моделями, такими как маркировка изображений, распознавание текста и сканирование штрих-кода. Для последнего варианта ML Kit предлагает более низкую точность, но большую безопасность пользовательских данных по сравнению с облачной версией.

Если вас интересует ландшафт мобильного машинного обучения, ознакомьтесь с этой коллекцией, созданной командой FritzAI. Кроме того, FritzAI сам по себе является платформой машинного обучения для мобильных разработчиков, которая предоставляет предварительно обученные модели, инструменты разработчика и SDK для iOS, Android и Unity.

Встроенные фреймворки

От портативных медицинских устройств до беспилотных летательных аппаратов - интеллектуальные передовые решения требуют расширенных выводов для решения сложных проблем. Но эти устройства не могут полагаться на сетевые подключения к центру обработки данных. Им нужна производительность логического вывода в маломощном корпусе с малым форм-фактором. Лучшим решением в отрасли на данный момент является платформа NVIDIA Jetson.

  • Он работает на графическом процессоре NVIDIA и поддерживается NVIDIA JetPack SDK, который включает TensorRT для оптимизации моделей глубокого обучения для вывода и других библиотек (компьютерное зрение, ускоренные вычисления, мультимедиа).
  • В зависимости от конкретных требований к производительности и бюджета вы можете выбирать между различными аппаратными решениями Jetson, которые используют одну и ту же архитектуру и SDK, что позволяет использовать единую кодовую базу и беспрепятственное развертывание для всего портфеля продуктов.

Обрезка и квантование модели

И сокращение, и квантование - это методы сжатия модели, которые делают модель физически меньше, чтобы сэкономить место на диске, и заставляют модель требовать меньше памяти во время вычислений для более быстрой работы.

  • Обрезка удаляет часть модели, чтобы сделать ее меньше и быстрее. Популярной техникой является обрезка веса, при которой удаляются отдельные веса соединений. Этот метод похож на развитие человеческого мозга, когда одни связи укрепляются, а другие отмирают. Другой подход - обрезка нейронов, при котором нейроны удаляются целиком. Это означает удаление столбцов или строк в весовых матрицах.
  • Квантование снижает числовую точность весов модели. Другими словами, каждый вес постоянно кодируется с использованием меньшего количества битов. Простой метод реализован в наборе инструментов TensorFlow Lite. Он превращает матрицу 32-битных чисел с плавающей запятой в 8-битные целые числа, применяя к ней простое преобразование центр и масштаб: W_8 = W_32 / scale + shift (scale и shift определяются индивидуально для каждой матрицы весов). Таким образом, 8-битное W используется в матричном умножении, и только результат затем корректируется путем применения операции центрировать и масштабировать в обратном порядке.

Отличным примером сокращения модели является MobileNet, который выполняет различные методы понижающей дискретизации по сравнению с традиционной архитектурой ConvNet для максимальной точности, не забывая при этом об ограниченных ресурсах мобильного или встроенного устройства. Этот анализ Юсуке Учида объясняет, почему MobileNet и его варианты работают быстро.

Кистилляция знаний

Извлечение знаний - это метод сжатия, при котором модель маленького ученика обучается воспроизвести поведение большой модели учителя. Метод был впервые предложен Bucila et al., 2006 и обобщен Hinton et al., 2015. В процессе дистилляции знания передаются от модели учителя к ученику путем минимизации функции потерь, в которой целью является распределение вероятностей класса, предсказанное моделью учителя. То есть - вывод функции softmax на логитах модели учителя.

Так как же в точности работают сети учитель-ученик?

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

Хорошо известным недавним примером применения дистилляции знаний на практике является DistilBERT от Hugging Face, который представляет собой меньшую языковую модель, созданную под наблюдением популярной языковой модели BERT. DistilBERT удалил встраиваемые токены и пулер (используемый для следующей задачи классификации предложений) из BERT, сохранив при этом остальную архитектуру идентичной и уменьшив количество уровней в два раза. В целом DistilBERT имеет примерно половину общего количества параметров базы BERT и сохраняет 95% производительности BERT в тесте GLUE для понимания языков.

Формат обмена

Результатом любого обученного алгоритма глубокого обучения является файл модели, который эффективно представляет взаимосвязь между входными данными и выходными прогнозами. Чаще всего эти модели существуют в формате данных, таком как HDF5 или Pickle. Обычно вы хотите, чтобы эти модели были переносимыми, чтобы вы могли развертывать их в средах, которые могут отличаться от тех, в которых вы изначально обучили модель.

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

5 - Мониторинг

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

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

1 - Изменения зависимости приводят к уведомлениям:

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

2 - Инварианты данных сохраняются при обучении и обслуживании входных данных:

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

3 - Функции обучения и обслуживания вычисляют одни и те же значения:

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

4 - Модели не слишком устаревшие:

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

5 - Модель численно устойчива:

  • Явно отслеживайте начальное появление любых NaN или бесконечностей.
  • Установите правдоподобные границы для весов и доли единиц ReLU в слое, возвращающем нулевые значения, и активируйте предупреждения во время обучения, если они превышают соответствующие пороговые значения.

6 - Модель не испытала резкого или медленного регресса в скорости обучения, задержке обслуживания, пропускной способности или использовании ОЗУ:

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

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

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

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

Заключение

Если вы хотите получить хорошее резюме этого материала, взгляните на раздел 4 этого репозитория GitHub о глубоком обучении на производственном уровне, созданного Алирезой Дирафзоон (еще одним участником Full-Stack Deep Learning) . Если вы пропустили до конца, вот основные выводы:

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

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

Следуя рекомендациям, изложенным в этой статье, вы, как инженер по машинному обучению, должны уметь: (1) беспрепятственно сотрудничать с инженерами и DevOps для создания приложений на основе машинного обучения, которые могут оказать реальное влияние на бизнес; и (2) быстро масштабировать инициативы машинного обучения, преобразовывая их истинный потенциал в бизнес-процессы и системы. Достаточно большой стимул, не так ли?

Этот пост изначально опубликован на моем сайте!

Если вы хотите следить за моей работой в области систем рекомендаций, глубокого обучения, MLOps и журналистики в области науки о данных, вы можете ознакомиться с моими Medium и GitHub, а также другими проектами на Https://jameskle.com/. Вы также можете написать мне в Твиттере, написать мне по электронной почте или найти меня в LinkedIn. Или присоединяйтесь к моей рассылке, чтобы получать мои последние мысли прямо на ваш почтовый ящик!