比 o3 更快更准？听说有人打造了一个超强邮件助手 ART·E 原创

你有没有遇到过这种情况？

突然收到一条消息：“我弟弟周五航班的时间是几点？”
你打开邮箱，翻来覆去地查找，输入关键词，一页一页浏览，好不容易才找到那封关键邮件。

这种操作在 2025 年还存在，是不是有点反人类了？

最近，有一个项目就瞄准了这个痛点，推出了一个名叫 ART·E 的电子邮件研究代理。它并不是那种“看起来很厉害”的模型，而是真正能帮你从海量邮件中快速准确找到答案的工具。

最让人惊讶的是，它的表现竟然超过了 o3，不仅回答正确率更高，运行速度更快，成本也低了将近 64 倍。

ART·E 是什么？它真的有用吗？

ART·E 全称 ART·E（可能是某个缩写，但目前还没公开），是一个通过强化学习训练出来的 AI 助手，专门用于从你的邮箱中查找和回答问题。

比如：

• “RSVP 方式是什么？”
• “修订版 anexb.doc 文件在哪儿下载？”
• “公司差旅政策里关于酒店报销的规定是什么？”

这些问题听起来是不是很眼熟？没错，这就是我们日常生活中经常碰到的真实场景。

而 ART·E 的目标很简单：让你不再手动翻找邮件，直接发问，它就能给出答案。

更夸张的是，它不仅能回答出这些问题，还能告诉你这些答案来自哪几封邮件，出处一目了然。

数据从何而来？Enron 邮件库成了训练宝库

为了训练这样一个模型，首先需要一个庞大的数据集。

于是开发者们盯上了 Enron——这家在 2001 年因财务造假被起诉的能源公司。当时公布的近 50 万封邮件，意外地成为了研究人员的宝藏。

最终，他们从中挑选了 8 个员工的邮箱作为测试集，另外选了 20 个作为训练集。每个邮箱至少包含 5,000 封邮件，有些甚至超过 10,000 封。

光有邮件还不够，还需要大量真实的问题与答案对来模拟用户可能提出的查询。

于是，GPT-4.11 被派上用场了。每批处理 20 封邮件，自动生成多个问题和答案，同时还会打一个“how_realistic”分值，来过滤掉那些不合理的提问。

最终，得到了一个包含约 4000 个问题的合成数据集。

举几个真实的例子看看你就明白了：

这些数据既贴近现实，又具备代表性，非常适合用来训练和评估模型。

工具设计简洁高效，只围绕核心任务展开

为了让模型专注于核心任务，环境的设计也被尽可能简化。

提供了三个基础工具函数：

def search_emails(keywords, sent_after=None, sent_before):
    """根据关键词及时间范围搜索邮件"""
    # 返回最多10封匹配的邮件ID和摘要片段
    
def read_email(message_id):
    """读取指定ID邮件的完整内容"""
    
def return_final_answer(answer: str, sources: list[str]):
    """返回最终答案及引用邮件ID列表"""

这三个工具已经足够让模型完成大部分的操作了。

所有数据都存储在一个 SQLite 数据库中，并使用 FTS5 全文检索引擎来加速搜索。

整个流程也非常简单：

1. 接收初始提示词：任务描述 + 用户问题；
2. LLM 生成下一步动作（调用哪个工具）；
3. 执行工具，获取结果；
4. 将工具返回的信息加入上下文；
5. 重复上述步骤，直到返回答案或达到最大步数（默认为 10）。

没有复杂的递归逻辑，也没有花里胡哨的中间层，就是最为直接的执行路径。

测试现成模型：别急着训练，先看看大模型能干啥

很多人拿到新任务第一反应就是“赶紧训练一个模型”，但在正式训练之前，先尝试一些现成的大模型其实是非常有必要的。

原因有几个：

1. 可能你发现现有的模型已经做得很好了，根本不需要再训练；
2. 很多时候模型表现差是因为提示词缺失、工具不可靠或者任务模糊，这些问题 RL 也解决不了；
3. 最重要的是，当你最终超越这些模型时，那一刻的成就感会让你觉得一切努力都值得。

