KARL：用强化学习训练知识搜索 Agent 的完整工程实践

来源: Databricks AI Research — Knowledge Agents via Reinforcement Learning 日期: 2026-03-05 标签: Agent Reinforcement Learning Enterprise Search Synthetic Data Grounded Reasoning 规模: 77 页，43 图，17 表，26 位作者 基础模型: GLM 4.5 Air（MoE 架构）

一句话总结

Databricks 提出了 KARL（Knowledge Agents via Reinforcement Learning），通过多任务强化学习 + Agentic 合成数据 + 迭代离线 RL 训练，将 GLM 4.5 Air 训练成在 6 类企业搜索任务上超越 Claude 4.6 和 GPT 5.2 的知识 Agent，且成本更低、延迟更低。名字来源于旧金山著名的 “Karl the Fog”（卡尔大雾）。

为什么这篇论文重要

1. 首个完整的 Agent RL 训练工程实践：从数据合成到 RL 训练到推理时计算扩展，全链条开源细节，包括基础设施实现
2. 解决了真实企业场景的核心问题：不是在公开网页上搜索，而是在企业私有数据（财报、医学文献、内部会议纪要、技术文档）上做 grounded reasoning
3. 证明了多任务 RL 的泛化优势：只在 2 个任务上训练，在 4 个未见过的任务上也有显著提升，比多专家蒸馏效果好
4. 提出了可复现的训练范式：OAPL 不需要 GRPO 的各种 trick（importance weighting、数据删除、router replay），对 MoE 大模型也能稳定训练
5. 证明 RL 不只是 “sharpening”：通过 max@k 分析证明 RL 真正扩展了模型的问题解决能力，而不仅仅是把已有能力的概率提高

论文背景：什么是 Grounded Reasoning

论文提出了一个关键概念：Grounded Reasoning——需要访问模型参数之外的知识才能完成的推理任务。

与常见的推理任务（常识推理、数学、编码）不同，grounded reasoning 的特点是：

• (a) 多步信息收集：需要反复查询、检索
• (b) 基于证据的复杂推理：答案必须有据可查

这类任务在企业场景中极具经济价值：金融、法律、医疗、制造业等领域都依赖海量私有数据，这些数据模型在训练时从未见过。

现有的 “Deep Research” 方案（如 OpenAI 的深度研究）依赖公开网页和黑箱搜索引擎，无法确定这些结果是否能泛化到其他 grounded reasoning 任务上。KARL 正是要回答这个问题。

第一部分：KARLBench——6 类搜索能力的评估套件

1.1 任务设计哲学

KARLBench 的设计有三个核心原则：

1. 闭合语料库：不依赖活的网页搜索，消除外部变量（搜索引擎行为、网页内容变动），确保可控对比
2. 单工具约束：Agent 只能用 vector search 一个工具。这是刻意的设计——隔离检索和推理能力，不测工具编排（与 OfficeQA 等需要多工具协同的 benchmark 区分）
3. Nugget-based 评估：将答案拆解为独立的信息单元（nugget），逐个评分。比二元对错更精细，能区分”完全正确”和”部分正确”

1.2 六类任务详细分析

关键洞察：BrowseComp-Plus 和 TREC-Biogen 测试的是两种结构性不同的搜索能力。

• BrowseComp-Plus = 深搜（Deep Search）：反复缩小搜索范围，排除不满足约束的候选，直到找到唯一实体。需要极长轨迹（中位数 50-200 步）
• TREC-Biogen = 广搜（Wide Search）：大范围收集分散信息，综合成连贯报告。轨迹较短（中位数 4-6 步）但需要高质量的信息整合

单一任务优化的模型无法同时覆盖这两种能力——这正是多任务 RL 的动机。

1.3 语料库构建细节

论文特别强调：不做任何针对特定数据集的预处理优化。没有针对性的 re-chunking、语义增强、元数据丰富化、或基于下游性能的 chunk 大小调优。这确保性能提升来自检索和推理能力本身，而不是语料库预处理 trick。

具体的索引策略：

