---
title: "高德路线规划演进：从工业引擎到端到端时空基座（MobilityBench + TransitLM 双路线）"
source: wechat
source_url: https://mp.weixin.qq.com/s/yTGfgsTp2x75EJpDdpRVcQ
author: 机器学习研发部
account: 高德技术
account_description: "高德官方技术号，关于高德的技术创新均呈现于此"
published: 2026-06-16T17:52:00+08:00
ingested: 2026-06-16
sha256: 85655161235bc1e965548c50c551242b2265031a831fb88171d46fb52b523103
tags: [mobilitybench, transitlm, rllm, route-llm, gaode, amap, amap-ml, route-planning, agent-benchmark, kdd-2026, agent-evaluation, map-free, end-to-end, route-agent, transit, gps, continual-pre-training, sft, route-generation, spatial-foundation-model, arxiv-2602-22638, arxiv-2605-22355, 阿里高德]
content_type: research-product
language: zh-CN
---

# 高德路线规划演进：从工业引擎到端到端时空基座

> 原创 / 机器学习研发部 / 高德技术 / 2026-06-16 17:52 / 北京

## 一、为什么要重新思考"路线规划"？

每天数以亿计的用户从 A 点导航到 B 点。这一次"算路"背后，是一套打磨多年的工业体系：路网建模、Dijkstra/A*/RAPTOR 等图搜索算法，加上为十万级 QPS、毫秒级响应而生的图预处理与性能优化，再叠上海量启发式规则与排序模型——已经不只是输出"最快"或"最短"，而是在为不同的人挑出他更可能选的那条。

> **这套体系达到了工业级稳定，但也暴露出一个关键挑战——它的灵活性有限。**

**典型痛点**：
- "顺路去加油站再去公司，别走二环。"
- "坐公交去天安门，能地铁就地铁。"

这些自然语言需求，今天的工业系统几乎无法直接表达、也无法稳定满足——因为它能消费的只是"起点—终点—偏好枚举"，不是千变万化的自然语言。

**高德的回应**：两条相互支撑的技术路径：

| 路径 | 思路 | 代表工作 |
|------|------|---------|
| **路径一** | 路线 Agent + 工业引擎（让 LLM "听人话、调工具、算好路"） | **MobilityBench** |
| **路径二** | RLLM (Route LLM) — 让模型从真实出行样本中学习，不查地图、不调引擎，直出一条结构有效的路线 | **TransitLM** (业界首个 RLLM) |

---

## 二、MobilityBench：让 Agent 学会"听人话、调工具、算好路"

### 2.1 问题：Agent 范式没有"考卷"

LLM Agent 调用导航工具来完成路线规划，是当下最现实的一条路：

- LLM 负责理解自然语言、做意图分解、做调度决策
- 导航服务作为确定性工具，提供工业级的算路、ETA、路况、公交时刻等能力
- Agent 把两者拼起来，输出一条满足用户复杂诉求的路线

> **但要把这件事真正做扎实，第一道坎不是模型本身，而是——怎么科学地评估一个路线规划 Agent 到底好不好？**

现有学术 Benchmark（TravelBench、TravelPlanner）大多停留在"高层行程安排"，对真实世界的路线规划场景覆盖不够；而真实地图 API 又是非确定性的：今天问一次和明天问一次，路况、ETA、甚至可用站点都可能不一样，导致评测无法复现。

> **把这道坎啃下来，价值是双向的**：
> - **对内**：成为驱动路线 Agent 持续迭代的"风洞"——每一次 Prompt 改动、每一次工具升级，都能跑出可比较的分数
> - **对外**：为全行业树立起统一的评测基准，让行业发展和技术比拼拥有公认标准

### 2.2 解法：MobilityBench

**MobilityBench**（已被 KDD 2026 录用为 Oral）—— 首个面向真实世界出行场景的路线规划 Agent 基准。它做了三件关键的事：

