CodexQA

Industry & PracticeResearch & Benchmarks

TreasuryQA Bench:智能体能不能处理一份扫描财务档案

CodexQA 团队42 min read

70 道题要求智能体在 Dropbox 里自己找到财政部扫描卷,再读出页上的一个数字。最好的智能体解出 64.8% 的尝试,最常见的失败是把淡数字读错一位。

In this piece

预印本。通信作者:Ritiz Tambi,电子邮件 ritiz@veris.ai

TreasuryQA Bench:智能体能不能处理一份扫描财务档案

Ritiz Tambi、Sahar Shayegan、Joshua Meyer、Sun Kim、Ali Khan、Victor Shih、Mehdi Jamei、Andi Partovi 所属单位:Veris AI。八位作者都在这家公司任职,通信作者是名单中的第一人。

2026 年 10 月

摘要

机构把几十年的财务记录以扫描 PDF 放在共享盘上,人工智能智能体现在可以通过模型上下文协议(Model Context Protocol,MCP)服务器访问这些盘。现有基准没有照见这种生产环境,因为它们把任务简化了。有的把相关文档直接交给智能体,于是它从不用搜索。有的让智能体在已经抽好文本的文档里搜索,于是它从不用读扫描图像。我们提出 TreasuryQA Bench,两件事都要做:在 Veris 的高保真 Dropbox 孪生环境里,针对 1,435 份美国财政部扫描出版物提出 70 个问题。每一题里,智能体通过 Dropbox 的 MCP 服务器找到相关文件,用 Reducto 的托管光学字符识别服务器或自己的工具读需要的页,并回复一个精确数字。一个 Python 评分器把每个答案对照正确答案周围的接受区间来检查。本文给出十个智能体的结果。最好的是 Claude Code 里的 Claude Opus 5.5,解出 64.8% 的尝试;最差的是 Codex 里的 GPT-5.6 Terra,解出 16.7%,所以这个基准远没有饱和。我们也检验扫描质量如何影响成绩:每个智能体在最模糊的扫描上都解出更少的题。多数失败尝试回复的是一个错误数字,而不是不给数字,最常见的原因是从扫描件上读错一位。文中附有三个带答案键的演算例。

1 引言

假设一位人类分析师被问到一个问题,答案躺在几十年的扫描财务记录里 [18, 16]。分析师必须先找到正确的文件,再定位正确的表,读对行和列,并用该表的合计核对这个数字。拿到同一问题的人工智能智能体用工具走同样的步骤:用云盘的模型上下文协议(MCP)服务器搜索文件 [1, 6],再用一个把扫描页变成文本的托管文档阅读器 [17]。智能体自己决定怎么搜盘、读哪些页,以及是否相信阅读器返回的文本。

现有基准只覆盖这条工作流的局部(表 1,第 2 节)。文档问答基准把页面交给智能体,并且可能接受差一点的答案 [12];智能体基准和金融基准给的是预先抽出的、机器可读的文本,而不是页面图像;工具使用基准评的是智能体留在某项服务里的状态。OfficeQA Pro [16] 要求从扫描的美国财政部公报里取出精确数字,但它的智能体是在自己文件系统上的整份语料本地副本里工作,而不是通过生产环境里会用到的工具。

表 1:TreasuryQA Bench 与最接近的基准。扫描件:没有机器可读文本的页面图像。检索:智能体必须在更大的集合里定位源文档。在线工具:工具服务器或有状态的服务。$\circ$:部分如此(语料只有一部分是扫描件;只用开放网页或一份本地副本)。

基准智能体读到什么扫描件检索在线工具评分任务数
DocVQA [12]一页图像✓✗✗ANLS 相似度50,000
TAT-DQA [25]1–3 页报告$\circ$✗✗精确匹配、F116,558
GAIA [14]网页、文件✗✓$\circ$准精确匹配466
BrowseComp [19]开放网页✗✓$\circ$大语言模型评判1,266
OfficeQA Pro [16]财政部公报$\circ$✓$\circ$精确匹配133
Finance Agent [3]SEC 申报、网页✗✓✓量规、大语言模型评判537
$\tau^{2}$-bench [2]服务数据库––✓结束状态279
MCPMark [20]MCP 服务状态––✓结束状态脚本127
TreasuryQA Bench(本文)扫描卷册✓✓✓Python、区间70

我们给出 TreasuryQA Bench(图 1)。它的档案是 OfficeQA Pro v2 语料中的 1,435 份纯图像 PDF [5],即 1793 年至 2024 年的美国财政部出版物,放在 Veris 的高保真 Dropbox 孪生环境里。智能体通过 Dropbox 的 MCP 服务器接触文档,并用 Reducto 的托管 MCP 服务器读页;网页搜索关闭。70 个任务都是分析师的问题,各有一个数值答案,其中 55 个为 TreasuryQA Bench 新写,15 个改编自 OfficeQA Pro v2。一个 Python 评分器把每个答案对照正确答案周围的接受区间来检查(第 3.5 节)。

一次作答流程

我们评测十个智能体,每一个都是放在自己的命令行脚手架里的一个模型,每题三次(表 2)。Claude Code 里的 Claude Opus 5.5 解得最多,占尝试的 64.8%,并不显著高于 Gemini CLI 里的 Gemini 4 Argon(60.0%)。最差的是 Codex 里的 GPT-5.6 Terra,解出 16.7%,所以这个基准远没有饱和。每个智能体在最模糊的扫描上都解出更少的题。多数失败尝试回复的是错误数字而不是不给数字,最常见的原因是从扫描件上读错一位。我们的贡献是:

  • TreasuryQA Bench:70 道精确数字题,对象是通过 Dropbox 的 MCP 服务器接触到的财政部扫描记录,答案键由程序算出并对照扫描件核对(第 3 节)。
  • 一个 Python 评分器,把每个答案对照一个接受区间来检查(第 3.5 节)。
  • 对十个模型与脚手架组合的评测,包括费用、时间、工具使用和失败原因(第 5 节与第 6 节)。

2 相关工作

#### 文档理解与光学字符识别。

扫描财务报告已经是基准的对象:Kleister 要求从慈善机构财务报告里取出收入和支出之类的金额,其中大多数是扫描件 [18]。DocVQA 用字符串相似度给关于单页图像的答案打分,所以小的光学字符识别错误代价不大 [12]。TAT-DQA 就几页财务报告提问,许多题需要算术,并且只有数字完全一致才给分 [25]。MMLongBench-Doc 把每一页的截图交给模型,并接受 1% 以内的小数答案 [11]。光学字符识别的错误也会传到建立在抽出文本之上的答案里 [23]。这些系统都是把文档直接交出去。在 TreasuryQA Bench 里,智能体必须先在一份大档案里找到那一页,而 1% 的容差会接受示例任务上给出的每一个错误数字(图 2),其中大多数是把淡淡的 8 读成了 6。

#### 文档集合上的问答。

GAIA [14] 和 BrowseComp [19] 问的是网页和文件上的短答案问题,不是扫描文档档案。OfficeQA Pro [16] 问的是美国财政部公报上的问题,按精确匹配评分;1996 年以前的期次是扫描件,嵌入的文本层被去掉。它的智能体在装有光学字符识别库的本地副本上工作,把解析好的文本交给它们会提高准确率。我们使用的 v2 发布是一份新的 1793–2024 语料,PDF 随附解析文本 [5]。AGORA 就职场文档提出数值问题,智能体在离线沙箱里探索 [7]。TreasuryQA Bench 扣下解析文本,把扫描件放在文件库的 MCP 服务器后面,给每个智能体同一个托管阅读器,并对照已知的错误答案设定每个区间。

