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

Производственные системы машинного обучения

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

Как мы видим, та часть, в которой происходит фактическое моделирование ML (обозначенная «кодом ML»), является крошечной частью гораздо большей системы. Традиционно в курсах колледжей и онлайн-МООК большое внимание уделяется «коду машинного обучения». Я думаю, основная причина в том, что трудно обучать и оценивать некоторые другие навыки, показанные на диаграмме. Тем не менее, другие блоки составляют большую часть того, как выглядит система машинного обучения производственного уровня.

Если машинное обучение является важным аспектом вашего бизнеса, то необходимо иметь надежную инфраструктуру вокруг вашего «кода ML». Мне нравится сравнивать его с традиционными крупномасштабными программными системами, где необходимо иметь кодовую базу с контролем версий, конвейеры CI/CD, поддержку инфраструктуры вычислений и данных и т. д., чтобы инженеры могли работать эффективно, а ваша техническая опора была сильный.

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

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

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

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

Примечание. В настоящее время существуют такие компании, как Tecton и Hopsworks, которые предлагают комплексные решения корпоративного уровня.

Магазин функций

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

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

Таким образом, Магазин функций — это не просто база данных, в которой вы можете хранить и извлекать свои функции. Это также инфраструктура для: создания этих функций, управления метаданными вокруг функций, обеспечения возможности обнаружения функций, обеспечения их совместного использования, обеспечения постоянной доступности в автономном и онлайн-режиме, отслеживания качества функций и, в некоторых случаях, даже предоставления согласованного API для выполнения. функциональная инженерия.

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

Проблема 1: непротиворечивость функций

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

Когда DS/MLE строит модель для решения проблемы (например, предсказания CTR), процесс обычно выглядит следующим образом:

  1. Получить данные из Data-warehouse или Datalake
  2. Займитесь разработкой функций: преобразуйте свои строки в одноразовые, вычислите исторические агрегаты и т. д. (обычно это делается в стеке на основе Python: Pandas, NumPy, PySpark)
  3. Обучите свою модель этим функциям, оцените качество
  4. Сделать его доступным для обслуживания

Во время обслуживания у вас еще нет готового полноценного вектора признаков, так как же можно выполнять проектирование/преобразование признаков в режиме онлайн прямо перед тем, как передать свой вектор признаков в модель для прогнозирования? Где живет этот код разработки функций? DS/MLE написали логику разработки функций на Python в своей записной книжке, но как она переносится на ваш Java-сервис с малой задержкой? Давайте посмотрим некоторые варианты.

Вариант 1. Дублируйте код

Мы можем дублировать код между офлайн-обучением и системами онлайн-обслуживания. Некоторые компании делают это, структурируя команды машинного обучения таким образом, что DS пишет код разработки функций на Python в блокнотах, а MLE пишет тот же код на Java для обслуживания. На мой взгляд, это довольно рискованно, особенно если у вас разные среды обучения и обслуживания (Python и Java). Более того, дублировать код в разных системах, чтобы делать одно и то же, просто плохая практика. Кроме того, очень сложно убедиться, что вычисления между офлайн- и онлайн-системами точно такие же. Обычный способ проявления этой проблемы — когда ваша модель очень хорошо работает в автономном режиме, но плохо работает в сети. Хорошим местом для изучения этого является просмотр функций, вычисленных в Интернете. Наличие хорошей системы мониторинга для измерения дрейфа функций офлайн/онлайн также помогает, хотя и не решает основную проблему дублирования логики в 2 местах в вашей системе машинного обучения.

Вариант 2. Общая библиотека для вычислений

Здесь у нас нет дублирующегося кода, но есть общая библиотека, которая выполняет разработку функций. Это возможно, если ваша обучающая и обслуживающая системы могут использовать одну и ту же среду выполнения. Это становится сложным с разработкой функций на основе Pandas/NumPy (если только ваша обслуживающая система не написана на Python). Однако это можно сделать, если вы используете PySpark для разработки функций. PySpark, являющийся просто оболочкой над Scala-Spark, по существу выполняет вычисления на JVM. Поэтому, если ваша онлайн-система обслуживания с малой задержкой работает на Java или другой системе на основе JVM, это разумное решение проблемы согласованности функций. Это то, что мы делаем в Yelp для нашей системы машинного обучения, ориентированной на рекламу. Для получения более подробной информации вы можете проверить мой блог о разработке Yelp.

Вариант 3: одно вычисление, две БД

Здесь у нас есть функции, вычисленные и загруженные в автономный DW/Datalake, а также в онлайн-базу данных (например, Cassandra для обеспечения высокой доступности). Это требует, чтобы все функции были вычислены и сохранены в этих хранилищах данных. Для обучения мы читаем из оффлайн БД, для обслуживания читаем из онлайн БД. Здесь есть два сложных аспекта:

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

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

Большинство инфраструктур Feature Store используют этот подход и решают вышеупомянутые проблемы: общую логику вычислений и автоматическое заполнение. Крупные технологические компании в области машинного обучения (Facebook, Uber, Airbnb) разработали своего рода DSL для общей логики вычислений, поэтому разработчикам не нужно писать код дважды, что довольно удобно. DSL обычно очень специфичны для предметной области и компании, поэтому я не уверен, сколько из них может быть широко распространено, даже если они открывают исходный код.

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

