PlannerForge：当LLM学会了给自动驾驶找茬

先说一个场景。

你是一名自动驾驶算法工程师，早上九点打开电脑，第一件事是打开一个GUI地图编辑器，手动画一段慕尼黑市区的马路，画完之后再切换到另一个数据库工具，翻找有没有类似的危险场景可以复用。找到了，你又打开第三个脚本工具，手动改改车辆轨迹让场景更刁钻一点。改完之后，运行测试脚本，等结果跑出来，再打开Excel统计成功率和碰撞率。整个流程涉及四五个互不相通的软件，每一步都要你亲自搬砖。

这就是当前自动驾驶“场景测试”的真实状况：一条流水线,被拆成了好几个各自为战的孤岛。

**场景测试**：在虚拟环境里模拟各种交通状况（比如突然变道的卡车、闯红灯的行人），检验自动驾驶系统会不会闯祸的一种验证方法。因为真实世界里的危险场景太贵也太少见，所以行业普遍靠模拟器批量制造这些"边缘案例"。

TUM（慕尼黑工业大学）团队的这篇论文,做的事情说起来不复杂:把这条流水线上所有的孤岛,全部塞进一个用大语言模型驱动的聊天机器人里,让你打字聊天就能完成整套测试。这个系统叫PlannerForge。

场景测试为什么这么麻烦

行业里有一套经典的六阶段测试框架,来自德国Pegasus项目和后续的学术综述:场景来源、场景生成、场景数据库、场景选择、测试执行、结果评估。这六步说起来清楚，但现实中，每一步都是不同的软件工具在做,彼此之间几乎零配合。

生成场景靠人工画图或写脚本；从数据库里挑场景靠人工写筛选条件；想稍微改改某辆车的行为，往往根本没有现成工具支持，只能自己动手改配置文件；测试跑完了，规划器的参数是手动调的；不同规划器之间要对比，还得各自跑一遍再手动拼数据。整个过程像是雇了五个互不说话的助理，你得亲自当传话筒。

在这篇论文之前，已经有不少研究把大语言模型用到了自动驾驶测试里，但几乎都只盯着"场景生成"这一个环节。比如ChatScene、TTSG这些工作，专注于用自然语言生成CARLA模拟器里的危险场景；LLM-Attacker专门优化攻击者轨迹。这些工作各自解决了流水线上的一块拼图，但没有人把整条流水线串起来。这就是PlannerForge要填的空。

一个会聊天的路由器,是怎么让流水线活起来的

PlannerForge最核心的设计,是一个叫"模块路由器"（Module Router）的组件。

传统测试工具是死板的：生成场景后必须先选择,选择后必须再修改,修改后才能测试,测试后才能分析,顺序完全固定,你没法半路插一句"等等,我想先改改这辆车的行为"。

**模块路由器**：一个负责理解你说的话属于哪种操作意图的LLM组件，它会把你的自然语言请求分类成"修改场景""调参数""跑测试""看分析""随便问问"这五种动作之一，然后把具体指令转发给对应的功能模块去执行。

路由器的工作方式分两步。第一步，LLM先读懂你这句话到底想干什么，把它整理成一个结构化的JSON，里面写明"这是MODIFY类型"还有具体要改的参数是什么。第二步，一个叫"处理引擎"的东西拿着这个JSON，去调用对应的功能模块真正执行操作。

这就像餐厅里的服务员和后厨的关系。你对服务员说"这道菜少放点辣"，服务员不会自己跑去炒菜，他要先听懂你的意思（辣度调整，具体是这盘菜），然后把这个指令准确传给后厨。如果没有这个服务员环节，你得自己冲进厨房告诉厨师，而厨房的流程是死板的先炒后调味,你根本插不进去。路由器扮演的正是这个"翻译并转发"的角色，它让原本必须按顺序走的流水线，变成了你随时可以打断、随时可以跳转的对话。

