LlamaIndex 甩出一个企业文档提取 Benchmark，结果自家的方案排第一

手里有 370 份企业文档——合同、发票、报表、保险单、采购单——要批量抽出关键字段做成结构化数据，怎么选方案？

这问题过去基本靠"感觉"判断：用 GPT-4o 直接提好像还行，但长文档偶尔吞记录；写一段 Python 调 API 做 CoT 抽取，精度上去了，成本也跟着起飞。哪个方案性价比最高，没人能给一个带分数的答案。

LlamaIndex 团队今天放出了一个新 Benchmark，名叫 ExtractBench。论文挂在 arXiv 上，数据集和评估代码同步开源在 HuggingFace 和 GitHub。

设计思路

ExtractBench 测的是 Schema-Guided Extraction——给定文档和用户定义的 Schema（比如"提取所有发票号、金额、日期、供应商"），模型要严格按 Schema 输出，每条输出要附原文证据，不能凭空编。

评估集 4869 页，370 份企业文档，覆盖 8 个业务领域、67 种文档类型。每份文档都打了难度标签——有些是单页表单，有些是几十页的多记录报表。论文用三条生产线构建 Ground Truth：真实文档靠多个独立系统交叉验证，合成列表直接拿已知值做底，表单类文档有人工核验兜底。

评估维度也比一般 QA 测试更落地。不只盯值对不对（Order-insensitive Value F1），还看召回够不够全、有没有漏记录（Record Completeness），以及每条提取结果能不能追溯到原文的哪个词、哪一页（Word-level 和 Page-level Grounding F1）。加上成本折算，四个维度一起打分。

结果

商用 VLM（视觉语言模型）在短文档上表现不错，但文档一长，记录列表就开始被截断。精度本身没问题——模型上下文窗口和注意力机制撑不住几十页的细粒度抽取。从 50 页采购合同抽出全部条目，它可能只给前 20 条，后 30 条直接丢了，也不报错。

Coding Agent——让模型写代码循环遍历文档做抽取——精度确实高，但代价也高得多。跑完一份长文档，API 账单能比直接调 VLM 贵好几倍。

LlamaIndex 自己的产品 LlamaExtract Agentic Plus 在这三个评估指标上都排第一。论文原话是"accuracy comparable to coding agents at a fraction of the cost"——精度对标 Coding Agent，成本只有几分之一。

结果出自 LlamaIndex 团队自己的论文，打分对象包括他们自己的产品。论文公开，数据和代码也开源，谁都可以去验证。但这不妨碍 ExtractBench 作为一个有用的工具——过去企业做文档抽取选型基本靠经验和拍脑袋，现在至少有了一个带标尺的测试集。

对开发者的价值

正在做企业文档处理类产品的团队，可以直接拿这套 Benchmark 去做方案对比。8 个领域、67 种文档类型，基本覆盖了常见业务文档形态。跑一遍就知道选定的模型在具体文档类型上精度如何、成本多少、会不会吞记录。

场景是几十页的大表、长合同、多记录清单的，这条信息更直接：纯 VLM 方案大概率会在长尾记录上翻车，不加代码层做分页循环或 Agent 编排，很难拿到完整结果。

数据在这里：HuggingFace | GitHub

论文里说了一句大实话：Enterprise workflows increasingly rely on agents for schema-guided extraction。企业流程正在往 Agent 迁移，但迁移之后的提取结果到底靠不靠谱，过去没人系统地给过答案。ExtractBench 算是第一个正经的尝试。

一个 Benchmark 不能代表所有业务场景。文档长什么样、Schema 定义多复杂、容错容忍度多大，最终还得结合自己的数据跑一遍。但至少不用再盲猜了。