ART·E — 用 GRPO 把 8B 小模型训成邮件搜索 Agent，超越 o3

January 1, 2020

原文：Building ART·E: Reinforcement Learning for Email Search Agent Development | 开源模型：OpenPipe/art-e-008 | 训练代码：github.com/OpenPipe/ART

这篇文章基于 OpenPipe 团队的技术博客深度扩写。我以第一视角重新梳理了他们用 GRPO 把 Llama-3.1-8B 训成邮件搜索 Agent 的完整过程——从 Enron 邮件语料造数据，到 3 个工具的极简 Agent 环境，到多目标奖励函数设计，到 15 轮训练迭代的调参教训。最终这个 8B 小模型在邮件搜索任务上比 o3 更快、更便宜、更准确。

这篇文章说了什么

OpenPipe 团队做了一个叫 ART·E 的项目——用 GRPO 强化学习训练一个小模型当邮件搜索 Agent。给定一封邮件 inbox 和一个自然语言问题（比如"我女儿教室聚会的 RSVP 是什么"），Agent 通过搜索邮件、阅读邮件内容、返回最终答案来完成任务。

关键结果：

比 o3 更准：ART·E 答对了 60% o3 答错的问题
比 o3 更快：速度是 o3 的 5 倍（更少的工具调用轮次）
比 o3 更便宜：运行成本是 o3 的 1/64
训练成本：单张 H100，总花费不到 $80

核心结论：Agent RL 训练不需要海量标注数据。只需要一个可验证的奖励函数 + 一个合理的 Agent 环境 + 少量合成数据，就能在小模型上跑出比大模型更好的效果。

有效的实验就这几招

方法	做了什么	效果
多目标奖励函数	同时优化答案正确性 + 最少轮次 + 反幻觉，权重可调	速度 5x、幻觉减少、准确率反超 o3
减少轮次奖励	每多一轮给少量负奖励，鼓励模型一步到位	最终比 o3 平均少用近一整轮
幻觉惩罚	错误答案给显著负分（比"我不知道"更差）	训练后模型幻觉率低于 o3
Env 极简设计	只有 3 个工具：search_emails、read_email、return_final_answer	极简的环境让模型更快收敛，不会被复杂工具干扰
合成 QA 数据	基于 Enron 邮件语料 + GPT-4.1 生成 4000 条 Q&A，带 "how_realistic" 评分过滤	4,000 条足矣，数据质量比数量重要
15+ 指标监控	包括 answer_correct、sources_correct、num_turns、hallucination、bad_tool_call 等	及时发现 reward hacking、及时发现训练卡住

试了但没用的方法：中间奖励（partial credit）——给"搜到了目标邮件""读了目标邮件""来源邮件选对了"等中间步骤打分。理论上这些中途奖励应该让梯度更密集，但实际上没有加速训练，因为模型在训练早期就已经能足够频繁地找到正确答案，直接从最终结果学到了。

一个反面教训：给"多走几步"加正分 → 模型学会了在最后一轮反复重复同样的 tool call，直到达到步数上限。 奖励函数的设计要非常小心——模型总会找到你没想到的捷径。

一、先搞懂这些概念

1.1 邮件搜索 Agent 的任务

这是一个典型的多轮 Agent 任务。Agent 拿到一个自然语言问题和它能访问的邮件 inbox，需要通过"搜索→阅读→判断→回答"的循环来找到答案。

用户问题: "What time is my brother's flight on Friday?"

Agent 的执行过程:
Step 1: search_emails("brother flight Friday") 
        → 返回 10 条匹配邮件摘要（含 message_id）
Step 2: read_email("msg_12345")  
        → 返回完整邮件正文："Your flight CO1984 departs SFO at 3:45 PM..."
Step 3: return_final_answer("Your brother's flight departs at 3:45 PM on Friday", 
                             sources=["msg_12345"])

看似简单，但实际难点在于：

