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

Введение

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

Соответствие на основе времени получения

Существующее решение состоит из трех основных этапов, а именно этапа поиска, этапа фильтрации и этапа ранжирования. На рис. 1 показано визуальное представление этих шагов.

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

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

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

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

Сопоставление на основе оценки DRAC

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

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

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

Модель DRAC обучается по расписанию на Kubeflow — популярной платформе машинного обучения на базе Kubernetes. На рис. 2 показан развернутый конвейер. Мы извлекаем данные из Hive и преобразуем их в функции модели с помощью PySpark. Набор функций является входом компонента обучения модели. После обучения модели проверяются рабочие характеристики модели. Если все проверки пройдены, мы сохраняем обученную модель в S3. Процесс Kubeflow также создает запрос на вытягивание в репозиторий Github, в котором размещена модель, включающая сериализованную модель и все необходимые ресурсы для повторного тестирования модели. Наконец, мы уведомляем всех заинтересованных лиц об обучении модели через сообщения Slack.

АБ-тестирование

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

Измерив несколько внутренних ключевых показателей эффективности бизнеса, мы обнаружили, что скорость принятия водителем запросов на поездку увеличилась в среднем на 13,3% на разных рынках. Кроме того, нам требуется в среднем на 15 % меньше времени, чтобы найти соответствие запросу на поездку. Beat также выигрывает от увеличения количества завершенных поездок. Однако есть и отрицательный побочный эффект, поскольку мы наблюдаем, что пассажиры склонны чаще отменять свои запросы.

Заключение

Сопоставление водителей с запросами на поездки — важнейшая функция любого приложения для заказа поездок. Со временем мы сделали нашу технологию сопоставления более учитывающей различные факторы, чтобы обеспечить беспрепятственный процесс посадки как для пассажиров, так и для водителей. Домен Beat’s Matching развивает подход машинного обучения, чтобы учитывать большое количество факторов при поиске наиболее подходящего водителя для поездки. Компания AB, тестирующая решение DRAC, демонстрирует значительные улучшения практически во всех изученных бизнес-KPI.

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

Если вам была интересна эта статья и вы ищете новый вызов, ознакомьтесь с нашими открытыми ролями.

Об авторах

Команда по машинному обучению в рамках домена Beat’s Matching — это междисциплинарная команда, в которую входят инженеры по машинному обучению и инженеры по данным, работающие в рамках домена и отвечающие за предоставление функций, основанных на науке о данных и машинном обучении. Мы работаем над полным жизненным циклом проекта Data Science: от формализации требований к продукту до сбора и анализа соответствующих данных, обучения моделей машинного обучения и запуска их в производство. Мы уже разработали решения для таких задач, как эффективное сопоставление водителей с пассажирами и оценка продолжительности поездки.

Мы Акис Контонасиос, Вассилис Статопулос и Одиссеас Бурнас.