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

Похоже, что каждая опытная команда машинного обучения создала хранилище функций для своей платформы машинного обучения. Uber построил Палитру. Airbnb построила Зиплайн. Netflix построил Путешествие во времени. Google Cloud работал с нашим клиентом GoJek над созданием Feast.

К счастью, вам больше не нужно создавать или управлять своими собственными. Google Cloud Vertex AI предлагает полностью управляемый магазин функций, как и Sagemaker. Есть даже такие компании, как tecton.ai, занимающиеся созданием хранилищ функций, не зависящих от облачных вычислений. Учитывая все это, может показаться, что хранилища функций — это хранилища данных машинного обучения — вы должны не только использовать хранилища функций, но и централизовать свою платформу машинного обучения вокруг хранилища функций.

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

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

Тренировочный перекос в подаче

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

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

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

1. В рамках модели

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

Преимуществом этого метода является простота. Дополнительная инфраструктура не требуется. Код предварительной обработки переносится вместе с моделью. Итак, если вам нужно развернуть модель на периферии или в другом облаке, вам не нужно делать ничего особенного. Формат SavedModel содержит всю необходимую информацию.

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

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

2. Функция преобразования

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

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

Такие платформы, как Tensorflow Extended (TFX), предоставляют возможность преобразования для упрощения учета. Некоторые платформы машинного обучения на основе SQL, такие как BigQuery ML, также поддерживают предложение TRANSFORM.

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

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

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

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

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

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

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

Каноническое использование хранилища функций

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

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

Таблица решений

Соображения, обсуждаемые здесь, обобщены в этой таблице решений:

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

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

1. Известно клиенту.
2. В хранилище данных.
3. Не зависит от времени.
4. Требуется только для пакетного обслуживания.
5. Недорогие в вычислительном отношении

Будь проще.

Дальнейшее чтение

  1. Feature Store — это один из шаблонов проектирования, которые мы обсуждали в нашей книге Шаблоны проектирования машинного обучения. Даже там мы предостерегали от перебора с этим шаблоном, но я боюсь, что Feature Store становится тем же, чем был шаблон Visitor в книге Gang of Four — чаще используется неуместно, чем нет.
  2. Используйте Keras Preprocessing Layers для предварительной обработки в модели и предложение TRANSFORM в BigQuery ML для преобразований. TFX предоставляет возможность преобразования для моделей TensorFlow/Keras.
  3. В Google Cloud, если вам нужен магазин функций, используйте полностью управляемый магазин функций Vertex AI.

Спасибо моему коллеге Ананду Айеру за полезные обсуждения этой темы.