ExtractBench:长文档提取精度跌至28%?首个多维企业级评测基准拆解
ExtractBench: A Benchmark for Schema-Guided Enterprise Document Extraction
在企业级大模型应用落地中,自动化文档处理(IDP)一直被视为投资回报率最高的场景之一。金融分析师需要从长达百页的财报中抓取基金持仓明细,核保人员需要从格式各异的医疗单据中录入理赔条目,政企采购则要在扫描件与手写表格间反复核对采购清单。
ArXiv URL:https://arxiv.org/abs/2607.29677
以往的做法依赖人工录入或规则死板的传统 OCR 模板匹配。随着多模态大模型(VLM)与自主 Agent 的爆发,行业迅速转向了“基于 Schema 的按需抽取”(Schema-Guided Extraction):用户仅需给出一份标准 JSON Schema,定义期望提取的字段、嵌套对象及逻辑约束,系统便应自动从非结构化或半结构化文档中抽取出对应实体,并附带可审计的原始位置信息。
然而,实验室里的演示 demo 往往与企业真实工况相差甚远。当大模型遇到动辄上千行的连续对账单、手写笔迹模糊的报税单、以及跨页断裂的复杂嵌套表格时,幻觉、截断与字段错位频频发生。更棘手的是,市面上现有的文档抽取基准(如 SROIE、DocILE 等)大多停留在固定的单一模板匹配上,既无法评测任意用户定义的 Schema,也未将可追溯性(Grounding)与工业级部署的核心生命线——单页提取成本(Cost per Page)纳入考量。
来自 RunLLama 的团队正式推出了 ExtractBench。这是业内首个将数值准确度、大规模长记录完整性、像素级溯源能力与真实落地成本放在统一天平上衡量的企业级基准。该基准覆盖 8 大核心业务领域、67 种文档类型与 4,869 页真实或高度拟真的测试集,对包含主流商业 VLM、开源解析管线、Coding Agent 及专用 API 在内的 14 款代表性系统进行了全面摸底。测试揭示出一个残酷的工程现实:主流前端大模型在长文档抽取场景下召回率极易断崖式下跌,而高精度的代码 Agent 方案其调用成本又足以击垮大多数业务的 ROI 底线。
拆解企业级抽取的五重困境
为了彻底切除传统评测只看“综合总分”带来的虚假繁荣,ExtractBench 将文档抽取的难点拆解为五个完全解耦的正交维度。这种标签化分类让每一次抽取失败都能精准追溯到具体机制,而不是含糊地归咎为“模型能力不够”。
第一个维度是任务挑战(Task Challenge)。这里的困难源于数据本身的语义密度与分布形态。例如“稀疏实体抽取”(如在百页合同中寻找某一条违约赔偿条款)、“超长列表完整性”(成百上千行的资产配置表),以及让大模型最容易犯错的“高密表单抽取”。在高密表单场景中,页面往往布满了密密麻麻的标签、待填空白、复选框和扫描瑕疵,伴随着海量格式相同的日期、金额与编号。系统在此类任务中的典型死法是“过度抽取”(Over-extraction)——为一个明明为空的字段生搬硬造一个看似合理的值,或是将两个临近单元格的数据张冠李戴。针对超大复合税表,基准还专门设立了叶子节点超过 150 个的超大 Schema 子集,专门考察模型对极端上下文和复杂层级约束的服从能力。
第二个维度是感知挑战(Perception Challenge)。企业业务接收到的文件往往不受自身控制,因此 ExtractBench 明确划分了数字原生文档(Born-digital)、扫描件噪点、物理翻折旋转以及真实手写笔迹。一个能在干净矢量 PDF 上发挥完美的解析器,在遇到手写体和复印噪点时,其底层表征往往会瞬间崩解。
第三个维度是针对表格结构(Table Structure)设立的独立坐标。表格是企业文档中高价值密度的核心载体,但也是解析逻辑最易受挫的结构:
-
多级嵌套与合并表头:极易导致列对齐错位,将数据挂载到错误的父级属性下;
-
转置与侧边表头:打破了大模型从左到右、从上到下的阅读惯性,引发整条记录的转置混乱;
-
跨页连续表格:在分页断点处,大模型经常丢失表头上下文,甚至误判表格已经结束;
-
单单元格内嵌套微型表:文本被压缩为单一字符串,结构完全被抹平;
-
千行级超长表:单表跨越数十页,严酷考验系统的长窗口一致性。
第四与第五个维度分别是文档长度(分为 10 页以下的短文档、11-50 页的中长文档,以及 50 页以上的长文档)与业务领域。评测覆盖了对冲基金持仓、能源监管、政府采购、医疗理赔凭单、破产法律清算以及不动产交割声明等 8 个极度依赖人工审核的典型垂直领域,拒绝用单一场景的过拟合替代通用抽取能力。
兼顾规模与精确度的三轨数据工程
为如此海量且复杂的企业文档构建无争议的标注基准(Ground Truth),是过去该领域难以推进的最大瓶颈。如果人工一张张画框填值,4,800 多页的成本难以承受且人工极易漏看;如果完全依赖纯人工生成,则无法涵盖企业真实版式的长尾缺陷。ExtractBench 设计了一套三轨并行的严苛工程化标注管线。

