← 返回 PaperDaily 视觉与图像

先锁模块再找代码：Apollo新方法把故障定位做细了

自动驾驶的故障定位，最烦的不是“系统报错”，而是“系统没报错但就是跑歪了”。这篇 HINT 直接把问题拆成两步：先锁模块，再找代码，思路很工程，也很实用。

龙哥读论文 阅读 5 查看原文
#自动驾驶 #Agent
先锁模块再找代码：Apollo新方法把故障定位做细了
🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！ 👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
自动驾驶的故障定位，最烦的不是“系统报错”，而是“系统没报错但就是跑歪了”。这篇 HINT 直接把问题拆成两步：先锁模块，再找代码，思路很工程，也很实用。


原论文信息如下：
论文标题:
Hierarchical Fault Localization for Autonomous Driving Systems with Hypothesis Validation and Intent Analysis 发表日期:
2026年07月 发表单位:
不详 原文链接:
https://arxiv.org/pdf/2607.12598v1.pdf
### 文章上半部分子标题： 引言
方法概述
问题背景及相关工作
第一阶段：LLM看“回放”，用“假设-验证”揪出闯祸模块
第二阶段：比对设计“想法”和代码“做法”，不一致就是Bug ### 文章下半部分子标题： 实验验证：77.8%的成功率，真实Bug也能精准命中
总结与局限：未来还需破解多模块连锁故障
龙迷三问
龙哥点评
主要参考文献

自动驾驶出了Bug，找代码“元凶”比大海捞针还难？

自动驾驶最麻烦的地方，不是“它会不会出错”，而是“它出错了还不吭声”。系统不一定崩，车也不一定撞，但行为已经悄悄跑偏：该超车时不超、该让行时硬冲、该停时还在往前蹭。对开发者来说，这种 Bug 才最折磨人，因为表面症状在系统层，真正的锅却可能藏在成千上万行代码里。
这篇论文提出的 HINT，全称是 Hierarchical Fault Localization for Autonomous Driving Systems with Hypothesis Validation and Intent Analysis，中文可以理解成“带假设验证和意图分析的自动驾驶分层故障定位”。它的核心思路很朴素，也很工程：先找嫌疑模块，再找嫌疑代码。别一上来就对着几十万行源码乱翻，先把案子缩小到一个模块，再把模块内部的“可疑片段”一层层扒出来。
封面
图1：系统总体框架。HINT把故障定位拆成两阶段：先用运行回放和场景证据锁定模块，再用设计意图和代码实现的差异继续下钻到具体函数或代码段。

两阶段“探案”：先锁定嫌疑模块，再精准定位代码行

这套方法最像什么？像老刑警办案。第一步不是冲进现场翻抽屉，而是先判断“案发点在哪个楼层”；第二步才是进房间找指纹、找脚印、找真正动手的人。自动驾驶系统的故障定位也是这个逻辑：系统级症状和代码级根因之间隔着一层复杂的工程迷雾，不分层处理，定位基本靠缘分。
论文把自动驾驶的运行过程看成一个模块化流水线：感知、预测、规划、控制等模块按场景动态执行。故障往往不是“程序直接报错”，而是“行为不对”。所以 HINT 先从测试回放、场景描述、地图信息、时间对齐日志里提取证据，判断哪个模块最像“闯祸的人”；再进入源码层，把设计文档里“应该怎么做”和代码里“实际上怎么做”放在一张桌上比对。只要两边的意图对不上，嫌疑就会迅速升高。
图2：自动驾驶系统架构
图2：自动驾驶系统架构。现代自动驾驶通常由多个解耦模块组成，模块之间通过中间件通信，执行路径还会随场景动态变化，这也是故障定位难度高的根源。
这里有个关键点要先说人话：HINT 不是拿大模型“瞎猜 Bug 在哪”，而是让大模型在证据约束下做推理。它会利用运行日志、车道和障碍物的鸟瞰图（BEV，Bird’s-Eye View，鸟瞰图）、以及用于判断违规区间的 STL（Signal Temporal Logic，信号时序逻辑）监视器，把“这次到底哪里违反了预期”先钉死，再让 LLM 去做模块级假设和验证。这样比纯文本式的自由发挥靠谱得多。

