Проектирование и реализация унифицированного механизма прогнозирования

алгоритм
Проектирование и реализация унифицированного механизма прогнозирования

1. Предпосылки

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

(1) Универсальность: Oppo предлагает множество рекомендуемых бизнес-сценариев, включая информационные потоки, магазины, короткие видеоролики, альянсы, журналы на экране блокировки, музыку и т. д. Предполагается, что движок должен поддерживать очень много сценариев, а структура должна быть универсальный.

(2) Мультимодельная оценка: в рекламных сценариях необходимо поддерживать ocpx, а ctr и cvr необходимо оценивать одновременно в одном запросе, что может быть несколько разных моделей конверсии (таких как загрузка, оплата и т. д.). ).

(3) Динамическое обновление моделей: некоторые модели обновляются ежечасно, а некоторые модели обновляются ежедневно, что требует динамического обновления без ощущения.

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

2. Позиционирование и выбор технологий

Учитывая, что бизнес-характеристики каждого бизнеса сильно различаются, если унифицированному механизму прогнозирования необходимо поддерживать эксперименты со стратегией и эксперименты по отклонению каждого бизнеса, модуль механизма прогнозирования будет очень раздутым и не сможет поддерживаться. Итак, в конце концов было решено, что механизм оценки выполняет только связанные с оценкой вещи. От исходных данных до оценочных результатов ctr требуется извлечение признаков, а результаты после извлечения признаков используются для оценки модели. Учитывая, что результаты извлечения признаков относительно велики, для одной оценки требуется около 2 М результатов признаков, и если такие большие данные будут передаваться по сети, это займет слишком много времени. Таким образом, общий процесс механизма прогнозирования включает две части: извлечение признаков и прогнозирование модели.

3. Дизайн и реализация Predictor

3.1 Место модуля Predictor во всей рекомендательной системе

图片1.png

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

3.2 Основной процесс модуля Predictor图片2.png

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

3.3 Модуль управления словарем

Как показано на следующем рисунке: conf1, conf2, lr_model_x0 и т. д. представляют файлы на диске. Каждое имя файла обрабатывается отдельным классом разбора словаря. Этот класс разбора словаря отвечает за управление загрузкой этого файла и переключение между двойные бафы. Например, FeatureConfDict отвечает за парсинг conf1.Он хранит внутри два буфера типа FeatureConfList.При обновлении файла conf1 он использует резервный FeatureConfList* для загрузки.После завершения загрузки, в процессе загрузки, сервис использует основной указатель FeatureConfList*. После завершения загрузки выполняется переключение master-slave, и память старого буфера освобождается, когда нет запроса на использование старого буфера.图片3.png

3.4 логика подзадач

Получен запрос, в котором указано несколько моделей conf для оценки. Как показано ниже:图片4.png

На приведенном выше рисунке показано, что всего имеется 8 образцов, и для извлечения признаков используются две конфигурации: conf0 и conf1.Результаты conf0 оцениваются по моделям model0 и model1, а результаты conf1 оцениваются по моделям2 и model3. По 2 образцам и одной задаче, после разделения задачи получится 4 задачи, как показано на следующем рисунке:图片5.png

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

3.5 Процесс слияния

После того, как оценка завершена, результаты оценки должны быть организованы в соответствии с размерностью conf/model и отправлены специалисту по ранжированию.Окончательный ответ показан на правом подрисунке ниже.图片6.png

3.6 Дизайн платформы извлечения признаков

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

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

3.6.1 Формат файла конфигурации функции

Файл конфигурации функции состоит из двух частей: части схемы и части оператора функции.

3.6.2 часть схемы

图片7.png

На приведенном выше рисунке показано 5 конфигураций схемы.

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

item_schema: Указывает рекомендуемую информацию, связанную с элементом, которая используется только в онлайн-режиме, часть ее передается по запросу, а часть получается из файла словаря.

context_schema: указывает рекомендуемую информацию, связанную с контекстом, которая используется только в онлайн-режиме и передается по запросу игры. Например: является ли текущий статус сети Wi-Fi или 4G.

