Этот блог размещен в блоге Aqueduct.

На прошлой неделе я размышлял о последнем десятилетии исследований систем машинного обучения и о том, как новые абстракции и программные среды для машинного обучения (например, scitkit-learn, PyTorch, Tensorflow) катализировали легкодоступные данные и вычисления, чтобы запустить революцию машинного обучения.

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

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

Следующий рубеж: тестирование? Нет, вывод!

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

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

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

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

Исторически сложилось так, что компании, которые успешно использовали машинное обучение, тратили значительные инженерные усилия на логические выводы и проблемы, связанные с управлением процессом логических выводов — иногда даже создавали специальные микросхемы исключительно для логических выводов. Например, в широко цитируемой статье Google Скрытый технический долг в системах машинного обучения Scully et al. изображает самую большую проблему в производственном машинном обучении.

Но что такого сложного в том, чтобы делать прогнозы на основе обученной модели? В конце концов, в scikit-learn вы просто вызываете model.predict(x).

Почему вывод так сложен?

Когда моя исследовательская группа в Калифорнийском университете в Беркли взялась за эту новую повестку дня, ориентированную на логические выводы, мы сделали это с точки зрения технологических гигантов. Моя группа, как и многие другие, черпала вдохновение в проблемах, с которыми сталкиваются спонсоры и недавние выпускники таких компаний, как Amazon, Google, Meta и Uber. В этих крупных компаниях, ориентированных на машинное обучение, были целые команды, занимающиеся рендерингом прогнозов для критически важных моделей. Такие задачи, как прогнозирование рейтинга кликов в режиме реального времени, рекомендации контента, обнаружение мошенничества и ценообразование маршрутов, были центральными для их бизнеса и в значительной степени зависели от постоянно меняющихся входных данных. В результате они развертывали большие деревья решений и глубокие нейронные сети, а также предъявляли жесткие требования к задержке прогнозирования (‹10 мс) для конвейеров многоэтапного прогнозирования. Им нужно было поддерживать всплески пользовательского трафика и динамически масштабировать до различных уровней аппаратных ускорителей. И все это нужно было делать, принимая во внимание стоимость, высокую доступность и большое количество отзывов.

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

Velox: Магазин прототипов функций

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

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

Отправка нескольких моделей одновременно с помощью Clipper

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

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

Clipper был принят такими компаниями, как LINE, и многие более поздние системы обслуживания прогнозов, включая TensorFlow Serving и SageMaker, использовали ту же архитектуру. Удивительные студенты, участвовавшие в проекте Clipper, в конце концов закончили учебу, и архитектура была включена в другие исследовательские проекты Cloudflow и Ray Serve. (Одним из недостатков работы профессором является то, что ваши лучшие студенты всегда заканчивают учебу.)

От моделей к конвейерам моделей и автомасштабированию

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

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

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

Почему машинное обучение бесполезно (пока)

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

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

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

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

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