Исследование и практика глубокого обучения в оценке ETA доставки Meituan

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

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

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

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

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

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

На следующем рисунке показана временная шкала всего процесса выполнения райдера.В процессе задействованы различные параметры длительности.Видно, что узлов более десятка, из них ключевая длительность достигает семи. Эти продолжительности включают в себя несколько сторон, таких как гонщики (забор-забор-доставка), продавцы (обед вне дома) и пользователи (доставка), и должны пройти через внутренние и наружные переходы между сценами, поэтому проблемы очень сложны. высокий. Для моделирования ЭТА это не только простая временная оценка, но и временная оценка всего звена, и в то же время необходимо учитывать баланс между коэффициентом конверсии «единичный объем - транспортная мощность - коэффициент конверсии пользователей». Эволюция ETA дистрибутива включает в себя постоянное улучшение на уровне данных и функций, а также эволюцию пользовательской структуры LR-XGB-FM-DeepFM на уровне модели.

Конкретное место ETA во всем дистрибьюторском бизнесе и общую практику машинного обучения в дистрибьюторском бизнесе см.«Практика машинного обучения в системе распределения Meituan: использование технологий для восстановления реального мира».

2. Улучшение модели в итерации бизнес-процесса

2.1 Итерация и выбор базовой модели

Подобно итеративному пути большинства моделей CTR, бизнес-итерация модели распределения ETA прошла путь LR-> Модель дерева-> Внедрение-> DeepFM-> Целевая модификация структуры. Уровень функций также постоянно повторяется и обогащается.

Размерность модели начинается с линейной комбинации признаков, слияния плотных признаков в древовидной модели, интеграции признаков ID-типа в Embedding и сочетания признаков второго порядка после низкоранговой декомпозиции модели. Механизм FM, и, наконец, модель ориентирована в соответствии с потребностями бизнес-показателей.
Измерение функции постепенно расширяется до размеров портрета пользователя/портрета водителя/бизнес-портрета/функции адреса/функции трека/функции региона/функции времени/функции последовательности/функции заказа.

После сравнения общих моделей, таких как Wide&Deep, DeepFM и AFM, текущая версия модели наконец выбрала DeepFM в качестве предварительной базовой модели с учетом вычислительной производительности и эффекта. После того, как функции всей модели DeepFM встроены на основе FM (машина факторизации), далее добавляется глубокая часть для выполнения целевого слияния разреженных и плотных функций соответственно. Часть FM рассматривает слияние признаков первого и второго порядка через внутренний продукт скрытых переменных, а часть DNN изучает слияние признаков высокого порядка посредством Feed-Forward. В процессе обучения модели используются функции Learning Decay/Clip Gradient/solver/Dropout/Activation, которые здесь повторяться не будут.

2.2 Функция потерь

В сценарии оценки ожидаемого времени прибытия более важными бизнес-индикаторами являются показатель своевременности и уверенность. Первоначальная попытка заменить функцию потерь Square функцией потерь Absolute интуитивно больше соответствует более строгим ограничениям MAE, чем ME. При правильном снижении обучения результаты конвергентны и стабильны.

В то же время, учитывая одинаковое время выполнения ETA в итерации, при ограничении в N минут до и после, прибытие на 1 минуту раньше лучше, чем прибытие на 1 минуту позже, и дизайн функции потерь надеется, что общий результат прогноза может быть как можно вперед. Для ранней части уменьшите численный штраф соответствующим образом. Для поздней части увеличьте численный штраф соответствующим образом. После многих раз отладки и проектирования, наконец, определено, что передние и задние N минут и начало координат используются как 3 точки сегментации. На основе оптимизации исходной абсолютной функции в передней части разработана абсолютная функция с наклоном в 1,2 раза, а в последней секции разработана абсолютная функция с наклоном в 1,8 раза, так что результаты могут сходиться к центру в целом, и оценочные результаты, скорее всего, будут предоставлены заранее.По пунктам ETA показатели были значительно улучшены.

2.3 Интеграция бизнес-правил в модель