#### 金融问答。

金融问答基准问的是现代公司申报,例如盈余报告 [4] 和完整的公开申报 [8],这些材料自带机器可读文本。智能体金融基准让模型研究美国证券交易委员会申报,由带量规的大语言模型评判来评分 [3]。在 TreasuryQA Bench 里,文档只以页面图像存在,智能体必须先在盘里找到正确文件,而且每题只有一个脚本可以核对的数值答案。

#### 工具使用环境与脚手架。

智能体基准越来越多地评智能体留在客户服务工具背后的数据库里的状态 [22, 2],或留在真实 MCP 服务器里的状态 [20];TheAgentCompany 让智能体在自托管盘以及其他服务里处理文件 [21]。TreasuryQA Bench 不评最终状态。它的难度在于通过 Dropbox 和 Reducto 的工具来阅读。模型外面的脚手架既改变准确率也改变费用 [9],并且可以颠倒排名 [10]。因此每个专有模型都跑在其厂商自己的命令行界面里,Terminal-Bench 也是把厂商的模型配到该厂商的界面上 [13],我们用模型和脚手架一起来称呼每个智能体。我们把费用和准确率一起报告,并遵循智能体基准清单 [26]。

3 TreasuryQA Bench

图 1:一次 TreasuryQA Bench 尝试。智能体通过 Dropbox 的 MCP 服务器,在 Veris Dropbox 孪生环境的一份新副本里找到卷册,并把下载链接交给 Reducto 的 MCP 服务器,后者返回它所要的页。若其 ANSWER: 行上的数字落在该任务的区间内,这次尝试就算解出。

3.1 设计与任务表述

三个选择塑造了 TreasuryQA Bench。场景对齐真实使用:云盘里没有机器可读文本的扫描件,通过该盘自己的 MCP 服务器接触。每个答案键都由程序从源文档算出,并在扫描件上确认。由 Python 评分器而不是模型决定答案对不对。智能体只拿到一次问题,独自工作,以一次回复结束。图 2 给出一个示例任务。

图 2:一个示例任务。答案是一张表里的一个单元格。智能体必须找到卷册,选中小计行,并用该页自己的合计来确定一个淡淡的数字。

示例任务

3.2 环境

本节说明档案、孪生环境、阅读器以及每次尝试所在的容器。

#### 档案。

档案是 OfficeQA Pro v2 语料 [5]:一个文件夹里的 1,435 份 PDF。我们数出 118,524 页,并核对过这些文件都没有机器可读文本。大多数是年度的《收入、支出与余额合并报表》(Combined Statements of Receipts, Expenditures and Balances,1872–2024);其余是更早的收支报告(1793–1893)。大多数文件以 150 像素每英寸扫描,但有的粗到 60 像素每英寸。

#### Dropbox 孪生环境。

档案放在 Veris 的 Dropbox 孪生环境里,该环境由对在线服务的录制建成,每次尝试得到一份新副本。智能体使用 Dropbox 的 MCP 服务器及其真实工具列表和说明 [6],我们把下面每一种行为都对照在线服务核对过。search 匹配文件名和文件文本,因此对扫描件只匹配名字。get_file_content 返回文件文本,扫描件的文本是空的,并且拒绝超过 5 MB 的文件。download_link 返回一个短时链接,智能体把它传给 Reducto。孪生环境不提供 Dropbox 自己的光学字符识别,所以每个智能体都通过同一个阅读器读页。

#### Reducto。

每个脚手架都连接到 Reducto 的托管 MCP 服务器 [17],它把文档中选定的页变成文本和表。它从 URL 而不是从智能体的磁盘读文档,所以智能体把下载链接传给 parse_document,或传给 upload_file,后者返回一个标识,供以后的调用复用。

#### 脚手架、容器与说明。

每次尝试在一个新容器里运行一个脚手架,容器里有 Python 和常见命令行工具,但没有档案文件,也没有光学字符识别引擎。每个脚手架保留自己的内置工具:外壳、文件工具,以及 Claude Code 的子智能体。网页搜索关闭,但外壳可以到达网络。智能体收到共用说明(附录 A)和问题,合成一条消息;每个命令行界面保留自己的系统提示。说明解释文件如何命名,告诉智能体通过卷册目录找到页,并用 Reducto 读较小的页范围,要求使用一个数字的最新修订,如同 OfficeQA Pro 那样 [16],并要求最后一行是 ANSWER: <final answer>。每次尝试有 30 分钟。

3.3 任务构建

我们分三步建任务:脚本找出候选数字,大语言模型智能体围绕每个数字写一道题,脚本和一个模型求解器检验草稿。然后我们对照扫描件核对每一题,并自己复查(第 3.4 节)。

#### 寻找候选数字。

OfficeQA Pro v2 随 PDF 提供解析文本。智能体从看不到它,但我们用它来建任务。脚本在其表里搜索这样的单元格:其值由该表自己的行合计或列合计所固定,因此即使解析文本是错的,正确数字仍能在页面上确认。

#### 撰写任务。

大语言模型撰写智能体从文档重新推导每个候选数字,并丢掉站不住的。对剩下的 70 个,智能体各写三样东西。问题写明时期、单位和精度,但不写用哪份文档,也不写如何计算答案。预言机是一个 Python 程序,从源文档读取数字并算出答案键,所以没有答案键是手工键入的。它还检查表的合计是否确认该键,每个已知错误答案是否都落在区间之外,并且对大多数任务检查档案里没有任何文档直接印出答案。已知错误答案是说得通的失误:读错的单元格、相邻的行或年份、另一个基数,或翻错的符号。70 个问题里,55 个是新的,15 个改编 OfficeQA Pro v2 的问题 [5],就同一批文档问一个不同的量。

#### 检验草稿。

脚本拒绝没有预言机或没有已知错误答案的草稿,拒绝已知错误答案落在区间内的草稿,也拒绝与另一题重复的草稿。然后一个 Claude Sonnet 5.5 智能体带着解析文本试做每题。它解出 23 题,并在 39 题上给出已知错误答案。没有任何任务因为结果而被丢掉。

3.4 质量控制

#### 在扫描件上核对答案键。

模型智能体把每个答案键的源页以高分辨率渲染出来,重读单元格并重算答案键。全部 70 个键都成立。有 7 题印出的数字与其表的合计不一致;那里答案键跟随合计。

#### 修订。

主运行之前,我们改写了 8 个允许第二种读法的问题,并把求解器的一些错误答案加进已知错误答案列表。试点之后,我们复查了没有任何尝试解出的任务。每个答案键都成立,我们改写了一题。其中三题的答案在我们找到的任何副本上以 60 像素每英寸都读不出来,于是我们用一份公开副本里更清晰的图像替换了它们的答案页,保留页码,并且不加入机器可读文本。其余文件都不改。作者复查了每一题、核对智能体的每一项发现,以及每一处编辑。

3.5 评分与指标

#### 评分。

一个 Python 评分器读取回复最后一行 ANSWER: 上的数字(附录 E),若它落在该任务的接受区间内,这次尝试就通过。美元答案大约允许一美元的舍入;其他答案允许百分之零点几的一个小分数。每个区间都收得足够窄,以拒绝说得通的错误答案,例如读错一位或相邻年份。没有数字的回复失败。

#### 为什么不用大语言模型评判。

拿到同样答案键的大语言模型评判放过了 32 个错误答案,其中大多数只差一位。即使给了参考答案,大语言模型评判仍可能接受错误答案 [24],而差一点正是 TreasuryQA Bench 要测的。

