尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

世界模型与LLM协同的自动驾驶决策系统实践

世界模型与LLM协同的自动驾驶决策系统实践 这两年自动驾驶算法圈子里有两个词几乎在每个技术分享里都会被反复提到一个是世界模型World Model另一个是大语言模型LLM。我最近在手头的自动驾驶算法项目里把这两者真正放到了一起做让世界模型负责“预演未来”让大语言模型负责“读懂场景、判断意图”最后让两者协同输出驾驶决策。这篇文章就是把这套思路从论文变成可跑通方案的全过程复盘适合正在做感知决策系统、或者想在自动驾驶里引入多模态大模型的工程师参考。先说一个基本判断世界模型和大语言模型单拉出来都不新鲜世界模型在强化学习里被研究了很多年大语言模型更是被聊透了大半但把两者结合到自动驾驶算法里现在还没有标准答案。大家都还在试验阶段所以这篇文章不是给你一个“绝对正确”的方案而是给你一条已经趟过坑的路你可以在这个基础上按自己的场景去调。我会从“为什么结合”讲起然后给出一套可参考的系统架构再说数据、训练、评测怎么做最后把踩过的坑和处理方法整理成速查表。整个过程我会尽量贴近实际开发少讲虚无缥缈的概念多讲能落地的细节。1. 为什么把世界模型和LLM放在一起做自动驾驶1.1 世界模型到底在做什么世界模型这个名字听起来很玄但其实核心就一句话让模型在内部建一个环境的动态表征然后预测未来。在自动驾驶场景里世界模型的输入是过去几帧的感知结果比如相机画面、激光雷达点云、高精地图信息输出是未来几秒内可能出现的场景状态。这个“状态”可以有很多种形式。早期的工作像Dreamer是在隐空间里预测状态向量和奖励值后来像GAIA-1这类模型直接在图像或特征空间里预测未来的视觉帧。无论形式怎么变本质上都是在拟合环境的转移概率。世界模型能帮自动驾驶做的不是“看见”现在而是“想象”接下来几秒钟会发生什么。这和传统预测模块有什么区别传统预测通常是独立预测每个交通参与者的轨迹而世界模型是对整个场景做联合建模把道路结构、其他车、行人、自车运动放到同一个表征空间里推演。联合预测的优势在于一个场景里所有元素是相互影响的前车打方向灯往往意味着旁边车道会有车插入这种事用独立轨迹预测很难捕捉但世界模型可以通过全场景推演天然建模这种关联。1.2 大语言模型给自动驾驶补上什么大语言模型在自动驾驶里的作用不是接管方向盘而是补上传统感知-预测-规划框架里缺失的“常识”和“语义理解”。我举个例子在一段施工路段路边的锥桶摆出了一个向左绕行的引导形状纯视觉感知模块看到的就是一堆锥桶把它当成普通静态障碍物。这时候规划模块会怎么做大概率会认为车道被占用然后减速停车等清理。但人开车时会立刻明白这是在引导变道应该跟着锥桶的方向向左绕行。这种从场景语义到驾驶意图的推理大语言模型天生擅长因为它训练数据里包含了大量人类驾驶经验、交规知识、对异常场景的理解。另一个作用是“可解释性”。自动驾驶最难的不是做对一个动作而是让安全员、监管方、乘客理解为什么这么做。LLM可以把决策过程转成自然语言先描述场景、再说明风险点、最后给出动作理由。这在路测和事故复盘里价值极高很多团队现在已经把决策解释作为大模型上车的首要出口。另外多模态版本的大语言模型也就是视觉大语言模型VLM可以直接把图像输入和文本输入拼在一起这在自动驾驶里最实用的点是你不需要单独训练一个感知头去识别所有东西而是让VL M用语言描述场景里的关键元素再在后端解析成结构化指令。这对长尾场景特别友好传统的目标检测只能识别训练集中出现过的类别但语言描述是开放式的。1.3 世界模型与大模型的区别与分工很多人会把世界模型和大语言模型混为一谈尤其从技术形态上看两者都是序列预测。世界模型预测的是环境状态序列大语言模型预测的是词元序列。但本质上它们建模的对象完全不同。世界模型要拟合的是物理世界动态得理解“车有惯性”“碰撞会发生”“红灯亮了车要停”这类物理规则它是在低层感知信号上做学习的。大语言模型拟合的是人类知识的分布更关注语义、逻辑、意图、常识这些抽象层的东西。结合到自动驾驶算法里我的分工习惯是世界模型做感知和预测侧的密集推理负责把场景动态推演出来给后续决策一个“未来状态”的基础大语言模型做行为侧的稀疏推理负责理解场景语义、识别异常情况、规划高层的驾驶意图再把这个意图交还给下游的控制模块去执行。世界模型处理的是连续空间的“快思考”大语言模型处理的是离散语义的“慢思考”两者互补而不是替代。2. 整体方案设计与技术选型2.1 一套可落地参考的系统架构先给出一套我实际在用的系统架构不一定是最优解但每个模块都有明确的存在理由。整体分五层第一层是感知层负责把摄像头、激光雷达、毫米波雷达的原始数据转换成统一的场景表示。这里可以选择端到端的BEVBird‘s Eye View感知网络也可以选择传统的检测-跟踪管线。我的建议是尽量输出带有时间戳和轨迹ID的结构化结果方便后面做对齐。第二层是场景token化层这是世界模型和LLM能否协同的关键。感知层输出的数据格式千差万别有的是框有的是栅格地图有的是稠密点云需要统一编码成离散的token序列世界模型和LLM才能共用一套接口。第三层是世界模型层。它拿到历史场景token序列后通过自回归的方式预测未来的场景token。这里预测的不只是自车的未来轨迹而是整个场景里所有相关元素的未来状态分布。第四层是LLM推理层。世界模型推演出的未来场景经过一个投影模块变成LLM可以读入的embedding。LLM同时读取感知层的语义标签和人类设定的驾驶任务输出高层驾驶意图、决策解释以及异常情况的处理方式。第五层是决策执行层把LLM输出的意图和世界模型的预测结果做加权融合结合安全约束生成具体的轨迹交给下游控制模块。这个架构的关键点是第三层和第四层之间的接口我会在后面实操章节展开。2.2 世界模型选型从GAIA-1到UniSim说到世界模型的选型现在公开可参考的模型已经不少3D世界模型survey也越来越多。我自己调研过的主要分两类一类是面向视觉场景重建的比如NVIDIA的UniSim能在仿真环境里渲染高保真的场景帧优点是感官效果好缺点是计算量大很难实车部署另一类是面向决策推演的隐空间模型比如Dreamer系列、IRL还有自动驾驶领域很有名的GAIA-1直接在特征空间做预测不重建图像速度快更适合和下游决策模块对接。我的实际选择是偏向隐空间方向。理由很简单自动驾驶的决策系统不关心画面像素多好看关心的是未来障碍物位置、自车可行区域、碰撞概率这些任务相关的信息。在隐空间里预测既能满足决策需求又能控制算力开销。具体网络结构上我采用的是“编码器-时序Transformer-解码器”的结构。编码器把一帧场景编码成一组token时序Transformer负责捕捉多帧之间的关系并预测未来token解码器把未来token还原成占用栅格、障碍物轨迹等任务特征。这里有个细节时序Transformer的注意力窗口只覆盖历史5帧到未来10帧大概0.5秒历史加1秒未来再长的预测置信度掉得很快意义不大。2.3 大模型选型端侧小模型还是云端大模型大语言模型选型是个很现实的问题直接决定项目的算力成本和响应延迟。在自动驾驶场景里LLM一般有两个部署位置端侧和云端。端侧方案比如在域控制器里本地部署一个视觉大语言模型优势是低延迟、不依赖网络、数据不出车适合做实时决策和预警。但端侧有算力限制一般只能跑参数量较小的模型比如4B~8B的量化版。这类小模型的推理质量够不够用取决于你的任务复杂度如果是简单的场景描述和意图分类基本够用如果要做多轮复杂推理会明显吃力。云端方案不受算力限制可以直接上几十B甚至上百B参数的大模型也可以直接用商业API。这个方向适合做数据挖掘、场景标注、难例分析这类离线任务不适合实时决策因为网络延迟和通信稳定性很难保证。我的项目是两条腿走路离线用云端大模型做场景库的自动标注和难例挖掘在线用端侧8B量化模型做实时的意图推理。还有一个经验是不要追求用云端大模型做在线决策哪怕延迟再低在隧道、地库等无信号场景都会失速端侧兜底是必须的。2.4 两种模型的输入输出接口设计这是整个系统设计里最容易被忽视却最容易出问题的环节。世界模型和LLM本来是两种完全不同的技术栈如果不设计好接口最后一定会变成“两套系统硬拼”效果还不如单独用任何一个。我采用的接口设计思路是“语义对齐”。具体来说把感知层的结构化结果和世界模型的预测结果都映射到自然语言描述空间。比如车道线、限速牌、前车位置关系、可能碰撞风险这些信息统一转成类似“前方30米有车切入自车车道概率0.7”这样的语义描述再作为prompt的一部分输入给LLM。这里的关键点是转成自然语言的过程必须可靠不能丢关键信息。同时LLM输出的驾驶意图也会转成结构化的操作指令比如“保持车道”“减速让行”“向左变道”再和世界模型的轨迹预测结果做融合。这样两边在语义层面对齐就不需要强行让两种模型共享一个embedding空间工程难度会低很多。3. 实操过程数据、训练与评测3.1 数据准备公开数据集和闭环数据两手抓自动驾驶模型最吃数据世界模型和LLM结合的项目尤其如此。纯靠公开数据集跑通demo可以但要做闭环验证远远不够。公开数据集方面nuScenes是首选它有完整的传感器数据和驾驶行为标注适合训练场景token化网络和世界模型的基础预测能力。Waymo Open Dataset的数据量更大路况更多样可以作为补充训练集。如果要做地图相关的推理可以加OpenDrive仿真地图做过采样。但真正让模型“学会处理长尾场景”的是闭环数据。我一般用CARLA或者类似仿真器搭建城市道路、高速、施工区、恶劣天气四类场景在仿真环境里让带规则决策的自动驾驶系统随机跑把系统出错或安全员介入的场景全部采集下来。这些“被打断的轨迹”是世界模型和LLM最好的训练材料因为它们的输出都是典型的困难样本。数据规模上我给一个参考场景token化网络需要至少10万帧以上的数据才稳定世界模型预训练建议50万到100万帧LLM微调阶段用到的多模态指令数据不需要太多1万到3万条高质量指令就够了效果远好于堆量。3.2 场景token化让世界模型和LLM说同一种语言这是整个项目里代码量不大但坑最多的一步。我一开始直接用ResNet把图像压成feature map再拉平成token喂给Transformer结果训练时loss下降得挺好但可视化检查时发现token里几乎没有保留“前车在第几车道、距离多远”这类细粒度信息。后来改成“实例级token化”感知模块输出的每个交通参与者车、人、骑行物单独编码成一个tokentoken的内容包含位置、速度、朝向、类别、尺寸和历史轨迹的压缩向量静态元素比如车道线、路沿、交通标志单独一组静态token。动态token和静态token拼在一起形成描述一帧场景的完整token序列。这么做的好处是token的语义明确后续和LLM的自然语言描述对齐非常顺畅。坏处是依赖前置感知模块的质量感知漏检了世界模型再怎么推演也救不回来。实操时要注意感知模块的召回率宁可多出误检不要太低的召回因为误检还可以靠后续的轨迹一致性过滤漏检就彻底信息缺失了。3.3 训练策略两阶段和课程学习世界模型和LLM结合的系统不建议端到端一把梭式训练。参数量太大、数据需求太复杂、梯度也不稳定大概率训不出来。我的做法是分阶段训练每阶段锁定一部分参数。第一阶段训练场景token化网络。只用感知-重建任务目标是让token序列能足够好地恢复原始场景状态比如从token里能重建出正确的障碍物位置和类别。第二阶段训练世界模型。输入历史token序列预测未来token序列损失函数用未来场景状态和真实数据的交叉熵加误差加权。这里的预测时域我设了10帧每帧100毫秒也就是预测未来1秒。有朋友问为什么不做更长时间预测我的经验是超过1秒后预测误差快速变大强行延长反而会误导LLM的决策不如把1秒内的预测做准。第三阶段用视觉大语言模型的底子先做领域适配用自动驾驶场景的图文描述数据微调。这个阶段不追求让LLM做决策只让它学会“描述和总结场景”。第四阶段把世界模型的预测结果以prompt的形式引入LLM用少量人工标注的驾驶决策数据做端到端微调让LLM学会结合未来预测做决策。微调用LoRA就行全参数微调容易灾难性遗忘。课程学习也很有用。我先在简单的高速场景上训练然后逐步切换到城市道路、施工区、恶劣天气等复杂场景。顺序乱了模型很容易被困难样本带偏。3.4 评测指标开环指标与闭环指标自动驾驶算法的评测是个老大难问题世界模型加LLM的组合让评测更复杂。我只说我自己在用的指标分成开环和闭环两套。开环指标本质是离线评测拿真实路测数据回放看模型的输出和真实驾驶员操作有多像。常用的有轨迹误差ADE/FDE、碰撞率、驾驶得分Drive Score、决策一致性LLM输出的意图和真实操作意图的一致率。开环指标的最大问题是“一票否决”式误差累计一个错误决策后面全错所以参考时只关注前端误差重点看决策一致率。闭环指标是把模型放进仿真环境里让模型真的去开车统计成功率、事故率、接管次数、平均行驶距离等。这是最接近实际效果的评测方式。我用CARLA的闭环评测接口设置固定路线集让模型连续跑10条路线统计平均无接管里程。只有当无接管里程超过某一阈值我才会考虑把模型放到真车上做进一步验证。还有一个我特别看重的指标决策可解释性评分。让LLM每个决策都输出理由再用另一个评分模型判断理由和场景描述是否吻合。没有这个指标LLM的幻觉问题会很难发现。4. 关键实现细节从推演到决策4.1 世界模型输出如何进入LLM世界模型预测出的未来场景token怎么喂给LLM是让很多人卡壳的地方。公开资料里提到的做法大多是直接把隐向量投影成LLM的embedding但这样做有个问题LLM的训练分布和世界模型的隐向量分布差得太远融合效果很不稳定。我采用的方案是多了一步“翻译”。世界模型的未来场景token先经过一个轻量的状态解码器转成结构化的自然语言描述。例如前方8米左侧车道有一辆白色轿车速度约10m/s正在向自车车道靠拢自车当前车速15m/s若保持当前速度预计1.5秒后两车横向距离将小于0.5米存在擦碰风险。这段描述接着被加入LLM的prompt。这相当于在世界模型和LLM之间加了一个“语义接口层”。代价是会丢失一部分连续空间的精度但换来的是稳定性和可解释性大幅提升。考虑到自动驾驶决策本身是个高层语义行为我认为这个代价完全可接受。如果任务允许也可以同时把世界模型的隐向量作为一个附加模块拼到LLM输入里让LLM自己学会融合两种信息。但试验下来效果不稳定需要更多的调参成本。在工程优先的项目里我建议先走语义接口方案。4.2 LLM如何输出安全可控的驾驶决策让LLM直接输出方向盘转角或加速度是最危险的选择语言模型对连续数值的回归天然不擅长。我的做法是让LLM只输出离散的意图再交给下游的轨迹规划器生成具体的路径。意图集合设计也很关键不是随便给几个词就行。我定义了一套九宫格意图集保持当前车速、加速、减速、轻微制动、紧急制动、向左变道、向右变道、向左避让、向右避让。只用这几个固定选项不开放自由生成。这样做的原因是可以严格约束LLM的输出空间避免模型语出惊人同时对下游规划器也更友好。提示词模板我经过了多轮迭代最终的稳定版本长这样你是自动驾驶系统的行为决策模块。请根据当前场景描述和未来推演结果从以下动作列表中选择一个最合适的动作[列表]。输出格式为JSON{action: ..., reason: ...}。注意1. 安全第一优先避免碰撞2. 遵循交通规则3. 在确保安全前提下尽量保持通行效率4. 如果场景存在不确定性选择保守动作。这里的“存在不确定性选择保守动作”非常关键不加这句LLM经常会在复杂场景里硬着头皮做一个激进决策。加了这个约束后很多模糊场景的输出会自动偏向减速或制动这其实和人类驾驶员的心理机制很像。4.3 简化实现框架伪代码级别我把整体的推理流程用伪代码的方式整理一下方便你在自己的代码库里对照。# 伪代码世界模型 LLM 推理主流程 def run_step(sensor_data, history_tokens, ego_state): # Step 1: 感知编码得到当前场景 token current_tokens perception_encoder(sensor_data) # Step 2: 世界模型预测未来 token future_tokens world_model.predict( history_tokenshistory_tokens[-5:], current_tokenscurrent_tokens, horizon10 # 预测未来1秒10帧 ) # Step 3: 语义接口层把未来 token 翻译成自然语言 scene_description semantic_translator( current_tokenscurrent_tokens, future_tokensfuture_tokens, ego_stateego_state ) # Step 4: 构造 LLM prompt并推理 prompt build_prompt(scene_description, ego_state, tasksafe_navigation) llm_output llm_query(prompt, modelqwen-vl-8b-quantized) # Step 5: 解析意图保证输出合法 action, reason parse_llm_output(llm_output, allowed_actions) # Step 6: 安全校验 轨迹生成 if safety_check(action, future_tokens, ego_state): traj trajectory_planner(action, ego_state) return traj, reason else: # 安全校验不通过降级为保守动作 fallback_traj trajectory_planner(brake, ego_state) return fallback_traj, safety_filter_triggered这段伪代码里最容易被忽略的是最后的安全校验。LLM输出了意图并不代表可以直接执行尤其是加了模型量化、推理加速之后错误输出的概率会上升。一个独立的、可解释的安全过滤器是必须的它不需要智能只需要死守规则不能碰撞、不能压压实线、不能超出车辆动力学约束。5. 踩坑实录与常见问题排查5.1 时空对齐问题我一开始做世界模型和LLM融合时效果怎么调都不对后来排查发现是时间戳没对齐。感知模块输出的是100毫秒一帧世界模型预测的是未来1秒LLM推理又需要200多毫秒等所有结果都算完真实世界已经往前走了好几帧。解决方案是给系统的每个模块都打上统一的时间戳并且用外推对齐LLM输出决策的时刻世界模型的预测结果也要同步外推到那个时刻。印象最深的一次前车明明已经在减速了但因为LLM处理太慢决策出来时用的还是1秒前的场景描述差点在仿真里去做了个变道超车。后来我加了一个“决策时效性校验”如果从感知时刻到决策输出的总延迟超过500毫秒强制丢弃这次决策按保守动作处理。5.2 幻觉问题与安全兜底LLM的幻觉在自动驾驶里是个致命问题。有次在仿真里场景明明是一辆静止的故障车LLM却写理由说“前方车辆正在减速靠边可以正常通行”。如果这个理由被直接采纳后果不敢想。针对幻觉我做了几层防护。第一层是把视觉信息换成结构化描述不指望LLM真的看懂图像第二层是在提示词里加入“如果不确定必须选择减速”第三层是加一个专门的场景一致性校验模块用另一个轻量模型判断LLM的理由和结构化场景描述是否有矛盾。这三层叠下来幻觉出现的概率从早期测试的20%以上降到了约2%。说实话2%还是偏高但配合安全过滤器实际决策已经不会把幻觉当依据LLM的作用更多是提供候选意图和解释最终执行以安全校验为准。5.3 算力瓶颈与工程优化世界模型加视觉大语言模型端侧算力压力极大。我在Jetson Orin平台上实测纯CPU推理8B量化模型一次推理耗时接近800毫秒完全不可用。后来把模型量化到INT4并用TensorRT加速推理时间压到250毫秒左右才算勉强满足低速场景的实时性。还有一个经验是尽量让LLM不要每帧都推理。我设置了一个“事件触发机制”当场景语义稳定时沿用上一次的意图只有当世界模型检测到新的风险事件、车道结构变化、或者自车状态突变时才唤起LLM重新推理。这样平均决策延迟大幅下降实际LLM推理频率从10Hz降到不到1Hz算力压力小了很多。5.4 常见问题速查表问题现象可能原因处理方法世界模型预测未来帧模糊预测时域过长缩短到10帧以内加预测误差权重LLM输出动作不在意图集内提示词约束不足强制JSON输出格式非集内动作触发重试或保守动作场景描述和实际不符感知漏检或token化丢失信息提高感知召回率检查token解码可视化决策延迟过高LLM过于频繁调用加入事件触发机制降低推理频率幻觉理由出现模型过度自信增加场景一致性校验模块端侧帧率不达标模型量化不足或计算图未优化换INT4量化用TensorRT加速闭环测试总被接管决策过于激进在提示词中加强安全约束下调最大车速6. 最后再分享一点我的个人体会项目做到后期我最大的感受是世界模型和大语言模型的结合真正的难点不在模型本身而在接口设计和工程兜底。模型的能力边界就摆在那怎么把两种能力缝成一个可靠的决策闭环才是工程师每天要啃的硬骨头。我强烈建议你从“语义接口”这条路入手先把世界模型的预测结果翻译成自然语言再让LLM做意图推理最后一定要加安全过滤器做兜底。这套方案不需要你一开始就搞很复杂的跨模态对齐每一步都有现成工具可用适合跑通第一个可运行的版本。等你的数据多了、问题清晰了再考虑做更深的表征融合。另外有一个小技巧想分享给你调试这种多模型协同系统时一定要把中间结果可视化出来尤其是世界模型的预测结果翻译成的文本以及LLM输出的原始JSON。很多问题光看指标发现不了一看中间文本就立刻明白了。我现在每个环节都保留了日志和可视化工具排查问题的效率至少提高了一倍。这条路还没走完目前我也只是在仿真场景和特定数据上验证了可行性。但方向是明确的让模型在连续空间中“想象”未来让语言在语义空间中“理解”意图两者配合能解决很多单一模型解决不了的问题。希望这篇复盘能给你一些参考少踩我踩过的坑。
返回列表