精读笔记

Problem Setting

论文标题：ParkingTransformer: LLM-Enhanced End-to-End Trajectory Planning for Autonomous Parking（arXiv preprint / 2026）。

这篇论文解决的不是常规近距离自动泊车，而是从停车场入口或附近道路到目标车位的长距离端到端泊车。这个 setting 的关键矛盾是：任务需要长时程目标保持和阶段性决策，但最终执行又要求厘米/分米级几何精度。前者偏语义和任务状态，后者偏局部几何和控制。

传统泊车方法卡在两端：模块化系统可以显式建图、规划、控制，但长链路误差累积和规则工程严重；E2E 泊车可以从图像到轨迹，但多是局部 reactive mapping，缺少对“现在处于泊车流程哪个阶段、目标车位在哪里、是否应该前进/转向/倒车”的高层状态建模。BEV 方法提供几何统一坐标，但在长距离范围下 dense grid 计算冗余明显，而且并不天然解决任务语义和解释性。

Motivation

作者的核心观察是：长距离泊车失败往往不是因为最后几米的局部几何无法拟合，而是因为模型缺少可持续的任务语义状态。短距泊车可以靠局部图像和目标 query 回归轨迹；长距泊车需要模型理解停车场拓扑、目标车位方位、当前 maneuver 阶段以及历史已走过的路径。

已有路线缺的东西有两个：一是高层语义压缩，能把多视角场景、ego 状态、目标车位条件转成可供 planner 使用的 latent task state；二是精细空间对齐，避免 LLM/VLM 只会生成描述而无法支撑轨迹级控制。ParkingTransformer 正是在这两者之间折中：用 LLM 提供语义状态，用 3D PE 和视觉 cross-attention 把它拉回几何空间。

Core Idea

论文真正改变的是规划信息流。它不再先构建 dense BEV，再在 BEV 上做规划；也不是让 LLM 直接输出控制。它把轨迹 query 作为核心计算实体：LLM hidden state 给 query 注入高层任务语义，query 再主动从历史 memory 和当前多视角图像中提取与轨迹生成有关的信息。这是一个 query-centric 的端到端规划框架。

这个设计的直觉是合理的：长距离泊车环境大部分区域对当前控制无关，dense BEV 会浪费大量计算；而轨迹 query 只需要关注与目标、可行通路、障碍和末端泊入相关的稀疏信息。LLM 的作用不是精确几何推理，而是提供类似“latent route/maneuver prior”的条件，使 decoder 不必仅从局部视觉中隐式推断任务阶段。相对 prior 的本质区别在于，它把语义理解从辅助 caption/解释模块提升为 trajectory query 的条件状态。

Method

方法里真正必要的机制可以压缩成四点。

第一，LLM-conditioned trajectory query。多视角视觉特征和 ego/goal 状态通过 adapter 输入 Qwen2.5，取最后 hidden state 与轨迹 query 融合。它解决的是长距离任务条件表达不足的问题：目标车位、当前环境、驾驶意图被压成一个隐式状态，而不是只作为低维数值或局部图像信号进入 planner。

第二，Temporal Cross-Attention + fixed-window memory。历史 ego query 被缓存，当前 query 通过 cross-attention 读取最近历史。它解决的是纯单帧策略在长距离泊车中缺少连续性的问题。需要注意的是，这更像短期 memory reuse，而不是全局长期规划；50–300m 的长期依赖很可能主要由目标位姿和数据分布承担。

第三，Sensor Cross-Attention 直接访问图像特征。它绕开 dense BEV，让 query 在图像 token 上做选择性检索。核心变化是把空间感知从显式全场景栅格化变成任务驱动的稀疏读取，理论上更适合低速、局部关键区域稀疏的泊车场景。

第四，3D PE 与 coarse-to-fine decoder。3D PE 试图弥补 LLM hidden state 的空间无标定问题；coarse-to-fine 则把轨迹生成拆成先给全局趋势、再逐层修正局部几何。后者在泊车末端尤其合理，因为末端轨迹对小误差非常敏感。

Key Insight / Why It Works

最可能真正有效的是“目标条件 + 语义状态 + 历史 memory”共同形成了一个 latent task state，使模型不再把长距离泊车当作单帧局部控制问题。长距离泊车的动作模式高度结构化：进入停车场、沿通道行驶、靠近目标车位、调整姿态、倒入。LLM hidden state 即使不做真正推理，也可能作为强大的语义压缩器，把这些阶段性模式编码进 query。这里的能力更接近 representation alignment / retrieval，而不是可证明的 reasoning。

第二个有效点是 query-centric sensor access。泊车场景速度低、动态复杂度有限、有效障碍稀疏，dense BEV 并不一定划算。让 trajectory query 直接 attend 到图像 token，可以减少中间表征损失，也让 planner 只抽取对当前轨迹有用的信息。这是一个更好的 inductive bias，而不只是工程优化。

第三，coarse-to-fine 对轨迹精度的贡献可能真实存在，但不是新思想；它更像把已有 planning decoder 的 refinement 机制迁移到泊车。短轨迹加权 loss 也可能显著改善末端指标，属于训练分布校正，不应被过度包装成模型结构贡献。