Текущая бизнес-архитектура представляет собой «модель + правила». После того, как модель оценит значение ETA для конкретного бизнес-сценария, определенные бизнес-правила будут со временем накладываться друг на друга, чтобы удовлетворить потребности конкретного сценария. Каждое правило создается путем нескольких итераций показатели бизнеса. Существует разрыв между общей оптимизацией модели и правил.После того, как время модели и время правила оптимизируются отдельно, то есть влияние времени правила нельзя учитывать при обучении модели, и время правила будет производят разные изменения в разные периоды времени года. Плавающее после повторных итераций в течение определенного периода времени увеличит степень фрагментации.

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

Для простых правил, таких как (a * b + c) * d, логика правила может быть непосредственно реализована оператором OP TF.Например, когда b и d являются фиксированными значениями, тогда a и c являются обучаемыми параметрами.
Для чрезмерно сложной части правил ее можно заменить подгонкой модели с помощью определенной структуры модели, оптимизация вложенности слишком большого количества сложных ОП-операторов одновременно непроста.

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

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

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

Структура модели пытается скорректировать предполагаемую цель:

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

2.4 Обработка пропущенных значений

При обработке модели неизбежно есть некоторые пропущенные значения на уровне признаков, а для обработки пропущенных значений он полностью изучается из«Практика модели глубокого обучения Meituan «Угадай, вам нравится» ранжирования»способ в статье. Введите функцию x в модель TF и оцените. Если это отсутствующее значение, установите параметр w1. Если это не отсутствующее значение, введите значение модели как w2 * x. Здесь w1 и w2 используются как обучаемые параметры, и они помещаются в сеть для обучения. Этот метод заменяет средние/нулевые значения и т. д. в качестве методов для пропущенных значений.

3. Оптимизация задачи с длинным хвостом

3.1 Расчетные результаты модели + время компенсации правила длинного хвоста

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

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

В рамках приведенной выше разборки для решения проблемы краткой оценки длинного хвоста используется правило дополнительного времени: дополнительное время правила длинного хвоста представляет собой комбинацию . Деловой фактор длинного хвоста — это бизнес-факторы, такие как расстояние и цена, а модельный фактор длинного хвоста — стандартное отклонение RF. Окончательная стратегия ETA — это результат прогнозирования модели + время компенсации правила длинного хвоста.

4. Практика инженерных разработок

4.1 Практика тренировочной части

Общий тренировочный процесс

Для офлайн-обучения принят следующий процесс обучения:

Интеграция необработанных данных Spark -> Spark генерирует TFRecord -> параллельное обучение данных -> автономная оценка GPU TensorFlow Serving -> онлайн-прогнозирование CPU Inference

Весь рутинный процесс обучения длится около 4 часов при нескольких раундах Эпох миллиардов данных, При обучении TF, учитывая, что фактическая вычислительная эффективность TF не очень высока, большая часть находится в части ввода-вывода данных, и часть TFRecord генерируется Spark.Здесь скорость может быть ускорена примерно в 3,6 раза. В части параллельного обучения данных расширение параллелизма на 16 карт в основном близко к линейному, с хорошей масштабируемостью. Поскольку количество параметров на PS не достигло автономного невыносимого уровня, параметры на PS пока не сегментированы. Часть оценки обслуживания графического процессора в автономном режиме не является обязательным элементом всего процесса.Хотя главный работник может установить набор действительных для определенных индикаторов в процессе обучения, для полной автономной оценки вызов обслуживающего графического процессора через данные Spark имеет короткий период времени.Завершите все возможности процесса и можете указать большое количество сложных пользовательских индикаторов.

Метод параллельного обучения данных

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

Распределенное решение:

Использование собственной архитектуры TF PS-Worker, асинхронный параллелизм данных, использованиеtf.train.MonitoredTrainingSessionКоординировать весь тренировочный процесс. Все параметры модели хранятся в PS, и каждый рабочий процесс на каждом шаге извлекает данные для параллельных вычислений данных и возвращает градиент для завершения обновления. Текущая модель имеет пропускную способность одного рабочего процесса 1–2 Вт/с, а выполнение нескольких циклов эпох с данными на уровне миллиардов занимает несколько часов. При этом тестируется коэффициент ускорения модели на платформе, он составляет порядка 16 блоков, вычислительная мощность увеличивается линейно с количеством воркеров, после 16 карт наблюдается небольшой отрыв. В текущей деловой практике в основном 4-6 карт могут выполнять рутинные учебные задачи за короткое время.

