问题背景
公交路线规划，听起来是件小事——打开地图App输入起终点，路线就出来了。但背后支撑这套能力的工程体系，远比想象中复杂。
图1：传统方案（上）流程冗长；通用LLM（左下）产出断裂路线与幻觉站点；TransitLM（右下）通过隐式空间定位，端到端生成结构完整的连通路线。
传统方案：重依赖、长链路
传统的公交规划依赖一套完整的地图基础设施——站点拓扑图、实时时刻表、寻站策略……然后通过候选召回、多目标排序等多级管线一步步输出结果。管线长、依赖重，部署成本居高不下。
让大模型来做？准确率堪忧
既然LLM推理能力强、世界知识丰富，那能不能直接用它规划路线？实测表现让人大跌眼镜——六大最强通用模型（GPT-5.4、DeepSeek-V4、Gemini-3.1、Claude-4.6、Qwen-3.6、Doubao）的最佳连通率仅75.5%，精确匹配只有40.2%。更极端的是，去掉文字、只给GPS坐标后，精确匹配直接暴跌至0，说明这些模型完全没有空间定位能力。
结论很清晰：通用LLM缺的不是推理能力，而是公交网络的领域拓扑知识。
工具增强（LLM + 路径API）？依然复杂
另一条路是让LLM调用路径引擎API获取候选路线再做选择。这看似绕开了问题，实际上只是把「路线生成」降级为「路线选择」，工程复杂度没降低多少——地图基础设施依赖仍在，需要粗排/截断防止候选上下文过长，多轮API调用还会引入网络延迟与配额限制。
我们的思路：端到端，从数据中直接学会路线规划
核心问题：路线规划能否从数据中直接学会，完全绕开地图和引擎？
如果答案是肯定的，我们将获得：
如何实现？
通用大模型缺乏公交网络知识，但这些知识实际上大量存在于导航平台的路线规划日志中——每一条日志都完整记录了换乘逻辑、站点序列、空间关系和用户偏好。实验证明，路线规划完全可以从数据中学会。更进一步，模型在训练过程中涌现了隐式空间定位能力——仅给定原始GPS坐标，无需任何地理数据库或坐标-站点映射表，模型即可精确定位到最近的公交站点并生成完整路线。
基于这一洞察，本方法包含三个关键设计：
1、站点即Token：从根源消灭幻觉
将全部120,845个站点ID注册为模型词表中的独立token。这一设计带来两个好处：其一，模型只能输出真实存在的站点，从根源消除幻觉站点；其二，站点作为独立token参与注意力计算，模型可以直接从共现模式中学习站点间的连通关系——频繁相邻出现的站点对自然获得更高的关联强度，从而在表示层面建立起网络拓扑，大幅降低生成断连路线的概率。
2、两阶段训练：CPT + SFT
继续预训练（CPT）：在13.9M条路线规划文本上做next-token prediction，让模型学习到可泛化的网络拓扑表示、站点空间关系和换乘逻辑——这不是死记硬背见过的路线，而是真正学会了网络结构。监督微调（SFT）：在三种规划任务上做prompt→label对齐，适配具体使用场景。实践中，同一个CPT模型可根据不同业务需求灵活扩展新任务，无需重新训练底座。
3、轻量骨干
Qwen3-4B-Base作为基座模型，4B参数即可完成全部任务。甚至0.6B模型仍能取得可用效果（连通率93.5%），使得移动端离线部署成为可能。
图2：TransitLM方法总览。左侧为数据来源（路线规划日志、站点信息、线路信息）；中间为三个Benchmark任务与评测体系；右侧为训练流程（词表扩展 → CPT → SFT）。
数据集与Benchmark
为了推动社区在这一方向的研究，团队开源了完整的数据集与评测基准。
数据集规模
图3：数据集中四个城市路线规划出发地的地理分布
三个Benchmark任务
PS：对于未使用我们数据集训练及未采用对应站点ID体系的模型，我们提供了统一的评测API接口以确保公平比较，详见GitHub。
评测指标一览
设计了覆盖四个维度的10项评测指标，确保全面衡量路线质量：
实验结果
主实验：端到端无地图路线规划可行
Qwen3-4B在三个Benchmark任务上的核心指标：
- 连通率 ≥ 93%：生成的路线绝大多数结构完整、可实际行走
- 站点定位 ≥ 96%：上/下车站几乎都在起终点合理范围内
- 精确匹配达71.0%：超七成路线与用户实际行走路线完全一致
- MAPE < 1.4%：距离、时间、费用预测误差极小
三任务联合训练的Joint模型达到全局最优（73.7%精确匹配），且三个任务之间完全没有负迁移——证明CPT阶段学到的公交网络知识是任务无关的，可支撑多种规划场景的统一部署。
vs 通用大模型：短板在数据，不在规模
对比六大最强通用模型（GPT-5.4、DeepSeek-V4、Gemini-3.1、Claude-4.6、Qwen-3.6、Doubao），并且降低了评测难度（只需预测上下车站，而本模型需要生成完整中间站序列）：
- 最佳表现（Gemini-3.1）：75.5%连通率，40.2%精确匹配
- 最小的0.6B模型（62.1%精确匹配）已全面超越所有通用模型
结论：性能瓶颈在于领域数据而非模型规模。数据才是关键推动力。
核心发现：隐式空间定位能力涌现
这是本文最重要的发现之一。设计了一个极端测试：去掉输入中的所有文字信息（起终点名称、查询语句），仅保留原始GPS坐标作为输入。
这说明什么？
- 通用模型依赖文字语义推断空间位置，一旦去掉文字就完全丧失定位能力
- TransitLM从数据中学会了GPS坐标与站点的空间映射关系，无需任何显式坐标-站点映射表或地理数据库
- 这种空间理解能力是纯粹从训练数据中涌现的，并非显式设计
vs 工具增强方案：纯生成媲美生产级管线
最强的工业替代方案是让LLM调用高德地图路径引擎API获取候选路线，再从中选择最优。结果：
- 工具增强方案：71.7%~74.4%精确匹配
- TransitLM纯生成：73.7%，性能持平
关键差异：
- TransitLM输出完整中间站序列（更难的任务），工具增强仅需选择上下车站
- TransitLM无外部依赖、无网络延迟、无配额限制
- 单模型端到端推理，部署复杂度降低一个数量级
结论：CPT让模型学到的路线规划知识，等效于一套生产级路径引擎。
数据规模效应
测试了不同CPT数据量的影响：
- 6.25%数据：已达94%连通率、49.9%精确匹配——证明端到端方案在小数据量下即具备实用性
- 100%数据：性能单调递增，未观察到饱和，扩大数据规模仍有空间
这揭示了一个清晰的学习层次：基础拓扑（连通性）最先学会，精确路线匹配和数值标定需要更密集的数据覆盖。同时也证明，这种路线规划能力的学习并不需要大量数据堆砌——6.25%的数据即可达到实用水平，降低了该方案的落地门槛（仅需论文配置训练不到一天）。
更多实验详情见论文：https://arxiv.org/abs/2605.22355
局限与未来工作
当前局限
- 无法处理网络动态变化。数据集记录的是静态网络快照，无法反映新开线路、站点撤销或临时调整。目前网络变更的唯一方式是在包含新实体的数据上重新训练。
- 无法融合实时交通信息。模型不感知实时拥堵、临时停运等动态状态，生成的路线基于历史平均而非当前实况。
- 地理覆盖有限。目前仅覆盖四座城市（12万站点），而全国公交网络约有180万站点。扩展至全国规模将带来词表线性增长的内存与计算开销，该规模下的有效性仍待验证。
未来方向
- 动态网络更新：探索轻量级增量训练或检索增强生成等机制，在推理时注入实时状态信息，避免全量重训练
- 全国规模扩展：研究高效词表压缩或层次化编码方案，解决180万站点词表规模问题
- 更广泛的规划场景：将端到端范式拓展至驾车路线规划，或公交+驾车+骑行的混合出行规划，实现更全面的端到端出行规划
引用链接
数据集：HuggingFace - GD-ML/TransitLM
评测代码：GitHub - HotTricker/TransitLM
demo链接：https://transit-lm.amap.com/
paper链接：https://arxiv.org/abs/2605.22355
hugging face：https://huggingface.co/papers/2605.22355
ModelScope: https://modelscope.cn/datasets/GD-ML/TransitLM
