Skip to content
←返回论文库

PAPER DEEP DIVE

大语言模型后训练强化学习

Rufus-Air:开放的 106B MoE 大模型后训练配方

基于 GLM-4.5-Air 的开放后训练研究,把监督微调、推理强化学习、多类智能体训练和偏好学习串成八阶段流水线,验证可学习性筛选、奖励可靠性排序与长轨迹训练基础设施对最终能力的共同作用。

论文:Rufus-Air: An Open LLM Post-Training Recipe

作者:Chia-Yuan Chang、Renyuan Cheng、Rui Feng 等 22 位作者,署名按姓氏字母排序,研究工作均在 Amazon 完成。

版本与链接:arXiv:2609.29421v2,2026 年 9 月 25 日修订,论文主页。

代码状态:按论文标题、作者和正文仓库链接检索,截至解读时未发现官方开源实现。论文详细描述了 Rufus-Slime 与 Rufus-Gym,但二者是内部训练栈说明,不等同于已发布的完整代码。

一句话总结

这篇论文把语言模型后训练写成一条可操作的八阶段流水线,并证明最终能力并非只由某个强化学习算法决定,而是由 SFT 能力底座、可学习样本筛选、奖励被投机利用的难易程度,以及长轨迹训练基础设施共同塑造。

研究背景与动机

公开权重模型降低了后训练门槛,但公开配方往往仍停留在系统卡层面。团队可以下载基座模型,却很难知道指令微调数据怎样配比、强化学习题目如何过滤、多个阶段为何按某个顺序排列,以及多轮工具调用产生的 token 轨迹怎样原样进入训练器。Rufus-Air 试图补齐的正是这段工程知识,而不是再提出一个只存在于单轮实验中的新损失函数。

论文选择 GLM-4.5-Air-Base 作为固定起点。它是总参数 106B、激活参数 12B 的混合专家模型,公开权重与原生思考格式可直接复用,Slime、Megatron-LM 和 SGLang 也能支撑其训练与推理。与从头训练基座相比,这样的规模让研究者可以在真实 MoE 路由问题上做实验,同时把强化学习阶段控制在 8 到 32 个节点,而不是只做小模型的概念验证。

作者将整条路线定义为一条严格串联的流水线。SFT 建立基础能力和统一输出格式,随后依次进行推理强化学习、代码强化学习、指令遵循强化学习、通用智能体、代码智能体、搜索智能体和基于人类反馈的强化学习。每个阶段接收上一阶段的检查点,因此后一阶段既能增强目标能力,也可能覆盖前一阶段的部分收益,这正是论文坚持逐阶段测量的原因。

这篇工作的关键判断是:阶段顺序应当跟随奖励可靠性,而不能只按人类直觉排列任务难度。推理和代码任务的答案可由确定性程序验证,适合尽早优化;指令遵循虽然部分依赖模型评分,但与策略已有行为接近,奖励可利用空间较小;开放式偏好奖励最容易漂移和投机,因此被放到最后,以缩短脆弱奖励持续承受优化压力的时间。

整体配方

论文用下图概括八个训练阶段、目标能力与奖励形式。流程不是并行训练多个专家后合并,而是让同一个策略连续吸收不同环境中的信号。

Rufus-Air 八阶段后训练流水线

图 1:从 GLM-4.5-Air-Base 出发,依次训练 SFT、推理、代码、指令遵循、三类智能体和 RLHF,最终得到 Rufus-Air。

