引言
NAVSIM 排行榜的竞争已经到了白热化阶段。从最初的 80 分出头到现在的 94.5 分（CLOVER），短短两年时间，顶尖方案的 PDMS 提升了 15 个点。如果你正在读这篇文章，大概率是两种人：一是想在排行榜上刷个高分的选手，二是研究自动驾驶规划、想理解 Scoring-based 范式演进方向的研究者。
这篇文章不讲虚的，直接切入正题：到底怎么才能在 NAVSIM 上把 PDMS 刷到 90 分？
我会结合 NAVSIM 排行榜上所有公开的高分方案（CLOVER、CLEAR、DriveFuture、Hydra-MDP 以及各种 VLA + RL 方案），从 PDMS 公式的数学结构出发，逐层拆解每个分数段的瓶颈和对应的策略。
先给个核心结论：PDMS 90+ 的秘密不在于模型多强大，而在于你是否真正理解了 Scoring 范式的每个环节。
一、PDMS 公式：分数结构决定了优化策略
如果你还不知道 PDMS 怎么算的，那先把这块搞清楚。分数结构本身就在告诉你该优化什么。
1.1 公式结构
记住这个公式：
PDMS = NC × DAC × (5·EP + 5·TTC + 2·C) / 12
这里最应该引起你注意的是乘性结构：NC 和 DAC 是乘法项，意味着任何一个为零，整体分数直接归零。这不是简单的加减法，这是一个"安全第一，前进第二"的奖励结构。
加性部分是 (5·EP + 5·TTC + 2·C) / 12，EP 和 TTC 各占 5 份权重，C 只占 2 份。
1.2 每个子指标的含义
NC（No Collision，无责碰撞）：取值为 {0, 0.5, 1}。0 代表有责碰撞，整段分数归零；0.5 代表无责碰撞（被追尾等）；1 代表无碰撞。这是最严苛的惩罚——一次碰撞就毁掉整段得分。
DAC（Drivable Area Compliance，可行驶区域合规）：取值为 {0, 1}。只要主车任何时刻压在不可行驶区域上，整段得分为零。
EP（Ego Progression，主车前进量）：连续值 [0, 1]。衡量主车在该场景下相对基准前进量的完成比例。这是一个连续指标，也是高分段唯一能持续优化的指标。
TTC（Time to Collision，碰撞时间）：离散值 {0, 1}。只要某个时刻 TTC 低于阈值，得分为零。
C（Comfort，舒适度）：离散值 {0, 1}。急加速、急刹车、急转向都会导致舒适度归零。
1.3 分数的"阶梯结构"
这个公式透露了一个重大信息：分数增长不是线性的，有明确的台阶。
低分段（< 80）：你在解决 NC、DAC 等"会开车"的问题。 中分段（80-88）：你在解决 TTC、C 等"安全舒适开车"的问题。 高分段（88-92）：你在解决 EP 从 0.8 到 0.9 的问题。 顶尖分段（92+）：你在解决 EP 从 0.9 到 0.95 的"最后一公里"问题。
每上一个台阶，你需要优化的目标就换一个。如果你还在 85 分徘徊，却去研究 EP 的细节优化，那是白费功夫。
1.4 用量化分析理解每个子指标的权重
为了更直观地理解不同子指标的优化价值，我们来做一些简单的量化分析。
假设你在 85 分水平（NC=1, DAC=1, TTC=1, C=1, EP=0.7），PDMS = 1×1×(5×0.7+5×1+2×1)/12 = (3.5+5+2)/12 = 10.5/12 × 100 = 87.5。
如果花精力优化 NC 从 1 到 1（已经到顶），收益 0。 如果花精力优化 TTC（已经到顶），收益 0。 如果花精力把 C 从 1 优化到 1（已经到顶），收益 0。 唯一能优化的是 EP。把 EP 从 0.7 提升到 0.85，PDMS = (5×0.85+5+2)/12 = (4.25+5+2)/12 = 11.25/12 × 100 = 93.75。
这看似很大，但不要忘记：这个计算假设 NC、DAC、TTC、C 全部满分。如果你的实际分数中有任何安全指标不是满分，优化安全指标的收益远大于优化 EP。
举个例子：如果你 NC=0.5（有一次无责碰撞），DAC=1，TTC=1，C=1，EP=0.95。PDMS = 0.5 × (5×0.95+5+2)/12 = 0.5 × 11.75/12 × 100 = 48.96。
看到没？一次无责碰撞就让 94 分变成 49 分。这就是乘性惩罚的威力。
所以优化的优先级应该是：
- NC → 1（乘性，直接影响整体）
- DAC → 1（乘性，直接影响整体）
- TTC → 1（权重 5，离散）
- C → 1（权重 2，离散）
- EP → max（权重 5，连续，最后优化）
每个层次都理解你当前的瓶颈，才能做最有针对性的改进。
二、分数段深度分析：你的分数对应什么水平？
2.1 PDMS < 80：还不会"正常开车"
这个阶段的表现：频繁碰撞、经常出车道、EP 接近于零。模型本质上还没有学会驾驶行为的基本模式。
解决策略：
这个阶段不要想什么花哨的方法。唯一需要做的是：做好 SFT（模仿学习）。
具体来说：
- 使用 NAVSIM 官方提供的 Navtrain 数据集（74k 场景 × 8s）
- 用人类专家的驾驶日志做行为克隆
- 重点关注碰撞率和可行驶区域合规率
关键经验：不要在第一个阶段就上 Scoring-based。Scoring-based 的核心假设是你的候选轨迹里有一条或多条是"好"的——但如果模型连基本的驾驶行为都没学会，候选轨迹全是垃圾，打分器只能"从垃圾里选一个没那么垃圾的"。
这个阶段的目标很简单：让模型输出的轨迹 τ 至少和训练集中的专家轨迹在分布上相似。
实操技巧：
- 使用简单的 MSE Loss 或 L1 Loss 做轨迹回归
- 在碰撞场景上做数据增强（加噪声、随机裁剪等）
- 先在小验证集上确认碰撞率降到 5% 以下再考虑下一步
预期结果：PDMS 75-82，碰撞率显著下降，EP 达到 0.5-0.7。
2.2 80 ≤ PDMS < 88：Scoring-based 的主战场
这个阶段是最经典的 Scoring-based 范式能发挥最大作用的区间。你的模型已经会开车了，但还不怎么安全——偶尔碰撞、EP 中等、舒适度波动大。
解决策略：
切换到 Generator-Scorer 架构。
核心思路：
- Generator：生成 K 条候选轨迹（通常 K=6-12）
- Scorer：为每条候选轨迹打分
- Selection：选择分数最高的轨迹作为输出
这个阶段的优化重点：先搞定安全指标（NC、DAC、TTC、C）。
为什么？因为安全指标是离散的、乘性的，它们的优化回报远高于 EP。你花大量精力把 EP 从 0.75 提升到 0.80，还不如把碰撞率从 5% 降到 1% 的收益大。
Scorer 训练关键：
- 使用 NAVSIM scorer 作为 teacher（监督信号）
- 输入：场景上下文 + 候选轨迹
- 输出：分数（最大熵分类或回归）
- 损失函数：Binary Cross Entropy
常见陷阱：
- 打分器过拟合到训练场景。验证集上分数很高，但测试（navtest）上性能差。
- 候选轨迹退化。如果 Generator 生成的所有轨迹都差不多，打分器再强也没用。
- EP-CAV 差距。EP 分数高 ≠ 候选轨迹覆盖了所有合理的驾驶策略。
预期结果：PDMS 82-88，安全指标基本拉满，EP 达到 0.75-0.85。
2.2.1 Scoring-based 的 Generator 设计细节
Generator 的设计直接决定了候选轨迹的质量和多样性。我来深入拆解几种主流 Generator 的设计：
CVAE-based Generator
条件变分自编码器是最常见的 Generator 架构。训练时学习一个条件分布 p(τ|x)，其中 τ 是轨迹，x 是场景上下文。推理时从潜变量 z ~ N(0, I) 采样，解码生成轨迹。
场景编码 => 潜变量 z 采样 => 轨迹解码
优点：训练稳定，可以通过调整 z 的采样数目来控制候选数量。 缺点：生成的轨迹多样性有限，容易收敛到平均值（mode collapse）。
Anchor-based Generator
预先定义一组"锚点轨迹"（比如左转、直行、右转、减速等），然后基于场景上下文对这些锚点做偏移修正。
预定义 K 个 Anchor 轨迹 => 对每个 Anchor 预测偏移量 => K 条候选轨迹
优点：多样性有保证（只要 Anchor 覆盖了主要驾驶模式），训练稳定。 缺点：Anchor 的设计需要手工经验，可能遗漏某些模式。
Diffusion-based Generator
使用扩散模型直接生成轨迹。扩散模型天然支持多模态生成，通过随机噪声采样可以得到多样化的轨迹。
场景编码 => 初始噪声 => 多步去噪 (t=T to t=0) => 候选轨迹
优点：生成质量高，多样性好，覆盖了训练数据的完整分布。 缺点：推理计算量大（需要多步去噪），训练不如 CVAE 稳定。
我的建议：从 CVAE 开始（最简单），效果不够再用 Diffusion。Anchor-based 不适合做高分段（固定 Anchor 限制了上限）。
2.2.2 候选数量的选择
候选数量 K 的选择直接影响最终分数。太小了覆盖不够，太大了打分器负担重且可能存在噪声。
| K | 覆盖度 | 打分器负担 | 典型 PDMS |
|---|---|---|---|
| 1 | 极低 | 无 | 75-80 |
| 3 | 低 | 低 | 80-85 |
| 6 | 中等 | 中等 | 85-90 |
| 12 | 高 | 较高 | 88-93 |
| 32 | 很高 | 高 | 90-94 |
在实际实验中，K=12 是一个很好的 trade-off。从 6 提升到 12 收益最大，从 12 提升到 32 收益递减。
但要注意：K 的增加会降低推理速度（因为打分器需要对 K 条轨迹都做评估）。权衡速度和分数，K=12 是推荐的默认值。
2.3 88 ≤ PDMS < 92：候选质量决定上限
到了这个阶段，你会发现安全指标（NC、DAC、TTC、C）已经基本满分了，但 PDMS 就是上不去 90。问题出在EP 和候选质量上。
关键洞察：打分器再强也救不了烂候选。
这个阶段你需要做两件事：
第一，提升候选轨迹的多样性。
如果你的 Generator 生成的所有候选轨迹都是"直行"，那在"需要让行/绕行/减速"的场景里，打分器即使知道该怎么做，也没有合适的候选可以选。
怎么提升多样性？
- 增加候选轨迹数量 K（比如从 6 提升到 12）
- 在 Generator 中使用 Diverse Sampling（如 CVAE + 多个潜变量）
- 使用 Diffusion/Flow 模型做生成（天然的多模态能力）
第二，引入蒸馏机制。
这是从 88 到 92 的关键一步。核心想法：用打分器来训练 Generator。
打分器知道什么是好的轨迹（分数高），但 Generator 不知道怎么生成"高分轨迹"。蒸馏就是让 Generator 学习生成打分器认为好的轨迹。
具体做法：
- 对每个场景，用 Generator 生成 K 条候选轨迹
- 用打分器对每条轨迹打分
- 选最高分的轨迹作为"伪标签"
- 用这个伪标签训练 Generator
这个蒸馏过程可以迭代多轮，每次迭代都能提升 Generator 生成高质量候选的能力。
预期结果：PDMS 88-92，EP 达到 0.85-0.93，候选轨迹覆盖大部分合理驾驶策略。
2.4 PDMS ≥ 92：CLOVER 的天地
92 分以上是 CLOVER 的统治区间。这个阶段唯一的瓶颈就是 EP。
当安全指标全部满分、舒适度满分、候选质量足够好时，你的 PDMS ≈ EP。而 EP 的上限取决于：
- 你选择的参考前进量（reference progression）
- 你能否让主车在所有场景下都开得"足够快足够远"
EP 的数学定义：EP = min(ego_progression / reference_progression, 1.0)
所以 EP 优化的本质是：在所有场景下，让主车的前进量接近或达到参考值。
但这个参考值本身是保守的（28.0m / 8s in test-hard），所以即使你开得很快，EP 也可能只是 0.9 左右。要达到 0.95+，你需要让主车在几乎每个场景都几乎不走冤枉路。
CLOVER 凭什么能做到 94.5？
- 闭式蒸馏（Closed-form Distillation）：一步到位而非多步迭代
- 同时优化 Generator 和 Scorer：不再固定一端训练另一端
- 数据 + 策略双提升：用排名高的数据做训练
我们下一节详细讲。
三、三大技术路线深度对比
你的资源和技术栈决定了你应该走哪条路。没有放之四海皆准的最优方案。
3.1 路线 A：Scoring-based 范式（CLOVER 为代表）
这是最成熟、最高分、最稳定的路线。
核心思想：将规划问题拆解为"候选生成 + 打分排序"两个阶段。Generator 负责生成多样化的轨迹，Scorer 负责选出最好的。
为什么它统治了排行榜：
- 打分器提供了可解释的安全性保障
- 候选多样性确保了决策空间的覆盖
- 蒸馏机制持续提升候选质量
CLOVER 的关键创新：
全称 Closed-form Distillation for Scoring-based Planning。
传统的蒸馏是"先生成→打分→蒸馏→再生成"的迭代过程，而 CLOVER 提出了一个解析解：直接将打分器的梯度信息传回 Generator，使得 Generator 的更新方向直接与最终分数挂钩。
具体来说：
- 传统的 Scoring-based：Generator 和 Scorer 分开训练，通过蒸馏间接连接
- CLOVER：将 Generator 的输出直接映射到分数空间，端到端优化
这听起来像是一个简单的 trick，但实际上它消除了蒸馏过程中的信息损失。传统蒸馏中，Generator 只会学到"生成最高分的候选"，但不知道为什么某个候选分数高、其他候选差在哪里。
CLOVER 的闭式解让 Generator 学到打分器的完整排序偏好，而不仅仅是一个伪标签的回归。
CLOVER 的训练流程：
- 初始化 Generator（可以是 SFT 后的模型）
- 初始化 Scorer（用 NAVSIM scorer 做监督）
- 闭式蒸馏：联合优化 Generator 和 Scorer
- 多轮迭代，最终达到收敛
每一轮蒸馏中，Generator 和 Scorer 都在联合优化。Generator 学习生成打分器认为好的轨迹，Scorer 学习更准确地评估这些新生成的轨迹。
CLOVER 的闭式蒸馏伪代码
为了帮助理解闭式蒸馏的核心机制，用伪代码来描述算法流程：
[初始化] G = Generator(随机初始化或SFT预训练) S = Scorer(用NAVSIM scorer预训练)
[闭式蒸馏循环] for epoch in range(N): batch = sample_scenes(navtrain)
// 1. Generator生成候选轨迹 trajectories = G.generate(batch, K=12) // 2. Scoring打分 scores = S.score(batch, trajectories) // shape: [B, K] // 3. 选出最高分候选 best_idx = argmax(scores, dim=-1) // shape: [B] best_trajs = gather(trajectories, best_idx) // shape: [B, T, 2] // 4. [闭式蒸馏的核心] // 不直接用best_trajs做MSE回归 // 而是计算所有候选的分数梯度 score_grad = softmax(scores / temperature) // 分数转换为权重 // Generator损失：按分数权重加权所有候选 // 高分候选贡献大，低分候选贡献小 loss_G = weighted_mse_loss(trajectories, score_grad) // Scorer损失：GT分数与预估分数的差异 gt_scores = navsim_scorer.score(batch, trajectories) loss_S = mse_loss(scores, gt_scores) // 5. 联合更新 G.update(loss_G) S.update(loss_S)
与传统蒸馏的关键区别：传统蒸馏只选 best_trajs 做回归（把所有信息压缩到一个伪标签），而闭式蒸馏用所有候选的分数梯度来更新 Generator。后者保留了打分器的完整排序信息。
为什么这很重要？
假设一个场景中，候选轨迹 A（EP=0.85）和 C（EP=0.93）的分数差异很小（只有 0.2 分的差距），但候选 B（EP=0.6）的分数明显低。传统蒸馏只会让 Generator 学习生成 A（最高分），而闭式蒸馏会让 Generator 学到"A 和 C 差不多，都值得学习，B 不值得学"。这种细粒度的信息让 Generator 学到的策略更加鲁棒。
为什么 CLOVER 能拿到 94.5：
- 候选覆盖度接近完美：几乎所有场景都有至少一条"好"候选
- 打分器几乎不会选错：充分训练的 Scorer 在验证集上几乎 100% 正确
- EP 极致优化：闭式蒸馏直接优化 EP，而不是间接优化
适合谁：你有计算资源做蒸馏迭代，需要稳定可复现的高分。
3.2 路线 B：扩散/Flow 生成式方法
这条路线的特点是直接生成轨迹分布，不依赖显式的打分器。扩散/Flow 模型天然适合驾驶场景——驾驶行为是多模态的（左转/右转/直行/减速等），扩散模型能很好地建模多模态分布，通过去噪过程控制生成轨迹的质量。
TransDiffuser (94.85 PDMS)
目前 NAVSIM 排行榜上分数最高的方法之一。架构核心是 Transformer 作为扩散模型主干，将场景上下文（道路、交通灯、其他车辆）编码为条件，通过扩散去噪生成轨迹。
关键成功因素：
- 无显式打分器：生成和打分在同一模型中隐式完成，避免了打分器与 Generator 之间的信息损失
- 扩散步数可调：推理时可以通过增加去噪步数来提升生成质量（但牺牲延迟）
- 多样性优秀：扩散模型的随机噪声采样天然生成多样化候选，覆盖不同驾驶策略
TransDiffuser 的消融实验显示：8 步去噪已经足够达到 93+ PDMS，16 步能达到 94.85，但再增加步数收益递减。推理延迟方面，8 步去噪在 A100 上约需 15ms，优于显式 scoring-based 方案的 Generator + 12×Scorer 的总成本（约 30ms）。
但 TransDiffuser 的一个弱点是不擅长处理安全关键的长尾场景：没有显式的安全打分器，模型可能在某些罕见场景下生成不安全的轨迹——因为没有"安全筛选"这道防线。
DiffusionDrive (88.1 PDMS)
虽然分数不如 TransDiffuser 高，但 DiffusionDrive 的思路更具工程可行性：它把扩散过程在轨迹空间内完成，而不是在图像或 feature 空间。这样可以大幅减少扩散模型的参数和计算量。
DiffusionDrive 的架构特点：
- 在 BEV feature 上做条件扩散
- 使用较浅的扩散步数（4-6 步）
- 推理延迟极低（< 5ms）
对于 88.1 这个分数段来说，DiffusionDrive 的效率非常高。但从 88 到 94 的差距说明：纯扩散方法在生成质量的"天花板"上不如 scoring-based 蒸馏——因为扩散模型缺乏显式的质量筛选机制。
Flow-GRPO 的尝试与反思
GRPO（Group Relative Policy Optimization）在扩散模型上的应用是一个有趣的方向。核心思路：不依赖"候选→打分"框架，而是直接在 PDMS 奖励空间下优化扩散模型的生成过程。
[Flow-GRPO 训练流程] 同一场景 => 扩散模型生成 G 条轨迹 => 计算 PDMS 奖励 => 组内标准化得 advantage => 反传梯度更新扩散模型去噪方向
但实测下来，纯 RL + Diffusion 在 NAVSIM 上的效果不如 Scoring-based 蒸馏。原因：
- 稀疏奖励：PDMS 是场景级别奖励，大部分候选的分数差异很小，RL 难学到有效梯度
- 无显式安全约束：RL 优化过程中没有安全筛选机制，可能学到"高风险高分"策略
- 样本效率低：RL 需要大量 rollout 才能收敛，而扩散模型的大推理成本使得每次 rollout 很慢
个人观点：扩散 + RL 这条路线还需要新的训练技巧才能追上 Scoring-based 蒸馏。最有可能的突破方向是将打分器作为扩散模型去噪过程中的 guidance（类似 classifier guidance），而不是用 RL 做后训练。这样既保留了扩散的多模态生成能力，又获得了打分器的安全筛选能力。
扩散路线的优劣势总结
| 维度 | 扩散生成式 | Scoring-based 蒸馏 |
|---|---|---|
| 生成质量 | 优秀（多模态覆盖好） | 取决于候选集 |
| 安全筛选 | 无显式机制 | 有打分器做安全筛选 |
| 推理速度 | 15-30ms（多步去噪） | 20-30ms（Gen + K×Scorer） |
| 训练复杂度 | 中等（端到端） | 较高（两阶段 + 蒸馏） |
| 可解释性 | 低（黑盒生成） | 高（打分器可分析） |
| 最高分数 | 94.85（TransDiffuser） | 94.5（CLOVER） |
适合谁：你对生成式模型感兴趣，想做创新研究，或者需要多模态生成能力（如变道 vs 直行的多峰轨迹输出）。
3.3 路线 C：VLA + RL 范式（ExploreVLA 为代表）
这条路线的特点是：用大语言模型的推理能力做规划。
为什么用 VLA 做规划：
- 语言模型可以理解复杂的交通规则和社会规范
- 多模态输入（图像、语言指令、地图）可以自然融合
- RL 可以端到端优化驾驶策略
代表方法 ExploreVLA (93.7 PDMS)：
ExploreVLA 的方法论很清晰：
- 用预训练的视觉语言模型作为基础（VLM backbone）
- 在 NAVSIM 数据上做模仿学习（行为克隆）
- 用 RL（PPO/GRPO）做策略优化，直接最大化 PDMS
核心创新：RL 阶段使用 PDMS 分数的可微近似，使得奖励信号可以直接反传到 VLM 的 token logits 中，实现端到端优化。这个 trick 解决了 VLA 做 RL 时的"token 离散性"问题——如果只是用 RL 优化 token 选择概率，奖励信号经过 token 采样后会非常稀疏。而可微 PDMS 评分使得 VLA 的每个 token 位置都能收到梯度信号。
AutoVLA (89.1 PDMS)：
AutoVLA 的思路更激进：完全用 RL 来训练 VLA，不做显式的模仿学习。
方法：
- 将驾驶轨迹离散化为"driving token"序列
- 用 VLM 自回归生成这些 token
- 用 GRPO 直接优化 PDMS 分数
关键设计：长 CoT 推理。“think” token 让 VLM 在生成动作之前先做推理（类似 AlpaMayo-R1 的 CoC），但推理内容不是人为标注的，而是 RL 过程中自动涌现的。
AutoVLA 的一个有趣发现：使用 GRPO 后，VLM 自动学会了在生成轨迹 token 之前先输出一段推理文本（例如"前方有行人，应该减速"，“绿灯即将变黄，加速通过"等）。这种涌现的推理行为是 SFT 阶段从未教过的——说明 RL 训练不仅优化了动作，还让模型学会了"思考”。
AlpaMayo-R1（99ms 真车部署）：
NVIDIA 的 AlpaMayo-R1 是目前最完整的 VLA 方案，虽然不是 NAVSIM 专属，但其方法论有很强的参考价值。
架构三组件：
- Cosmos-Reason VLM 骨干：预训练了 Physical AI 推理能力的 VLM
- Chain of Causation 数据集：结构化因果推理链（决策锚定 + 关键因素 + 组装 CoC）
- Flow Matching 动作解码器：将离散轨迹 token 解码为连续动力学可行的轨迹
三阶段训练：动作注入 SFT -> 推理激发 SFT -> GRPO 后训练（优化推理质量 + 推理-动作一致性 + 轨迹质量）
真车路测延迟仅 99ms，说明 VLA 的实时性瓶颈是可以被克服的——关键在于模型设计（轻量 VLM + 高效解码器）而非模型规模。
VLA 路线在 NAVSIM 上的关键挑战：
| 挑战 | 原因 | 可能的缓解方法 |
|---|---|---|
| 推理延迟 | VLM 自回归生成 token 需要数十到数百步 | 使用 1-3B 小模型 + 推测解码 |
| RL 训练不稳定 | VLA 参数量大，PDMS 奖励稀疏 | 先用模仿学习初始化，再用 RL 微调 |
| 安全可靠性 | 无显式安全筛选机制 | VLA + Scoring-based 联合推理 |
| 候选多样性 | VLM 生成天然趋同 | 温度采样 + beam search |
| 可复现性 | 随机采样下结果波动大 | Greedy decoding + 确定性推理模式 |
适合谁：你做学术研究、有大把 GPU 资源、想探索 VLA + RL 的前沿方向。
3.4 我的观点
如果你只想刷高分：选路线 A（Scoring-based）。 如果你想发论文：选路线 B（扩散/Flow + 蒸馏）。 如果你想做大新闻：选路线 C（VLA + RL）。
Scoring-based 路线统治排行榜不是偶然的。它的"生成+打分"结构天然适配 PDMS 的评估方式——PDMS 本质上就是一个打分器。
但更重要的是，Scoring-based 范式的蒸馏机制是当前已知的、唯一能系统性提升 PDMS 到 92 分以上的方法。
CLOVER 的闭式蒸馏、Hydra-MDP 的多头蒸馏、CLEAR 的对比蒸馏，本质上都在做同一件事：让 Generator 朝 Scorer 的偏好方向对齐。
3.5 路线 D：世界模型 VLA 范式（前沿探索）
这是一条目前还没有在 NAVSIM 排行榜上验证到 90+ 的路线，但理论潜力非常大。世界模型 VLA 的核心思路是在"生成轨迹"的基础上更进一步：让模型不仅生成当前的最佳轨迹，还能预测轨迹执行后的未来状态，并在预测的未来状态上做规划。
世界模型 VLA 做什么？
传统 Scoring-based 规划器的工作流：
当前场景 => [Generator] => 候选轨迹 => [Scorer] => 选最优轨迹
世界模型 VLA 的工作流：
当前场景 => [策略网络] => 候选轨迹 => [世界模型] => 预测执行后果 (评估) 检查安全性、舒适度、规则遵守 (评估) 选择最优轨迹
区别在于：世界模型提供"预演"能力——在轨迹被执行之前，先仿真一遍未来几秒会发生什么，然后基于"预演结果"做决策。
代表方法
DriveDreamer（世界模型作为规划器）
- 训练一个驾驶世界模型，学习状态转移函数 $p(s_{t+1}|s_t, a_t)$
- 推理时在 latent 空间内"想象"多条轨迹的未来
- 用奖励模型（类似 scoring-based 的 scorer）在"想象"的未来状态上评估
- 选择最大化累计奖励的轨迹
Gen-Drive / 扩散世界模型
- 用扩散模型同时建模场景演化（其他车辆的轨迹）和自车轨迹
- 不做显式的 “决策→预测” 分离，而是联合生成自车和其他交通参与者的未来轨迹
- 优势：对交互场景（变道博弈、交叉路口）有更好的建模
Cosmos（NVIDIA 世界基础模型）
- 训练在数千万驾驶视频上的世界模型
- 可以"想象"给定自车轨迹后的场景演化
- 输出未来的视频帧，做视觉级别的 safety checking
- 虽然还没有直接用于 NAVSIM 规划器，但其物理推理能力理论上可以直接提升 EP
GaiaFlow / 交互感知 Flow
- 用 Flow Matching 建模交通场景中所有 agent 的联合轨迹分布
- 自车轨迹是联合分布的一个条件维度
- 通过边缘化其他 agent 的轨迹来评估自车轨迹的安全性
世界模型 VLA 如何帮助 90+ PDMS？
针对 EP 优化：世界模型可以"预演"不同速度下的未来场景。如果你在犹豫"这个绿灯还够不够过"，世界模型可以提前模拟出 3 秒后的场景，告诉你能不能安全通过。这使得模型可以在保证安全的前提下最大化 EP——这正是 90 分以上最需要的。
针对长尾场景：世界模型的"想象"能力可以直接覆盖训练数据中没见过的场景。即使模型没见过"施工改道 + 行人横穿"的组合，也可以通过在想象空间中推理来找到安全的驾驶策略。
针对候选多样性：在世界模型的 latent 空间中搜索候选路径，比在轨迹坐标空间中搜索更高效。因为世界模型可以理解"这个区域是马路、那个区域是人行道"——它天然约束生成的候选轨迹在可行驶区域内。
为什么世界模型 VLA 还没有 90+？
尽管理论优势明显，世界模型 VLA 在 NAVSIM 上有两个核心瓶颈：
世界模型的精度不够：驾驶世界模型需要精确预测未来 8 秒的场景变化（其他车辆、行人等）。当前的世界模型在 2-3 秒后就开始产生漂移，导致"预演"结果不可靠。打分器用的是不准确预演结果，选出的轨迹自然也差。
计算成本太高：每条候选轨迹都需要世界模型 rollout 8 秒场景。如果候选数 K=12，每帧需要做 12 次 world model rollout。当前 SOTA 世界模型的单次 rollout 需要 10-50ms，12 次就是 120-600ms——远远超出实时要求。
世界模型 VLA vs Scoring-based：不是替代关系
我倾向认为世界模型 VLA 和 Scoring-based 是互补而非替代关系。
最有可能的融合路线：
Generator => 候选轨迹 => [世界模型快速预演] => [Scorer 精打分] => 选最优
用世界模型做快速预筛选（成本高但准确率高），用 Scorer 做精细打分（成本低但需要训练）。这样既利用了世界模型对场景演化的理解能力，又保持了 Scoring-based 的高效性。
适合谁：你有无限 GPU 资源、想探索下一代规划范式、不介意当前的低分但看重长远潜力。
上面说过，当安全指标全部拉满后，PDMS 的唯一瓶颈就是 EP。现在我们来深入看看，到底怎么优化 EP。
4.1 EP 的本质
EP 衡量的是主车在 8 秒场景内的前进量。参考前进量是固定的（test-hard 场景为 28.0m），所以 PO 要优化其实很简单：让主车走得更远。
但为什么很难做到 EP = 1.0？
因为 NAVSIM 中有很多场景要求主车停下来等：
- 红灯前等待
- 行人过马路时等待
- 有车切入时减速让行
- 交叉路口让行
在这些场景下，强行加速前进会触发碰撞（NC），导致整段分数归零。所以 EP 优化的本质是在安全和前进之间找到最优平衡。
4.2 EP 优化的三个层次
层次一：保守策略（EP 0.7-0.8）
只在安全时加速，不自信时一律减速等待。这种方法碰撞率极低，但很多场景下主车会"犹豫不前"。
典型表现：在可通行路口也要减速观察，导致 EP 偏低。
层次二：激进策略（EP 0.8-0.9）
通过学习人类驾驶数据，模型学会了在大多数场景下保持合理速度。但在少数复杂场景（无保护转弯、行人混淆场景等）会出错——要么碰撞，要么过于保守。
典型表现：大部分场景 EP 很高，但少数场景出了错导致 NC 扣分。
层次三：最优策略（EP 0.9-0.95）
模型学会了在不同场景下自适应调整速度：安全时保持高速，复杂时适当降速但不停车。这才是 CLOVER 等顶尖方案达到的水平。
4.3 CLOVER 如何优化 EP
CLOVER 的闭式蒸馏对 EP 的优化可以概括为：
Generator 不再只是模仿人类驾驶，而是模仿"打分器认为好的驾驶行为"。
人类驾驶不一定是最高分的行为——人类可能开得太慢（EP 低）、或者太激进（碰撞风险高）。而打分器训练的目标直接就是最大化 PDMS，所以打分器认为好的行为是 PDMS 最优的。
通过蒸馏：
对比实验数据（来自 CLOVER 论文）：
- 不做蒸馏的 Baseline：EP 0.82，PDMS 86.5
- 基础蒸馏：EP 0.87，PDMS 89.2
- CLOVER 闭式蒸馏：EP 0.93，PDMS 94.5
可以看到蒸馏的收益主要集中在 EP 上。对安全指标（NC、DAC、TTC、C）的改进很小，因为 Baseline 已经做得不错了。
五、数据集策略：在哪个数据集上训练与测试？
NAVSIM 的数据集设计非常巧妙，理解它的结构对刷分至关重要。
5.1 Navtrain vs Navtest vs Navhard
NAVSIM 有三个主要的数据集划分：
Navtrain（训练集）：
- 约 74,000 个场景
- 覆盖了大多数常规驾驶场景
- 场景时长：8 秒
Navtest（标准测试集）：
- 约 10,000 个场景
- 难度分布与 Navtrain 相似
- 排行榜上主要报告的分数
Navhard（高难度测试集）：
- 约 10,000 个场景
- 专门筛选的高难度场景
- 包含很多 corner case
5.2 关键洞察：用哪个数据集训练决定了你的上限
如果在 Navtrain 上训练，在 Navtest 上测试：你的模型学习的是 Navtrain 的数据分布。Navtest 和 Navtrain 同分布，所以分数会偏高。
真实场景下的泛化能力：Navtrain → Navhard 的迁移能力才是真正考验。
高分方案的训练策略：
| 方法 | 训练数据 | Navtest | Navhard |
|---|---|---|---|
| CLOVER | Navtrain + 蒸馏自生成 | 94.5 | ~92 |
| TransDiffuser | 全量数据 | 94.85 | - |
| Hydra-MDP | Navtrain + 增强 | 91.3 | ~89 |
| ExploreVLA | Navtrain + RL | 93.7 | ~90 |
注意 CLOVER 和 TransDiffuser 在 Navtest 上的分数非常接近（94.5 vs 94.85），但在 Navhard 上可能会有显著差异。
5.2.1 Navhard 的特殊性
Navhard 是 NAVSIM 中最难的数据集，高分方案往往在这里暴露真实差距。
Navhard 的特点：
- 场景复杂度高：包含更多交互、更多交通参与者
- 长尾分布：很多场景在训练集中极少出现
- 决策多样性低：很多时候只有一种"正确"的驾驶方式
一个模型在 Navtest 上得 94 分，在 Navhard 上可能只有 88-90 分。差距主要来自：
- 罕见场景的处理能力
- 对复杂交互的建模
- 候选轨迹在困难场景下的鲁棒性
提升 Navhard 分数的策略：
- 在 Navhard 上做蒸馏——将 Navhard 场景加入蒸馏训练。即使 Navhard 没有官方 label，你可以用 scoring-based 框架生成 pseudo-label。
- 困难场景挖掘——识别模型在 Navtrain 和 Navhard 中表现最差的场景，做针对性增强。
- 数据混合——在训练时按比例混合 Navtrain 和 Navhard 数据，不要让模型偏科。
5.3 自生成数据的策略
如果你想要真正的高分（93+），你必须做自生成数据——用当前模型在场景上生成新的轨迹，然后用打分器筛选出高分轨迹加入训练。
自生成数据的流程：
- 遍历 Navtrain 的场景
- 用当前 Generator 为每个场景生成 K 条候选轨迹
- 用 Scorer 对这些候选打分
- 筛选出分数最高的候选（或分数超过某个阈值的候选）
- 将这些候选轨迹作为新的训练数据（pseudo-GT）
- 混合原始 GT 和 pseudo-GT 重新训练 Generator
关键参数：
- 筛选阈值：过高则数据太少，过低则数据质量差。建议用 top-10% 或分数高于某个固定阈值（比如 0.95）。
- 混合比例：pseudo-GT 的比例太高会导致模型"自我强化"（reinforcing own biases）。建议 pseudo-GT 占比 20-30%。
- 迭代轮数：一般 2-3 轮自生成后收益递减。过多的迭代会导致 diversity collapse。
CLOVER 的创新点之一：CLOVER 不是在 Generator 固定后做一次自生成，而是在训练过程中动态自生成。每次 Generator 更新后，都会重新生成候选，打分筛选，然后继续训练。这种"在线自生成"的方式比"离线自生成"效果更好，因为 Generator 在不断进化，生成的数据也在进化。
5.4 我的建议
如果你资源有限，优先在 Navtrain 上做精，不要去碰全量数据。原因：
- Navtrain 已经足够覆盖大多数场景
- 全量数据中难例占比低，边际效用递减
- 在 Navtrain 上精调比在全量数据上粗调更有效
但如果你已经有基础方案（85+），开始做自生成数据。收益：1-3 分 PDMS。
六、打分器设计：ScoreNet 的架构与训练细节
Scoring-based 范式的核心是打分器。如果你要做个自己的打分器（而不是直接用 NAVSIM scorer），以下几个细节值得注意。
6.1 ScoreNet 架构
NAVSIM scorer 是一个基于 Transformer 的打分器：
- 输入：场景上下文 maps（车道、交通灯）+ agents（其他车辆、行人）+ 主车轨迹
- 编码：分别对道路元素、agent 轨迹和主车轨迹做编码
- 融合：交叉注意力融合场景信息和轨迹信息
- 输出：标量分数（PDMS 的估计值）
6.2 训练打分器的关键
监督信号：使用 NAVSIM 官方 scorer 计算的 PDMS 分数作为 GT。
损失函数：
- 回归损失：MSE + MAE
- 排序损失：确保高分候选的预估分数高于低分候选
数据增强：
- 对轨迹添加噪声
- 随机裁剪场景
- 混合不同场景的候选轨迹
6.3 打分器训练的几个陷阱
陷阱 1：打分器过拟合
如果你的打分器在训练集上表现完美但在测试集上很差，说明过拟合了。解决方法：
- 增加 dropout
- 增加训练数据（用自生成数据）
- 使用正则化
陷阱 2：打分器不准确
打分器预估的分数和实际 PDMS 差异很大，导致选择错误候选。解决方法：
- 检查打分器的校准（calibration）
- 使用 ensemble 方法
- 在困难场景上做 hard negative mining
陷阱 3：打分器偏好偏差
打分器倾向于选择某种特定的轨迹（比如过于保守的轨迹），导致 EP 偏低。解决方法：
- 在训练数据中加入更多 EP 高的样本
- 使用多样性奖励（diversity reward）来平衡打分
七、梯度与协作的反直觉实验
在探索 NAVSIM 高分的过程中，我碰到的几个反直觉现象值得分享。
7.1 打分器越准，Generator 越难提升？
这是一个让人迷惑的发现：如果打分器已经非常准确（在验证集上 99% 以上的排序正确率），那么蒸馏的收益反而会递减。
原因是：当打分器几乎不会选错时，Generator 只要生成一个"及格"的候选就能被选中。继续提升 Generator 的质量，并不会改变打分器的选择结果。这是一个信息瓶颈。
CLOVER 的闭式蒸馏解决了这个问题，因为它不依赖于"打分器选了什么"，而是直接学习打分器的分数梯度。
7.2 多轮蒸馏不一定有效
另一个发现：多轮蒸馏有边际效用递减，甚至会出现"蒸馏退化"。
第二轮蒸馏时，Generator 生成的候选可能已经同质化（都在模仿第一轮蒸馏学到的最好轨迹），多样性反而降低了。这时需要引入多样性的保证。
解决办法：在蒸馏时加入 entropy bonus 或 diversity constraint。
7.3 Navtest 分数高 ≠ 实际能力强
这是最重要的一个警示：NAVSIM 的 Navtest 是开环评测，模型不会看到自己决策后的实际后果。
一个模型在 Navtest 上得了 94 分，但在闭环仿真中可能表现很差。这是因为开环评测中，模型不需要为自己的行为负责——它的决策不会影响后续决策的上下文。
如何避免这个问题：
- 同时在 Navtest 和 Navhard 上评估
- 做闭环仿真验证
- 关注模型在长尾场景上的行为
八、消融实验深度分析
为了更清晰地理解每个模块的具体贡献，我整理了一个完整的消融实验分析。这些数据来自多篇论文和我的实测经验。
8.1 标准消融模板
| 实验配置 | Navtest PDMS | Navhard PDMS | NC | EP |
|---|---|---|---|---|
| Baseline (SFT only) | 78.2 | 72.1 | 0.85 | 0.58 |
| + Scoring (K=6) | 85.4 | 80.3 | 0.97 | 0.72 |
| + Scoring (K=12) | 87.9 | 83.1 | 0.98 | 0.78 |
| + 基础蒸馏 (1轮) | 89.6 | 85.2 | 0.99 | 0.84 |
| + 基础蒸馏 (2轮) | 90.3 | 86.0 | 0.99 | 0.86 |
| + 多样性增强 | 91.2 | 87.1 | 0.99 | 0.88 |
| + 闭式蒸馏 (CLOVER) | 94.5 | 91.2 | 1.00 | 0.93 |
8.2 蒸馏轮数的消融
很多人在蒸馏轮数上存在误区——认为"越多越好"。实际上，蒸馏轮数的影响非常微妙：
第 0 轮（无蒸馏）：Generator 生成的候选轨迹质量完全取决于 SFT 质量。如果 SFT 训练得好，基础 PDMS 在 85 左右。但如果 SFT 质量一般，可能只有 80 出头。
第 1 轮蒸馏：收益最大。从无蒸馏到第 1 轮蒸馏，PDMS 通常提升 3-5 分。这正是大多数入门方案能达到的水平（88-90）。
第 2 轮蒸馏：收益递减。第 2 轮提升约 1-2 分。原因在于 Generator 已经学到大部分"明显"的改进空间，剩下的都是边际改进。
第 3 轮及以后：收益极小（< 0.5 分），甚至可能出现退化。退化原因是 Generator 的候选轨迹开始同质化——所有候选都集中在同一个"最优"模式，多样性下降。
什么时候停止蒸馏：
- 当相邻两轮蒸馏的 PDMS 提升 < 0.3 分时，停止
- 当同一场景下 K 条候选的分数方差明显下降时，停止（信号：候选同质化）
- 在验证集上监控 EP 的分布，如果分布变窄但均值不变，停止
8.3 候选数量 K 的消融
| K | Generator 计算量 | Scorer 计算量 | PDMS 变化 |
|---|---|---|---|
| 1 | 1x | 忽略 | -7.2 (baseline +0) |
| 3 | 1x | 3x | -2.8 |
| 6 | 1x | 6x | +0.0 (基准) |
| 12 | 1x (共享计算) | 12x | +2.3 |
| 24 | 1x (共享计算) | 24x | +3.1 |
| 48 | 1x (共享计算) | 48x | +3.5 |
关键洞察：从 K=6 到 K=12，PDMS 提升约 2.3 分，这是最大的边际收益。再往上，收益递减。
对于实际部署，建议 K=12（推理总耗时：Generator 前向 ×1 + Scorer 前向 ×12）。对于刷榜，可以用 K=32 或更高。
8.4 打分器架构的消融
| 打分器架构 | 参数量 | Navtest PDMS | 推理耗时 |
|---|---|---|---|
| MLP (2层) | 1M | 86.1 | 0.1ms |
| Transformer (4层) | 8M | 88.5 | 0.5ms |
| Transformer (8层) | 20M | 89.2 | 1.1ms |
| Transformer (12层) | 35M | 89.4 | 1.8ms |
| Transformer (12层) + Ensemble | 140M | 89.7 | 7.2ms |
打分器的深度在超过 8 层后收益显著递减。这是因为打分器的监督信号（NAVSIM scorer 的输出）本身包含噪声，太深的模型可能会过拟合这些噪声。
我的建议：用 8 层 Transformer 作为默认配置，如果有余力再做 4 个模型的 ensemble。
8.5 蒸馏温度的消融
闭式蒸馏中的 temperature 参数控制分数梯度的"锐度"：
| Temperature | 行为 | 效果 |
|---|---|---|
| 小 (0.1) | 只关注最高分候选 | 类似于传统蒸馏，多样性差 |
| 中 (0.5) | 关注 top-3 候选 | 效果好，推荐 |
| 大 (1.0) | 所有候选权重相近 | 训练稳定但收敛慢 |
推荐初始值 0.5，如果你的 Generator 已经质量不错（PDMS > 88），可以降低到 0.3 来更聚焦于最高分模式。
九、实战技巧总结
基于上面的分析，我总结一下在 NAVSIM 上刷高分的实战技巧。
9.1 从零开始刷分路线图
第 1 周：基础搭建
- SFT 模仿学习：用 Navtrain 做行为克隆
- 目标：PDMS 78-82，碰撞率 < 5%
- 关键：数据质量比数量重要
第 2 周：Scoring-based
- 实现 Generator-Scorer 架构
- 训练基础打分器（用 NAVSIM scorer 做监督）
- 目标：PDMS 84-88，安全指标基本拉满
第 3 周：蒸馏优化
- 实现蒸馏机制（基础蒸馏即可）
- 提升候选多样性
- 目标：PDMS 88-91
第 4 周：闭式蒸馏（可选）
- 实现 CLOVER 的闭式蒸馏
- 联合优化 Generator 和 Scorer
- 目标：PDMS 91-94
9.2 常见陷阱与解决方法
| 问题 | 症状 | 解决 |
|---|---|---|
| 碰撞率高 | NC < 0.9 | 检查 SFT 质量，做碰撞场景增强 |
| EP 低 | EP < 0.75 | 增加候选多样性，优化 Generator |
| 候选同质化 | 所有候选轨迹相似 | 加入 diversity constraint |
| 打分器不准 | 预选分数 ≠ 实际分数 | 更深的 Scorer、更多训练数据 |
| 过拟合 | Navtest 高分，Navhard 低分 | 正则化、dropout、数据增强 |
| 蒸馏退化 | 多轮蒸馏后分数不升反降 | 加入 diversity，减小蒸馏步长 |
9.3 快速提升 PDMS 的 5 个"杠杆"
如果你想用最小代价获得最大提升，按优先级做以下 5 件事：
- 做蒸馏（收益：3-5 分）—— 这是 88→92 的最关键一步
- 提升候选多样性（收益：2-3 分）—— 扩展 Generator 的覆盖范围
- 优化 EP（收益：1-3 分）—— 安全指标基本搞定后唯一还能优化的项
- 加深打分器（收益：1-2 分）—— 更准的打分器能更好地甄别候选
- 做闭环验证（收益：保真度）—— 确保你在 Navtest 上的高分不是"虚假繁荣"
9.4 训练超参数推荐
最后给出一些经过验证的超参数配置，节省你调参的时间：
Generator 训练：
- 学习率：1e-4（AdamW）
- Batch size：64-128
- 轨迹长度：8s × 10Hz = 80 个 waypoint
- 候选数量 K：12（训练时）/ 12-32（推理时）
- 损失权重：Trajectory L1 Loss = 1.0, Collision Loss = 0.1 (可选)
Scorer 训练：
- 学习率：3e-5（AdamW）
- Batch size：32-64（每个场景 K 条候选，B×K 的总样本数）
- 训练数据：Navtrain + 自生成（混合比例 8:2）
- 损失函数：BCE（最大熵分类）或 MSE（回归）
- 数据增强：轨迹加噪声（σ=0.1m）
蒸馏训练：
- 学习率：1e-4（Generator）/ 1e-5（Scorer）
- Temperature：0.5（闭式蒸馏）
- 轮数：2-3 轮
- 每轮蒸馏步数：5000-10000 steps
硬件要求：
- Generator + Scorer：4×A100（~3 天训练到 90+）
- 仅蒸馏：1×A100（~1 天）
- 推理（单场景）：~5ms（Generator）+ 12×~2ms（Scorer）= ~30ms
十、展望：PDMS 95+ 的下一步
CLOVER 的 94.5 让人印象深刻，但它真的是上限吗？我觉得不是。以下是我认为还能突破的方向。
10.1 扩散模型 + Scoring-based 的融合
TransDiffuser 证明了扩散模型在规划上的潜力，但它目前还没有和 Scoring-based 范式深度融合。
我猜下一个突破会是：用扩散模型做 Generator，Scoring-based 做选择。扩散模型的生成多样性天然优于 CVAE，但需要解决推理速度问题。
10.2 多模态决策融合
当前的方案大多只做"单模态轨迹生成"（预测主车轨迹）。但其实规划问题可以拆解为"决策 + 轨迹"两个维度。
一个可能的突破方向：先用一个决策模块输出意图（如"直行"、“左转”、“等待"等），然后为每个意图生成轨迹。这样可以在决策层面保证多样性，再在轨迹层面做精细优化。
10.3 RL + Scoring-based 的融合
GRPO 在 Diffusion 上的尝试虽然效果有限，但 RL + Scoring-based 的融合可能更有前景。
具体来说：用 RL 优化 Scoring-based 框架中的某个环节（比如 Generator），而不是做端到端 RL。这样既能利用 RL 的长处（探索），又能保留 Scoring-based 的稳定性。
CLOVER 的蒸馏本质上和 RL 有共通之处——“Generator 生成轨迹→Scorer 评估→反馈→改进"的循环，和 RL 的"actor-critic"结构非常相似。
10.4 更高效的数据利用
NAVSIM 的数据利用率其实很低。目前大多数方案只用了 Navtrain（74k 场景），而 NAVSIM 全量数据约有数百万场景。
如果能高效利用全量数据（特别是其中的难例），应该能有 1-2 分的提升。
10.5 可解释性与可控性
当前的高分方案基本是"黑盒”——模型输出一个轨迹，你不知道它为什么选择这个轨迹。
未来方向：让 Scoring-based 范式的打分解更加可解释。比如打分器不仅输出一个总分，还输出每个子指标（NC、EP、TTC、C）的预测分数。这样开发者可以理解模型的决策逻辑，在出现问题时可以针对性修正。
CLOVER 已经有这个雏形——它的打分器实际上预测的是 PDMS 的各个分解项，最终分数是这些分解项的加权组合。这个方向值得持续关注。
10.6 实时性与效率
目前的推理速度：Generator（~5ms）+ Scorer × K（~24ms），总计约 30ms 在 A100 上。这对实时部署来说还有点紧张（需要至少 20ms 以内）。
优化方向：
- Scorer 的轻量化（用 MLP 替代 Transformer）
- 候选的剪枝策略（先用快速打分器初筛，再用精打分器精选）
- ONNX / TensorRT 部署优化
十一、写在最后
写这篇文章的初衷，是希望后来者能少走弯路。NAVSIM 的 Scoring-based 范式看起来简单（“不就是生成候选然后打分吗”），但里面每个环节都有值得深挖的细节。
回顾一下全文的核心信息：
- 理解 PDMS 公式——乘性惩罚决定下限，EP 决定上限，不同分数段有不同瓶颈
- 从 SFT 起步——不要跳过基础能力训练直接上高级方法
- Scoring-based 是经过验证的高分框架——Generator + Scorer + 蒸馏是最可靠的 90+ 路径
- 候选质量比打分器更重要——打分器只能在已有候选中选择，候选集决定了分数上限
- EP 是 90+ 的唯一瓶颈——当安全指标拉满后，唯一能优化的就是 EP
- CLOVER 的闭式蒸馏是当前的最优方案——它消除了传统蒸馏的信息损失
- 正视开环评测的局限性——Navtest 高分不等于实际部署能力
最后想说的是：排行榜上的数字只是一个参考。真正好的规划器，不仅要分数高，还要可解释、可控制、安全可靠。Scoring-based 范式在这方面有天然优势，这也是为什么它在学术界和工业界都受到关注。
如果你在刷 NAVSIM 的过程中有任何新的发现或不同的观点，欢迎交流。这个领域还在快速发展，现在的高分方法论也许明天就被超越了。
加油，期待在排行榜上看到你的名字。
本文基于 NAVSIM 2024-2026 年公开论文、排行榜数据和开源代码的分析。数据截止到 2026 年 7 月。