#### 外部来源。

智能体可以在网上查找基准答案 [9],所以我们审计了每一次到达档案之外网站的通过尝试。这 27 次里,13 次使用了档案之外的数字,计为失败(第 6.3 节)。

#### 指标。

pass@1 是一个智能体的尝试中被解出的比例;pass@3 是三次尝试里至少解出一次的任务比例,pass3 是三次全部解出的任务比例 [22]。我们报告在任务上的 95% 区间 [15],由自助法算出。排名里相邻智能体之间的差异,在配对的任务级差异上检验 [15],用带 Holm 校正的自助法。

#### 获取。

三个演算例,即图 2 的任务和附录 B 的两个,连同答案键一起给出,说明在附录 A。其余任务保持不公开,以保护答案键。

4 实验设置

我们评测十个智能体,每一个都是钉在一个版本上的命令行脚手架里的一个模型:Claude Code 里的 Claude Opus 5.5 和 Claude Sonnet 5.5,Codex 里的 GPT-6.1 Sol 和 GPT-5.6 Terra,Gemini CLI 里的 Gemini 3.8 Flash 和 Gemini 4 Argon,Grok CLI 里的 Grok 4.7,以及开源 Pi 脚手架里的 GLM 5.3 Flash、Kimi K3 和开放权重的 DeepSeek V4.1 Flash(版本与提供方见表 5,附录 D)。每个智能体的推理力度都是高。每个智能体每题尝试三次,任务文本、说明和设置都相同,共计 2,100 次尝试。费用是智能体自己的模型花费,按标价,不含 Reducto 的收费(附录 G)。下文把名字简写为 Opus、Sonnet、Sol、Terra、Gemini 3.8 Flash、Argon、Grok、DeepSeek、GLM 和 Kimi。

5 结果

表 2:70 题、每题三次尝试的主要结果:pass@1 及其 95% 任务自助区间,pass@3 与 pass3(第 3.5 节);按标价计的每次尝试与总计的智能体侧费用,缓存读取按缓存费率计费;以及每次尝试的中位分钟数和工具调用数。每一列的最佳值用粗体。

智能体脚手架pass@1 [95% 区间]pass@3pass3美元/次美元合计分钟调用
Claude Opus 5.5Claude Code64.8 [55.7, 73.3]81.445.71.563285.324
Gemini 4 ArgonGemini CLI60.0 [50.0, 70.0]71.445.72.4551416.846
GPT-6.1 SolCodex51.4 [41.0, 61.4]64.338.60.6213011.233
Gemini 3.8 FlashGemini CLI51.0 [40.5, 61.4]65.737.11.7436610.386
Claude Sonnet 5.5Claude Code41.9 [31.9, 51.9]58.627.11.192513.025
DeepSeek V4.1 FlashPi37.1 [28.1, 46.2]57.117.10.25538.867
Kimi K3Pi27.6 [18.6, 36.7]40.018.62.555357.641
GLM 5.3 FlashPi27.1 [19.0, 35.7]45.711.40.245012.860
Grok 4.7Grok CLI18.1 [11.4, 25.2]32.94.33.557457.347
GPT-5.6 TerraCodex16.7 [10.0, 24.3]30.08.61.172472.416

表中十行按通过率从高到低排列。Claude Opus 五点五在 Claude Code 中的一次通过率为百分之六十四点八,区间从五十五点七到七十三点三,三次至少通过一次为百分之八十一点四,三次都通过为百分之四十五点七,每次一点五六美元,合计三百二十八美元,中位五点三分钟、二十四次调用。Gemini 四点 Argon 为百分之六十,七十一点四与四十五点七,每次二点四五美元,合计五百一十四美元,十六点八分钟、四十六次调用。GPT 六点一 Sol 为百分之五十一点四,六十四点三与三十八点六,每次零点六二美元,合计一百三十美元。Gemini 三点八 Flash 为百分之五十一点零,六十五点七与三十七点一,每次一点七四美元,合计三百六十六美元。Claude Sonnet 五点五为百分之四十一点九,五十八点六与二十七点一,每次一点一九美元,合计二百五十一美元。DeepSeek V 四点一 Flash 为百分之三十七点一,五十七点一与十七点一,每次零点二五美元,合计五十三美元。Kimi K 三为百分之二十七点六,四十点零与十八点六,每次二点五五美元,合计五百三十五美元。GLM 五点三 Flash 为百分之二十七点一,四十五点七与十一点四,每次零点二四美元,合计五十美元。Grok 四点七为百分之十八点一,三十二点九与四点三,每次三点五五美元,合计七百四十五美元。GPT 五点六 Terra 为百分之十六点七,三十点零与八点六,每次一点一七美元,合计二百四十七美元。

#### Opus 领先,但不显著。

Opus 解出其尝试的 64.8%,Argon 解出 60.0%(表 2)。差距不显著,而且 Opus 每次都解出、Argon 一次都没解出的四题就占满了全部差距。智能体分成五对:Opus 与 Argon;Sol 与 Gemini 3.8 Flash;Sonnet 与 DeepSeek;Kimi 与 GLM;Grok 与 Terra。校正多重比较之后,没有一个智能体显著领先于排名紧挨在它下面的那一个。有两题从未被解出。

#### Argon 超时;Opus 读错。

当 Argon 给出一个数字时,它有 83% 的时候是对的,Opus 是 69%。但 Argon 超过四分之一的尝试撞上 30 分钟限制而没有答案。Opus 很快。它的解出里有一半用时不超过 5 分钟。

图 3:非常模糊的扫描把智能体分开。按任务标签、在全部三次尝试上的 pass@1(%);括号给出任务数,来源是一道题所依据的文档。

模糊扫描分开智能体

#### 非常模糊的扫描把智能体分开。

在清晰扫描上,Sol 解得最多。在 20 道非常模糊的题上,Opus 解出 60%,Argon 解出 50%,而其他每个智能体都在 37% 或以下,Sol 降到 25%(图 3)。Sol 和 Argon 在不同的题上成功,两者合起来至少解出一次的有 62 题,而单是 Opus 是 57 题。

#### 智能体在一道题上很一致,即使是错的时候。

一个智能体通常三次全解出一道题,或者一次都不解出。结果有混合的智能体–任务对,不到机会所预测的一半。错误答案也会重复。在 72 对里,智能体每次都给出同一个错误数字。

图 4:每次尝试的词元。每个智能体按种类计的平均词元,并标出总数以及按标价计的每次尝试智能体侧费用。

每次尝试的词元

#### 费用取决于缓存,而不取决于准确率。

GLM 是每次尝试最便宜的,而 GLM、DeepSeek、Sol 和 Opus 给出相对其费用最高的准确率(表 2)。Grok 最贵,每次尝试的费用是 DeepSeek 的 14 倍,解出的尝试却不到一半。费用跟着未缓存输入及其价格走:Argon、Gemini 3.8 Flash 和 Grok 送出许多未缓存词元,Kimi 为其缓存读取支付高费率,DeepSeek 几乎一切都从便宜的缓存里读取(图 4)。整场评测大约用了 395 个智能体小时,花费 3,218 美元。

6 分析

下面按工作方式、失败尝试和完整性来拆开这些结果。

6.1 智能体如何工作