flowchart LR
  B["GLM-4.5-Air-Base
106B total / 12B active"] S["SFT
9.01M samples
27.04B supervised tokens"] R["Reasoning RL
learnability band
0/1 verifier"] C["Coding RL
all tests pass
64K to 128K"] I["Instruction RL
necessary rubrics only"] G["General Agent
stateful MCP reward"] A["Coding Agent
shell + tests in sandbox"] W["Search Agent
tool gate + judge reward"] H["RLHF
open preference reward"] F["Rufus-Air
shipped checkpoint"] B --> S --> R --> C --> I --> G --> A --> W --> H --> F

若把每个阶段的策略记为 $\pi_k$,整条流水线可以写成:

$$\pi_0 \xrightarrow{\mathrm{SFT}} \pi_1 \xrightarrow{\mathrm{Reasoning\ RL}} \pi_2 \xrightarrow{\mathrm{Coding\ RL}} \pi_3 \xrightarrow{\mathrm{IF\ RL}} \pi_4 \xrightarrow{\mathrm{General\ Agent}} \pi_5 \xrightarrow{\mathrm{Coding\ Agent}} \pi_6 \xrightarrow{\mathrm{Search\ Agent}} \pi_7 \xrightarrow{\mathrm{RLHF}} \pi_{\mathrm{Rufus}}$$

这个表达看似只是流程图,实际规定了归因边界。论文主要用相邻检查点衡量阶段增益,而不是把最终模型与基座模型比较后,把所有差值都算到最后一阶段头上。

第一层:SFT 不是热身,而是能力底座

Rufus-Air 的 SFT 混合集包含 901 万个样本、445 亿原始 token、6670 万轮对话,其中 2350 万轮带有监督信号。屏蔽系统消息、用户回合和工具观测后,仍有 270.4 亿 token 参与损失计算,占原始 token 的 60.8%。这些数字说明 SFT 不只是教模型说几种固定格式,而是在注入数学推理、代码轨迹、长上下文和多轮工具调用等大量行为样本。

数据分布存在一个容易被样本数掩盖的差异。通用智能体样本占 39.6%,却只贡献 14.2% 的训练 token;数学与代码智能体合计只占 18.8% 的样本,却贡献 49.1% 的监督 token。原因是推理轨迹和多轮代码执行过程很长。论文同时报告样本占比与 token 占比,读者才能区分“来源覆盖广”和“实际监督量大”两件事。

SFT 数据类别按样本和 token 的占比

图 2:SFT 混合集的样本占比与监督 token 占比并不一致,数学和代码智能体在 token 侧明显更重要。

清洗流程先统一角色、损失掩码和思考标签,再处理智能体轨迹中的“思考、工具调用、工具结果”链。只有工具结果紧随其后的助手回合才被视为中间步骤,最终回答则切成独立训练样本。此前对话保留为上下文,但助手推理内容会被遮蔽,只有最后一次真实用户请求之后的有效步骤参与监督。这一设计避免模型把历史思考误当成当前答案。

污染过滤采用 8 词连续片段重叠、全量关键词检查和向量检索。对报告中的十个基准先做顺序筛查,共删除 3529 个样本;对最易泄漏的数学与知识题再做穷举 8-gram 和向量近邻人工复核,最终累计剔除 658 个唯一样本,使总删除量达到 4187 个实例。作者明确承认,任何基于 n-gram 和嵌入的过滤都不可能证明零泄漏,因此后续强化学习题集也沿用同一套筛查。

训练使用 512 张 H200,批大小 4096 个序列,峰值学习率 $5\times 10^{-5}$,随后余弦衰减到 $5\times 10^{-6}$。三个 epoch 的最终损失从 0.84 降到 0.34,但验证分数在第一轮后基本平台化。于是团队没有拿最后一步检查点,而是选择第 3799 步作为强化学习起点。这是一个很实用的选择:更低的训练损失不等于更好的泛化能力。

SFT 损失曲线和验证分数平台

图 3:重复数据让训练损失在 epoch 边界继续下降,但 AIME、GPQA、IFEval 等验证分数在第一轮后已趋平。

检查点IFEvalIFBenchGPQAAIME 25AIME 26
公开 GLM-4.5-Air83.0033.6073.9084.2086.50
Rufus-Air SFT 379988.3357.7568.1890.8390.00
差值+5.33+24.15-5.72+6.63+3.50

SFT 检查点已经在 IFEval、IFBench 和两个 AIME 上超过含强化学习的公开 GLM 版本,却在 GPQA 上低 5.72 分。能力提升与能力缺口同时被保留下来,后面的强化学习才有明确靶点。这也解释了为什么论文把 SFT 定义为“建立能力下限”,而不是可有可无的格式准备。

第二层:推理强化学习依靠筛选,而不是复杂目标

推理阶段汇总数学、科学和谜题三类共 121,161 道可验证题。数学占 47.7% 的题目,谜题只占 16.7%,却占 55.5% 的提示 token,因为棋盘、网格和规则说明更长。数学答案由 Math-Verify 检查规范化后的最终值,科学题使用模糊字符串匹配,谜题由生成的 Python 检查器执行验证。

第一道门是正确性过滤:如果 GPT-OSS-120B 教师也无法获得一次正奖励,题目会被删除,避免错误答案或无解任务污染训练。第二道门是可学习性过滤:当前策略成功率高于 0.8 的题目太简单,完全没有成功样本的题目则暂时学不会。训练中还会额外采样 1024 个候选题,只保留组均奖励落在宽松学习区间内的提示,形成自动课程。

$$\bar r=\frac{1}{G}\sum_{j=1}^{G}r_j,\qquad \bar r\in(0.0,0.8]$$

其中 $r_j$ 是同一提示第 $j$ 个回答的奖励,$G$ 是组内采样数。这个筛选并不是保证难度永远固定,而是随着策略变强,把过去稍难的题重新推进学习区间。它把课程设计从人工改题库变成了训练过程中的在线选择。

策略优化采用序列级 GSPO。论文没有把新目标当作核心创新,反而指出在强 SFT 底座上,数据筛选比策略梯度目标的细节更重要。为降低长回答无意义变长,训练会对超过同组最短正确回答的长度做线性惩罚;截断样本不参与损失。MoE 模型还使用 Rollout Routing Replay,使推理引擎采样时的专家路由与训练前向保持一致。

整个阶段在 GPQA 上从 68.18 提升到 73.50,但 AIME 25 和 AIME 26 分别下降 2.81 与 2.60。作者把 AIME 视为护栏而非主目标:每年只有 30 题,不到 3 分的波动甚至不足一道题,且相同条件下的重复评测可产生 4.6 分差异。因此更稳妥的结论是 GPQA 获得明确提升,而 AIME 变化落在评测噪声附近。

第三层:代码强化学习让执行器决定奖励

代码阶段使用 29,405 道 Python 题,包含函数断言与标准输入输出两种验证方式。EvolveCoder 提供带对抗测试的改写题,Nemotron 提供竞赛题,Dolci 与 ADR 补充混合格式和算法标签题。每道题在进入训练前经过模式检查、去重、教师可解性验证和“全通过即删除”的热身筛选。

模型回答必须把代码放在最后一个 Python 围栏块中。环境最多抽取 50 个测试,抽样种子由题目哈希决定,因此同一道题在不同回答间使用相同测试子集。所有选中测试通过才得到 1,否则为 0:

$$R_i=\mathbf{1}\left[\text{all selected verifier tests pass}\right]$$

这个二元奖励没有格式分,因为初始围栏格式合规率已经达到 98% 到 100%。它把优化压力集中在真正能否运行和通过测试上,也避免了“写了代码块但没有解决问题”仍然拿奖励。

训练最关键的变化发生在回答预算。前 23 个 rollout 仅允许 64K token,11% 到 28% 的样本被截断并从损失中屏蔽。第 23 步后预算扩到 128K,截断率降到 0.1% 以下,奖励继续从 0.34 上升到 0.42。LiveCodeBench v6 的 pass@1 从 67.9 升到扩预算后的 75.9,pass@8 则从 85.1 升到 87.4。

代码强化学习奖励和 LiveCodeBench 曲线

图 4:64K 预算阶段已带来主要增益,扩到 128K 后截断几乎消失,pass@1 在第 33 步达到 75.9。

相邻检查点LiveCodeBench pass@1LiveCodeBench pass@8
Reasoning RL68.685.1
+ Coding RL75.987.4
阶段增益+7.3+2.3

pass@1 增益远大于 pass@8,说明代码强化学习主要让模型更稳定地一次做对,而不是拓宽本就不足的候选答案空间。论文也强调该表采用单阶段 n=8 协议,与最终总表的 LiveCodeBench 结果不能直接横向比较。

第四层:指令遵循只奖励必要约束

指令遵循阶段同时处理单轮多约束与多轮对话。团队合成 1.4 万条包含 2 到 6 个原子约束的单轮请求,每个约束都有 Python 检查函数;另合成 1.3 万段平均 6.1 轮的多轮对话,由教师模型扮演用户,多个开放模型轮流扮演助手,主动叠加、修改和干扰先前指令。两类数据共享同一套评分规则:每个必要约束单独判定,全部通过才给正奖励。

$$R_i=\mathbf{1}\left[\bigwedge_{j=1}^{m_i}c_{ij}=1\right]$$

这里 $m_i$ 是第 $i$ 个样本的必要约束数量,$c_{ij}$ 表示第 $j$ 个约束是否满足。关键设计是只把“必须满足”的条件列为评分项,不把“最好更长、更全面”之类可选偏好放进奖励。作者做过反向尝试:当每题加入约十个可选评分项后,模型立刻学会堆砌冗余内容来提高命中率,回答长度显著膨胀。

去除可选评分项后,最终回答从约 5.4K token 降到 3.6K,同时 IFEval、IFBench、Multi-challenge 和 AdvancedIF 全部上升。这个结果很有解释力:过得去的指令遵循并不等于写得更多,精确满足约束反而要求模型删掉无关内容。

指令遵循强化学习训练曲线

图 5:指令遵循奖励持续上升,最终回答长度从约 5.4K 降到 3.6K,说明模型在学习更精确而不是更冗长。

阶段结果非常集中:IFEval 从 90.5 到 94.5,IFBench 从 63.8 到 77.8,Multi-challenge 从 31.1 到 55.8,AdvancedIF 从 45.5 到 62.9。GPQA 同时上升 3.2,AIME 25 只下降 1.2,没有出现明显的推理能力交换。论文认为先做推理训练有助于复杂约束求解,因此“推理先于指令遵循”被保留为课程选择。

第五层:用环境状态训练通用智能体

通用智能体阶段建立在 AgentWorldModel 的 10K 个单服务器 MCP 任务上。每题连接一个合成数据库和约 35 个工具,工具调用会真实改变服务器状态,任务结束后由规则检查最终状态。正确性过滤保留教师或初始策略至少成功过一次的任务,难度过滤再移除当前策略太熟或完全不会的题,最后约剩 2K 题。

$$R_i=\mathbf{1}\left[\mathrm{poststate}_i\models\mathcal{C}_i\right]$$

$\mathrm{poststate}_i$ 是回合结束后的数据库状态,$\mathcal{C}_i$ 是任务成功条件。训练不使用步骤奖励,也不使用模型评审;中间过程好坏不会直接得分,只有最终状态是否满足约束产生二元信号。这种奖励比答案匹配更接近真实工具使用,但要求环境稳定、工具语义明确且终态可验证。

该阶段采用 GRPO 和 DAPO 式动态采样,丢弃全组成功或全组失败的提示。由于 MCP 服务端 I/O、数据库写入和奖励验证都在 CPU 上执行,每步 3072 条轨迹会形成明显瓶颈,因此 Rufus-Gym 把环境 actor 分发到不同节点。分布式 rollout 不是性能优化附带项,而是让状态型工具环境达到可用吞吐的必要条件。

通用智能体训练奖励和轨迹长度

图 6:通用智能体训练奖励与留出分数同步上升,轨迹长度从约 14K 增至约 16.5K token。

从指令遵循检查点出发,MCP-Atlas 从 34.95 升到 42.75,Tau2-Retail 从 74.00 升到 83.80;AIME 26、IFEval、GPQA 和 LiveCodeBench 也略有上升。论文将其解释为通用工具编排先验的迁移,而不是只在某个合成环境中记住了固定工具名。

第六层与第七层:代码智能体、搜索智能体

代码智能体只提供一个动作:在沙箱中执行任意 shell 命令。模型需要自己探索文件系统、修改代码、运行测试并从错误中恢复。任务采用 Harbor 统一格式,每题包含说明、Dockerfile 和测试脚本;环境预先快照,避免 rollout 时现场构建镜像。基础设施错误被标记为 aborted,不当作奖励为 0 的任务失败,从而避免非策略噪声污染组内优势。

这一阶段把 Terminal-Bench 2.1 从 38.76 提升到 40.17,把 SWE-bench Verified 从 65.60 提升到 67.80,但作者明确说明训练用尽可用算力即停止,并未收敛。更重要的是,SWE-bench 的增益没有保留到最终发布模型,最终仍为 65.6;Terminal-Bench 则继续升到 42.7。由于两题只在阶段结束和最终模型处测量,无法把后续变化归因给搜索或 RLHF 中的某一步。

搜索智能体处理开放网页而非固定工具集。它可使用搜索、网页抽取和隔离 Python 三类工具,训练最多 100 次工具调用,评测最多 200 次,整条轨迹预算为 128K token。数据先删掉无需工具即可答对的题,再去掉 8 次全错或全对的题,只保留能够提供有效组内差异的约 2200 个问题。

最终奖励由答案质量、工具调用门槛和错误调用比例共同决定。至少两次成功工具调用才可能获得正奖励;格式错误会按比例降低分数,最差降至 0.5;耗尽预算仍无最终答案则得到 -0.1。可以概括为:

$$R_i=s_i(1-0.5m_i)$$

其中 $s_i$ 是答案的评审分数,$m_i$ 是格式错误工具调用占比。因为评审本身带有噪声,团队没有使用标准差的组内归一化,而只减去组均值:

$$\widehat{A}_i=r_i-\frac{1}{G}\sum_{j=1}^{G}r_j,\qquad G=16$$

如果继续除以组奖励标准差,一个孤立的成功会把 1.0 的差距和 0.1 的评审差距都放大到相同优势,噪声也就被当成真实解题能力。论文的配对消融显示,均值优势组在每次匹配评测上均领先规范化版本。

搜索阶段带来 BrowseComp +3.0、Seal-0 +5.4、HLE-Verified +3.4。训练使用内部搜索引擎,评测使用不同标准化搜索栈,这使增益更像是搜索行为迁移,而不是利用了训练后端。

最后一层:把最容易被投机的奖励放到最后

RLHF 使用 Skywork-Reward-V2-Qwen3-8B 作为开放奖励模型,在过滤后的 75,815 条 HH-RLHF 提示上做在线强化学习。数据集中的偏好答案只用于离线分析,训练奖励来自当前策略回答经过奖励模型打分的结果。由于奖励是 Bradley-Terry 体系下的无界点分数,作者还加入线性长度惩罚,压低过长且原始奖励为正的回答。

RLHF 放在最后并非因为开放式质量最基础,而是因为模型奖励最容易被策略找到漏洞。若先优化这种信号,后续大量训练会长期放大偏差;放到最后可以把风险暴露压缩到一个阶段。最终 Arena-Hard v2 Hard Prompt 从 83.06 升到 89.05,Creative Writing 从 38.56 升到 52.97,其中创作写作提升 14.41,是整条配方最大的单项跨阶段增益之一。

不过创作写作仍是最终模型的弱项。公开 GLM-4.5-Air 为 60.3,Rufus-Air 为 53.0,说明用通用偏好奖励补足写作风格仍有明显上限。论文也承认没有专门为文风调优奖励模型。

基础设施:token 保真、沙箱与分布式环境

Rufus-Slime 负责 SFT 和一般强化学习,底层使用 Megatron-LM 训练、SGLang 采样。MoE 模型在 FP8 推理与 BF16 更新之间可能出现专家路由不一致,Rollout Routing Replay 缓存采样时的路由选择,并在训练前向中重放。大 rollout 批次、截断率监控和长序列分桶也属于训练配方,而不是可忽略的工程细节。

Rufus-Gym 把多轮环境统一成类似 gym 的接口:输入任务,输出完整 token 轨迹、奖励和带类型的终止原因。它不会每轮把消息重新渲染成文本再分词,而是直接把 SGLang 产生的 token ID、对数概率、损失掩码和专家路由传回训练器,从而避免重复分词、聊天模板变化和外部修复工具调用造成的策略偏差。文本记录只用于检查,token 轨迹才是训练事实来源。

代码轨迹需要持续保留工作目录、依赖和运行进程,因此系统为每条轨迹分配独立 Firecracker 微虚拟机,预初始化环境以快照方式恢复。E2B 运行时提供沙箱 API,Ray 把 CPU 密集的环境 actor 分散到集群。对不可重复的 shell 命令,只在能够证明命令尚未开始时重试;一旦可能已执行,就返回可恢复错误,防止重复写入和重复测试。

综合结果与如何正确阅读

主要指标公开 GLM-4.5-AirRufus-Air变化
IFBench33.676.9+43.3
IFEval83.095.4+12.4
LiveCodeBench v659.676.4+16.8
MCP-Atlas35.945.3+9.4
BrowseComp22.737.1+14.4
Seal-033.351.4+18.1
Terminal-Bench 2.124.742.7+18.0
SWE-bench Verified50.665.6+15.0

这组结果与训练信号的分布一致:配方在指令遵循、代码和智能体任务上投入最多阶段,提升也最明显;数学与知识主要由单个推理阶段处理,最终与同类模型接近而非全面领先。论文没有把每个指标都训练到饱和,也没有用“最终总分”掩盖阶段目标。

阶段目标指标阶段前阶段后
Reasoning RLGPQA68.1873.50
Coding RLLiveCodeBench pass@168.675.9
Instruction RLMulti-challenge31.155.8
General AgentTau2-Retail74.0083.80
Coding AgentSWE-bench Verified65.6067.80
Search AgentBrowseComp34.237.2
RLHFArena-Hard v2 CW38.5652.97

阅读这张表时必须保留协议差异。代码阶段使用单阶段 n=8 评测,最终总表可能采用另一套聚合;Tau2-Retail 阶段表使用 Claude Sonnet 4.5 用户模拟器,总表使用 Sonnet 5;搜索阶段内部结果与最终结果也可能因测试集版本或聚合方式略有不同。正确做法是观察相邻检查点的同协议差值,而不是把不同表中的数字任意拼接。

局限与独立判断

作者自述的首要局限是阶段顺序只证明“有效”,没有证明“最优”。八阶段顺序来自早期实验和算力约束,论文没有比较领域专家并行训练后再做多教师策略蒸馏等替代路线。因此“奖励越难验证越靠后”是一个有价值的设计原则,但仍不是经过完整消融的定律。

第二个明确局限是代码智能体按可用算力停止,而不是训练到收敛。SWE-bench 的阶段增益没有保留到最终检查点,说明后续参数更新可能覆盖该能力。由于没有一个统一基准贯穿全部阶段,某些最终变化只能归因到“中间所有阶段的组合”,不能礼貌地归给最后一阶段。

第三个限制来自搜索评审的噪声。即使用均值优势减轻放大效应,模型评审仍无法完全判断答案是否真的依赖检索证据。两个成功工具调用只是执行门槛,不能保证最终事实来自工具返回;论文用轨迹审计观察此类残余路径,但没有在奖励函数中彻底关闭。

从独立分析看,Rufus-Air 的可复现性应理解为“配方组件和方法描述足够详细”,而不是“任何人可一键复现”。SFT 单项使用 512 张 H200 训练约 13 天,代码智能体需要约一万并发沙箱、月成本约一万美元,搜索评测也会产生大量外部调用。数据虽公开,过滤、环境修补和内部后端仍需相当工程能力,这些成本应被算进复现边界。

论文内部还存在少量表格测量不一致,例如 IF RL 检查点在两个阶段表中分别记为 GPQA 71.1 与 73.36。作者解释了评测条件差异,但这提醒读者:这是一份工程报告,而不是所有变量都被严格控制的单一对照实验。其价值在于透明记录真实系统如何跑通,而不是提供小数点级的排行榜神话。

结论

Rufus-Air 最重要的贡献是把后训练从“选择一个 RL 算法”改写成一组相互依赖的系统决策。强 SFT 决定策略从哪里起步,可学习性过滤决定梯度来自哪些题,奖励可靠性决定阶段顺序,token 级轨迹与可恢复沙箱决定智能体训练能否稳定扩展。最终模型在多个开放权重模型对比中表现突出,但这些增益背后的方法比单个榜单分数更值得复用。

对机器人基础模型和多模态智能体团队而言,论文的启示同样直接:数据规模和奖励公式之外,必须把环境状态、工具执行、轨迹保真和失败类型纳入训练验证。只要环境不可靠,所谓智能体强化学习就会把基础设施噪声误当成策略错误;只要奖励可被投机,越长的训练只会更快放大偏差。

后训练的质量上限,不只由模型“学得多快”决定,更由我们能否把正确的经验、可验证的奖励和可信的环境连接成一条完整链路决定。

大语言模型后训练强化学习GLM-4.5-AirAgentLarge Language ModelsLLM后训练

原始链接

https://arxiv.org/abs/2609.29421

相关论文

LENS:面向动态原始文档的无索引上下文内搜索框架

LENS:面向动态原始文档的无索引上下文内搜索框架

阿里巴巴 ModelScope 团队把动态原始文档上的问答形式化为「预算约束下的证据定位」,提出无索引框架 LENS:低成本先验压缩搜索域,预算约束的 propose–observe–update 循环用 LLM 相关性 oracle 序贯收窄候选证据窗口,最后整合为可溯源证据集。受控 500 题评估中答案分与 ReAct 持平(62.4% vs 65.2% EM,p=0.1143),证据召回 84.8% vs 50.4% 领先 34.4pp、答案溯源率 96.8% vs 71.8%;零索引直查 15,517 个原始维基 shard 时两系统答案持平而 LENS 溯源更高(84.0% vs 70.7%)。语料扩充后复用旧索引的系统证据召回崩至 0–5.5%,LENS 仅降 0.8pp。

Xingjun Wang, Gongsheng Li, Qi Fan · 1283次阅读 · 2026年8月17日
大语言模型RAG
2026年8月17日
ScientistTwo:用自主 AI 开拓人类知识前沿

ScientistTwo:用自主 AI 开拓人类知识前沿

Google Cloud AI Research 的 ScientistTwo 是完全自主的多智能体科研框架:从人类最优方法的局限出发生成假设,子集先行验证后扩展全集,经进化式想法改进、消融驱动再精炼,以及闭环的模拟评审-反驳-元评审,端到端产出论文与可复现代码库。在 107 个 ICLR/ICML/NeurIPS 级研究难题上完成 86 个(80.4%),平均相对提升 25.2%,生成论文获 ScholarPeer 7.5 分、91.9% 通过率,并在独立评审下 72.1% 通过;单任务平均 2.5 天、3,765 美元。

Nam, Jaehyun, Yoon, Jinsung, Pan, Yanzhou · 1371次阅读 · 2026年9月17日
自主智能体AI Research
2026年9月17日
从专有 LLM API 窃取推理轨迹

从专有 LLM API 窃取推理轨迹

本文发现 Anthropic、OpenAI 和 Google 的加密推理块可在会话、用户与模型之间重放。攻击者把前沿模型产生的加密推理签名注入同一厂商的较弱模型,迫使后者把隐藏思维过程转录为明文,从而绕过反蒸馏机制、恢复公开轨迹中的密钥与个人信息、暴露隐藏有害推理,并执行不可见提示注入。论文解码 315320 个公开推理块,在真实用户会话中发现 62 个 API key 等敏感数据,并提出了上下文绑定、密钥轮换和训练侧拒绝转录等缓解方案。

Alexander Panfilov, David Schmotz, Ilia Shumailov · 701次阅读 · 2026年8月10日
大语言模型安全
2026年8月10日
LENS:面向规划的LLM引导环境简化

LENS:面向规划的LLM引导环境简化

LENS利用大语言模型引导环境简化,为机器人任务规划提供更高效的环境表示和推理基础。

Aileen Liao, Rachel Holladay, Dinesh Jayaraman · 491次阅读 · 2026年7月22日
大语言模型任务规划
2026年7月22日

作为亚马逊联盟会员,我们可能从符合条件的购买中获得佣金。