EXHOLD：滴滴大规模网约车匹配中基于体验感知的实时保持控制

# EXHOLD：滴滴出行大规模网约车匹配中基于体验感知的实时保持控制

来源：https://arxiv.org/html/2607.09090

###### 摘要。在大型网约车匹配系统中，*保持控制*是一种高杠杆机制，用于改善端到端的乘客与司机体验：通过有选择地延迟某些司机-订单匹配对，系统可以等待更好的机会、减少取消和过度等待、减轻司机无效行程，最终提升订单成交率。在实践中，许多工业级的保持策略依赖于对多个预测模型进行启发式阈值判断，这在非平稳交通条件下可能变得脆弱，且难以针对多个体验导向目标进行优化。我们提出**EXHOLD**，一个可部署的两阶段框架，将*体验感知的匹配对评估*与*保持时间执行*解耦。在第一阶段，我们学习一个决策模型，将每个司机-订单对分配到离散且可解释的*体验等级*，优化一个聚合了匹配漏斗中多个满意度相关信号的统一目标。在第二阶段，我们通过对经验分位数进行约束优化，求解一个单调的保持时间计划，明确强制执行服务护栏，以限制对有前景匹配的不必要保持，同时最大化整体体验改善。我们通过在滴滴出行巴西生产网约车匹配系统中进行在线随机A/B实验来评估**EXHOLD**。结果表明，在市场效率和乘客-司机体验方面均有一致提升：**EXHOLD**提高了订单完成率和司机收入，同时显著减少了乘客在接单前和接单后的取消，并改善了关键漏斗效率信号（如从呼叫到接单的时间更短）。我们进一步进行了针对性的消融实验和行为深度分析，表明**EXHOLD**的两个阶段对观察到的增益都至关重要，并且该策略在时空异质性下做出了校准的决策。**EXHOLD**已逐步上线并目前正在巴西市场生产环境中运行。网约车；决策制定；表示学习；上下文老虎机；约束优化 ††已被第32届ACM SIGKDD知识发现与数据挖掘会议（KDD 2026）接收。这是arXiv作者版本。

## 1. 引言

