51c大模型~合集120

我自己的原文哦~      https://blog.51cto.com/whaosoft/13860194

#SRPO

业内首次! 全面复现DeepSeek-R1-Zero数学代码能力，训练步数仅需其1/10

OpenAI 的 o1 系列和 DeepSeek-R1 的成功充分证明，大规模强化学习已成为一种极为有效的方法，能够激发大型语言模型（LLM) 的复杂推理行为并显著提升其能力。

然而，这些推理模型的核心训练方法在其技术报告中仍然鲜有披露。近期社区的主要工作也仅局限于数学推理领域，使得跨领域泛化这一挑战依然未得到充分探索。此外，GRPO 训练过程中存在多项常见问题，如性能瓶颈、样本利用效率低下，以及在处理混合领域数据集时难以培养专业推理技能等，这些挑战使得强化学习方法的有效扩展变得更加复杂。

针对这些挑战，来自快手Kwaipilot团队的研究者提出了一种创新的强化学习框架——两阶段历史重采样策略优化（two-Staged history-Resampling Policy Optimization，SRPO），旨在从多个维度系统性地解决上述训练难题。他们对外发布了SRPO的技术报告，详细披露了该训练方法的技术细节，同时也开源了SRPO-Qwen-32B 模型。

论文标题：SRPO: A Cross-Domain Implementation of Large-Scale Reinforcement Learning on LLM

论文链接：https://arxiv.org/abs/2504.14286

模型开源地址：https://huggingface.co/Kwaipilot/SRPO-Qwen-32B

这是业界首个同时在数学和代码两个领域复现 DeepSeek-R1-Zero 性能的方法。通过使用与 DeepSeek 相同的基础模型 (Qwen2.5-32B) 和纯粹的强化学习训练，SRPO 成功在 AIME24 和 LiveCodeBench 基准测试中取得了优异成绩（AIME24 = 50、LiveCodeBench = 41.6），超越了 DeepSeek-R1-Zero-32B 的表现。

更值得注意的是，SRPO 仅需 R1-Zero 十分之一的训练步数就达到了这一水平。

SRPO AIME24 和 LiveCodeBench 表现，每项为 pass@1 的 32 次平均得分

方法概览

原始 GRPO 实现的挑战

在最开始的探索中，快手 Kwaipilot 团队使用过标准的 GRPO 算法（公式 1）直接进行训练：

公式 1：GRPO 优化目标

然而，在训练过程中，他们很快遇到了瓶颈，模型始终无法达到预期的 R1-Zero 性能水平。这些问题包括：

1. 数学与代码跨领域的优化冲突：数学问题很容易通过训练诱发较长且细致的推理轨迹（长 CoT），而代码数据这种倾向则弱很多。直接混合这两种类型的数据也会产生冲突，导致模型在两个领域中都表现欠佳。  
2. 相同的组奖励导致训练效率下降：GRPO 算法依赖于采样组内非零的奖励方差来计算优势。当一个组的 rollout 产生几乎相同的奖励值时，计算得到的优势会接近于零。当一个训练 batch 的大部分数据都表现出这种现象时，有效的梯度贡献会变得极小，大幅降低训练效率。
3. 过早的性能饱和：GRPO 训练在 benchmark 评测中较早遇到了性能瓶颈，奖励也遇到饱和平台期。这个问题一定程度上源于数据集的质量不足。当训练数据缺乏足够的复杂性或多样性，特别是简单的问题太多，模型会倾向于保守地维持其在较容易任务中的性能，难以得到解决挑战性问题所需的复杂、深入的推理能力。

阶段训练

为了解决数学和代码之间内在的响应长度冲突问题，快手 Kwaipilot 团队最终实现了一种两阶段训练范式：

• Stage 1 (Eliciting Reasoning Abilities)：初始训练阶段仅专注于具有挑战性的数学数据。此阶段的目标是充分激励模型的 test-time scaling，发展出反思性停顿、回溯行为和逐步分解等多种能力。
• Stage 2 (Skill Integration)：在此阶段，将代码数据引入到训练过程中。利用在阶段 1 中建立的推理基础，进一步提升代码能力，同时逐步强化程序性思维、递归和工具调用能力。

训练策略的比较分析

不同训练数据策略对响应长度的影响

Mixed Training：在数学和代码混合数据上训练的混合训练模型，在响应长度的增长方面表现出局限性，且基准测试性能较差。虽然数学问题会引发一些推理模式，但代码问题经常产生简短、直接的响应，主要集中于即时代码输出，而很少进行初步分析或规划。

Math-Only Training：仅使用数学数据进行训练能够稳定地增加回复长度，并在数学基准测试中表现出色。重要的是，这培养了强大的、能够很好地泛化的推理能力；当面对编程任务时，模型会尝试详细的、逐步的推理。观察到的行为包括在数学问题解决过程中细致的步骤检查和重新审视。这反映了数学数据激发推理能力的特征。

Code-Only Training：尽管在代码基准测试中的表现有所提高，但显式推理行为的发展甚微，并且实现响应长度的显著增加被证明是困难的。与纯数学训练相比，对代码和数学问题的响应都明显较短，代码任务的解决方案通常是直接生成的，缺乏实质性的逐步推理或初步分析。

Staged Training：快手 Kwaipilot 团队提出的两阶段训练在数学和编程领域均表现出优异的结果。该模型在解决数学问题时始终如一地生成详细的逐步推理模式，并在处理编程任务时生成结构化的推理模式。特别地，涌现出一些复杂的行为，例如模型自发地利用写代码来辅助数学推理。对这些响应模式的更详细分析将在后文中介绍。

History Resampling

快手 Kwaipilot 团队发现在训练的中后期阶段，batch 中近 50% 的采样组产生相同的奖励。这种情况通常发生在模型在较容易的问题上持续成功时，导致奖励的方差极小，梯度更新效果不佳。

在训练期间 batch 内近 50% 的优势函数值为零（蓝色线）

为了解决这种低效性并提高梯度信号的质量，他们引入了历史重采样（History Resampling）。在训练过程中，他们记录每个 epoch 内所有 rollout 奖励的结果。在一个 epoch 结束时，他们按如下方式重建下一个 epoch 的数据集：

• 过滤过于简单的样本：排除所有 rollout 都得到正确答案的样本，它们实际上没有为策略改进提供任何信息信号。
• 保留信息样本：保留结果多样（既有正确又有不正确）或结果全部不正确的样本。这些样本生成正向奖励方差，确保优势非零及梯度信号有效。此外，对于当前 epoch 中所有展开都不正确的困难样本，快手 Kwaipilot 团队也将其保留在数据集中。理由是，这些最初具有挑战性的一些问题，对于更新后的策略而言可能会变得相对容易，从而在后续的训练中产生有效梯度。这种策略的根本思想与课程学习相一致，即逐步将模型暴露于平均而言更具挑战性的样本，以提高训练效率。

Training statistics of History Resampling

与 DAPO 中提出的 Dynamic Sampling 方法相比，History Resampling 显著提高了计算效率，响应长度增长也更加稳定。

数据 

快手 Kwaipilot 团队对社区开源的 Code&Math 数据进行了数据清洗和筛选，通过启发式规则对原始数据进行过滤，清理题目文本中无关的 URL、格式噪声等，确保核心字段（问题和答案真值）完整。参考 PRIME 对数学数据的清洗方法，剔除一题多问、纯证明题、需要图像或表格理解的题目。针对代码数据，剔除依赖特定环境、需要文件 IO 或网络交互的题目，专注于算法逻辑。

在数据入库前，对数学和代码题目进行正确性校验，确保答案的正确性和可解性，剔除答案错误或存在歧义的题目；然后判断题目难度，结合通过率（Pass@k）将题目细分为简单、中等、困难三个等级。

实验结果

本节详细介绍使用 SRPO 方法的实验结果。快手 Kwaipilot 团队重点观测了训练过程中奖励的变化情况以及响应长度等指标。

训练过程

SRPO 的动态训练

上图展示了 SRPO 的训练完整奖励曲线和响应长度曲线。在奖励增长开始趋于平稳后，整体进入了第 2 阶段的训练。在第 2 阶段开始时，由于模型之前未训练编码能力，总体奖励下降，后续训练导致奖励稳步增加。在整合编码数据后，响应长度并没有显著增加，这与他们的预期一致。同时，基准测试结果表明，该模型的数学和编码能力都有持续和稳定的提高，证明了新方法的有效性。

具体来说，History Resampling 确保了在每个训练步骤中梯度更新始终有效，从而直接提高了信息梯度的比例。这种提升的采样效率带来了稳定的奖励增长，清晰地展现了重采样策略所实现的训练效率提升。

思维行为

快手 Kwaipilot 团队识别出了三种代表性的反思模式。这些模式包括 recheck、hesitation、exploration。他们对包含这种模式的响应进行统计，并记录这几种模式的平均响应长度。在 RL 训练过程中，他们观察到模型的自我反思、纠正和回溯频率逐渐增加。这表明模型展现了「自我验证」能力。他们认为模型在RL中涌现出类似人类认知过程的「反思」，是模型在策略优化过程中的适应性行为。

在训练过程中不同的 aha 模式出现的频次变化

如上图所示，在模型训练的早期阶段，模型几乎没有主动检查和反思先前推理步骤。然而，随着训练的进行，模型表现出明显的反思和回溯行为，形成如逐步推理、数值替换、逐一验证和自我优化等响应模式。

自我校正的例子

数值替换（绿色）和逐个验证（红色）

自我优化

同时，他们还发现了有趣的现象：模型在解决数学问题时，学会了自发使用程序代码进行验证。它首先通过数学推理给出解题过程，随后主动编写程序代码验证方案的正确性。这类案例体现了模型会借助程序性思维进行自我纠错和多次尝试。这一现象也进一步表明，在训练后期，模型已经掌握了广泛思考和综合运用多种代码思维进行问题求解的能力。

结论与展望

本文介绍了 SRPO，这是首个在数学与代码领域成功复现 DeepSeek-R1-Zero-Qwen-32B 的工作。快手 Kwaipilot 团队提出了一种创新的两阶段训练范式，利用训练过程中的历史重采样策略，同时设计了专为数学与代码联合强化学习（RL）训练定制的数据整理流程（pipeline）。这些方法为社区构建更强大的推理模型提供了重要参考。未来，团队将继续探索更大规模的数据与模型、更加高效的强化学习算法，以及其在更广泛推理场景中的应用潜力。

#仅用3周时间，就打造出Manus开源平替

AI 不再仅仅是一个工具，而是开始成为一个真正的队友。

可以对标 Manus 的智能体 Suna 来了！（有没有发现它是 manus 倒过来写）

这款智能体由 Kortix AI 团队打造，开源并且完全免费。

具体而言，Suna 是一个完全开源的 AI 助手，旨在帮助用户轻松完成现实世界中的各种任务。

使用起来也非常简单，通过自然语言对话的方式就可以让它帮你干活，比如辅助你完成各种研究、进行数据分析以及日常事务。

，时长02:27

Kortix CEO Marko 表示他们仅用了 3 周时间就打造出了 Suna

体验地址：https://www.suna.so/

此外，Suna 还集成了强大的工具集，包括用于网页浏览与数据提取的浏览器自动化、文档创建与编辑的文件管理功能、网页爬取与增强的搜索能力、网站部署功能，以及与多种 API 和服务集成的能力。

这些功能高度协同，使得 Suna 能够通过简单对话解决复杂问题，并实现各类工作流程的自动化！

既然免费用，也上手体验了一下，提示词为：「帮我整理一份世界各地的咖啡品牌。」

Suna 先进行了规划，并按国家或地区进行了整理。

然后，Suna 根据待办事项，使用网络搜索来收集不同地区咖啡品牌的全面信息，期间它会搜索各种网页内容。

最后，Suna 把所有这些信息整理成一份关于世界各地咖啡品牌的综合文档，并按地区对咖啡品牌进行了分类。

除了亲自体验外，官方也放出了很多 demo。

首先让它分析一下美国股市。

用户只需输入一句话：「就过去两周美国股市发生的情况给我写一份详细报告。分析标准普尔 500 指数的走势，并告诉我市场对未来几周的预期，这份报告是为银行首席财务官撰写的分析报告。」

只见 Suna 边思考边输出，中间执行了大约一分钟，完整的可读报告就出来了：

，时长01:17

接着，考验 Suna 对网站内容的分析能力。

输入提示：「访问 Crunchbase、Dealroom 和 TechCrunch，根据 SaaS 金融领域的 A 轮融资情况进行筛选，并为对外销售建立一份包含公司数据、创始人和联系信息的报告。」

同样的，Suna 出色的完成了任务。

，时长01:13

我们再看一个示例：「请帮我研究一下 B2C 人工智能市场，并向我展示一些你发现的有趣数据图表，请使用浏览器浏览网页。」

，时长01:29

各种展示看下来，Suna 真的是一位出色的 AI 助手。

目前，该项目刚上线没多久，星标量快速上涨。

项目地址：https://github.com/kortix-ai/suna

根据项目介绍，Suna 由四个主要组件构成：

1. 后端 API：基于 Python/FastAPI 的服务，负责处理 REST 端点、线程管理以及通过 LiteLLM 与 OpenAI、Anthropic 等大语言模型（LLM）的集成。
2. 前端：使用 Next.js/React 构建的应用程序，提供响应式用户界面，包括聊天界面、仪表板等。
3. Agent Docker：每个智能体的隔离执行环境，具备浏览器自动化、代码解释器、文件系统访问、工具集成以及安全功能。
4. Supabase 数据库：负责数据持久化，包括用户认证、用户管理、对话历史、文件存储、智能体状态、分析以及实时订阅等功能。

最后，根据公开资料显示，Kortix 成立于 2024 年，首席执行官是 Marko O. Kraemer。这家公司专注于开发 AI Agents，旨在通过自然对话完成现实世界的复杂任务。

#Cooragent

清华LeapLab开源框架：一句话构建您的本地智能体服务群

本文由清华黄高教授团队完成，第一作者王政是清华 MEM 工程管理硕士，SeamLessAI 创始人，曾任爱奇艺虚拟机云平台负责人，小红书商业化算法工程团队负责人。

刚刚，清华大模型团队 LeapLab 发布了一款面向 Agent 协作的开源框架：Cooragent。

你只需要说一句「咒语」：「创建一个 AI 情报收集秘书，为我收集最新的 AI 进展。」

魔法就会产生，Cooragent 就会根据你的个人偏好生成你专属的 AI 情报收集秘书，每天自动浏览网页，收集最重要的情报，总结成你喜欢的图文文档发送给你。

更有趣的是你创造的智能体之间自动组合，创造出无限可能。当然，你还可以将你的智能体发布到社区中，与其他人共享。

，时长00:50

• 项目链接：https://github.com/LeapLabTHU/cooragent

与人协同的 AGI

Cooragent 实际上成为了智能体落地的「最后一公里」。虽然智能体技术层出不穷，但是对于大众来说，智能体的使用门槛依然很高，很难落地。

拿写作智能体为例，通用的写作智能体很难满足不同人的个性化需求，而定制化的智能体开发流程又过于复杂，导致智能体很难落地到每个人的生活和工作中。

Cooragent 通过对话生成可协作的智能体，其本质一种可编辑的 AGI - 即让智能体通过 AGI 的方式产生，但同时可以随时保持其可编辑性，与人协作，让智能体真正落地到每个人的生活和工作中。

从 Agent 技术层面来看，Cooragent 是一个基于 Agent 的协作框架。通过动态上下文理解与自主归纳能力，Cooragent 彻底摒弃了传统 Agent 框架对人工设计 Prompt 的依赖。

系统利用深度记忆扩展和实时环境分析，自动生成高精度任务指令，显著降低使用门槛并提升智能体的适应性。它允许你通过一句话创建一个具备强大功能的智能体，并与其他智能体协作完成复杂任务。

无限可能

Cooragent 由两种工作模式：Agent Factory 和 Agent Workflow。

Agent Factory 模式下，你只需要你对智能体做出描述，Cooragent 就会根据你的需求生成一个智能体，系统的会自动分析用户需求，通过记忆和扩展深入理解用户，省去纷繁复杂的 Prompt 设计。Planner 会在深入理解用户需求的基础上，挑选合适的工具，自动打磨 Prompt，逐步完成智能体构建。智能体构建完成后，可以立即投入使用，但你仍然可以对智能体进行编辑，优化其行为和功能。

Agent Workflow 模式下你只需要描述你想要完成的目标任务，Cooragent 会自动分析任务的需求，挑选合适的智能体进行协作。Planner 根据各个智能体擅长的领域，对其进行组合并规划任务步骤和完成顺序，随后交由任务分发节点 publish 发布任务。各个智能领取自身任务，并协作完成任务。

Cooragent 可以在两种模式下不断演进，从而创造出无限可能。

Prompt-Free 设计

Prompt 本身越来越成为一种负担。Prompt 设计需要考虑的因素太多，用户很难在短时间设计出合适的 Prompt。Cooragent 采用 Prompt-Free设计，通过 Agent 的协作，深入理解上下文，自主归纳环境因素，自动生成 Prompt，从而省去 Prompt 设计。

MIT License 和本地部署

Cooragent 坚信开放与安全的力量，因此我们选择采用极其宽松且商业友好的 MIT License 进行开源。这种彻底的开放性旨在最大限度地降低使用门槛，并激励社区成员共同参与创新与贡献，共建繁荣的智能体生态。

更重要的是，Cooragent 提供了一键本地部署的能力。用户可以通过极其简单的步骤，在自己的个人电脑或私有服务器上快速部署和运行整个系统。这不仅极大地简化了安装配置过程，让用户能够迅速上手体验，更从根本上解决了数据安全和隐私的顾虑。

通过本地部署，用户所有数据——包括智能体配置、交互历史、处理内容等——都将完全保留在您自己的设备上，用户对自己的数据拥有绝对的控制权，无需担心数据泄露或被第三方平台滥用的风险。

快速安装

# 克隆仓库
git clone https://github.com/SeamLessAI-Inc/cooragent
cd cooragent


# 用uv创建并激活虚拟环境
uv python install 3.12
uv venv --python 3.12


source .venv/bin/activate  # Windows系统使用: .venv\Scripts\activate
uv run src/service/app.py   
# 安装依赖
uv sync


# 配置环境
cp .env.example .env
# 编辑 .env 文件，填入你的 API 密钥


# 运行项目
uv run cli.py

开发者友好【Cli + MCP】

Cooragent 提供了一系列开发者工具，帮助开发者快速构建智能体。通过 CLI 工具，开发者可以快速创建，编辑，删除智能体。CLI 的设计注重效率和易用性，大幅减少了手动操作的繁琐，让开发者能更专注于智能体本身的设计与优化。

通过 MCP 工具，开发者可以快速链接 MCP 社区，获取最新的工具。开发者可以浏览和获取由官方或社区贡献的预构建智能体模板、功能组件、工具插件、数据集或优化过的模型，将自己开发的优秀智能体、工具或组件发布到 MCP，与其他开发者共享，共同建设生态。

首个Agent 与人共同参与的社区

Cooragent 不仅仅是一个强大的智能体构建和协作框架，它更开创性地提出了一个全新的社区概念：一个人与 Agent 共同参与、互动、贡献的生态系统。这超越了传统开发者社区仅限于人际交流的模式，将智能体本身也视为社区的一等成员。

这种「人机共融」的社区模式打破了传统软件生态的边界。它不仅加速了知识的创造和传播，激发了前所未有的协作模式，更让智能体真正「活」了起来，从单纯的工具转变为社区中积极的参与者和贡献者。Cooragent 致力于构建这样一个充满活力、互相赋能的未来社区，让人类和他们创造的智能体共同塑造一个更加智能、高效的世界。

一起看看 Cooragent 的神奇之处

让我们通过几个例子来一起看看 Cooragent 的神奇之处。

构建我的漫画工作室

「咒语」：构建一个漫画师和一个剧本创作师，让他们协作完成一个漫画：一个小男孩在森林里迷路，遇到了一只小狗，他们一起努力走出森林。

，时长01:17

构建我的AI情报秘书

「咒语」: 为我创建一个AI 前沿科技追踪秘书，整理 AI 前沿科技信息，形成文字和图表汇报给我。

，时长00:31

使用 Cli 工具

进入 cooragent 命令工具界面

python cli.py

一句话创建小米股票分析智能体

run -t agent_workflow -m '创建一个股票分析专家 agent，分析过去一个月的小米股票走势，并预测下个交易日的股价走势，并给出买入或卖出的建议。'

使用一组智能体协作完成复杂任务

run -t agent_workflow -m '综合运用任务规划智能体，爬虫智能体，代码运行智能体，浏览器操作智能体，报告撰写智能体，文件操作智能体为我规划一个 2025 年五一期间去云南旅游的行程。首先运行爬虫智能体爬取云南旅游的景点信息，并使用浏览器操作智能体浏览景点信息，选取最值得去的 10 个景点。然后规划一个 5 天的旅游的行程，使用报告撰写智能体生成一份旅游报告，最后使用文件操作智能体将报告保存为 pdf 文件。'

面向私有化的架构设计

Cooragent 从一开始就将数据主权和部署灵活性作为核心设计原则。我们深知，对于许多企业和个人用户而言，能够完全掌控自己的数据、在私有环境中安全运行是至关重要的。因此，Cooragent 的整体架构都围绕着「私有化优先」的理念进行构建。

• 核心引擎本地运行： Cooragent 的核心调度、任务规划、Agent 管理和执行引擎均设计为在用户本地环境（个人电脑、私有服务器或内部网络）运行。它不强制依赖任何外部云服务来执行其基本功能，确保了操作的独立性和自主性。
• 数据不出域：所有的用户数据，包括但不限于：

• 智能体的配置和定义

• 用户与智能体的交互历史和日志
• 智能体处理和生成的内容
• 连接的本地工具或数据源信息

全面的兼容性

Cooragent 在设计上追求极致的开放性和兼容性，确保能够无缝融入现有的 AI 开发生态，并为开发者提供最大的灵活性。这主要体现在对 Langchain 工具链的深度兼容、对 MCP (Model Context Protocol) 协议的支持以及全面的 API 调用能力上。

• 深度兼容 Langchain 工具链:

• 可以在 Cooragent 的智能体或工作流中直接使用熟悉的 Langchain 组件，如特定的 Prompts、Chains、Memory 模块、Document Loaders、Text Splitters 以及 Vector Stores 等。这使得开发者可以充分利用 Langchain 社区积累的丰富资源和既有代码。
• 平滑迁移与整合: 如果您已经有基于 Langchain 开发的应用或组件，可以更轻松地将其迁移或整合到 Cooragent 框架中，利用 Cooragent 提供的协作、调度和管理能力对其进行增强。
• 超越基础兼容: Cooragent 不仅兼容 Langchain，更在其基础上提供了如 Agent Factory、Agent Workflow、原生 A2A 通信等高级特性，旨在提供更强大、更易用的智能体构建和协作体验。您可以将 Langchain 作为强大的工具库，在 Cooragent 的框架内发挥其作用。

