「从逐点token到逐段预测」
目录
[01 为什么端到端泊车比端到端行车更难？](#01 为什么端到端泊车比端到端行车更难？)
[02 把"下一点预测"改成"下一段预测"](#02 把“下一点预测”改成“下一段预测”)
[03 半锚点 query：让模型一次保留多种泊车意图](#03 半锚点 query：让模型一次保留多种泊车意图)
[04 两阶段训练：不只模仿动作，还优化结果](#04 两阶段训练：不只模仿动作，还优化结果)
[05 实验结果](#05 实验结果)
[06 消融实验：哪些设计最关键？](#06 消融实验：哪些设计最关键？)
[07 上车验证：不是只停留在评测表格](#07 上车验证：不是只停留在评测表格)
[08 给自动驾驶和机器人同学的三个启发](#08 给自动驾驶和机器人同学的三个启发)
自动泊车看起来是一个低速场景，但对规划算法并不友好。道路行驶通常有车道线、拓扑结构和相对平滑的运动方向；泊车则经常发生在无车道开放空间里，车辆需要前进、倒退、打满方向，甚至在一个很小的空间里通过多次换挡完成入位。
更麻烦的是，同一个停车位、同一个初始位置，并不只有一条"标准答案"。有的司机先往左探，有的司机先往右绕；有的策略一步入库，有的策略先调整姿态再倒入。对于模仿学习来说，如果强行把这些多样行为压成一条平均轨迹，模型很容易学到一条"看起来中庸、实际不可开"的路径。
针对这一系列问题，上海交通大学秦通老师团队联合卓驭科技、香港科技大学（沈劭劼教授参与） ，提出了一套端到端泊车规划框架 MultiPark。
图1| MultiPark 的核心动机。泊车路径包含换挡、急转、多解和恢复策略，不能简单套用道路行驶的平滑轨迹假设。
MultiPark 的中心判断很清楚：端到端泊车不能只学一个点、一个动作、一个模式。它需要同时解决三个问题：多段换挡、同场景多解、闭环部署中的误差恢复。
标题 | MultiPark: Multimodal Parking Transformer with Next-Segment Prediction
作者 | Han Zheng, Zikang Zhou, Guli Zhang, Zhepei Wang, Kaixuan Wang, Peiliang Li, Shaojie Shen, Ming Yang, Tong Qin*
机构 | 上海交通大学、卓驭科技、香港科技大学
论文链接 | https://arxiv.org/abs/2508.11537
项目主页 | https://wuyi2121.github.io/MultiPark/
01 为什么端到端泊车比端到端行车更难？
过去几年，端到端自动驾驶已经大量使用 BEV、Transformer、query decoder 等范式。但这些范式迁移到泊车任务时，会遇到场景本身带来的结构差异。
**第一，路径不是连续平滑的。**泊车轨迹天然包含 forward 和 backward 两种运动方向。换挡点附近往往出现明显转折，如果仍然按逐点 token 或逐点 waypoint 做自回归，序列会很长，误差也会一层层累积。
**第二，训练数据本身是多模态的。**论文指出，在同一场景下，不同驾驶员可能给出不同但同样合理的泊车路线。单模态回归会把多条可能路径平均掉，这就是自动驾驶预测和规划里常说的 mode collapse。
**第三，模仿学习有因果混淆。**模型如果只优化下一步动作，很容易学到数据里的相关性，而不是任务成功所需的因果关系。泊车这种长时序任务尤其明显：前一段轻微偏差，可能导致后一段碰撞；真正有价值的能力，是在偏离专家轨迹后还能找回可行解。
02 把"下一点预测"改成"下一段预测"
MultiPark 的第一个关键设计，是 next-segment prediction。
这个名字很像大语言模型里的 next-token prediction，但它没有把泊车路径切成密集坐标 token，而是把完整泊车过程拆成若干段 segment。
核心原因在于人泊车的时候不会很仔细在意下一个路径点到哪，而是大概这一把方向到哪里刹住，换挡开下一把
每一段由一个 gear shift point 连接。模型在当前段的起点，结合 BEV 场景特征，预测下一段的曲率序列和终点状态；再把这一段的终点作为下一段的起点，继续自回归展开。这样做的好处是，模型一次预测一段空间上连续、控制上可执行的路径，而不是在急转和换挡处被坐标级 token 拖慢。
这也是论文标题中 "Next-Segment Prediction" 最值得注意的地方：它不是给 Transformer 换个壳，而是根据泊车运动学特征重新定义了序列建模单元。
图2| MultiPark 框架。BEV 编码器负责融合环视图像、车位和占用信息；Transformer decoder 按段自回归预测多模态泊车路径。
03 半锚点 query：让模型一次保留多种泊车意图
MultiPark 的第二个设计，是 semi-anchor parking queries。
它不像纯 anchor-free 方案那样完全依赖模型自己分化模式，也不像传统 anchor-based 方法那样预设大量稠密轨迹模板，而是把泊车行为拆成三个维度：
- gear：前进或倒退；
- longitudinal：短、中、长等纵向行为；
- lateral：大左转、小左转、直行、小右转、大右转等横向行为。
论文的实现里，只需要少量可学习 query，例如 2 个 gear query、3 个 longitudinal query、5 个 lateral query，再加上 padding query，就能组合出 32 个 parking queries。每个 query 对应一种潜在泊车行为模式，decoder 可以并行输出多条候选路径和对应分数。
图3| Semi-anchor parking queries 的结构。通过 gear、longitudinal、lateral 三类 query 组合，模型可以并行表达不同泊车意图，并由预测头输出候选段的概率与曲率。
它不是盲目追求更大的 query 数量，而是把泊车行为里的先验结构拆出来，让模型在有限数据上也能稳定学习多模态分布。
04 两阶段训练：不只模仿动作，还优化结果
MultiPark 的第三个关键点，是两阶段训练策略。
**第一阶段是 teacher-forcing 预训练。**模型使用真实的上一段 gear shift point 来预测下一段，通过 winner-takes-all 的方式，只让最匹配专家轨迹的模态参与反传。这个阶段的目标是降低训练难度，让模型先学会"像人一样开"。
**第二阶段是 argmax finetuning。**模型不再只看专家给定的上一段，而是使用自己当前策略 rollout 出来的状态继续预测，这更接近真实部署时的闭环过程。为了避免模型只会追逐稀疏结果，论文同时保留 imitation loss 作为正则，并引入 outcome-oriented loss。
这个 outcome-oriented loss 包含两个核心结果：**一是终点是否准确落到目标车位姿态，二是路径是否避免碰撞。**论文使用 target-centric endpoint loss 衡量入位精度，用 ego-centric ESDF collision loss 描述车辆形状与障碍物之间的碰撞风险。
换句话说，MultiPark 并不满足于"每一步像专家"，而是希望模型知道"最后要停准，并且中间不能撞"。这对端到端泊车非常关键。
图 4| 两阶段训练中的 outcome-oriented loss。赢家模态结合 imitation loss 与 outcome loss，非赢家模态通过 endpoint loss 和 collision loss 获得结果级约束，提升闭环入位与避障能力。
05 实验结果
论文在真实世界 HP5 数据集上与 6 个基线方法进行了比较，包括 ParkingE2E、TransParking、TransFuser、GoalStatus、ParkingMLP 和 OnlyReg。
所有方法使用相同数据训练到收敛，并使用相同 encoder 以保证公平性。
图5| 项目页给出的主要性能表。MultiPark 在闭环精度、安全性和成功率指标上均取得最好结果。
从结果看，MultiPark 的成功率达到 0.7895，高于 OnlyReg 的 0.7470 和 ParkingE2E 的 0.6453；碰撞率降到 0.1749，也优于主要基线。
更有意思的是，OnlyReg 已经比不少端到端泊车基线更强，说明本文收益并不只来自 Transformer 架构，而是来自 BEV 表征、结果导向训练、多模态建模等组件的组合。
论文还报告了推理时间：ParkingE2E 为 224.42 ms，TransParking 为 226.94 ms，而 MultiPark 为 59.062 ms。next-segment prediction 减少了自回归 rollout 次数，因此在部署侧更接近实时要求。
06 消融实验：哪些设计最关键？
论文围绕三个问题做了消融：Next Segment预测是否比Next Token 更有效，多模态 query 是否真的提升精度和多样性，两阶段训练里哪些 loss 起主要作用。
结果可以概括成三点。
- **next-segment prediction 是效率核心。**相比逐 token 预测，按段预测大幅减少 rollout 步数，同时生成更平滑、更接近人类泊车行为的轨迹。
- **多模态不是装饰，而是避免平均解。**移除分类头、只回归单一路径的 OnlyReg 已经很强，但 MultiPark 在所有指标上继续提升，说明并行候选路径之间存在协同收益。
- **argmax finetuning 和 outcome-oriented loss 是闭环能力来源。**移除 argmax 后，覆盖率从 0.9720 降到 0.7541，成功率从 0.7895 降到 0.5082；移除 endpoint loss 后成功率也显著下降。
这说明端到端泊车不是简单的"多喂数据、多堆网络"。如果训练目标只盯着专家动作，模型可能在开环指标上不错，但一旦自己 rollout 出偏差，就缺少恢复能力。MultiPark 的价值，在于把闭环结果显式纳入训练。
07 上车验证：不是只停留在评测表格
论文还将 MultiPark 部署到量产车平台上。系统使用四个环视摄像头，经过 BEV encoder 得到场景特征，再由 MultiPark 直接生成候选路径。后处理阶段会选择安全且质量更好的路径，并进行速度分配和 MPC 跟踪。
08 给自动驾驶和机器人同学的三个启发
从这篇工作出发，可以提炼出三点对自动驾驶和机器人方向有参考价值的设计思路：
**第一，序列建模的基本单元要尊重任务结构。**在 NLP 里是 token，在普通行车里可能是 waypoint，在泊车里更自然的是 segment。任务结构变了，建模粒度也要变。
**第二，多模态规划不能只靠"多输出几条轨迹"。**如果没有合理的模式分解和训练目标，多条轨迹可能只是重复或发散。MultiPark 用 gear、longitudinal、lateral 三个维度给 query 注入弱先验，是一个很实用的折中。
**第三，闭环部署要从训练阶段开始考虑。**teacher-forcing 很适合降低学习难度，但真实车上不会一直给你专家上一状态。argmax finetuning 和 outcome-oriented loss 的意义，就是提前让模型面对自己的预测，并把"最后停得准、不碰撞"写进目标函数。
当然，MultiPark 的能力边界也需要客观看待。从论文信息看，它主要聚焦泊车路径规划本身，动态障碍的速度分配、路径选择、人类偏好和 MPC 跟踪仍在后处理阶段完成。
论文结尾提到，未来希望利用视觉语言模型的场景理解和推理能力，将 MultiPark 扩展为 ParkAgent------这也暗示了下一步方向：泊车不只是几何规划，还会逐步走向语义理解、意图解释和更复杂的人车交互。