Эта статья является второй в серии, посвященной платформам машинного обучения. Его поддержали Digital Catapult и PAPIs.

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

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

Обзор компонентов системы машинного обучения

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

Предположим, что «Базы данных» уже существовали до создания системы машинного обучения. Компоненты темно-серого и фиолетового цвета будут новыми компонентами, которые предстоит построить. Те, которые применяют модели машинного обучения для прогнозирования, выделены фиолетовым цветом. Прямоугольники используются для представления компонентов, которые, как ожидается, будут предоставлять микросервисы, обычно доступные через API передачи репрезентативного состояния (REST) ​​и выполняемые на бессерверных платформах.

В нашей системе машинного обучения есть две «точки входа»: клиент, запрашивающий прогнозы, и оркестратор, создающий / обновляющий модели. Клиент представляет приложение, используемое конечным пользователем, который получит выгоду от системы машинного обучения. Это может быть приложение для смартфона, которое вы использовали для заказа ужина, например UberEats запрашивает ожидаемое время доставки - важный вариант использования во время блокировки COVID-19!

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

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

Давайте резюмируем все компоненты, представленные на диаграмме выше, в виде списка:

  1. Сборщик наземной правды
  2. Этикетировщик данных
  3. Оценщик
  4. Монитор производительности
  5. Featurizer
  6. Оркестратор
  7. Конструктор моделей
  8. Модель сервера
  9. Внешний интерфейс

Мы кратко упомянули № 3, 4, 6, 7, 8 и 9. Давайте теперь предоставим немного больше информации и рассмотрим № 1, 2 и 5!

# 1: СБОРНИК НАЗЕМНОЙ ИСТИНЫ

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

# 2: ЭТИКЕТКА ДАННЫХ

Иногда у вас будет доступ к большому количеству исходных данных, но вам потребуется создать соответствующие достоверные данные вручную. Это тот случай, когда вы создаете детектор спама или детектор объектов по изображениям. Существуют готовые веб-приложения с открытым исходным кодом, упрощающие маркировку данных (например, Label Studio), а также специализированные сервисы для аутсорсинга ручной задачи маркировки данных (например, Рисунок 8 и Служба маркировки данных Google »).

# 3: ОЦЕНКА

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

Оценка модели преследует две важные цели: сравнение моделей и принятие решения о том, безопасно ли интегрировать модель в приложение. Оценка может выполняться на заранее определенном наборе тестовых примеров, для которых известно, каким должен быть прогноз (т. Е. Наземная истина). Можно изучить распределение ошибок, а ошибки можно объединить в показатели производительности. Для этого оценщику необходим доступ к основной истине набора тестов, чтобы при получении прогнозов на входе он мог вычислять ошибки прогнозирования и возвращать показатели производительности.

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

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

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

# 4: МОНИТОР ЭФФЕКТИВНОСТИ

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

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

# 5: ОСОБЕННОСТИ

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

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

Если по своей природе характеристики не меняются слишком часто, их можно вычислять партиями. Но в случаях использования машинного обучения, таких как ожидаемое время доставки UberEats, у нас могут быть «горячие» функции, которые будут быстро меняться и их нужно будет вычислять в реальном времени; например, среднее время доставки в определенном ресторане за последние X минут.

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

Featurizers могут запрашивать различные базы данных и выполнять различные агрегаты и обработки запрошенных данных. У них могут быть параметры (например, количество минут X в приведенном выше примере), которые могут влиять на производительность моделей.

№6. ОРКЕСТРАТОР

Рабочий процесс

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

  1. Извлечь-преобразовать-загрузить и разделить (необработанные) данные на наборы для обучения, проверки и тестирования.
  2. Отправьте наборы для обучения / проверки / тестирования для характеристики (если есть)
  3. Подготовить тематические наборы для обучения / проверки / тестирования
  4. Отправлять URI подготовленных наборов поездов / проверок вместе с метрикой для оптимизации в построитель моделей
  5. Получите оптимальную модель, примените к набору тестов и отправьте прогнозы оценщику
  6. Получите значение производительности и решите, можно ли отправить модель на сервер (например, для канареечного тестирования производственных данных).