• BrowseComp-Plus：每个文档只索引前 512 token（覆盖 86.5% 的 gold evidence）
• FinanceBench：按页级别索引
• FreshStack：使用提供的语义分割 chunk（最多 2048 token）
• TREC-Biogen：短摘要，不需要额外分割
• QAMPARI：句子级别 chunk（约 100 词），只索引包含至少一个答案实体的文档，共 250K+ chunk
• PMBench：每个文档只索引前 2048 token

第二部分：Agent 架构

2.1 Vector Search 作为唯一外部工具

Agent 在每一步可以：

1. 生成一个搜索查询
2. 通过 vector search 工具检索 k 个文档 chunk
3. 阅读检索结果
4. 决定继续搜索还是生成最终答案

检索参数不做逐任务调优，而是保持一致的 token 预算：k 值按 chunk 平均长度反向调整，上限 k=20。

Embedding 模型选择：

• BrowseComp-Plus：Qwen3-8B embeddings，k=20
• PMBench：GTE-large（匹配生产环境配置）
• TREC-Biogen、QAMPARI、FinanceBench：Qwen3-0.6B embeddings，k=20
• FreshStack：Qwen3-0.6B，k=10

2.2 上下文压缩：端到端 RL 训练的关键创新

对于长轨迹（BrowseComp-Plus 经常超过 200 步），上下文窗口会很快被填满。KARL 的压缩机制：

触发条件：当历史 token 数超过预定义阈值时自动触发

压缩方式：把整个历史发给模型自己，让它压缩成一个更短的摘要

关键区别：

• 先前工作：用独立的模型做压缩，预训练在摘要数据集上
• KARL：不用独立模型，不预训练摘要。压缩步骤直接纳入 RL 训练，端到端优化，目标是最大化最终任务奖励

这个设计的意义在于：模型自己学会了为了搜索目标而压缩——它会保留对后续搜索有用的信息，丢弃无关的。这不是通用的”好摘要”，而是任务导向的信息管理。

实验验证（Table 6）：论文做了一个巧妙的交叉实验——分离搜索模型和压缩模型：

• GLM 4.5 Air 搜索 + GLM 4.5 Air 压缩 = 0.44
• GLM 4.5 Air 搜索 + KARL 压缩 = 0.54（+10 绝对值！）
• KARL 搜索 + GLM 4.5 Air 压缩 = 0.46
• KARL 搜索 + KARL 压缩 = 0.57

结论：RL 训练同时提升了搜索能力和上下文管理能力。KARL 的压缩能力甚至能迁移给 GLM 4.5 Air 使用，提升 10 个百分点。

第三部分：Agentic 合成数据管线

训练数据的质量直接决定 RL 的上限。KARL 的数据合成管线是整篇论文中工程量最大的部分。

3.1 Stage I：问题-答案合成

输入：

• 文档语料库（BrowseComp-Plus 的 100K 文档 或 TREC-Biogen 的 2680 万文档）
• 少量种子示例（4 个 QA pair，来自验证集）

过程：

1. 合成 Agent 接收种子示例和语料库访问权
2. Agent 动态探索语料库：通过 vector search（BrowseComp-Plus 最多 60 步 k=5，TREC-Biogen 最多 50 步 k=20）
3. 基于发现的文档组合，生成 8 个候选 QA pair
4. 每个 QA pair 包含：问题、nugget 化的答案、相关引用

为什么要动态探索？

先前工作（SPICE、NaturalReasoning）的做法是：给合成模型一组静态文档，让它基于这些文档生成问题。KARL 的做法更有表达力——合成 Agent 自己决定去哪里搜索、发现什么样的文档组合，然后基于这些发现提出问题。这更接近真实的知识发现过程。

BrowseComp-Plus 的一个额外技巧：用种子文档引导合成。除了 4 个种子 QA 示例，还会采样 10 个种子文档，引导合成 Agent 的探索方向。实验表明这使文档覆盖率提升 25%。

去重管线（防止数据泄漏）：

两阶段去重，确保合成数据不包含测试集的问题：

1. 精确匹配：移除与测试集或合成集内部完全相同的问题
2. 近似重复检测：对每个测试集问题，用 Qwen3 embedding 检索 top-10/20 最相似的合成问题，然后用 gpt-4o-mini 作为释义判断器（paraphrase judge），标记为释义的移除

