基线模型

这篇论文主要对比了两个行业内非常有名的基线模型：AutoGPT 和 Voyager 。

  • AutoGPT： 这是一个自然语言处理自动化工具，主要依赖纯文本。它由 GPT-4 驱动，通过处理文本形式的智能体状态、环境反馈和执行错误来管理和执行子目标 。

  • Voyager： 这是一个在《我的世界》中非常经典的智能体，同样使用 GPT-4。它的特点是具有长期的程序化记忆和一个代码技能库 。但是，Voyager 完全依赖文本基础（textual grounding）来进行感知，很少甚至不强调视觉感知 。

简而言之，基线模型本质上是“盲人”。它们看不见游戏画面，只能靠阅读游戏后台发来的“文本日志”（比如：你前面3格有一个木头，你的血量是15）来玩游戏 。

为什么 STEVE 的方法比基线更好？使用了什么策略？

STEVE 效果更好，核心就在于它打破了“纯文本交互”的局限，具体使用了以下几个关键策略使得效果大幅提升：

  • 策略一：赋予视觉感知（Vision Perception）
    这是最大的优势。文本很难自然地传达环境的空间布局或合成配方等视觉概念 。STEVE 加入了视觉单元，通过视觉感知丰富信息，这极大地提高了搜索和探索任务的效率 。消融实验也证明，去掉视觉单元后，模型在处理高级任务（如获取钻石工具）时会面临巨大挑战 。

  • 策略二：内部的多智能体协作大脑（Language Instruction）
    STEVE 的大脑不仅仅是一个语言模型，而是被拆分成了四个分工明确的子代理：

    • Planner（规划者）： 制定高级任务指南 。

    • Critic（评估者）： 评估规划者的决策并提供反馈 。

    • Curriculum（课程）： 负责让智能体参与一系列复杂的任务进行持续学习 。

    • Describer（描述者）： 负责将大量数据压缩成简明的摘要 。
      这种设计让模型能够进行迭代推理，把复杂的宏大目标分解为可以执行的底层步骤 。

在系统刚刚初始化、记忆库完全空白的时候，课程 Agent 并不需要“绞尽脑汁”去想任务。作者在论文中明确提到，他们首先创建了一组任务（a set of tasks），以此作为智能体探索环境的初始课程。

整个系统的运作是一个不断循环的强化与规划过程。它们的标准调用顺序如下：

**[记忆库 Memory] & [当前环境状态]**
↓
1. 课程 (Curriculum, $\mathcal{C}_u$) —— 结合记忆，下发当前阶段的宏观任务 
↓
2. 规划者 (Planner, $\mathcal{P}_l$) —— 接收宏观任务、视觉画面和状态，生成具体的行动草案 
↓  $\rightleftarrows$ *(如果被否决，打回给 Planner 重新规划)*
3. 评估者 (Critic, $\mathcal{C}_r$) —— 审查草案，提供反馈 
↓ *(如果审核通过)*
**[执行阶段 Code Action]** —— 检索底层代码，在《我的世界》中实际执行动作 
↓ *(执行完毕，产生一大堆冗长的日志和环境变化数据)*
4. 描述者 (Describer, $\mathcal{D}_s$) —— 提炼日志，生成简短的经验摘要 
↓
**写入 [记忆库 Memory]** —— 供下一轮的 Curriculum 决策使用

  • 策略三：带摘要的持续学习（Chain of Summarization）
    随着游戏进行，记忆库会越来越大，导致大模型处理缓慢且难以理解现状 。STEVE 引入了“摘要链”方法，对冗长的历史记忆进行压缩，这帮助它在面对“获取钻石工具”这种超长线任务时提高了成功率 。

  • 策略四：基于检索的代码动作库（Code Action）
    大模型直接写底层代码容易出错。STEVE 建立了一个包含210个技能脚本的代码库，模型只需要将思考后的文本动作转化为向量，去库里匹配最相似的代码直接执行，保证了动作的可靠性 。

整体的评估指标