第一阶段：LLM看“回放”，用“假设-验证”揪出闯祸模块

第一阶段解决的是最难的一步：系统症状怎么映射到模块。自动驾驶日志很长，信息很杂，直接扔给模型，模型只会像看监控录像一样“看了个寂寞”。所以 HINT 先做场景抽象：把原始日志整理成时间对齐的执行轨迹，再从速度、距离等信号里用 STL 找出违规区间，最后把地图、轨迹和数值信号融合成一段可读的场景描述。
图4：场景抽象流水线
图4：场景抽象流水线。它把杂乱的运行记录变成“可推理”的证据包：时间对齐日志、违规区间、鸟瞰场景和自然语言场景描述，方便后续模块诊断。
然后才轮到“假设-验证”登场。HINT 会先根据失败症状生成一组粗粒度假设，比如问题更像感知偏差、预测错误、规划失配，还是控制执行异常。接着它不是直接拍脑袋选一个，而是给每个假设配一个验证技能（Skill）：该看哪些证据、如何检查一致性、怎样判断这个假设能不能解释当前故障。这个设计的妙处在于，每个嫌疑模块都用专门的证据来审，而不是用同一套笼统标准糊弄过去。
验证之后，系统还会做一次“责任判断”：这个异常到底是源头故障，还是下游被上游带歪了，或者只是顺手出现的伴生现象。这个区分特别重要。因为在自动驾驶里，某个模块“看起来不对”不等于它就是元凶，很多时候它只是替别人背锅。论文在这里的态度比较严谨，没有把“异常”直接等同于“故障”，而是加入了因果责任分析，尽量避免误伤。
图3：失败超车案例与代码修复示例
图3：一个“超车失败”的真实例子。表面上看是任务没完成，实际上问题链条很长：预测模块给出了错误的障碍物轨迹，规划模块因此变得过于保守，最后车就老老实实跟在前车后面不敢动了。
论文里这个例子很典型：真正的 Bug 并不在“车为什么没超车”这种表层问题上，而在预测模块内部一个过滤函数 FilterLaneSequences。它本来想限制附近车辆的候选轨迹，避免系统过于激进，结果条件写歪了，把一些高置信轨迹过滤掉了。后面的功能模块拿到的是“残缺候选集”，自然就做出了错误判断。说白了，前面一环写错，后面全体背锅，这就是自动驾驶系统最常见也最烦人的连锁故障。

第二阶段：比对设计“想法”和代码“做法”，不一致就是Bug

第二阶段开始进入源码层。前一阶段已经把嫌疑模块缩小了，接下来就不是“全城搜捕”，而是“进楼排查”。HINT 的核心动作是把某个任务的设计意图和实现意图放到同一个语义模板里对齐比较。论文把这个模板定义成四个字段：Goal、Guard、Safety、Assumption，分别对应目标、触发条件、安全约束和环境假设。
这一步很关键，因为代码 Bug 往往不是“写不出来”，而是“写出来但语义偏了”。设计文档说的是“车距足够近时要保守处理”，代码却可能在边界条件上写错，导致把本该保留的轨迹删掉。单看代码本身，语法没问题；单看文档，也像模像样。只有把两边放在一起，差异才会露馅。
图5：第二阶段双流意图分析
图5：第二阶段总览。左边是设计侧意图抽取，右边是代码侧意图抽取，中间是差异比较；如果差异足够大且证据可靠，就把嫌疑继续往函数级别收缩。
为了让两边真的能“对话”，HINT 还做了一个叫 Dynamic Execution Skeleton，DES（动态执行骨架） 的东西。名字听着像高端术语，实际干的事很接地气：先根据运行上下文把不相关的代码路径剪掉，只保留和当前故障场景有关的执行任务。这样做的好处是，源码再大也不用全展开，搜索空间不会爆炸。
在实现侧，HINT 不是简单抽函数调用树，而是构建一棵“语义树”：只保留真正影响任务语义的调用、判断和辅助逻辑。遇到不透明依赖，就继续下钻到定义处，直到当前任务的实现意图足够完整。这个过程本质上是在回答一个问题：这段代码到底想干嘛，以及它和设计文档里“应该干嘛”差了多远。
这里的亮点不在“比对”这个动作本身，而在“比对的对象”被统一了。很多传统定位工具只能告诉你“某个模块有异常”，却说不清它是逻辑错、边界错，还是依赖错。HINT 把设计意图和实现意图都拆成同一套字段，再按字段做一致性检查，最后把不一致程度映射回函数级别的可疑度。这样定位就从“猜模块”变成了“找语义偏差”，工程味道一下就上来了。