3.2 Stage II：解决方案合成 + 难度过滤

这是数据质量控制的核心环节。

步骤 1：多次尝试

• 每个合成问题 → 8 个 Solver Agent 实例独立尝试回答
• 每个 Solver Agent 使用 vector search 工具，BrowseComp-Plus 最多 200 步（配合压缩），TREC-Biogen 最多 50 步

步骤 2：通过率过滤（Pass-rate Filtering）

计算每题的通过率（8 次尝试中正确的比例），然后过滤：

• 全对的题删掉：太简单，模型已经会了，没有学习信号
• 全错的题删掉：太难（或者问题/答案有问题），超出模型当前能力

RL 的学习信号来自”有的对有的错”——模型可以从正确和错误的尝试对比中学到什么行为更好。

对于 TREC-Biogen（分数是 [0,1] 连续值），需要先二值化：设一个阈值（Iter.1 用 0.6，Iter.2 用 0.7），高于阈值算”正确”。TREC-Biogen Expert 的三轮迭代分别用 0.6、0.75、0.9——随着模型变强，阈值也提高，确保训练数据持续有挑战性。

步骤 3：质量过滤（Quality Filter Agent）

用 gpt-4o-mini / gpt-5-mini 作为 Quality Filter Judge，检查两种问题：

• 歧义问题：问题本身不够明确，导致不同的正确理解方式
• 答案错误：Stage I 合成的参考答案有事实错误

只有通过两层过滤的 QA pair 才进入最终训练集。

3.3 迭代自举（Iterative Bootstrapping）

这是 KARL 的训练飞轮：

GLM 4.5 Air → 合成数据 → OAPL 训练 → KARL Iter.1
KARL Iter.1 → 合成更高质量的数据 → OAPL 训练 → KARL Iter.2

每轮迭代：

• 合成 Agent 更强 → 数据质量更高、更难
• 通过率过滤的阈值也提高 → 数据始终有挑战性
• 模型不断攀升

训练数据统计：

TREC-Biogen 的 prompt 数远多于 BrowseComp-Plus，这是因为 BrowseComp-Plus 的轨迹长度是 TREC-Biogen 的一个数量级（中位数 50+ 步 vs 4-6 步）。为了平衡总训练 token，需要更多 TREC-Biogen prompt。

一个关键观察：Iter.2 的 BrowseComp-Plus 轨迹显著短于 Iter.1——中位数从 50 步降到 20 步。Iter.1 中，GLM 4.5 Air 经常用完整个 200 步预算还无法收敛到答案；而 KARL Iter.1 合成的数据中，这种情况消失了。模型学会了更高效地搜索。

第四部分：OAPL——迭代大批次离线策略 RL

这是论文最核心的技术贡献。OAPL（Optimal Advantage-based Policy Optimization with Lagged Inference policy）是一个全新的后训练范式。

4.1 数学推导

从 KL 正则化的 RL 目标出发：

max_π E_{x, y~π(·|x)} [r(x,y) - β · KL(π(·|x) || π_ref(·|x))]

其中 β > 0 控制 KL 正则化强度。

这个目标有闭合形式的最优策略：

π*(y|x) ∝ π_ref(y|x) · exp(r(x,y) / β)

和最优价值函数：

V*(x) = β · ln E_{y~π_ref(·|x)} exp(r(x,y) / β)

重排后得到最优优势函数关系：

β · ln(π*(y|x) / π_ref(y|x)) = r(x,y) - V*(x)

OAPL 的核心思路：用最小二乘回归让当前策略 π 拟合这个关系：

min_π Σ_x Σ_i (β · ln(π(y_i|x) / π_ref(y_i|x)) - (r(x,y_i) - V̂*(x)))²

其中 V̂*(x) 用 group rollouts 估计：

V̂*(x) = β · ln (1/G · Σ_i exp(r(x,y_i) / β))

实践中的双参数设计：论文引入两个独立的 β 参数——β₁ 用于计算 V̂*（控制价值估计的平滑度），β₂ 用于损失函数中的 KL 正则化强度。这提供了额外的调节自由度。