Одномашинное решение с несколькими картами:

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

Предварительная обработка ансамбля модели TF

В процессе обучения модели необходимо использовать словарь Vocab для низкочастотной фильтрации признаков класса ID, а непрерывные признаки необходимо нормализовать. Здесь будет сгенерировано большое количество файлов предобработки, которые можно легко обработать в формате Libsvm в Spark в процессе офлайн-обработки, а затем загрузить в модель для обучения. Однако при прогнозировании онлайн необходимо загружать несколько словарей и нормализованных файлов предварительной обработки (файлы средних/стандартных значений и т. д.). Проблемы с выравниванием.

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

Для функций класса ID необходимо выполнить низкочастотную фильтрацию, а затем составить словарь.Модель TF считывает list_arr словаря.Каждый вывод передает ph_vals для получения ph_idx соответствующего словаря.

tf_look_up = tf.constant(list_arr, dtype=tf.int64)
table = tf.contrib.lookup.HashTable(tf.contrib.lookup.KeyValueTensorInitializer(tf_look_up, idx_range), 0)
ph_idx = table.lookup(ph_vals) + idx_bias

Для непрерывных функций после того, как Spark обработал значение avg/std, оно напрямую записывается в граф расчета модели TF как постоянный узел.Каждый ph_in проходит через два узла, чтобы получить соответствующий ph_out.

constant_avg = tf.constant(feat_avg, dtype=tf.float32, shape=[feat_dim], name="avg")
constant_std = tf.constant(feat_std, dtype=tf.float32, shape=[feat_dim], name="std")
ph_out = (ph_in - constant_avg) / constant_std

4.2 Онлайн-прогнозирование модели TF

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

Модель DeepFM, используемая ETA, обучена с помощью TensorFlow для создания модели в формате SavedModel.Платформа управления моделями должна поддерживать формат Tensorflow SavedModel.

План реализацииС Существует несколько реализаций загрузки моделей TensorFlow SavedModel в онлайн-сервисы:

Создайте свою собственную службу ЦП TensorFlow Serving и предоставляйте услуги через gRPC API или RESTful API.Это решение относительно просто реализовать, но оно несовместимо с существующей платформой управления моделями на основе Thrift.
Используйте службу TensorFlow Serving, предоставляемую платформой графического процессора Meituan AFO.
Вызов API Java, предоставленный TensorFlow, через JNI на платформе управления моделями.TensorFlow Java API, завершает поддержку формата SavedModel платформой управления моделями.

Наконец, TensorFlow Java API используется для загрузки SavedModel для выполнения прогнозов на ЦП.Когда тестовая партия = 1, время прогноза находится в пределах 1 мс, а в качестве схемы реализации выбирается схема 3.

режим удаленных вычислений

Базовая библиотека динамической компоновки C ++ для TensorFlow Java API имеет требования к версии libstdc ++.so, а версия GCC должна быть не ниже 4.8.3.Большинство компьютеров с ЦП, которые в настоящее время обслуживаются в сети, — это CentOS 6, а GCC по умолчанию версия 4.4..7. Если каждый онлайн-сервер для бизнеса поддерживает локальные вычисления TensorFlow SavedModel, тысячи серверов необходимо будет унифицированно обновить до версии GCC, что является большой рабочей нагрузкой и может создавать другие риски.

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

онлайн-выступление

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

Резюме и перспективы

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

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

об авторе

Цзи Зе, технический эксперт Meituan Dianping, в настоящее время отвечает за итерацию стратегии в группе машинного обучения отдела стратегии алгоритмов распределения.
Чжоу Юэ присоединился к группе алгоритмов отдела распределения Meituan Distribution в 2017 году и в основном отвечает за разработку стратегии ETA.
Сяньцзе, технический эксперт Meituan Dianping, присоединился к Meituan в 2018 году и в настоящее время в основном отвечает за исследования и разработки, связанные с глубоким изучением платформы данных алгоритма распределения.