• 支持 MCP (Model Context Protocol):

• 标准化交互: MCP 定义了一套规范，用于智能体之间传递信息、状态和上下文，使得不同来源、不同开发者构建的智能体能够更容易地理解彼此并进行协作。
• 高效上下文管理: 通过 MCP，可以更有效地管理和传递跨多个智能体或多轮交互的上下文信息，减少信息丢失，提高复杂任务的处理效率。
• 增强互操作性: 对 MCP 的支持使得 Cooragent 能够更好地与其他遵循该协议的系统或平台进行互操作，构建更广泛、更强大的智能生态系统。

• 全面的 API 调用支持:

• Cooragent 的核心功能几乎都通过全面的 API (RESTful API) 暴露出来，为开发者提供了强大的编程控制能力。
• 程序化管理: 通过 API 调用，您可以自动化智能体的创建、部署、配置更新、启动/停止等全生命周期管理。
• 任务集成: 将 Cooragent 的任务提交和结果获取能力集成到您自己的应用程序、脚本或工作流引擎中。
• 状态监控与日志: 通过 API 获取智能体的实时运行状态、性能指标和详细日志，方便监控和调试。
• 构建自定义界面: 利用 API，您可以为 Cooragent 构建自定义的前端用户界面或管理后台，满足特定的业务需求和用户体验。

#FAR

迈向长上下文视频生成！NUS团队新作FAR同时实现短视频和长视频预测SOTA

本文由 NUS ShowLab 主导完成。第一作者顾宇超为新加坡国立大学 ShowLab@NUS 在读博士生，研究方向是视觉生成，在 CVPR、ICCV、NeurIPS 等国际顶级会议与期刊上发表多篇研究成果。第二作者毛维嘉为新加坡国立大学 ShowLab@NUS 二博士生，研究方向是多模态理解和生成，项目负责作者为该校校长青年教授寿政。

• 论文标题：Long-Context Autoregressive Video Modeling with Next-Frame Prediction
• 论文链接：https://arxiv.org/abs/2503.19325
• 项目主页：https://farlongctx.github.io/
• 开源代码：https://github.com/showlab/FAR

背景：长上下文视频生成的挑战

目前的视频生成技术大多是在短视频数据上训练，推理时则通过滑动窗口等策略，逐步扩展生成的视频长度。然而，这种方式无法充分利用视频的长时上下文信息，容易导致生成内容在时序上出现潜在的不一致性。

解决这一问题的关键在于：高效地对长视频进行训练。但传统的自回归视频建模面临严重的计算挑战 —— 随着视频长度的增加，token 数量呈爆炸式增长。 视觉 token 相较于语言 token 更为冗余，使得长下文视频生成比长上下文语言生成更为困难。

本文针对这一核心挑战，首次系统性地研究了如何高效建模长上下文视频生成，并提出了相应的解决方案。

我们特别区分了两个关键概念：

• 长视频生成：目标是生成较长的视频，但不一定要求模型持续利用已生成的内容，因此缺乏长时序的一致性。这类方法通常仍在短视频上训练，通过滑动窗口等方式延长生成长度。
• 长上下文视频生成：不仅要求视频更长，还要持续利用历史上下文信息，确保长时序一致性。这类方法需要在长视频数据上进行训练，对视频生成建模能力提出更高要求。

长上下文视频生成的重要性：

最近的工作 Genie2 [1] 将视频生成用于 world modeling /game simulation 的场景中，展现出非常令人惊艳的潜力。然而，现有基于滑窗的生成方法通常缺乏记忆机制，无法有效理解、记住并重用在 3D 环境中探索过的信息，比如 OASIS [2]。这种缺乏记忆性的建模方式，不仅影响生成效果，还可能导致对物理规律建模能力的缺失。这可能正是当前长视频生成中常出现非物理现象的原因之一：模型本身并未在大量长视频上训练，i2v（image-to-video）+ 滑动窗口的方式难以确保全局合理性。

FAR 的创新设计与分析

1）帧自回归模型（FAR）

FAR 将视频生成任务重新定义为基于已有上下文逐帧（图像）生成的过程。为解决混合自回归与扩散模型在训练与测试阶段存在的上下文不一致问题，我们在训练过程中随机引入干净的上下文信息，从而提升模型测试时对利用干净上下文的稳定性。

FAR 的训练测试流程；测试时对干净上下文的生成结果。

2) 长短时上下文建模

我们观察到，随着上下文帧数量的增加，视频生成中会出现视觉 token 数量急剧增长的问题。然而，视觉 token 在时序上具有局部性：对于当前解码帧，其邻近帧需要更细粒度的时序交互，而远离的帧通常仅需作为记忆存在，无需深入的时序交互。基于这一观察，我们提出了 长短时上下文建模。该机制采用非对称的 patchify 策略：短时上下文保留原有的 patchify 策略，以保证细粒度交互；而长时上下文则进行更为激进的 patchify，减少 token 数量，从而在保证计算效率的同时，维持时序模拟的质量。

FAR 的长视频训练测试流程

长短时上下文的非对称 patchify 带来的 token 减少以及训练效率提升

3) 用于长上下文视频生成的多层 KV Cache 机制

针对长短时上下文的非对称 patchify 策略，我们提出了相应的多层 KV-Cache 机制。在自回归解码过程中，当某一帧刚离开短时上下文窗口时，我们将其编码为低粒度的 L2 Cache（少量 token）；同时，更新仍处于短时窗口内帧的 L1 Cache（常规 token）。最终，我们结合这两级 KV Cache，用于当前帧的生成过程。

值得强调的是，多层 KV Cache 与扩散模型中常用的 Timestep Cache 是互补的：前者沿时间序列方向缓存 KV 信息，后者则在扩散时间步维度上进行缓存，共同提升生成效率。

针对长短时上下文策略的多层 KV Cache

长视频生成的效率提升

FAR 相对于 SORA 类 VideoDiT 的潜在优势

1）收敛效率：在相同的连续潜空间上进行实验时，我们发现 FAR 相较于 Video DiT 展现出更快的收敛速度以及更优的短视频生成性能。           

FAR 与 Video DiT 的收敛对比

2）无需额外的 I2V 微调：FAR 无需针对图像到视频（I2V）任务进行额外微调，即可同时建模视频生成与图像到视频的预测任务，并在两者上均达到 SOTA 水平。

条件 / 非条件视频生成的评测结果

基于条件帧的视频预测的评测结果

3）高效的长视频训练与长上下文建模能力：FAR 支持高效的长视频训练以及对长上下文建模。在基于 DMLab 的受控环境中进行实验时，我们观察到模型对已观测的 3D 环境具有出色的记忆能力，在后续帧预测任务中首次实现了近乎完美的长期记忆效果。

总结

我们首次系统性地验证了长上下文建模在视频生成中的重要性，并提出了一个基于长短时上下文的帧自回归模型 ——FAR。FAR 不仅在短视频生成任务中，相较于 Video DiT 展现出更快的收敛速度与更优性能，同时也在长视频的 world modeling 场景中，首次实现了显著的长时序一致性。此外，FAR 有效降低了长视频生成的训练成本。在当前文本数据趋于枯竭的背景下，FAR 为高效利用现有海量长视频数据进行生成式建模，提供了一条具有潜力的全新路径。

参考文献：

【1】Genie 2: https://deepmind.google/discover/blog/genie-2-a-large-scale-foundation-world-model/

【2】Oasis: https://oasis-model.github.io/

#Dia-1.6B

一天拿下3.4k star，这个1.6B开源模型火了，合成对话超逼真

如果不提前告诉你，你可能很难相信这段视频里的语音全部是 AI 生成的：

，时长00:34

这些声音来自 Dia-1.6B——一个刚刚在 𝕏、GitHub 等平台上走红的开源语音模型。它不仅能生成说话的声音、对话，同时也能合成真实感非常强的笑声、喷嚏声和吸鼻子声等表达情绪的声音。

由于效果过于逼真，它在 GitHub 上线后不到 24 小时就收获了超过 3.4k star，现在的 star 数更是已经达到了 5.4k。同时，Dia-1.6B 也是目前 Hugging Face 上热度第二的模型，目前已经被下载了超过 5600 次。

• GitHub：https://github.com/nari-labs/dia/
• Hugging Face: https://huggingface.co/nari-labs/Dia-1.6B
• 试用地址：https://huggingface.co/spaces/nari-labs/Dia-1.6B

在和 ElevenLabs Studio、Sesame CSM-1B 等之前以逼真著称的模型对比之后，Dia-1.6B 依然有着明显的优势，尤其是在情绪表达方面。

Dia-1.6B 生成结果：

Dia-1.6B,,7秒

 ElevenLabs Studio 生成结果：

ElevenLabs Studio,,11秒

 Sesame CSM-1B 生成结果：

Sesame CSM-1B,10秒

表现如此之好，自然也是收获好评无数：

也做了一些简单的尝试，下面是一个示例

Dia-1.6B cat,11秒

整体来说，Dia-1.6B 在合成简单英语对话方面确实表现卓越，但却并不能很好地理解用户通过括号标注的指令，偶尔会出现类似电流的杂音。

Dia 模型细节

Dia 来自 Nari Labs，是一个 1.6B 参数量的文本转语音模型。

Dia 可以直接基于文字生成高真实感的对话。用户可以对输出的音频进行调整，从而控制其情绪和语调。同时，模型还可以生成非语言的交流声音，例如笑声、咳嗽声、吸鼻子声等。

并且 Nari Labs 开源发布了 Dia，使用了 Apache License 2.0 证书。该团队表示：「为了加速研究，我们提供了预训练模型检查点和推理代码的访问权限。模型权重托管在 Hugging Face 上。」

不过遗憾的是，目前该模型仅支持英语生成。

硬件和推理加速

目前 Nari Labs 并未发布 Dia 模型的详细技术报告，但我们可以在其 Hugging Face 页面看到些许有关硬件和推理加速的技术细节。

该团队表示，Dia 目前仅在 GPU 上进行过测试（Pytorch 2.0+，CUDA 12.6）。CPU 支持也即将添加。并且由于需要下载 Descript Audio Codec，初始运行会需要更长时间。

在企业级 GPU 上，Dia 可以实时生成音频。在较旧的 GPU 上，推理会更慢。作为参考，在 A4000 GPU 上，Dia 大约每秒生成 40 个 token（86 个 token 相当于 1 秒的音频）。torch.compile 将提高受支持 GPU 的速度。

Dia 的完整版本需要大约 10GB 的显存才能运行。不过该团队承诺未来会放出一些量化版本。

Dia 还有更大规模的版本。在 Nari Labs 的 Discord 中，开发者 Toby Kim 表示更大的模型还处于规划阶段。感兴趣的用户可以通过这个链接加入等待列表：https://tally.so/r/meokbo

另外，Toby Kim 还指出目前最长能稳定生成大约 25 秒的音频，但用户也可以基于之前的生成结果来生成更长的音频。

Nari Labs 简介

Nari Labs 的 Hugging Face 页面透露，Nari 是一个源自韩语的词（나리），意为百合。

据介绍，Nari Labs 是一个非常小的团队，目前仅有一位全职研究工程师和一位兼职研究工程师。他们的 GitHub 账户也是四天前才刚注册的。

其中一位开发者 Toby Kim 在 𝕏 上表示，这两位工程师目前都还是本科生。而他们的目标是「构建一个可以与 NotebookLM Podcast、ElevenLabs Studio 和 Sesame CSM 相媲美的 TTS 模型。」

目前看来，他们已经取得了初步的成功。Toby Kim 表示这项成功耗时三个月时间，而这个过程中他们遇到的最大阻碍是计算不足。

接下来，他们计划将 Dia 做成一个 B2C 应用，可以生成有趣的对话和混音内容。

#OpenAI图像生成模型API发布

Token计价，一张图花掉1.4元

上个月，OpenAI 在 ChatGPT 中引入了图像生成功能，广受欢迎：仅在第一周，全球就有超过 1.3 亿用户创建了超过 7 亿张图片。

就在刚刚，OpenAI 又宣布了一个好消息：他们正式在 API 中推出驱动 ChatGPT 多模态体验的原生模型 ——gpt-image-1，让开发者和企业能够轻松将高质量、专业级的图像生成功能直接集成到自己的工具和平台中。

这也意味着，从今天开始，全世界的开发人员都可以使用 ChatGPT 强大的图像生成功能了。

API 指南：https://platform.openai.com/docs/guides/image-generation?image-generation-model=gpt-image-1

gpt-image-1 具有以下特点：

• 生成更准确，更高保真图像；
• 多样的视觉风格；
• 精确的图像编辑；
• 丰富的世界知识；
• 一致的文本呈现。

OpenAI CEO 奥特曼表示：API 版本与 ChatGPT 版本有一些不同：主要表现在用户可以使用 moderation 参数控制审核敏感度。还可以控制质量与生成速度、背景、输出格式等。

在价格方面，gpt-image-1 按 token 定价，文本和图像 token 的定价不同：

• 文本输入 token（提示文本）：每 100 万 token 5 美元
• 图像输入 token（输入图像）：每 100 万 token 10 美元
• 图像输出 token（生成的图像）：每 100 万 token 40 美元

在实际使用中，这意味着用户生成低质量、中质量和高质量的方形图像，分别需要花费约 0.02 美元、0.07 美元和 0.19 美元，再加上文本输入价格，只能说这很 OpenAI。

API 可以带来一系列好处，比如用户可以在单个请求中一次生成多张图像，但需要先设置 n 参数，默认情况下，API 返回单张图片。（感觉 token 使用量在燃烧。）

用户还可以将一张或多张图像作为参考图像来生成新图。在本例中使用 4 张输入图片来生成一张新的图片。

还可以使用蒙版进行图片编辑：

OpenAI 表示，现在已经有多家企业和初创公司将该模型用于创意项目、产品和体验。例如，多媒体巨头 Adobe 旗下的 Firefly 和 Express 应用，将集成 OpenAI 的图像生成功能。

AI 视频生成平台 HeyGen 正在集成 gpt-image-1 来增强虚拟形象的创建，特别是改进平台内的虚拟形象编辑功能。

大家可以参考官方 API 指南，了解更多内容。

参考链接：https://openai.com/index/image-generation-api/

#SLAM3R

北大陈宝权团队等只用单目长视频就能实时重建高质量的三维稠密点云

北京大学陈宝权团队和香港大学等高校及业界机构联合推出实时三维重建系统 SLAM3R，首次实现从长视频（单目 RGB 序列）中实时且高质量地重建场景的稠密点云。SLAM3R 使用消费级显卡（如 4090D）即可达到 20+ FPS 的性能，重建点云的准确度和完整度达到当前最先进水平，同时兼顾了运行效率和重建质量。该研究成果被 CVPR 2025 接收为 Highlight 论文，并在第四届中国三维视觉大会（China3DV 2025）上被评选为年度最佳论文，合作者为董思言博士（共同一作）、王书哲博士、尹英达博士、杨言超助理教授和樊庆楠博士，第一作者为北京大学本科生刘宇政。

• 论文标题：SLAM3R: Real-Time Dense Scene Reconstruction from Monocular RGB Videos
• 论文地址：https://arxiv.org/pdf/2412.09401
• 代码地址：https://github.com/PKU-VCL-3DV/SLAM3R

，时长00:22

SLAM3R 的交互界面（视频经过加速）。用户只需使用普通手机摄像头拍摄 RGB 视频，即可通过部署于服务器的 SLAM3R 系统实时重建出高质量的场景稠密点云，将二维视频转化为"可交互"、"可编辑"的三维世界。

在计算机视觉与机器人感知领域，基于单目摄像头的高质量三维环境感知与重建一直是个极具挑战性的课题——这主要是因为需要从有限的二维观测中恢复在相机投影过程中丢失的三维空间信息。过去的三十年间，研究者们建立了较为完善的多视角几何理论和计算框架，通常依赖多种算法的集成，包括运动恢复结构（Structure-from-Motion，简称 SfM）、同时定位和地图构建（Simultaneous Localization and Mapping，简称 SLAM）以及多视角立体视觉（Multi-View Stereo，简称 MVS）等。

由于拥有扎实的数学原理和优化算法作为"护城河"，三维重建领域较少受到神经网络等深度学习方法的"入侵"。在传统方法中，神经网络主要作为算法流程的辅助模块，用于提升特征匹配的鲁棒性和深度估计的完整性。近年来，随着以 DUSt3R 为代表的大型神经网络模型出现，这一传统范式正在改变：通过端到端的前馈神经网络，可以直接从多视角 RGB 图像预测三维几何，避免了传统方法中迭代优化所带来的效率瓶颈。

SLAM3R（发音：/slæmər/）进一步革新了这一范式的演进，首次将大模型应用于长视频序列的稠密重建任务。该方案通过前馈神经网络，将局部多视角三维重建与全局增量式坐标配准无缝集成，为基于单目 RGB 视频输入的稠密点云重建提供了高效率解决方案，无需迭代优化相机参数或三维点云。实验结果表面，SLAM3R 不仅在多个数据集上展现出最先进的重建质量，还能在消费级显卡上保持 20+ FPS 的实时性能。更为重要的是，SLAM3R 的成功展示了纯数据驱动的方法在长视频序列三维几何感知任务中的潜力，为未来重建系统的研究提供了新思路。

，时长00:13

SLAM3R 渐进式重建过程展示。输入 RGB 图像序列（如左上图所示）后，SLAM3R 首先进行局部多视角三维重建（左下图），然后执行全局增量式坐标配准（右图），从而逐步构建完整场景的点云模型。

三位一体的挑战：准确、完整、高效

基于多视角几何理论的传统方法通常将三维重建分为两个阶段：首先通过 SLAM 或 SfM 算法估计相机参数和场景结构，然后使用 MVS 算法补充场景的几何细节。这类方法虽然能够获得高质量的重建结果，但是需要离线优化等处理，因此实时性能较差。

近年来，DROID-SLAM 和 NICER-SLAM 等集成了相机定位和稠密重建的 SLAM 系统相继问世。然而，这些系统或是重建质量不够理想，或是无法达到实时运行的要求。DUSt3R 开创性地提出端到端的高效点云重建，但其仅局限于图像对（双目），在视频场景下仍需全局迭代优化，因而影响了效率。同期工作 Spann3R 虽将 DUSt3R 扩展为增量重建方式并提高了效率，但也带来了明显的累积误差，降低了重建质量。

此外，重建的准确度和完整度之间存在着固有的权衡关系，导致当前重建系统难以同时实现准确、完整和高效这三个目标。因此，在单目视频稠密重建领域中，要同时达到高质量和高效率极具挑战性。

SLAM3R：大模型时代背景下的实时稠密重建系统

DUSt3R 首次证明了大型神经网络模型的 Scaling Law 在双目立体视觉中的可行性。SLAM3R 在此基础上更进一步，通过引入传统 SLAM 系统的经典设计理念，成功将大模型应用于长视频序列的稠密重建任务。这种端到端的方法不仅具有天然的高运行效率，而且经过大规模训练后能达到高质量的重建效果，从而实现了一个在准确度、完整读和效率方面都表现出色的三维重建系统。

SLAM3R 系统示意图。给定单目 RGB 视频，SLAM3R 使用滑动窗口机制将其转换为互有重叠的片段（称为窗口）。每个窗口输入至 Image-to-Points（I2P）网络，用于恢复局部坐标系中的稠密点云。随后，这些局部点逐步输入至 Local-to-World（L2W）网络，以创建全局一致的场景模型。I2P 网络选择一个关键帧作为参考建立局部坐标系，并利用窗口中的其余帧估计该窗口的稠密点云。第一个窗口用于建立世界坐标系，之后 L2W 网络逐步融合后续窗口。在增量融合过程中，系统检索最相关的已注册关键帧作为参考，并整合新的关键帧。通过这个迭代过程，最终完成整个场景的重建。

SLAM3R 主要由两个部分组成：Image-to-Points（I2P）网络和 Local-to-World（L2W）网络。I2P 网络负责从视频片段中恢复局部坐标系下的稠密点云，而 L2W 网络则将局部重建结果逐步注册到全局场景坐标系中。在整个点云重建过程中，系统直接使用网络在统一坐标系中预测 3D 点云，无需显式计算相机参数和三角化场景点云，从而避免了传统重建方法中迭代优化等耗时的操作。

窗口内的多视角三维重建（I2P 网络）。在每个窗口内，选择一帧作为关键帧来建立参考系，其余帧（称为支持帧）用于辅助该关键帧的重建。我们基于 DUSt3R 解码器设计了关键帧解码器，通过引入简单的最大值池化操作来聚合多个支持帧的交叉注意力特征，从而有效整合多视角信息。这一改进在保持模型结构简洁的同时具有多重优势：1）继承 DUSt3R 预训练权重，从而保证预测质量；2）未引入过多计算开销，保持实时性能；3）支持任意数量的图像输入，具有良好的扩展性。

窗口间的增量式点云注册（L2W 网络）。窗口间的注册与窗口内的重建相似，不同之处在于前者使用多帧重建结果作为参考系，用以辅助注册新的关键帧。因此，L2W 采用了 I2P 的整体架构。在此基础上，引入简单的坐标编码器来处理点云输入，并通过逐层特征叠加的方式注入解码器。这种机制让模型在解码过程中持续接收几何和坐标系的双重引导，既确保了信息传递的充分性，又避免了复杂特征交互设计带来的计算负担。这一设计巧妙地继承了 DUSt3R 的坐标转换能力，并将其转化为可控的注册过程。

场景帧检索模块。我们提出了一种前馈检索机制，用于确定 L2W 网络在注册新关键帧时所使用的参考帧。当 SLAM3R 系统需要调用 L2W 融合新窗口（关键帧）时，系统会先通过场景帧检索模块从已注册窗口中检索 K 个最优参考帧，再将这些参考帧与新帧一同输入 L2W 模型进行坐标系转换。这种设计既保持了全局一致性，又有效缓解了传统 SLAM 系统中的累积误差问题。检索模块通过在 I2P 网络中附加额外的轻量级 MLP 实现，完成前馈式快速检索。

大规模训练。SLAM3R 系统的各个模块均采用前馈式神经网络实现，最大程度地复用了 DUSt3R 大规模预训练的权重，并在大规模视频数据集上进行训练。具体来说，我们收集了约 85 万个来自 ScanNet++、Aria Synthetic Environments 和 CO3D-v2 数据集的视频片段，使用 8 张 4090D 显卡进行训练。训练完成后，该系统可在单张 4090D 显卡上实现实时推理。

单目视频稠密重建迈入高质高效新时代

我们在室内场景数据集 7-Scenes 和 Replica 上评估了 SLAM3R。在重建速度较快（FPS 大于 1）的方法中，SLAM3R 实现了最佳的准确度和完整度。