为了证明系统的全面性，论文从三个截然不同的任务维度进行了评估，并使用了不同的量化指标：

  • 连续方块搜索（Continuous Block Search）：评估探索效率。

    • 指标1：找到10颗钻石所需的平均迭代次数（最大100次）。迭代次数越低，说明效率越高 。

    • 指标2：在100次迭代内找到的钻石平均数量。数量越多越好 。

  • 科技树掌握（Tech Tree Mastery）：评估长期规划和复杂工具链的合成能力（从木制工具一路升级到钻石工具）。

    • 指标1：成功率分数。即在3次尝试中成功完成的次数（例如 3/3，如果在160次迭代内无法完成则记为 0/3）。

    • 指标2：平均迭代次数。数值越低，说明解锁对应科技树的速度越快 。

  • 知识问答（Knowledge QA）：评估模型对游戏领域知识的理解程度 。

    • 指标：由 GPT-4、Claude-2 以及人类盲评打分。根据准确性、相关性和细节程度，在 0 到 10 分之间进行评分。分数越高，表示生成的答案与标准答案的一致性越好 。

模型输入输出

  • 模型输入：模型接收三种维度的输入：

    1. 视觉状态 XvX^vXv（来自游戏内第一人称视角的图像或视频） 。

    2. 智能体状态 XsX^sXs（以文本形式表示的生命值、饥饿度、物品栏等） 。

    3. 任务描述 XtX^tXt（文本形式的具体任务指令） 。

  • 模型输出：最终输出为可以与Minecraft环境直接交互的可执行代码动作（executable code action） aca^cac 。

模型的网络结构

STEVE 框架由三个核心模块串联组成 ：

  • 视觉感知 (Vision Perception, Pv\mathcal{P}^vPv)：包含一个基于 EfficientFormer 视觉分支的视觉编码器，用于将视觉状态编码为视觉Token；以及一个文本分词器（Tokenizer），用于将智能体状态和任务描述转化为文本Token 。

  • 语言指令 (Language Instruction, Il\mathcal{I}^lIl)：其核心是基于 LLaMA-2-13B 微调的 STEVE-13B 模型 。该模块由四个承担不同功能的代理组成：规划者（Planner）、评估者（Critic）、课程（Curriculum）和描述者（Describer） 。它的作用是进行复杂的迭代推理，将高层次的策略分解为具体的、底层的文本动作步骤 。

  • 代码动作 (Code Action, Ac\mathcal{A}^cAc)：这是一个基于向量检索的执行阶段 。它将语言模块输出的文本动作编码为查询向量，通过余弦相似度匹配，从预先构建的技能数据库中检索出最符合要求的代码片段，进而控制智能体执行 。

数据集

作者专门收集并构建了 STEVE-21K 数据集来训练和微调模型 。该数据集包含三个部分：

  • 视觉-环境对 (Vision-Environment)：包含超过600个第一人称视角的Minecraft游戏视频记录，配套提供了对应时间戳的视野内环境方块、实体标签以及上下文聊天记录 。

  • 知识问答对 (Question-Answering)：从Minecraft-Wiki和Reddit收集清理出的2万对单轮问答数据，涵盖世界实体、玩家机制、生存合成等多种类型 。

  • 技能-代码库 (Skill-Code)：包含210多个由人类编写并经过验证的技能执行脚本代码，配备有GPT-3.5生成的描述，用于构建动作检索数据库 。

改进

作者提出了一套名为 STEVE 的多模态具身智能体框架，从感知、推理到执行进行了全方位的改进：

  • 引入视觉感知模块，打破纯文本局限：

    • 为了解决文本难以传达合成配方等视觉概念的难题，作者在智能体中加入了视觉感知（Vision Perception）模块 。

    • 该模块使用了一个基于 EfficientFormer 的视觉编码器，能够将环境的视觉状态（如游戏内的图像或视频）直接编码为视觉 Token 。

    • 通过将这些视觉 Token 与智能体当前状态和任务描述的文本 Token 融合，智能体获得了对环境更细致、更全面的多模态理解能力 。

  • 领域专属微调与任务结构化拆解，降低输出不可预测性与提示工程依赖：

    • 作者没有直接使用通用 LLM 盲目进行提示工程，而是基于 LLaMA-2-13B，使用《我的世界》的相关语料微调出了专属的 STEVE-7B/13B 语言模型 。

    • 在语言指令（Language Instruction）模块中，作者设计了四个基于大语言模型的独立代理：规划者（Planner）、评估者（Critic）、课程（Curriculum）和描述者（Describer）。

    • 通过这些代理的协作，模型可以进行复杂的迭代推理，将高层次的抽象策略一步步拆解（Decomposition）为可以具体执行的低层次文本动作指令 。

    • 此外，模型还结合了带有记忆的课程学习和“摘要链”（Chain of Summarization）技术，帮助智能体从错误中学习，并有效管理和压缩冗长的历史记忆 。

  • 构建基于检索的代码动作模块，解决底层交互执行问题：

    • 针对 LLM 直接生成底层操作代码不可靠的问题，作者设计了代码动作（Code Action）模块作为执行阶段 。

    • 作者建立了一个“技能数据库”（Skill Database），其中包含具体的执行代码片段及其对应的描述向量 。

    • 系统会将语言指令模块输出的底层文本动作编码为查询向量，通过余弦相似度匹配，直接从数据库中检索出最合适的现成代码片段交给引擎执行，从而大大提高了动作的准确性和有效性 。

  • 构建专属多模态数据集，填补资源空白：

    • 为了支撑上述多模态智能体的训练，作者精心收集并构建了 STEVE-21K 数据集 。

    • 该数据集包含了 600 多对视觉-环境对、2 万对知识问答对以及 200 多个技能-代码对，专门用于解决开放环境中多模态数据整合研究不足的问题 。

