Джон Томас
В UFC бойцы готовятся к выступлению в октагоне с помощью интенсивных режимов тренировок. Бойцы и их команды будут проводить месяцы, анализируя стиль своего противника на предмет любых слабостей, которые можно использовать, оттачивая свое тело и свою технику, чтобы предложить наилучший бой.
Специалисты по данным из головной организации UFC, Endeavour, подходят к прогнозам машинного обучения с не меньшей решимостью. В то время как бойцы бросаются на камеру, данные, относящиеся к болельщикам, наблюдающим за боем, также подвергаются критическому анализу — конкуренция за привлечение и удержание зрителей является жесткой. Клиентам нужен увлекательный опыт, который удерживает их на крючке, и Endeavor стал растущим лидером в использовании машинного обучения и цифрового опыта для решения этой задачи. Ниже мы углубимся в работу Endeavour по максимизации информации о зрителях благодаря внедрению хранилища функций для оптимизации разработки машинного обучения в UFC.
Многие специалисты по данным, читающие это, знают, что основная часть работы по созданию моделей машинного обучения связана с созданием функций. Функции (т. е. предикторы или атрибуты), такие как агрегированные характеристики (например, количество дней с момента последней покупки или страна проживания клиента), являются необходимой частью прогнозных моделей машинного обучения. Чтобы модель делала точные прогнозы, ей нужны высококачественные функции, которые могут объяснить достаточное разнообразие выходных данных (другими словами, определить, к какой категории относится ваш прогноз). Но при масштабировании операций машинного обучения поддержание экосистемы машинного обучения может оказаться сложным или повторяющимся. Кроме того, ваша команда может рисковать несогласованностью определений в кодовой базе, повторяя одни и те же действия снова и снова. Компания Endeavor решила эту проблему с помощью Магазина функций, который стандартизирует и централизует функции для обеспечения согласованности, возможности обнаружения и повторного использования.
Разработка функций может занять значительное время, в зависимости от сложности вычислений. Вы можете потратить недели на агрегирование имеющихся необработанных данных в удобоваримом формате, подходящем для вашей модели. Некоторые функции могут быть общими для нескольких вариантов использования — например, продажи пожизненных билетов или наиболее часто используемых потоковых устройств — которые могут быть предсказуемы как для транзакционных моделей, так и для моделей поведения при просмотре. Если несколько специалистов по данным работают над моделями, используя один и тот же источник, могут возникнуть такие проблемы, как несогласованность определений, когда одни и те же функции создаются несколько раз для разных целевых функций (т. Е. Прогностический вопрос, на который вы хотите получить ответ). Усилия по обработке данных можно упростить, используя общий центр функций, которые можно использовать для нескольких клиентов и нескольких моделей.
Войдите в магазин функций.
Хранилище функций — это общий репозиторий кода, в котором несколько участников могут определять функции для разработки моделей.
В хранилище функций у вас может быть схема, состоящая из нескольких таблиц функций, каждая из которых дает представление об общем идентификаторе, который вы пытаетесь предсказать. Мы можем пройтись по примеру, используя работу, проделанную с Endeavour Streaming. Endeavor Streaming привносит передовые технологии и опыт работы с цифровыми медиа в мир потокового вещания и предоставляет набор аналитических возможностей для гигантов спортивного потокового вещания. С каждым клиентом (определяемым как бизнес-партнеры Endeavour для потоковой передачи их контента) Endeavour Streaming эффективно собирает данные об их потоковой передаче и транзакционном поведении, которые затем могут улучшить качество обслуживания клиентов. Специалисты по данным в нашей команде затем используют эти необработанные потоки данных для предоставления клиентам прогнозов машинного обучения. Если бы вы занимались машинным обучением для источника данных потокового видео, у вас могла бы быть, например, следующая разбивка:
Возможные целевые функции:
- Отток. Какова вероятность того, что клиент отменит подписку?
- Повторная покупка с оплатой за просмотр. Какова вероятность того, что клиент, купивший лицензию с оплатой за просмотр, купит ее снова?
- Повторное вовлечение клиентов. Какова вероятность того, что клиент будет транслировать определенный фрагмент контента?
На все эти вопросы очень разные ответы в том, что касается эффективности маркетинга и информации о продукте, но все они относятся к общему идентификатору: покупателю. Если мы достаточно знаем о клиенте, мы можем определить ответы для всех этих целевых функций, используя имеющиеся данные. Ниже мы обрисовываем, как эта структура хранилища функций может быть использована для UFC и как можно соответствующим образом использовать данные о количестве зрителей во время еженедельных боев. Мы можем за считанные минуты использовать информацию об активности взаимодействия для решения проблемы оттока и продолжать использовать эту агрегацию для решения проблемы повторного вовлечения. Продолжая пример потоковой передачи, одна из этих таблиц может выглядеть так:
Таблица 1: пример потока необработанных данных о просмотре для UFC
Endeavor использует базы данных Snowflake для хранения наших данных, и мы максимально повышаем эффективность, используя модели DBT для хранения запросов соответствующих агрегаций данных. Используя DBT, мы могли бы создавать тестовые наборы данных и наборы данных для вывода на уровне клиента (идентифицированного customer_EXID для ответа на имеющиеся целевые функции.
Некоторые функции, которые могут быть получены из этих наборов данных:
- Устройства, используемые клиентом
- Минуты просмотра клиентом
- Страна просмотра по клиентам
- Контент, просмотренный клиентом
- Первое просмотренное содержимое основной карты
На первый взгляд, вы можете использовать эти черты по отдельности и создать три приведенные выше модели для любого количества клиентов. В этом примере мы предполагаем, что у Endeavor Streaming есть два клиента:
Это работает." Этап манипулирования данными о просмотрах для двух клиентов может создать два фрейма данных (тест и вывод) для каждой целевой функции (3). Это приводит нас к двенадцати различным моделям, основанным на одних и тех же источниках и производящим одинаковый результат. Обратите внимание, что не все функции используются в каждой модели, поэтому это специально учитывается при создании каждой отдельной модели с помощью DBT. Однако это неэффективно по нескольким причинам:
- Дрейф определения функции — поскольку одни и те же функции воссоздаются для каждой из этих моделей, нет никаких механизмов, чтобы определение этой функции оставалось согласованным между моделями.
- Повторение. По мере появления новых клиентов процесс воссоздания этих точных моделей для этих клиентов должен повторяться.
- Обслуживание модели — по мере того, как данные изменяются или раскрывается новая глубина целевой переменной с течением времени, наименьшее изменение необходимо вручную реализовать во всех моделях одну за другой.
Хранилище функций решает эти проблемы, сохраняя все функции в одном месте для всех источников данных и всех моделей.
Теперь мы можем решить вышеуказанные проблемы, сосредоточив разработку функций в одном месте. Все функции, независимо от варианта использования, находятся в магазине функций. Одна модель может просто «проверить» любую понравившуюся функцию в магазине, просто присоединившись к идентификатору уровня строки (клиент). Красота этого дизайна не останавливается на достигнутом; любой клиент, который будет добавлен впредь, будет просто следовать логике своих предшественников для создания функций. Поскольку необработанная структура данных о просмотрах, поступающая в базу данных, идентична, если у нас есть новый «Клиент 3», мы можем просто применить ту же логику, что и для существующих клиентов, и создать те же функции для Клиента 3 с относительно небольшими усилиями. Это также позволяет нам быстро создавать модели (тестирование и вывод) для этих новых клиентов.
Это полезно по ряду причин:
- Работа по разработке функций может быть легко доступна другим специалистам по данным.
- Вычисление функций теперь автоматизировано для всех вариантов использования.
- Наборы данных для обучения и логического вывода согласуются по функциям
- Репликация моделей в различных сценариях использования быстро масштабируется.
Записи в хранилище функций по-прежнему представляют собой функции SQL, извлеченные с помощью моделей DBT, каждая из которых живет в виде таблицы функций. В каждой из этих таблиц функций есть несколько атрибутов клиента, все на уровне клиента. Устройства, используемые клиентом (feature_devices), могут иметь внутри себя функции, описывающие клиента, такие как first_device_used, most_commonly_used_device, multi-device_user и т. д. Все эти функции теперь можно выбрать, чтобы помочь предсказать, какую целевую функцию вы разрабатываете. Как только функции появятся, нам просто нужно будет объединить их все вместе на основе нашего общего идентификатора (клиент).
Хотя данные, обрабатываемые от уникальных клиентов, обслуживаемых Endeavor Streaming, существуют в одном и том же хранилище функций, данные объединяются при разработке модели путем простой фильтрации хранилища функций на основе клиента. В примере с UFC модели машинного обучения могут быть разработаны только после того, какспецифичные для UFCтренировочные наборы будут созданы, что гарантирует отсутствие утечки данных между клиентами. Безопасность данных встроена в дизайн и является еще одним преимуществом хранилища функций здесь, в Endeavor Digital.
Мы хотим, чтобы все таблицы были объединены в общую агрегацию на уровне строк, и в случае использования для работы с Endeavour Streaming мы хотим свести все к уровню клиента, обозначенному CUSTOMER_EXID. Объединение времени начала/окончания просмотра может быть очень полезным и достойным таблицы функций в нашем магазине.
WITH minutes AS (
SELECT
customer_exid,
DATEDIFF(
'minute', session_start, session_end
) AS session_length,
DATE(session_start) AS session_date
FROM
viewership
)
SELECT
customer_exid,
AVG(session_length) AS avg_session_length,
COUNT(DISTINCT session_date) AS distinct_days_active
FROM
minutes
GROUP BY
customer_exid
Таблица 2. Таблица характеристик, связанных с минутами (feature_minutes)
И наоборот, мы можем сделать то же самое для наших знаний о том, какие устройства они используют для потоковой передачи.
SELECT customer_exid, MODE(device) AS most_used_device FROM viewership GROUP BY customer_exid
Таблица 3: Таблица функций данных, связанных с устройствами (feature_devices)
Поскольку потоки данных Endeavor Streaming согласуются по своей структуре, мы можем полагаться на эти таблицы функций для автоматического вычисления этих функций после их создания.
С оттоком у нас может быть список подмножества исторических клиентов (представленных как CUSTOMER_EXID), а также идентификатор того, ушли ли они, отменили свою подписку или нет (они в настоящее время активны).
Таблица 4. Таблица статуса оттока клиентов (churn_status)
Наша цель с этой целевой функцией — найти предикторы качества, которые могут лучше всего классифицировать статус клиента как активный или просроченный. Хотя эта часть волшебства происходит в реальном машинном обучении, мы должны создать набор данных. Но прелесть хранилища признаков в том, что мы можем очень быстро создать набор данных для обучения на основе уже имеющихся таблиц. Нам не нужно делать сложный запрос, чтобы создать эту таблицу, нам просто нужно объединить все функции, которые мы хотим, вместе.
SELECT A.customer_exid, A.status, COALESCE(B.avg_session_length, 0) AS avg_session_length COALESCE(B.distinct_days_active, 0) AS distinct_days_active, COALESCE(C.most_used_device, 'Invalid') AS most_used_device FROM churn_status A LEFT JOIN feature_minutes B ON A.customer_exid = B.customer_exid LEFT JOIN feature_devices C ON A.customer_exid = C.customer_exid
Таблица 5. Набор обучающих данных для прогнозирования статуса оттока (ToTrain_churn_status)
Как видите, теперь у нас есть набор данных, по которому мы можем делать прогнозы status, используя все мои функции в качестве предикторов на уровне CUSTOMER_EXID . Вы также можете заметить здесь кое-что важное: не все клиенты будут отображаться в каждой из ваших таблиц характеристик. Клиент, у которого есть учетная запись, но который никогда не просматривал какой-либо контент, никогда не появится в таблице viewership или в любых таблицах функций, которые вытекают из нее. В результате вы хотите убедиться, что вы добавили COALESCE() к большинству, если не ко всем вашим объединениям, чтобы учесть эти нулевые значения.
Если другой специалист по данным хочет предсказать вероятность того, что клиент, купивший лицензию с оплатой за просмотр, купит ее снова, он может проверить функции, которые уже были созданы в сценарии использования оттока для их целевой функции. Это значительно сокращает время разработки модели и гарантирует, что определения функций являются общими для всех моделей. Кроме того, когда придет время для производства ваших моделей, вы можете снова использовать хранилище функций при создании наборов логических выводов. Используя хранилище функций, вы оптимизируете разработку обучения машинному обучению и создаете надежную экосистему для вашей команды специалистов по обработке и анализу данных, чтобы двигаться эффективно и результативно.
Хотите больше поговорить о данных с автором? Свяжитесь с Джоном Томасом напрямую в LinkedIn!