7-Scenes（上方表格）和 Replica（下方表格）数据集的重建结果评估。我们以厘米为单位报告重建的准确度和完整性。FPS 栏目的颜色渐变从红色变为黄色，再变为绿色，表示实时性能提升。

值得特别指出的是，即使没有进行任何后续全局优化，SLAM3R 的重建质量也达到了与需要复杂优化的离线方法相当的水平。这表明 SLAM3R 在准确度、完整度和运行效率三方面达到了理想的平衡。

，时长00:14

SLAM3R 基于公开数据集与日常视频的场景重建结果展示。

未来展望

SLAM3R 在保持 20+ FPS 实时性能的同时，其重建质量可达到离线方法相近的水平，旨在推动三维重建向高质量、高效率方向发展。通过将传统多阶段的三维重建流程简化为轻便的前馈网络，SLAM3R 降低了使用门槛，使三维重建有望从专业领域拓展至大众化应用。随着模型轻量化技术的突破，该方案未来有望进一步应用于移动终端，为三维资产快速获取、通用人工智能和具身智能的落地提供基础三维数据支持。

目前，SLAM3R 仍存在诸多局限性。由于跳过了相机参数预测和优化等环节，SLAM3R 无法执行显式的全局优化（Bundle Adjustment）。因此，在大规模场景中，系统仍会受到累积误差的影响。此外，基于场景重建推导出的相机参数的精度仍不如专门针对相机定位的 SLAM 系统。解决这些局限性是我们未来工作的重点。

#剑桥博士长文讲述RL破局之路

被《经验时代》刷屏之后

RL + LLM 升级之路的四层阶梯。

2025 年伊始，RL 以一种破局归来的姿态在 LLM 的后训练时代证明了其巨大价值，Sutton 和 Barto 拿了图灵奖，David Silver 去年在 RLC 上说 “（RL 受关注的程度）终将跨越 LLM 带来的低谷”，竟然来得如此之快。

PhD 这些年即将告一段落，这几个月梳理先前的工作，准备 Tutorial，借鉴了不少去年从 RLC 上听 David Silver 讲过的思想，在这个 “RL Finally Generalizes (Shunyu Yao)” 的时代到来之际，也一直想写一篇文章作为整理，恰好最近读 Silver 和 Sutton 一起写的《经验时代》(Welcome to the era of experience)，结合了一些自己的思考和理解，在出发开会前写下这篇文章，抛砖引玉，希望在新加坡可以和大家有更多的深度交流【关于 RL，Alignment，Reasoning，Agent，MCP，以及其他有关 AGI 的一切！】

RLxLLM 的当下 

成功归于 Inverse RL 和 Data-Driven Reward Models

0.1 RL 和 LLM 分别强在哪里？

距离 AlphaGo 击败李世石已经快有十年，这期间 RL 征服了各种棋类游戏，即时策略游戏，也被应用到了各种系统的性能优化当中。在这些任务中，RL 总能找到比人类专家更好的策略，它能将优化做到极致。也有在持续训练中不断提升的潜力。RL 找到的策略和解决方案，可以给人类专家带来启发 —— 虽然这并不容易。一个著名的例子是 AlphaGo 的 "Move 37"，它被当作 “RL 具有创造力” 的验证。

另一方面，数据驱动的生成模型在更好的架构，更稳定的优化器，更强的算力，更科学的算法，种种 buff 加持之下不断朝着 scaling law 的前沿推进。如今包括 Sora，StableDiffusion，GPT 在内的这些模型已经可以很好地理解用户，按照指令生成能让用户满意（甚至惊喜）的文字，图片，和视频。

然而，世界上的数据总量是有限的，即使 Scaling Law 总是成立，数据也迟早会枯竭。数据驱动的生成模型虽然有诸多优势 —— 比如在小样本上极强的泛化能力，强大的指令跟随能力，以及自然语言模型天然的可解释性 —— 然而这些模型不具备 RL 系统所拥有的创造力，持续进步提升的能力，和纠错的能力，也无法超越人类的专家水平。

0.2 RL + LLM?

那么，有没有可能有一个系统，它可以和 Data-Driven 的大模型一样去理解、帮助人，同时又可以不断迭代更新自己，纠错和变强呢？

从 LLM4RL 的角度来说，如果我们能用 LLM 实现 super-human performance，那么用自然语言为媒介可以更加容易地把这些 RL 系统的创造力用来启发人类。

从 RL4LLM 的角度来说，RL 可以赋予 LLM 不断提升（由 Reward 定义的任务上性能）的能力。如果把 Alignment 和 Post-train 统一地定义为提升特定方向的能力，那 post-train/alignment 的优化方向本身就是和 RL 这一学习范式非常契合的。

在数学领域，去年 AlphaProof+Alpha Geometry2 拿了 IMO 的银牌，今年 DeepSeek R1 的风已经席卷了全世界；在通用聊天领域，RLHF 里如火如荼的_PO 研究已经即将用尽字母表，庞大的用户规模加上 preference 标注为 OpenAI 提供了源源不断建模用户偏好，改进用户体验的数据。这些都是 RL + LLM 的成功。那么，如果想要把 RL + LLM 这一范式推广到更多的场景，我们面临的困难是什么？比较有潜力的解决方案是什么？这正是我们之前的 Tutorial 希望重点向大家介绍的 —— 当前的 LLM Alignment 是一种数据驱动（人类经验驱动）的 RL，Inverse RL 是这里最自然和简单的方案。

LLM 从人类生成的数据或反馈中学习 —— 也就是 Silver&Sutton 文章里所说的 "Human-Centered AI"。过去两年我参与的 IRLxLLM 的研究也围绕着 “如何从不同数据中构建更好的奖励模型” 进行探索 *[1]。

既然是探索，当然不该止步于 “什么方案最简单，最自然”，也要想未来进一步优化的方向在哪里。

0.3 人类如何学习？

相比 LLM，人类的学习似乎 “容易” 很多，人类不需要也不可能看完所有的书，电视，电影，不会去过所有的地方，但一样可以拥有（更）高程度的智能 —— 可以理解世界，推理，创造，交流，学习。人先在成长初期通过语言学习，交互，理解；同时通过和世界的简单交互了解非常简单的 "物理"(world model, laws)；后来习得书写和文字，又在游戏 / 虚拟世界中学习，学会从互联网上主动寻找有用的信息，最终通过和世界以及社会的交互不断提升能力。我想这恰好可以对应 LLM+RL 发展的四个不同阶段：Data-Driven，Game， Virtual Interaction，Physical Interaction。（人类在学习过程中，除了幼儿时期学语言几乎严格早于其他三者，剩下的学习过程是持续，同步发生的，这里的层级递进关系不一定成立。从 LLM -> AGI 的角度，分成这几层主要是考虑到实现起来的困难程度和安全可控程度。）

当下，主流的方法站在 AGI 的第一层：通过 Data-Driven Reward Model + RL 提升任务性能，接下来我们从这一层开始聊起。

第一层：【Data-Driven RL】(Human-Centered) RL with Data-Driven Reward Model

1.1 如何理解当下 Post-Training 中的 RL？

• RL 是什么

从 RL 的基础谈起 —— 从统计的角度，RL 研究的是如何在动态变化的数据分布中主动学习并建模（包括策略建模和环境建模，有前者可以 Black-box policy inference，有后者可以做 planning）；用更 RL 一点的语言描述，就是如何在和环境的交互中找到长期回报最高的策略。

解决思路上来说，不同的方法都在尝试于探索和利用之间找到平衡（无论是对环境 / Dynamics 的探索还是对策略的探索）。从这个角度出发，也可以理解为什么没有某种探索策略或者学习方法总是好的 —— 对于任何的探索策略，总能针对它设计 counter example，使得这种探索方法不是最优。而随机性是应对 counter example 设计的强有力工具。这也是为什么 MaxEntropy 类方法总是拿一个 random policy 的 KL 保持探索，且这一类方法总是在各种环境中都不太差的原因。

RL 优化 “长期回报”，这意味着首先要定义什么是回报 (Reward)，在大多数任务中，没有这样的 Reward。所以我们无法做到从 “和环境交互中优化策略”，而只能让 LLM 从人类的语言数据中学习，也就是从行为中学习。方法上分为两大类：(1) 模仿学习 (Imitation Learning)—— 比如 Behavior Clone，就是直接对着行为做监督学习，来生成与行为数据相同的行为模式；(2) 逆强化学习 (Inverse Reinforcement Learning)—— 先通过行为数据找到这些行为在尝试优化的奖励函数，然后用这个奖励函数做 RL 来生成与行为数据相同的行为模式。

• Post-Train 在做什么

(1). [Behavior Clone] 先从 Pre-train 说起，Pre-train model 的任务是预测下一个 token，也就是非常经典的 Behavior Clone，模仿人类的语料库。随着训练规模的扩大，模型各方面的能力不断提升，开始有能力理解比字面意更深层的语义，学会更能泛化更加有效的 embedding 模式，并且在新的任务上有了 few-shot 甚至 zero-shot 的能力。

(2). [Prompt Engineering] Post-train 阶段，我们从最简单的 prompt-optimization（或者 in-context learning）说起。因为这些 Autoregressive LLM 都是 Conditional Generator，随着输入的变化，输出 token 的条件概率和分布也会随之变化。因此，通过控制输入的样本，甚至是问问题的方式，都可以让模型在特定任务上达到更好的表现。这个方向在 2023 年是比较热的话题，后来的趋势是随着模型能力的提升，prompt optimization 的边际效应过于明显，并且大家意识到对着某一个 LLM 做 prompt engineering 很大概率是在 overfit test set，到下一个迭代的版本就又要重新找，与此同时 "lazy prompting (Andrew Ng)" 的效果也越来越好，工程上也需要在成本和性能之间进行更好的权衡。

(3). [Supervised Fine-Tuning] 接下来，如果我们有一些高质量的垂类数据或专家数据，在这个小规模数据集上进行监督微调 Supervised Fine Tuning 效果也可能会不错，且这个过程简单稳定，非常适合资源有限，数据质量高，任务对 LLM 基模来说相对简单，并不追求极致的性能改进的场景。

总结来看，Post-train 的总体目标是通过少量的高质量样本，来调整基座模型生成回答的数据分布，使之适应新的任务或特定的某类由样本特性所定义的任务。BC 和 SFT 是直接的模仿学习手段，而 Prompt-Engineering 很有一种 Prior-hacking 的味道，我们姑且把它也归为一种对 "成功 prior hacking 经验的模仿"。最近一年里有很多工作讲了 SFT 和 RL (HF) 分别在做什么，有很多种含义相近的描述，比如 SFT 负责记忆，RL 负责泛化，SFT 做 mass-covering，RL 做 Mode-Seeking。接下来，我们通过三个例子来看为什么有了 SFT/Prompt-Engineering 这些简单有效的方法，还需要 RL，或者说需要 Reward Model。

1.2 为什么用 Inverse RL 来解决 Data-Driven RL？

Inverse-RL 中的重要一步是通过数据建模 Reward Model，从而使不完整的 MDP\R 问题转化为完整的 MDP，进而能够调用 RL 工具去解决。我们把这里从人类行为数据出发，建模奖励函数的过程称为 (Neural) Reward Modeling，这是现阶段的主流做法，也是 Silver 和 Sutton 在文章中提到的 Human-Centered AI。我们通过以下三个例子来理解 Reward Model 的作用与优势

1. Inverse RL (Reward Models) 可以收集更加规模化的数据

这里举 ChatGPT 的例子 —— 当我们使用 GPT 的时候，会遇到让我们提供 preference，帮助 OpenAI 提供未来模型的选项，这件事能大规模应用的主要原因是 Preference 这个判别任务远比 demonstration 的生成任务更加容易和可拓展。我们能欣赏顶级网球选手打球，看谷爱凌苏翊鸣飞台子看 FWT，不需要我们自身有很高的运动水平

2. Inverse RL (Reward Models) 可以帮助找到更有泛化能力的解决方案

在 DeepSeek R1 的数学任务中，Rule-based (Data-Driven) reward model 给了 LLM 最大限度的自由度去探索有可能能够成功的回答问题模式，这种自由度允许模型自己去发现 “long chain-of-thought” 这种行为可以有效提升回答正确的可能，进而把最能够泛化的做题能力保持住。这里 (Outcome) RM 是因，找到可泛化的 pattern 是果，具体如何更高效率地 exploration，或者学这些发现的 pattern，是因果之间的媒介 —— 它会影响学习效率，但不会影响 “能不能学”。

3. Inverse RL (Reward Models) 是 Inference Time Optimization 的基础

正如文章一开始所说，在普通的 RL 任务中，没有 “Inference-Time” 和 “Training-Time” 的区别，大多数 RL 都是在测试任务上训练的。所以大多数 RL Policy 解决任务的方式就是训练完了之后部署在这个系统上做 Inference，每次生成 action 只需要 Network Forward 一把，也谈不上 Inference Time Optimization（比如 Mujoco/Atari 都是这样的任务）。然而，在围棋任务中，目前还没有每一步直接做一次 Neural Network Inference 就能击败人类顶级选手的 RL Policy，需要这些 Policy Network 配合 Value Network 做 MCTS 才能取得较好的效果。在这个过程中，value network 扮演的决策就是一个 "dense reward function"，能够在 inference 过程中把不好的 action 过滤掉。

同理，Reward Model 在困难的 LLM 任务中也可以扮演 Inference-time 过滤器的角色，它总能和已有的 post-train 方法相结合，进一步提升 LLM 生成的质量。

1.3 为什么关注 Inverse (Reward Model) 部分而不是 Forward (Policy Optimization) 部分

首先，准确的 evaluation 是一切算法改进的根基。Online RL 的工具库里有很多工具，但这些工具能用的前提是有一个靠谱的 Reward Model。找到问题出在哪是研究的第一步，如果 Reward Model 没有研究清楚，在第二阶段各种 RL 算法如此难收敛，超参如此之多又如此敏感，LLM 的训练又如此之慢的前提下，对着不靠谱的 Reward Model 做优化，得到的实验观察很难总结出可信的结论（更别提有人不到 10 个数据点取完 log 都 fit 不好也起名叫 scaling law 了）。

此外，RL 领域无数任务中的经验告诉我们，RL 里没有 Silver Bullet，最重要的是理解任务的特点，并根据任务（数据，奖励性质，系统性质，算力约束）去优化相应的算法。DPO 和 GRPO 的成功不是因为它们是 LLM 时代的策略优化万金油，而是因为它们找到了先前系统中存在的问题（冗余），根据任务的需求和硬件进行了优化。

1.4 为什么 Reasoning 是这一层里最重要 (和目前为止最成功) 的任务

首先是观察：Reasoning task 确实可以提升模型 "聪明" 的程度，跟随用户指令，完成任务和解决问题的能力，在数学上训出来的模型，整体能力都提升了。

其次是动机：如果能够真的让 LLM reasoning 起来，行为上具有想的越久，正确率越高的能力，那么这个系统兴许真的可以自举起来。数学家不断推理就有可能发现新的定理，提出新的问题，或是在解决问题的方向上取得进展。不过话说回来，用没有这种能力的模型尝试达到 “左脚踩右脚原地起飞” 的效果，并且用 “左脚踩右脚原地起飞” 宣传工作，或许有点不太合适。。

第二层：【Game】Experience from Games and Rule-based Tasks

在第一层，我们知道通过人类的经验，反馈，或是人工生成的题库来建立奖励模型，可以把 LLM Post-Train 这个缺失了 Reward Function 的 MDP\R 问题转化成完整的 MDP 问题。这种数据驱动的方式廉价，可规模化，在数学任务上优化过后取得了非常好的优化泛化性，显著提升了模型的通用能力。但是但凡是有限样本拟合的奖励函数，都会有过拟合的风险，只是不同的模型，不同规模的数据，不同的任务，这种过拟合的风险不同罢了。Reward Model 的过拟合带来的后果是 Reward Hacking，也就是朝着背离 Reward 设计初衷的方向狂奔，比如 helpful 这个任务里一个经典的 reward hacking 是 "length bias"—— 模型不管说的话有没有用，发现说的越多分数越高，就可劲输出废话。

短期来看，我们可以想办法在有限的范围内缓解 Reward hacking，就像这一路 data-driven 的科研模式中大家通过各种方式减少 overfit，提升模型的泛化性一样。但是长期来看，这种发展不符合数据 x 算力这种更加可预测的扩张模式 —— 在所有有可能的改进中，算法的改进可能是最难预测的（天不生 Sutton，RL 如长夜）

那么，除了数学，还有什么任务是或许可以突破数据瓶颈，增强模型能力的呢？回想人类幼崽的学习过程，从小时候学会了语言之后，首先接触的是游戏！技术上来讲，游戏往往是定义良好的完整 MDP，十几年前我们用游戏训练了 DeepRL 算法，那如果 DeepRL 算法运行在 LLM 上呢？

我们的终极目标是通过在环境中进行无穷多次的尝试探索，让 LLM 不断提升自己的理解 / 推理 / 规划 / 指令跟随能力。游戏恰好提供了这样的（廉价模拟）环境 —— 想要在游戏中取胜，需要首先理解其规则，进而在规则限定的范围内对策略进行优化。这里的游戏包括文字为基础的辩论 / 讨论类型的游戏，规则更为明确的棋牌类游戏，以及其他更一般的 3D 类型游戏。其中文字 / 辩论类游戏的胜负判断相对困难，但输入输出空间最适用于语言模型。棋牌类游戏虽然可行，但输入输出空间的表征适配或许是一个较大的挑战。更复杂一些的游戏虽然可行，但现在 LLM 包括 VLM 的能力可能距离玩好这些游戏太远了，找到合适的 curriculum 和任务是重要的问题。从去年下半年开始 ^*[3]，我们陆续看到了这个方向的尝试，包括简单的 Atari，贪吃蛇类型游戏，3D，Text-based game，未来可期，但也有诸多亟待解决的问题：

1. 什么样的任务最适合评估 LLM 的能力？如何避免 text-based game 中的 cheating？
2. 怎样找到 LLM 处理输入输出，理解游戏的最佳表示？
3. 什么样的游戏可以最全面地发展 LLM 个方面的能力（而不至于让 LLM “玩物丧志” overfit 到游戏）
4. 游戏中取得的进展是否可以像数学一样带来全面的能力提升？
5. 如果允许调用 Tool（比如 AlphaGo 的 value function 或者 GTO 软件），LLM 还能（需要）在这个过程中学会推理吗，学会造轮子更重要还是使用轮子更重要
6. 这里是否会有一个对应的 game supremacy scaling law 之类的东西存在？游戏提升 LLM 推理能力的上限在哪里

解决了这些问题之后，大规模上 Self-Play，突破目前的数据局限，提升 LLM 的推理能力就只剩下算力问题。

第三层：【Virtual Experience】“Experience” in the Virtual World

在过去两年做 Alignment 研究的过程中，一直很想做但又没有合适机会的方向是 Agent——Agent 是一个非常面向产品 / 用户 / 落地的课题，工程上的优化，用户的反馈，活跃开发社群的建设和维护都十分重要。除此之外，即使可以在研究中尽可能地将基座模型的能力和框架以及学习范式二者分离，基座模型的能力提升往往可以直接带来质变。

至于非技术上的问题，例如早期大家担心的适配与权限问题，目前看来在 MCP 到来以后都不再是重点。除非数据的拥有者能做到垄断，不然市场的反向选择一定会让数据的拥有者对 Agent 更加开放。当然，一切的前提都是 Agent 背后有足量用户的支持，Agent 足够强大和有用。从这个角度看，Agent 时代做内容和社交，或许能带来洗牌的机会。Agent 时代很或许会有新的微信。

从 RL 的角度，Agent 时代也有更多的机遇和挑战：

首先，Agent 与虚拟世界（互联网中的内容）进行交互，完成 “任务”。所以其实 Agent 相比 LLM 的变化，重点不在于加了几个 prompt，引入了工作流，而是增加了很多它们和非语言系统交互的可能性。有交互就会有反馈，这些反馈信息是一手的，真实的，on-policy 的，用 Silver 和 Sutton 的话说就是它们自己的 Experience。

在这个交互过程中，用户可以定义无穷多的任务，并且提供任务是否成功的反馈。相比在游戏中进行 self-play，直接和用户打交道的 Agent 所参与的场景和用户的日常需求高度对齐，不太需要担心能力提升的泛化问题。通过用户众包形式的反馈，提升 Agent 的能力就像是在培养具有专业技能的劳动者。

更重要的是，Agent 达成目标这个任务属于 RL 中的 Multi-Goal 问题，Multi-Goal 最大的特点就是很方便从失败的经验中学习 (Hindsight Methods)。举个例子，LLM 做数学题的时候，一道题做错了，生成的错误答案只能通过 “反思，纠错”，来帮助 LLM 以后在类似的题上不犯同样的错误 —— 但是它很有可能会犯别的错误。这里失败的经验只能被拿来做排除法，从失败中学习难就难在失败的可能千千万，成功的路径相比之下要稀缺很多。所以数学就不是一个很好的 “multi-goal” 的例子 —— 没有人会把 “做错这道题” 当成一个有效的目标。

再来看 Agent 达成目标这个任务，如果我让 Agent 帮我【订一张从北京到上海的火车票】，结果 Agent 一通操作，帮我买了一张从北京到深圳的机票，我们会认为这个任务失败了，但是这个失败的经验只是对于原始的目标失败了，如果有一天我想从北京去深圳，这次 Agent 的失败经验是很有用的，只需要更改这次失败经验的目标，就可以让 Agent 的 Experience 中有【订一张从北京到深圳的机票】这个目标应该如何达成这一条，对着成功的案例学习，效率自然会比用排除法高很多。

在这些机遇背后，很多技术问题的答案也让人充满好奇 ——

• 可以规模化的持续学习的能力如何注入，范式是什么
• RL 会有 plasticity vanishment 的问题，GPT 系列模型做 Supervised Learning 的 scaling law 到了 RL 还是否存在？
• 大规模的 Agent Learning 是工程和算力的双重挑战。人类社会是多元的，Agent 更像是人类社会中承担不同工作的员工们，人类的多元化和不同的天赋让分工更加明确，并且持续积累经验，不断提升专业化的程度和业务能力。用 Prompt 给 Agent 注入的 Diversity 或许帮助有限，用 Fine-tuning 甚至不同的 pretrain model 又难以支撑。
• Agentic Personalization 是必然的趋势，但端侧友好的轻量化实现目前并没有好的方案。对齐和监管要求这个过程必然是中心化进行的，如果要用目前的技术手段做到这个规模的中心化，英伟达的卡是不是需要普及到人手一块。

第四层：【Physical Experience】“Experience” in the Physical World

最近两年机器人和具身智能再度火热，早期做 RL 方向的同学可能大多都对这个方向有着比较深的感情，robot control、mujoco 应该是当年开始 RL 的时候大家最先接触的任务。能够和物理世界做真实交互的机器人一定是未来，但是硬件和伦理是两大绕不开的挑战。硬件的成本会随着技术的进步不断降低，但风险和伦理问题一眼还需要更多思考。