微调

一、 视觉输入到底是在什么地方加的？

视觉输入并不是从网络中间某个奇怪的隐藏层插进去的，而是直接在最前端的输入序列级别（Token-level）拼接进去的。

这个过程需要一个至关重要的组件：投影层（Projection Layer），它就像是一个跨模态的“翻译官”。

  1. 特征提取：首先，图像（或视频帧）输入到视觉编码器（比如这篇论文里的 EfficientFormer 或者开源界常用的 CLIP ViT）。编码器会把图像切成很多块（Patches），输出一堆视觉特征向量（例如维度是 768 或 1024）。

  2. 跨模态投影：这些特征向量接着会通过一个投影层（通常是一个简单的线性层 Linear 或者两层的 MLP）。这个投影层的唯一目的，就是把视觉特征的维度，强行拉伸或压缩到和 LLaMA 词嵌入（Word Embedding）完全一致的维度 （比如 LLaMA-2-13B 的 d=5120d=5120d=5120）。

  3. 序列拼接（Concatenation）：经过投影后，图像就变成了一串维度为 5120 的“视觉 Token”。在进入 LLaMA 的第一层 Transformer Block 之前，系统会直接把这些视觉 Token 和你的文本 Token（比如 Prompt）在序列长度维度上拼在一起 。

最终喂给 LLaMA 的，就是一个长长的、维度统一的矩阵：[视觉Token序列, 文本Token序列]。对 LLaMA 内部的自注意力机制来说，它只看到了一串 5120 维的向量，它通过计算 Attention 权重自然地实现了图文信息的融合。

二、 视觉输入是怎么微调的？（梯度怎么流？）

在多模态大模型（VLM）的标准范式（如 LLaVA 架构）中，微调通常分为两个阶段。而这篇 STEVE 论文在具体实现上做了一些结合环境的调整。

1. 标准 VLM 的微调范式（背景知识）

为了防止原本聪明的语言模型被乱七八糟的初始化视觉特征“带偏”，训练时对梯度的控制非常严格：

  • 阶段一：特征对齐（Feature Alignment）

    • 状态：冻结（Freeze）视觉编码器，完全冻结 LLaMA 本身。
    • 训练谁：只训练那个中间的“投影层”。
    • 目的：用大量的（图像, 简单描述）数据，强迫投影层学会把视觉特征翻译成 LLaMA 已经能听懂的“文本口音”。

  • 阶段二：视觉指令微调（Visual Instruction Tuning）

    • 状态：保持视觉编码器冻结。
    • 训练谁：放开投影层，并且在 LLaMA 中插入 LoRA 权重（或者全量微调 LLaMA）。
    • 目的：用多模态的 QA 数据，让模型学会如何结合视觉信息来回答复杂的指令。
2. 这篇论文是怎么做的？

由于 STEVE 是一个要在动态虚拟环境中执行任务的智能体，它的微调策略 更偏向于“在线（Online）”的场景适配：

  • Offline Warm-up（离线预热）：作者第一步居然没有先上图片，而是用 STEVE-21K 数据集里的纯文本 QA 对，先对 LLaMA 加 LoRA 跑了一遍微调 。这一步是为了让模型先熟悉 Minecraft 里的各种知识和指令格式。

  • Online Finetuning（在线微调）：这是引入视觉的核心阶段。在模拟环境中，系统不仅输入文本，还输入了通过 Ray Tracing 剔除遮挡后的可见视觉特征 。

  • 梯度流向：在这个阶段，作者同时训练了视觉编码器和 LLaMA（带 LoRA） 。

  • 损失计算：在计算交叉熵损失（Cross-Entropy Loss）时，只对回答部分（Answer tokens）计算 Loss ，也就是公式里的 L(θ)=−∑log⁡Fθ(Yj∣Xv,Y^1:j−1)\mathcal{L}(\theta) = -\sum \log \mathcal{F}_{\theta}(Y_j | X^v, \hat{Y}_{1:j-1})L(θ)=−∑logFθ​(Yj​∣Xv,Y^1:j−1​) 。

  • 随着反向传播，梯度会穿过 LLaMA 的 LoRA 权重，一直传导回最前端的视觉编码器。