表 3:来自智能体轨迹的工具使用。这些轨迹少计了 DeepSeek、Kimi 和 GLM 的调用,并省略了 Claude Code 的子智能体。每次尝试:平均调用次数和查看的页面图像数。Reducto:用 reducto:// 标识点名已上传卷册的读取所占份额(上传),第一次 parse_document 调用成功的尝试所占份额(首次读取),以及返回错误的调用所占份额。光学字符识别:在外壳里运行光学字符识别软件并返回了文本的尝试。

每次尝试Reducto(%)
智能体ShellReductoDropbox图像上传首次读取错误光学字符识别
Claude Opus 5.54.913.05.72.890.196.112.30
Gemini 4 Argon7.536.810.92.287.476.215.10
GPT-6.1 Sol6.625.011.50.087.397.17.52
Gemini 3.8 Flash42.219.016.116.898.874.86.72
Claude Sonnet 5.52.512.210.01.138.332.026.60
DeepSeek V4.1 Flash14.612.09.56.479.880.113.615
Kimi K314.318.411.04.895.736.514.759
GLM 5.3 Flash17.521.912.36.478.715.336.328
Grok 4.721.312.915.38.082.789.618.835
GPT-5.6 Terra7.715.79.90.053.320.623.83

把表中每次尝试的调用按行读出来。Claude Opus 五点五:外壳四点九次,Reducto 十三次,Dropbox 五点七次,图像二点八张,上传复用百分之九十点一,首次读取成功百分之九十六点一,错误百分之十二点三,外壳光学字符识别为零。Gemini 四点 Argon:外壳七点五,Reducto 三十六点八,Dropbox 十点九,图像二点二,上传百分之八十七点四,首次读取百分之七十六点二,错误百分之十五点一。GPT 六点一 Sol:外壳六点六,Reducto 二十五,Dropbox 十一点五,图像为零,上传百分之八十七点三,首次读取百分之九十七点一,错误百分之七点五,光学字符识别两次。Gemini 三点八 Flash:外壳四十二点二次,Reducto 十九,Dropbox 十六点一,图像十六点八,上传百分之九十八点八,首次读取百分之七十四点八。Claude Sonnet 五点五:外壳二点五,Reducto 十二点二,Dropbox 十,图像一点一,上传只有百分之三十八点三,首次读取百分之三十二,错误百分之二十六点六。DeepSeek:外壳十四点六,Reducto 十二,Dropbox 九点五,图像六点四,上传百分之七十九点八,首次读取百分之八十点一,光学字符识别十五次。Kimi:外壳十四点三,Reducto 十八点四,上传百分之九十五点七,首次读取只有百分之三十六点五,光学字符识别五十九次。GLM:外壳十七点五,Reducto 二十一点九,错误百分之三十六点三,首次读取只有百分之十五点三,光学字符识别二十八次。Grok:外壳二十一点三,Dropbox 十五点三,图像八张,光学字符识别三十五次。GPT 五点六 Terra:外壳七点七,Reducto 十五点七,图像为零,上传百分之五十三点三,首次读取百分之二十点六,错误百分之二十三点八。

#### 智能体很快找到文件,但交给 Reducto 的方式不同。

每个智能体通常都在一分钟内按文件名找到卷册并交给阅读器。Opus、Argon、Sol 和 Gemini 3.8 Flash 把每份卷册向 Reducto 上传一次并复用;Sonnet 和 Terra 常常改为传递下载链接,并得到许多 Reducto 错误。GLM 的错误最多,成功的首次读取最少(表 3)。

#### 答得快只对 Opus 有效。

Opus、Sonnet、Terra 和 Grok 常常在 3 分钟内作答,但只有 Opus 这样做时通常是对的(56 次尝试中的 40 次);Sonnet、Terra 和 Grok 在它们自己的这类尝试里最多 40% 是对的。Argon 从没有那么快作答。

#### 在同一个脚手架里,由模型决定。

同一脚手架里的模型相差很大:Claude Code 里差 23 个百分点,Codex 里差 35 个百分点。Opus 在 90% 的读取里复用已上传的卷册,Sonnet 是 38%。Gemini 3.8 Flash 在其大多数尝试里查看页面图像,Argon 不到三分之一,两个 Codex 智能体都从不这样做。只有 Claude Code 会启动子智能体,它有 16 次尝试以仍在工作的说明结束,而这是说明所禁止的。

#### 看页面的帮助比看上去要小。

查看过页面图像的尝试被解出得更频繁(42% 对 29%),但在运行 5 分钟或更久的尝试里,差距缩小并且不再显著。Gemini 3.8 Flash 几乎在所有非常模糊的尝试里都看了页面,可它在那里给出的答案仍有一半以上读错。

#### 智能体相信印出的数字,胜过合计。

在印出数字是错的那 7 题上,智能体解出 24% 的尝试,其他地方是 41%,而且那里的多数失败报告的是印出的数字。在 30 条失败回复里,智能体自己的核对已经指向正确答案,它仍然报告印出的数字。Opus 有一次写下了正确的合计,然后回答:“我的答案采用印出的数字。”

6.2 失败的尝试

图 5:读错数字是十个智能体里七个的最常见失败。条形按首要原因拆分每个智能体的失败尝试($n$;共计 1,269);占 10% 或以上的区段标出标签。

失败原因

#### 多数失败是错误数字,常常只差一位。

大约四分之三的失败尝试给出一个错误数字,其余大多什么数字都不给。错误数字里超过四分之一与答案键只差一位。一个模型智能体给每次失败指定一个原因,独立复查在一个样本的 93% 上一致(附录 F)。读错数字是最常见的原因,占失败的 36%,并且在十个智能体的七个上领先(图 5)。它影响清晰扫描上 7% 的答案,以及非常模糊扫描上 56% 的答案,最常见的是 8 与 6 或 9 混淆。接下来是超时,以及报告一个与合计矛盾的印出数字。

#### 智能体犯同样的错。

大多数错误数字(62%)也被另一个智能体给出过。有 20 题上最常见的答案是错的,所以多数表决最多能解出 50 题,而至少有一次尝试解出的是 68 题。这些常见错误大多不在我们的列表上:由四个或更多智能体给出的 38 个错误数字里,29 个不在该任务的已知错误答案之中。303 个已知错误答案里,只有 20 个曾经被给出。

#### Grok 不读就答。

Grok 在 36 次尝试里还没读任何一页就给出了数字,常常是在一次失败的上传之后,这些答案大多差得很远。在它大约一半的失败里,回复中的数字没有出现在它读过的任何东西里。一条回复引用一个不存在的文件;另一条回答 1234.56。

6.3 完整性

遵循智能体基准清单 [26](附录 H),我们检查智能体能否不做任务就得分。智能体的外壳可以到达网页,13 次通过的尝试从另一份卷册副本、一部法规或基准自己的材料里取了数字。这些计为失败,限制智能体能到达的网站就可以防止它们。Grok 有 4 次解出里,数字没有出现在任何工具输出中;它们仍然计分,因为评分器只检查数字。没有任何智能体改过档案文件。

7 局限

局限分成任务与答案键、评分与设置、规模与暴露三个方面。

#### 任务与答案键。

这些任务不是问题的随机样本:每一题都建在页面合计能够确认的一个表单元格上,这偏向又淡又难读的数字,而且全部来自同一份英语档案,答案都是单个数字。答案键由模型智能体核对,主要是得分最高的 Claude Opus 5.5,而不是领域专家。Claude Sonnet 5.5 试做过草稿,它自己也是被评测的智能体之一。在它给出过已知错误答案的那些题上,智能体解出得更少。有一题允许第二种读法,我们的答案键把它标为错;接受它不会改变任何排名。

#### 评分与设置。