硬件方面，2020 年和朋友一起琢磨过面向发烧友的手工出海，做过一条非常简易的 “四足机器 (狗？)”。元件就是几个电机，树莓派，四条腿是一次性筷子做的，拍脑袋写了个声控往前爬往后爬的运动模式。然而出师未捷，内忧外患一起出现 —— 贸易战升级，小米也出了一款价格四位数的消费级器狗。对比过后发现硬件这个东西不比服务或者互联网，一分价格一分货，且重资产轻技术，十几二十块的电机就是做不到精准有力的操控，力度不够就是没办法后空翻，这个产品或许只能卖给发烧友搞着玩，价格也不便宜，后来就不了了之了。

更现实一些，距离我们生活最近的场景是智能 (辅助) 驾驶，在这个场景里，车是市场上存在的刚醒需求，客户不会因为智能的 “具身” 支付太多额外的硬件成本。车作为智能的载体，能执行的动作也比较有限，更加可控。即使在这样的 Embodied AI 系统里 —— 我们多大程度上可以接受自己的车一边开一边学，增强推理和理解场景的能力？多大程度上可以接受它犯错？谁来承担系统的错误。

人的分工和相互信任建立在长时间的社会稳定和协作共赢之上，但人和机器如何做到互信，要花多久？当智能能够通过具身或者物理世界的载体和人交互，就不可避免会带来伦理问题，包括我在内的大多数的技术 / 科研工作者对此可能都一无所知，这里也就不多做讨论。可以确定的是，AGI 时代会有更多的挑战，关于 AI Safety 的探讨也会更加迫切，当 Agent 有有了无限探索的能力和物理世界做交互的时候，碳基文明的存亡也有了实实在在的威胁。

在 AGI 的前夜，人类更加需要伟大哲学家的指引

作者简介

孙浩是剑桥大学 4 年级在读博士生，研究课题为强化学习和大语言模型的对齐（后训练）。他关于强化学习的研究涵盖了稀疏奖励，奖励塑形，可解释性等课题，研究发表于 NeurIPS 会议；在关于大语言模型对齐的工作中，重点关注如何从数据中获得奖励函数，提升大模型在对话和数学上的能力，论文发表于 ICLR 会议，并参与贡献了 AAAI2025 和 ACL2025 的系列课程报告。

原文链接：​​https://zhuanlan.zhihu.com/p/1896382036689810197​​

[1] 过去两年我参与的 IRLxLLM 的研究也围绕着 “如何从不同数据中构建更好的奖励模型” 进行探索

ICLR'24: RM for Math & Prompting;

ICML'24: Dense RM for RLHF;

RLC workshop'24: RM from Demonstration data;

DMRL'24: When is RM (off-policy-evaluation) useful?;

ICLR'25: foundation of RM from preference data;

Preprint (s)'25: Active RM, Infra for Embedding-based Efficient RM Research, PCA for Diverse/Personalized RM)

[2] 关于未来方向的畅想，理解和思路上距离在 Agent 方向深耕的研究难免会有偏差，烦请大家不吝斧正！

[3] 更早一些在 2023 年底的 NeurIPS 就有一篇工作是讲外交类游戏博弈的，希望 LLM+Game 这个方向的未来不要步前几年的 RL + 阿瓦隆 / 狼人杀 /xx 游戏的后尘，而是在选择任务上多一些思考，做长期更有价值的探索！

#TTRL

TTS和TTT已过时？TTRL横空出世，推理模型摆脱「标注数据」依赖，性能暴涨

在大语言模型（LLMs）竞争日趋白热化的今天，「推理能力」已成为评判模型优劣的关键指标。OpenAI 的 o 系列、Anthropic 的 Claude 和 DeepSeek-R1 等模型的惊艳表现背后，测试时缩放（TTS）技术功不可没。

测试时缩放（TTS，Test-Time Scaling）是一种提升大语言模型推理能力的新兴策略，通过在测试阶段优化推理过程（如多数投票、蒙特卡洛树搜索等）提升大型语言模型（LLMs）的性能，而无需修改模型参数。

研究表明，TTS 在计算效率上优于预训练阶段扩大模型规模，能以更低资源成本实现更好表现。然而，TTS 依赖预训练知识，在面对未标注新数据或输入分布变化时，泛化能力受限。如 OpenAI o3 在某基准任务上达到 75.7% 的成功率，对更复杂的新任务却仅能解决 4% 的问题。

为克服 TTS 的局限，测试时训练（TTT，Test-Time Training）一度受到广泛关注。TTT 通过在测试阶段利用 RL 等技术动态更新模型参数，使模型适应新数据或任务，弥补了 TTS 在泛化能力上的不足。但 TTT 同样面临自身的挑战：测试阶段缺乏奖励函数或验证信号，而人工标注数据的高成本使得无监督环境下的 RL 应用受限。

在最新的一篇论文中，清华大学和上海人工智能实验室提出了一种新方法 —— 测试时强化学习（Test-Time Reinforcement Learning，TTRL），该方法能够在无标注数据上对 LLM 进行强化学习训练。

• 论文标题：TTRL: Test-Time Reinforcement Learning
• 论文地址：https://arxiv.org/abs/2504.16084
• GitHub：https://github.com/PRIME-RL/TTRL
• HuggingFace：https://huggingface.co/papers/2504.16084

TTRL 通过利用预训练模型中的先验知识，使 LLM 具备自我演化的能力。实验证明，TTRL 在多种任务和模型上都能持续提升性能：在仅使用未标注测试数据的情况下，TTRL 将 Qwen-2.5-Math-7B 在 AIME 2024 任务中的 pass@1 指标提升了约 159%。

值得注意的是，虽然 TTRL 仅依靠 Maj@N 指标进行监督，但其表现不仅能持续超越初始模型的性能上限，更能接近于那些直接在有标注测试数据上进行监督训练的模型性能。实验结果验证了 TTRL 在多种任务中的广泛有效性，充分展示了该方法在更广阔领域中的应用潜力。

方法

图 2 展示了研究者提出的 TTRL 方法如何应对此类挑战。给定状态表示为输入提示 x（prompt x），模型依据参数化策略 π_θ(y | x) 生成输出 y。为了在无真实标签的条件下构造奖励信号，研究者通过重复采样的方法，从模型中生成多个候选输出 {y₁, y₂, ..., y_N}。接着，使用多数投票（majority voting）或其他聚合方法从这些候选中推导出共识输出 y*，作为近似的最优动作（optimal action）的替代。

环境反馈的奖励 r (y, y*) 则根据当前动作 y 与共识输出 y* 之间的一致性进行设定。模型的 RL 目标是最大化期望奖励：

通过梯度上升（gradient ascent）更新参数 θ：

该方法能够在推理阶段实现模型的动态适应，无需标注数据即可提升模型应对分布变化输入时的性能。

多数投票奖励函数（Majority Voting Reward Function）

多数投票奖励机制的核心在于：首先借助多数投票策略估算一个伪标签（pseudo-label），再基于该估计标签计算规则驱动的奖励（rule-based rewards），并作为最终用于 RL 训练的奖励信号。

在具体操作上，给定一个输入问题 x，研究者对其输入到大型语言模型中，并生成一组输出结果。随后，答案抽取器（answer extractor）对这些输出进行处理，提取对应的预测答案，记为 P = {ŷᵢ}ⁿ_{i=1}。接着，研究者在集合 P 上应用第 4 节定义的多数投票策略函数 s (y, x)，选出出现频次最高的预测 y，作为估计标签。

随后，该多数投票结果 y 被用作标签估计，用于计算基于规则的奖励信号：

实验

TTRL 在大多数任务和模型上都表现出色。尽管 TTRL 完全依赖于使用无标注测试数据的自我进化，但其性能却可媲美基于大规模标注数据集训练的现有 RL 模型。如表 1 所示，在 AIME 2024 上，TTRL 实现了 159.3% 的大幅提升，超过了所有在大规模数据集上训练的模型。此外，当应用于 Qwen2.5-Math-7B 时，TTRL 在三个基准测试中平均提高了 84.1%。

TTRL 自然扩展。另一个值得注意的现象是，随着模型大小的增加（从 1.5B 到 7B），其在 AIME 2024 和 AMC 上的性能提升也在增加，这凸显了 TTRL 的自然扩展行为：更大的模型可以在自我改进过程中产生更准确的多数投票奖励，从而更有效地学习新数据。不过，LLaMA-3.1-8B-Instruct 和 Qwen2.5-Math-1.5B 可能由于容量有限，未能通过 TTRL 在 AIME 2024 上取得有意义的进展。相比之下，Qwen2.5-Math-7B 的模型容量更大，知识更充分，因此可以从自我改进中获益，从而取得明显的性能提升（第 4.3 节会详细讨论这一点）。

TTRL 在目标任务之外也有很好的通用性。研究者以 Qwen2.5-Math-7B 为骨干，在每个基准上执行了 TTRL，并在其他基准上进行了进一步评估。图 3 展示了结果。尽管这种设置具有分布外的性质，但 TTRL 在所有基准上都取得了实质性的改进。这表明 TTRL 并没有依赖过拟合（过拟合会导致在其他任务上的取舍），而是在自我改进过程中获得了可推广的收益。

TTRL 与不同的 RL 算法兼容。图 4 展示了结果。研究者在 MATH-500 上使用 PPO 应用 TTRL，以评估其与不同强化学习算法的兼容性。PPO 和 GRPO 的性能轨迹非常接近。与 GRPO 相比，PPO 能产生更稳定的结果，同时实现相似的整体性能。

讨论

Q1：TTRL 的性能能有多好？

研究者使用了两个上限来分析 TTRL 的潜在性能。第一个上限是 Maj@N，用于计算 TTRL 训练过程中的奖励。第二个上限是在基准数据集上的直接训练，它假定可以访问 ground-truth 标签，因此会向策略模型泄露标签信息。

关键发现如下：

1. TTRL 不仅超越了其训练信号和初始模型的直观上界 Maj@N，还接近了用标注测试数据训练的直接 RL 的性能。这一进步可能要归功于 TTRL 使用 RL 进行测试时间训练：通过将基于投票的伪标签转换为奖励，它提高了有效监督的质量，同时使学习摆脱了 Maj@N 的限制。

2. TTRL 的经验上限是在测试数据上进行训练（即在测试数据上进行训练），这凸显了它与标准训练评估协议相比在功效上的潜在优势。

3. 对于具有挑战性的任务，TTRL 只需使用 1.5B 模型即可达到经验上限。这表明，现在 LLM 可以通过 TTRL 有效地自我进化，从而在大规模数据集上实现无限制的终身学习。

TTRL 受 Maj@N 监督，却超越了 Maj@N。图 6 展示了 TTRL 在 Qwen2.5-Math-7B 上的测试结果。可以看出，在所有基准测试中，TTRL Avg@64 均优于 Qwen2.5-Math-7B Maj@64，大大超出预期。此外，在应用多数表决时，TTRL 的性能也有大幅提升。

TTRL 的「性能增益法」基准训练，图 7 展示了结果。令人惊讶的是，TTRL 的性能曲线非常接近 RL（泄漏）的性能曲线。

Q2：TTRL 为何有效？

这一节主要分析了 TTRL 在无监督条件下实现稳定有效的 RL 的因素，包括两个关键方面：标签估计和奖励计算。

标签估计。TTRL 与标准 RL 算法的一个直接区别是，TTRL 涉及标签估计，而标签估计会带来奖励误差。研究者认为，尽管存在这些误差，TTRL 仍能正常工作，原因有以下两点：

(i) 现有研究表明，RL 可以容忍一定程度的奖励不准确性。此外，与通常依赖于记忆训练数据的监督微调（SFT）相比，RL 的泛化效果往往更好。在 RL 中，奖励通常是模糊的，主要是作为探索的方向信号，这导致了 RL 对奖励噪声的鲁棒性。

(ii) 之前的研究还从优化的角度研究了什么是好的奖励模型，发现更准确的奖励模型不一定是更好的教师。因此，由政策模型本身估计的奖励信号可能会为学习提供更合适的指导。

奖励计算。当模型能够通过多数投票估算出准确的标签时，随后估算出的奖励一般都是可靠的。然而，一个自然而然的问题出现了：为什么在 AIME 2024 等具有挑战性的基准上，即使模型无法估算出准确的标签，TTRL 仍然有效？

研究者表示，最根本的原因在于 RL 中奖励的定义。基于规则的奖励是根据预测答案是否与「标签」匹配来分配的。因此，即使估计的标签不是 ground-truth，只要它与错误预测的答案不同，系统仍可分配正确的「负」奖励。

为了提供更详细的案例研究，研究者在 Qwen2.5-Math-7B 上检验了 TTRL 在 AIME 2024 上的性能。图 8 显示了三个指标的变化曲线。

研究者发现了 TTRL 在 AIME 2024 上依然有效的两个主要原因：

• 首先，奖励比标签更密集，即使估计的标签不准确，也有更多机会恢复有用的学习信号。
• 其次，当模型能力较弱时，TTRL 给出的奖励可能更准确。

Q3：TTRL 何时失效？

在算法层面，TTRL 与现有的 RL 算法并无本质区别，因此继承了它们的一些特点，如对数据难度的敏感性、对先验的强烈依赖性以及在某些条件下崩溃的风险。

在实现层面上，这些问题因 TTRL 的限制而进一步扩大，TTRL 通过多数投票来估计标签，并且只在稀疏和以前未见过的测试数据上运行，在某些情况下可能会导致失败。

在初步实验中，研究者发现了两个潜在问题：

缺乏对目标任务的先验知识。如表 2 所示，研究者发现，随着问题难度的增加，性能提高率和长度缩减率都呈下降趋势。这表明主干系统的可用先验知识不足以支持对更具挑战性问题的学习。

不恰当的 RL 超参数。图 10 比较了在 AIME 2024 上的几次失败尝试。

#MANIPTRANS

机器人也会挤牙膏？ManipTrans：高效迁移人类双手操作技能至灵巧手

研究团队由来自北京通用人工智能研究院（BIGAI）、清华大学和北京大学的跨专业研究者组成，致力于具身智能领域的前沿研究。团队成员在开发高效、智能的通用机器人技术，特别是机械灵巧手操作方面，拥有丰富的研究经验。一作为北京通用人工智能研究院研究员李恺林，其它作者为清华大学博士生李浦豪、北京通用人工智能研究院研究员刘腾宇、北京大学博士生李宇飏；通讯作者为北京通用人工智能研究院研究员黄思远。

近年来，具身智能领域发展迅猛，使机器人在复杂任务中拥有接近人类水平的双手操作能力，不仅具有重要的研究与应用价值，也是迈向通用人工智能的关键一步。

目前，数据驱动的具身智能算法仍需要精确、大规模且高度灵活的灵巧手动作序列。然而，传统的强化学习或真机遥操作方法通常难以高效获取此类数据。

为了解决这一问题，北京通用人工智能研究院联合清华大学、北京大学的研究人员提出了一种两阶段方法——ManipTrans，可在仿真环境中高效地将人类双手操作技能迁移至机器人灵巧手。

• 论文地址：MANIPTRANS: Efficient Dexterous Bimanual Manipulation Transfer via Residual Learning
• 论文链接：https://arxiv.org/pdf/2503.21860
• 项目主页：https://maniptrans.github.io
• 代码与数据集：https://github.com/ManipTrans/ManipTrans

ManipTrans 首先利用通用轨迹模仿器的预训练模型模仿人类手部动作；然后针对不同的操作技能，引入残差学习模块，结合基于物理的交互约束进行精细调整（如图 1 所示）。该方法将动作模仿与物理约束分离，使复杂的双手任务学习更加高效，执行更加精准。

基于 ManipTrans，研究团队同时发布了大规模灵巧手操作数据集 DexManipNet，涵盖了如盖笔帽、拧瓶盖等此前未曾深入探索的任务。

图1. 基于ManipTrans实现相同操作技能的跨型号灵巧手技能迁移

研究背景

人类双手在与环境交互中发挥着关键作用，这激发了对机器人灵巧手操作的广泛研究。如何快速获取大规模、精确且接近人类水平的灵巧手操作数据，已成为亟待解决的问题。

现有的基于强化学习的方法需要精心设计针对特定任务的奖励函数，这通常限制了任务的复杂性，并可能导致机器人动作的不自然；另一类基于遥操作的方法成本高昂、效率低下，且所采集的数据通常针对特定的本体，缺乏通用性。

目前，一种有潜力的解决方案是通过模仿学习，将人类的操作动作迁移到仿真环境中的灵巧手上，以生成自然的「手-物交互」。然而，实现精确且高效的迁移并非易事。由于人手和机器人手在形态上的差异，直接进行姿态重定向的效果并不理想。并且，尽管动作捕捉得到的数据相对准确，但在高精度任务中，误差的累积仍可能导致任务失败。此外，双手操作引入了高维度的动作空间，显著增加了高效策略学习的难度，因此，先前的大多数工作通常止步于单手的抓取任务。

研究方法

图2. 本文提出的ManipTrans方法框架图

针对上述挑战，本文提出了一种简洁而有效的方法——ManipTrans（如图 2 所示），旨在实现操作技能，特别是双手协同技能，在仿真环境下从人手向机械灵巧手的迁移。核心思想是将迁移过程划分为两个阶段：第一阶段，实现手部运动的轨迹模仿；第二阶段，在满足物理交互约束的前提下，对动作进行微调。

具体而言，首先预训练一个通用模型，以准确模仿人类手指的运动；在此基础上，引入残差学习模块，对灵巧手的动作进行微调，着重针对以下两点：1）确保手指与物体表面的稳定接触；2）协调双手，保证复杂情况下双手操作的高精度和高保真执行。

本文将该问题建模为隐式马尔可夫决策过程（MDP），在两个阶段均采用 PPO 算法以最大化折扣回报。在第一阶段，设计奖励函数，约束灵巧手跟随参考的人手轨迹，同时确保动作的稳定性和平滑性。其中，手指模仿奖励函数「鼓励」灵巧手的关键点位置与人手保持一致，特别是与物体接触最频繁的拇指、食指和中指的指尖位置是否对齐，此设计有效解决了形态不一致的问题。

在第二阶段，残差模块输出动作的补偿项，通过与第一阶段的动作相加，实现微调。该模块额外考虑了以下信息：1）物体的质心位置和所受重力，以增强对力矩的感知；2）基于空间基点集（BPS）表示的物体形状；3）灵巧手关键点与物体的空间位置关系；4）仿真环境提供的指尖接触力。第二阶段特别加入了接触力奖励函数，鼓励更加稳定的手物接触。在训练过程中，引入了随机参考状态初始化和课程学习策略，提高了收敛速度和训练稳定性。

综上，ManipTrans 的设计在第一阶段缓解人手与灵巧手之间的形态差异，在第二阶段捕捉细微的交互动作。通过将手指模仿与物理交互约束解耦，显著降低了动作空间的复杂度，同时提升了训练效率。本文在一系列复杂的单手和双手操作任务中，验证了该方法的有效性和高效性，任务甚至涵盖了铰链物体的操作。为评估该方法的泛化能力，本文进行了跨本体的实验，验证了 ManipTrans 可应用于具有不同自由度和形态的灵巧手，无需额外参数调节。此外，基于 ManipTrans 方法得到的双手操作数据，也在真机部署中得到了验证。

DexManipNet 数据集

图3. 灵巧手白板写字

图4. 双手舀取物体

基于 ManipTrans 方法，本研究将两个大型「手-物交互」数据集（OakInk V2 和 FAVOR）迁移至灵巧手，构建了 DexManipNet 数据集。该数据集涵盖了 61 种具有挑战性的任务，包含对 1200 多件物体的 3300 条灵巧手操作序列，总计约 134 万帧的数据量。其中，约有 600 个序列涉及复杂的双手操作任务（如图 3、图 4 所示），充分展示了机器人在高难度操作场景下的能力。

图5. 灵巧手拨开牙膏盖

图6. 双手协同完成倾倒入试管操作

此外，研究人员在真机平台上重放（replay）了 DexManipNet 的数据轨迹，使用了两台有 7 个自由度的机械臂和一对灵巧手，部署结果展示了此前未曾实现的精细灵巧操作能力。例如，在「拨开牙膏盖」的任务中，左手稳固握持牙膏管，右手的拇指和食指灵巧地拨开小巧的牙膏盖，这些细微而复杂的动作往往难以通过遥操作精确捕捉（如图 5、图 6 所示）。

实验结果

表1. ManipTrans与基线方法定量对比

本文将 ManipTrans 与两大类现有方法——基于强化学习的方法和基于优化的方法，进行了对比评估。结果显示，ManipTrans 在各项指标上均优于基线方法，展现了在单手和双手操作任务中的高精度（如表 1 所示）。定性和定量分析证实了，ManipTrans 的两阶段迁移框架能够有效捕捉手指的细微运动并与物体的交互，提高了任务成功率和运动的真实感。

图7. 跨本体迁移实验

图8. 双手操作铰链物体

此外，研究展示了 ManipTrans 在不同型号灵巧手上的可扩展性。该框架仅依赖人类手指与灵巧手关键点之间的对应关系，无需过多参数调整即可适配不同形态和自由度的灵巧手（如图 7 所示）。文章还在铰链物体操作数据集 ARCTIC 上进行了验证。通过对奖励函数的微调，添加铰链物体运动角度奖励，成功实现了灵巧手对铰链物体的指定角度旋转操作（如图 8 所示），展现了 ManipTrans 方法在复杂操作任务中的潜力。

#深度剖析25种RAG变体

本文全面、深入探讨了 25 种 RAG 变体。 从基本的标准 RAG 到 CRAT 和 Graph RAG 等高级框架 — 详细的架构、组件细分、流程和具体的代码级实现，以实现 LLM 的动态、实时增强。

主流RAG框架可以分为以下五个主要的进化方向：成本控制型（适合初创公司）、实时互动型（适用于财经/新闻场景）、域专家类型、认知增强型、安全与合规类型。接下来，让我们详细了解一下这25种RAG变体。

1. 标准RAG

一个基本的RAG系统由检索模块和生成模块组成。系统会对查询进行编码，检索相关的文档块，然后为基于transformer的LLM构建丰富的提示。

1. 查询编码器：使用预训练的转换器（例如DPR）生成密集的查询嵌入。代码实现如下：

from transformers import AutoTokenizer, AutoModel
import torch

tokenizer = AutoTokenizer.from_pretrained("facebook/dpr-question_encoder-single-nq-base")
model = AutoModel.from_pretrained("facebook/dpr-question_encoder-single-nq-base")

def encode_query(query: str) -> torch.Tensor:
    inputs = tokenizer(query, return_tensors="pt", truncatinotallow=True, max_length=128)
    return model(**inputs).pooler_output