| 创新 | 含义 |
|------|------|
| **真实大规模数据** | 从高德海量、脱敏的真实用户 query 中提炼，覆盖多城市、多出行方式、多重约束的路线规划意图 |
| **确定性 API 回放沙箱** | 把所有依赖的地图服务"录"下来，评测时做确定性回放，彻底剥离线上服务波动带来的噪音 |
| **多维评测协议** | 不仅看最终输出的"对不对"，还分别评估指令理解、规划能力、工具使用、效率等子能力 |

### 2.3 三个关键发现

**① 最强模型也只做对 ~69%**

用 MobilityBench 评测了 GPT-5.2、Claude-Opus-4.5、Gemini-3、DeepSeek-V3.2 等主流大模型——**最高最终通过率（FPR）也只有约 69%**。说明真实场景下的路线规划 Agent，远没有被解决。

**② 真值构造方法被验证**

围绕真实用户 query 沉淀了一整套真值标注与生成 pipeline。这套方法生成的监督信号是否"学得动"？答案是肯定的——**用 17K 条按此方法构造的数据对 Qwen3-4B 做 LoRA SFT，最终通过率从 53.5% 跃升到 69.8%（+16pp）**，**4B 小模型直接追平 235B 级通用大模型**。这条 pipeline 还可以源源不断地构造更多训练数据，撑起后续路线 Agent 的专项训练与 RL。

**③ 错误来源初步定位**

对失败 case 的人工分析显示：

- **工具调用相关错误约 36%**
- **规划推理相关错误约 26%**

是目前最显著的两类问题，分别指向**工具函数对齐**与**长程约束推理**两个优化方向。

### 资源链接

- 📄 论文：https://arxiv.org/abs/2602.22638
- 📦 代码：https://github.com/AMAP-ML/MobilityBench
- 🤗 数据：https://huggingface.co/datasets/GD-ML/MobilityBench

---

## 三、TransitLM：不要地图、不要算法引擎，大模型直接"画"出公交路线

### 3.1 一个挑衅性的问题

> **如果说 Agent 路线还在"借用导航服务的力"，那我们不禁想问一个更激进的问题：路线规划，能不能直接从数据里学出来？地图、路网、图搜索算法，能不能彻底不要？**

直觉上这听起来像痴人说梦——通用大模型（GPT、Qwen 等）即使再强，让它直接生成一条公交路线，输出的往往是幻觉站点、断开的换乘、上下错的车站。原因也很自然：**它从未真正"见过"一个城市的公交拓扑**。

但是反过来想：公交平台本身每天产生海量真实路线规划日志，里面隐式地编码了路网拓扑、路线生成以及指标平衡等关键知识。**这些数据本身就是一座金矿**。

### 3.2 解法：TransitLM

**TransitLM**—— 一发布就在社区引起了广泛的讨论与关注。它的关键设计有三点：

| 维度 | 内容 |
|------|------|
| **数据规模** | 4 个中国大城市，1300 万+ 真实公交路线记录，覆盖 12 万+ 站点、1.3 万+ 线路 |
| **训练范式** | 先做 **Continual Pre-training**（让模型把站点、拓扑、空间关系内化进去），再做 **SFT**，覆盖三个核心任务——最优路线生成、偏好感知规划、多路线生成 |
| **评测体系** | 从连通性、上下车站可达性、路线重合度、数值准确性等多个维度衡量 |

最终得到的 TransitLM 模型，**不查地图、不调站点表，仅凭起终点（甚至是任意 GPS 经纬度）就能直接输出结构有效、连通可走的公交路线**。

### 3.3 三个关键发现

**① 端到端的 map-free 公交路线规划是可行的**

在传统路线规划上，**TransitLM 的效果和线上工业级公交导航服务基本持平**——表明仅凭丰富的出行数据即可取代传统的基于地图的路径规划引擎。**在自然语言算路上，TransitLM 的效果也和用最优闭源大模型为基座的 Agent + 工具效果相当**。

**② 隐式空间定位能力能够从数据中自然涌现**