4.2 多步 Agentic 场景的处理

Agent 的 rollout 是多步的，包含模型生成的 token（搜索查询、摘要、最终答案）和工具返回的 token（检索到的文档）。OAPL 的处理：

Token 掩码：只计算模型生成的 token 的 log-probability。prompt token 和工具返回的 token 被掩码掉——它们不是模型”说”的，不应该参与策略优化。

轨迹分段：对于涉及多次压缩步骤的长轨迹（BrowseComp-Plus），在每个压缩步骤处切分：

• 每个段的 (x, y)：x = 压缩后的历史摘要，y = 直到下一次压缩的所有步骤
• 每个段使用整个 rollout 的奖励（不是段级奖励）
• V̂* 在初始 prompt 处计算

压缩步骤也纳入 RL：为压缩步骤单独创建 (x, y) pair：x = 待压缩的历史，y = 模型生成的摘要。同样使用整个 rollout 的奖励作为信号。

这个设计的好处：

1. 避免在超长序列上训练（节省 GPU 内存）
2. 压缩和搜索端到端联合优化
3. 模型学会”为了最终任务目标而压缩”

4.3 迭代训练

Round 1: π_ref = GLM 4.5 Air → 生成大批离线数据 → OAPL 优化 → π_1
Round 2: π_ref = π_1 → 生成新的离线数据 → OAPL 优化 → π_2
Round 3: π_ref = π_2 → 生成新的离线数据 → OAPL 优化 → π_3

实验最多做 3 次迭代。每次迭代后：

• 用新模型重新生成训练数据（数据质量随模型提升）
• 数据和训练完全解耦

4.4 与在线 GRPO 的全面对比

4.5 多任务 RL：简单但有效

选择 BrowseComp-Plus（深搜）和 TREC-Biogen（广搜）作为两个训练任务，因为它们测试结构性不同的能力。

实现方式极其简单：直接合并两个任务的损失，按总训练 token 平衡数据集比例。就是这样。没有任务权重调节、没有 curriculum、没有梯度控制。

结果：两个任务同时提升，4 个未见过的任务也同时提升。

第五部分：推理时计算扩展（Test-Time Compute）

KARL 探索了两种互补的推理时计算策略，都使用并行计算而非串行计算（为了延迟考虑）。

5.1 Parallel Thinking（通用策略）

流程：

给定问题 x
  ↓
模型 π 并行生成 N 个独立 rollout → N 个答案
  ↓（每个 rollout 都可以使用工具）
提取 N 个答案，喂给同一个模型 π
  ↓（aggregator 也可以使用工具）
输出最终答案

关键发现 1：Aggregator 不只是投票。 它会使用工具合成新答案。在 PMBench 上，23.7% 的时候 aggregator 生成了比任何单个 rollout 都好的答案。这使 Parallel Thinking 比 Best-of-N 或多数投票更有表达力。

关键发现 2：RL 的收益与 TTC 互补。 增加 N 对 GLM 4.5 Air 和 KARL 都有提升，但 KARL 在所有 N 值上都保持优势。RL 的收益不会被 TTC 抵消，反而叠加。

关键发现 3：Aggregation 步骤很轻量。 Table 7 显示 aggregation 平均只需 1.3-3.7 个 LLM 步，远短于搜索本身。

关键发现 4：收益在 N=15 后递减。 论文推测原因是 pass@k 饱和 + aggregator 的上下文长度压力（N 个 rollout 的答案一起喂进去）。

5.2 Value-Guided Search（任务特定策略）

Value Model 训练：

用 KARL 生成大量 rollout 数据 {x, y}，训练一个 Qwen3-4B-Thinking 模型作为 value model。训练目标是 token 级别的二元交叉熵——预测从当前 partial rollout 出发，最终得到正确答案的概率。

只对模型生成的 token 计算损失（工具返回的 token 被掩码）。

搜索过程：

每个 Agent 步骤：
  1. 模型 π 并行生成 k=2 个候选动作
  2. Value model 对每个候选评分
  3. 选最高分的候选
  4. 继续到下一步

重复这个 BFS 过程 N 次 → N 条完整轨迹
  ↓
