• Оригинальный адрес:ПОЗНАКОМЬТЕСЬ С MICHELANGELO: ПЛАТФОРМА МАШИННОГО ОБУЧЕНИЯ UBER
• Оригинальный автор:JEREMY HERMANN & MIKE DEL BALSO
• Перевод с:Программа перевода самородков
• Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
• Переводчик:lsvih
• Корректор:TobiasLee, xfffrank

Платформа машинного обучения Uber — Микеланджело

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

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

Микеланджело работает в Uber уже около года и стал настоящей «платформой» для инженеров Uber и специалистов по данным, и теперь десятки команд строят и развертывают модели на этой платформе. Фактически, платформа Michelangelo сейчас развернута в нескольких центрах обработки данных Uber и использует специальное оборудование для обеспечения возможностей прогнозирования наиболее загруженных онлайн-сервисов компании.

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

Мотивация Микеланджело

До появления платформы Michelangelo инженеры и специалисты по данным Uber сталкивались со многими проблемами при создании и развертывании некоторых моделей машинного обучения, которые были необходимы компании и могли масштабироваться в соответствии с реальными операциями. В то время они пытались использовать различные инструменты для создания прогностических моделей (такие как язык R,scikit-learn, пользовательские алгоритмы и т. д.), после чего команда инженеров создает несколько одноразовых систем, чтобы использовать эти модели для прогнозирования. Поэтому в Uber очень мало специалистов по данным и инженеров, которые могут использовать различные инструменты с открытым исходным кодом для создания фреймворков за короткий период времени, что ограничивает применение машинного обучения внутри компании.

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

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

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

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

Вариант использования: модель оценки времени доставки UberEATS

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

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

Прогнозирование времени доставки (ETD) доставки еды — непростая задача. Когда пользователь UberEATS размещает заказ, заказ отправляется в ресторан для обработки. Ресторану необходимо подтвердить заказ и приготовить блюдо в соответствии со сложностью заказа и загруженностью ресторана.Этот шаг, естественно, займет некоторое время. Когда еда была почти готова, водитель Uber отправился за ней. Далее доставщику необходимо подъехать к ресторану, найти парковку, зайти в ресторан за едой, вернуться к машине, доехать до дома клиента (этот шаг занимает время в зависимости от маршрута, пробок и других факторов). ), найдите место для парковки и идите к двери клиента Окончательная доставка. Цель UberEATS — прогнозировать общее время этого сложного многоэтапного процесса и пересчитывать ETD на каждом этапе.

На платформе Michelangelo специалисты по обработке данных UberEATS использовали регрессионную модель GBDT (Gradient Boosted Decision Tree) для прогнозирования сквозного времени доставки. Функции, используемые этой моделью, включают информацию о запросе (такую ​​как время, место доставки), исторические характеристики (например, среднее время приготовления еды в ресторане за последние 7 дней) и функции почти в реальном времени (например, среднее время приготовления еды в последний час)) Эта модель развернута в контейнере, предоставленном платформой Michelangelo в центре обработки данных Uber, обеспечивая сетевые вызовы через микросервис UberEATS. Прогнозы отображаются клиентам до того, как еда будет приготовлена ​​и доставлена.

структура системы

Система Michelangelo состоит из ряда систем с открытым исходным кодом и встроенных компонентов. Основные используемые компоненты с открытым исходным кодом:HDFS,Spark,Samza,Cassandra,MLLib,XGBoost,TensorFlow. Если позволяют условия, команда разработчиков предпочитает использовать некоторые зрелые системы с открытым исходным кодом и, при необходимости, разветвляет их, настраивает и вносит в них свой вклад. Они также сами создают некоторые системы, если не могут найти подходящее решение с открытым исходным кодом.

Системы Michelangelo построены на основе данных и вычислительной инфраструктуры Uber и представляют собой «озеро данных», которое содержит все данные транзакций и журналов Uber. Все сервисные журналы Uber собираются и обобщаются Kafka, а затем рассчитываются и развертываются с помощью механизма потоковых вычислений Samza, управляемого кластером Cassandra и внутренними службами Uber.

В следующем разделе мы возьмем модель ETD UberEATS в качестве примера, чтобы кратко представить различные уровни системы и объяснить технические детали Микеланджело.

Рабочий процесс машинного обучения

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