> **仅给定起点和终点的 GPS 坐标，该模型就能学习将任意坐标解析为相应的上车和下车站点，而无需任何显式的坐标到站点映射或地理数据库，从而有效地将交通网络的空间拓扑结构内化。**

**③ 单一模型可泛化至不同的规划目标**

联合训练的模型在全部三个核心任务上均达到或超越了各任务专用模型的表现，且未出现负迁移现象——**这证实了数据集中编码的公交知识是任务无关的**。

### 资源链接

- 📄 论文：https://arxiv.org/abs/2605.22355
- 📦 代码：https://github.com/HotTricker/TransitLM
- 🤗 数据：https://huggingface.co/datasets/GD-ML/TransitLM
- ⚙️ Demo：https://transit-lm.amap.com/

---

## 四、两条路线的辩证：Agent 与端到端，谁会赢？

> **我们经常被问：到底是 MobilityBench 这条 Agent 路赢，还是 TransitLM 这条端到端路赢？我们的答案是：两条都会赢，只是节奏不同。**

### Agent 路线（对应 MobilityBench）

**优点**：
- **快**：复用已有导航服务，工程门槛可控，能快速把"自然语言定制"落到亿级用户
- **稳**：路线由确定性的工业引擎产出，安全、可追溯
- **空间大**：意图理解、工具编排、追问、个性化记忆——每一个子模块都还有显著提升空间

**局限**：
- **依然依赖传统导航服务**——Agent 解决不了引擎本身的天花板
- 多轮、复杂、长尾意图下，Agent 还需要持续打磨

> **我们的判断：在很长一段时间内，Agent 范式都会是路线规划的主流形态，它是把"AI 时代的路线规划"落地的最现实通路。**

### 端到端路线（对应 TransitLM）

**优点**：
- **架构极简**：不依赖地图、不依赖算路引擎，模型即系统
- **天花板高**：把整个城市的时空知识压进模型权重，理论上可以建模引擎做不到的隐式偏好
- **可成长**：和 LLM 在数学、编程领域类似，数据越多、模型越大、效果越强——是一条"会自己长大"的路径

**当前的硬骨头**：
- **动态信息**：事件、施工、拥堵、站点增减——这些时变信息今天的 LLM 还不够擅长
- **可控性、可解释性、安全性**：相比工业引擎，仍需建立一套新的护栏

> **但我们坚信：正如 LLM 在一个又一个领域突破人类基线，"LLM + 动态时空信息"的端到端直出路线，将以更优异的效果，尤其是在自然语言交互的新范式下，成为未来的领先方向之一。**

---

## 五、更远一步：把时空，编码进基座模型

把这两条路线放在一起，会浮现一个更宏大的图景：

- **MobilityBench** 这条 Agent 路让我们看到，**LLM 可以学会"理解人 + 调度世界"**
- **TransitLM** 这条端到端的路让我们看到，**LLM 可以学会"挂接空间 + 直出路线"**

**那么自然的下一步是**：

> 当我们把整个地理空间——道路、POI、路线、事件、拥堵 …… ——都编码进一个统一的大模型时，是不是就真正创造了一个 **"时空领域的基座模型"**？

它对内可以驱动路线、推荐、调度、预测一系列业务；对外则可能是出行、物流、城市治理共通的底座。**这正是我们正在前进的方向——面向未来的路线规划，本质上是面向未来的"时空智能"。**

---

## 六、结语：路线规划的三步未来

回到开头的那个问题：路线规划的未来是什么？

**当下** —— 一个会听人话、会用工具、会自我评估的路线 Agent，正在以工业级稳定性走进每一个用户的日常出行

**不远的明天** —— 一个不再依赖地图、能直接从坐标"画"出路的端到端时空模型，正在以惊人的速度逼近、并将在某些场景超越传统导航

**更远的将来** —— 一个真正理解时空、能在自然语言交互下重构出行体验的时空基座模型

**这三步，高德都已经在路上。**