论文测试发现，一个用正则表达式硬编码规则做的路由器，只能达到45.5%的准确率。而用LLM做同样的事，最好的模型能到99.7%。这个差距说明什么？说明人说话的方式太灵活了，"帮我把这辆车改凶一点"和"让20026号车开快点"表达的可能是同一个意图，但字面上完全不像，靠关键词匹配根本兜不住。

场景是怎么被"生造"出来的

PlannerForge生成新场景，走的是两阶段路子。

第一阶段是地图和交通合成。你说"慕尼黑一个十字路口，中等车流，重点看一辆转弯的卡车"，LLM会把这句话解析成一个结构化的意图：地点、道路类型、车流密度、车辆构成、模拟时长。这个边界框会去调用OpenStreetMap的Overpass接口，抓取真实的路网数据。

**OpenStreetMap**：一个开源的世界地图数据项目，任何人都能编辑，包含全球真实的道路、建筑等地理信息。

抓到路网之后，交给SUMO微观交通模拟器去填充车流，让车辆按照真实的跟车、变道规律动起来，再转换成CommonRoad格式的场景文件。

**SUMO**：一个开源的微观交通流模拟软件，能模拟每辆车的加减速、跟车、变道行为，常用于交通研究。CommonRoad是慕尼黑工大自己开发的自动驾驶场景描述格式，相当于场景文件的"通用语言"。

第二阶段是规划问题的合成：从生成好的场景里，选一辆车当"自车"（ego vehicle），再给它指定一个目标区域，一个完整的可测试场景就成型了。

这里有个值得说的设计：论文里明确把"LLM该管什么"和"LLM不该管什么"划得很清楚。LLM只负责把自然语言解析成结构化意图，剩下的地图抓取、格式转换、交通模拟，全部交给确定性的工具去做，LLM完全不碰。

为什么要这样切割？因为LLM会犯幻觉,如果让它直接生成路网拓扑或者车辆轨迹，很可能编出一个不存在的车道ID，或者一条物理上不可能的加速轨迹，这种错误一旦混进流水线，可能到最后一步才暴露，返工成本极高。这就像装修房子时，你可以让室内设计师（LLM）决定墙刷什么颜色、家具怎么摆，但绝对不能让他去做承重墙的结构计算，那部分必须交给有资质的工程师（确定性算法）用规范公式来算，出了事故设计师赔不起。把幻觉风险死死限制在"语言理解"这一层，后面的几何和物理计算全靠可验证的程序，是这套系统能跑得稳的关键。

在实验中，93个查询里91.5%的场景库能顺利执行，96%的城市、道路、车辆属性都精准命中了用户要求。相比一个叫Scenario Factory 2.0的规则式竞品，PlannerForge慢了近十倍（21.6秒对2.2秒），但换来的是200个查询里193个能成功跑完（对方只有144个），而且能针对城市、道路类型这些细节属性做精确控制，规则式工具根本没法理解这些自然语言里的微妙要求。

从数据库里“捞”场景，比关键词搜索精准多少

如果数据库里已经有现成的场景，何必重新生成？这就是选择模块要干的事。

选择模块的设计思路是五步走的漏斗式过滤。用户和LLM进行一场五轮对话，每一轮LLM都从你说的话里抽取一个结构化信息片段：地理位置、场景标签、道路网络类型、障碍物设置、速度范围。每问完一轮，候选场景池就被过滤缩小一次，像是不断收紧的筛子。

如果这五轮问下来筛出的候选集是空的，系统会退而求其次，用语义相似度搜索兜底。

**语义相似度搜索**：把用户的话和场景库里每条描述都转成向量（一串数字），比较向量之间的接近程度来找相似内容，而不是死板匹配关键词。

论文把这套系统和经典的BM25关键词搜索做了对比。BM25几乎不花钱不费时（不到0.01秒），但在"第一条结果就命中用户要求"这件事上，只能做到67.5%，而PlannerForge能做到92%。差距在哪？关键词搜索没法处理同义改写、地点的模糊指代，也理解不了隐含的数值范围要求，比如用户说"车速大概二十来公里"，关键词搜索根本不知道该匹配哪个区间，而LLM能把这种模糊表达转成一个具体的速度区间去匹配。