评分器只检查数字:与答案键相差 1.00 美元以内的美元答案即使分位读错也会通过,弃答和错误数字得分相同。一个分数衡量的是一个模型在一个脚手架里、通过一个托管阅读器 Reducto 来阅读,而 Reducto 的版本没有钉住。换一个脚手架可能改变分数及其次序 [10],换一个阅读器也一样。更长的时限可能帮助经常超时的 Argon 和 GLM,不过 Argon 自己的工作只在其 58 次超时里的 7 次里已经握有答案。

#### 规模与暴露。

有 70 题时,pass@1 区间很宽,达 14 到 21 个百分点。PDF 和 OfficeQA Pro v2 的问题对任何申请访问的人都可用 [5],前沿模型已经记住许多历史金融统计 [16]。没有任何文档印出的答案键限制了凭记忆作答,但并没有排除它,而智能体解出改编题和新题的频率大致相同。我们没有做人类基线。

8 结论

TreasuryQA Bench 要求智能体通过盘的 MCP 工具和一个托管光学字符识别阅读器,从财政部扫描记录里找到、读出并报告一个数字。领先的两个智能体 Claude Opus 5.5 和 Gemini 4 Argon 分别解出其尝试的 64.8% 和 60.0%:Argon 作答时通常是对的,但常常超时,而 Opus 答得快、读错更多。多数失败是错误数字,常常只差一位,而且即使自己的核对与之矛盾,智能体也倾向于报告印出的数字。因为脚本给每条回复评分,这些结果不依赖于一个模型的判断。

披露

作者在 Veris AI 工作,该公司建造了这里使用的 Dropbox 孪生环境。TreasuryQA Bench 与 Reducto 一起发布,每个智能体都使用了它的托管阅读器。

可复现性声明

每个智能体都是固定的模型标识、提供方、脚手架版本和推理力度(表 5),每次尝试都在孪生环境的一份新副本上运行相同的任务文本和智能体配置。说明在附录 A 按原文给出。Reducto 的托管服务不报告发布版本。它的 r-1 模型做了解析,全部调用落在 2026 年 10 月 3 日到 21 日之间。把每一条存下的回复再评一次,会重现全部 2,100 个判定,费用使用 2026 年 10 月的标价(附录 G)。说明(附录 A)以及三个带答案键的演算例(图 2、附录 B)都在本文中给出。

大语言模型使用声明

大语言模型智能体起草了任务、它们的答案键程序和已知错误答案,在扫描件上核对了每个答案键,并标注了失败原因(第 3.3 节与第 3.4 节)。作者复查了每一题、每一项发现和每一处编辑。作者使用大语言模型助手来编写分析脚本并编辑本文;脚本从评测记录算出每一个数字。

