предисловие
Недавно документ местной команды логистики Али «Оценка времени цикла выполнения заказа для доставки еды по требованию» был принят в качестве устной презентации KDD'2020 Applied Data Science Track (ACM Knowledge Discovery and Data Mining (SIGKDD), CCF A Классная конференция, лучшая конференция в области интеллектуального анализа данных, уровень принятия устных докладов в 2020 году составляет 5,8%).
Проблема времени цикла выполнения заказа (OFCT: время цикла выполнения заказа) более сложна, чем общая проблема оценки времени, которая включает в себя соотношение спроса и предложения между ресторанами и пользователями, неопределенность времени приема пищи в ресторане и неопределенность райдера. поведение вопросы секса. В статье мы впервые подробно представили академическому сообществу вопрос оценки времени доставки и дали эффективное решение, которое в итоге было единодушно признано рецензентами.
У каждого есть опыт заказа еды на вынос на Ele.me, так как же Ele.me позволяет пассажирам вовремя и вовремя доставлять еду на вынос, чтобы каждый пользователь мог вовремя съесть горячую еду? Эта статья даст вам краткое введение.
Постепенно демонтируя весь процесс доставки еды на вынос (производительность: платформа Ele.me гарантирует, что пассажиры смогут вовремя доставить еду на вынос), мы анализируем существенную разницу между предполагаемым временем доставки еды на вынос и другими распространенными проблемами времени доставки (например, такси) различиями. , а также объяснять и объяснять характеристики, влияющие на продолжительность соблюдения. Для пользователя может быть видно только то, сколько времени потребуется, чтобы съесть еду на вынос, и за этим нам нужно извлечь множество влияющих факторов, чтобы обеспечить точность оценки времени выполнения. Мы вводим эти влияющие факторы в глубокую нейронную сеть, чтобы сделать вывод об их связи со временем выполнения, и дополнительно вводим скрытые векторы ресторанов, адресов пользователей и пассажиров, чтобы повысить эффективность прогнозирования модели. Наконец, мы предлагаем новый оператор нейронной сети постобработки для повышения скорости сходимости и точности модели. Представленная нами модель развернута в Ele.me, ежедневно обслуживая десятки миллионов пользователей.
Введение
Модель оценки времени выполнения оценивает период с момента, когда пользователь размещает заказ, до момента, когда курьер доставляет заказ пользователю (т. е. предполагаемое время доставки). Платформа Ele.me генерирует десятки миллионов заказов каждый день.В рамках мгновенной доставки оценка времени влияет не только на пользовательский опыт, но и на производительность водителя.Поэтому ее точность очень важна для платформы и не может быть оценена , Он слишком длинный (влияет на пользовательский опыт) и не может быть оценен как слишком короткий (гонщик не может выполнить доставку вовремя). На следующем рисунке показаны различные ссылки, участвующие в оценке времени.
Каждая ссылка в основном включает:
- Пользователь: пользователь размещает заказ до тех пор, пока заказ не будет доставлен ему. Каждый пользователь должен надеяться получить заказанные блюда вовремя.
- Ресторан: Ресторан принимает заказы с момента приготовления еды. Ресторан должен завершить приготовление еды как можно скорее, чтобы не повлиять на получение и доставку еды пассажиру.Если пассажиру нужно долго ждать, чтобы забрать еду, когда он прибывает в ресторан, пассажиру склонны к беспокойству, а некоторые пользователи также будут голодны.
- Райдер: Райдер с момента получения заказа до завершения доставки. Это включает в себя всадника, прибывающего в ресторан, а затем забирающего заказ из ресторана. В то же время пассажиры могут забирать несколько блюд из ресторанов, поэтому пассажирам необходимо дождаться всех заказов, прежде чем отправиться и доставить их.
- Платформа: платформа Ele.me должна координировать пользователей, рестораны, райдеров и учитывать эффективность дистрибуции. Это включает назначение и маршрутизацию заказов. Распределение заказов относится к назначению заказов подходящим находящимся поблизости пассажирам, а планирование маршрута относится к рекомендации разумных маршрутов вывоза и доставки для пассажиров.Этот маршрут должен учитывать как расстояние доставки пассажира, так и риск перегрузки заказа.
На картинке ниже показана информация, которую вы можете увидеть, когда заказываете еду на вынос на Ele.me.Время доставки рассчитывается по нашей модели оценки времени работы.
Разница между временем доставки еды на вынос и расчетным временем прибытия
Расчетное время прибытия (ETA) — это «расчетное время доставки», которое обычно оценивает время от пункта отправления до места назначения. Расчетное время доставки в сценарии такси — это типичная проблема ETA. Модель оценки времени выполнения заказа на вынос, предложенная в этой статье, оценивает время, которое проходит с момента, когда пользователь размещает заказ, до момента, когда пользователь доставляет еду пользователю. платформе, как показано ниже.
Расчетное время доставки является более особенным, чем расчетное время доставки, что в основном отражается в следующих двух аспектах:
- Необходимо учитывать больше влияющих факторов: общая задача расчетного времени доставки должна учитывать только погоду, условия движения, пространственно-временную информацию, информацию о маршруте и т. д., в то время как задача оценки времени доставки на вынос должна учитывать географическое положение ресторана. в дополнение к такой информации, как местонахождение, время приготовления заказа в ресторане и отправка системы диспетчеризации.
- Невозможно получить ключевую информацию: Ele.me рассчитала предполагаемое время доставки для пользователя, когда пользователь успешно разместил заказ, но в это время заказ не был принят перевозчиком, и перевозчик должен быть назначен системой. чтобы начать забирать и доставлять еду, поэтому мы не можем заранее получить информацию о пассажирах и их фактических путях доставки.
Разница между двумя вышеупомянутыми аспектами создает большие проблемы для точности задачи оценки времени доставки.
Какие характеристики обычно требуются для прогнозирования времени выполнения заказа на вынос?
Чтобы смоделировать время выполнения заказа на вынос, как правило, необходимо в полной мере использовать данные, связанные с информацией о заказе, включая:
- Пространственные функции: в том числе большое количество функций идентификации, таких как идентификатор области пользователя, идентификатор ресторана, идентификатор города и идентификатор сетки и т. д.
- Характеристики времени: включая час, является ли день рабочим днем и т. д., как показано на следующем рисунке (а).
- Опишите характеристики размера заказа: в том числе количество блюд, соответствующих заказу, и стоимость заказа и т. д.
Вам должно быть интересно, как цена заказа повлияет на время доставки? Когда сумма заказа, размещенного пользователем, высока, вес или объем, соответствующий еде, обычно велик. Например, пользователь заказал торт или заказал много чашек чая с молоком. Такой тип заказа с высокой суммой сумму гонщику трудно доставить, поэтому выполнение контракта занимает много времени. Рисунок (b) ниже показывает эту корреляцию.Можно видеть, что уровень цены заказа может описывать неявную информацию о том, трудно ли доставить заказ в определенной степени.
Влияние спроса и предложения на время выполнения
С точки зрения платформы количество заказов, размещенных пользователями, и количество заказов, полученных ресторанами, резко меняются в разное время, и это изменение соотношения спроса и предложения окажет большое влияние на фактическое время доставки.
Прежде чем представить построение характеристик спроса и предложения, позвольте мне ввести понятие «волна» в доставке на вынос: для группы заказов на райдере сгруппируйте заказ данной группы заказов, чтобы гарантировать, что все релевантные заказы в каждой группе сгруппированы. В эту группу входят способы получения и доставки заказа, а группа — текущая волна доставки пассажира. В ответ на изменения в спросе и предложении мы строим такие функции, как коэффициенты спроса и предложения на основе периодов и коэффициенты завершения. Чем выше соотношение спроса и предложения, тем больше будет средняя длина волны и время выполнения.
С другой стороны, когда скорость выполнения выше, можно сделать вывод, что гонщик выполнил доставку большего количества заказов, и в это время гонщик может продолжать выполнять заказы, отправленные системой.
Кроме того, мы используем текущее количество заказов, которые должен забрать ресторан (количество заказов, ожидающих доставки пассажиров после того, как ресторан получил заказ), чтобы описать загруженность ресторана. Ресторан увеличивается, а производственная мощность ограничена, это приведет к отставанию заказов.Если райдер уже прибыл в ресторан, то потребуется больше времени ожидания, чтобы получить еду, и, соответственно, когда ресторан становится загруженным, предполагаемое время выполнения модели будет больше.
Время обслуживания в ресторане
Время доставки заказа является важным фактором в модели оценки времени выполнения заказа на вынос, эта характеристика получается путем агрегирования исторического времени доставки ресторана. Тем не менее, текущие сложные проблемы стали серьезной проверкой точности расчета времени приема пищи, в том числе:
- Ресторану не хватает рабочей силы, чтобы нажимать кнопку заказа один за другим после того, как приготовление еды завершено, поэтому наша платформа не может полностью собрать реальную стоимость еды в ресторане. отметьте реальную еду ресторана время.
- В настоящее время платформа Ele.me в основном рассчитывает заказы, сгенерированные ресторанами в приложении Ele.me, и не имеет данных о заказах, сгенерированных ресторанами в других каналах, или данных о заказах в ресторане, поэтому сложно получить фактические данные о спросе и предложении. ресторанов.
- Реальное время приема пищи в ресторане совершенно случайно. Например, рестораны могут готовить блюда заранее для определенных блюд, и эти приготовленные заранее блюда могут быть поданы немедленно. Что касается блюд, которые ресторан должен приготовить, когда пользователь размещает заказ, водителю может потребоваться некоторое время подождать, чтобы получить еду после прибытия в ресторан, и фактическое время доставки этих свежеприготовленных заказов будет больше.
- Порядок заказов не обязательно указывает порядок подачи блюд в ресторане. Из-за ограниченного количества конфорок в ресторане соответствующие конфорки могут обрабатывать только фиксированные блюда, поэтому, если одно и то же блюдо появляется в партии заказов, бэк-шеф выберет их совместное приготовление, в этом случае время подачи часть ордеров будет явно перекошена.
В реальном приложении мы рассчитываем фактическое время приема пищи продавцом в соответствии со временем, когда продавец получает заказ, и временем, когда покупатель на самом деле щелкает, чтобы забрать еду, и в этом есть некоторые данные о шуме:
- Райдер нажимает, чтобы прибыть в ресторан сразу после принятия заказа.
- Райдер нажимает кнопку получения сразу после получения заказа.
Кроме того, для части обучающих образцов мы полагаем, что ресторан фактически приготовил еду, когда гонщик забирает еду, например, гонщик забирает еду поздно или гонщик щелкает, чтобы забрать несколько блюд в то же время. Для этих данных мы исключили определенную пропорцию при расчете характеристик времени приема пищи в ресторане.
Как разумно использовать информацию о гонщике
Ele.me делит каждый город на разные области с «сеткой» как наименьшей единицей с точки зрения платформы. Всадники в каждом пункте доставки Hummingbird будут обслуживать несколько фиксированных сеток вокруг сайта. Знакомство с деловыми районами или сообществами в сетке. излучаемого сайтом, определяет эффективность его распределения. Как видно из рисунка ниже, поскольку водитель знаком с расположением ресторана и сообществом, в котором находится пользователь, в процессе получения или доставки еды нет обходных путей.
Когда пользователь успешно размещает заказ, приложение Ele.me немедленно отображает расчетное время доставки для пользователя.В настоящее время неизвестно, какому гонщику будет назначен заказ. Чтобы в полной мере использовать влияющие факторы, связанные с гонщиком, мы характеризуем каждого гонщика, чей заказ может быть принят, в зависимости от расстояния, на котором гонщик может забрать еду, сколько заказов гонщик в настоящее время принимает и т. д. На вынос модель оценки времени производительности, а затем используйте механизм внимания для извлечения информации о последовательности гонщика, чтобы улучшить способность прогнозирования модели.
ETA сегмента доставки для похожих заказов в нескольких измерениях
ETA сегмента доставки относится к расчетному времени, которое требуется пассажиру, чтобы выйти из машины рядом с пунктом назначения (местонахождение пользователя) и доставить еду пользователю, что является конечным звеном доставки пассажира.
Чтобы оценить ETA сегмента доставки, мы теоретически можем напрямую использовать модель регрессии для обучения, но обычно используемая модель регрессии обычно преобразует входные данные в ряд функций и находит взаимосвязь между этими влияющими факторами и целевым результатом. с помощью обучения с учителем, чтобы удобно изучать и улучшать способность модели к обобщению.Эти отношения обычно параметризуются в гладкую функцию, основанную на моделях нейронной сети и ансамблевого дерева.Однако недостатком этого гладкого предположения является то, что оно не может хорошо обрабатывать длиннохвостые нерегулярные случаи, что может повлиять на работу пользователей. Например, когда пассажирам нужно подняться на высотном лифте, чтобы доставить еду, им, возможно, придется долго ждать в часы пик, и системе сложно делать такие прогнозы в реальном времени. Как вы можете видеть на изображении ниже, водитель провел в здании 7,6 минуты, доставляя еду.
Чтобы частично решить эту проблему, мы опираемся на идею недавней языковой модели на основе памяти [1], берем исторические заказы в качестве корпуса для оценки времени доставки и строим многомерные признаки для представления каждого исторического порядка. Когда генерируется новый заказ, мы одновременно ищем несколько исторических заказов, похожих на новый заказ, на основе K ближайших соседей, а затем делаем средневзвешенное фактическое время доставки этих похожих заказов в качестве расчетного времени доставки новый порядок. Наконец, мы вводим предполагаемое время доставки на основе поиска K ближайших соседей в качестве функции в модель оценки времени выполнения заказа на вынос.
Как работать с данными с длинным хвостом
Оценка времени - это, по сути, проблема регрессии. В процессе обучения модели мы обнаружили, что модель медленно сходится, а производительность перекрестной проверки отклоняется от ожиданий. Анализируя причины, мы обнаружили, что распределение данных подгонки модели и распределение фактического времени выполнения сдвинулось, реальное время выполнения на самом деле представляет собой длиннохвостое распределение со смещением вправо, что эквивалентно тому, что небольшая часть реального времени доставки заказа слишком велика, и модель не изучила его. В статье мы предлагаем новую нейронную сеть постобработки.Оператор масштабирует и преобразует результаты подгонки модели оценки времени выполнения заказа на вынос, чтобы улучшить скорость сходимости и точность модели. Оператор постобработки может быть описан как:
в,
$y_o^{out}$: указывает подходящее значение модели OFCT.
$\mu^{real}$: представляет среднее значение реального значения выборки.
$\sigma^{real} $: представляет стандартное отклонение истинного значения выборки.
$\mu^{ini}$: указывает среднее значение инициализации модели OFCT.
$\sigma^{ini}$: указывает стандартное отклонение инициализации модели OFCT.
После автономного обучения и проверки оператор постобработки может эффективно повысить скорость сходимости и точность модели оценки времени выполнения заказа на вынос.
Недавно мы исследовали новый оператор постобработки: адаптивное обратное преобразование Бокса-Кокса.По сравнению с оператором постобработки, предложенным в этой статье, адаптивный обратный оператор Бокса-Кокса лучше подходит для данных с длинными хвостами. , так что эффект модели был дополнительно улучшен, и этот оператор был применен к онлайн-выводу.
Экспериментальный эффект
Предлагаемая нами модель оценки времени выполнения на вынос использует «кодирование и прогнозирование» в качестве основной структуры модели, и конкретная структура показана на рисунке ниже.
Среди них модуль Nearest Courier Index реализует введенное выше кодирование информации о гонщике.Этот модуль позволяет модели в полной мере использовать информацию о гонщике, который может получать заказы.Постобработка – это оператор постобработки, который позволяет модели быстрее сходиться и Также улучшите точность модели.
До того, как мы предложили модель оценки времени выполнения заказа на вынос, онлайн-модель оценки времени работала стабильно в течение определенного периода времени, поэтому мы провели эксперименты AB, используя существующую онлайн-модель в качестве основы. Экспериментальные данные на рисунке ниже показывают, что по сравнению с исходной моделью MAE относительно снижена на 9,8%, а количество жалоб пользователей относительно снижено на 19,3%.Ошибка прогнозирования и частота жалоб пользователей значительно улучшились, что оказывает значительное влияние на пользовательский опыт положительный эффект.
Резюме и перспективы
В этой статье мы представляем модель Ele.me для оценки времени выполнения заказов на вынос, которая в настоящее время работает онлайн и обслуживает пользователей и доказала свою эффективность посредством оценки в автономном режиме и онлайн-тестирования.
В дальнейшем мы в основном сосредоточимся на следующих двух аспектах:
- Время приема пищи является одним из факторов, влияющих на модель оценки времени выполнения еды на вынос, что очень важно, но обработка времени приема пищи в настоящее время относительно проста, поэтому есть значительные возможности для улучшения;
- Кроме того, мы разработаем общую структуру модели, то есть многозадачное обучение для времени приема пищи и времени выполнения.
использованная литература
[1] Urvashi Khandelwal, Omer Levy, Dan Jurafsky, Luke Zettlemoyer, and Mike Lewis. Generalization through memorization: Nearest neighbor language models. In ICLR, 2020.
Профиль команды
Все авторы из местной команды умной логистики Alibaba.С момента своего создания в 2017 году команда была разделена на 5 групп в соответствии с проектом: планирование специальной доставки, регулирование давления, оценка времени / давления, служба определения местоположения и диапазон распределения. подразделение делового района. За три года непрерывных усилий мы с нуля создали умный мозг колибри, который внес огромный вклад в снижение затрат и повышение эффективности работы колибри. Мы всегда настаиваем на использовании данных и алгоритмов для повышения операционной эффективности и всегда разрабатываем по принципу «в первую очередь пользователи, а уже потом пассажиры», чтобы предоставить клиентам и пассажирам лучший опыт.
В будущем мы будем придерживаться политики одновременного развития алгоритмических инноваций и бизнес-инноваций не только для того, чтобы помочь бизнесу достичь больших успехов, но и для того, чтобы продолжать делать инновации и прорывы в алгоритмах.