Задавайте важные вопросы быстрее.

Каждая команда в Tubi в значительной степени полагается на эксперименты, помогая принимать решения обо всем, от функций до изменений инфраструктуры и моделей машинного обучения. За последние 3 года количество экспериментов в Tubi увеличилось в 18 раз. Каждый третий эксперимент машинного обучения в последнем квартале показал влияние KPI компании. Не будет преувеличением сказать, что культура экспериментирования Tubi способствовала успеху компании в последние три года.

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

Двигатель эксперимента Поппера

Одним из важнейших компонентов платформы экспериментов Tubi является механизм экспериментов, серверная служба, написанная на Scala с использованием среды Akka. Это вторая итерация экспериментального движка Tubi, разработанная с учетом уроков, которые мы извлекли из нашей первой версии, основанной на библиотеке Facebook PlanOut (предыдущий пост). Поскольку мы хотели способствовать более научному подходу к экспериментам, мы назвали новую услугу в честь Карла Поппера.

«Поскольку научное утверждение говорит о реальности, оно должно быть опровергнуто » - Карл Поппер.

Основные абстракции

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

Каждое пространство имен может назначать (посредством согласованного хеширования) все экспериментальные цели (например, устройства, пользователей, IP-адреса и т. Д.) В настраиваемое количество сегментов, каждый из которых связан с постоянными хешированными значениями целей. . Сегменты назначаются не более чем для одного эксперимента, который затем относит сегменты к одной конкретной группе лечения. Эксперименты могут содержать несколько фаз, которые резервируют разное количество сегментов (например, фаза 1: 1% для дня 1, фаза 2: 10% в течение 2 дней после этого, фаза 3: 100% для оставшейся части эксперимента). Наконец, сегменты могут быть дополнительно уточнены с помощью условий (например, «только новые пользователи»), чтобы обеспечить более эффективное использование пространства имен.

Встроенная воспроизводимость

Эксперименты и пространства имен выражаются в виде конфигураций JSON, хранящихся в репозитории git. В каждом пространстве имен Поппер использует последовательность только для добавления для хранения любых операций CRUD над экспериментами.

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

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

Делаем его пригодным для использования

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

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

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

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

Поддержка при принятии решения

Измерение

Экспериментирующие клиенты будут извлекать конфигурации из механизма экспериментов Поппера, чтобы решить, какую ветвь кода выбрать. В той точке кода, где проводится эксперимент, на серверную часть отправляется событие разоблачение, указывающее, что на конкретного пользователя или устройство повлияло это конкретное пространство имен, эксперимент и группа лечения. Эта обработка данных осуществляется через конвейер, состоящий из служб Spark Streaming (работающий на Databricks) и Akka Streams, написанных на Scala.

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

Для получения дополнительных сведений о конвейерах экспериментов Tubi и о том, как мы используем dbt для создания доступного набора данных для экспериментов в RedShift, см. Наш предыдущий пост ниже.



Конвейеры экспериментов и DBT @Tubi
Введение: code.tubitv.com



Анализ

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

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

Экспериментальные проверки работоспособности

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

Хотя видов отказов бесчисленное множество, мы просто обрисовываем здесь три наиболее распространенных класса проблем:

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

Уроки выучены

Успешная платформа для экспериментов - это не просто сочетание механизма A / B-тестирования и аналитической панели. Он пронизывает многие дизайнерские решения, которые мы делаем как компания. Здесь описаны некоторые из самых важных уроков, которые мы извлекли.

Самообслуживание - ключ к скорости

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

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

Задавайте важные вопросы

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

Любого цвета, только если он черный

Почти каждая команда в Tubi хочет проводить эксперименты, чтобы помочь им работать быстрее и принимать более обоснованные решения. Эти эксперименты проводятся на 20 различных платформах для мобильных устройств и OTT. Код для запуска этих экспериментов написан на многих разных языках, от Scala и Elixir на сервере до Kotlin, Swift и Typescript на клиенте. Потребовалось немало усилий, чтобы интегрировать все экспериментальные приложения в одну платформу, но согласованность между платформами была важна для ускорения итераций в компании в целом.

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

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

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

Выводы

Вложения, которые мы вложили в улучшение экспериментов, оказали огромное влияние на повышение производительности всей компании и помогли нам принимать более обоснованные решения. От механизма Popper, созданного нашей бэкэнд-командой MLOps, до конвейеров данных, созданных Data Engineering, и системы анализа, созданной Data Science, эта платформа для экспериментов представляла собой сложную работу нескольких команд.

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

Если вы увлечены созданием лучших инструментов для экспериментов, присоединяйтесь к нам в Tubi Engineering!