{{detailStore.author.is_follow?'已关注':'关注'}}
图 1 是理想上一代架构; 图 2 是理想现在的新架构; 有点难理解,但整体还行,解释一下: 理想两代架构对比:为什么'绕过语言'是正确的一步 两代架构放在一起,最容易看出来的变化是:中间那层不见了。 上一代有Spatial → Linguistic → Action,三段式。 这一代把'语言'那层压缩掉,视觉信号和文本信号直接进模型,出来就是动作。 但'去掉语言层'这件事,不是字面意思那么简单。 它背后有一套因果逻辑,值得认真拆解。 语言模型在中间扮演什么角色? 先回答一个问题:为什么上一代要用Mind GPT做中间层? 语言模型的核心能力是语义理解和常识推理。 '停在站台边的公交车可能要起步',这个判断不是像素直接告诉你的,是你知道公交车通常不会无缘无故停在路边,有人上车才会启动。 知道这个常识,才能做出正确判断。 所以上一代的思路是:先用3D编码器把视觉信息压缩成语义特征,再让语言模型在语义层面做理解和推理,最后靠扩散解码器把推理结果翻译成可执行的轨迹。 语言在这里充当了一座桥。 视觉信号先过桥变成文字,语言模型在彼岸推理,推理结果再过桥变成动作。 这座桥本身不是问题。 问题是桥的两端在不同的世界里。 语言模型的'输入'是离散的符号序列,'输出'也是离散的符号序列。 一张2D图像被编码器压缩成一系列token,token之间是离散的语言符号。 但驾驶不是离散符号,它是一个连续的物理过程,旁车的速度、它和你的相对距离、道路曲率下一秒会怎么变化,这些信息在语言符号的离散空间里不可避免地会被压缩。 更关键的是,驾驶需要多步推演。 '如果我现在变道,旁车3秒后会减速。' 这不是一个静态的语义理解,而是一个动态的条件预测。 语言模型能理解'A会导致B',但它的下一个词预测机制不显式建模时间维度上的因果链,它能输出'A导致B'这句话,但'因为A所以B'的推演过程藏在模型的权重里,从外面看不到。 换句话说:语言模型能给出对的答案,但它的推理过程不可审计。 这在聊天场景里不是问题,答案对就行。 但在自动驾驶场景里,'为什么'和'是什么'同样重要。 如果系统做了一个决策,工程师需要知道决策的依据是什么,才能判断这个决策是否合理、边界在哪里。 上一代用语言翻译搭的桥,在推理和动作之间留下了一个不透明的灰色地带。 隐空间推演是什么? 这一代的核心变化,就是把推理从语言空间挪到了隐空间。 隐空间不是语言符号构成的空间,而是连续数学构成的空间。 它的每一个点不是一个词或一个标签,而是一个连续的状态向量。 连续空间天然适合描述物理过程。速度、距离、加速度、相对位置,这些物理量在隐空间里直接对应向量运算,不需要被翻译成'前车速度较快'这样的离散标签再处理。 隐世界模型在这里做的,是把当前场景编码成隐空间里的一组向量,然后用这组向量推演未来几步的状态变化。 不生成像素,不生成文字,直接在连续空间里'想象',如果我做了动作A,未来某个时刻系统的隐状态会变成什么样。 这套机制能解决'多步推演'的问题。 语言模型能做一步推理(看到公交车,输出'可能起步'),但两步以上的条件推理(如果我减速它会怎样、如果我加速它会怎样)需要在前一步的结果上继续推演,每一步都有信息损耗。 隐世界模型不一样——它推演的是连续状态,每一步之间的信息传递是向量之间的数学运算,没有离散符号翻译的损耗。 这就是为什么隐空间比语言空间更适合驾驶推理。 不是因为数学上更先进,而是因为驾驶这个问题的本质就是连续物理过程,用连续空间建模天然比用离散符号建模更匹配。 显式推理的必要性。 但隐世界模型有个弱点:它推演的过程也在隐空间里,外面看不到。 模型输出了一个决策,但你不知道它为什么做了这个决策。隐状态变了,你知道状态变了,但不知道为什么会变。 这对产品来说是可接受的——用户不需要知道车的'脑子里'在想什么。但对工程来说不可接受。 出了问题,调参没有依据,边界情况一个接一个地冒出来。 所以这一代加了一个'系统2'层,把隐空间的推理结果翻译成可读的逻辑表达。 我认为这辆公交车正在等人,所以我选择减速跟随而不是绕行。 这句话不是驾驶决策本身,而是决策的推理链。 它输出给用户,是解释; 输出给工程师,是调试依据; 输出给验证流程,是可追溯的决策记录。 系统2不改变决策结果,它把决策过程显式化了。模型在隐空间里做推演,在语言空间里说清楚,两个过程并行存在,各司其职。 动作生成的三层设计。 推演完了,接下来是动作生成。 上一代用扩散解码器做轨迹生成,过程是:输入一个带噪音的轨迹,通过多轮去噪迭代,逐渐恢复出一条干净、合理的轨迹。 扩散生成的好处是质量高,每一步迭代都在约束轨迹的物理合理性。但坏处是慢——多轮去噪需要串行计算,推理延迟有下限。 这一代没有把扩散解码器扔掉,而是把它拆成了三层: 第一层:Action Expert。 从3D场景特征、导航目标、驾驶指令中提取关键信息,生成一个'大概对'的初始轨迹。 快,但不精确。 第二层:Parallel Decoding。 把所有轨迹点并行输出,不是一个点一个点生成,而是一次性生成完整轨迹。 解决的是速度问题。 第三层:Discrete Diffusion。 对并行生成的轨迹做多轮去噪精修。解决的是质量问题。 三层各司其职:Action Expert给出方向,Parallel Decoding给出速度,Diffusion给出精度。 上一代是'精但慢',这一代是'快的基础上求精'。 两者不是替代关系,而是分工关系。 最后说一下长时记忆。 上一代架构在上下文层面支持用户偏好——当前会话里的驾驶习惯可以被感知和调用。 但这种偏好存储在上下文窗口里,关机即消失,不跨session。 这一代有了显式的Long-term Memory模块。 用户偏好被持续学习、长期存储,不依赖单次会话的上下文长度。系统记住你偏保守、喜欢在中间车道跑、经过这个路口习惯提前并线,这些偏好跨时间积累,持续影响模型决策。 这个变化在架构层面意味着什么? 意味着用户偏好不再只是'当前这轮对话的输入',而是模型权重调整的一部分。 系统不是根据你说了什么临时做决策,而是根据你过去怎么开车,持续校准决策风格。 不是'记住你说了什么',是'记住你是什么样的人'。 上一代的答案是'语言空间'。 视觉信号翻译成语言,语言模型在语言层面推理,推理结果翻译成动作。 三次翻译换来了可解释性,代价是信息损耗和延迟。 这一代的答案是'隐空间'。 视觉信号和语言信号一起进入隐空间,在连续数学里直接推演,最后把推理过程显式翻译成可读的解释。 推理和动作在同一个空间里完成,没有翻译损耗。 绕过语言不是因为语言模型不够强,而是因为驾驶这个任务的本质是连续物理过程,在连续空间里做推理比在离散符号空间里更匹配问题的数学结构。
  • 全部评论{{detailStore.commentnum}} 条
  • 只看作者
  • 最热
  • 最新
  • 最早

「待审核」

首评 {{ comment.relativeTime }} 已被赞赏 {{comment.integral}} 积分 回复

{{ type!=10 ? '前排沙发空着~' : '暂无相关评论' }}

{{type!=10 ? '还没有人评论哦,快抢沙发吧!' : '发表一下个人看法吧'}}
写评论
积分赞赏
点赞
评论区
  • 编辑
  • {{ is_favourite ? '已收藏' : '收藏' }}
  • {{ is_personal_top ? '取消主页置顶' : '个人主页置顶' }}
  • 举报
  • 加入黑名单
  • 内容{{ eyes_only ? '公开' : '仅自己' }}可见
  • 删除
  • 取消置顶
  • 置顶推荐
    • 6小时
    • 12小时
    • 24小时
    • 3天
    • 一周
    • 长期
  • {{ feature?'撤销':'进' }}精选库
  • {{ digest?'撤销精华':'设为精华' }}
回到顶部