1. 文档分割：将文档拆分为多个块（可以使用句子分词或滑动窗口的方法）。代码如下：

import nltk
nltk.download('punkt')
from nltk.tokenize import sent_tokenize

def segment_document(document: str, window_size: int = 5, overlap: int = 2) -> list:
    sentences = sent_tokenize(document)
    return [" ".join(sentences[i:i+window_size]) for i in range(0, len(sentences), window_size - overlap)]

1. 索引和检索：嵌入每个块并通过FAISS为它们编制索引。在查询期间，执行最近邻搜索。相关代码：

import faiss, numpy as np

def build_faiss_index(embeddings: torch.Tensor) -> faiss.IndexFlatL2:
    emb_np = embeddings.detach().cpu().numpy().astype('float32')
    d = emb_np.shape[1]
    index = faiss.IndexFlatL2(d)
    index.add(emb_np)
    return index

1. 提示构造函数和生成：将检索到的块与原始查询（使用特殊分隔符）相结合，并将提示传递给LLM（例如GPT-2/GPT-4）进行生成。代码如下：

def construct_prompt(query: str, retrieved_chunks: list) -> str:
    delimiter = "[DOC]"
    context = " ".join([f"{delimiter} {chunk} {delimiter}" for chunk in retrieved_chunks])
    return f"{query}\n{context}"

关键事实：标准RAG将外部知识动态注入生成过程，而无需修改LLM本身，就像是给LLM戴上了一副能随时获取新知识的“眼镜”。

2. 矫正RAG（CRAG）

CRAG在标准RAG的基础上增加了迭代反馈循环。它能够检测低置信度或不准确的输出，并重新查询外部知识库进行更正。

1. 初始生成：使用标准RAG生成初步答案。
2. 置信度评分：使用令牌级softmax概率评估输出。代码如下：

from transformers import AutoModelForCausalLM

gen_tokenizer = AutoTokenizer.from_pretrained("gpt2")
gen_model = AutoModelForCausalLM.from_pretrained("gpt2")

def generate_response(prompt: str, max_length: int = 200) -> str:
    inputs = gen_tokenizer.encode(prompt, return_tensors="pt", truncatinotallow=True, max_length=1024)
    outputs = gen_model.generate(inputs, max_length=max_length, num_beams=5, early_stopping=True)
    return gen_tokenizer.decode(outputs[0], skip_special_tokens=True)

def evaluate_confidence(output_ids: torch.Tensor) -> float:
    outputs = gen_model(output_ids, labels=output_ids)
    return torch.exp(-outputs.loss).item()

1. 反馈回路：如果置信度低于阈值，重新运行检索（可能会调整查询词）并重新生成答案。代码如下：

def iterative_crag(prompt: str, threshold: float = 0.8, max_iters: int = 3) -> str:
    current_prompt = prompt
    for _ in range(max_iters):
        response = generate_response(current_prompt)
        output_ids = gen_tokenizer.encode(response, return_tensors="pt")
        conf = evaluate_confidence(output_ids)
        if conf >= threshold:
            return response
        current_prompt += "\n[REFINE]"
    return response

关键事实：CRAG的迭代校正通过强制执行重新检索周期，直到输出达到预定义的置信度，从而最大限度地减少幻觉，让AI的回答更加靠谱。

3.Speculative

RAGSpeculative RAG采用双模型策略：轻量级专家模型起草多个候选回答，重量级通才模型验证并选择最佳候选。

1. 专家模型（制图）：从各种检索子集并行生成多个候选响应。代码：

def generate_candidates(prompt: str, num_candidates: int = 3) -> list:
    inputs = gen_tokenizer.encode(prompt, return_tensors="pt", truncatinotallow=True, max_length=1024)
    candidates_ids = gen_model.generate(inputs, max_length=200, num_return_sequences=num_candidates, num_beams=5)
    return [gen_tokenizer.decode(c, skip_special_tokens=True) for c in candidates_ids]

1. 通才模型（验证）：对每个候选项进行评分（使用似然或专门的验证指标）并选择最准确的一个。代码：

def select_best_candidate(candidates: list) -> str:
    best_candidate = None
    best_score = -float('inf')
    for candidate in candidates:
        inputs = gen_tokenizer.encode(candidate, return_tensors="pt", truncatinotallow=True, max_length=1024)
        outputs = gen_model(inputs, labels=inputs)
        score = torch.exp(-outputs.loss).item()
        if score > best_score:
            best_score = score
            best_candidate = candidate
    return best_candidate

def speculative_rag(prompt: str) -> str:
    candidates = generate_candidates(prompt, num_candidates=3)
    return select_best_candidate(candidates)

关键事实：通过将生成解耦为起草和验证，Speculative RAG利用并行性提高了速度和准确性，就像多个助手同时工作，然后挑选出最佳方案。

4. 融合RAG

Fusion RAG集成了多种检索策略和各种数据源，以丰富提示。它同时使用语义（密集嵌入）和词法（基于关键字）检索方法。

1. 混合检索：执行并行检索管道，一个使用密集嵌入，另一个使用传统的BM25或关键字匹配。代码如下：

# Placeholder for BM25 retrieval（e.g., using rank_bm25 library)
def bm25_retrieve(query: str, corpus: list, k: int = 5):
    from rank_bm25 import BM25Okapi
    tokenized_corpus = [doc.split() for doc in corpus]
    bm25 = BM25Okapi(tokenized_corpus)
    tokenized_query = query.split()
    scores = bm25.get_scores(tokenized_query)
    top_k = np.argsort(scores)[-k:]
    return top_k

def hybrid_retrieve(query: str, dense_index: faiss.IndexFlatL2, corpus: list, k: int = 5):
    query_emb = encode_query(query)
    _, indices_dense = retrieve_documents(query_emb, dense_index, k)
    indices_bm25 = bm25_retrieve(query, corpus, k)
    # Merge indices (simple union, can use weighted merging)
    merged_indices = list(set(indices_dense[0]).union(set(indices_bm25)))
    return merged_indices

1. 数据融合：根据相关性量度对从不同来源检索到的数据进行动态加权和合并。 关键事实：Fusion RAG通过结合多种技术最大限度地提高检索召回率和精度，提供更强大的外部环境，让AI能获取更全面的信息。

5. Agentic RAG

Agentic RAG采用模块化“代理”，专门用于特定任务，如查询重新表述、文档检索和响应合成，允许动态、实时调整。

1. 微服务架构：每个代理都作为独立的服务（通常通过REST API）运行，通过消息队列进行通信。
2. 动态协调：代理根据他人的反馈调整行动，例如，Query Reformulator可能会根据初始检索性能调整查询。代码如下：

import requests

def query_reformulator(raw_query: str) -> str:
    response = requests.post("http://agent-service/reformulate", jsnotallow={"query": raw_query})
    return response.json().get("reformulated_query", raw_query)

def document_retriever(query: str) -> list:
    response = requests.post("http://agent-service/retrieve", jsnotallow={"query": query})
    return response.json().get("documents", [])

def response_synthesizer(original_query: str, documents: list) -> str:
    payload = {"query": original_query, "documents": documents}
    response = requests.post("http://agent-service/synthesize", jsnotallow=payload)
    return response.json().get("response", "")

def agentic_rag(raw_query: str) -> str:
    reformulated_query = query_reformulator(raw_query)
    docs = document_retriever(reformulated_query)
    return response_synthesizer(raw_query, docs)

关键事实：Agentic RAG的分散式设计通过在专业服务之间划分检索生成过程，实现了精细的控制和可扩展性，就像一个分工明确的团队高效协作。

6. Self-RAG：开启LLM自我进化循环

Self-RAG是一种独特的RAG变体，它赋予LLM根据自身生成的响应检索上下文的能力，从而构建起一个迭代的自我提升循环，就像为模型注入了自我反思的“智慧”。

自我嵌入：精准定位知识短板

在初始生成阶段，模型会先依据输入生成一个初步的响应。随后，Self-RAG会对这个响应进行重新编码，这一过程被称为“自我嵌入”。通过自我嵌入，模型能够精准地识别出自身知识的缺口，明确哪些地方的信息还不够完善，哪些表述可能存在模糊之处。例如，在回答“2024年人工智能领域的重大突破有哪些”时，模型初步生成的答案中可能遗漏了部分关键突破，通过自我嵌入，就能发现这些缺失的信息。

内部反馈：知识检索补充信息

基于自我评估所发现的知识差距，模型会启动内部反馈机制。它会依据这些自我评估的结果，从外部知识库或自身存储的信息中检索额外的上下文信息。这一过程就像是模型在主动查阅资料，为自己补充“营养”，让回答更加全面和准确。比如，模型在发现自己对“2024年人工智能领域的重大突破”回答不足后，会去检索相关的学术论文、新闻报道等资料，获取更多详细信息。

迭代优化：反复打磨输出质量

在获取到额外的上下文信息后，Self-RAG会更新输入提示，并将其重新输入到模型中进行新一轮的生成。这个过程会不断重复，直到模型对输出结果的置信度达到较高水平。每一次迭代都是对答案的优化和完善，使得模型的输出更加精准、可靠。例如，经过多次迭代，模型对“2024年人工智能领域的重大突破”的回答可能会从最初的简单列举，变得详细且深入，涵盖突破的技术原理、应用场景以及对行业的影响等多方面内容。

代码示例：Self-RAG的实现逻辑

def self_rag(prompt: str, iterations: int = 3) -> str:
    current_prompt = prompt
    for _ in range(iterations):
        response = generate_response(current_prompt, gen_model, gen_tokenizer)
        response_emb = encode_query(response)
        additional_context = " [ADDITIONAL EVIDENCE REQUIRED]"
        current_prompt = f"{prompt}\n{additional_context}"
    return response

在这段代码中，​​self_rag​​​函数接收一个提示​​prompt​​​和迭代次数​​iterations​​​作为参数。在循环中，模型首先根据当前提示生成响应​​response​​​，接着对响应进行编码得到​​response_emb​​​ ，然后添加额外的上下文信息​​additional_context​​到当前提示中，最后返回最终的响应。通过这样的循环迭代，实现了Self-RAG的自我提升过程。

关键事实：减少依赖，提升自主性

Self-RAG的关键优势在于，它借助内部自我评估来迭代提升输出质量。一旦模型识别到足够的上下文信息，就能够减少对外部资源的依赖，在保证回答质量的同时，提升了模型的自主性和效率。这意味着在一些外部资源受限的场景下，Self-RAG依然能够给出高质量的回答，展现出更强的适应性和灵活性。

Self-RAG为LLM的发展开辟了新的路径，通过自我反思和优化机制，让模型在不断迭代中变得更加智能和可靠。在未来的人工智能应用中，Self-RAG有望在智能问答、文档生成等领域发挥重要作用，为用户提供更优质的服务和体验。

7. 自适应RAG：智能决策的RAG变体

自适应RAG的核心在于引入了一种门控机制，这种机制能够动态地决定模型是依靠自身内部的知识进行输出，还是调用外部检索来获取更全面的信息。这一设计就像是为模型配备了一个智能“开关”，使其能根据具体情况灵活调整策略，在保证回答质量的同时，最大限度地提高资源利用效率。

门控网络：精准评估，智能决策

门控网络是自适应RAG的关键组件之一，它基于内部标记概率来计算置信度分数。简单来说，模型会对输入的查询进行分析，根据自身对该查询的理解程度给出一个置信度数值。这个数值反映了模型对利用内部知识回答问题的信心。如果模型对某个问题非常“熟悉”，其内部知识足以给出可靠的答案，那么置信度分数就会较高；反之，如果模型觉得这个问题比较陌生，内部知识可能不足以准确回答，置信度分数就会较低。

动态切换：灵活应变，高效输出

基于门控网络计算出的置信度分数，自适应RAG会进行动态切换。当置信度低于设定的阈值时，系统会判定模型内部知识不足，进而触发外部检索。在外部检索过程中，模型会从预先构建的数据库或知识源中查找相关信息，以补充自身的知识储备。而当置信度高于阈值时，模型则会直接依赖内部知识进行回答，这样可以避免不必要的外部检索，节省计算资源和时间成本。

自适应提示：按需构建，精准引导

根据门控结果，自适应RAG会有条件地构建丰富的提示。如果触发了外部检索，模型会将检索到的相关信息与原始查询相结合，形成一个包含更多上下文的提示，为后续的回答生成提供更充足的信息。反之，如果直接依赖内部知识，提示则可能仅包含原始查询。这种自适应的提示构建方式，能够根据实际情况为模型提供最恰当的引导，帮助模型生成更准确、更符合需求的回答。

代码示例：直观展现，深入理解

def gating_decision(query: str, threshold: float = 0.85) -> bool:
    query_emb = encode_query(query)
    confidence = query_emb.norm().item() / 100
    return confidence < threshold

def adaptive_rag(query: str, dense_index: faiss.IndexFlatL2) -> str:
    if gating_decision(query):
        distances, indices = retrieve_documents(encode_query(query), dense_index, k=5)
        retrieved_docs = [chunks[i] for i in indices[0]]
        prompt = construct_prompt(query, retrieved_docs)
    else:
        prompt = query
    return generate_response(prompt, gen_model, gen_tokenizer)

在上述代码中，​​gating_decision​​​函数用于判断是否需要进行外部检索。它首先对查询进行编码得到​​query_emb​​​，然后通过计算​​query_emb​​​的范数并除以100来得到置信度​​confidence​​​，最后将置信度与阈值进行比较，返回判断结果。​​adaptive_rag​​​函数则根据​​gating_decision​​​的结果进行相应操作，如果需要外部检索，就执行检索、构建提示等步骤；如果不需要，则直接将原始查询作为提示。最后，调用​​generate_response​​函数生成回答。

关键事实：优化资源，提升性能

自适应RAG的关键优势在于，它能够根据实时的置信度测量来决定检索的必要性，从而实现对资源的优化利用。在面对大量查询时，这种方式可以避免模型在不必要的情况下进行复杂的外部检索，有效减少计算资源的消耗和响应时间，提升模型的整体性能。无论是在处理日常简单问题，还是应对复杂的专业领域问题时，自适应RAG都能根据具体情况做出最佳决策，为用户提供高效、准确的服务。

自适应RAG通过创新的门控机制和动态决策过程，为RAG技术的应用带来了更高的灵活性和效率。它在优化资源利用的同时，也提升了模型的性能表现，为大语言模型在更多领域的深入应用奠定了坚实基础。未来，随着技术的不断发展，自适应RAG有望在智能问答、信息检索等多个领域发挥更大的作用，为用户带来更加优质的体验。

8. REFEED（检索反馈）：优化回答的智慧“补丁”

REFEED，即检索反馈（Retrieval Feedback），是RAG技术中的一个重要变体，它通过在模型初始输出后反馈外部证据的方式，有效地“纠正”答案，从而显著提升生成响应的质量。这一技术为大语言模型在处理复杂问题时提供了更可靠的解决方案，让模型的回答更加准确和完善。下面，我们就来详细了解REFEED的工作原理、具体实现步骤以及它的关键优势。

初始生成：奠定基础，开启优化之旅

在REFEED的工作流程中，模型首先会根据输入的问题生成一个初步答案。这个初始答案是基于模型自身的知识和训练经验得出的，它为后续的优化提供了基础框架。虽然初始答案可能并不完美，但它包含了模型对问题的初步理解和分析，为进一步的改进指明了方向。

反馈检索：深度挖掘，填补知识缺口

得到初始答案后，REFEED会对这个答案进行深入分析，识别其中可能存在的信息差距或不准确之处。基于这些分析结果，模型会启动新的检索过程，从外部知识库或相关数据源中查找能够补充和完善答案的信息。例如，如果初始答案在某个关键知识点上表述模糊或缺失，反馈检索就会针对性地寻找相关的详细解释、案例或数据，以填补这些知识缺口。

输出优化：融合信息，打造精准回答

在获取到额外的上下文信息后，REFEED会将这些信息与原始提示进行合并，构建一个包含更丰富信息的新提示。然后，模型会基于这个新提示再次生成回答。通过这种方式，模型能够将新获取的知识融入到答案中，对初始答案进行优化和完善，从而生成一个更加准确、全面的最终回答。这种优化过程就像是为初始答案打上了一个个“补丁”，让答案的质量得到了显著提升。

代码示例：清晰呈现，掌握技术细节

def refeed_rag(query: str, dense_index: faiss.IndexFlatL2) -> str:
    initial_response = generate_response(query, gen_model, gen_tokenizer)
    feedback_query = f"{query} {initial_response}"
    distances, indices = retrieve_documents(encode_query(feedback_query), dense_index, k=5)
    additional_context = " ".join([chunks[i] for i in indices[0]])
    new_prompt = f"{query}\n[REFEED CONTEXT] {additional_context}"
    return generate_response(new_prompt, gen_model, gen_tokenizer)

在这段代码中，​​refeed_rag​​​函数实现了REFEED的核心逻辑。它首先调用​​generate_response​​​函数生成初始答案​​initial_response​​​，然后将初始答案与原始查询结合形成​​feedback_query​​​。接着，通过​​retrieve_documents​​​函数进行反馈检索，获取相关的上下文信息​​additional_context​​​。最后，将原始查询和新获取的上下文信息组合成新的提示​​new_prompt​​​，并再次调用​​generate_response​​函数生成优化后的回答。

关键事实：高效精准，无需重新训练

REFEED的关键优势在于，它能够在不重新训练模型的前提下，通过结合基于初始输出反馈的二次检索，显著提高回答的准确性。这种方式不仅避免了重新训练模型带来的高昂成本和时间消耗，还能让模型在面对新问题时快速适应，及时调整回答策略。无论是在处理突发的热点问题，还是解决专业性较强的复杂问题时，REFEED都能通过高效的反馈检索和输出优化机制，为用户提供更加准确、可靠的答案，提升用户体验。

REFEED作为RAG技术的重要变体，通过独特的检索反馈机制，为大语言模型的回答优化提供了一种高效、灵活的解决方案。它在不改变模型基础架构的情况下，有效提升了模型的回答质量，为智能问答、信息服务等领域带来了新的发展机遇。随着技术的不断进步，REFEED有望在更多场景中得到应用和拓展，为用户提供更加优质的知识服务。

9. REALM：检索融入语言建模的新探索

REALM将检索紧密集成到预训练和推理过程中，让模型从本质上就具备检索感知能力。

利用检索进行掩码语言建模

在预训练阶段，模型会对标记进行屏蔽，然后结合内部上下文与外部检索到的文档来预测这些标记。这一过程就像是模型在“学习”如何利用外部知识来填补文本中的空缺，从而提升对语言的理解和生成能力。

联合训练

检索器和生成器会以端到端的方式一起进行优化。在这个过程中，两者相互协作，检索器为生成器提供更丰富准确的信息，生成器则根据这些信息不断调整，使得整体模型在生成文本时更加准确和合理。

过程

• A）预训练：对标记进行屏蔽，并检索外部上下文信息，帮助模型学习如何利用外部知识来理解和生成文本。
• B）联合优化：通过反向传播算法，让检索器和生成器同时优化，以提高模型整体性能。
• C）推理：在生成文本的过程中，模型针对每个掩码标记向检索器发起查询，获取相关信息来生成更准确的内容。

实现细节

对transformer架构进行了修改，虽然具体代码因模型而异，但关键步骤包括：

• 在transformer模块中集成交叉注意力层，这一操作可以帮助模型更好地关注检索到的信息。
• 在训练时，基于预测的标记和检索输出共同计算损失函数，以此来引导模型学习到更有效的知识。

关键事实

REALM在训练阶段对架构进行修改，使得检索成为语言建模的内在组成部分，而不是在推理时才进行的附加操作。这一设计让模型在处理各种语言任务时，能够更自然、高效地利用外部知识，提升了模型的性能和泛化能力。

10. RAPTOR（递归抽象与树状结构检索）：构建层次化知识体系的检索利器

RAPTOR将大型文档组织成一个分层树结构，为检索和生成提供了多级抽象能力。

文档分块和聚类

利用k-means等算法对文档进行分段处理，并将相似的数据块聚集在一起。这一步就像是把一本厚厚的书按照主题和内容相似性分成不同的章节和段落，方便后续快速查找和管理。

树构造

通过递归地汇总聚类结果，构建出分层树。在这个树结构中，每个节点都代表了一定层次的信息汇总，从宏观到微观，形成了一个有序的知识体系。

分层检索

在查询时，模型会遍历这棵树，既可以获取高级别的摘要信息，也能深入到细节层面获取精细的内容。这就好比在查阅一本目录清晰的书籍时，既能快速了解各章节的核心要点，又能根据需要深入阅读具体段落。

def cluster_chunks(embeddings: torch.Tensor, num_clusters: int = 10):
    from sklearn.cluster import KMeans
    emb_np = embeddings.detach().cpu().numpy()
    kmeans = KMeans(n_clusters=num_clusters)
    labels = kmeans.fit_predict(emb_np)
    return labels, kmeans.cluster_centers_


def build_tree(chunks: list, labels: list):
    tree = {}
    for label in set(labels):
        tree[label] = [chunks[i] for i, lab in enumerate(labels) if lab == label]
    return tree


# 在查询时：
def tree_retrieve(query: str, tree: dict):
    aspects = query.split()  # 用于适当分解的占位符
    retrieved = []
    for aspect in aspects:
        for key, docs in tree.items():
            if aspect.lower() in " ".join(docs).lower():
                retrieved.extend(docs)
    return list(set(retrieved))


# 使用方法：
labels, _ = cluster_chunks(chunk_embeddings, num_clusters=10)
raptor_tree = build_tree(chunks, labels)
tree_docs = tree_retrieve(query, raptor_tree)
raptor_prompt = construct_prompt(query, tree_docs)
raptor_response = generate_response(raptor_prompt, gen_model, gen_tokenizer)

关键事实

RAPTOR的多级检索策略，能够同时提供广泛和详细的上下文信息，这对于需要深入推理的任务来说至关重要。通过这种树状结构的组织和检索方式，模型可以更全面、准确地理解问题，并给出更有深度和准确性的回答。

11. REVEAL（检索增强视觉语言预训练）：开启多模态检索新时代

REVEAL通过将视觉和文本数据整合到统一的表示形式中，把RAG技术拓展到了多模态领域。

多模态编码

使用共享编码器将图像和文本映射到同一个嵌入空间，使得模型能够在同一“语言”下理解和处理不同模态的数据。这就像是为图像和文本搭建了一座沟通的桥梁，让它们可以在模型内部自由交互。

动态检索

可以同时检索与上下文相关的文本和视觉信息，为模型生成内容提供更丰富的素材。比如在描述一幅图片时，模型不仅能根据图片本身的特征，还能结合相关的文本描述来生成更准确、生动的内容。

融合机制

在transformer架构中利用注意力层来整合多模态数据。注意力层就像是模型的“聚焦器”，可以让模型根据任务需求，有重点地关注不同模态的数据，从而更好地融合它们。

实现细节

