企业文档抽取最容易被演示视频骗过。给模型一张发票，它抽出金额、日期、供应商，看起来已经能替人录系统。可真正上线时，麻烦常常不在这三个字段上。
一份许可证有几十页，后面跟着长长的清单；一张扫描表格里有没勾选的复选框；一个合同附件跨页延续，表头只在第一页出现。模型抽对前十行，漏掉后五十行，demo 仍然很漂亮，业务系统会直接出错。更麻烦的是，审核员追问“这个字段从哪来”，系统只给一个 JSON，没有证据框，也没有页码。
LlamaIndex 团队这篇 ExtractBench，打的就是这个点。它没有把企业文档抽取简化成“字段准确率”一个数字，而是把值是否正确、长记录是否完整、证据能否定位、每页成本多少放到同一张考卷里。我的判断很直接：企业抽取系统接下来要拼两件事：抽错时能不能被快速发现，抽一百万页时账还能不能算得过来。
企业文档抽取，最怕对一半
schema-guided extraction 听起来很技术，其实就是企业里最常见的录入工作。用户先定义一个 JSON Schema，告诉系统要抽哪些字段、字段是什么类型、哪些值可以为空。系统读完整份文档后，输出符合 schema 的 JSON，最好还能告诉人类每个答案来自哪一页、哪一个词框。
这和传统固定模板抽取不一样。发票、保险理赔、采购订单、政府许可证、基金持仓表，每个流程都有自己的字段清单。企业不会为了每个新 schema 单独训练一个模型，它希望同一个抽取系统读懂新的字段说明，然后在不同版式、不同长度、不同扫描质量的文档里稳定工作。
旧 benchmark 很容易漏掉这层难度。只看短文档，模型会显得很强；只看字段值，长列表漏行看不出来；只看总分，不知道系统到底怕手写、怕跨页表格，还是怕密集小字。ExtractBench 的价值就在这里：它把那些上线后才会炸的细节，提前放进评测。
这张总览图基本讲清了任务。左边输入 JSON Schema，中间输入企业文档，右边系统输出 JSON 和 evidence。评分不只看 Value F1，还看 word-level grounding、page-level grounding、不同 challenge tag 下的表现，以及 cost per page。
图里的例子是能源领域的 W-14 disposal permit。schema 里有 county、reason_pressure、api_no 等字段，总数达到 159 个。系统输出 county 是 Atascosa，还要给出词级证据框；reason_pressure 是 false，因为对应复选框没勾选；api_no 是 null，因为表格里这个字段为空。这个例子很小，但它戳中了生产流程的痛处：很多字段的正确答案来自“没有出现”“没有勾选”“在另一页继续”这种视觉和结构判断。
数据集规模也比普通演示扎实：370 份企业文档，4869 页，8 个业务领域，67 种文档类型，13 类挑战标签。标签覆盖任务挑战、感知挑战、表格结构、领域和长度。这样一来，系统拿不到一个平均分就糊过去的机会，评测会把它切开看：到底是长文档掉分，还是扫描手写掉分，还是大型不规则表格掉分。
这个设计承认企业文档抽取不是单点能力。一个系统短文档抽得好，不能自动推出它长文档也稳；能读清楚电子 PDF，不能自动推出它能处理低质量扫描件。把 challenge tags 做出来，等于给后面的产品选型留了诊断入口。
这里还有一个很现实的场景：年度审计或合规归档。团队不是抽十张发票试试看，而是一批几万页 PDF 一次性进系统。前两页抽得很准没有太大意义，系统要在第七十页的附表里继续保持耐心。长列表截断尤其阴险，输出 JSON 看起来结构完整，只是少了几条记录。如果后续流程拿这份 JSON 去做付款、风控或报送，错误会顺着自动化链条继续往下游跑。
ExtractBench 把 record completeness 单独纳入视野，这一点比单纯堆模型榜单更接近业务。很多 VLM 对短文档确实够便宜，也够快，但长文档一旦开始省略尾部记录，省下来的推理费会变成人工复核费。反过来，coding agent 把文档拆开、写代码处理，准确率更高，可每页成本很快冲上去。两条路都不是银弹，差别只在于把成本付给模型，还是付给后面的人工。
便宜 VLM、高价 Agent，都没法只看一个总分
最有传播性的结果在质量成本图里。横轴是每页成本，纵轴是 overall unified value F1。商业 VLM 站在便宜区间，每页通常不超过 1 美分，但整体 F1 没有超过 80%。Coding agents 能做到 87% 到 94% F1，可成本超过每页 15 美分。
论文里最醒目的对比是 LlamaExtract Agentic Plus 和 Codex GPT-5.5。前者达到 95.6% F1，每页 8.1 美分；后者约 93.6% F1，每页 27.8 美分。LlamaExtract Cost-Effective 也有意思，86.8% F1，每页约 1.0 美分。这个结果当然要记住利益相关，毕竟论文来自 LlamaIndex，自家系统在图上很漂亮。但质量成本图本身的判断方式是对的。
企业采购不会只问“哪个模型最强”。如果一年处理一百万页文档，每页多一美分就是一万美元。更高的准确率能不能抵消更高成本，要看错误类型、人工审核成本和业务风险。一个便宜 VLM 如果总漏长清单，后面人工补漏可能更贵；一个 coding agent 如果每页烧到几十美分，规模化时也很难解释预算。
所以 ExtractBench 不是简单给系统排名，它把抽取系统放回了真实账本。准确率、成本、文档长度、证据定位必须一起看。只拿一个总分做采购，风险很大。
没有证据定位，自动化就停在演示里
Grounding 是这篇论文里容易被忽略、但我认为最接近生产的一项。抽取结果进入企业流程后，人类不会完全退出。系统总会出错，审核员需要快速知道错在哪里。答案旁边如果没有页码和词框，审核员只能回到原文里重新找一遍，自动化省下来的时间又被吃掉。
ExtractBench 分 word-level grounding 和 page-level grounding。前者要求系统指出答案对应的词级位置，后者要求指出页码。这个设计比“给一个引用片段”更硬，因为企业文档里相似字段太多：同一个金额可能出现在摘要页、明细页、附件页；同一个日期可能是签署日期、生效日期、到期日期。证据定位不准，值就算碰巧对了，也很难信。
证据定位还会改变产品交互。一个抽取系统如果能把 county 对应到文档里的 Atascosa 词框，把未勾选的复选框对应到 false，把空白字段对应到 null，审核员的动作就从“重新读文档”变成“确认系统标注”。这两种工作量差很多。前者仍然是人工录入，只是多了一个模型助手；后者才像半自动流水线。
我对这类 benchmark 的期待也在这里。它不应该只服务模型公司发榜，更应该帮企业写采购问题：你的系统在长文档上的漏行率是多少？能不能返回词级证据？每页成本按真实 token 和信用点计算了吗？遇到手写扫描件，错误集中在哪些字段？这些问题比“用了哪个大模型”更接近上线风险。
这里我有一个保留意见。ExtractBench 的开源数据和评测代码是好事，但自家系统拿到最漂亮的质量成本位置，后续最好有第三方复测。尤其是不同企业的文档分布差异很大：法律合同、医院病历、能源许可证、基金报表，错误成本完全不是一回事。一个 benchmark 很难一次覆盖所有生产环境。
但这不影响它提出的问题。过去很多文档抽取演示只证明了“模型能从一页干净文档里抽字段”。ExtractBench 把门槛往前推了一步：长文档会不会漏，证据能不能查，成本能不能扛，错了之后人能不能修。
这几个问题答不出来，抽取系统就还停在演示里。
再往深一点看，成本也不只有 API 账单。抽取系统如果不给证据，企业要么增加抽检比例，要么接受更多漏检风险；如果长文档经常截断，团队会被迫把 PDF 先拆页、再合并、再人工核对。那些都不会写在模型价格表上，却会出现在项目延期和运营人力里。ExtractBench 把 measured cost 放进评测，至少让讨论从“这个模型看起来聪明”回到“这条流程总共要花多少钱”。
所以我会把这篇论文当成一份选型清单，而不是单纯的模型排行榜。它逼供应商回答那些演示里不会主动说的事：漏了多少行、证据到哪一层、长文档怎么计费、人工复核还剩多少。
这比一句“支持 PDF 抽取”更有用。企业购买的是一条能被审计、能算账、能返工的流程，抽取动作只是中间一步。
如果这个流程跑不稳，模型分数再高也只是样板间。
总账本最终不会骗人。能抽出 JSON 只是开始，能带着证据和账本进流程，才是企业真正要买的东西。
在云栈社区，越来越多技术人也在讨论如何让这类自动化流程真正落地，而不是止步于漂亮 demo。
发表于 2 小时前
|
查看: 3|
回复: 0