聚合策略（MV / WMV / BoN）

聚合方式对比（BrowseComp-Plus，Figure 14）：

• Weighted Majority Voting（WMV）：效果最好，达到 70.4
• Best-of-N（BoN）：次之
• Majority Voting（MV）：最差

WMV 优于 MV 说明 value model 提供了超越频率的有用信号。BoN 弱于 WMV 说明跨 rollout 信息组合（投票）优于单选。

意外发现：VGS 扩展同时提升了文档召回率（Figure 14 right），尽管 value model 从未被训练来预测召回率。

5.3 Parallel Thinking vs VGS

• Parallel Thinking：通用，适用于所有任务类型（包括开放式生成任务）
• VGS：在答案有明确等价类的任务上（如 BrowseComp-Plus 的命名实体）效果更好
• 两者可以互补使用

第六部分：Agent 基础设施

论文用了相当篇幅描述工程基础设施，这在学术论文中极为罕见。

6.1 高吞吐 Vector Search

RL 训练需要生成海量 rollout 数据（数十万条长轨迹），每条轨迹包含大量检索查询。传统 client-server 向量数据库的网络 I/O 是瓶颈。

KARL 的方案：嵌入式列式向量数据库

离线处理：
  文档 → 分块 → Embedding → 建索引 → 缓存到共享存储

运行时：
  每个 worker 进程 → 从缓存加载索引到内存 → 嵌入式查询（零网络 I/O）

结果：每台机器 500+ QPS，确保 GPU 利用率最大化。

6.2 aroll 框架

三大设计目标：

1. 高吞吐：支持数十万条长轨迹的离线数据收集
2. 可组合的任务特定奖励：添加新任务不需要改代码
3. 训练和推理完全同构：从数据收集到训练到评估到线上推理，用完全相同的代码路径

三层抽象：

Exploration Strategy（最外层）
  ├── 接收 prompt 批次
  ├── 实例化 Environment-Agent 对
  └── 编排并发执行，收集完成的 rollout

Environment（交互循环）
  ├── 每步：呈现历史 → 调 Agent → 执行工具 → 评估奖励
  ├── 奖励函数通过配置声明，独立于策略和 Agent 代码
  └── 新增任务 = 新增奖励配置

Agent（决策封装）
  ├── 标准实现：每步一次 LLM 调用
  └── VGS 实现：每步 k 个并行候选 + value model 选择（即插即用替换）

Lifecycle Plugins：横切关注点通过插件注入：

• 压缩插件：token 超阈值时触发，强制 Agent 压缩历史
• 步数预算插件：限制最大步数
• 工具网关插件：控制工具调用权限

插件通过配置组合，所有环境（数据收集/训练/评估/推理）使用完全相同的插件列表。

为什么同构很重要？ 训练时使用的代码路径和推理时不同，会导致分布偏移（distributional shift）。论文引用 Yang et al. 2024 指出这是一个已知问题。aroll 通过同构设计从架构层面消除这个问题。

第七部分：实验结果详解

7.1 主实验结果（Table 4）

单任务 RL 验证：

• KARL-TREC（只在 TREC-Biogen 上训练）：TREC-Biogen 得分 85.0（第二名），但 BrowseComp-Plus 只有 42.2
• KARL-BCP（只在 BrowseComp-Plus 上训练）：BrowseComp-Plus 得分 59.6，但 TREC-Biogen 只有 68.0

结论：单任务训练在自己的任务上很强，但无法迁移到另一个分布内任务。

多任务 RL 主结果：

关键观察：

• 无 TTC 的 KARL 已经接近 Claude Sonnet 4.5 水平，总分 58.9 vs 58.6
• KARL par. N=3 超过 Claude 4.6 Sonnet：64.1 vs 62.3
• KARL par. N=10 匹配 Claude 4.6 Opus：67.5 vs 67.5
• KARL par. N=20 超过所有模型：68.1

7.2 成本和延迟优势

成本：

• 单次调用 KARL 不到 $0.10/query，是 55 分以上所有模型中最便宜的
• KARL 比它的基座模型 GLM 4.5 Air 还便宜，同时得分高 6+！原因：RL 让模型学会了更高效地搜索，更少的步骤、更少的 token 开销
• KARL par. N=10 匹配 Opus 4.6 质量，成本低 33%