不过这套系统也有个明显的软肋：在五个待抽取的信息槽位里，"场景标签"这一项的准确率始终卡在64%到67%之间，远低于其他四项。原因不是漏抽了标签（漏抽率只有0.3%），而是LLM太爱"加戏"了，它会给场景硬贴上一些数据库里根本不存在的标签，比如"交通拥堵"这个标签被凭空捏造了139次，而实际数据库里没有一个场景带这个标签。这提醒我们，让LLM做信息抽取时，"宁缺毋滥"往往比"尽可能多说"更靠谱，多说的部分反而成了噪音。

改场景这件事，为什么必须绕道SUMO

场景修改模块解决的是一个很实际的问题：CommonRoad里的场景一旦生成，车辆轨迹就是写死的固定数据。如果你想让某辆车绕道、让某辆车变得更激进，直接编辑轨迹坐标，很容易改出一个物理上不可能存在的运动，比如瞬间从静止变成时速一百公里。

PlannerForge的解法是，把每一次编辑都先转换成SUMO的路网和路由文件格式，让LLM在这个格式上做修改，改完之后再转换回CommonRoad，这个"回炉"的过程会自动保证轨迹的运动学合理性。

这套系统支持四类编辑：轨迹重定向（让某辆车改走别的路）、行为预设切换（把某辆车的驾驶风格换成"激进型"或"谨慎型"）、车辆增减（往场景里加一辆卡车或删掉某辆车）、目标点调整（改变自车的行驶目标）。

对比一个叫From-Words-to-Collisions的同类LLM工具，差距非常悬殊。那个工具是直接生成坐标数值，结果大约70%的编辑在物理上根本不成立，相当于让一辆车瞬间穿墙而过。PlannerForge因为绕道SUMO再转回来，四类编辑的物理有效率全部保持在94%以上。

这就好比修改一份Word文档的排版，你可以直接在渲染出来的最终画面上用画图工具涂涂改改，改完之后这份文件已经不是一份能被Word正常打开的文档了，格式全乱了。而正确的做法是回到Word的编辑界面，用它自带的排版功能改，改完存盘，打开还是一份规规矩矩的文档。SUMO在这里扮演的正是那个"合规编辑器"的角色，绕过它直接改最终坐标看似省事,但产出的东西根本经不起下一步验证。

十种大模型的“月考”成绩单

论文对十种大模型（五个商业API、五个开源模型）在生成、选择、修改、路由、规划器测试、性能提升这六大任务上做了系统评测，一共跑了八万次调用，全程没有做任何针对性的微调。

结果显示，各任务的最高分数在0.88到1.00之间，其中生成任务0.957，路由任务0.997，规划器测试任务甚至有模型拿到满分1.00。

开源模型的表现出乎意料。参数量在20B到35B之间的开源模型，在三个任务上追平了商业API的水平。这个结果值得琢磨一下：不是说开源模型全面碾压商业模型，而是说在这些结构清晰、有明确输出格式约束的任务上，模型的"理解力天花板"其实没有想象中那么高，一旦任务本身足够规整，中等规模的开源模型也能摸到这个天花板。

论文还发现一个有意思的现象：给带"思考模式"的开源模型（比如Qwen3.6:35b的Think版本）额外叠加思维链提示，反而会拉低表现，还会增加延迟和token消耗。这说明外部强加的推理脚手架，可能会和模型自身内置的推理机制打架，就像给一个本来就会自己规划路线的司机硬塞一张导航图，反而让他分心走错路。

把六个模块串成一条完整流水线（从生成到数据库、选择、修改、测试、参数调优）后，用同样的200个种子查询测试，商业模型能保住83%的查询存活到最后一步，开源模型是78%。这个"漏损率"主要发生在选择和修改两个环节，因为这两步涉及最复杂的语义理解。

LLM给规划器"调参"，成绩单能变多好看