参考文献

  • [1] Anthropic。作者与年份:2024。题名译为:介绍模型上下文协议。Introducing the Model Context Protocol。https://www.anthropic.com/news/model-context-protocol,2024。发布于 2024-11-25。访问于 2026-10-12。出处、页码与年份均按原文著录。
  • [2] Victor Barres、Honghua Dong、Soham Ray、Xujie Si、Karthik Narasimhan。作者与年份:2026。题名译为:$\tau^{2}$-Bench:在双控制环境中评测对话智能体。$\tau^{2}$-Bench: Evaluating conversational agents in a dual-control environment。载于第 43 届国际机器学习会议(ICML)论文集,第 306 卷,第 6736–6782 页,2026。出处、页码与年份均按原文著录。
  • [3] Antoine Bigeard、Langston Nashold、Rayan Krishnan、Shirley Wu。作者与年份:2025。题名译为:金融智能体基准:在真实世界金融研究任务上评测大语言模型。Finance agent benchmark: Benchmarking LLMs on real-world financial research tasks。arXiv 预印本 arXiv:2508.00828,2025。出处、页码与年份均按原文著录。
  • [4] Zhiyu Chen、Wenhu Chen、Charese Smiley、Sameena Shah、Iana Borova、Dylan Langdon、Reema Moussa、Matt Beane、Ting-Hao Huang、Bryan Routledge、William Yang Wang。作者与年份:2021。题名译为:FinQA:金融数据上数值推理的一个数据集。FinQA: A dataset of numerical reasoning over financial data。载于 2021 年自然语言处理实证方法会议(EMNLP)论文集,第 3697–3711 页,2021。10.18653/v1/2021.emnlp-main.300。出处、页码与年份均按原文著录。
  • [5] Databricks。作者与年份:2026。题名译为:OfficeQA Pro v2:一个有依据的推理基准。OfficeQA Pro v2: A grounded reasoning benchmark。https://huggingface.co/datasets/databricks/officeqa-pro-v2,2026。Hugging Face 数据集;数据 CC BY-SA 4.0,代码 Apache 2.0;门控访问。访问于 2026-10-12。出处、页码与年份均按原文著录。
  • [6] Dropbox。作者与年份:2026。题名译为:如何连接 Dropbox 远程 MCP 服务器。How to connect the Dropbox remote MCP server。https://help.dropbox.com/integrations/connect-dropbox-mcp-server,2026。Dropbox 帮助中心,页面更新于 2026-09-30。访问于 2026-10-12。出处、页码与年份均按原文著录。
  • [7] Honglin Guo、Qi Zhang、Yu Zhang、Weijie Li、Rui Zheng、Zhikai Lei、Qiyuan Peng、Zhiheng Xi、Tao Gui、Qi Zhang。作者与年份:2026。题名译为:AGORA:面向智能体职场文档推理的档案依据基准。AGORA: An archive-grounded benchmark for agentic workplace document reasoning。arXiv 预印本 arXiv:2606.24526,2026。出处、页码与年份均按原文著录。
  • [8] Pranab Islam、Anand Kannappan、Douwe Kiela、Rebecca Qian、Nino Scherrer、Bertie Vidgen。作者与年份:2023。题名译为:FinanceBench:金融问答的一个新基准。FinanceBench: A new benchmark for financial question answering。arXiv 预印本 arXiv:2311.11944,2023。出处、页码与年份均按原文著录。
  • [9] Sayash Kapoor、Benedikt Stroebl、Peter Kirgis、Nitya Nadgir、Zachary S. Siegel 等。作者与年份:2026。题名译为:整体智能体排行榜:人工智能智能体评测所缺少的基础设施。Holistic agent leaderboard: The missing infrastructure for AI agent evaluation。载于学习表征国际会议(ICLR),2026。出处、页码与年份均按原文著录。
  • [10] Yixuan Li、Yiyun Zhou、Yao Long Teng、Fuchao Yang、Yanchen Deng、Zhiyi Lyu、Xuyu Dong、Feng Chen、Bo An。作者与年份:2026。题名译为:找到合适的搭配:智能体任务上的模型与脚手架交互。Finding the right fit: Model-harness interactions across agent tasks。arXiv 预印本 arXiv:2610.00917,2026。出处、页码与年份均按原文著录。
  • [11] Yubo Ma、Yuhang Zang、Liangyu Chen、Meiqi Chen、Yizhu Jiao、Xinze Li、Xinyuan Lu、Ziyu Liu、Yan Ma、Xiaoyi Dong、Pan Zhang、Liangming Pan、Yu-Gang Jiang、Jiaqi Wang、Yixin Cao、Aixin Sun。作者与年份:2024。题名译为:MMLongBench-Doc:用可视化评测长上下文文档理解。MMLongBench-Doc: Benchmarking long-context document understanding with visualizations。载于神经信息处理系统进展(数据集与基准轨道),第 37 卷,第 95963–96010 页,2024。出处、页码与年份均按原文著录。
  • [12] Minesh Mathew、Dimosthenis Karatzas、C. V. Jawahar。作者与年份:2021。题名译为:DocVQA:文档图像视觉问答数据集。DocVQA: A dataset for VQA on document images。载于 IEEE/CVF 冬季计算机视觉应用会议(WACV)论文集,第 2200–2209 页,2021。出处、页码与年份均按原文著录。
  • [13] Mike A. Merrill、Alexander G. Shaw、Nicholas Carlini、Boxuan Li、Harsh Raj 等。作者与年份:2026。题名译为:Terminal-Bench:在命令行界面的困难、真实任务上评测智能体。Terminal-Bench: Benchmarking agents on hard, realistic tasks in command line interfaces。载于学习表征国际会议(ICLR),2026。出处、页码与年份均按原文著录。
  • [14] Grégoire Mialon、Clémentine Fourrier、Craig Swift、Thomas Wolf、Yann LeCun、Thomas Scialom。作者与年份:2024。题名译为:GAIA:通用人工智能助手的一个基准。GAIA: a benchmark for general AI assistants。载于学习表征国际会议(ICLR),2024。出处、页码与年份均按原文著录。
  • [15] Evan Miller。作者与年份:2024。题名译为:给评测加上误差线:语言模型评测的一种统计做法。Adding error bars to evals: A statistical approach to language model evaluations。arXiv 预印本 arXiv:2411.00640,2024。出处、页码与年份均按原文著录。
  • [16] Krista Opsahl-Ong、Arnav Singhvi、Jasmine Collins、Ivan Zhou、Cindy Wang、Ashutosh Baheti、Owen Oertell、Jacob Portes、Sam Havens、Erich Elsen、Michael Bendersky、Matei Zaharia、Xing Chen。作者与年份:2026。题名译为:OfficeQA Pro:端到端有依据推理的企业基准。OfficeQA Pro: An enterprise benchmark for end-to-end grounded reasoning。arXiv 预印本 arXiv:2603.08655,2026。出处、页码与年份均按原文著录。
  • [17] Reducto。作者与年份:2026。题名译为:Reducto MCP 服务器。Reducto MCP server。https://docs.reducto.ai/mcp-server,2026。访问于 2026-10-12。出处、页码与年份均按原文著录。
  • [18] Tomasz Stanisławek、Filip Graliński、Anna Wróblewska、Dawid Lipiński、Agnieszka Kaliska、Paulina Rosalska、Bartosz Topolski、Przemysław Biecek。作者与年份:2021。题名译为:Kleister:涉及复杂版式长文档的关键信息抽取数据集。Kleister: Key information extraction datasets involving long documents with complex layouts。载于文档分析与识别 ICDAR 2021,计算机科学讲义,第 564–579 页,2021。10.1007/978-3-030-86549-8_36。出处、页码与年份均按原文著录。
  • [19] Jason Wei、Zhiqing Sun、Spencer Papay、Scott McKinney、Jeffrey Han、Isa Fulford、Hyung Won Chung、Alex Tachard Passos、William Fedus、Amelia Glaese。作者与年份:2025。题名译为:BrowseComp:浏览智能体的一个简单却困难的基准。BrowseComp: A simple yet challenging benchmark for browsing agents。arXiv 预印本 arXiv:2504.12516,2025。出处、页码与年份均按原文著录。
  • [20] Zijian Wu、Xiangyan Liu、Xinyuan Zhang、Lingjun Chen、Fanqing Meng 等。作者与年份:2026。题名译为:MCPMark:对真实而全面的 MCP 使用做压力测试的基准。MCPMark: A benchmark for stress-testing realistic and comprehensive MCP use。载于学习表征国际会议(ICLR),2026。出处、页码与年份均按原文著录。
  • [21] Frank F. Xu、Yufan Song、Boxuan Li、Yuxuan Tang、Kritanjali Jain 等。作者与年份:2025。题名译为:TheAgentCompany:在有后果的真实世界任务上评测大语言模型智能体。TheAgentCompany: Benchmarking LLM agents on consequential real world tasks。载于神经信息处理系统进展(数据集与基准轨道),2025。出处、页码与年份均按原文著录。
  • [22] Shunyu Yao、Noah Shinn、Pedram Razavi、Karthik Narasimhan。作者与年份:2025。题名译为:$\tau$-bench:真实世界领域中工具–智能体–用户交互的基准。$\tau$-bench: A benchmark for Tool-Agent-User interaction in real-world domains。载于学习表征国际会议(ICLR),2025。出处、页码与年份均按原文著录。
  • [23] Junyuan Zhang、Qintong Zhang、Bin Wang、Linke Ouyang、Zichen Wen、Ying Li、Ka-Ho Chow、Conghui He、Wentao Zhang。作者与年份:2025。题名译为:光学字符识别阻碍检索增强生成:评测光学字符识别的级联影响。OCR hinders RAG: Evaluating the cascading impact of OCR on retrieval-augmented generation。载于 IEEE/CVF 国际计算机视觉会议(ICCV)论文集,第 17443–17453 页,2025。10.1109/ICCV51701.2025.01620。出处、页码与年份均按原文著录。
  • [24] Lianmin Zheng、Wei-Lin Chiang、Ying Sheng、Siyuan Zhuang、Zhanghao Wu、Yonghao Zhuang、Zi Lin、Zhuohan Li、Dacheng Li、Eric P. Xing、Hao Zhang、Joseph E. Gonzalez、Ion Stoica。作者与年份:2023。题名译为:用 MT-Bench 和 Chatbot Arena 评判“以大语言模型为评判”。Judging LLM-as-a-judge with MT-Bench and Chatbot Arena。载于神经信息处理系统进展(数据集与基准轨道),第 36 卷,第 46595–46623 页,2023。出处、页码与年份均按原文著录。
  • [25] Fengbin Zhu、Wenqiang Lei、Fuli Feng、Chao Wang、Haozhou Zhang、Tat-Seng Chua。作者与年份:2022。题名译为:通过离散推理走向复杂文档理解。Towards complex document understanding by discrete reasoning。载于第 30 届 ACM 国际多媒体会议(ACM MM)论文集,第 4857–4866 页,2022。10.1145/3503161.3548422。出处、页码与年份均按原文著录。
  • [26] Yuxuan Zhu、Tengjun Jin、Yada Pruksachatkun、Andy K. Zhang、Shu Liu、Sasha Cui、Sayash Kapoor、Shayne Longpre、Kevin Meng、Rebecca Weiss、Fazl Barez、Rahul Gupta、Jwala Dhamala、Jacob Merizian、Mario Giulianelli、Harry Coppock、Cozmin Ududec、Antony Kellermann、Jasjeet S. Sekhon、Jacob Steinhardt、Sarah Schwettmann、Arvind Narayanan、Matei Zaharia、Ion Stoica、Percy Liang、Daniel Kang。作者与年份:2025。题名译为:建立严格智能体基准的最佳实践。Establishing best practices in building rigorous agentic benchmarks。载于神经信息处理系统进展(数据集与基准轨道),第 38 卷,2025。10.52202/085713-5547。出处、页码与年份均按原文著录。

附录 A 说明

共用说明按原文照录(1,402 个字符,十个智能体相同)。第二段的前两句来自 OfficeQA Pro [16]。下面是该说明的中译,文件名、工具名和最后一行的格式保持原文。