• 对于图像-文本对，可以借助CLIP等模型获取联合嵌入，让图像和文本在嵌入空间中建立紧密联系。
• 检索过程与标准RAG类似，但操作的是混合数据库，其中包含了转换为嵌入形式的图像和文本数据。

关键事实

REVEAL的架构专门针对跨模态检索进行了优化，这对于视觉问答、图像描述等多模态任务来说至关重要。它让模型能够充分利用不同模态的数据信息，生成更加准确和丰富的回答，为多模态人工智能应用开辟了新的道路。

12. ReAct（推理和行动）：推理与行动交织的智能模式

ReAct将推理与明确的行动交织在一起，使模型在生成过程中能够执行诸如API调用等操作。

思维链生成

模型会生成一个包含推理步骤的解释序列，展示其思考过程。这就好比一个人在解决问题时，会逐步阐述自己的思路，让他人能够理解其思考逻辑。

行动令牌

通过特殊的标记，指示模型执行特定的操作，例如查询数据库获取相关信息。这些标记就像是模型的“行动指令”，引导模型与外部资源进行交互。

集成跟踪

最终输出不仅包含推理的路径，还包括执行行动的结果。这样可以让用户清楚地看到模型是如何思考以及根据思考采取了哪些行动，结果又是什么。

def generate_with_actions(prompt: str) -> str:
    inputs = gen_tokenizer.encode(prompt, return_tensors="pt", truncatinotallow=True, max_length=300)
    outputs = gen_model.generate(inputs, max_length=300, num_beams=5)
    return gen_tokenizer.decode(outputs[0], skip_special_tokens=True)

关键事实

ReAct的交错设计需要精心设计提示工程，以便在同一生成周期内同时触发推理和可执行的输出。这种设计让模型能够在思考的同时采取实际行动，获取更多信息来完善回答，提升了模型的实用性和智能性，但也对提示设计提出了更高的要求。

13. REPLUG（检索插件）：无损增强大语言模型的便捷方式

REPLUG把大语言模型视为一个“黑匣子”，在不修改模型的前提下，通过在输入前添加外部检索到的文档来增强其输入内容。

外部检索

利用像FAISS这样独立的检索系统来收集相关文档，为模型提供丰富的外部知识支持。这就好比给模型配备了一个强大的“知识助手”，帮助它获取更多信息。

提示增强

将检索到的文档添加到查询前面，在保持大语言模型原始架构不变的情况下，丰富模型的输入内容，引导模型生成更好的回答。

模型调用

把增强后的提示输入到大语言模型中，让模型基于这些丰富的信息进行处理和生成。

def replug_rag(query: str, dense_index: faiss.IndexFlatL2) -> str:
    query_emb = encode_query(query)
    _, indices = retrieve_documents(query_emb, dense_index, k=5)
    retrieved = [chunks[i] for i in indices[0]]
    enriched_prompt = construct_prompt(query, retrieved)
    return generate_response(enriched_prompt, gen_model, gen_tokenizer)

关键事实

REPLUG提供了一种模块化的方法，通过外部检索提升大语言模型的性能，同时保持核心模型不变。这种方式简单高效，方便在不同场景中快速应用，为优化大语言模型的表现提供了一种便捷途径。

14. Memo RAG：融合记忆机制的智能检索增强

Memo RAG集成了一个内存组件，它能将大型数据集压缩成“全局内存”，并生成检索线索来引导外部搜索。

内存模块

运用知识蒸馏等技术压缩大型数据集，将海量的信息浓缩成更易于管理和使用的形式，存储在“全局内存”中。

线索生成

针对给定的查询，模型会生成检索提示，这些提示就像“线索”一样，帮助模型在外部搜索时更精准地定位相关信息。

上下文集成

将生成的线索与检索到的数据进行合并，构建最终的提示，为模型生成回答提供更有针对性的信息。

# 假设memory_module是一个预训练模块，具有generate_clue方法。
def memo_rag(query: str, dense_index: faiss.IndexFlatL2, memory_module) -> str:
    clue = memory_module.generate_clue(query)
    feedback_query = f"{query} {clue}"
    _, indices = retrieve_documents(encode_query(feedback_query), dense_index, k=5)
    retrieved = [chunks[i] for i in indices[0]]
    prompt = construct_prompt(query, retrieved)
    return generate_response(prompt, gen_model, gen_tokenizer)

关键事实

Memo RAG借助内部内存机制提高了外部检索的精度，尤其在处理模糊或复杂查询时表现出色。通过生成线索引导检索，模型能够更准确地找到相关信息，从而生成更符合需求的高质量回答。

解锁RAG的进阶奥秘：ATLAS及其他变体深度解析

在检索增强生成（RAG）技术的不断演进中，诞生了诸多创新的变体，为大语言模型（LLM）的发展注入了新的活力。今天，让我们一同深入探索从15. ATLAS开始的多种RAG变体，揭开它们提升模型性能的神秘面纱。

15. ATLAS（基于注意力的RAG）：检索与注意力的深度融合

ATLAS的独特之处在于，它将检索与注意力机制巧妙融合，通过把检索到的文档直接整合到transformer的注意力层，让模型在处理文本时能够更充分地利用外部知识。

• 密集嵌入与检索：ATLAS运用密集嵌入技术，从海量数据中精准检索出语义相似的文档，为后续的处理提供丰富的信息来源。
• 交叉注意力集成：在编码器 - 解码器框架内，ATLAS借助交叉注意力层，将检索到的上下文信息无缝融入到模型的处理过程中，使得模型在生成文本时能够更好地关注相关信息。
• 联合优化：为了实现更高效的信息整合，ATLAS对检索器和生成器进行联合训练，确保两者协同工作，优化整体性能。
• 实现细节：在技术实现上，ATLAS对transformer架构进行了优化，新增的交叉注意力层将检索到的嵌入作为键和值。这里运用到的标准注意力公式为：

def scaled_dot_product_attention(Q, K, V, mask=None):
    import math
    d_k = Q.size(-1)
    scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(d_k)
    if mask is not None:
        scores = scores.masked_fill(mask == 0, -1e9)
    attention_weights = torch.softmax(scores, dim=-1)
    output = torch.matmul(attention_weights, V)
    return output, attention_weights

其中，和均来自检索到的数据。

• 关键事实：ATLAS的设计将外部上下文紧密地与令牌级预测相结合，这一特性使得模型在处理知识密集型任务时表现卓越，显著提升了性能。

16. RETRO（检索增强变压器）：Transformer架构中的检索创新

RETRO另辟蹊径，将检索功能融入transformer的架构之中。它把输入文本划分为固定大小的块，然后利用交叉注意力机制从外部数据库中查找相似序列。

• 块分割：首先，RETRO会把输入文本切割成固定大小的块，为后续的检索和处理做好准备。
• 最近邻检索：针对每个文本块，RETRO使用FAISS等工具从大型索引语料库中检索相似的块，获取相关信息。
• 交叉注意力层：通过额外的交叉注意力机制，RETRO将检索到的块融入到文本生成过程中，增强模型对信息的利用效率。

def retro_retrieve(block_embedding, index, k=5):
    distances, indices = index.search(block_embedding.detach().cpu().numpy().astype('float32'), k)
    return indices

output = scaled_dot_product_attention(Q, K, V)[0]

• 关键事实：RETRO通过在令牌生成阶段高效整合外部信息，成功实现了以较少的参数提升模型性能的目标。

17. 自动RAG：自主优化的迭代循环

自动RAG引入了自主迭代循环机制，模型能够自我评估输出，并根据评估结果决定是否需要进一步检索。

• 自我评估：在初始生成文本后，自动RAG模型会对输出的置信度进行评估，判断当前答案的可靠性。
• 动态迭代：如果输出置信度较低，模型会触发额外的检索循环，并更新提示信息，再次生成文本，不断优化答案。
• 终止标准：这一过程会持续进行，直到模型输出达到预设的收敛阈值，确保最终答案的质量。

def auto_rag(prompt: str, max_iterations: int = 3, threshold: float = 0.8) -> str:
    current_prompt = prompt
    for i in range(max_iterations):
        response = generate_response(current_prompt, gen_model, gen_tokenizer)
        output_ids = gen_tokenizer.encode(response, return_tensors="pt")
        conf = evaluate_confidence(output_ids)
        if conf >= threshold:
            break
        current_prompt += "\n[RETRIEVE_MORE]"
    return response

• 关键事实：自动RAG基于内部置信度评估，通过自动化的迭代重新检索循环，有效提升了输出质量。

18. CORAG（成本受限的RAG）：资源约束下的检索优化

CORAG聚焦于在资源受限的环境中优化检索过程，它采用蒙特卡洛树搜索（MCTS）等策略，平衡检索质量与计算成本。

• MCTS检索：CORAG将候选检索组合视为搜索树中的节点，通过MCTS算法对这些节点进行探索，寻找最优的检索方案。
• 成本建模：为了控制计算成本，CORAG引入成本函数，对高成本的检索路径进行惩罚，引导模型选择更经济高效的检索方式。
• 自适应配置：在资源限制的前提下，CORAG会选择能够最大化检索质量的配置，确保在有限资源下实现最佳检索效果。

def mcts_retrieval（query: str, index: faiss.IndexFlatL2, iterations: int = 10):
    best_set = None
    best_score = -float('inf')
    for _ in range(iterations):
        candidate_set = sample_candidate_set(index)
        quality = evaluate_candidate_quality(candidate_set, query)
        cost = evaluate_candidate_cost(candidate_set)
        score = quality - cost
        if score > best_score:
            best_score = score
            best_set = candidate_set
    return best_set

• 关键事实：CORAG的成本感知优化策略，确保了在资源有限的场景下，检索过程依然高效且有效。

19. EACO - RAG（边缘辅助和协作RAG）：分布式检索的新范式

EACO - RAG借助边缘计算的优势，将检索过程分布到各个边缘节点，有效降低延迟并平衡计算负载。

• 本地知识库：每个边缘节点都维护着本地化且及时更新的索引，方便快速检索本地相关信息。
• 协作检索：边缘节点之间通过消息队列进行通信，协同完成检索任务，实现资源的高效利用。
• 贝叶斯多臂强盗算法：为了动态分配资源，EACO - RAG采用贝叶斯多臂强盗算法，根据节点的实时性能指标，合理分配检索任务。

def edge_retrieve(query: str, local_index: faiss.IndexFlatL2) -> list:
    q_emb = encode_query(query)
    _, indices = retrieve_documents(q_emb, local_index, k=5)
    return [chunks[i] for i in indices[0]]

def collaborative_retrieve(query: str, edge_indices: list) -> list:
    results = []
    for idx in edge_indices:
        results.extend(edge_retrieve(query, idx))
    return rank_results(results)

• 关键事实：EACO - RAG利用分布式计算，在大规模部署中实现了低延迟、可扩展的检索。

20. 规则RAG：特定领域的精准检索

规则RAG通过应用明确的特定领域规则，指导检索和合成过程，确保最终输出仅包含高度相关的文档信息。

• 规则引擎：规则RAG使用Python或外部规则引擎，实施确定性规则，对文档进行筛选和排序。
• 检索前后过滤：在检索前，规则用于优化查询条件；检索后，规则则对检索结果进行进一步筛选，确保输出的相关性。

def apply_rules(query: str, documents: list, keyword: str = "RAG") -> list:
    return [doc for doc in documents if keyword.lower() in doc.lower()]

def rule_rag(query: str, dense_index: faiss.IndexFlatL2) -> str:
    _, indices = retrieve_documents(encode_query(query), dense_index, k=10)
    raw_docs = [chunks[i] for i in indices[0]]
    filtered_docs = apply_rules(query, raw_docs, keyword="RAG")
    prompt = construct_prompt(query, filtered_docs)
    return generate_response(prompt, gen_model, gen_tokenizer)

• 关键事实：规则RAG的确定性筛选机制，通过严格的标准确保只有符合要求的文档才会参与最终输出，极大地增强了在专业领域的相关性。

21. 对话式RAG：多轮对话的智能伙伴

对话式RAG专为多轮对话系统设计，它能够根据对话历史持续更新检索上下文，提供更符合对话情境的回答。

• 上下文跟踪：对话式RAG会维护一个对话历史缓冲区，记录每一轮对话的内容。
• 动态检索：在每一轮对话中，它会结合累积的上下文信息，查询外部数据源，获取更全面的信息。
• 集成合成：将对话历史与新检索到的内容进行融合，生成连贯、准确的回复。

def conversational_rag(dialogue_history: list, query: str, dense_index: faiss.IndexFlatL2) -> str:
    context = " ".join(dialogue_history)
    full_query = f"{context} {query}"
    _, indices = retrieve_documents(encode_query(full_query), dense_index, k=5)
    retrieved = [chunks[i] for i in indices[0]]
    prompt = construct_prompt(full_query, retrieved)
    return generate_response(prompt, gen_model, gen_tokenizer)

• 关键事实：对话式RAG能够在多轮交互中保留上下文信息，实现动态检索，准确反映整个对话的意图。

22. 迭代RAG：精益求精的答案优化

迭代RAG通过多次检索和生成循环，不断优化响应，直至答案满足预设的收敛标准。

• 初始生成：首先生成一个基线响应，作为后续优化的基础。
• 差距分析：对基线响应进行分析，找出其中置信度较低或缺失信息的部分。
• 细化循环：针对这些差距重新进行查询，并迭代更新提示信息，逐步完善答案。

def iterative_rag(query: str, dense_index: faiss.IndexFlatL2, max_iters: int = 3) -> str:
    current_prompt = query
    for _ in range(max_iters):
        response = generate_response(current_prompt, gen_model, gen_tokenizer)
        if "unclear" not in response:
            return response
        _, indices = retrieve_documents(encode_query(response), dense_index, k=5)
        additional_context = " ".join([chunks[i] for i in indices[0]])
        current_prompt = f"{query}\n{additional_context}"
    return response

• 关键事实：迭代RAG的重复循环机制，对于复杂或多方面的查询，能够有效提升响应质量。

23. 上下文驱动的树状结构检索：复杂查询的拆解与解答

这种RAG变体将复杂查询分解为子查询的树状层次结构，全面探索问题的各个方面。

• 方面分解：把复杂查询解析为多个子主题，明确问题的不同维度。
• 树构造：按照层次结构组织这些子主题，每个分支代表一个特定的方面。
• 分支检索与聚合：针对每个分支独立检索文档，最后将结果合并，给出全面的答案。

def decompose_query(query: str) -> list:
    # 为演示目的，按标点分割；如有需要，可替换为高级主题建模方法
    return query.split(";")

def tree_retrieve(aspects: list, dense_index: faiss.IndexFlatL2) -> list:
    tree_results = []
    for aspect in aspects:
        _, indices = retrieve_documents(encode_query(aspect), dense_index, k=3)
        tree_results.extend([chunks[i] for i in indices[0]])
    return list(set(tree_results))

def tree_rag(query: str, dense_index: faiss.IndexFlatL2) -> str:
    aspects = decompose_query(query)
    tree_docs = tree_retrieve(aspects, dense_index)
    prompt = construct_prompt(query, tree_docs)
    return generate_response(prompt, gen_model, gen_tokenizer)

• 关键事实：树状结构的方法确保了复杂查询的每个方面都能得到处理，最终生成更全面的回复。

24. CRAT（因果增强反射翻译）：翻译领域的智能升级

CRAT将检索和因果推理融入翻译过程，有效处理模糊或特定领域的术语翻译。

• 未知术语检测：首先识别可能在翻译中存在问题的术语，为后续处理做准备。
• 双语知识图谱构建：构建一个双语知识图谱（TransKG），映射术语及其跨语言关系。
• 因果反思：运用因果推理验证检索到的翻译是否符合上下文语境。
• 最终翻译合成：将经过验证的外部数据与模型内部的翻译输出进行融合，得出最终准确的翻译结果。

def detect_unknown_terms(text: str) -> list:
    return [word for word in text.split() if word.isupper()]

def construct_transkg(terms: list) -> dict:
    return {term: f"translated_{term}" for term in terms}

def crat_translate(text: str) -> str:
    unknown_terms = detect_unknown_terms(text)
    transkg = construct_transkg(unknown_terms)
    for term, translation in transkg.items():
        text = text.replace(term, translation)
    return text

• 关键事实：CRAT通过整合经过因果推理验证的外部双语信息，确保了翻译的准确性。

25. Graph RAG：结构化知识的力量

Graph RAG借助结构化知识图谱，捕捉实体之间的关系，并将这些结构化上下文融入文本生成过程。

• 实体和关系提取：使用命名实体识别（NER）和关系提取工具（如SpaCy）解析文档，提取其中的实体和关系。
• 知识图谱构建：利用NetworkX或Neo4j等工具构建知识图谱，直观呈现实体间的联系。
• 图嵌入和遍历：通过图神经网络（GNN）生成节点嵌入，并遍历图谱，找到与上下文相关的子图。
• 提示增强：将结构化的图谱数据（如关键实体、关系）融入提示信息，辅助模型生成更准确的文本。

import spacy, networkx as nx
nlp = spacy.load("en_core_web_sm")

def extract_entities_relations(text: str) -> (list, list):
    doc = nlp(text)
    entities = [ent.text for ent in doc.ents]
    relations = [(entities[i], entities[j]) for i in range(len(entities)) for j in range(i+1, len(entities))]
    return entities, relations

def build_graph(documents: list) -> nx.Graph:
    G = nx.Graph()
    for doc in documents:
        entities, relations = extract_entities_relations(doc)
        for entity in entities:
            G.add_node(entity)
        for (e1, e2) in relations:
            G.add_edge(e1, e2)
    return G

def graph_based_prompt(query: str, G: nx.Graph) -> str:
    relevant_nodes = [node for node in G.nodes if node.lower() in query.lower()]
    graph_context = " ".join(relevant_nodes)
    return f"{query}\n[GRAPH_CONTEXT] {graph_context}"

• 关键事实：图形RAG通过将结构化关系融入生成提示，提供了更深入的上下文理解，提高了复杂信息检索的准确性。

#Transformers PR代码完全解读

Qwen3超前分析报告

最近，在 transformers 的代码中可以看到关于Qwen3的PR在3月21日时被提交，并在最近被合并进了主分支了。在src/transformers/models/可以找到已经更新的Qwen3的代码。

Transformers项⽬中上Qwen3的PR

虽然网上有几篇针对 Qwen3 模型的 PR 代码分析文章，但是笔者发现绝大多数都是使用 LLM 生成的文章，许多内容都是错误或者具有严重的误导性，因此笔者仅自己所能对代码做了细致的分析和考证。

本文我们将根据Qwen3的稠密模型和MoE模型相较于于原来模型的差异，说下笔者的一些观点、猜测和想法，同时也希望阅读本文的读者也可以学习到如何比对模型结构变化。

本文撰写于4月21日，后期如果Qwen3的技术报告发布，我们也会持续跟进分析。对文章中的分析可能存在不足的地方，欢迎大家讨论和提出改进意见。如发现错误或者不足之处也可以通过邮件 contact@swanlab.cn 告知笔者～

改进总结

首先，我们先速览一下，Qwen3 相比 Qwen2/2.5 改进了哪些地方（根据公开信息）。具体细节如下表所示：

1. Qwen3和Qwen3MoE模型的Attention层中都对q和k进行了归一化处理
2. Qwen3-8B的模型参数量比Qwen2.5-7B增加了约1B
3. Qwen3和Qwen3MoE模型默认支持滑动窗口缓存
4. Qwen3MoE模型集成transformers框架的flash-attention模块
5. Qwen3MoE删除了共享专家模式

前置知识Qwen2、Qwen2.5、Qwen3模型规格一览

笔者做了一个表格，方便大家直接了解Qwen2到Qwen3系列模型的模型架构和参数分布分布。

⚠️注意：截止本文撰写日期为止，Qwen3系列并未公开其权重，因此上表Qwen3、Qwen3-MoE为代码中已公开大小，实际上种类应该会更为丰富。​

Qwen2.5相比于Qwen2

Qwen2.5相比于Qwen2在训练阶段使用了不同的数据集，然后对模型的初始参数修改了下，结构上直接使用Qwen2的结构，而Qwen2.5的技术报告剩下的50%基本都在讲和其他模型的对比评估结果，因此Qwen2.5的技术报告给出的信息较少，总结下面几点：

1. 预训练数据集增加，从Qwen2的7T tokens增加到18T tokens。
2. 模型支持高达 128K 的上下文长度，可生成最多 8K 内容，并拥有强大的多语言能力，支持 29 种以上语言。
3. 在数学推理等问题上相比于其他的主流模型评分要高。

Qwen2相比于Qwen2MoE

稠密模型（比如Qwen3、Qwen2.5系列模型等）是在模型的结构或激活过程中，全部参数或模块被激活；稀疏模型（MoE模型）在模型的结构或激活过程中，只有部分参数或模块被激活，而不是全部。之所以使用MoE模型，是因为其训练时计算速度比稠密模型要快，而且在相同激活参数条件下MoE收敛速度快，适合大规模训练，因此Qwen2除了有稠密模型也有稀疏模型。

需要注意的是，我们通常所见的MoE（Mixture of Experts，混合专家模型）是稀疏模型的一种具体实现，它通过将复杂的任务分解为多个子任务，并由多个“专家”模型分别处理这些子任务。MoE的核心思想是通过稀疏激活机制，仅激活部分专家来处理当前输入，从而提高计算效率。混合专家模型的一个显著优势是它们能够在远少于稠密模型所需的计算资源下进行有效的预训练。这意味着在相同的计算预算条件下，您可以显著扩大模型或数据集的规模。特别是在预训练阶段，与稠密模型相比，混合专家模型通常能够更快地达到相同的质量水平。

笔者这里打个比方，稠密模型可以类比于一个专家来处理所有tokens的训练，那么如果用一块卡来训练的话，这里可以假设显存占用率有80%，而稀疏模型有多个专家，每个专家在训练过程中可能只负责其中的几个tokens，比如输入总共是100tokens的话，那么假设有10个专家，假设每个专家处理相同数量的tokens，那么每个专家可能只负责处理其中10个tokens，假设每个专家分别挂载到不同的卡上，那么每个专家的显存占用率可能只有8%（参考稠密模型的），这样可以明显降低计算资源，提高训练效率，但是需要注意的是，由于不同专家分配到了不同的设备上，因此对卡间带宽的要求较高。

简单来说：

稀疏 VS 稠密

• 与稠密模型相比， 预训练速度更快
• 与具有相同参数数量的模型相比，具有更快的 推理速度
• 需要 大量显存，因为所有专家系统都需要加载到内存中
• 在 微调方面存在诸多挑战，但 近期的研究 表明，对混合专家模型进行 指令调优具有很大的潜力。
• 稀疏模型适用于拥有多台机器且要求高吞吐量的场景。在固定的预训练计算资源下，稀疏模型往往能够实现更优的效果。相反，在显存较少且吞吐量要求不高的场景，稠密模型则是更合适的选择。
• Qwen2与Qwen2MoE的代码层面改动

