Fed-LTD：通过联邦学习调度实现跨平台叫车

摘要

跨平台共享原始订单调度数据可能会泄露用户隐私和商业机密。这种数据隔离不仅损害用户体验，也降低平台的潜在收入。我们提倡跨平台网约车的联邦订单调度，多个平台可以在不共享本地数据的情况下协作做出调度决策。实现这一概念需要新的联邦学习策略，以应对订单调度背景下的有效性、隐私和效率方面的独有挑战。为此，设计了一个名为Federated Learning-to-Dispatch (Fed-LTD)的框架，它通过共享调度模型和决策来实现有效的订单调度，同时提供原始数据的隐私保护和高效率。我们使用滴滴GAIA数据集通过大规模的追踪驱动实验来验证Fed-LTD。广泛的评估表明，Fed-LTD在总收入方面比单一平台订单调度提高了10.24%到54.07%。

1.引言

网约车已成为普遍的交通方式，其中包括滴滴、Uber、Lyft等多个网约车平台。这些平台的核心问题是订单调度：如何将连续的出租车订单分配给合适的出租车司机。通常，这被建模为二分图匹配问题，传统上通过组合优化方法解决。最近，由于其实时处理现实世界动态的能力，数据驱动的解决方案，如强化学习（RL），已成为主流。尽管基于学习的订单调度取得了成功，但我们认为其有效性受到现实世界中数据隔离问题的限制。多个网约车平台在同一城市运营，大型平台可能包含几个附属出租车公司。每个公司或平台通常独立运作和管理自己的数据。这些数据可能包含客户隐私信息，如位置和旅行记录，或商业机密，如订单和司机分布。因此，这些数据不能自由聚合或跨平台共享，导致训练的调度模型和相应的调度决策是孤立的。例如，乘客在高峰时段在平台A上叫车，但附近没有司机，订单被取消。然而，另一个平台B可能在她的位置有空闲司机。由于数据隔离问题，订单不能由B接单，其过剩的供应资源被简单地浪费。总之，数据隔离问题不仅损害了平台的潜在收入，也损害了网约车的用户体验。为了打破网约车中的数据隔离问题，我们引入了联邦订单调度（FOD），这是一种专门针对跨平台网约车的联邦学习公式，多个网约车平台协作做出调度决策，而不共享他们的原始数据。然而，实现这一概念面临着独特的挑战，包括在跨平台网约车中如何最大化订单调度的总效用（例如，收入），如何在联邦订单调度中实现隐私保护和高效率。

 2.问题描述

2.1 订单调度(Order Dispatching) 

定义 1（司机集合）。𝑈 是一个司机集合，其中每个元素 𝑢 ∈ 𝑈 代表一个司机。𝑢.𝑙𝑜𝑐是司机的位置。

定义 2（订单集合）。𝑉 是一个订单集合，其中每个元素 𝑣 ∈ 𝑉 代表一个订单。𝑣.𝑜𝑟𝑖𝑔𝑖𝑛 和 𝑣.𝑑𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛 分别是订单的当前位置和目的地。𝑣.𝑟𝑒𝑤𝑎𝑟𝑑 是订单的收入。

司机集合和订单集合可构成一个二分图 𝐺 = (𝑈∪𝑉, 𝐸)，其中每条边 𝑒 = (𝑢, 𝑣)∈ 𝐸 的边重𝑤(𝑢, 𝑣) = 𝑣.𝑟𝑒𝑤𝑎𝑟𝑑。当𝑢.𝑙𝑜𝑐 和𝑣.𝑜𝑟𝑖𝑔𝑛 之间的距离超过阈值 𝑅 时，边将被剪除。

定义 3（匹配分配）。M 是二分图 𝐺 = (𝑈 ∪ 𝑉, 𝐸)上的匹配分配（或订单调度结果）。它是一组司机-订单对，其中每个元素 (𝑢, 𝑣)都必须满足以下条件：(1).𝑢∈ 𝑈, 𝑣∈ 𝑉, (2).我们进一步定义计算 M 中边权重总和的效用函数，即

给定二分图𝐺，要找到能最大化𝑆𝑈𝑀(M(𝐺))的匹配分配 M，是经典的最大二分图匹配问题，可以用匈牙利法[11]在多项式时间内求解。在实际订单调度场景中，订单和司机是以在线方式到达的[19]。在这种情况下通常使用基于批量的模型 [8，24，28]，订单调度问题可定义如下。

定义 4（订单调度问题）。给定一个批次序列〈1, 2, ......, 𝑇〉，在每个批次𝑡 中，自上一个批次以来到达的司机和订单可以构成一个二分图𝐺 (𝑡)。订单调度问题是为每个批次决定匹配的分配 M(𝑡)，使效用总和最大化，即：

一个简单的解决方案是在每个批次中进行最大二分图匹配。借助于大规模历史数据，基于强化学习（RL）的解决方案通常被应用以获得更好的性能。在这些方法中，通常会学习一个价值函数作为调度模型，并根据它做出决策。我们采用了[20]中最先进的订单调度方法作为我们的本地操作符，并专注于在联邦设置中同时聚合本地调度模型和决策。

2.2 联邦订单调度(Federated Order Dispatching)<