延迟：

• 无 TTC 的 KARL 是 55 分以上所有模型中延迟最低的
• KARL par. N=10 匹配 Opus 4.6 质量，延迟低 47%（并行轨迹并发执行）

7.3 多专家蒸馏 vs 多任务 RL（Figure 8）

论文对比了一种流行的替代方案：分别训练 BrowseComp-Plus Expert 和 TREC-Biogen Expert，然后通过 SFT 蒸馏合并（DeepSeek-V3.2 和 GLM-5 使用的方案）。

关键发现：

• 蒸馏 + TTC 在分布外几乎没有提升（59.4 → 59.6，+0.2）
• KARL + TTC 在分布外大幅提升（53.7 → 62.7，+9.0）

结论：蒸馏教模型模仿任务特定的专家行为，在分布内能通过 TTC 进一步放大，但无法泛化。RL 发展出的是更通用的搜索能力，TTC 在分布内外都能放大。

7.4 多轮迭代训练（Figure 9）

以 KARL-TREC（3 轮迭代）为案例：

每轮迭代都有意义的提升，没有到达平台期。分布外任务也同步改善（尽管只在 TREC-Biogen 上训练）。

7.5 RL 不只是 Sharpening（Figure 10-11）

这是论文中最有说服力的分析之一。

背景：学界有争论——RL 后训练是真的学到了新能力，还是只是”锐化”（sharpening）了基座模型已有的分布？如果只是 sharpening，那 max@1 会提升（更一致地给出正确答案），但 max@k（k 大时）不会变（因为能力边界没扩展）。

KARL 的证据：

max@k 在所有 k 值上都随迭代提升：

• 训练后 max@1 = 基座的 max@8
• 训练后 max@2 已经超过基座的 max@16
• 也就是说：训练后模型 2 次尝试就能解决基座模型 16 次都解不了的问题

这证明 RL 真正扩展了模型的问题解决能力边界。

Pass@16 流动分析（Figure 11）：

• 37.2% 的 Unsolved 问题变成了 Partial
• 33.3% 的 Partial 问题变成了 Solved
• 只有 6.4% 的 Solved 降级为 Partial
• 0% 的 Solved 降级为 Unsolved

关键细节：训练时 Solved 和 Unsolved 的数据都被过滤掉了（因为全对和全错的没有学习信号），所以训练后在这些 unseen 问题上的改善完全是泛化。

第八部分：RL 如何改变模型行为

8.1 搜索效率提升

在 87 个三个模型（GLM 4.5 Air、KARL Iter.1、KARL Iter.2）都达到完全召回的 BrowseComp-Plus 问题上：

大部分节省来自减少”无效搜索”——在已经检索到所有需要的文档后，GLM 4.5 Air 仍然继续搜索 134 步（错误答案的情况）。KARL Iter.2 把这个数字降到 56.5 步。

8.2 搜索多样性提升

尽管 RL 目标从未直接优化搜索多样性，KARL Iter.2 比 GLM 4.5 Air：

• BrowseComp-Plus：累计检索的独特文档增加 37%
• TREC-Biogen：增加 8%

GLM 4.5 Air 的低多样性部分原因是重复搜索模式（论文 Table 14 提供了具体案例）。

8.3 定性案例研究

案例 1：搜索坚持性

三个模型面对同一个难题：

• Claude Sonnet 4.5：25 步后放弃，结论”找不到”
• GLM 4.5 Air：用完整个 200 步预算，仍然没找到
• KARL：在第 155 步找到了正确答案

RL 训练让模型学会了在需要时坚持搜索，而不是过早放弃。

案例 2：证据推理

三个模型都检索到了大部分相关证据，但推理方式不同：

• Claude Sonnet 4.5：25 步后找对了书，但对类型做了无根据的假设
• GLM 4.5 Air：69 步后缩小到两本候选书，正确列出两个类型，但最终选错了
• KARL：7 步就正确识别了书和类型

8.4 搜索环境泛化（消融实验）

