Декомплексная разработка функций

Хранилище признаков становится полноценным компонентом современного стека данных и вызывает большой интерес в последние три года. Эта относительно новая категория инструментов обещает упростить производство моделей машинного обучения по сравнению с препятствиями, с которыми они сталкиваются в настоящее время. Это чрезвычайно амбициозное обещание, поскольку 85% проектов машинного обучения, реализуемых в настоящее время, никогда не доходят до производства. Хотя эта статистика сомнительна, так как эту цифру крайне сложно оценить, она отражает суровую реальность: большинство ML-проектов никогда не увидят своего дня. Магазины товаров обещают это изменить. Как же так? Предоставляя специалистам по данным каталог аккуратных, готовых к работе функций, повышая эффективность и масштабируемость моделей машинного обучения.

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

Вот краткий обзор:

I — Модели и функции: что это такое?

  • Определение моделей и функций на примере Ubereats
  • Проблемы с операционализацией моделей ML

II — Что такое магазин функций?

  • 5 компонентов магазина функций
  • Чего на самом деле достигают магазины функций?
  • Вам нужен магазин функций?

Модели и особенности: какие они?

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

Вводный пример

Хорошим примером модели машинного обучения, с которой знакомо большинство из нас, является модель приложения Uber Eats. Конечная цель этой модели — точно предсказать, сколько времени потребуется, чтобы ваша еда была приготовлена ​​и доставлена ​​к вашей двери, отвечая на фундаментальный вопрос человеческого существования: «когда мы едим?». Это амбициозная задача, поскольку Uber берет на себя задачу ответить на этот вопрос тысячам пользователей одновременно, для разных мест, разных ресторанов и разных водителей. Эта модель особенно интересна тем, что она породила саму концепцию хранилища признаков. Я объясню, как позже. А пока давайте погрузимся в веселую часть.

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

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

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

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

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

Чтобы делать прогнозы, модель использует две вещи:

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

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

Проблемы с операционализацией моделей ML

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

Первая задача: управлять различными периодами обновления

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

  1. Сколько времени обычно требуется ресторану, чтобы приготовить блюдо. Этот сигнал довольно прост. Вы можете рассчитать его раз в неделю или раз в месяц и убедиться, что он всегда доступен в вашем хранилище данных для передачи в модель. Время, затрачиваемое на приготовление бургера, обычно не сильно различается, так что вы в безопасности. Этот тип функции называется автономной функцией, поскольку он в основном используется пакетными процессами. Обычно эти функции рассчитываются с помощью таких фреймворков, как Spark, или путем простого выполнения SQL-запросов к базе данных.
  2. Сколько заказов есть у ресторанов и как оно соотносится с обычным количеством заказов, которые они получают за 30 минут. Это дает представление о том, насколько загружен ресторан. Если он загружен больше, чем обычно, вы можете ожидать, что ваша еда будет доставлена ​​дольше. Этот сигнал намного сложнее. Его нельзя вычислить в хранилище данных, поскольку хранилище данных не содержит данных, которые были доступны за последние 30 минут, и в любом случае оно не предназначено для быстрых операций. Итак, что обычно происходит, так это то, что события заказа заполняются через поток Kafka, и некоторые задания потоковой агрегации читают эти потоки kaka, агрегируя эти данные в окне агрегации 15–30 минут. Окно должно быть коротким, чтобы, когда вам нужно сделать прогноз времени приготовления еды, сигнал был доступен немедленно. Окно всегда обновляется в режиме реального времени. Этот тип функции называется онлайн-функцией, потому что ее нужно вычислять очень быстро и часто обслуживать с задержкой в ​​миллисекунды. Необходимые вычисления более сложны, чем для автономных функций, поскольку они требуют быстрых вычислений и быстрого доступа к данным.

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

Вторая проблема: сложный рабочий процесс производства

Путь к производству моделей машинного обучения следующий:

  1. Исследователи данных положили начало рабочему процессу машинного обучения. Они начинают с определения данных, необходимых для создания функций, а затем экспортируют эти данные в локальную среду Python. Они очищают данные, преобразуют их, чтобы извлечь соответствующие сигналы для модели (разработка функций). Затем модель обучают, чтобы убедиться, что она хорошо работает, когда дело доходит до прогнозирования новых значений. После того, как модель признана работоспособной, прототип полностью передается команде инженеров.
  2. Инженеры данных берут записную книжку Python и заботятся о «производстве» модели машинного обучения. То есть они строят конвейеры данных, необходимые для подачи модели с нуля. Они пишут конвейеры данных для обслуживания модели в производственной среде и создают производственные службы/мониторинг. По сути, они создают специальный инженерный микросервис для поддержки этих прогнозов. Этот рабочий процесс повторяется для каждой функции и для каждой модели, которую организация хочет внедрить в производство.

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

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

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