[说明] 你回答关于存放在公司 Dropbox 里的美国财政部历史文档语料的问题。文件是扫描 PDF;文件名带有文档族和年份,例如 combined_statement__historical__cs-1941.pdf、govinfo_receipts__1832__GOVPUB-….pdf、combined_statement__modern__2016__c07.pdf。用 Reducto 工具阅读扫描页。卷册长达 1,000 页,所以先定位正确的页,例如经由目录页或索引页,再按较小的页范围阅读。要用 parse_document 读一个页范围,请把 options 里的 settings.page_range 设为一个对象,其中放起始页码和结束页码,例如 start 为 43、end 为 47。你使用的每一个数字都要以文档里的内容为依据。

若多份文档报告同一指标,除非问题指定了确切日期或文档,否则使用最新的修订。不要依赖你遇到的第一个匹配值。除非问题另有说明,计算时使用最大精度,并按问题所要求的精度给出数值答案。若语料里没有答案,就这么说。每个问题只回复恰好一条完整消息:绝不要请用户等待,绝不要承诺稍后回报,也绝不要提议发送文档本身。写出你用过的文件名,然后用恰好如下形式的单独一行结束消息:

ANSWER: <final answer>

附录 B 演算例

除图 2 的任务外,另有两道任务作为公开演算例。

附录 C 构建与答案键

预言机优先的构建(第 3.3 节)开始于一次审计:七道 OfficeQA Pro 问题里有一道,其答案键是解析文本所达不到的。70 个预言机共有 11,339 行和 1,078 条断言。运行之后,十一条美元区间被收窄,这没有改变任何判定。

表 4 按问题要求智能体做什么,把 70 题分成七类。当问题要求同一年两项之差时,pass@1 最低,为 25.6%;当它要求百分比变化或超出时最高,为 63.3%。

表 4:按问题要求智能体做什么来分的任务。非常模糊和多文档是该类任务中的份额。70 题里有 60 题把印错或读错的数字列在已知错误答案里。陷阱列给出该类中最常见的另一类已知错误答案,并给出带有它的任务数;若没有别的种类达到该类的四分之一,则写印错或读错的数字。pass@1 是十个智能体在该类任务的全部尝试上的结果;最佳智能体是在这些题上 pass@1 最高的那个。

问题要求做什么任务数非常模糊多文档典型陷阱pass@1最佳智能体
读一个印出的数字743%0%相邻的行或合计(3)37.1%Opus(76.2%)
把一张表的若干行加总1040%0%印错或读错的数字(10)36.3%Argon(86.7%)
同一年两项之差1242%8%符号或方向(6)25.6%Argon(38.9%)
两个时期之间的变化1233%75%符号或方向(8)40.3%Opus(77.8%)
占合计的份额1323%8%错误基数(9)44.1%Opus(69.2%)
百分比变化或超出520%60%错误基数(2)63.3%Sonnet(86.7%)
多年上的统计或选取110%54%另一版本的数字(3)42.4%Sol(78.8%)
全部任务7029%29%39.6%

七类任务依次是:读一个印出的数字,七题,非常模糊占百分之四十三,没有多文档,典型陷阱是相邻的行或合计,一次通过率百分之三十七点一,最佳是 Opus。把一张表的若干行加总,十题,非常模糊百分之四十,陷阱是印错或读错,一次通过率百分之三十六点三,最佳是 Argon。同一年两项之差,十二题,一次通过率百分之二十五点六,为全表最低。两个时期之间的变化,十二题,多文档占百分之七十五,一次通过率百分之四十点三。占合计的份额,十三题,一次通过率百分之四十四点一。百分比变化或超出,五题,一次通过率百分之六十三点三,为全表最高。多年上的统计或选取,十一题,没有非常模糊的扫描,一次通过率百分之四十二点四。全部七十题里非常模糊和多文档各占百分之二十九,总一次通过率百分之三十九点六。

#### 答案键如何计算。

每个预言机以全精度工作,把美元金额按精确的分来求和,并只在末尾按问题所要求的精度舍入一次。查找也从表的合计重新计算,若一个序列在后来的卷册里重印,预言机就读取其来源中的每一次印本。只有当问题有第二种合理读法时才接受第二个区间,而一个通不过自己那张表所印合计的数字从不被接受。

附录 D 环境

表 5:智能体。每个智能体都是一个模型,通过所示提供方、用所示标识调用,放在钉住一个版本的命令行脚手架里;力度是通过脚手架设置的推理力度。Codex 在容器内关闭它自己的沙箱运行。

智能体模型标识脚手架提供方力度
Claude Opus 5.5us.anthropic.claude-opus-5-5Claude Code 2.1.284Amazon Bedrockhigh
Claude Sonnet 5.5us.anthropic.claude-sonnet-5-5Claude Code 2.1.284Amazon Bedrockhigh
GPT-6.1 Solopenai.gpt-6.1-solCodex 0.153.3Amazon Bedrockhigh
GPT-5.6 Terraopenai.gpt-5.6-terraCodex 0.153.3Amazon Bedrockhigh
Gemini 3.8 Flashgemini-3.8-flashGemini CLI 0.61.0Gemini APIhigh
Gemini 4 Argongemini-4-argonGemini CLI 0.61.0Gemini APIhigh
Grok 4.7global.xai.grok-4.7Grok CLI 1.0.46Amazon Bedrockhigh
DeepSeek V4.1 Flashdeepseek-ai/DeepSeek-V4.1-FlashPi 0.99.2Basetenhigh
GLM 5.3 Flashaccounts/fireworks/models/glm-5p3-flashPi 0.99.2Fireworkshigh
Kimi K3moonshotai/Kimi-K3Pi 0.99.2Basetenhigh

十个智能体的标识、脚手架、提供方和力度都钉在上表。Claude Opus 五点五与 Claude Sonnet 五点五走 Claude Code 二点一二八四,提供方是 Amazon Bedrock,力度为高。GPT 六点一 Sol 与 GPT 五点六 Terra 走 Codex 零点一五三三,同样是 Amazon Bedrock,力度为高。Gemini 三点八 Flash 与 Gemini 四点 Argon 走 Gemini CLI 零点六一零,提供方是 Gemini API。Grok 四点七走 Grok CLI 一点零四六,提供方是 Amazon Bedrock。DeepSeek V 四点一 Flash 与 Kimi K 三走 Pi 零点九九二,提供方是 Baseten。GLM 五点三 Flash 也走同一版 Pi,提供方是 Fireworks。推理力度一列全部为高。

#### 档案与容器。

1,435 个文件共有 118,524 页(13.3 GB):1,321 份合并报表(1872–2024)和 114 份更早的报告(1793–1893),最长 1,016 页。其中 1,256 份以 150 像素每英寸扫描,102 份以 100–120,77 份以 60–80;582 份超过 get_file_content 的 5 MB 限制。download_link 给出的链接持续 1 到 15 分钟,并且按 Dropbox 的工具说明只可使用一次。每次尝试在一个无特权的 Debian 12 容器里运行,配 2 个 CPU 和 4 GiB,提供 Python、poppler、ripgrep、curl 和 jq。脚手架在 30 分钟限制之前一分钟停止命令行界面,以便其回复仍被记录。Reducto 用它的 r-1 模型解析,它的七个工具可用。

#### 构建与统计。

候选搜索扫过 OfficeQA Pro v2 解析文本中的 206,820 张表,编目了 201 个由其表合计确认的单元格,并把 90 道 OfficeQA Pro v2 问题中的 36 道系到这样的单元格上。撰写智能体收到 110 个候选(90 个编目单元格和 20 道 OfficeQA Pro v2 问题),丢掉 40 个。这些任务依据 55 份卷册,中位页数 594。自助区间在任务上做 4,000 次百分位重抽样,并把每题的三次尝试保持在一起;Holm 校正覆盖排名中相邻者之间的九次比较。