Проблема 2: Путешествие во времени

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

Это часто недоступно в традиционных решениях БД, если только для каждой схемы, содержащей наши функции, мы не добавим столбец времени события. И можно представить, что эти данные становятся очень большими для хранения в традиционной БД.

Более подходящим решением в этом случае будет хранение вашего моментального снимка или журналов изменений, разделенных по времени, на Datalake. Таким образом, мы можем хранить все обновления, разделенные по дате/времени, и мы можем писать поверх них запросы Spark/SQL, чтобы ответить на такой вопрос, как: какая средняя оценка была дана этим пользователем с января 2020 года по март 2020 года.

К счастью, это предоставляется в виде готовых к использованию решений от AWS (с использованием набора решений AWS, таких как S3, Glue, Athena, Kinesis) и Databricks Delta. Delta может работать поверх существующего Datalake (S3, хранилище блогов Azure, HDFS) и поверх него предоставлять хорошее решение для управления данными.

Сложным аспектом этого является управление потоковыми данными с помощью журналов изменений в вашем озере данных. Delta by Databricks также предлагает решение этой проблемы. Один из вариантов — не выполнять потоковые обновления и часто запускать пакетные добавочные обновления в журналах изменений, и этого обычно достаточно. Например, сводная статистика за последние 90 дней пользователя (средний CTR пользователя за 90 дней) не будет сильно меняться каждый час, поэтому можно делать это на моментальном снимке один раз в день. Однако, если для вашей модели важны последние 10 поисков, сделанных пользователем, вам нужны потоковые обновления.

Проблема 3: Разработка функций

Эта проблема очень тесно связана с проблемой согласованности, но она больше связана с DS/MLE, чем с инфраструктурой. Проблема заключается в том, как найти хороший набор библиотек для разработки функций, а также чтобы ваши определения функций были согласованными. Например, есть библиотеки, такие как Pandas и PySpark, которые DS/MLE используют для разработки функций, и они довольно мощные, но у них есть свои тонкие различия, которые могут остаться незамеченными. Поэтому, если один DS вычисляет однократное кодирование в Pandas, это может отличаться от однократного кодирования, выполняемого в PySpark. Так как же нам предоставить единый интерфейс для всех DS/MLE для разработки функций.

Вариант 1. Предоставьте DSL

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

Вариант 2. Используйте единую библиотеку разработки функций

Это может быть ограничением: что, если этой одной библиотеки недостаточно для ваших потребностей в разработке функций? И можно ли эту библиотеку использовать и для сервировки? Некоторое решение этой проблемы состоит в том, чтобы ваша библиотека разработки функций была на языке, который можно использовать для обслуживания, и предоставлять над ней оболочки для интерактивных языков, таких как Python. Я считаю, что это то, что Twitter делает, предоставляя обертки поверх Scala (я не уверен на 100%).

Вариант 3. Общий формат и исполнение

Если мы сможем придумать формат и механизм выполнения, который сможет использовать мой конвейер разработки функций, написанный на Python с использованием Scikit-learn, и сериализовать его в формат, который может использоваться моей службой логического вывода в реальном времени (возможно, на основе JVM), то эта проблема решено!

В Yelp мы пришли к этому решению. Мы не ограничивали нашу DS/MLE использованием одной библиотеки, такой как Pandas или PySpark, но любая разработка библиотеки/функции преобразуется если они могут быть сериализованы в общий формат: MLeap. Чтобы узнать больше о платформе машинного обучения Yelp, посетите этот блог. MLeap является относительно новым, но действительно мощным, поскольку он позволяет нам переключаться между различными средами обучения и обслуживания и не ограничивать себя необходимостью использовать только одну единственную библиотеку для разработки функций. Это также очень быстро, что можно увидеть здесь в тестах.

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

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

Проблема 4: Повторно используемые наборы данных

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

Обычно для материализации наборов данных используется долгосрочное дешевое хранилище, такое как S3/HDFS. Также рекомендуется материализовать данные в формате, подходящем для вашей библиотеки обучения моделей (TFRecord для Tensorflow, .npy для PyTorch, .h5 для Keras, паркет для моделей Spark ML).

Проблема 5: онлайн-обслуживание

Когда DS/MLE обучает модели, их набор функций обычно состоит из сотен функций, взятых из разных таблиц DW/Datalake. Но в среде обслуживания запрос состоит из очень простой информации, такой как user_id, product_id, time_of_request, платформа пользователя (мобильная/веб) и т. д. Следующим важным шагом является гидратация этого запроса для создания вектора признаков, чтобы сделать предсказания. Именно здесь появляется онлайн-магазин функций. Обычно он определяется вашими основными бизнес-объектами (пользователь, бизнес, продукт) и состоит из ряда атрибутов/функций ваших объектов, с помощью которых вы можете создать свой вектор функций. Иногда помимо этих функций требуется дополнительное преобразование. Здесь в игру вступает Feature Engineering. Наконец, вектор признаков затем отправляется в модель для обслуживания прогнозов в реальном времени. Apache Cassandra часто используется для хранения функций для онлайн-поиска из-за высокой пропускной способности, доступности и масштабируемости. Некоторые другие популярные варианты — MySQL и MongoDB.

Проблема 6: Управление метаданными

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

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

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

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

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

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

Проблема 7: Управление данными

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

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

Заключение

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

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

Рекомендации