Michelangelo был специально разработан, чтобы предоставить масштабируемые, надежные, многоразовые и простые в использовании инструменты автоматизации для решения следующего 6-этапного рабочего процесса:

1. Управление данными
2. Обучите модель
3. Модель оценки
4. Модель развертывания
5. результат прогноза
6. Предиктивный мониторинг

Ниже подробно описано, как архитектура Микеланджело облегчает различные этапы рабочего процесса.

Управление данными

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

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

Компоненты управления данными Michelangelo делятся на онлайн-конвейеры и автономные конвейеры. В настоящее время автономные конвейеры в основном используются для предоставления данных для пакетного обучения моделей и заданий пакетного прогнозирования; онлайн-конвейеры в основном используются для предоставления данных для онлайновых заданий прогнозирования с малой задержкой (и позже для поддержки систем онлайн-обучения).

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

Рис. 2. Конвейер предварительной обработки данных сохраняет данные в библиотеке функций и хранилище обучающих данных.

Автономное развертывание

Данные транзакций и журналов Uber «поступают» в озеро данных HDFS, которое можно легко вызвать с помощью вычислительных заданий Spark и Hive SQL. Платформа предоставляет контейнеры и запланированные задачи для выполнения регулярных заданий по вычислению частных функций в рамках проекта или публикации их в репозиториях функций (см. ниже) для совместного использования с другими командами. Когда запланированная задача запускает пакетное задание или запускает пакетное задание другими способами, задание будет интегрировано в инструмент мониторинга качества данных, который может быстро проследить, чтобы выяснить, где находится проблема в конвейере, и определить, является ли она проблема с локальным кодом или ошибки исходящих данных, вызванные проблемами с кодом.

Онлайн-развертывание

Модели, развернутые онлайн, не смогут получить доступ к данным, хранящимся в HDFS, поэтому некоторые функции, которые необходимо считывать из резервной базы данных производственных сервисов Uber, сложно использовать напрямую для таких онлайн-моделей (например, невозможно напрямую запросить сервис заказов UberEATS для расчета среднего времени приготовления еды в ресторане за заданный период времени). Поэтому инженеры предварительно вычисляют и сохраняют в Cassandra функции, необходимые онлайн-модели, которая может считывать эти данные с малой задержкой.

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

• пакетный предварительный расчет. Система периодически выполняет большие пакетные вычисления и загружает историю признаков из HDFS в базу данных Cassandra. Это очень просто и грубо, но если требуемые функции не требуют высокой производительности в реальном времени (например, разрешение обновлений каждые несколько часов), эффект все равно очень хороший. Система также гарантирует, что данные, используемые для обучения и обслуживания в пакетном конвейере, являются одним и тем же пакетом. UberEATS использует эту систему для обработки некоторых функций, таких как «среднее время приготовления еды в ресторане за последние семь дней».
• вычисления почти в реальном времени. Эта система будет публиковать соответствующие метрики в системе Kafka, а затем запускать задание потоковых вычислений Samza для создания всех функций с малой задержкой. Затем эти функции сохраняются непосредственно в базе данных Cassandra для обслуживания и резервируются в HDFS для последующего обучения. Как и в случае систем пакетного предварительного вычисления, это также гарантирует, что один и тот же пакет данных будет обслуживаться и обучаться. Чтобы избежать холодного запуска системы, инженеры также создали инструмент специально для системы, чтобы «заполнять» данные и запускать пакеты на основе истории для создания обучающих данных. UberEATS использует этот вычислительный конвейер почти в реальном времени для получения таких функций, как «среднее время приготовления еды в ресторане за последний час».

Общая библиотека функций

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

1. Это позволяет пользователям легко хранить свои собственные функции в общей библиотеке функций (нужно только добавить немного метаданных, таких как сумматор, описание, SLA и т. д.), а также позволяет хранить некоторые функции, специфичные для проекта, в частной форме. .
2. После того, как функция сохранена в библиотеке функций, впоследствии ее очень просто использовать. Будь то онлайн-модель или автономная модель, просто напишите название функции в конфигурации модели. Система извлечет правильные данные из HDFS и вернет соответствующий набор функций после обработки, который можно использовать для обучения модели, пакетного прогнозирования или онлайн-прогнозирования, взяв значения из Cassandra.

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

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

