AdaDrive：LLM与实时控制融合的快慢双路自动驾驶决策框架-北京尧图网络

做自动驾驶或机器人决策系统时最折磨人的往往不是某一算法不够准而是“慢速的聪明决策”和“快速的稳定执行”之间那条缝。之前我们组内部讨论过一个方向把 LLM 接入闭环让它处理各种开放、非结构化的长尾场景从而提升整体闭环性能。第一次想简单了直接把 LLM 的输出当作主控制闭环的唯一决策源结果离线评测指标确实好看——绕障更果断、切弯更丝滑但线上完全跑不住推理一来一回动辄几百毫秒控制周期被拖到两位数毫秒甚至更低车辆在动态环境下基本是在“开盲盒”。AdaDrive 就是在那个阶段沉淀下来的一套 Slow–Fast 协作框架。它不是让 LLM 接管整条控制链路而是用一路时刻在线、高频运行的 Fast 路径保证实时效率再把 LLM 当作 Slow 路径按照风险与不确定性按需介入、按量融合最终兼顾闭环性能与实时效率。整篇文章想讲清楚的就两条主线什么时候该请 LLM 出场以及出场时它的意见到底占多大分量。1. 整体设计与思路拆解1.1 为什么不是“端到端 LLM 规划”而是快慢双路先算一笔账。常规闭环控制至少要跑到 30Hz高动态场景甚至需要 50Hz 以上单次控制周期预算只有 20 到 33ms。而一个正经大模型的单次推理延迟在量化部署后通常也要 300ms 起步复杂 prompt 或长上下文状态下突破一秒也很正常。如果让 LLM 每拍都参与决策控制链路从“毫秒级”变成“百毫秒级”即便模型本身决策正确执行器跟随不上系统也会在做闭环性能评估时出现严重的跟踪误差。更关键的是很多驾驶场景根本不需要“深思熟虑”。直线跟车、稳定巡航、标准绕障这些可以通过成熟的轻量模型或状态机完成。真正的难点集中在少数长尾场景无保护左转、施工区临时改道、前方物体语义不明、多车博弈意图模糊。如果让一套简单策略去硬扛这些场景闭环性能一定上不去但让慢速推理介入所有场景实时效率又会被拖垮。所以 AdaDrive 的底层逻辑不是“谁比谁强”而是“按难度分配频率”。Fast 路径是常驻执行体负责绝大多数常规工况保证基本实时效率Slow 路径只处理少数“低置信度高风险”的决策窗口为闭环性能兜底。两条路径之间不是互斥抢权而是通过一个调度层和融合层共同产生最终 actuator 指令。1.2 “按需介入”的实质控制触发面而不是无脑召唤很多人一听到“让 LLM 介入”第一反应是把模型挂在主流程里随时调用。这个问题在真实系统里非常致命不只是延迟还有计算资源占用、调用成本、以及模型误判带来的连锁风险。AdaDrive 里对“介入”的定义很克制它必须满足以下任何一个条件才会派发请求快速路径对当前局部规划结果的自查置信度掉到阈值以下说明常规策略已经“看不懂”这个场景。场景级风险评估模块拉出告警比如碰撞时间低于安全边界或者预测轨迹分布出现多峰分裂。快速路径给出的迭代控制量发生高频振荡系统怀疑自己陷入了某种局部循环。满足条件之后请求还会过一道“冷却闸”同一类场景触发后至少要维持一段时间不能因为置信度在阈值附近抖动就反复唤醒慢速路径。这个设计背后是一个很朴素的工程观点LLM 的慢是客观存在的我们无法消除它但可以用触发机制让它的慢不被放大成系统的慢。按需介入的本质是把“LLM 永远在线”改成“LLM 只在状态空间真正复杂时被拉起来”。1.3 “按量融合”的本质用权重替代开关慢速介入之后下一个问题是它的推理结果怎么用最原始的方法是二值切换——LLM 给一版规划Fast 路径让位。这种做法在闭环里特别容易翻车因为模型输出天然具有非平滑性上一帧轨迹和下一帧轨迹可能相差很大直接切换会让控制量出现阶跃车辆姿态发生突变乘员体感极差极端情况下还会诱发执行器震荡。AdaDrive 的处理方式是“按量融合”最终控制量取 Fast 路径输出和 Slow 路径输出的加权和权重系数随场景实时变化。低风险场景下LLM 意见占比可能只有 0.1 甚至更低系统仍然以 Fast 路径的稳定输出为主高风险场景下慢速路径的占比可以上升到 0.7 以上让模型的深度推理在关键时刻真正主导决策。这样既利用了 LLM 在复杂场景下的语义理解和规划能力又保留了一条平滑衔接的退路。本质上我们是在决策输出层做了一个连续的软切换而不是让模型“接管”或者“交出”全部控制权。2. 核心模块拆解与原理补充2.1 Fast 路径高频运行的“常驻执行体”Fast 路径承担的是最基础、最高频的闭环职责。它接收感知模块输出的目标级信息经过轻量融合后生成局部规划结果再交给底层控制模块执行。在我的经验里很多人会把 Fast 路径简单理解成“备用方案”觉得系统都上 LLM 了Fast 路径随便拿一组规则凑合就行。这是大忌。Fast 路径的设计越扎实慢速路径的触发越精准融合效果也越好。举个例子如果 Fast 路径的置信度没有合理校准它在普通场景下频繁自评过低会迫使 LLM 介入大量正常工况反过来如果它在高风险场景下自评过高又会错过关键介入时机。所以我们在 AdaDrive 里宁可把 Fast 路径做得“保守且完整”——覆盖车道保持、跟车、常规绕障、路口直行等基础功能同时输出一个实时置信度分数作为后续调度的核心信号。Fast 路径的具体实现不限定某种算法。规则状态机、轻量决策网络、或者经过蒸馏的小模型都可以关键是必须满足高频运行条件。我们内部实测下来这一路从状态输入到控制输出单周期开销控制在 3ms 以内运行频率稳定在 30Hz 以上。快速、稳定、可量化这三条是它存在的全部理由。2.2 Slow 路径把 LLM 当“规划顾问”而不是执行器Slow 路径的存在价值不是替代 Fast 路径而是解决 Fast 路径“看不懂”的那部分场景。所以它的输入不能是原始传感器数据——点云、图像直接喂给大模型既浪费上下文窗口也会引入大量与决策无关的冗余信息。我们实际采用的方式是让感知模块先做一次结构化压缩输出一张“场景语义摘要”当前自车位置、速度、航向角周边目标的类型、相对位置、运动趋势被遮挡区域和不确定性标记当前 Fast 路径方案的置信度与失败原因。LLM 接收摘要后不是直接返回方向盘转角或油门开度而是返回一份“决策建议协议”推荐的目标车道、速度策略、需要避让的目标集合、对应的约束条件比如最小安全距离、最大横向加速度。Slow 路径的推理结果本质上是“建议”而不是“命令”这份协议会被送到融合层和 Fast 路径的实时输出一起产生最终指令。这样设计的好处非常明显LLM 擅长的是语义理解、常识推理和多目标权衡而不是高频数值控制。让它做“规划顾问”正好把优势发挥出来同时把延迟劣势隔离在建议层之外。2.3 路由器风险信号的第一次筛选路由器是 AdaDrive 里最容易低估、实际最影响系统效果的部分。它的职责是对每个控制周期做一次“是否需要启动慢速路径”的判断核心输入是风险评分和置信度评分。我们内部采用的路由判断逻辑大致如下routeScore w1 * uncertaintyScore w2 * riskScore w3 * oscillationScore其中 uncertaintyScore 来自 Fast 路径的自查模块riskScore 来自场景风险评估oscillationScore 用来识别规划结果的高频抖动。权重 w1、w2、w3 需要根据具体车型和应用场景标定在线运行时还会结合当前车速和驾驶模式做动态调整。路由触发不是简单的阈值比较而是带滞回区间的状态机。举例当 routeScore 超过 0.6 时触发慢速介入但介入后要等 routeScore 回落到 0.4 以下才解除。这个 0.2 的死区能有效抑制临界场景下反复唤醒模型的问题。很多系统在仿真里看起来路由逻辑没问题一放到真实路测就频繁触发几乎都是因为没有做滞回设计。2.4 融合模块权重怎么算怎么平滑融合模块是整个框架里“按量融合”思想的落地点。它的输入有三个Fast 路径的实时控制量、Slow 路径的决策建议协议、当前场景的风险与置信度信号。输出是最终执行的控制量。融合权重 alpha 的计算方式可以表述为alpha clamp(gamma * riskScore (1 - gamma) * interventionNeed, 0.0, 1.0)其中 gamma 是一个可调参数interventionNeed 由 Fast 路径置信度和场景复杂度共同构成。由于 alpha 本身是逐帧计算的直接使用会造成控制量抖动。我们的做法是加一级平滑滤波限制 alpha 每帧变化量不超过 0.05同时在慢速路径首次介入后的前几帧做一个斜坡上升给它一个“逐渐取得信任”的过程。另外还有一条硬性安全约束Slow 路径给出的建议协议在任何情况下都必须通过安全校验器的检查。如果校验不通过alpha 直接归零系统继续以 Fast 路径输出为准。这条规则保证了融合层不会因为模型的一次误判而把车辆带进危险状态。3. 实操过程与闭环调参3.1 先跑通不带 LLM 的闭环我在团队里推 AdaDrive 时第一步从来不是接模型而是先把 Fast 路径闭环跑到足够稳。具体做法分两步先在离线仿真平台上把常见场景全部刷一遍包括直线巡航、前车切入、低速绕障、静态障碍避让记录每条轨迹的跟踪误差和控制平滑度然后放到实车/真机平台上验证频率指标确认单周期开销和稳定性符合预期。这个阶段的目标非常明确让团队所有成员对“Fast 路径到底能处理到什么程度”有一个量化认知。只有知道基线在哪里后面评估慢速路径的增益才不是拍脑袋。3.2 搭一个模拟延迟的介入链路模型还没接的时候可以先做演练。我在工程上强烈建议准备一套“假慢速路径”本质是一个函数接收同样的场景摘要返回一组预设好的规划建议但每次调用都强制 sleep 300到800ms。为什么这么做因为 LLM 接入后最明显的变化不是决策内容而是延迟。提前把延迟引入系统可以逼着调度和融合逻辑在真实延迟条件下工作而不是在“没有延迟”的梦幻环境里自嗨。演练期间要重点观察两件事一是路由触发后的等待阶段Fast 路径是否会继续安全运行二是慢速输出到达后融合过程的控制量是否平滑。这两点决定了真实模型接入后的体验上限。3.3 触发阈值与融合权重的标定流程正式接入 LLM 以后调参顺序要严格先调触发再调融合最后调 prompt 内容。触发阈值标定时我习惯用一批“困难场景集”来压测包括雨雾天气、夜间低照度、交通参与者行为异常、道路施工改道等。然后统计如下指标指标含义目标触发召回率应该介入的场景里有多少帧确实触发了尽量接近 95%误触发率不需要介入但因置信度波动触发的比例低于 5%平均介入间隔两次慢速介入之间的平均时间越大越好融合权重 alpha 的标定我倾向于用网格搜索配合闭环评估在典型场景里固定路由条件把 alpha 分别设为 0、0.1、0.2直到 1.0每组跑若干次闭环仿真记录碰撞率、平均横向偏差、控制加速度抖动等指标。最后取表现最优且余量充足的 alpha 区间作为基准曲线再做风险映射。3.4 量化“闭环性能”和“实时效率”框架上线后需要一套能被所有人同意的量化口径。我们内部日常跟踪的指标分成三类实时效率类Fast 路径运行频率、单控制周期 p99 延迟、慢速路径占用率。闭环性能类复杂场景完成率、平均跟踪误差、与驾驶员/人工轨迹的偏差。融合质量类控制量平滑度、慢速介入前后的加速度跳变峰值、alpha 抖动幅度。有一个容易被忽略的点闭环性能不只看“完成了多少场景”还要看“完成过程中身体和心理的安全余量”。慢速路径的介入如果让车辆在某几帧里出现明显过冲即使最终没发生碰撞这种表现也不能算合格。所以我们的闭环评估会额外加入“最大横向加速度变化率”这类细节指标。4. 常见问题与排查实录4.1 慢速路径触发太频繁实时效率恶化症状日志里慢速路径平均每小时触发几十次控制周期 p99 明显上升系统整体手感变“沉”。根因通常有两个一是路由阈值设得过低Fast 路径置信度稍微波动就直接触发二是缺少冷却或滞回机制置信度在阈值附近来回穿越导致反复唤醒。解决思路第一步把触发阈值往上抬同时把解除阈值往下限加宽滞回区间第二步给同类场景加最短冷却时间比如同一个触发源在 3 秒内不许重复介入第三步检查 Fast 路径的置信度校准是否准确很多频繁触发其实是置信度滤波没做好造成的高频抖动。4.2 融合权重抖动导致控制量不平滑症状alpha 数值本身变化不大但融合后的控制量在慢速路径介入瞬间出现明显“拽一下”的感觉。排查后发现很多情况跟融合公式无关而是慢速路径输出的建议协议结构太粗和 Fast 路径的输出空间不在同一个坐标系里。比如 Fast 路径输出的是路径点序列而慢速路径只给了一个目标点融合时就会出现语义错位。解决办法是在融合层之前加一个“协议翻译器”把 LLM 的建议协议转换成与 Fast 路径完全一致的数据结构再做加权。另外把 alpha 变化率硬约束加上效果会更直接。4.3 慢速路径判断失误后没有兜底LLM 再聪明也会有幻觉和不稳定的情况。我们在一次内部测试里遇到过模型建议“绕过施工区走对向车道”这个建议在语义上是合理的但根据当前车速和两侧车流状态执行窗口根本不够安全校验器直接拦截并把 alpha 归零。我强烈建议所有做类似框架的人把两个模块当作强制项一个是安全校验器负责对慢速建议做几何可行性、动力学可行性和语义一致性检查另一个是回退策略一旦校验不通过系统应自动保持 Fast 路径输出同时标记一个“慢速路径不可信”的临时状态降低后续触发优先级。4.4 仿真表现很好一上真实设备就乱套这是最常见也最让人头疼的问题。仿真环境里感知理想、延迟固定、执行器响应线性而真实设备上感知噪声、调度抖动、网络波动全部叠加慢速路径的输出往往变得不稳定。有个有效的经验仿真平台一定要内置“延迟注入模块”和“感知噪声模块”而不是让开发环境太干净。我们在后面几个迭代里干脆把仿真平台的延迟参数调成比真实平台更恶劣逼着调度逻辑在最坏条件下还能保持闭环稳定这样上真机后反而很少出现“水土不服”。5. 个人实操沉淀中的一些体会调试 AdaDrive 的过程中我踩过最大的坑就是一开始总想让 LLM 承担更多责任。后来发现大模型在决策链路里的正确位置不是“全知全能的主控”而是“偶尔被请来会诊的专家”。如果总是让它做事它既快不起来还会因为延迟和幻觉引入新的不确定因素如果从不让它做事那引入它就没价值。真正的平衡点是用一套扎实的路由机制和融合机制让它在复杂场景里恰到好处地发挥优势。还有一个细节想分享融合权重的上限千万不要设成 1.0。哪怕场景再危险我也习惯把最大融合权重控制在 0.85 左右。原因很简单给 Fast 路径留一点固定比例的输出能保证系统永远有一条熟悉底层控制律的路径在托底。这条经验在面对模型输出异常、通信中断、计算降级等极端情况时救过我们很多次。AdaDrive 这套框架目前已经在我们内部的多个模拟平台上跑过了完整的闭环实验也经历了好几轮“仿真—真实设备—再仿真”的反复迭代。它未必是最终形态但我觉得“快慢协作、按需介入、按量融合”这三个原则对于任何想把大模型引入实时闭环系统的人来说都值得作为第一版设计基线。后续如果继续往下做我还有两个方向想探索一是把路由决策本身也变成可学习的模块让系统自动适应不同驾驶风格二是把慢速路径从单一的 LLM 扩展到“多专家协作”进一步提升长尾场景的覆盖质量。

AdaDrive：LLM与实时控制融合的快慢双路自动驾驶决策框架

相关推荐

Ollama 本地大模型推理实战：从模型管理到 RAG 与 Go 应用部署

NLP特征提取与无监督学习：从词袋到BERT的实战指南

FAIR风险量化分析实战：从损失频率到安全预算决策

更多资讯

Stable Diffusion室内设计实战：从毛坯房到风格效果图的AI辅助流程

用视频生成搭一座桥：动作剪影如何让机器人学会预演未来

为什么new出来的MonoBehaviour不执行Start？深度解析Unity生命周期调用链

YOLOv11农业病害识别实战：从数据准备到部署全流程

九宫格与方块轮盘抽奖H5实现：核心逻辑、性能优化与避坑指南

AI接入飞书机器人：基于OpenClaw的完整实践与排错指南

今日更新

NetSpot 实战：用信道分析与频宽优化解决 Wi-Fi 卡顿

C++ split() 字符串分割的五种实现与性能实测

R语言坐标轴范围设置：从xlim/ylim到coord_cartesian的完整指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？