在线微调

在第一阶段（离线预热）中，模型通过纯文本问答对具备了基础的指令理解能力 。而在线微调的核心目的，就是让模型真正在虚拟环境中“边看边学”，并对齐一个更强大的“专家”。

根据论文第 3.5 节的内容，在线微调的具体执行步骤可以详细拆解为以下几个环节：

1. 引入“专家教练”（Expert LLM）进行知识蒸馏

论文并没有让人类去手把手教模型玩游戏，而是引入了一个结合了 GPT-4 的专家级大语言模型（Expert LLM，表示为 Ep\mathcal{E}_pEp​）作为“教练” 。

  • 在模拟环境中，研究人员会将完全相同的输入环境信息（相同的视觉画面、状态、任务提示）同时喂给正在训练的 STEVE-7B/13B 以及这个 专家大模型 。

  • 系统会将专家大模型输出的指令，直接作为训练的真实标签（Ground Truth Label） 。这实际上是一种在交互环境下的知识蒸馏。

2. 利用光线追踪（Ray Tracing）获取精确的视觉监督信号

模型在环境里需要训练它的视觉编码器（Vision Encoder, EvE^vEv），让它认识游戏里的方块和实体 。但游戏画面是像素，怎么给它打标签呢？

  • 作者使用了一种光线追踪方法（Ray Tracing method, RTR_TRT​） 。
  • 痛点：如果你直接从 Minecraft 的后台读取数据，系统会把玩家周围一大块区域（Chunk）里的所有方块和实体都告诉你，包括墙背后的僵尸、地下的矿石。但作为基于视觉的智能体，它不应该拥有这种“透视挂”，它只能根据屏幕上真正看见的东西来做决策。
  • 做法：作者使用 Ray Tracing 技术 RTR_TRT​，从智能体的“虚拟眼睛”向屏幕的每个像素发射射线 。如果射线碰到了石头，停下来了，那么石头后面的僵尸就被判定为“不可见”。

  • 提取出当前屏幕上真实可见的方块和实体的标签（记为 lll），公式表示为 l=RT(Xv)l=R_T(X^v)l=RT​(Xv) 。

  • 一旦获得了这些精确的环境信息标签，系统就会以此来训练视觉编码器 。

3. 视觉与语言指令的联合训练（Simultaneous Training）

在线微调不是分步优化的，而是一个端到端的联合过程。在模拟过程中，系统会同时训练视觉编码器 EvE^vEv 和微调语言模型 STEVE-7B/13B 。

  • 损失函数的计算：训练采用了预测 Token 上的负对数似然目标（Negative Log-likelihood Objective） 。公式定义为：
    L(θ)=−∑j=1Llog⁡Fθ(Yj∣Xv,Y^1:j−1)\mathcal{L}(\theta)=-\sum_{j=1}^{L}\log\mathcal{F}_{\theta}(Y_{j}|X^{v},\hat{Y}_{1:j-1})L(θ)=−∑j=1L​logFθ​(Yj​∣Xv,Y^1:j−1​)

  • 专注回答部分：在计算损失时，为了确保模型专注于生成连贯的响应（而不是去预测前面的问题或视觉前缀），论文指出他们只对回答的 Token（Answer tokens, XAX_AXA​）计算损失 。

4. 大规模模拟与高质量数据沉淀

这个在线训练不是跑几局就结束了。

  • 论文提到，他们在环境中进行了 5,000 次模拟 。

  • 经过这大量的模拟后，他们筛选并收集了所有成功运行的上下文信息 。

  • 这些成功案例的数据（包括连续的视觉画面、对应的问答聊天流），最终被打包整理成了 STEVE-21K 数据集中的“视觉-环境（Vision-Environment）”部分 。

蒸馏

这里的“蒸馏”确实就是纯数据层面的蒸馏（在当前大模型领域，这通常被称为 Output Distillation 或 Behavioral Cloning / 行为克隆），而不是传统意义上提取教师模型“软标签（Logits/隐藏层特征）”的蒸馏。