搜索步数（Figure 12 左）：性能从 10 步到 200 步稳步提升，200-400 步趋于平稳。模型学会了有效利用更多步数。

检索文档数（Figure 12 右）：k=10 到 k=20 性能稳定，k=40 急剧下降。原因：一次检索 40 个文档会填满大部分上下文窗口，没有空间做多步推理。

Embedding 模型替换（Table 5）：把 Qwen3-8B embedding 换成 GTE-large hybrid retriever，性能几乎不变（0.570 vs 0.568）。模型学到的是通用搜索策略，没有过拟合特定 retriever 的特性。

压缩工具移除（Table 5）：移除压缩工具导致大幅下降（0.570 → 0.389）。确认 KARL 依赖训练过的上下文管理策略。

对实践者的启示

如果你在做 RAG / 搜索 Agent

1. 不要只在一种搜索任务上优化：多任务训练带来的泛化效果远好于单任务 + 蒸馏
2. 合成数据管线值得投入：Agentic synthesis 比静态文档条件生成质量高得多——让合成 Agent 自己探索语料库
3. 难度过滤是关键：全对和全错的样本都没用，只保留”有的对有的错”的数据
4. 把压缩纳入训练：不要用独立的压缩模型，让 Agent 端到端学习如何管理上下文

如果你在做 RL 后训练

1. OAPL 是 GRPO 的更简单替代方案：不需要 importance weighting 等 trick，对 MoE 稳定
2. 离线大批次比在线小批次更实用：数据生成成本分摊，超参搜索方便
3. 迭代训练有持续收益：3 轮迭代没有到达平台期
4. 关注 max@k 分析：用它来判断 RL 是否真正扩展了能力边界

如果你在做 Agent 基础设施

1. 训练和推理用同一套代码：消除分布偏移
2. 嵌入式向量数据库：消除网络 I/O，RL 数据生成需要极高吞吐（500+ QPS/host）
3. Lifecycle Plugin 模式：压缩、预算控制等横切逻辑通过插件注入，新增任务只需新增奖励配置

如果你在做推理时计算扩展

1. Parallel Thinking 比投票更强：generative aggregator 可以合成超越任何单个 rollout 的答案
2. RL 训练收益与 TTC 互补叠加：不是替代关系
3. 小的 value model 就够用：Qwen3-4B 就能有效引导搜索

局限性与开放问题

1. KARLBench 自建成分：虽然包含了多个公开数据集，但 PMBench 未公开，整体套件的外部可比性需要社区验证
2. 只测试了 vector search：实际场景中 Agent 可能需要 SQL、API 调用、代码执行、网页浏览等多种工具，多工具编排未被评估
3. 基础模型限制：论文基于 GLM 4.5 Air（MoE），在其他架构（dense model、更大/更小模型）上效果如何未验证
4. 闭合语料库限制：没有测试开放网络搜索场景，live web content 的动态性未考虑
5. 蒸馏对比的公平性：蒸馏方案用了两个单任务专家，如果用单个多任务专家蒸馏效果可能不同
6. N=15 后收益递减的原因：论文推测是 pass@k 饱和和上下文长度压力，但未深入分析
7. 压缩行为的可解释性：虽然附录 G 有案例分析，但端到端学到的压缩策略是否最优仍然不清楚

延伸阅读

• OAPL: Ritter et al. 2026 — KARL 使用的 RL 训练算法的详细论文
• A*PO: Brantley et al. 2025 — OAPL 的理论基础，证明了 V̂* 估计的有效性条件
• BrowseComp-Plus: Chen et al. 2025 — 约束驱动实体搜索 benchmark
• TREC-Biogen: Gupta et al. 2024 — 跨文档生物医学报告综合 track
• Search-R1: Jin et al. 2025 — 另一种用 RL 训练搜索 Agent 的方案
• VGS: Wang et al. 2025 — Value-Guided Search 原始论文
• AgentIR: arxiv.org/abs/2603.04384 — 另一种 Agent 检索方案

本文基于 arXiv:2603.05218 原文（77 页，43 图，17 表）深度整理。重点提取了完整的技术方案、实验数据和工程实践细节，力求为读者提供可直接参考的实践指南。