← 返回 PaperDaily
视觉与图像
ASSCG来了：自动驾驶LLM该查、该存、还是该扔？
自动驾驶里最怕的不是“慢”，而是慢系统该出手时没出手、不该出手时瞎出手。ASSCG把这个老大难问题拆成“查、存、扔”三种动作，思路很朴素，效果却相当能打。
龙哥读论文
阅读 3
查看原文
🐉 龙哥读论文知识星球来了！公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～
龙哥推荐理由：
自动驾驶里最怕的不是“慢”，而是慢系统该出手时没出手、不该出手时瞎出手。ASSCG把这个老大难问题拆成“查、存、扔”三种动作，思路很朴素，效果却相当能打。
原论文信息如下：
快慢规划困境：LLM何时该出手？何时该闭嘴？
自动驾驶规划里，慢系统通常指大语言模型或视觉语言模型这类“脑子很大、反应不算快”的模块；快系统则是实时规划器，负责每一帧都得稳稳当当地把车往前开。问题就来了：慢系统不是天天都该上场。它太勤快，算力和时延直接爆表；它太懒，又可能错过关键交互，甚至把车带沟里去。于是论文把这个老问题说得很直白：不是“要不要用LLM”，而是“什么时候用、用多久、用了之后还信不信”。
这篇工作最有意思的地方，不是简单给慢系统加个开关，而是把它拆成三种动作：Query、Cache、Drop。Query 是“现在该请慢系统出山了”，Cache 是“上次的建议还能接着用”，Drop 则更狠一点：这条慢建议不靠谱，直接扔掉。这就很像老司机开车时的判断：导航可以参考，但要是导航开始把你往河里领，那就别犹豫，赶紧关掉。
这里顺手解释两个缩写，免得读者被论文术语绊一跤。LLM 是 Large Language Model，中文常译为“大语言模型”。VLM 是 Vision-Language Model，即“视觉语言模型”。论文里还用到 GRPO，即 Group Relative Policy Optimization，中文可理解为“组相对策略优化”，这里是借鉴其“按组比较、做策略更新”的思路来训练门控策略，而不是让门控凭感觉乱点按钮。
论文先点破了一个现实：很多现有快慢协同方案，看起来很聪明，实际却有点“玄学”。固定频率查询最省脑子，但也最死板；按场景难度触发看似合理，但“难不难”这个代理指标，未必真能代表“这一次请慢系统出手值不值”。更尴尬的是，慢系统并不是每次都帮忙，有些片段里它甚至会添乱。于是作者把问题升级成一个更像控制论的任务：在资源预算下，学习一个帧级决策器，判断慢系统该不该被调用、该不该继续沿用、还是该直接屏蔽。
直觉量化：定义“等效区间”与“失效区间”
为了不让门控变成拍脑袋，论文先把“什么时候该复用”“什么时候该停用”这件事做了概念化。作者提出三个很关键的时间概念：等效区间、有效区间和失效区间。它们听起来像考试名词，实际是给门控策略划边界：哪些时候慢系统的建议还是“新鲜的”，哪些时候继续用它能省算力，哪些时候它已经开始胡说八道。
先说等效区间（Equivalent Interval, EI）。它指的是：刚刚查询完慢系统后的一段时间里，重新查询得到的信息几乎没变化，收益很小。说白了就是“刚问过，别急着再问”。如果慢系统输出的语义特征几乎没变，或者再次调用对控制轨迹的影响很小，那这段时间就属于等效区间。这个概念特别朴素，但很实用，因为很多计算浪费，恰恰来自这种“刚说完又问一遍”的重复劳动。
再看有效区间（Effective Interval, EfI）。它表示当前这份慢系统指导真的被快系统用起来了，而且在一段时间内仍然有效。EfI 可以理解成“这口锅还能继续炒菜”的窗口。EfI 太短，说明慢系统来得太勤，算力白烧；EfI 太长，又可能让指导陈旧。理想状态当然是 EfI 和 EI 尽量接近，既不浪费，也不过时。
最有杀伤力的是失效区间（Failure Interval, FI）。它不是“慢系统没用”，而是“慢系统此时一出手，反而更糟”。这点很关键，因为很多人默认“加大模型一定更好”，但在自动驾驶里，局部交互、遮挡、时序延迟、状态误判都会让慢建议变成干扰项。论文明确指出：慢系统不是圣旨，它也会翻车。所以门控不只是决定“要不要叫它来”，还要决定“来了以后要不要相信它”。
为了把这些概念从口头描述变成可学习的策略，作者把门控建模成一个序列决策问题。每一帧，门控都要基于当前场景、历史缓存和时间间隔做选择。这里最像“人”的地方在于，它不是一次性决定整段场景的快慢比例，而是像老司机那样边开边看，动态修正。这个设计比固定间隔更灵活，也比纯难度阈值更贴近真实收益。
自适应门控ASSCG：查、存、扔三档智能切换
ASSCG 的全名是 Adaptive Slow-System Control Gate，中文可以理解为“自适应慢系统控制门”。它的任务很明确：每一帧都要决定要不要刷新慢系统、要不要继续沿用、或者要不要把慢系统输出直接屏蔽掉。这个门控不是摆设，而是整个快慢协同里真正管钱、管命、管算力的那位。
从结构上看，ASSCG 不是把一个大模型硬塞进控制器，而是用一个轻量时序骨干来做门控。论文选了 RWKV 作为时序主干。RWKV 的全称是 Receptance Weighted Key Value，中文常译为“接收加权键值”架构。它的优势在于：既保留了序列建模的记忆能力，又不至于像标准 transformer 那样把长序列算得满头大汗。对门控来说，这很合适，因为它要看的不是一帧两帧，而是一整个驾驶片段的节奏。
门控输入也很讲究。它不是只看当前帧的“热闹程度”，而是把三个信息拼起来：当前场景的压缩表示、缓存里的参考慢指导、以及距离上次慢查询过去了多久。论文先用一个轻量注意力池化把场景 token 汇总，再和缓存特征做余弦相似度比较，同时加入时间特征。这样一来，门控就不只是“看眼前”，还知道“刚才问过没有”“问过之后变化大不大”。这比单纯看复杂度靠谱得多，因为复杂场景并不一定需要慢系统，简单场景也不一定永远安全。
从动作语义上看，三档切换其实很像现实里的驾驶决策：Query 是“重新问一次导航和策略建议”，Cache 是“继续按上一次的建议开”，Drop 则是“这条建议不对劲，先别听”。特别是 Drop，这个动作很有胆识。很多门控只会“开”或“关”，但这篇论文明确承认：有时候最好的策略不是少问，而是把错误建议彻底踢出局。这就是它和“只会省算力”的方法最大的不同。
训练上，论文也没有玩虚的。第一阶段先做监督微调，利用固定查询策略里“得分最高”的轨迹当伪标签，让门控先学会一个像样的初始策略。第二阶段再上强化学习，而且是带计算成本意识的强化学习：每一次 Query 都要付出代价，Cache 和 Drop 则能省掉这笔开销。这样训练出来的门控，不会只盯着分数，也会掂量算力账本。说人话就是：既要跑得好，也要少烧钱。
这里还要提一下一个很实用的工程点：论文把原始快慢系统冻结住，只训练门控本身。这样做的好处是，提升更容易归因——如果结果变好了，基本能说明是“调度更聪明”而不是“模型又偷偷长大了”。对研究来说，这种控制变量的写法很重要，不然最后很容易变成“到底是谁在立功，谁也说不清”。
结果逆袭：分数涨2.28，耗时降60%
这部分是最容易让人点头的地方：ASSCG 不是只在概念上“挺聪明”，而是确实把结果做出来了。在 nuPlan Hard20 闭环评测上，把 ASSCG 接到 AsyncDriver 之后，整体分数提升到 67.28，比原始系统提升 2.28 分；同时平均端到端推理时延大约降低 60%。这就不是“做了个漂亮门控图”的水平了，而是实打实把效率和效果一起往上拽了一把。
从指标拆解看，ASSCG 的收益并不是靠“猛冲路线进度”换来的，而是更多体现在安全和规则遵循上。比如可行驶区域遵循、行驶方向一致性、舒适性、碰撞相关指标和 TTC 都有改善。这意味着门控不是单纯减少慢系统调用，而是更准确地挑选了“该信慢系统的时候”和“该屏蔽它的时候”。换句话说，它不是省掉了思考，而是把思考用在了刀刃上。
论文还做了一个很有说服力的对照：拿一个固定每 5 帧查询一次的基线来和 ASSCG 比。这个基线的平均时延和 ASSCG 差不多，算是“效率对齐”的公平比较。结果 ASSCG 在相近时延下，分数从 64.27 提到 67.28。这说明收益并不只是“少问慢系统所以更快”，而是“会问、会存、会扔”本身带来了更好的时机选择。
在 NAVSIM 上，论文又把同样的门控思想迁移到另一个快慢系统里。这里的设置换成了基于 RecogDrive 的双系统：快分支用轻量视觉骨干，慢分支保留更强的视觉语言模块，门控则简化成二分类，决定走快还是走慢。结果是 PDMS 提升到 91.4，同时平均推理时延也进一步下降。这个结果很重要，因为它说明 ASSCG 不是只对某个特定架构有效，而是有一定的架构无关性。
消融解码：Drop动作和强化学习定乾坤
如果只看主结果，容易以为 ASSCG 只是“一个更会挑时间的门”。但消融实验告诉读者，真正把这个方法立住的，恰恰是两个看起来不那么花哨的设计：Drop 动作和计算感知强化学习。前者负责“把坏建议踢出去”，后者负责“让门控学会算账”。少了这两个，门控就容易退化成一个只会复用缓存的保守派。
先说 Drop。很多人会下意识觉得，既然慢系统都已经算出来了，为什么不用？论文的回答很直接：因为它有时候会误导快系统。尤其在复杂交互里，慢系统的高层语义并不总是可靠，错误的参考会让轨迹更保守、更犹豫，甚至更危险。Drop 动作本质上是在告诉模型：“不是所有信息都值得留在缓存里。” 这个判断非常重要，因为它让门控从“节流器”升级成了“过滤器”。
再看强化学习。监督微调能让门控学到“像样的历史模式”，但它学到的通常只是某种离线最优的影子，未必真懂闭环驾驶里“少一次调用能省多少、错一次调用会坏多少”。强化学习阶段引入了查询代价，门控就开始真正面向闭环目标优化。论文里用 GRPO 风格的策略优化，再加上 KL 约束和熵奖励，让策略既不会乱跑，也不会一味保守。这种训练方式的意义在于：门控最后学到的不是“少用慢系统”，而是“把慢系统用在刀口上”。
另外，论文还展示了固定查询策略的网格搜索结果。这个实验很有意思，因为它说明最佳查询频率并不是一个全局常数，而是会随场景类型变化，甚至同一类型里不同 episode 也会不一样。也就是说，固定间隔策略天然会吃亏；ASSCG 的价值就在于把“场景差异”和“时间差异”都纳入了决策。对自动驾驶这种长尾场景特别多的任务来说，这种细粒度自适应是很有必要的。
龙迷三问
这篇论文到底解决什么问题？它解决的是自动驾驶里快慢协同的“调用时机”问题：慢系统不是越频繁越好，关键是要在值得出手的时候出手，在不值得的时候闭嘴，甚至在它会添乱的时候直接扔掉。
Query、Cache、Drop 分别是什么意思？Query 是调用慢系统刷新指导，Cache 是继续沿用上一次的慢指导，Drop 是把当前慢指导屏蔽掉，避免错误信息继续影响快系统。三者合起来，才构成真正的“会判断”的门控。
为什么要定义等效区间和失效区间？因为它们把“什么时候该复用、什么时候该停用”从模糊直觉变成了可学习、可分析的对象。等效区间强调重复查询没收益，失效区间强调慢系统有时会害人，这两个概念正好支撑了门控策略的设计逻辑。
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数：★★★★☆
把快慢协同从“固定调度”推进到“帧级三动作门控”，思路不算玄，但抓得很准，尤其是 Drop 这个动作，让门控从“会省”变成“会判”。
实验合理度：★★★★☆
在 nuPlan 和 NAVSIM 两个不同设置上都验证了门控思想，还做了固定间隔、随机策略、消融和时延对比，比较完整，能看出收益不是偶然。
学术研究价值：★★★★☆
它把“何时调用大模型”这个问题拆成了可学习的资源决策问题，对自动驾驶和其他需要快慢协同的系统都有参考意义。
稳定性：★★★☆☆
方法比纯固定策略稳，但毕竟还是依赖门控学习质量；一旦分布变化大，门控是否还能准确识别失效区间，还得继续验证。
适应性以及泛化能力：★★★★☆
论文展示了跨架构迁移到 NAVSIM 的结果，说明门控思想有一定通用性；但不同平台的输入形式仍需重新适配。
硬件需求及成本：★★★★☆
门控本身用 RWKV 做得比较轻，能减少慢系统调用次数，整体更适合实际部署；不过慢系统本体若太重，成本仍然主要卡在它身上。
复现难度：★★★☆☆
思路清楚，但涉及闭环仿真、双系统搭建、RL 微调和多数据集验证，工程量不小；好在项目页给了视频和额外结果，门槛不至于离谱。
产品化成熟度：★★★☆☆
在受控自动驾驶规划链路里有不错的落地潜力，但要进产品，还得继续验证极端场景、长尾分布和系统集成稳定性。
可能的问题：门控学得再聪明，也还是依赖训练分布和闭环仿真；一旦场景迁移太猛，Query/Cache/Drop 的边界可能会变模糊。
主要参考文献
[1] Ang, S., Chen, Y., Haiyan, L., Mao, X., Bao, J., Xuliang, S., & Wang, Y. ASSCG: Just-Right Gating over Chattering for Fast–Slow LLM Planning in Autonomous Driving. arXiv, 2026.
[2] 项目页面与演示视频：https://williamxuanyu.github.io/asscg/
[3] 论文原文：https://arxiv.org/pdf/2606.25509v1.pdf
*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！
欢迎加入龙哥读论文粉丝群，
扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。
一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
自动驾驶、LLM、强化学习、机器人都能聊，别让论文只躺在收藏夹里吃灰～🚗🤖