实验验证：77.8%的成功率，真实Bug也能精准命中

论文的实验主要基于 Apollo 和 Carla，覆盖了公开问题和注入故障，既看模块级诊断，也看代码级定位。这个设计比较合理，因为自动驾驶故障定位最怕“只在玩具样例上好看”，一到真实系统就失灵。作者显然知道这一点，所以把评测重点放在真实模块、真实执行记录和真实 Bug 上。
表1：基准数据集组成
表1：基准数据集组成。这里列出了不同故障场景、模块和数据来源的组合，用来支撑后续模块诊断与代码定位实验。
图6：模块诊断准确率对比
图6：模块诊断准确率对比。HINT 在模块级诊断上整体表现最强，说明第一阶段的“假设-验证”确实能把锅先甩对方向。
表2：代码级故障定位准确率
表2：代码级故障定位准确率。和现有方法相比，HINT 在代码级定位指标上也占优，说明第二阶段并不是“模块找对了，代码还得靠运气”。
最值得注意的结果，是端到端真实 Bug 上的 77.8% Class@5 准确率。Class@5 可以理解为：只要真正的故障代码排进前五名，就算命中。对于代码级定位来说，这个标准不算苛刻，但也绝不是“随便猜猜”。能在真实 Bug 上把真凶稳定排进前五，说明方法不是只会在论文图里表演，是真的有点实战能力。
表4：端到端故障定位性能
表4：端到端故障定位性能。这个表最能说明问题：HINT 不只是模块级诊断强，连从系统症状一路追到代码根因的完整链路也跑通了。
消融实验也很有信息量。论文在 Dreal 这个组件上做了分析，结果表明，如果去掉场景抽象、意图分析或者可靠性校准，性能都会明显掉。这个结论其实不意外，因为 HINT 的强项不是某一个“神奇模块”，而是三件事串起来：先把证据整理干净，再把意图抽象统一，最后用可靠性把噪声压下去。少一环，定位链条就会松。
表3：Dreal消融实验
表3：Dreal 消融实验。去掉关键组件后性能下滑，说明系统效果并不是靠单点堆料，而是靠两阶段链路的协同。
论文还测试了不同大模型骨干的鲁棒性。结果说明，HINT 的整体框架并不完全依赖某一个特定模型，只要底层模型具备足够的推理和抽取能力，框架就能维持较稳定的表现。这一点对工程落地很重要，因为真正的系统不会永远绑定某个单一模型，能换骨干、能降级、能迁移，才更像可部署方案。
表5：不同LLM骨干的鲁棒性
表5：不同大模型骨干下的鲁棒性。说明 HINT 不是“押宝某个模型”，而是把诊断流程设计成了可替换、可迁移的框架。

总结与局限：未来还需破解多模块连锁故障