论文里有一组数据格外抓人眼球:用LLM去调整运动规划器的成本权重参数，在400个测试场景上，成功率从50.4%提升到70.2%，碰撞率从19.0%降到8.4%，而且全程没做任何专门的微调训练。

**成本权重**：运动规划器在做决策时，会给不同的驾驶目标（比如"离障碍物远一点""加速度小一点""贴近参考路径"）赋予一个权重数值，权重的组合直接决定了这辆虚拟车最终开出来是什么风格。手动调这些权重通常需要资深工程师反复试错。

用户可以直接说"配置得更安全一点，把和障碍物的距离权重设成0.4"，LLM就能把这句话翻译成一份符合格式规范的YAML配置文件，替换掉原来的默认参数。论文测试了gpt-5.4-mini这个模型，在一种进阶提示条件下，这项任务拿到了满分1.000，比裸提示条件下的0.675高出0.325。而对照组用的是一个死板的YAML编辑器，只能做到72.5%。

这组数字背后藏着一个更深的问题：为什么直接改配置文件的规则编辑器打不过LLM？因为像"开得安全一点"这种表达本身是模糊的，安全对应到具体哪几个参数、该往哪个方向调、调多少，需要一种语义层面的推断能力，规则编辑器只能处理你写清楚变量名和数值的指令，遇到模糊表达就束手无策。

这就像你告诉理财顾问"我想稳一点"，靠谱的顾问会理解你说的是要降低股票配比、增加债券比例，具体调整多少个百分点；而一个只会执行"把股票仓位设为30%"这类精确指令的自动交易程序，压根听不懂"稳一点"是什么意思。

写在后面

读完这篇论文，最触动我的不是某个具体的技术指标，而是那个关于"该让LLM管什么，不该让它管什么"的取舍。

论文里反复强调一个原则：LLM只处理语言到结构化输出的转换，几何计算、物理模拟这些确定性的活儿，一律交给传统算法。这不是一个讨巧的工程决定，而是一种对LLM能力边界的清醒认知，它知道大模型擅长什么，也知道大模型的幻觉在哪个环节最致命,于是把最脆弱的部分死死焊住，只让LLM在它真正擅长的自然语言理解上发挥。

另一个让我意外的细节是那个"场景标签"抽取失准的案例，139次编造出一个根本不存在的标签。这提醒我们，评估LLM系统的时候，不能只看"它做对了多少"，还得看"它凭空多做了什么"。过度自信有时候比彻底沉默更危险，一个说"我不知道"的模型至少不会误导你，一个信心满满编造答案的模型才是真正的隐患。

论文最后也坦白承认了限制：整套系统目前是开环运行的，也就是说其他交通参与者只按照预先录制好的轨迹走，不会对自车的实际动作做出反应。这在真实道路上显然是不成立的，真车会因为你的一个急刹车而跟着调整。这个"闭环"的缺口，恰恰是这类工作接下来最值得较劲的方向。

如果有一天，你的车能自己跟工程师说"我觉得这段路测试得不够狠，再给我加个突然变道的卡车"，那会是什么感觉？

Q&A

Q1：PlannerForge是什么？

A：PlannerForge是慕尼黑工业大学团队开发的一个用大语言模型驱动的自动驾驶场景测试框架，它把场景生成、选择、修改、执行测试、结果分析这些原本分散的环节全部整合进一个聊天机器人界面，用户打字聊天就能完成整套自动驾驶测试流程。

Q2：PlannerForge用的是什么大模型，效果怎么样？

A：论文测试了十种大模型，包括Qwen3.6、Deepseek、Gemini、GPT等商业和开源模型。结果显示各任务最高得分在0.88到1.00之间，20B到35B参数规模的开源模型在多个任务上能追平商业API的水平，且全程没有做任何针对性微调。

Q3：PlannerForge调整规划器参数能带来多大提升？

A：在400个测试场景上，用LLM调整规划器的成本权重参数后，成功率从50.4%提升到70.2%，碰撞率从19.0%降到8.4%，用户只需说出类似"配置得更安全一点"这样的自然语言指令即可完成调参。