最可疑的是 3D PE 的叙事。论文声称 3D PE 补偿 LLM 空间推理不足，但消融表中去掉 3D PE 的 driving score/success rate 反而略高。这说明该模块的收益至少没有被实验证实；可能是指标噪声、场景过小、或者 LLM/视觉 cross-attention 已经足够。这个结果削弱了论文最重要的“语义-空间结合”论证。

此外，LLM 的作用也没有被充分归因。w/o LLM 明显下降，但 w/o LLM 的 baseline 是否参数量、输入信息、训练方式完全公平，文中未充分说明。不能排除增益主要来自更大的模型容量、更强的预训练视觉语言 prior，或者 prompt/文本监督带来的额外语义标签。

Relation To Prior Work

这篇最接近三条谱系的交叉：ParkingE2E / E2EParking 这类 camera-to-planning 泊车方法，TransFuser/UniAD/VAD 这类 query/transformer planning 方法，以及 LMDrive/DriveGPT4/DriveVLM 这类 LLM-enhanced driving 方法。

相对 ParkingE2E，它的实质区别是把长距离阶段语义和历史状态显式放进 trajectory query，而不是主要依靠 BEV 或局部视觉回归。相对 BEVFormer/LSS，它放弃 dense BEV，把计算中心转到稀疏 query，这与 VAD/UniAD 的 query 化方向一致。相对 DriveGPT4/LMDrive，它没有让 LLM 直接输出控制，而是把 LLM hidden state 当作 planner latent condition，这比语言动作序列更适合精细轨迹控制。

看似新的部分中，Q-Former-style adapter、PETR-style 3D PE、fixed-window memory、coarse-to-fine decoder 都是已有思想重组。比较实质的新增信息在于：把这些机制组合到长距离泊车，并把 LLM hidden state 作为端到端轨迹 query 的初始化/条件，而不是只用于解释或高层决策。

Dataset / Evaluation

评测包含仿真闭环和真实车辆实验，这是论文比纯 CARLA 工作更有说服力的地方。但覆盖范围明显有限：CARLA 是 Town04 单一停车场；真实世界也是一个户外停车场，停车位数量和路线模式有限。数据规模也小，真实训练 clips 数量尤其不足以支持强泛化结论。

论文最强的实验证据是：短距离上方法只是略好，长距离上 baselines 基本崩溃，而 ParkingTransformer 仍能完成任务。这确实支持“长距离需要高层状态/历史信息”的方向判断。但 baseline 长距离结果为空会带来解释风险：这些方法可能并未被公平改造成适合长距离目标条件输入和历史建模，而不是天然不能做。

真实世界闭环结果说明系统可跑，但还不能证明跨场景泛化。它更像一个场景内或同分布验证。论文没有展示跨停车场、跨相机 rig、跨光照天气、跨车位布局的系统泛化，也没有充分报告失败案例类型。因此 evaluation 支持 feasibility，不足以支持 broad scalability。

Limitation

第一，方法成立高度依赖训练数据覆盖。长距离泊车轨迹模式在固定停车场内很可能有限，模型可能学到的是 route/maneuver template retrieval。所谓 LLM reasoning 未必是在线推理，更可能是把场景描述映射到训练分布中的行为原型。

第二，LLM 增益归因不清。没有看到与同等参数量非语言 transformer encoder、冻结/微调 LLM、无文本 CE loss、不同 prompt 的严格对比。当前证据只能说明“加这个 LLM pipeline 有用”，不能说明“语言推理是必要的”。

第三，长期规划能力可能被高估。固定窗口 K=10 很难承载 50–300m 的真实长期记忆，模型更可能依赖当前全局 ego pose、target pose 和场景先验。也就是说，长期性可能由输入目标位姿和数据分布解决，而不是由 memory 机制解决。

第四，空间推理论证不稳。3D PE 消融没有证明正收益，反而略差。这意味着“LLM 空间不足—3D PE 补偿—轨迹更准”的链条没有闭合。

第五，部署成本并不低。推理延迟约 200ms 量级，泊车低速下可接受，但这仍然是把 BEV 计算压力转移到 LLM/VLM pipeline。若要扩展到更复杂停车楼、多层地图、行人交互、遮挡和动态车辆，scaling 上限不明确。

第六，论文没有充分说明控制闭环细节。轨迹点如何转成底盘控制、重规划频率、异常恢复、目标车位被占用、定位漂移等实际 deployment 问题都不是本文重点，但这些恰恰决定长距离泊车能否可靠落地。

Takeaway

• 1. 长距离泊车不应被建模成放大版短距泊车；核心是 latent task state，而不是单纯更大的感知范围。
• 2. LLM/VLM 在这类低速结构化任务里最合理的角色不是直接控制，而是提供语义条件和阶段性行为 prior，再交给几何感知模块做精细轨迹。
• 3. Query-centric planning 是比 dense BEV 更适合泊车的一条路线，尤其在场景稀疏、目标明确、低速闭环的条件下。
• 4. 未来真正值得做的是拆清楚 LLM 的贡献：它到底提供语言语义、预训练世界知识、额外监督，还是只是更大的 latent encoder；同时需要跨停车场泛化和更强失败模式评估。

一句话总结

ParkingTransformer 是把 LLM 作为高层语义状态编码器、把轨迹 query 作为稀疏规划载体的长距离端到端泊车框架；它的主要价值在于重组语义、历史和传感器信息流，而不是证明了 LLM 具备可靠空间推理能力。