针对真实商业文档(如 SEC 13F 文件、市政水电账单),团队引入多模型集成一致性裁决机制。首先根据样本起草初始 Schema,再让来自不同模型家族的多个高阶抽取系统独立执行。唯有所有独立系统给出完全一致的抽取值(包括对缺失字段给出空值 null),该结果才会被作为候选基准。对于任何出现分歧的字段,系统会做二分类归因:若多方解读皆能自圆其说,说明 Schema 定义存在歧义,人工便进一步细化字段描述、补充别名约束与反例警告,直到重新运行收敛;若确认属于模型理解错误,则由专业审核员对照原图进行最终裁定。
针对动辄包含数千条记录的超长列表文档,团队采用了一种“逆向生成”的打法——先定数据,后出文档。首先提炼真实基金持仓或债权人名册的统计规律,由代码 Agent 深入学习目标版式的字体、边距、列宽与页眉页脚特征,编写自动化渲染代码。因为每一条记录的数值、所在页码乃至单词级别的外接矩形框(Bounding Box)在 PDF 渲染成型之前就已经是确定已知的结构化数据,这使得超长合成文档天生具备 100% 准确、无需人工画框的绝对基准真值。渲染出来的文档还会通过物理断行测量防溢出,并经由抽取模型池反复交叉审计,排除排版引擎的代码缺陷。
针对争议最大的真实扫描与手写表单,则完全由人工介入兜底。在固化的空白模板上定义好 Schema 后,由集成系统先行打分,争议项交由仲裁 Agent 初审,最后由专职人工标注员在自建的标注界面中对每个字段的外接框进行逐一确认、微调、删除或重新框选。在这部分涵盖 169 份文档的精标集合中,84% 的验证字段拥有精确的人工定位框,其余则精确标记为空值。
这种三轨组合不仅保证了字段语义的确定性,更让后续的自动化客观评测有了极高的置信度。
告别自欺欺人:如何科学衡量抽取系统?
在指标设计上,ExtractBench 纠正了以往研究中的两大误区:一是直接借用文本生成的 BLEU/ROUGE 等模糊匹配指标,二是忽视了企业级审核必不可少的溯源与运营成本。
首先是统一值级 F1 指标(Unified Value F1)。由于抽取出的 JSON 可能包含数组乱序,简单的字典匹配会带来巨大偏差。ExtractBench 将系统输出与标准答案展平为一个个独立的叶子单元格。对于标量字段与对齐后的记录子字段,统一按归一化后的字符串计算精确匹配度。
在处理缺失值时,规则极其冷酷:输出中漏掉某个字段,直接等同于输出了显式的 null。这意味着在有内容的字段上漏提会受到 Recall 惩罚,而在原本为空的字段上盲目填入幻觉内容会直接遭遇 Precision 惩罚。系统只有在“该提取的地方正确提取,该留空的地方正确识别为空”时,才能获得满分。数组记录之间的匹配使用匈牙利算法做全局最优对齐,任何多提或漏提行记录的动作都会在 F1 上被如实放大。
其次是可解释性与溯源评测(Grounding)。在真实业务流中,没有系统能承诺 100% 准确率,因此人类专家复核(Human-in-the-loop)是必经环节。如果系统不能精准圈出答案在第几页、哪几个单词周围,人工审计的成本甚至会超过全量手工录入。ExtractBench 设立了两个溯源层级:
-
Word-Level Grounding F1:要求提取出的值必须正确,且预测的文字外接框与人工标注框的交并比($\text{IoU}$)必须 $\ge 0.5$。框选精准但内容提取错误,得零分;内容提取正确但没有框或框偏移,同样不得分。
-
Page-Level Grounding F1:相对宽容的准则,仅要求值正确且命中了对应页码。
最后是实测单页成本(Cost per Page)。工业落地不是跑跑实验室榜单。当企业日处理量突破百万页时,单页成本哪怕仅相差 1 美分($0.01),年化运营成本差额就高达 10,000 美元。ExtractBench 将测试集在各商业 API 上实际消耗的 Token 与积分换算为单页法币成本,直观绘制出抽取质量与成本之间的真实帕累托前沿(Pareto Frontier)。
14 款系统横评:VLM 幻觉断崖与成本鸿沟
在对 14 款代表性系统(覆盖通用商业 VLM、开源本地模型、Coding Agent 与专用抽取云服务)的评测中,多项突破直觉的现象浮出水面。
长文档下的“召回率坍塌”
在 10 页以下的常规短文档中,多模态模型的表现堪称惊艳,大部分主流商业模型在短文本上的 Value F1 都能轻松突破 85% 甚至 90%。然而,一旦将文档长度拉升至 50 页以上,性能曲线发生了剧烈分化。
最为典型的是 Gemini 3.5 Flash。在短文档上它拿下了 87.9% 的优秀成绩,但在长文档切片中,其综合准确度暴跌至 27.9%。深入拆解混淆矩阵后发现,精度(Precision)依然维持在较高水准,发生雪崩的是召回率(Recall)。商业 VLM 在面对包含海量信息的超长上下文时,由于上下文衰减以及缺乏细粒度的遍历状态追踪,往往在读完前几页后便提前终止抽取,将后续数十页的表格整段整段地遗漏,导致长列表记录惨遭截断。
相比之下,具备自主规划、代码编写与分页处理能力的 Coding Agent(如 Claude Code Opus 4.8 取得 88.1% F1)以及专门针对长文档做了针对性分片与聚合管线的专用服务(如 Reducto Deep Extract 取得 92.0%,LlamaExtract Agentic Plus 取得 94.4%),在面对超长文档时几乎没有出现断崖式性能衰退,展现了极强的长程稳定性。
Coding Agent 的性价比死穴
既然具备编写 Python 脚本、调用 OCR 工具并执行自检循环的 Coding Agent 准确度如此之高,那它们是企业的最终答案吗?成本测试给出了否定回答。
测试显示,基于 Codex GPT-5.5 的 Coding Agent 虽然拿下了 93.6% 的高准确率,在应对超 150 字段的密集表单时甚至飙出了 95.4% 的高分,但其单页处理成本高达惊人的 27.8 美分/页;Claude Code Opus 方案的单页成本也达到了 16.2 美分/页。背后的原因在于,Coding Agent 在面对复杂页面时,往往需要经历“观察-编写脚本-运行报错-反思纠错-多次交互重试”的超长思考路径,每一页文档都会成倍吞噬推理 Token。对于需要吞吐成百上千万页商业单据的企业而言,这种方案在经济性上几乎无法成立。
与之形成鲜明对比的是专为结构化抽取设计的专用 Agent 流水线。例如 LlamaExtract Agentic Plus 在测试中取得了全局第一的成绩(95.6% 全局 Value F1),在短文档、中长文档和长文档上分别斩获 96.6%、93.3% 和 94.4% 的极稳输出,同时其单页成本仅为 8.1 美分/页,不足顶级 Coding Agent 的三分之一。
此外,更轻量级的专用方案(如 LlamaExtract Cost-Effective)能够在 1.0 美分/页 的超低成本区间实现 86.8% 的 F1 分数,甚至优于大部分调用成本在同一区间、但未做专门架构设计的普通 VLM 裸调方案。这充分印证了:在复杂文档工程中,无脑堆砌通用大模型的算力不仅极度昂贵,效果也常常被有针对性编排的专用 Agent 架构降维打击。
溯源(Grounding)的巨大鸿沟
在审计与溯源能力上,系统的断层更为夸张。所有开箱即用的通用商业多模态大模型和绝大多数 Coding Agent,在默认配置下只能输出提取出的键值对或 Markdown 文本,完全不具备输出 Word 级别边界框的能力。
在 ExtractBench 的 Word-level Grounding 评测中,绝大多数通用方案得分直接挂零。唯有提供了细粒度边界框选项的专业抽取引擎(如开启了 Granular Bounding-box 的 LlamaExtract 与专用版式解析管线)能够稳定输出 IoU $\ge 0.5$ 的精确定位元数据。对于受监管严格的金融和法律场景,这道鸿沟直接决定了系统究竟是一个可投产的生产级基础设施,还是一个只能用于草稿生成的演示玩具。
从 ExtractBench 看企业文档智能的破局路线
ExtractBench 的实测数据为大模型在文档智能化处理的下一程落地指明了极具价值的工程方向:
首先,“单次上下文全吞”(Single-pass In-context)的范式在企业长文档处理中已经基本被判死刑。长达数十页的表格与密集表单,其信息熵远超通用多模态模型的单轮注意力机制承载上限。盲目扩大模型的上下文窗口,并不能解决模型中途疲劳截断和注意力漂移的内在缺陷。未来的赢家方案必然依赖于某种形式的分层解析架构:通过外挂的布局感知模块对文档进行语义切片,再通过轻量有状态的调度 Agent 进行跨页延续与状态核对。
其次,可审计性必须作为第一等公民内嵌至抽取架构中。大模型的幻觉本质决定了它绝不可能在工业级工况中做到绝对的零失误。当错误不可避免时,快速人工仲裁就成了系统最后的防线。不能输出像素级文字定位的抽取系统,在企业端正在迅速失去采购吸引力。
最后,追求 Pareto 最优的工程编排远比盲目调用“最贵、最大”的模型更具商业价值。在 ExtractBench 的前沿曲线上,我们清晰地看到,通过将 OCR 锚定、规则校验与专用 Agent 状态机结合,专有方案完全可以用三分之一的推理成本换取比顶级通用模型更卓越的精度与长程鲁棒性。大模型时代的企业文档提取,下半场的竞争已经不再局限于谁的模型参数量更大,而是谁能在精度、溯源与运营成本的三角博弈中,构建出最契合企业现实 ROI 的工程架构。