AppliedModels
行业前沿前沿EvalEval
往期

2026 年 9 月 24 日

周四

检索截止 · 北京时间 09:14

评测动态

01

FinFIRST 在 9 月 21 日提交、进入本轮检索窗口。它评测金融信息搜索 Agent，但没有只看最后答案对不对，而是把一次研究任务拆成“原始信息获取、来源核验、计算与答案形成”三类原子标准。数据包含 123 个专家编写任务、138 个金融信息源，并由 50 多位金融从业者参与构造；15 组模型配置在统一工具条件下测试。论文报告 Claude Opus 5 的 atomic score 最高，为 87.59%，GPT-5.6 Sol 的 strict pass rate 最高，为 71.54%；不同系统普遍在“计算与答案形成”阶段弱于原始信息获取。它提供了一个值得留意的评测设计：保留最终任务成功作为目标，同时让中间证据链可以单独计分和定位错误。FinFIRST 论文 原注

02

RRSI 同样于 9 月 21 日提交，研究对象则从模型变成了 Agent harness。这里的 harness 指包围固定 backbone model 的 prompt、控制流、工具、memory 和 context management。作者让系统自动迭代这些组件，同时设置 regularization，防止它为了开发集专门长出 benchmark-specific trick。论文在 8 个 coding、workspace 和 engineering-design benchmark 上测试：针对演化集的提升最高 14.1 分，而 5 个 OOD benchmark 上最高提升 4.7 分；最终 harness 使用的 policy token 还比未正则化版本少约 30%。这个结果本身还不能说明哪种 harness 最好，但它把一个越来越重要的 Eval 问题摆得很清楚：Agent benchmark 的被测对象往往已经不是单独的模型权重，而是 model × harness 的组合。RRSI 论文 原注

03

这两项工作放在一起还有一个方法学上的共同点。FinFIRST 不满足于“最终答案正确率”，因为相同的错误结果可能来自检索、来源选择、对齐或计算；RRSI 则显示，即使 backbone 不变，外围运行系统也会改变 benchmark 表现。因此以后看到 Agent 榜单中的一个数字，至少要先分清两个问题：它测的是哪个系统边界，以及这个总分有没有能力区分失败发生在哪一层。

评测研读

1 / 1

xDailyBench：从“考试题”走向真实用户任务以后，评测单元发生了什么变化

今天研读一个 9 月 7 日发布、但很适合作为真实工作 Eval 入门对象的 xDailyBench。它的出发点很直观：很多经典 benchmark 先规定一道题，再要求模型给出一个标准答案；但现实里，人交给 AI 的事情经常只有一个比较自然的需求，例如“结合这些材料帮我准备参观攻略”“根据我的情况比较教育和房产方案”“检查这套留学文书评价标准”。需求可能没说完整，约束散落在附件和用户背景里，而且合格答案不止一种。xDailyBench 论文 原注

xDailyBench 因此没有先设计能力 taxonomy 再往里面填题。团队调查了超过 1,000 名参与者，让他们提交自己确实用 AI 做过、或者真实打算交给 AI 做的事情，同时提交原始 instruction、可选 workspace 文件、与任务有关的用户背景以及参考方案。经过筛选和交叉检查，最后得到 248 个任务，分布在个人生活、白领工作、学习研究及其他跨领域需求中，共 51 个细分场景。论文完整方法 原注

这里首先值得理解的是“任务来源”和“题目长得真实”之间的区别。一道 benchmark 题可以由研究者精心编写得非常像真实工作，却仍然是 synthetic task；xDailyBench 要求任务来自贡献者实际发生或真实计划发生的需求。作者甚至刻意保留日常请求中不那么规整的部分：目标没有完全说清、约束分散、需要结合用户背景、可能存在多个合理答案。它因此测试的不只是模型有没有某项知识，还包括模型能不能恢复“完成这件事实际需要满足什么”。

这种设计马上产生评分难题。如果任务是“给我制定一套符合这些现实条件的装修方案”，不存在唯一字符串可以 exact match。xDailyBench 的做法是给每道任务建立一组 task-specific binary rubrics：平均每题 13.3 条，每条独立判断 0 或 1，再按重要性加权得到 task score。Rubric 被要求满足 alignment、completeness 和 openness：要对应真正的任务要求，合起来覆盖成功所需的重要条件，但不能把某一份参考答案规定成唯一合法答案。Rubric 构造说明 原注

举一个教学性的简化例子，和论文真实样本区分开：假设用户说“我周末带一个十个月婴儿去广州两天，给我安排计划”，并提供酒店和航班信息。一个 rubric 可以检查“行程是否与航班时间相容”，另一个检查“是否考虑婴儿午睡”，再一个检查“推荐地点是否在相应日期开放”。最后可以有许多完全不同的行程都拿满分。这里 evaluator 判断的是成功条件有没有满足，而不是生成结果和 reference answer 长得有多像。

更有意思的是，xDailyBench 把这些 rubric 又分成显式与隐式要求。248 道任务中，70.5% 的 rubric 属于用户直接说出的 explicit requirement；18.5% 属于一般情况下完成任务应该满足、但用户未必会专门说出的 general implicit requirement，例如可执行性、事实准确、适当格式和专业惯例；另外 11.0% 是要根据用户身份和上下文推断的 user-specific implicit requirement。任务统计与 Rubric 分类 原注

