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

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

Даже несмотря на то, что переход на облачные технологии уменьшился, не менее двух третей затрат на ИТ по-прежнему сосредоточены на задачах режима обслуживания. До сих пор мало исследований о том, применимо ли это разделение к проектам, связанным с ML, но я считаю, что этот процент даже значительно увеличится из-за того, что рабочая нагрузка ML имеет более «жидкие» входные данные и меньше рычагов управления, как показано ниже:

По сути, техническое обслуживание в основном определяется уровнем изменчивости и контроля, который мы можем иметь над различными компонентами системы. Как показано на диаграмме, разумно сделать вывод, что рабочие нагрузки машинного обучения более подвержены задачам обслуживания. Что еще хуже, пути эволюции данных и кода (бизнес-роли) не обязательно должны быть согласованы. Это подробно объясняется в статье Скрытый технический долг в системах машинного обучения.

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

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

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

Какая инфраструктура нам нужна для масштабного запуска машинного обучения?

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

В магазине функций

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

Магазин функций состоит из нескольких элементов:

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

В тренажерном зале

Целью обучающей установки является поиск и создание наилучшей модели (в определенный момент времени) с учетом: (i) исходной архитектуры модели, (ii) набора настраиваемых гиперпараметров и (iii) набора исторических помеченных функций. .

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

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

  • Проверка повторного обучения. Задача этого компонента — определить, когда необходимо повторно обучить текущую золотую модель. Во многих ситуациях необходимо инициировать событие повторного обучения. Я предлагаю развернуть несколько оценщиков для проверки условий переобучения. Некоторыми примерами могут быть изменения в функциях (добавление или удаление), статистическое расхождение в обучающем наборе (дрейф данных), или между данными обучения и данными обслуживания (перекос), или просто падение показателей точности. Сгенерированная модель должна быть передана компоненту-промоутеру, который будет иметь последнее слово в отношении ее развертывания в рабочей среде и того, как это сделать.
  • Цикл золотой модели: это, вероятно, самый важный шаг, он фактически выполняет обучение. Поэтому при разработке системы следует учитывать соображения производительности (например, распределенная инфраструктура и доступ к аппаратным средствам asics). Другая обязанность заключается в создании подписи модели, четком определении интерфейсов ввода и вывода, а также любой задачи инициализации (например, загрузчик переменных).
  • Следующий цикл золотой модели: этот компонент предназначен для обнаружения потенциальных новых моделей путем постоянной оптимизации (или попыток) текущей золотой модели. Есть два подцикла: один для оптимизации гиперпараметров (например, скорость обучения, оптимизаторы и т. д.), а другой — для запуска поиска новой архитектуры модели (например, количества слоев). Несмотря на наличие двух отдельных циклов, кандидаты на новую архитектуру модели могут быть дополнительно уточнены в цикле гиперпараметров. Этот компонент может быть ресурсоемким, особенно если пространство поиска велико, а алгоритм оптимизации (например, поиск по сетке, гиперполоса) является жадным. С инженерной точки зрения следует учитывать такие методы, как контрольные точки для возобновляемых операций и механизмы определения приоритетов заданий. Результаты этого компонента следует дополнительно оценить, прежде чем предпринимать какие-либо дополнительные действия.
  • Промоутер модели. Этот компонент отвечает за выдачу моделей, готовых к работе в производстве, поэтому на этом этапе необходимо выполнить обширное тестирование. В любом случае, как мы проверим на установке логического вывода, ни одна новая модель не будет развернута открыто для всех своих потенциальных пользователей.
  • Хранилище метаданных. Этот компонент централизовал все метаданные, связанные с этапом обучения (репозиторий моделей, параметры, эксперименты и т. д.).

Внутри системы прогнозирования

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

На этапе вывода присутствуют несколько компонентов:

  • Преобразование признаков:даже при наличии хранилища признаков для отделения признаков от систем производства данных, я думаю, что преобразование признаков по-прежнему имеет свое место во время вывода, чтобы применять специфические операции низкого уровня к потенциально повторно используемым и т. д. абстрактная функция. Для онлайн-систем требования к задержке имеют решающее значение.
  • Диспетчер.Задачей диспетчера является маршрутизация запросов к определенной конечной точке прогнозирования. Я считаю, что каждый отдельный запрос должен подвергаться эксперименту, поэтому диспетчер должен иметь возможность перенаправить вызов на конкретный или несколько живых экспериментов, на золотую модель или на то и другое. Каждый запрос, не подлежащий экспериментированию, означает упущенную возможность улучшения.
  • Прогнозирование магистрали.На этом компоненте сосредоточена мощность системы прогнозирования, поэтому с инженерной точки зрения крайне важно разработать его с учетом классических нефункциональных требований, таких как производительность, масштабируемость или отказоустойчивость.
  • Кэш-уровень.Хранилище значений ключа с малой задержкой для быстрого ответа на повторяющиеся запросы. Он должен реализовывать классические механизмы кэширования (аннулирование, ключевые вычисления на основе хеширования функций, очереди LRU и т. д.).
  • Золотой промоутер/де-промоутер:по мере проведения A/B-тестирования мы потенциально можем достичь точки, когда один из живых экспериментов будет на самом деле более эффективным, чем текущая золотая модель, миссия этого компонента состоит в том, чтобы проанализируйте метаданные и, в частности, наземные данные в хранилище функций, чтобы предложить замену золотой модели одним из экспериментов.
  • Подогрев модели:компонент для обеспечения прогрева кеша и памяти при возникновении ситуации «холодной звезды» (например, при продвижении новой модели).
  • Explainer:компонент, который реализует логику объяснимости модели (например, Anchors, CEM ..) и возвращает ее для заданного запроса.
  • Хранилище метаданных.Этот компонент централизовал все метаданные, связанные с этапом прогнозирования (результаты экспериментов в реальном времени, статистика прогнозных данных и т. д.).

Некоторые пути пользователя поддерживаются платформой

Есть несколько путей, которые может сформулировать эта архитектура, моя цель не в том, чтобы упомянуть их все, но я хотел бы выделить несколько интересных:

Во время создания функции

  • Составьте сложную функцию и обслуживайте ее в режиме реального времени
  • Составьте сложную функцию, запускающую LRO, и последовательно используйте ее во многих моделях.
  • Измените/обновите производителя информации об объектах, не влияя на логику преобразования и обслуживания.

Во время тренировки

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

Во время прогноза

  • Постепенно внедрять новую золотую модель, расширяя охват всего населения.
  • Запрос прогноза вместе с его объяснением черного ящика

Управляемость

  • Осмотрите модели, функции, версии сигнатур

Доступные технологии для развертывания

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

К счастью, мы можем положиться на kubernetes как на основную платформу, на которой мы развертываем наши компоненты. На следующей диаграмме показано предложение с сопоставлением компонентов с продуктами/проектами с открытым исходным кодом*.

*Интеграция FEAST и kubeflow в настоящее время находится в стадии разработки.

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

Заключение

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

Некоторые компоненты и примеры блокнотов по этой теме я публикую здесь.