所以这次也测试了不少主流模型，包括 GPT-4o、Qwen-14B、o3、o4-mini 等等。

并通过 LLM-as-judge 的方式来做自动评估：

def judge_answer(golden_answer, model_answer):
    """判断模型回答是否正确"""
    prompt = f"请比较以下两个答案是否一致：\n\nGolden Answer: {golden_answer}\nModel Answer: {model_answer}"
    response = call_llm(prompt)
    return response.strip().lower() == "yes"

结果显示，即使是目前最强的大模型，在这类任务上的准确率也不高。这就为我们提供了改进的空间。

奖励函数怎么设计？告诉模型你要什么

这是整个过程中最关键的一环之一。

很多人都会误解：我已经有一个评价函数了，还需要什么奖励函数？

其实不然。虽然我们可以用 LLM 作为裁判来衡量答案是否正确，但这只是一个最终目标。而在 RL 中，我们还可以引导模型同时优化多个指标，比如：

• 准确性（Correctness）
• 幻觉抑制（Hallucination Penalty）
• 步数最小化（Turn Minimization）

最终采用的奖励函数如下：

def calculate_reward(correct, hallucinated, turns):
    base_reward = 1.0 if correct else -1.0
    hallucination_penalty = -0.5 if hallucinated else 0
    turn_bonus = 0.1 * (10 - turns) / 10  # 鼓励更少步骤
    return base_reward + hallucination_penalty + turn_bonus

其中：

• ​​correct​​ 表示答案是否正确；
• ​​hallucinated​​ 表示是否虚构答案；
• ​​turns​​ 是完成任务所用的步骤数。

这个函数背后的核心思想在于：既要鼓励模型回答正确，又要惩罚错误行为（如幻觉），还要让它尽可能高效完成任务。

训练过程揭秘：GRPO + ART 库实战

训练部分使用的是他们自己开源的 ART（Agent Reinforcement Trainer）库，采用 Group Relative Policy Optimization（GRPO）算法。

整个流程非常清晰：

1. 加载一批问题（每次加载 12 个）；
2. 每个问题跑 4 次轨迹（trajectory）；
3. 对每个轨迹计算奖励；
4. 使用 GRPO 公式更新模型权重；
5. 每 30 步运行一次验证集测试；
6. 直到模型在验证集上停止提升为止。

完整的训练脚本只有几十行代码：

from art.trainer import GRPOTrainer
from art.envs.email_agent_env import EmailAgentEnv

env = EmailAgentEnv()
trainer = GRPOTrainer(env=env, model="qwen-14b", reward_func=calculate_reward)

# 开始训练
trainer.train(
    dataset_path="data/synthetic_qa_dataset.json",
    num_epochs=2,
    learning_rate=1.2e-5,
    batch_size=12,
    rollout_per_questinotallow=4,
    save_dir="results/art-e/",
    log_to_wandb=True
)

训练监控方面也有一些小技巧：

• 观察奖励标准差：如果所有轨迹得分接近，说明模型陷入局部最优；
• 跟踪多个指标：包括准确率、幻觉率、平均步数等；
• 定期查看模型输出：防止 Reward Hacking，比如模型学会了重复调用同一个工具来“占满”回合数从而拿更多奖励。

最终，整个训练在一块 H100 GPU 上完成，耗时不到一天，总成本约为 80 美元。

性能对比：ART·E vs o3，谁更胜一筹？

最后来看一下 ART·E 的实际表现：

可以看到，ART·E 不仅在准确性上远超 o3，在成本和效率上也实现了质的飞跃。更关键的是，它能回答很多 o3 根本无法理解的问题。

结语：通往通用 Agent 的一小步

ART·E 的诞生并不是终点，而是探索真正智能代理（Intelligent Agent）旅程中的重要一步。

它证明了一个道理：即使是最前沿的问题，也可以通过合理的方法、合适的数据以及一点巧思，打造出令人惊艳的产品。

本文转载自​​Halo咯咯​​    作者：基咯咯