Qwen2MoE相比于Qwen2仅有FFN处进行了改动，Qwen2MoE将原有的MLP处改成了只要专家数量>0就走Qwen2MoeSparseMoeBlock函数也就是混合专家模块，并且需要注意的是，该模块使用了共享专家机制，该机制是DeepSeek团队在V2技术报告里提到的，如下图所示：

共享专家机制简介：传统路由策略中，分配给不同专家的Token可能蕴含一些通用知识或信息。不同的专家可能会在各自的参数中获得这些通用知识，从而导致专家参数的冗余。若有专门的共享专家来捕捉和整合上下文中的通用知识，将缓解其他路由专家之间的参数冗余。这种冗余参数的减少有助于由更专业的专家构建更加参数高效的模型。为实现该目标，deepseek团队在细粒度专家划分的基础上进一步隔离一部分专家作为共享专家。无论路由模块如何，每个Token都将会被送入这部分共享专家。为保证恒定的计算成本，激活的路由专家将减少相应的数量，如上图所示。

不过根据Qwen3提交的PR代码来看，Qwen3MoE中取消了共享专家机制，这个在后文有所分析。​

Qwen3的改动

我们直接可以对比下transformers集成代码中，位于src/transformers/models的Qwen2和Qwen3中的modeling_qwen.py文件看看具体代码信息变动。根据代码分析此次模型的变动如下：

1、模型任务领域

从下图中可以看出，Qwen3系列模型应该是文本模型而非图文模型，并且发布稠密模型和混合专家模型，目前没有看到有vl模型还有O模型（端到端多模态模型）的代码更新。

当然，由于Qwen2.5发布了O模型（Qwen2.5-Omini），笔者也认为Qwen3会有多模态模型的更新，目前还没有和transformers进行集成，可能要再等一段时间，之前的Qwen2的vl模型和文本模型相差了一个多月，那么如果Qwen3有vl的模型的更新，笔者猜测应该要需要等文本模型更新后了。

PS:
Qwen2.5似乎有些pr，看了之后感觉是把一些模型的名字改了下，没有结构上的大修改，因此不必在意，我们就只看下Qwen3即可。

2、注意力机制改动

我们从代码对比中可以看到，在attention部分的初始化定义了归一化部分，使用的是RMSNorm函数，和Qwen2一样，但是在原Qwen2中是的DecoderLayer才有，是对到attention层和mlp层的输入进行归一化，这种归一化方式通过去除输入的尺度差异，提升了训练的稳定性和收敛速度，同时增强了模型对不同尺度输入的适应性，从而提高泛化能力。公式如下：

Attention(Q,K,V)=Softmax(\frac{RMSNorm(Q)·RMSNorm(K)^T}{\sqrt{d_k}})·V

使用​​RMSNorm​​​的原因估计是降低计算成本，因为​​RMSNorm​​仅需进行一次平方和、一次平方根和一次除法运算，这使得相比其他正则化方法其在计算上更加高效，因此在LLM上更受欢迎（此前Qwen2、包括新的LLaMA都使用了RMSNorm）。

Qwen3在attention层中对输入进行进一步的归一化处理，这里笔者猜测可能是想进一步提升训练的稳定性，笔者估计这么做的原因是因为Qwen3的模型参数（尤其是层数）方面会有进一步增长。

• 具体代码：

## 初始化部分
self.q_norm = Qwen3RMSNorm(self.head_dim, eps=config.rms_norm_eps)
self.k_norm = Qwen3RMSNorm(self.head_dim, eps=config.rms_norm_eps)
## 前向传播
query_states = self.q_norm(self.q_proj(hidden_states).view(hidden_shape)).transpose(1, 2)
key_states = self.k_norm(self.k_proj(hidden_states).view(hidden_shape)).transpose(1, 2)

• 用结构图展示下具体变动，其中红色部分是修改的地方：

3、模型参数量

在模型结构中一般不太会写模型参数量，一般都是在设定参数的时候才有，但是我们可以从代码中找到一点相关信息。

看样子有个8B参数量的模型，然后我们可以从Qwen2.5的模型仓库中发现没有8B参数量的模型，然后一般src/transformers/models/configuration_qwen2.py是模型结构参数初始化的文件，而观察了configuration_qwen3相比于configuration_qwen2的初始化参数后发现好像只更改了名字，虽然新增加了head_dim，但是和原来的是一样的，同时新增加了attention_bias参数，原来是默认的False，如下图所示。

所以从初始化参数看不出为什么Qwen3是个8B的模型，而不是原来7B的。

这里笔者猜测一下此次变大的原因——主要是Embedding层参数量占比过高导致的。根据Qwen2.5的技术报告来看，Qwen2.5的Embedding层的词表大小148k大小左右，占据了7B参数量的接近7%，约为0.5B，换句话说No-embedding参数量仅为6.5B。这导致了Qwen2.5模型相比于同代数的是模型如Gemma2-9B（No-embedding参数8.2B）或者Llama3-8B（No-embedding参数7.5B）参数量要小得多。

笔者猜测Qwen团队在构建Qwen2系列模型时为了维持模型7B的参数量，模型是做了部分删减的。这在Qwen的层数也能看出来——Qwen2.5-7B仅有28层，维度也仅为3584，对比Llama3-8B的层数32，维度为4096要小得多。因此在Qwen3的设计中，估计Qwen团队将直接让其No-embedding参数与业界主流模型保持一致，来取得更优秀的效果。

从这个稠密模型的参数量相比于Qwen2的变化来看，估计模型仓库里的模型整体上都有参数量的提高（相比于Qwen2或2.5系列单个模型多0.1B-1B左右）。

关于LLM的参数配置，有一篇很有意思的论文MobileLLM做了详细的研究和实验。 Scaling Law在小模型中有自己独特的规律。 引起Transformer参数成规模变化的参数几乎只取决于​​d_model​​​和​​n_layers​​

• ​​d_model​​​↑ + ​​n_layer​​s↓ -> 矮胖子
• ​​d_model​​​↓ + ​​n_layers​​↑ -> 瘦高个

MobileLLM提出在较小的模型上深度比宽度更重要，「深而窄」的「瘦长」模型可以学习到比「宽而浅」模型更多的抽象概念。 例如当模型参数固定在125M或者350M时，30～42层的「狭长」模型明显比12层左右的「矮胖」模型有更优越的性能， 在常识推理、问答、阅读理解等8个基准测试上都有类似的趋势。不过这种趋势一般存在于较小的模型，在较大的模型上比例关系对于性能的影响并非非常明显。

1. 明确支持滑动窗口（sliding window）机制
2. 在 Qwen3Attention 类中，Qwen3 明确检查了是否启用了滑动窗口机制，并在必要时调整了注意力的计算方式。
3. 具体代码：

这里应该只是改成了初始化部分定义，能更方便调用，并且和原来不一样的是，Qwen3的滑动窗口是默认开启，原来Qwen2是默认不用滑动窗口，如果当前层的索引小于 ​​max_window_layers​​，则表示当前层不在滑动窗口机制的范围内，因此也禁用滑动窗口机制。滑动窗口机制通常用于处理长序列数据，以提高计算效率和减少内存占用。

笔者猜测使用默认滑动窗口的原因是Qwen3将支持更长的上下文长度（业内比如MiniMax上下文长度支持到了恐怖的4M，Llama4 Scout更是到了10M，而DeepSeek-V3的文本长度也达到了128k），Qwen3的文本长度大概率会持平或者超过128k。更长的上下文本长度对于采用R1这种强化学习训练方法更有帮助，比如Llama4文本长度达到了256K，因此此次Qwen3很可能会进一步升级文本长度。

4、Qwen3MoE相比于Qwen2MoE

参数量变化

图9.Qwen2-MoE模型和Qwen3-MoE模型的结构代码对比(模型参数量部分)

根据提交的代码来看，Qwen3MoE模型的最小参数量将达到15B（激活参数2B），能方便更多研究者进行研究。

根据此前Qwen1.5-MoE模型（14.7B）的结构估计，最小Qwen3MoE模型猜测是64专家、每个token路由4个专家的MoE模型。感兴趣的同学可以提前参考Qwen1.5-MoE模型的config文件，不过Qwen1.5-MoE采用了共享专家策略，因此其激活参数为2.7B，与Qwen3-MoE代码中记录的2B有些许区别。

在Qwen3MoE的config中发现默认参数的专家数量是128，每个token分配的专家数量是8，然后Qwen2MoE的config中默认参数的专家数量是60，

每个token分配的专家数量是4，由于Qwen3MoE模型的默认参数是15B-A2B，因此笔者认为Qwen1.5-MoE模型的专家数量更具有参考价值，而笔者之前也猜测Qwen3MoE模型不一定只有15B的参数量，有可能有更大参数量的模型，因此认为15B-A2B的模型仍然可以参考Qwen1.5-MoE的参数配置，也就是专家数量是60，每个token分配的专家数量是4。

当然了，估计Qwen3MoE除了发布15B-A2B大小的模型，还会发布更大的MoE模型，期待Qwen团队后续的权重公开。

attention层部分改动

1. 归一化层

moe的attention部分和Qwen3一致，都是对输入部分进行了RMSNorm归一化处理，因此该部分的结论和上面一样，应该也是降低计算成本，提高模型泛化能力，避免在训练过程中出现梯度爆炸或消失的问题。

1. 输出层部分改动

相比于Qwen2，Qwen3应该是对attention输出权重矩阵适配了统一函数做了一些改动，可以看到ALL_ATTENTION_FUNCTIONS函数应该是在transformers的通用模板中，这么做的目的应该是和transformers框架做更好的适配。

这么看，Qwen3_moe相比于Qwen2_moe删减了很多，而大部分的处理应该和ALL_ATTENTION_FUNCTIONS重叠，或者最终效果一致，那么Qwen应该是做了相应的适配。

注意：
在Qwen3_moe的参数初始化中，有一个self.scaling参数，在上图右下角也有，Qwen3Moe 中的 self.scaling 是通过 self.head_dim**-0.5 计算的，而 Qwen2Moe 中是通过 math.sqrt(self.head_dim) 计算的。

MLP层改动

删除共享专家机制

从对比代码中看，Qwen3_moe删除了共享专家部分，这里猜测Qwen团队应该是做了相关的实验，笔者之前也猜测15B应该是他们MoE的最低门槛参数量的模型，应该还有更大的模型，而该模型框架要适配他们所有的MoE模型的，因此应该是有没有共享专家机制都不会影响最终的模型性能，而使用了共享专家机制的话shared_experts需要过多的资源，其他的专家所在的设备有可能不能有效利用，因此综合考虑之后Qwen团队选择直接删掉该模块也是合情合理的。

共享专家机制在deepseek-v2模型中被引入，V3和R1都有很好的应用，关于共享专家可在Qwen2相比于Qwen2MoE中看到。

直观上采用共享专家这种方式可以结合稠密网络和稀疏网络的优点。但是共享专家也有些潜在的缺点：

• 训练和推理的计算框架变得更为复杂，需要专门针对共享专家处进行优化。
• Qwen团队可能在实际验证后发现共享专家不一定有很好的效果提升，因此Qwen团队就直接简化处理了。

模型应用层

1. Qwen3MoEPreTrainedModel

相比于Qwen2，Qwen3增加了一些属性和对特定功能的支持，这些变化反映了 Qwen3MoE 模型在设计和实现上的改进。以下是详细的对比和分析：

• 新增功能：
• 灵活的注意力机制：​​_supports_flex_attn​​​ 表示 ​​Qwen3MoE​​ 支持灵活的注意力机制，可以动态调整注意力的计算方式。
• 量化缓存：​​_supports_quantized_cache​​​ 表示 ​​Qwen3MoE​​ 支持量化缓存，可以减少内存占用，提高推理速度。
• 属性值的变化：
• 更灵活的缓存处理：​​_skip_keys_device_placement​​ 从字符串改为列表，支持更复杂的缓存机制。
• 明确不支持静态缓存：​​_supports_static_cache​​​ 明确为 ​​False​​​，表明 ​​Qwen3MoE​​ 更侧重于动态缓存机制。
• 支持注意力后端：​​_supports_attention_backend​​​ 表示 ​​Qwen3MoE​​ 支持多种注意力实现方式，提高了模型的灵活性和性能。

这些变化反映了 ​​Qwen3MoeE​​ 模型在设计上的改进，特别是在处理长序列、动态缓存和灵活注意力机制方面的优化。这些改进有助于提高模型的效率、适应性和实际应用中的性能。

1. Qwen3MoEModel

首先，对于缓存机制，删除了很多代码，左下方已经给出是因为要适配transformers新的框架做了修改，效果和原来一致，都是动态缓存机制。

其次，我发现在该函数里，在初始化以及前向传播函数中多次提到​​flash_attention​​​的相关参数​​flash_attn_kwargs​​​，在 ​​Qwen3MoEModel​​​ 中引入 ​​flash_attn_kwargs​​​ 参数是为了提供更灵活的注意力机制实现方式。​​flash_attn_kwargs​​ 是一个字典，包含了用于配置和优化注意力计算的各种参数。这种设计允许模型在运行时动态调整注意力机制的实现细节，以适应不同的硬件环境和任务需求,不仅提高了模型的性能和内存使用效率，还为未来的扩展提供了便利。

具体代码：