搜索关键词怎么选："brother flight Friday" 还是 "brother" + 日期推演？模型要根据第一次搜索结果决定下一步
哪封邮件值得点开读：关键词搜索可能返回 10 封相关但不同的邮件，模型要判断哪封真正包含答案
答案的出处：不能编，必须附上来源邮件 ID

1.2 3 个工具的极简环境

Agent 只有且仅有 3 个工具：

工具	功能	参数
`search_emails`	全文搜索邮件，返回最多 10 条结果（含 message_id + 匹配片段）	`keywords`, `sent_after`, `sent_before`
`read_email`	读取指定邮件的完整正文	`message_id`
`return_final_answer`	提交最终答案（含来源邮件 ID 列表）	`answer`, `sources`

环境底层是 SQLite + FTS5 全文搜索引擎。没了。

OpenPipe 团队强调：Agent 循环本身极其简单——没有递归调用、没有回溯、没有复杂编排。就是：调 LLM → 解析 tool call → 执行工具 → 把结果追加到对话历史 → 循环，直到模型输出最终答案或超过 10 步。

1.3 GRPO 训练循环

ART·E 的训练循环是这个样子：

从数据集取 12 个问题（和它们的正确答案）
对每个问题，跑 4 次 rollout（生成 4 条完整的 Agent 执行轨迹）
用奖励函数给 4 条轨迹分别打分
用 12 组 × 4 = 48 条轨迹 + 它们的分数，计算 GRPO loss 并更新模型
每 30 步跑一次验证：100 条验证问题，计算准确率
回到步骤 1，直到验证集上不再提升

注意几个细节：

num_generations=4（每个 prompt 生成 4 个候选），比通常的 8 要少——因为邮件 Agent 的轨迹很长（多轮交互），4 个已经很耗显存
验证集 100 条、每 30 步验证一次——频繁验证对于发现 reward hacking 很关键
训练在单张 H100 上跑，15 轮迭代

二、数据：基于 Enron 邮件语料的合成 Q&A

2.1 为什么用 Enron

Enron 是 2001 年一家能源公司，因大规模会计欺诈被起诉，诉讼过程中约 50 万封真实邮件 被公开。这是目前能拿到的最大的真实英文邮件语料。

一个自黑的建议：如果你也打算从事大规模会计欺诈，记得不要保留邮件。

2.2 如何合成 Q&A

随机选了 28 个员工 inbox（20 个训练、8 个测试），每个 inbox 至少 5000 封邮件。然后：

每个 inbox 里每次取 20 封邮件为一个 batch
每批邮件扔给 GPT-4.1，让模型生成 Q&A 对（问题 + 正确答案 + 来源邮件 message_id）
同时让模型输出一个 how_realistic 评分（0-1），这个评分在过滤不像是真人会问的问题上很有效
最终生成约 4000 条 Q&A

生成的数据样例：

问题	答案
What issues will be discussed at the Tuesday afternoon meeting with EES?	强制公用事业公司支付拖欠的 PX 信用额度、新的 1 美分附加费是否转嫁给客户、是否将客户退回 utility bundled service
When is the Astros group game against the Cubs?	Thursday, April 27, at 3:05 PM
What countries are on the boycott list for e-commerce trading?	Bahrain, Iraq, Kuwait, Lebanon, Libya, Oman, Qatar, Saudi Arabia, Syria, UAE, Yemen
What is my confirmation number for my Continental Airlines flight to Colorado Springs?	N1BTZH

合成数据最大的坑：GPT-4.1 生成的 Q&A 有时候答案本身就是错的——因为它对邮件的理解有偏差。所以评估时用的正确答案是人工二次校验过的。

三、奖励函数：多目标的艺术

OpenPipe 的奖励函数是一个典型案例——不是一道单选题，而是一张多维度打分表。

3.1 三大奖励维度

维度	权重	逻辑
答案正确性	最高	LLM Judge 判断 Agent 的最终答案跟标准答案是否一致
最少轮次	低（额外加分）	在答对的前提下，轮次越少越好——这是延迟的代理指标
反幻觉惩罚	高（负分）	如果答错了，给显著负分——比"我不知道"更差