Некоторые дополнительные сведения о шаге № 3 («подготовить специальные наборы для обучения / проверки / тестирования»):

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

Способы запуска рабочего процесса

Весь рабочий процесс может выполняться вручную, но для частого обновления моделей или для совместной настройки гиперпараметров функциональности и разработчика модели его придется автоматизировать. Этот рабочий процесс может быть реализован как простой сценарий и запускаться в одном потоке, но вычисления могут быть более эффективными за счет распараллеливания запусков. Сквозные платформы машинного обучения позволяют это делать и могут предоставить единую среду для определения и запуска полных конвейеров машинного обучения. С помощью Google AI Platform, например, вы можете использовать продукты данных Google Cloud, такие как Dataprep (инструмент обработки данных, предоставляемый Trifacta), Dataflow (упрощенный инструмент потоковой и пакетной обработки данных), BigQuery (бессерверный облачное хранилище данных), и вы можете определить обучающее приложение на основе TensorFlow или встроенных алгоритмов (например, XGBoost). При обработке важных объемов данных популярным выбором является Spark. Databricks, компания, стоящая за Spark, также предоставляет сквозную платформу.

В качестве альтернативы, каждый шаг рабочего процесса может выполняться на другой платформе или в другой вычислительной среде. Один из вариантов - выполнить эти шаги в разных контейнерах Docker. Kubernetes - одна из самых популярных систем оркестровки контейнеров с открытым исходным кодом среди практиков машинного обучения. Kubeflow и Seldon Core - это инструменты с открытым исходным кодом, которые позволяют пользователям описывать конвейеры машинного обучения и превращать их в кластерные приложения Kubernetes. Это можно сделать в локальной среде, а приложение можно запустить в кластере Kubernetes, который может быть установлен локально или предоставлен в облачной платформе - например, Google Kubernetes Engine, который используется платформой Google AI Platform, или Служба Azure Kubernetes, или Amazon EKS. Amazon также предоставляет альтернативу Kubernetes с Fargate и ECS. Apache Airflow - еще один инструмент управления рабочим процессом с открытым исходным кодом, изначально разработанный Airbnb. Airflow стал популярным способом координации выполнения общих ИТ-задач, в том числе машинного обучения, а также интегрируется с Kubernetes.

Активное обучение для более сложных рабочих процессов

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

№7. СТРОИТЕЛЬ МОДЕЛИ

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

$ curl https://bigml.io/optiml?$BIGML_AUTH -d '{"dataset": "<training_dataset_id>", "test_dataset": "<test_dataset_id>", "metric": "area_under_roc_curve", "max_training_time": 3600 }'

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

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

№8. МОДЕЛЬНЫЙ СЕРВЕР

Роль сервера модели - обрабатывать запросы API для прогнозов по данной модели. Для этого он загружает представление модели, сохраненное в файле, и применяет его, благодаря интерпретатору модели, к входным данным, найденным в запросе API; прогнозы затем возвращаются в ответ API. Сервер должен позволять обслуживать несколько запросов API параллельно и обновлять модель.

Вот пример запроса и ответа для модели анализа настроений, которая принимает только одну текстовую функцию в качестве входных данных:

$ curl https://mydomain.com/sentiment 
-H 'X-ApiKey: MY_API_KEY' 
-d '{"input": "I love this series of articles on ML platforms"}'
{"prediction": 0.90827194878055087}

Существуют различные представления моделей, такие как ONNX и PMML. Другой стандартной практикой является сохранение моделей, живущих как объекты в вычислительной среде, в файле. Это требует также сохранения представления вычислительной среды, в частности ее зависимостей, чтобы объект модели можно было создать снова. В этом случае «интерпретатор» модели просто состоит из чего-то вроде model.predict (new_input).

№9. ВНЕШНИЙ ИНТЕРФЕЙС

Интерфейс может служить нескольким целям:

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

Управление жизненным циклом модели

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

Заключение

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

Если вы серьезно относитесь к созданию дорогостоящих проприетарных систем машинного обучения для своей компании и хотите узнать больше, ознакомьтесь с моим онлайн-курсом, который я будет запущен 21 апреля 2020 г .: ОБУЧЕНИЕ НА СОБСТВЕННОЙ МАШИНЕ!