# forward参数初始化
**flash_attn_kwargs: Unpack[FlashAttentionKwargs],
# layer输出
if self.gradient_checkpointing and self.training:
                layer_outputs = self._gradient_checkpointing_func(
                    partial(decoder_layer.__call__, **flash_attn_kwargs),
                    hidden_states,
                    causal_mask,
                    position_ids,
                    past_key_values,
                    output_attentions,
                    output_router_logits,
                    use_cache,
                    cache_position,
                    position_embeddings,
                )
            else:
                layer_outputs = decoder_layer(
                    hidden_states,
                    attention_mask=causal_mask,
                    position_ids=position_ids,
                    past_key_value=past_key_values,
                    output_attentinotallow=output_attentions,
                    output_router_logits=output_router_logits,
                    use_cache=use_cache,
                    cache_positinotallow=cache_position,
                    position_embeddings=position_embeddings,
                    **flash_attn_kwargs,
          ）

注意：
Qwen3_MoE直接删除了Qwen2MoeFlashAttention2部分，而结合上面说的，在Qwen3MoEModel中加入了flash_attention参数，应用于前向传播计算当中，以及说的简化模型结构，这里猜测是设计值直接默认使用flash_attention加速模型推理，从而使得15B的模型能够实现MoE的基本功能。

笔者总结

1. Qwen3和Qwen3MoE模型的Attention层中都对q和k进行了归一化处理，估计是为了提升训练的稳定性，以支持更大尺寸模型的训练
2. Qwen3-8B的模型参数量比Qwen2.5-7B增加了约1B，估计是为了平衡embedding参数占比过大的问题
3. Qwen3和Qwen3MoE模型默认支持滑动窗口缓存，估计是为了支持更大的上下文长度
4. Qwen3MoE模型集成Flash Attention 2和SDPA加速，比Qwen2MoE的规范性和兼容性更好
5. Qwen3MoE并没有使用Qwen2MoE中的共享专家模式

题外话

该文章也会发布在SwanLab微信公众号上，SwanLab是我们团队的核心产品，用于模型训练跟踪和可视化分析，可以访问https://docs.swanlab.cn/了解，有兴趣的小伙伴可以多多关注。​

参考文章

• Qwen3 即将推出！
• Qwen3即将发布？深度研究报告——解析阿里巴巴新一代大语言模型的技术革新与行业影响
• 【大模型】大模型中的稀疏与稠密——一场效率与性能的较量
• Qwen 技术报告
• 手搭一个qwen模型--CSDN
• qwen2.5技术报告--知乎
• qwen2模型分析--CSDN
• Qwen2.5-1M Technical Report
• DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
• Llama-4-Maverick-17B-128E-Instruct
• LLaMA3初步解读：ScalingLaw颠覆之作，弱智吧挑战及格！
• 详解SwiGLU激活函数
• 1-transformer_model/llm参数量-计算量-显存占用分析.md
• Qwen1.5-MoE-A2.7B模型配置

附录：如何获得Qwen3模型结构信息

途径一：技术报告

一般来说，想这些模型在发布的时候，会有该模型的技术报告一起发出，比如qwen2.5的技术报告如下图所示，链接在这：

如果模型在版本更迭的时候有结构上的变化，一般在技术报告里能找到，而如果没有结构的变化，一般技术报告也会写出预训练和微调等超参数设置、sacling law等，当然也包含评估模型的分数等。

途径二：开源社区模型仓库

而如果没有技术报告，那么如果在模型结构上有很大的变动的话，在开源社区的模型仓库也可以找到，比如deepseek-r1，是找仓库中的modeling_deepseek.py，其中有embedding、attention等代码结构，可以直接找到。

途径三：transformers集成

如果上述都没有找到模型结构信息，那么也可以从各个开源框架中寻找是否有模型集成的信息，比如我们常用的transformers，一般都是各个模型集成的首选框架，这次的qwen3我们就可以直接从集成的代码中找到结构信息：modeling_qwen3.py

#RL真让大模型更会推理？

清华新研究：其能力边界或仍被基座「锁死」

近年来，RLVR（可验证奖励的强化学习）训练大模型在数学、代码等各项任务中表现惊艳，大模型的推理能力快速提升，强化学习因而被视为重要的推手。然而，其中直指核心的重要问题却悬而未决：强化学习真的能让大模型获得超越基础模型的新推理能力吗？

清华大学LeapLab团队联合上海交通大学开展的最新实证研究，通过实验现象揭示了一个值得关注的问题：当前的 RLVR 方法似乎尚未突破基座模型的能力上限。

通过数学、代码、视觉推理三大领域的系统性实验，他们发现了这一出人意料的现象 —— 引入强化学习的模型在某些任务中的表现，竟然不如未使用强化学习的基座模型。RLVR 只是将采样做得更有效率，而其输出的正确答案，早已藏在基座模型的「基因」里。  

• 论文标题：Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?
• 论文链接：https://arxiv.org/abs/2504.13837
• 展示页面：https://limit-of-RLVR.github.io

针对给定问题，通过从基础模型和 RLVR 训练模型中重复采样生成搜索树。灰色表示模型不太可能采样的路径，黑色表示模型更可能采样的路径，绿色表示能获得正向奖励的正确路径。

论文的核心发现是：RLVR 模型中的所有推理路径均已存在于基础模型中。

对于某些问题（如问题 A），RLVR 训练会偏向奖励路径的分布，从而提升采样效率；但代价是推理范围的缩减：对于其他问题（如问题 B），基础模型包含正确路径，而 RLVR 模型却可能丢失该路径。）

这篇工作刷新了 AI 圈里的「普遍认知」：此前各类基于 RLVR 做后训练的大模型，如 OpenAI 的 o1、DeepSeek-R1 等，在各项评测中成绩显著，似乎它就能让大模型实现「自我进化」，赋予模型超越其基座模型的能力。然而，此项研究指出，RLVR 的潜力并不像之前认为的那样强大 —— 它并不能使模型解决基础模型无法解决的问题。论文一经发出，就获得国内外学者的广泛关注，发布首日即登顶 Hugging Face 日榜和 alphaxiv 榜首，在 Twitter 上累计接近 30 万次浏览，引起大量讨论。

当技术社区关注于 RL 带来的短期收益时，或许需要此类研究提醒我们：大模型的真正突破，永远始于对本质问题的追问。

实验设计：用 pass@k 揭开模型的「能力边界」

一个很重要的问题是：如何界定模型所能触及的能力边界？

传统评测聚焦单次回答准确率（pass@1）或多次回答平均准确率。然而，模型在几次采样下未能解决问题、采样更多次后最终成功解决的现象并非个例，对这种情况的忽视将会极大低估模型的真实潜力。因而，它们都不适合作为所谓「能力边界」的参照指标。

为找到更合适的指标，研究团队提出了一个更本质的问题：当允许多次尝试时，模型究竟能解决多少问题？ 为此，他们引入 pass@k 指标：若模型在 k 次采样中至少生成一次正确答案，则认为其具备解决该问题的能力。若 RL 训练真能扩展推理能力，我们应看到 RL 模型比基座模型解决更多此类问题。为减小直接采样计算 pass@k 值可能导致的高方差，他们采用无偏估计的方法，使用严格定义来确保 pass@k 的可靠性。

多个数学基准测试中的基础模型及其经强化学习训练的对应模型的 pass@k 曲线，横轴为采样次数 k，纵轴为 pass@k 准确率

研究团队强调，使用 pass@k 而非大多数研究采用的多数表决（majority voting）—— 这并不会导致结果无效。他们使用 pass@k 并非为了衡量实际效率，而是为了探索大语言模型的推理能力边界。

所谓「能力边界」是指模型是否具有正确解决某类问题的潜质，而「效率」是在给定时间和资源成本下模型的表现，因而不能将大模型的「能力边界」和「效率」混为一谈。这项研究从未否定 RL 带来的「效率」上的提升，而是更深入地发起对其能力边界的探讨。

跨领域的一致性：与 RL 相比，基座模型表现出更广泛的覆盖能力

实验中，研究团队在三个具有代表性的领域进行实验，对比评估 RLVR 模型和基座模型的能力边界。在所有的实验中，都获得了以下的核心发现：

1. RL 模型在小 k 时占优，然而基座模型在大 k 时逆袭：在数学题、代码生成和视觉推理等任务中，RL 模型在 pass@1 上的表现显著优于基座模型。而当采样次数增至数十或数百时，在所有基准测试和 LLM 模型家族中，基础模型的表现会无一例外地逐渐追平强化学习训练的模型，并最终实现反超。
2. 答案同源性：验证 RL 模型的正确答案均存在于基座模型的输出分布中，RL 仅通过调整概率分布「筛选」高奖励路径。 

数学推理

在数学推理任务中，研究团队在 AIME24、AMC23、MATH500 等多个基准上评估多个 LLM 系列（如 Qwen-2.5 和 LLaMA-3.1）及其经过 RL 后训练的变体。

实验结果显示，在两大 LLM 系列、6 个数据集的总共 24 个对比实验中，基础模型的能力表现均在采样次数增大后追平并反超对应的 RL 模型。

人工检查推理链。数学解题，存在着「蒙对」的可能。为此，研究团队人工检查了基座模型正确答案的 CoT 推理过程，发现对于大部分题目，基座模型在多次采样中至少存在一个 CoT 推理过程是正确的，从而确认了答案的得出符合逻辑而非随机蒙对。同时团队观察到，基座模型输出的 CoT 也能很复杂但逻辑完整，例如通过多次试错调整解题方法和方程参数，说明基座模型也有输出长 CoT 和自我反思的能力。

此外，团队还研究了另一款在 AIME24 上表现优异的 RL 模型 Oat-zero。结果同样表明，尽管 RL 在初始阶段提高了准确性，但基础模型仍保持更广泛的推理覆盖能力。

代码生成

值得注意的是，生成的代码必须通过所有测试样例，几乎不可能蒙对正确答案，模型必须真正写出符合逻辑的代码才能得分。代码生成任务的实验结果同样支持前述的核心发现：RLVR 强化学习模型 CodeR1-Zero-Qwen2.5-7B 提升了单样本 pass@1 得分，但在更高采样次数（k=128）时降低了覆盖范围。原始模型在更大的 k 值下仍展现出持续改进的潜力，而 RLVR 的性能则趋于稳定。

视觉推理

在视觉数学推理数据集 MathVista 中，RL 训练后的模型在单次回答准确率上提升显著，但当 k 增至 64 次时，基座模型仍展现出更广的问题覆盖能力。RLVR 在视觉推理上的改进与数学和代码基准中的表现一致，表明原始模型已涵盖广泛的可解决问题范围，即使在多模态任务中也是如此。

以上跨领域的一致性表明，与 RL 相比，基座模型表现出更广泛的覆盖能力。RLVR 并未从根本上改变模型的问题解决方式。  

深度探索：RL 无法突破基座天花板

通过以上的实验，研究团队发现，强化学习提高了采样效率，但缩小了推理能力边界。

更进一步的困惑度（perplexity）分析表明，RLVR 训练模型生成的推理路径本就存在于基础模型的输出分布中，这意味着 RLVR 只是让模型更偏向高奖励解决方案，而非创造新的推理能力。然而，这种对奖励路径的聚焦削弱了模型的探索能力，限制了其在大规模采样时对可解问题的覆盖范围。这些发现说明 RLVR 并未从根本上突破基础模型的推理能力，而是以牺牲解决问题的多样性为代价来优化现有路径。

那么，不同的 RLVR 算法在此问题上是否表现出差异？对比实验发现，各 RLVR 算法表现相似且均远未达最优。

研究比较了多种 RL 算法（PPO、GRPO、Reinforce++，RLOO，DAPO， ReMax），发现它们的采样效率差距（∆SE）衡量的性能差异很小。尽管算法间∆SE 存在细微差别，但所有方法都与最优效率存在显著差距。这表明当前以提高采样效率为目标的 RL 方法仍远未达到最优性能。

研究团队还发现，RLVR 与蒸馏训练存在本质区别。RL 仅能提升采样效率，而蒸馏训练能真正为模型注入新知识。因此蒸馏模型通过学习蒸馏数据往往能拓展基础模型的推理能力边界，这与能力始终受限于基础模型的 RLVR 训练模型形成鲜明对比。

作者答疑

针对 AI 圈对这项工作的广泛关注和困惑，研究团队在论文网站上精选具有代表性的问题并给出答复，希望能够更好地阐释他们的工作。

Q1: 既然随机采样在 k 极大时也能命中答案，你们关于「RL 提升 pass@k」的结论岂非毫无意义？  

A1:  并非如此。「量变引发质变」。理论上随机打字确实有非零概率生成正确答案（约 1/V^L，V 为词表大小约 3 万，L 为输出长度超 200），但实际搜索空间堪比天文数字。关键在于概率量级：若基座模型正确概率为 1/10⁴-10⁵，RL 或需百万次采样才能找到；但若概率低于 1/10¹⁰，RL 几乎无法突破局部最优。我们的实验显示，多数问题在 k=128 或 1024 时就能观测到正确输出（当代算力可及），因此 pass@k 恰恰证明基座模型已具备必要推理路径。  

Q2: RL 将 pass@k 提升为 pass@1 不是常识吗？ 

A2:  RLVR 将 pass@k 转为 pass@1 并不意外 —— 这本就是 RL 的设计目标。但更值得关注的是：RLVR 在实验中并未展现出超越性。若基座模型无法解决的问题，RL 训练后依然无解。这清晰揭示了 RL 在推理任务中的能力上限。此现象与传统 RL（如 Atari 或围棋）形成鲜明对比 —— 传统 RL 能通过自我对弈不断发现新策略，而 LLM 的 RL 微调却受限于基座模型原有能力。实际上，RL 微调模型在 pass@k 上表现反而不如基座模型，这一现象令许多研究者惊讶。 

Q3: 论文是否宣称 RL 完全无法激励超越基座模型的推理？

A3:不，我们并未做出如此绝对论断。本研究旨在通过系统实验探讨「RL 能否真正扩展 LLM 的推理能力」，并为学界提供新视角。

我们不排除模型规模与训练数据扩展可能改变结果的可能性。事实上，我们正在基于 DeepSeek-V3-base 与 R1-zero 开展进一步研究。

Q4: DeepSeek-Math 已报道类似结果，你们的工作有何不同？  

A4:  DS-Math 确实观察到相似趋势，但其研究仅针对单一指令微调模型和两个数学基准。我们的工作系统性地考察了零 RL 设置的纯基座模型，覆盖更多 LLM 家族和多样化基准测试。我们还通过人工分析思维链、困惑度分析、不同 RL 算法对比、蒸馏模型评估等提供了更全面的 RLVR 能力边界分析。我们认为「RLVR 的推理范围受限于基座模型」这一现象值得研究社区深入关注。  

结语：超越「精耕细作」，探索「开疆拓土」

清华和上交的这项研究为当前火热的 RL 训练热潮提供了冷思考：若将 base 模型比作一棵树，RLVR 只能修剪枝叶使其更整齐，却无法让树长出新的枝干。RLVR 在实现大模型能力提升的进程中究竟能够扮演怎样的角色，是我们不得不思考的问题。

该研究可能暗示着，可验证奖励的强化学习更像是一位精于调律的乐师，而非谱写新曲的作曲家。它能将模型已有的潜能雕琢得更加纯熟，却难以赋予其全新的能力维度。能否将当前的 RLVR 视作开启通用智能的万能密钥需要我们重新思考。

未来的探索之路，或许更需聚焦于基础模型自身的架构革新 —— 在知识表征的广度、认知结构的深度以及推理脉络的构建等方面潜心耕耘，而非仅仅寄望于下游策略的微调润色。基座模型的「原始智慧」很可能被低估，知识蒸馏的思路很可能有更大的用武之地。

真正的「进化」，或许需要更根本的范式变革 —— 让模型不仅能高效利用既有知识，更能主动跳出先验去探索未知领域。

作者信息

该论文的一作是清华大学自动化系三年级博士生 Yue Yang（乐洋），他专注于强化学习、世界模型、多模态大模型和具身智能的研究。他的导师是黄高教授。此前他作为两位一作之一的论文《How Far is Video Generation from World Model: A Physical Law Perspective》被国内外众多大佬 Yan Lecun，Xie Saining，Kevin Murphy 等转发。此外他也是 DeeR-VLA 的一作。

另一位一作是清华大学自动化系本科生 Chen Zhiqi（陈之琪），目前在黄高教授团队 LeapLab 实习。 

#OpenAI推出「轻量级」Deep Research

刚刚，OpenAI推出，免费用户也能薅羊毛！

刚刚，OpenAI 宣布推出「轻量级」版本的 Deep Research，免费用户也可以使用！

轻量级版本由 OpenAI 的 o4-mini 模型提供支持，而之前的 Deep Research 使用的是更强大的 o3 模型（或其变体）。OpenAI 表示，虽然响应通常会更简短，但仍能够维持您所期待的深度和质量。

同时，轻量级版本允许更高的使用配额。例如，当用户达到原始深度研究工具的查询限制后，系统会自动切换到轻量级版本。

具体来说，免费版每月提供 5 个轻量版任务额度；Plus & Team 版每月提供 10 个原始版任务额度和额外 15 个轻量版任务额度；Pro 版每月提供 125 个原始版任务额度和额外 125 个轻量版任务额度。

现在我们上手实测一下，大家看看「轻量级」效果如何。

OpenAI 的 Deep Research 功能于 2025 年 2 月 2 日正式发布，被认为是目前最复杂的 Deep Research 工具，适合需要高质量报告的专业用户，但需专家核查结果。

它的竞争对手包括涵盖 Gemini、Perplexity、Grok 等模型也先后推出了类似功能，各自在速度、准确性和应用场景上有所侧重。

参考链接：

​​https://techcrunch.com/2025/04/24/openai-rolls-out-a-lightweight-version-of-its-chatgpt-deep-research-tool/​​

​​https://x.com/OpenAI/status/1915505961500070245​​​

#Describe Anything

英伟达开源「描述一切」模型,拿下7个基准SOTA

你说不出来的话，大模型替你说了。

图像描述（image captioning）生成一直是计算机视觉和自然语言处理领域面临的长期挑战，因为它涉及理解和用自然语言描述视觉内容。

虽然近期的视觉语言模型 (VLM) 在图像级描述生成方面取得了令人瞩目的成果，但如何为图像中的特定区域生成详细准确的描述仍然是一个悬而未决的问题。

这一挑战在视频领域尤为突出，因为模型必须额外捕捉动态视觉内容，例如人类动作、物体运动以及人与物体的交互。

为了解决上述问题，来自英伟达、UC 伯克利等机构的研究者推出了「描述一切模型」 (DAM，Describe Anything Model)。这是一个强大的多模态大语言模型，可以生成图像或视频中特定区域的详细描述。用户可以使用点、框、涂鸦或蒙版来指定区域，DAM 将提供这些区域丰富的上下文描述。

论文标题： Describe Anything: Detailed Localized Image and Video Captioning 

论文地址：https://arxiv.org/pdf/2504.16072

论文主页：https://describe-anything.github.io/

，时长03:21

我们先来看效果。

DAM 对视频中指定对象的描述：「一头身披深棕色皮毛、臀部有一块浅色斑块的母牛，正以一系列动作展现其姿态。起初，母牛略微低着头，展现出平静的神态。随着画面的推进，母牛开始向前移动，双腿舒展，步态稳健而有节奏。其尾端有簇毛，每走一步都会轻轻摆动，为其动作增添一丝流畅感。母牛的身体基本保持直立，背部略微拱起，展现出一种放松的姿态。结实而轮廓分明的双腿，带着母牛坚定地向前迈进。在整个画面中，母牛保持着均匀的步伐，动作流畅而从容，展现出一种宁静沉稳的气质。」

「一只浅棕色皮毛、面部稍深的猴子在一系列动态动作中被捕捉到。最初，它似乎用右手伸进一个容器中，手里拿着一块黄色的食物。猴子的姿势稍微前倾，表明它在与食物互动时的专注和意图。随着动作的进行，猴子将食物靠近嘴边，用双手操作。它的面部表情显示出专注和享受，眼睛半闭。猴子的身体轻微移动，保持平衡，继续进食。在整个过程中，猴子的动作流畅而有目的，展示了它的灵巧和敏捷。最后的画面描绘了猴子用双手拿着食物，将其靠近脸部，然后稍微降低，可能准备再咬一口。」

DAM 对图片的描述「一只白色的猫，有着浅橙色的耳朵和粉红色的鼻子。这只猫表情放松，眼睛微微闭合，身上覆盖着柔软的白色毛发。」

机器之心也上手测试了一下，看起来是鼠标指到哪个对象，该对象就会被自动分割，最后我们选择了拉布拉多幼犬，模型回答的快且准确，

测试地址：https://huggingface.co/spaces/nvidia/describe-anything-model-demo

详细局部描述

DLC（Detailed Localized Captioning）与传统图像描述不同，传统图像描述对整个场景的总结比较粗略，而 DLC 则更深入地挖掘用户指定区域的细微细节。其目标不仅是捕捉对象的名称或类别，还包括微妙的属性，如纹理、颜色图案、形状、特点以及任何视觉上独特的特征。

不仅是图片，DLC 可以自然地扩展到视频领域，描述特定区域的外观和上下文如何随时间变化。达到这种目的，模型必须跨帧跟踪目标，捕捉不断变化的属性、交互和细微的变化。

DAM 比较擅长生成图像和视频中物体的详细描述。通过平衡焦点区域的清晰度和全局上下文，该模型可以突出细微的特征（例如复杂的图案或变化的纹理），这远远超出了一般图像级描述所能提供的范围。

用户还可以引导模型生成不同细节和风格的描述。无论是简短的摘要，还是冗长复杂的叙述，模型都能调整输出。这种灵活性使其适用于各种用例，从快速标记任务到深入的专家分析。

除了生成描述之外， DAM 模型无需额外的训练数据即可回答有关特定区域的问题。例如用户可以询问该区域的属性，模型会利用其对局部区域的理解，提供准确的、基于上下文的答案。

方法介绍

为了解决指定区域特征中细节丢失问题，本文提出了 DAM，该模型既保留了局部细节也保留了全局上下文。DAM 通过两个关键创新实现这一点：

1）焦点提示（focal prompt），它对感兴趣区域进行编码；

2）局部视觉骨干网络（localized vision backbone），它确保精确定位的同时整合全局上下文。

这些组件使 DAM 能够生成详细准确的描述，即使是对于复杂场景中的小物体。

具体而言：

焦点提示，可以提供完整图像和目标区域的放大视图。这种方法确保模型能够捕捉精细细节，同时保留全局背景。最终呈现的描述细致准确，既能反映全局，又能捕捉细微之处。

局部视觉主干网络，引入了一个集成全局特征和局部特征的局部视觉主干网络。图像和掩码在空间上对齐，门控交叉注意力层将局部细节线索与全局上下文融合。此外，新参数初始化为零，从而保留预训练的能力。这种设计能够产生更丰富、更具有上下文感知能力的描述。

此外，由于现有的数据集缺乏详细的局部化描述，该研究设计了一个两阶段流程。

• 首先，他们使用视觉语言模型（VLM）将数据集中的简短类别标签扩展为丰富的描述。
• 其次，在未标记的图像上应用自训练，作为一种半监督学习方法，并使用 DAM 模型生成和优化新的描述。

这种可扩展的方法可以在不依赖大量人工注释的情况下构建大型、高质量的训练数据集。

实验及结果

DAM 在局部图像与视频描述任务中表现卓越，能够支持多粒度输出（包括关键词、短语及详细描述），并在 7 个领域内基准测试和零样本基准测试中均达到 SOTA。

在 object-level LVIS  和 part-level PACO 数据集上进行测试，本文方法取得了最佳性能。

在表 4 中的 Ref-L4 基准测试中，本文方法在基于短语言的描述指标上平均比之前的最好方法相对提高了 33.4% ，在基于长语言的描述指标上平均比之前的最好方法相对提高了 13.1%。

如表 5 所示，DAM 显著优于现有的通用和基于特定区域的 VLM。

在表 6 中， DAM 在 HC-STVG 上比之前的最佳成绩相对提升了 19.8%。在表 7 中， DAM 在零样本和域内设置中均超越了之前的最佳成绩。

#心响 App「一切从简」

95后团队30天造出通用超级智能体！百度心响App全量上线、人人免费用，亲测效果惊艳

2025 年第一个「爆款预定」的智能体 App，就这么华丽丽地来了！

无需邀请码，也不用申请内测，不玩任何套路。

在备受关注的 AI 智能体赛道，百度抢先丢下了一颗「重磅炸弹」。

4 月 25 日，在 Create2025 百度 AI 开发者大会现场，百度正式亮相了首个移动端的通用超级智能体 App—— 心响，并宣布所有人都可以免费使用。

这预示着，人手一个超级智能体的时代到来了！

毫不夸张地讲，心响 App 的提升是方方面面的：

在功能定位上，它被打造成了一个「指哪打哪、高效输出」的通用超级智能体。集成进心响 App 的多个子智能体在理解用户意图之后，通过任务拆解、组合与协作，一站式完成各种指令。比如生成有声的试题讲解视频：

执行过程

，时长00:19

生成的视频

在提示词上，用户得到前所未有地解放。心响 App「一切从简」，只需一句话说出自己的需求，剩下的一切交给它自动处理，效率大增。同时，在结果交付上，心响 App 完成向集成化的转变，将执行过程完全托管给智能体，一气呵成，呈现完整成品。

比如规划一份 Create2025 大会上午结束后的周边半日游，心响 App 将所有的因素（景点、美食、交通出行等）考虑在内，制定出了一份紧凑合理的行程：

，时长00:30

据百度智能体业务首席架构师、心响 App 负责人黄际洲表示，在应用场景上， 心响 App 目前支持超过 200 种任务类型，并在例行任务、城市旅游、AI 相亲、AI 绘本、摸鱼游戏、深度研究、法律咨询、健康咨询、智慧图表和试题讲解等 10 大场景中表现出色。未来计划扩展到 10 万 + 场景，满足更广泛的用户需求。

总之，24 小时待命的心响 App，随时随地为你排忧解难。目前，用户可以在各大安卓应用商店下载使用，苹果 App Store 也将很快上线。

更值得关注的是，能力出众、运行丝滑、场景全面的心响 App，竟是百度内部一个 95 后团队从零开始，在短短 30 天内开发完成的。

这也意味着，心响 App 远未达到最终形态。随着功能的进一步打磨，这个迭代进化中的通用超级智能体势必会为我们带来更多惊喜。

一手实测

移动端的智能体已经长这样了 

心响 App 的界面非常简洁。体验时有个小 tip：在创建新任务时，用户既可以直接输入需求；也可以点击界面上列出的场景，然后快速定制任务需求。比如下图（中）为「城市旅游」场景，（右）为「法律咨询」场景：

首先令心响 App 创建一个例行任务「每天晚上 9 点给我一个升职小技巧」，30 秒左右就搞定了。

，时长00:32

对于春节档爆火的动画电影《哪吒之魔童闹海》，让心响 App 创建票房排行以及每日票房变化的可视化交互图（截止到 4 月 24 日），输出结果一目了然。

，时长00:58

在一些专业性要求比较高的场景中，比如健康咨询，心响 App 也能给出不错的建议。在详实的诊前问询之后，系统自动调度多位「医生 AI 分身」进行联合会诊。诊断意见虽然不能替代专业的医生，但仍能为患者自查提供参考。

，时长01:47

此外，心响 App 还能制作一些小游戏，并且点开就能玩，比如经典贪吃蛇：

，时长01:47

不擅长游戏的小编试玩了几把，终于得分了：

这番亲测之后，我们的感受一是「全能」，凡是日常工作、生活、学习和娱乐中常见的任务需求，心响 App 都能有求必应；二是它正在一步步向真正掌控在用户手中的个性化和实用型 App 进化。

心响 App 的更多玩法，等待着大家进一步探索。

多智能体的有序高效执行

靠的是什么？

心响 App 的实测让我们看到了这样一个事实：一个 App 如果想要与超级智能体平台划等号，并不能靠单纯地堆功能，而是要构建多智能体系统的「理解 —— 拆分 —— 调度 —— 协作 —— 交付」完整闭环。

这些正是当前超级智能体 App 落地的难点所在，每一环都至关重要，需要从任务理解与意图建模、多智能体协作机制、多线程任务调度、主动响应与交互优化等多个技术层面发力。

在将心响这个独立的 App 打造成为超级智能体的过程中，实际上涉及到了一整套系统级的技术创新，尤其要在系统架构、算法设计和技术实现上做好充分的优化。

首先，为了始终能够 get 到用户的复杂需求（比如帮我做个出差安排），心响 App 要准确识别出其中隐藏的多个子意图（包括订票、订酒店、安排日程、预算控制等），这就要求系统具备多轮上下文追踪、实体识别等 NLP 能力。 

因此，当接收到用户的任务需求，承担主智能体角色的心响会在深度理解之后，将它们拆解成一系列可执行的关联子任务，并进行动态规划与管理。这种 AI 工作流调度就像「AI 指挥官」一样下达命令，将用户所有意图「一网打尽」。

其次，在拆解用户需求之后，自动选择合适的子智能体协同执行对应的子任务成为顺利交付结果的前提。这些子智能体之间的「分工」不能重复或遗漏，执行中还需要保留全局上下文信息，实现协作过程一致并可追溯。

心响 App 的多智能体协作通过自主规划，调用多领域的子智能体来解决问题。其中的关键在于引入了一个全新的接入方案 ——Agent Use。

作为最近爆火的模型上下文协议，MCP 通过「上下文共享和工具连接」等功能，为多智能体之间、内外部资源之间的互联互通提供统一的接口，增强了系统的可扩展性和执行效率。

心响 App 采用的 Agent Use 可以自动调度百度自己和市面上所有第三方子智能体，以及各种内外部 AI 工具、应用和服务接口，最终交付精准契合用户需求的成果。

比如法律服务场景，你想要咨询「上班路上不小心被车撞成骨折，是否算工伤」。心响 App 在执行过程中自动调度多位律师 AI 分身组成的「律师智囊团」协同答复，给出一份逻辑严谨、条理清晰的法律意见书。

，时长01:31

此外，开发者也可以利用 MCP Server 轻松接入心响 App。这样一来，在无需改造的情况下，开发者就能让拥有专业知识的优质智能体或 AI 应用被心响 App 高效调用，丰富智能体「武器库」。

开放的 MCP 调用与接入能力极大扩增了心响 App 的应用场景和智能体能力，从而能够快速适应多样化的用户需求，并形成不断增长和进化的智能体生态。这也是百度近来积极拥抱 MCP 生态的体现，通过将一个个成熟的 AI 功能纳入进来，创建平台级的「综合体」应用。

随之而来，心响 App 正朝着通用超级智能体的方向迈进，并开启从「对话范式」向「执行范式」的跃迁，加速 AI 应用场景深化。

属于智能体的战场

才刚刚开始

百度创始人李彦宏曾预言，「2025 年或成 AI 智能体爆发元年」。其他 AI 圈大佬如 OpenAI CEO 奥特曼、Meta CEO 扎克伯格都纷纷看好 AI 智能体的发展前景。

在这种形势下，谁能更好更快满足用户多场景真实刚需并赢得青睐，谁就更有可能在激烈的竞争中拔得头筹。眼下，多智能体协作应用成为衡量玩家们技术实力和产品落地能力的重要标志之一。

因此，在大模型厂商和互联网大厂追逐 AI 智能体「Alpha 时刻」的当下，心响 App 的推出不仅是百度在通用智能体赛道的关键布局，也成为其大模型战略的延伸，代表了其在 AI 应用层面的探索进入到了又一个阶段。

此外，这一举措通过整合百度生态内的工具链提供一站式 AI 服务，增强用户粘性的同时帮助其巩固生态优势，并探索新的商业化路径。百度在 AI 领域的技术领先地位也有望得到进一步强化。

从基础大模型到垂直场景应用，再到如今的通用超级智能体，我们见证了又一次范式的更替。百度用 App 释放一个清晰的信号：智能体的价值，不只是回应，更在解决。在生成式 AI 从「对话范式」走向「执行范式」的关键节点，百度率先迈出了实质性一步。

在智能体这个有可能变成「红海市场」的 赛道，竞争会越来越白热化。能否围绕用户需求构建起真正可执行的「工作流」并将 AI 能力落在用户体验上，将成为决出最终赢家的分水岭。