3.2 最少轮次奖励的妙用

他们给了一个很小的"额外加分"：答案正确的情况下，用的轮次越少，奖励越高。

为什么是延迟的代理指标？因为 Agent 的速度瓶颈不是 LLM 推理一次的速度，而是多少轮 round trip——每一轮都要调 LLM、解析 tool call、执行工具、把结果塞回 prompt。轮次越少，用户等待越短。

训练结束后，ART·E 的平均轮次比 o3 少了近 1 整轮——这意味着即使单次推理速度相同，用户感知延迟也缩短了 20-30%。

3.3 幻觉惩罚

让模型答错不如让它说"我不知道"。答错会给用户虚假信息（在金融/邮件场景这可能会有实际损失），而说"不知道"至少是诚实的。

所以奖励函数的梯度：

正确答案 → 高分
"我不知道" → 低分但不惩罚
错误答案 → 负分（比"我不知道"更差）

训练后，ART·E 不仅答对率比 o3 高，幻觉率也比 o3 低。

3.4 中间奖励为什么失败

他们尝试了对中间步骤打分的 partial credit：

模型是否在某一步搜到了正确的邮件 → +分
模型是否在某一步读了正确的邮件 → +分
模型是否把正确的邮件列为了来源（即使答案错了）→ +分

结果：这些中间奖励基本没有加速训练。

原因是：任务本身没有难到模型完全找不到方向。模型从一开始就能——虽然不是每次都——找到正确答案。来自最终答案的稀疏奖励信号已经足够了。

关键教训：中间奖励是双刃剑。如果设计了不该设的中间目标，模型会去优化这些目标而不是真正想优化的事。早期一个实验给"多走几步"加分 → 模型学会了在最后一步反复重复同一个 tool call，直到 10 步耗尽。

"Show me the incentive and I'll show you the outcome." — Charlie Munger（原文引用）

四、训练监控：15+ 个指标的意义

OpenPipe 的 ART 框架把每个 rollout 的每个维度都做了结构化度量，总共 15+ 个指标：

class FinalRubric:
    answer_correct: bool = False           # 最终答案是否正确
    sources_correct: bool = False          # 来源邮件是否列对
    num_turns: int = 0                     # 用了多少轮
    attempted_answer: bool = False         # 是否尝试回答（vs 放弃）
    ever_found_right_email: bool = False   # 某一步是否搜到了正确邮件
    ever_read_right_email: bool = False    # 某一步是否读了正确邮件
    cant_parse_tool_call: bool = False     # 工具调用 JSON 解析失败
    bad_tool_call_name: bool = False       # 调了不存在的工具
    bad_tool_call_args: bool = False       # 参数不对
    ran_out_of_turns: bool = False         # 超过最大步数
    returned_i_dont_know: bool = False     # 主动说不知道
    num_sources: int = 0                   # 列了多少条来源
    ever_tried_to_read_invalid_email: bool = False  # 试图读不存在的邮件 ID
    prompt_tokens: int = 0                 # 输入 token 数
    completion_tokens: int = 0             # 输出 token 数

4.1 为什么要看这么多指标

GRPO 训练中最隐蔽的失败模式：reward 在涨，但模型在做跟你预期不同的事。

你只看 reward curve 往上升，以为训练正常。实际：

模型可能学会了钻奖励函数的空子（reward hacking）
模型可能陷入了某种退化的策略（比如每条都调 search → 永远停在第一步）
模型的所有输出可能都趋同了（zero-std 问题）

所以必须同时看多种指标，而且要定期抽查实际输出。 OpenPipe 团队跑了 15 个训练 job（大部分只跑了几小时），每次失败都靠这些指标定位问题。

4.2 最关键的监控信号