既然你做过基于 QA pairs 的 SFT，其实你对这个过程已经非常熟悉了。我们可以把这两者结合起来，详细拆解一下这个公式到底在干什么。

1. 这里的“蒸馏”本质是什么？

在大模型时代，如果不用 OpenAI 的内部 API，我们是拿不到 GPT-4 的 Logits 的。因此，STEVE 论文中所谓的“蒸馏”，实际上就是用 GPT-4 来自动生成高质量的 SFT（监督微调）训练数据。

具体场景是这样的：

  • 输入侧（环境）：当前游戏画面（通过 Ray Tracing 提取出的方块和实体）+ 玩家状态 + 任务目标。
  • 专家侧（GPT-4）：把上述环境信息用文字描述给 GPT-4，GPT-4 会输出一段完美的、包含推理过程的行动计划（比如：“发现苦力怕，先后退，然后用铁剑攻击”）。
  • 学生侧（STEVE）：把 GPT-4 刚刚输出的这段话，直接作为真实标签（Ground Truth）。

所以，这本质上就是使用专家数据进行的监督微调（SFT）。作者把大模型在环境里的交互过程记录下来，让 GPT-4 给出标准答案，然后让本地的 LLaMA 去死记硬背（拟合）这些标准答案的推理模式。

2. 那个微调公式到底在算什么？

论文中给出的公式：

L(θ)=−∑j=1Llog⁡Fθ(Yj∣Xv,Y^1:j−1)\mathcal{L}(\theta) = -\sum_{j=1}^{L} \log \mathcal{F}_{\theta}(Y_j | X^v, \hat{Y}_{1:j-1})L(θ)=−j=1∑L​logFθ​(Yj​∣Xv,Y^1:j−1​)

这其实就是你做 SFT 时用到的最经典的自回归下一个词预测（Next-Token Prediction）的交叉熵损失函数（Cross-Entropy Loss）。

我们把这个公式里的符号代入到刚才的《我的世界》场景中，你就完全明白了：

  • L(θ)\mathcal{L}(\theta)L(θ)：Loss（损失值），也就是我们要通过梯度下降尽量缩小的误差。θ\thetaθ 就是你的模型参数（视觉编码器 + LLaMA 原有参数 + LoRA 权重）。
  • XvX^vXv：视觉输入（Vision Input）。也就是经过视觉编码器和投影层处理后，拼接在最前面的“视觉 Token 序列”（它看到了苦力怕）。
  • Y^1:j−1\hat{Y}_{1:j-1}Y^1:j−1​：历史文本上下文。这包含了任务的 Prompt，以及模型在当前词之前已经生成（或已经给定）的所有词。
  • YjY_jYj​：目标词（Target Token）。这是这个公式的核心——这个词是谁决定的？就是 GPT-4 决定的！ 它是专家给出的标准答案里的第 jjj 个词。
  • Fθ(...)\mathcal{F}_{\theta}(...)Fθ​(...)：这是你的 STEVE 模型输出的概率分布。它表示在看到画面 XvX^vXv 和前文 Y^1:j−1\hat{Y}_{1:j-1}Y^1:j−1​ 的情况下，模型预测下一个词正好是 GPT-4 那个标准答案 YjY_jYj​ 的概率。
总结：公式与蒸馏的完美结合

这个微调的过程，翻译成大白话就是：
“在看到当前的视觉画面（XvX^vXv），并且已经说了前半句话（Y^1:j−1\hat{Y}_{1:j-1}Y^1:j−1​）的前提下，STEVE 模型，你预测下一个词汇的概率，必须无限逼近 GPT-4 说的那个词（YjY_jYj​）。”

因为公式前面有个负号（−log⁡-\log−log），所以当 STEVE 预测 GPT-4 那个词的概率越接近 100%100\%100% 时，log⁡(1)=0\log(1)=0log(1)=0，Loss 就越接近 000。

所以，这套方法没有任何魔法。它和你 QA LoRA SFT 在数学原理上完全一模一样。唯一的区别在于：

  1. 输入端多拼了一段代表图像的向量（XvX^vXv）。
  2. Target 答案不是人工手写的 Wiki 知识，而是 GPT-4 看着游戏画面临时生成的战术指导。
# 人工智能
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

AI 写 C# 代码很快，但为什么老项目里不能直接复制？

avatar AtomGit开源社区
cover

智能体式邮件安全体系对抗社会化工程攻击研究

avatar AtomGit开源社区
cover

EXPLAIN进阶：读懂key_len和filtered

avatar AtomGit开源社区