跳转至

高德路线规划双路线:MobilityBench(Agent 基准)+ TransitLM(端到端 RLLM)

Ch01.854 高德路线规划双路线:MobilityBench(Agent 基准)+ TransitLM(端到端 RLLM)

📊 Level ⭐⭐⭐ | 19.0KB | entities/gaode-routing-dual-pathway-mobilitybench-transitlm-2026.md

高德路线规划双路线:MobilityBench(Agent 基准)+ TransitLM(端到端 RLLM)

高德 AMAP-ML 团队(机器学习研发部)2026-06-16 发布的技术战略文章,揭示路线规划从"工业引擎"演进到"端到端时空基座"的两条并行路线。两篇论文同时发表:MobilityBench (KDD 2026 Oral) + TransitLM(业界首个 RLLM)。

核心命题

当 LLM 是新一代运行时,路线规划是不是也可以从"借力工业引擎"走向"模型即系统"?

每天数以亿计的用户从 A 点导航到 B 点。背后是一套打磨多年的工业体系:路网建模、Dijkstra/A*/RAPTOR 图搜索算法 + 十万级 QPS 毫秒级响应的图预处理 + 海量启发式规则 + 排序模型。

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

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

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

双路线战略

路径 思路 代表工作 论文
路径一 路线 Agent + 工业引擎(让 LLM "听人话、调工具、算好路") MobilityBench arxiv 2602.22638 (KDD 2026 Oral)
路径二 RLLM (Route LLM) — 让模型从真实出行样本中学习,不查地图、不调引擎,直出一条结构有效的路线 TransitLM (业界首个 RLLM) arxiv 2605.22355

第一路线:MobilityBench(Agent 路线规划基准)

问题:Agent 范式没有"考卷"

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

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

现有 Benchmark 的两个缺陷: - 覆盖不足:学术 Benchmark(TravelBench、TravelPlanner)大多停留在"高层行程安排" - 不可复现:真实地图 API 是非确定性的(今天问一次和明天问一次,路况、ETA 都可能不一样)

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

解法:MobilityBench 三大创新

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

三个关键发现

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

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

② 真值构造方法被验证

用 17K 条按真实用户 query 标注 pipeline 构造的数据,对 Qwen3-4B 做 LoRA SFT:

阶段 最终通过率
基线 53.5%
LoRA SFT 69.8% (+16pp)

4B 小模型直接追平 235B 级通用大模型

这条 pipeline 还可以源源不断地构造更多训练数据,撑起后续路线 Agent 的专项训练与 RL。

③ 错误来源初步定位

错误类型 占比 指向优化方向
工具调用错误 ~36% 工具函数对齐
规划推理错误 ~26% 长程约束推理
其他 ~38%

第二路线:TransitLM(端到端 RLLM)

挑衅性问题

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

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

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

解法:TransitLM 三大设计

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

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

三个关键发现

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

  • 传统路线规划:TransitLM 效果和线上工业级公交导航服务基本持平
  • 自然语言算路:TransitLM 效果也和用最优闭源大模型为基座的 Agent + 工具效果相当

仅凭丰富的出行数据即可取代传统的基于地图的路径规划引擎

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

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

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

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


双路线辩证:两条都会赢,只是节奏不同

我们经常被问:到底是 MobilityBench 这条 Agent 路赢,还是 TransitLM 这条端到端路赢?我们的答案是:两条都会赢,只是节奏不同。

Agent 路线(对应 MobilityBench)

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

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

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

端到端路线(对应 TransitLM)

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

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

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


时空基座模型愿景

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

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

那么自然的下一步是

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

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


三步未来

阶段 内容
当下 一个会听人话、会用工具、会自我评估的路线 Agent,正在以工业级稳定性走进每一个用户的日常出行
不远的明天 一个不再依赖地图、能直接从坐标"画"出路的端到端时空模型,正在以惊人的速度逼近、并将在某些场景超越传统导航
更远的将来 一个真正理解时空、能在自然语言交互下重构出行体验的时空基座模型

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


关键资源

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

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


与 AMAP-ML 团队其他工作的关联

  • APPO:同 AMAP-ML 团队(中科大+阿里高德)2026-06 发表的 Agent RL 信用分配算法(arxiv 2606.12384),用 Branching Score 把信用分配从工具调用边界下沉到细粒度决策点——这正好对应 MobilityBench 错误定位中"工具调用 36% + 规划推理 26%"两类问题的优化方向
  • AMAP Proactive Agent:高德 LBS 时空 Agent 主动式推荐(出行场景下 Agent + 时空知识融合的另一个维度)
  • AMAP AI Native End-to-End Infrastructure:高德 AI Native 端到端基础设施(TransitLM 的工程底座)
  • AMAP ABot Earth 0.5:高德 3D 原生世界模型(时空基座模型的视觉维度)
  • SPEC as AIOS:高德 AI Native 系列 2(Anti-Entropy 架构——支撑时空基座模型的工程原理)
  • Autoresearch Marketing Growth:高德 AI Native 营销增长(时空基座模型在商业场景的应用)

原文存档