HINT 的价值，不在于“又用了一个大模型”，而在于它把自动驾驶故障定位这件事拆成了工程上更合理的两步：先用运行证据把责任范围缩小，再用设计意图和实现意图的差异去找具体代码。这个思路很适合模块化、文档化、日志齐全的复杂系统，尤其适合那种不报错但行为错的场景。
但它也不是万能药。论文自己其实已经暗示了边界：当前重点放在碰撞、交通规则违规和任务未完成这几类常见场景，且方法依赖较完整的运行记录、场景重建、设计文档和源码索引。如果文档缺失严重、模块耦合特别乱，或者故障是多个模块连续失配造成的，定位难度还会继续上升。换句话说，HINT 把“单点故障”的路径打通了，但“连环故障”的案子还要继续攻。
不过从行业角度看，这已经很有启发了。未来自动驾驶系统越复杂，调试越不能只靠人肉翻日志。真正有价值的方向，不是让模型替代工程师，而是让模型把“证据整理、假设筛选、语义对齐”这些苦活脏活先做掉。这样工程师才能把时间花在真正有判断价值的地方，而不是在海量日志里当人形搜索引擎。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决什么问题？解决的是自动驾驶系统出了故障以后，怎么从“车表现不对”一路追到“具体哪段代码写错了”。它不是只做模块级报警，而是把故障定位推进到代码级根因。

STL、BEV 和 DES 分别是什么？STL 是信号时序逻辑，用来精确找出违规发生的时间段；BEV 是鸟瞰图，用来把车辆和地图关系画出来；DES 是动态执行骨架，用来根据场景把相关代码路径筛出来，避免源码搜索空间爆炸。

为什么它能比传统方法更准？因为它不是只看异常现象，而是把运行证据、设计文档和源码实现放在同一条推理链里。第一阶段负责把模块猜对，第二阶段负责把代码缩小到具体函数或片段，两步都围绕证据和语义差异展开，误判会少很多。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

把“模块级诊断”和“代码级定位”串成一个分层框架，思路不花哨，但很对症，尤其适合自动驾驶这种复杂模块系统。

实验合理度：★★★★☆

用了 Apollo、Carla、公开问题和注入故障，评价链条比较完整；如果再覆盖更多跨模块连锁故障，信服力还会更强。

学术研究价值：★★★★☆

对自动驾驶调试、复杂系统诊断和 LLM 证据约束推理都有启发，研究价值比较实在，不是那种只会堆概念的工作。

稳定性：★★★☆☆

流程设计比纯 LLM 猜测稳，但仍依赖日志、文档和场景重建质量，环境一乱就会掉链子。

适应性以及泛化能力：★★★☆☆

对模块化、文档齐全的系统更友好，迁移到其他系统有希望，但前提是同样能拿到足够的运行证据和设计材料。

硬件需求及成本：★★★☆☆

训练成本不突出，但推理链条里有多轮 LLM 调用、检索和代码分析，算不上轻量级工具。

复现难度：★★★☆☆

框架和流程说得比较清楚，但要复现真实自动驾驶场景、日志、地图和源码环境，门槛还是不低。

产品化成熟度：★★★☆☆

适合辅助调试和离线诊断，离“开箱即用的自动故障定位产品”还有距离，尤其是面对复杂连锁故障时。

可能的问题：对文档、日志和场景证据依赖较强，遇到多模块级联故障或证据缺失时，定位精度可能明显下降。


主要参考文献

[1] Changwen Li, Rui Zheng, Yi Ji, Rongjie Yan. Hierarchical Fault Localization for Autonomous Driving Systems with Hypothesis Validation and Intent Analysis. arXiv:2607.12598v1, 2026.
[2] Apollo 开源自动驾驶平台与 Carla 仿真平台，见论文实验部分说明。

end
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
自动驾驶、机器人、大模型、AI医疗、AI金融都能聊，Bug 定位、论文拆解、开源代码、招博信息也都在群里。
wechat_helper dianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。