Проблемы, возникающие при продакшене ML-моделей:

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

❌ Производство ML-моделей сопряжено с огромными затратами, поскольку требует создания сложных конвейеров данных с нуля каждый раз, когда мы хотим запустить модель в производство.

Что такое магазин функций?

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

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

  • Запускает конвейеры данных, которые преобразовывают необработанные данные в значения функций. Подумайте об агрегировании заказов, чтобы получить значение функции «количество заказов в ресторане за последние 30 минут».
  • Хранит данные объектов и управляет ими (в онлайн- или офлайн-режиме).
  • Последовательно ли предоставляет данные об объектах для обучения модели и целей логического вывода?

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

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

Хранилище

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

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

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

Хранилище функций — двойная база данных

Каталог

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

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

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

Преобразования

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

Существуют различные типы преобразования данных:

  • Пакетные преобразования применяются только к данным в состоянии покоя, в хранилище данных, озере данных или базе данных. Этот вид преобразования будет применяться для получения среднего времени, необходимого для приготовления еды в ресторане.
  • Потоковые преобразования применяются к данным в движении/источникам потоковой передачи. То есть данные преобразуются по мере их прохождения по конвейеру. Эти преобразования обычно выполняются в Kafka, Kinesis, Pubsub и т. д. Этот вид преобразования можно использовать в контексте получения количества заказов. для данного ресторана за последние 30 мин.

Обслуживание

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

Мониторинг

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

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

Чего на самом деле достигают магазины функций?

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

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

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

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

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

Вам нужен магазин функций?

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

  1. Зависит ли ваш продукт от машинного обучения? Некоторые модели машинного обучения просты в развертывании. Со сложными моделями машинного обучения, такими как Ubereats или рекомендательный сервис Amazon, весь продукт зависит от точности модели. Это мотивирует необходимость подачи дополнительных сигналов. Чем больше сигналов, чем больше контекста вы получите, тем лучше будут ваши прогнозы. Если у вас сложные конвейеры и высокие затраты на машинное обучение, вам, вероятно, понадобится хранилище функций.
  2. Кто является потребителем варианта использования ML? Существует большая разница между успехом и стоимостью варианта использования ML в зависимости от того, кто является потребителем этого варианта использования. Обычно, если его целью является внутреннее аналитическое потребление (т. е. прогнозирование продаж), оно, как правило, обходится намного дешевле, чем операционное машинное обучение. Специалисты по обработке и анализу данных являются сквозными владельцами внутренних проектов машинного обучения, и ставки ниже. Для оперативного ML вам нужно, чтобы все работало идеально, потому что ваш продукт полностью зависит от производительности вашей модели. Есть SLA, больше инженерных требований и огромные бизнес-расходы, если что-то пойдет не так для этих вариантов использования. Если вы занимаетесь операционным машинным обучением, вам, вероятно, понадобится хранилище функций больше, чем если бы ваши варианты использования оставались внутренними.

Эволюция инструментов хранения функций

Функциональные магазины появились совсем недавно. Концепция была представлена ​​Uber в 2017 году с запуском их платформы Микеланджело. Если у вас есть лишние минуты, посмотрите, как была построена платформа Микеланджело и какие мотивы стояли за ней, это может только углубить ваше понимание вопроса.

После этого всего через год были запущены Hopsworks и Feast, два проекта магазина функций с открытым исходным кодом. Технологические гиганты, такие как Google (Vertex AI), Amazon (SageMaker) и Databricks, также быстро предложили свои собственные полностью управляемые платформы хранения функций. Вот краткий график, чтобы понять эволюцию инструментов:‍

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

Более современные тесты стека данных?

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

В Castor мы создаем инструмент документирования данных для генерации Notion, Figma, Slack. Или по данным для поклонников Fivetran, Looker, Snowflake, DBT. Мы разработали наш каталог, чтобы он был простым в использовании, восхитительным и удобным.

‍

Первоначально опубликовано на https://www.castordoc.com.