这项拆分让总分之外多出一个很有解释力的信号。论文测试了 11 个 frontier model / agent configuration，所有模型在 implicit rubric 上都明显弱于 explicit rubric，差距至少 9 个百分点。例如 GPT-5.6 Sol 的 explicit rubric score 为 75.0，implicit 为 66.0；DeepSeek V4 Pro 则分别为 72.5 和 53.5。也就是说，“把用户写出来的条件完成”与“知道一件事情正常情况下还应该满足什么”在这套数据上表现为可分离的困难。模型结果 原注

不过这里有一个很容易误读的地方：这些结果并不是裸模型能力分。论文给所有系统提供统一的工具、文件系统和 execution pipeline，最多运行 120 个 Agent step；默认使用 Nanobot harness。但 Kimi-K3、Kimi-K2.6 和 Gemini 3.1 Pro 因与 Nanobot 兼容性明显较差，作者改用 OpenCode。文本结果由 LLM-as-a-Judge 判断，涉及文件的 deliverable 则由 Agent-as-a-Judge 判断，实验统一使用 GLM-5.1 作为 Judge。实验设置 原注

这个细节非常重要。若 A 模型用 Nanobot、B 模型用 OpenCode，那么 leaderboard 可以告诉我们“这些实际系统配置在 xDailyBench 上谁完成任务更多”，但不能把差异全部归因于模型权重本身。作者这样处理有合理目的：避免 harness compatibility 把某些模型压得过低；代价是 model-level causal comparison 变得不那么纯。真实工作 Eval 经常面对这种取舍——统一 harness 提高控制性，却可能人为惩罚不适配该 harness 的模型；允许适配 harness 更接近最佳实际使用，又减少模型间严格的控制变量。

评分器也有类似问题。xDailyBench 没有简单相信 LLM Judge。构造阶段会让人类贡献者和自动 Judge 对同一批实际输出逐 rubric 独立评分，每条 rubric 要达到至少 90% 的 human–automatic agreement；达不到就人工检查并修改 rubric。这个设计值得学习，因为它把“Judge 靠不靠谱”落实到了具体 criterion，而不是只报告一个整体相关系数。自动评分验证方法 原注

但 90% agreement 也不能理解成“自动评分已经有 90% 准确率，所以榜单误差可以忽略”。Agreement 是在论文定义的试验输出和 rubric 上测得的，而且 rubric 本身会被修改到更容易可靠判断。它证明的是这套最终评价协议经过了一轮可评性筛选；如果换 Judge、换模型输出分布，或者把同样方法迁移到另一批更主观的工作，仍然需要重新验证。

xDailyBench 最值得看的地方其实不是排行榜。作者根据 rubric failures 和 execution traces 找出了两种很真实的 failure mode。第一种是“方案写得很完整，却没做 feasibility check”：例如装修方案给出详细排期和预算，但排期已经超过用户搬家 deadline，模型仍然把它作为可执行方案交付。第二种是 evidence-collection non-convergence：Agent 已经搜索到了所需官方材料，却继续反复扩展搜索词，始终不进入整合和交付阶段；论文中的一个案例最后形成 94 次搜索链，耗尽 120-step budget，最终没有产物，得分为 0。失败轨迹分析 原注

这说明 task-level benchmark 和 capability benchmark 的信息结构很不一样。一个任务失败时，我们最初只知道“工作没完成”；有了 atomic rubric、capability tag 和 trajectory，才可能继续定位：是漏掉用户明确要求，是没有推断隐性条件，是计算错，是 artifact 不合格，还是 Agent 根本没有从搜索阶段收敛到交付阶段。反过来，如果只保留这些细粒度能力指标，又可能失去一个现实事实：业务最终拿到的是整份结果，十三条要求完成十二条并不保证这份东西真的可用。

因此，读 xDailyBench 的分数最好同时保留三个层次。task-level score 接近“整件工作完成到什么程度”；rubric-level score解释具体要求满足了多少；capability aggregation 用来寻找跨任务的重复弱点。三者不是互相替代的指标，而是在不同粒度回答不同问题。

对当前研究的启发

xDailyBench 对四角色框架最有价值的地方，是它提供了一个框架之外的观察角度：角色定义和评测粒度是两件事。 Operator 当前定义为“把明确输入转化为业务流程需要的结果”，Reviewer 是“依据规则、标准或证据进行判断、检查和把关”。xDailyBench 中确实可以找到类似工作，但整个 benchmark 并没有按照角色组织，而是从真实用户需求出发，再把一份工作拆成多个 success criteria。Benchmark 的存在本身因此不能证明某个角色具有多大的业务需求。

它倒是对“work unit 应该怎样评分”提供了比较直接的方法参考。如果未来一个真实工作 Bench 只给整题 0/1，那么诊断价值可能很低；如果只统计几十个细能力分，又可能无法回答模型究竟能不能把工作接走。xDailyBench 的 task → atomic rubric → capability tag 三层结构值得保留为一种候选设计：work unit 是主要评测对象，rubric 负责解释为什么成功或失败，跨题聚合后才形成能力信号。

同时，它对“明确输入”这四个字提出了一个值得继续观察的问题。真实任务的输入可以是明确存在的——instruction、文件、用户背景都给了模型——但“成功条件”未必全部被用户显式写出。xDailyBench 中所有模型在 implicit requirements 上至少低 9 个百分点，就是一条外部证据，说明“能按明确约束交付”和“能从工作情境恢复未明说但必要的要求”可以形成不同难点。现在还不足以因此修改 Operator 定义，但后续若更多真实工作 benchmark 反复出现这一结构，就值得判断：implicit contract inference 是 Operator 内部的一项能力，还是四角色框架目前没有描述到的另一类工作责任。xDailyBench 原注

部分原生引用无法独立还原；缺少独立网址的条目已标明，已有网页链接均按原稿保留。