Предметно-специфический язык (DSL) для выбора и преобразования функций.

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

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

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

Обучите модель

В настоящее время платформа поддерживает крупномасштабное распределенное обучение в автономном режиме, включая деревья решений, линейные модели, логические модели и неконтролируемые модели (k-means), модели временных рядов и глубокие нейронные сети. Инженеры будут периодически добавлять ряд UberЛаборатория искусственного интеллектаНедавно разработанная модель. Кроме того, пользователи также могут предоставлять свои собственные типы моделей, включая индивидуальное обучение, оценку и код для предоставления услуг. Распределенные системы обучения моделей могут обрабатывать миллиарды выборочных данных в масштабе, а также могут обрабатывать небольшие наборы данных для быстрой итерации.

Конфигурация модели включает тип модели, гиперпараметры, источник данных, функцию DSL и требования к вычислительным ресурсам (количество необходимых машин, использование памяти, использование графического процессора и т. д.). Эта информация будет использоваться для настройкиYARNилиMesosУчебная работа на кластере.

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

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

Учебные задания можно настраивать и управлять ими через веб-интерфейс или API (обычно с помощьюJupyter notebook). Большинство команд используют API и инструменты управления процессами для регулярного переобучения своих моделей.

Рисунок 3: Задание обучения модели обучает модель, используя наборы данных в библиотеке функций и хранилище данных для обучения, а затем сохраняет модель в библиотеке моделей.

Модель оценки

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

Каждая модель, обученная на платформе Michelangelo, должна хранить следующую информацию в виде объектов версии в репозитории моделей Cassandra:

• Кто обучал модель.
• Время начала и время окончания обучения модели.
• Полная конфигурация модели (включая используемые функции, настройки гиперпараметров и т. д.).
• Обратитесь к обучающим и тестовым наборам.
• Опишите важность каждой функции.
• Метод оценки точности модели.
• Стандартные оценочные таблицы или графики для каждого типа модели (например, график ROC, график PR, матрица путаницы для бинарной классификации и т. д.).
• Все изученные параметры модели.
• Сводная статистика визуализации модели.

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

Отчет о точности модели

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

Рис. 4. Отчет для регрессионной модели, показывающий показатели производительности, связанные с регрессией.

Рис. 5. Отчет о модели двоичной классификации, показывающий показатели производительности, связанные с классификацией.

Визуальное дерево решений

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

Рис. 6. Просмотр модели дерева с помощью мощного компонента визуализации дерева.

Отчет о функциях

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

Рисунок 7: Функции, которые можно увидеть в отчете о функциях, их важность для модели и корреляция между различными функциями.

Модель развертывания

Michelangelo поддерживает сквозное управление развертыванием моделей с помощью пользовательского интерфейса или API. Модель можно развернуть тремя способами:

1. Автономное развертывание. Модели будут развернуты в автономных контейнерах с использованием заданий Spark для пакетного прогнозирования на основе спроса или запланированных задач.
2. Онлайн-развертывание. Модель будет развернута в кластере службы онлайн-прогнозирования (кластер обычно состоит из сотен машин, развернутых с использованием балансировки нагрузки), и клиенты могут инициировать одиночные или пакетные запросы на прогнозирование через сетевые вызовы RPC.
3. Развернуть как библиотеку. Инженеры хотят иметь возможность запускать модели в служебных контейнерах. Его можно интегрировать в библиотеку, а можно вызвать через Java API (этот тип не показан на рисунке ниже, но аналогичен онлайн-развертыванию).

Рис. 8. Модели в репозитории моделей развертываются в сетевых и автономных контейнерах для обслуживания.

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

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

результат прогноза

После развертывания модели в сервисном контейнере и ее успешной загрузки ее можно использовать для прогнозирования данных объектов из конвейера данных или данных от клиента. Исходные функции будут переданы через скомпилированный DSL, который при необходимости можно изменить, чтобы улучшить исходные функции, или получить некоторые дополнительные функции из репозитория функций. Окончательный построенный вектор признаков передается модели для оценки. Если модель является онлайн-моделью, результаты прогнозирования будут отправлены обратно клиенту по сети. Если модель находится в автономном режиме, результаты прогнозирования будут записаны обратно в Hive, которые затем могут быть переданы пользователю через нисходящее пакетное задание или непосредственно с помощью SQL-запроса следующим образом:

Рис. 9. Онлайн- и офлайн-сервисы прогнозирования используют набор векторов признаков для создания прогнозов.

эталонная модель

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

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

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

Масштабирование и задержка

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

Задержка онлайн-сервиса зависит от типа и сложности модели, а также от того, использует ли она функции, взятые из библиотеки функций Cassandra. Задержка теста P95 составляет менее 5 мс, когда модели не нужно извлекать функции из Cassandra. Задержка теста P95 по-прежнему составляет менее 10 мс, когда речь идет о выборке функций из Cassandra. Наиболее используемая сегодня модель обеспечивает более 250 000 прогнозов в секунду.

Предиктивный мониторинг

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

Чтобы решить эту проблему, система Michelangelo будет автоматически записывать и добавлять некоторые результаты прогнозирования к меткам конвейера данных.С помощью этой информации можно получить непрерывные показатели точности модели в реальном времени. В регрессионной модели R^2/решающий фактор,среднеквадратическая логарифмическая ошибка(RMSLE),Средняя квадратическая ошибка(RMSE) иошибка среднего абсолютного значенияВ системе мониторинга в реальном времени, выпущенной для Uber, пользователи могут анализировать значки взаимосвязи между показателями и временем, а также устанавливать пороговые сигналы тревоги:

Рисунок 10: Выборка прогнозов и сравнение с наблюдениями для получения показателей точности модели.

Управление, API, веб-интерфейс

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

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

Построить работу после платформы Микеланджело

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

• AutoML. Это будет система, которая автоматически ищет и обнаруживает конфигурации моделей (включая алгоритмы, наборы функций, значения гиперпараметров и т. д.), чтобы найти наиболее эффективную модель для данной проблемы. Система также автоматически создает конвейеры данных для создания функций и меток, необходимых для модели. В настоящее время команда инженеров решила большинство проблем этой системы с помощью библиотеки функций, унифицированного автономного и онлайн-конвейера данных и функций поиска гиперпараметров. Системы AutoML могут ускорить раннюю работу в области науки о данных, где специалистам по данным нужно только указать набор меток и целевую функцию, а затем они могут использовать данные Uber, чтобы найти лучшую модель для решения проблемы, не беспокоясь. Конечной целью этой системы является создание более интеллектуальных инструментов, которые упрощают работу специалистов по данным и тем самым повышают производительность.
• Визуализация модели. Для машинного обучения, особенно для глубокого обучения, понимание и отладка моделей становятся все более важными. Хотя инженеры впервые предоставили инструменты визуализации для древовидных моделей, необходимо проделать дополнительную работу, чтобы помочь специалистам по данным понимать, отлаживать и настраивать свои модели для получения действительно убедительных результатов.
• электронное обучение. Большинство моделей машинного обучения Uber напрямую зависят от продуктов Uber в режиме реального времени. Это также означает, что эти модели должны работать в сложном, постоянно меняющемся реальном мире. Чтобы модели оставались точными в изменяющихся условиях, эти модели должны развиваться вместе с окружающей средой; команды теперь регулярно переобучают модели на платформе Michelangelo. Комплексное решение на основе платформы должно позволять пользователям легко обновлять, обучать и быстро оценивать модели с помощью более сложной системы мониторинга и сигнализации. Хотя это потребует большой работы, более ранние результаты показывают, что создание полноценной системы онлайн-обучения может принести огромные преимущества.
• Распределенное глубокое обучение. Все больше и больше систем машинного обучения Uber внедряются с использованием глубокого обучения. Рабочий процесс для определения и повторения моделей глубокого обучения сильно отличается от стандартного рабочего процесса и поэтому требует дополнительной поддержки со стороны платформы. Глубокое обучение должно работать с большими наборами данных и требует другой аппаратной поддержки (например, графического процессора), поэтому ему требуется дополнительная поддержка распределенного обучения и тесная интеграция с более гибким стеком управления ресурсами.

Если вы заинтересованы в масштабном машинном обучении, приглашаем вас подать заявкуКоманда платформы машинного обучения Uber!

Об авторах: Джереми Херманн — инженер-менеджер в команде платформы машинного обучения Uber, а Майк Дель Бальсо — менеджер по продукту в команде платформы машинного обучения Uber.

---

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,React,внешний интерфейс,задняя часть,продукт,дизайнЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.