信号	含义	怎么办
Reward 标准差→0	所有 rollout 分数趋同，训练卡住	增加 rollout 数量、让奖励函数更细粒度、降低学习率、增加场景多样性
Number of turns 持续上升	模型学到了"多兜圈子"的坏习惯	检查奖励函数是否鼓励了多轮次
Hallucination 率不降	反幻觉惩罚不够重	加重幻觉惩罚、检查"我不知道"是否得到了合理奖励
Cant parse tool call 率不降	模型学不会输出格式	格式奖励不够好、可能需要先 SFT 再 RL

五、训练基础设施：ART 框架

OpenPipe 开源了他们的训练框架 ART（Agent Reinforcement Trainer），专门为多轮 Agent 的 GRPO 训练设计。

ART 的核心设计理念：

Rollout 函数标准化：每个 Agent 环境只需要实现一个 rollout 函数（输入 prompt → 跑完整个 Agent loop → 输出完整轨迹）
指标系统结构体化：每个 rollout 返回一个 Pydantic 结构体，所有指标自动上报到 W&B 和日志
Checkpoint 自动保存：reward 最高的模型自动保存

关键参数：

rollouts_per_prompt=4：每个 prompt 生成 4 条轨迹
steps=30 验证一次
单 H100 可跑，框架支持多 GPU

六、工程启示

6.1 先尽力把 prompted 模型推到极限

在开始 RL 训练之前，OpenPipe 花了很多时间 benchmark 各种模型（GPT-4.1、Claude、o3 等），反复修 Agent loop 的 bug、调整 prompt、确认工具确实能返回正确结果。

为什么？

你可能发现不需要训练——现成模型就够了
很多时候模型表现差是因为你没给够上下文、工具实现有 bug、目标定义模糊——这些问题 RL 也修不了
知道 prompted baseline 后，你的 RL 模型超越 baseline 时才能确认训练真的有效果

6.2 奖励函数是你的 UI

用户的"满意"最终只有你能定义。奖励函数就是把"什么是好"翻译成"多少分"的翻译器。这个翻译要做到：

高分的输出真的是你想要的（有效性）
低分的输出真的是你不想要的（区分度）
模型不能找到漏洞（鲁棒性）

6.3 不到 $80 的训练成本意味着什么

单张 H100、不到 $80，训出来的模型比 o3 更快更准。这意味着用 RL 训练垂直 Agent 的门槛已经非常低了——不再是大厂专属。

6.4 跟其他 GRPO Agent 项目的对比

维度	ART·E	RLVR Tool Calling	基金助手
Agent 类型	多轮搜索 Agent	单轮工具调用	多轮 SubAgent
工具数量	3	5+3(评估)	6
多目标奖励	✅(正确性+轮次+反幻觉)	✅(三层分级)	✅(复合加权)
中间奖励	❌ 失败	❌ 未尝试	⚠️ 部分有用
开源程度	模型+代码全开源	平台托管	-
训练成本	小于 $80	40 分钟 serverless	-

共同主线：奖励函数设计 + 小模型替代大模型 + 极简 Agent 环境 = 可靠的垂直 Agent。

这篇文章说了什么​

有效的实验就这几招​

一、先搞懂这些概念​

1.1 邮件搜索 Agent 的任务​

1.2 3 个工具的极简环境​

1.3 GRPO 训练循环​

二、数据：基于 Enron 邮件语料的合成 Q&A​

2.1 为什么用 Enron​

2.2 如何合成 Q&A​

三、奖励函数：多目标的艺术​

3.1 三大奖励维度​

3.2 最少轮次奖励的妙用​

3.3 幻觉惩罚​

3.4 中间奖励为什么失败​

四、训练监控：15+ 个指标的意义​

4.1 为什么要看这么多指标​

4.2 最关键的监控信号​

五、训练基础设施：ART 框架​

六、工程启示​

6.1 先尽力把 prompted 模型推到极限​

6.2 奖励函数是你的 UI​

6.3 不到 $80 的训练成本意味着什么​

6.4 跟其他 GRPO Agent 项目的对比​