Reducto 有两条工具说明会误导:parse_document 提供一个智能体选项,服务器只在带有提示时才接受(1,317 次被拒的调用);upload_file 说它接受本地路径,而托管服务器读不了本地路径(411 次被拒的调用,其中 225 次是 Grok 的,123 次是 GLM 的)。

附录 E 评分器

#### 抽取规则。

评分器去掉 Markdown 和 LaTeX 包装,把 Unicode 减号、贴在数字或货币符号上的破折号,以及会计括号读作负数,并且从不用单位词重缩放一个数字。它使用最后一行以 ANSWER 或 Final answer 开头的行,不区分大小写。在这一行上,它丢掉属于文件名的数字,丢掉跟在 page、table 或 line 之类词后面的数字,也丢掉跟在 fiscal year 或 June 30 之类词后面的年份,并取剩下的第一个数字;若该行声明了一处更正(“should be”、“instead”、一个箭头),则取最后一个。数字之前的弃答措辞(“not available”、“cannot be determined”)使回复成为弃答。若没有答案行,它取最后一笔金额:带货币符号、小数点、千分位分隔符或百分号、且不是年份的数字。若最终回复没有存下,它从轨迹里读取智能体的最后一条消息。

附录 F 失败原因

一个模型智能体根据完整记录给每次失败尝试指定一个首要原因(第 6.2 节)。数字:从图或从 Reducto 的文本里读错一个数字,并且没有核对。保留:尽管表自己的合计指向答案键,仍按印出的样子报告一个数字。来源:错误的卷册、数字后来被重述过的较早版本,或档案之外的数字。行:表对了,但行、列或时期错了。方法:输入对了,但计算或定义错了。无依据:回复中的数字没有出现在这次尝试的任何工具输出里。放弃:智能体拒绝,或说语料缺少数据。时间:时限结束了这次尝试,没有提交数字。结束:尝试更早结束,没有提交数字。

附录 G 费用与力度

表 6 给出每个智能体的时间、词元和总费用。每百万词元的输入、缓存读取、缓存写入和输出价格是标准文本词元标价,短上下文、五分钟缓存写入:Opus 为 4、0.20、5、20 美元;Sonnet 为 2、0.20、2.50、10 美元;Sol 为 2、0.10、2.50、10 美元;Terra 为 2、0.20、2.50、12 美元;Gemini 3.8 Flash 为 0.75、0.075、0.75、3.75 美元;Argon 为 2、0.10、无、10 美元;Grok 为 2、0.50、2、6 美元;DeepSeek 为 0.30、0.007、0.30、1.20 美元;Kimi 为 3、0.30、3、15 美元;GLM 为 0.15、0.03、0.15、0.50 美元,取自 10 月 18 日的价目,因为其余智能体所用价目没有 GLM 的价格。不施加区域端点加价和长上下文附加费。一次 Kimi 尝试没有记录词元或费用;它在合计和均值里计为零。

表 6:每个智能体的费用与词元。小时:智能体总时间;词元和平均费用按每次尝试,未缓存输入、缓存读取和缓存写入构成输入,推理计在输出之内;费用是按标价的智能体侧费用;全部给出全部尝试上的均值。

输入输出(千)费用(美元)
智能体小时未缓存(千)缓存读取(百万)缓存写入(百万)全部推理均值合计
Claude Opus 5.524.93.02.310.1516.15.11.56327.91
Gemini 4 Argon64.7910.63.320.0034.424.32.45514.01
GPT-6.1 Sol44.44.12.690.116.02.00.62129.51
Gemini 3.8 Flash42.5867.712.570.0046.633.21.74366.11
Claude Sonnet 5.517.50.12.810.1817.15.41.19250.51
DeepSeek V4.1 Flash45.6124.913.610.00100.888.70.2553.28
Kimi K339.1267.95.000.0016.47.92.55535.25
GLM 5.3 Flash53.9233.26.300.0026.119.70.2449.77
Grok 4.741.7970.52.920.0023.915.73.55744.79
GPT-5.6 Terra21.111.13.190.178.04.71.17246.57
全部395.4339.35.470.0629.520.71.533,217.71

上表逐行读作:Claude Opus 五点五用二十四点九小时,未缓存输入三千词元量级,缓存读取二百三十一万,缓存写入十五万,输出一万六千一百,其中推理五千一百,平均每次一点五六美元,合计三百二十七点九一美元。Gemini 四点 Argon 用六十四点七小时,未缓存输入很大,缓存读取三百三十二万,输出三万四千四百,推理二万四千三百,平均二点四五美元,合计五百一十四点零一美元。GPT 六点一 Sol 用四十四点四小时,平均零点六二美元,合计一百二十九点五一美元。Gemini 三点八 Flash 用四十二点五小时,缓存读取一千二百五十七万,输出四万六千六百,平均一点七四美元,合计三百六十六点一一美元。Claude Sonnet 五点五用十七点五小时,平均一点一九美元,合计二百五十点五一美元。DeepSeek V 四点一 Flash 用四十五点六小时,输出十万八百,推理八万八千七百,平均零点二五美元,合计五十三点二八美元。Kimi K 三用三十九点一小时,平均二点五五美元,合计五百三十五点二五美元。GLM 五点三 Flash 用五十三点九小时,平均零点二四美元,合计四十九点七七美元。Grok 四点七用四十一点七小时,平均三点五五美元,合计七百四十四点七九美元。GPT 五点六 Terra 用二十一点一小时,平均一点一七美元,合计二百四十六点五七美元。全部尝试合计三百九十五点四小时,平均每次一点五三美元,总计三千二百一十七点七一美元。

附录 H 智能体基准清单

TreasuryQA Bench 对照智能体基准清单 [26];在结果有效性条目里,适用于答案匹配的那些(外加 O.b.2)适用。状态:是、部分或否。

条目要求状态证据或缺口
T.1–2工具版本;API 工具可访问部分写明了命令行版本、模型标识和图像;Reducto(r-1)是托管的,没有钉住。
T.3–4处理 API 失败;清空状态是30 分钟限制;每次尝试都评分;新的孪生环境和容器。
T.5与地面真值隔离部分答案键从不在容器里;外部来源的通过计为失败。
T.6设置随时间冻结否Reducto 是在线的;其工具列表在运行中变过。
T.7–8地面真值已核验;可解是预言机算出的答案键,在扫描件上确认;68 题被解出。
T.9–10预言机求解器;没有捷径部分预言机程序,不是智能体;67 题检查过是否印出答案。
O.h.1–2规定格式;尽量减少猜测是最后的 ANSWER: 行;44 个美元区间中的 40 个满足 $\leq\pm$$1.00$。
O.b.2罗列答案会失败是只有答案行上的第一个数字算数。
O.c.1大语言模型评判已验证不适用没有评判来评分;比较在第 3.5 节。
R.1–2开放数据与脚手架部分说明和三个例子在本文中。
R.3–5污染;更新;维护部分答案键不公开,扫描件公开。
R.6–10构念;对象;缺陷;影响是第 1、4、3.4 与 7 节。
R.11–12显著性;解释是自助区间、Holm 校正的检验;第 7 节。
R.13–14非人工智能基线;平凡智能体否;部分没有人类基线;没有数字或已知错误答案即失败。

Found it useful? Pass it on

WeChat

Scan with WeChat to open it on your phone and forward it.

Subscribe via RSS

Submit a correction