all_schema: указывает информацию о схеме окончательного образца. Онлайн-режим заключается в размещении полей user_schema, item_schema и context_schema в соответствующей позиции all_schema, а в автономном режиме — десериализации строк текста hdfs в соответствии с типом, указанным all_schema_type. Будь то в сети или в автономном режиме, окончательный порядок полей выборок фрейма объекта сохраняется в порядке all_schema.

all_schema_type: используется только в автономном режиме, указывает тип каждой схемы. Эти имена типов определяются заранее. В автономном режиме каждое поле десериализуется в соответствии с типом схемы.

3.6.3 Раздел конфигурации оператора функции

图片8.png

Каждая функция включает следующие поля:

Имя: имя функции

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

Слот: Уникально идентифицирует функцию

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

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

Str_args: параметры, передаваемые оператору функции в виде строк.

3.6.4 Группировка функций (общие и необычные)

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

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

图片9.png

Функция i_id зависит от item_id поля элемента, поэтому это необычная функция.

Функция u_a/net зависит только от поля user_schema или контекста, а не от поля элемента, поэтому это общая функция. Функция комбинации u_a-i_id зависит от функции i_id, а интервал зависит от item_id, поэтому это необычная функция,

Комбинированная функция u_a-net зависит только от полей u_a и network, поэтому это общая функция, и запрос учитывается только один раз во время извлечения функции.

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

3.7 Раздел оценки

Как упоминалось ранее, запрос указывает, какой файл конфигурации функций используется для извлечения функций и какая модель используется для оценки. Все модели имеют асинхронные потоки обновления словаря, отвечающие за обновление. В настоящее время он поддерживает оценку LR, FM, DSSM, Deep&Wide и других моделей, и его относительно легко расширить. Ниже приводится краткое введение в следующие две модели, которые были глубоко оптимизированы в соответствии с бизнес-сценариями:

3.7.1 Прогнозирование модели FM (аналогично LR)

图片10.pngв

图片11.png

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

图片12.png

Все образцы в красной части одинаковы, и запрос нужно вычислить только один раз.

3.7.2 Модель DSSM (башни-близнецы)

Сетевая структура модели башни-близнеца показана на следующем рисунке:

图片13.png

На самом деле есть три башни: C (информация о контексте), U (информация о пользователе), I (информация об элементе), векторы, полученные пользователем и вложенными башнями элементов, скалярно умножаются, а затем суммируются с C.

3.7.3 Часть онлайн-обслуживания

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

图片14.png

В режиме онлайн рассчитываются только башня c и башня u, и для запроса необходимо рассчитать только одну выборку; часть I башни получается путем поиска в словаре для получения вектора. По сравнению с полным подключением объем вычислений значительно сокращается. Производительность была значительно улучшена, но поскольку информация о пользователе и элемент умножаются только на один слой скалярного произведения, автономный AUC снизится на 1% по сравнению с полным соединением, поэтому он больше подходит для сценариев, которые не требуют высокая точность, такая как отзыв или грубая сортировка. В рекламном бизнесе информационного потока и рекламном союзе исходный статистический приблизительный рейтинг CTR был заменен, а комплексный индекс увеличился на 5 или 6 процентных пунктов.

3.8 Оптимизация производительности

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

(1) Уменьшите выделение памяти и улучшите производительность за счет объединения объектов.

(2) Зависимости полей признаков заранее преобразуются в индексы.При извлечении признаков индексы напрямую используются для выбора соответствующих полей, чтобы уменьшить объем вычислений.

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

4. Резюме

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

об авторе

Сяо Чао Старший инженер по интеллектуальному анализу данных

Более 10 лет опыта разработки рекламных систем.В oppo он в основном отвечает за извлечение признаков модели и разработку рассуждений.

Для получения более интересного контента отсканируйте код, чтобы подписаться на общедоступную учетную запись [OPPO Internet Technology].

qrcode_for_gh_7bc48466f080_258.jpg