大型网约车平台在严格的延迟、可靠性和服务质量约束下，解决持续不断的匹配决策流 (Xu等人，2018 (https://arxiv.org/html/2607.09090#bib.bib29))。对于每个传入订单，系统评估许多候选司机-订单对（DOpair），并且必须决定不仅要*与谁*匹配，还要*何时*匹配 (Wang等人，2021 (https://arxiv.org/html/2607.09090#bib.bib26); Zhang等人，2017 (https://arxiv.org/html/2607.09090#bib.bib34))。此过程中的一个关键杠杆是*保持控制*：有选择地将某些DOpair候选者保持一段系统设定的时间，以便系统可以等待更好的机会、减少取消和过度等待、减轻司机无效行程——最终改善端到端的乘客-司机体验和订单成功率 (Tu, 2024 (https://arxiv.org/html/2607.09090#bib.bib24); Afèche等人，2023 (https://arxiv.org/html/2607.09090#bib.bib2))。保持控制强大但微妙：过于激进的策略可能抑制良好匹配并损害平台服务水平，而过于保守的策略则影响甚微 (Xu等人，2018 (https://arxiv.org/html/2607.09090#bib.bib29); Afèche等人，2023 (https://arxiv.org/html/2607.09090#bib.bib2))。

##### 为什么保持控制在生产中具有挑战性。保持决策本质上是多目标、顺序的，并与匹配流水线紧密耦合 (Supian等人，2024 (https://arxiv.org/html/2607.09090#bib.bib19))。首先，体验退化通过*异质漏斗结果*表现出来：乘客在司机接单前取消（PCBA）、司机未响应、乘客在司机接单后取消（PCAA）以及司机接单后取消（DCAA），这些对用户伤害和效率影响各不相同 (Xu等人，2018 (https://arxiv.org/html/2607.09090#bib.bib29); Wang等人，2021 (https://arxiv.org/html/2607.09090#bib.bib26))。其次，保持是一种延迟作用机制：保持一个候选者会改变未来状态，例如乘客等待时间、局部供需状况以及系统之后看到的可行匹配集合 (Afèche等人，2023 (https://arxiv.org/html/2607.09090#bib.bib2); Barbour和Luiz，2019 (https://arxiv.org/html/2607.09090#bib.bib3))。此外，生产系统需要明确的*服务护栏*：系统必须限制对有前景匹配的不必要保持，并在非平稳交通条件下保持稳定 (Yan等人，2020 (https://arxiv.org/html/2607.09090#bib.bib30); Sühr等人，2019 (https://arxiv.org/html/2607.09090#bib.bib18))。

##### 启发式模型阈值策略的局限性。许多工业保持模块被实现为对多个预测模型的启发式阈值判断，例如将每个司机-订单对映射到一个固定或动态阈值，然后将预测器与该阈值进行比较以决定保持或释放 (Chen等人，2021 (https://arxiv.org/html/2607.09090#bib.bib4); Wen等人，2024 (https://arxiv.org/html/2607.09090#bib.bib27); Yatnalkar，2019 (https://arxiv.org/html/2607.09090#bib.bib32))。虽然作为基线有效，但这种范式在实践中面临三个反复出现的局限性：（i）*错误累积*：当多个模型被链接时，小的校准偏移通过决策规则放大 (Somalwar等人，2025 (https://arxiv.org/html/2607.09090#bib.bib17))；（ii）*弱多目标协调*：使用手动调整的阈值规则难以同时优化跨漏斗的多个体验相关信号（例如，PCBA、PCAA、DCAA和乘客过度等待）(Naumov和Keith，2023 (https://arxiv.org/html/2607.09090#bib.bib15))；（iii）*有限的时间推理*：时间效应通常由静态校准近似，这在交通变化下可能变得脆弱。因此，这些策略在时空异质性下可能难以调整以改善体验，并且可能无法在服务约束下提供显式、可审计的“多少保持是可以接受的”控制 (Lee等人，2022 (https://arxiv.org/html/2607.09090#bib.bib11); Tirachini，2020 (https://arxiv.org/html/2607.09090#bib.bib23); Yang等人，2020 (https://arxiv.org/html/2607.09090#bib.bib31))。

##### 我们的方法：将体验感知评估与保持时间执行解耦。我们提出**EXperience-aware HOLD**（**EXHOLD**），一个可部署的两阶段框架，用于工业网约车匹配系统中的保持控制 (图2 (https://arxiv.org/html/2607.09090#S3.F2))。**EXHOLD**的关键思想是将*保持什么*与*保持多久*分开，方式与生产约束和体验导向目标保持一致：
- •**第一阶段（体验感知的匹配对评估）**。我们学习一个决策模型，将每个DOpair分配到一个离散的、可解释的*体验等级*。等级划分优化了一个统一目标，该目标聚合了跨匹配漏斗的多个乘客-司机满意度相关信号（订单完成、不同阶段的取消以及等待相关指标，如图1 (https://arxiv.org/html/2607.09090#S2.F1)所示）。为了支持在非平稳交通下的鲁棒性，第一阶段引入了基于Transformer的时间表示 (Vaswani等人，2017 (https://arxiv.org/html/2607.09090#bib.bib25))和LinUCB (Chu等人，2011 (https://arxiv.org/html/2607.09090#bib.bib5))头部，提供稳定的在线决策。
- •**第二阶段（护栏约束的保持时间优化）**。给定来自第一阶段的体验等级，我们通过对经验分位数进行约束优化，计算一个单调的保持时间计划 (Kotary等人，2021 (https://arxiv.org/html/2607.09090#bib.bib10); Liang等人，2022 (https://arxiv.org/html/2607.09090#bib.bib12))。此阶段明确强制执行服务护栏，以限制对有前景匹配的不必要保持，并提供一个可控制保守性的工具，从而可以在生产平台安全部署。

**EXHOLD**的解耦设计不仅仅是工程上的便利，也是对在异质反馈、严格操作约束以及生产中对显式护栏的需求下，难以端到端优化保持控制策略这一挑战的原则性回应 (Feng等人，2021 (https://arxiv.org/html/2607.09090#bib.bib6); Liu等人，2025 (https://arxiv.org/html/2607.09090#bib.bib13))。

##### 真实世界部署与关键发现。我们在滴滴出行巴西生产网约车匹配系统中部署**EXHOLD**，并通过大规模A/B实验进行评估。结果表明，**EXHOLD**在提高订单成功率和司机福利方面带来了一致的改善，同时减少了降低体验的取消并提高了匹配效率，表明在实际运营中实现了更好的端到端乘客-司机匹配体验。除了总体结果，我们提供了（i）漏斗级分析，将收益归因于曝光后转化率的提高和更少的取消，以及（ii）消融实验和行为深度分析，验证了多信号体验建模和护栏约束保持时间优化的作用。在A/B验证之后，**EXHOLD**已逐步上线并在市场规模部署，服务于巴西市场的实时流量。

##### 贡献。我们将主要贡献总结如下：
- •我们将网约车匹配中的保持控制形式化为一个以乘客-司机体验为中心的决策问题，并设有明确的服务护栏以限制不必要保持。
- •我们提出**EXHOLD**，一个实用的两阶段框架，将体验感知等级分配与保持时间执行解耦，结合了表示学习、上下文老虎机和基于经验分位数的约束优化。
- •我们开发了一个体验导向的目标和训练流程，聚合了网约车漏斗中的异质信号。在线A/B实验显示，订单成功率和司机福利提高，损害体验的取消减少，漏斗效率加快；在线消融进一步确认了第一阶段和第二阶段对于一致收益都是必不可少的。

## 2. 问题形式化

参见图注

图1. 网约车乘客-司机匹配中异质体验反馈的示意图。在时间步(t)时，系统首先识别所有可用的候选司机。一个保持决策模块（以蓝色突出显示）然后决定哪些司机应被保持一段时间，而其余候选者则被传递给调度引擎进行广播。在司机的决策过程及随后的接驾过程中，可能发生各种异质的体验反馈（以黄色突出显示）。

我们将大规模网约车匹配中的保持控制形式化为一个具有*体验导向目标*和*服务护栏*的约束决策问题。我们的形式化强调了在优化和评估中都会产生实质性影响的工业方面：（i）DOpair决策单元及其在匹配流水线中的位置；（ii）对应不同乘客/司机体验成本的异质漏斗结果；（iii）通过时间和乘客-司机交互产生的延迟效应；（iv）限制对有前景匹配不必要保持的显式护栏。

### 2.1. 系统上下文与决策单元

生产网约车平台针对每个传入订单持续评估候选的司机-订单对。我们将原子*决策单元*定义为一个司机-订单对（DOpair），代表在特定时间对特定附近司机评估的特定订单。保持控制应用于这些候选者，然后才由下游广播/分配模块执行，因此可以改变暴露给司机的候选者集合以及已接受和已完成的订单构成。具体来说，在决策时间步(t)，系统观察一个DOpair的状态向量(s_t ∈ S)，该向量聚合了：
- •**订单上下文**：当前乘客等待时间及其演变、OD属性、费用/距离代理、以及其他订单特征；
- •**司机上下文**：司机可用性/状态、近期活动模式、历史响应统计量、以及其他司机特征；
- •**时空特征**：一天中的时间、局部供需状况（例如，附近可用司机和订单）、历史供需、以及其他时空特征；
- •**系统特征**：估计接驾距离和时间、估计行程时间、以及其他系统增强的匹配特征。

这些信号共同表征了*即时可行性*（例如，接驾距离/时间）和*体验敏感性*（例如，累积等待时间和供需压力）。

### 2.2. 体验等级与保持时间执行

保持决策决定一个DOpair是应立即释放给下游流水线还是暂时延迟。由于延迟信用分配、不安全探索和紧张的延迟预算，在生产中直接优化连续保持持续时间是困难的。因此，我们将在线决策建模为选择一个离散的*体验等级*：(a_t ∈ A = {0, 1, ..., K})，其中较大的(a_t)表示从体验角度看较不利的配对，因此需要更强的保持。每个等级随后映射到一个保持时间(x_{a_t})，该时间由约束优化过程离线计算（第二阶段，第3.3节 (https://arxiv.org/html/2607.09090#S3.SS3)）。在线执行应用延迟动作策略：(保持时间 = x_{a_t}, x_0 = 0 ≤ x_1 ≤ ... ≤ x_K)。这种设计使在线推理快速且有界，同时通过护栏使时间组件显式可控。

### 2.3. 保持的异质体验成本

在DOpair被释放（立即或保持后）之后，系统根据乘客和司机行为以及下游匹配演变。每个决策导致几个互斥结果之一：CBA、司机未响应、PCAA或DCAA；这些时间延迟的结果如图1 (https://arxiv.org/html/2607.09090#S2.F1)所示。这些结果对应于异质的体验成本：PCBA通常与接单前的摩擦和过度等待有关，PCAA直接浪费司机努力并导致乘客糟糕体验，DCAA则可能放大低效和后续取消。因此，保持控制必须优化*多信号体验目标*，而不是单一的代理结果。

### 2.4. 保持目标：服务护栏下的体验效用最大化

理想情况下，我们寻求一个策略(π)，将DOpair状态映射到体验等级，以最大化期望的体验效用，同时满足明确的服务护栏。令(y_t ∈ Y)表示实现的结果类别，令(r_{oracle}(s_t, a_t, y_t))表示聚合多个体验相关结果的oracle奖励，其中(s_t)是实时的DOpair状态（第2.1节 (https://arxiv.org/html/2607.09090#S2.SS1)），(a_t)是由策略生成的实时保持动作（是否保持以及保持多长时间）。那么约束保持目标可以表示为：
(3) (max_π) (E_π[∑_t γ^t r_{oracle}(s_t, a_t, y_t)])