企业文档抽取

来源：市场资讯

（来源：科技行者）

你有没有经历过这样的场景：财务同事拿着一份几百页的基金持仓明细，要一行行核对每一笔股票代码和金额，核对到眼睛发花。或者保险理赔部门每天面对成堆的表格，有的字迹潦草得像医生开的处方，还得从里面挑出关键信息填进系统。

这种活儿以前只能靠人力堆。现在大模型来了，企业都想让AI agent接手这些工作，输入一份文档和一张"要提取什么字段"的清单，让AI直接吐出结构化的数据。这件事有个专业说法，叫**模式引导抽取**。

模式引导抽取*：给定一份文档和用户自定义的字段模式（schema），系统需要严格按照这个模式，从文档里抽出正确的值，并且要标明每个值是从文档的哪个位置抽出来的。

这事听起来不难，无非是"读文档，填表格"。但当你真正拿几百页扫描件、手写表格、几万行的持仓清单去测试各家AI系统时，会发现一个挺让人意外的现象：很多顶级的商业大模型，在长文档上会悄悄"偷懒"——不是编造错误答案，而是干脆漏掉一大截该抽取的记录，然后自己浑然不觉。

这正是这篇论文要解决的问题。研究团队做了一个叫ExtractBench的评测基准，专门用来撕开这层"看起来很智能"的表象，看看AI系统在真实企业场景下到底能不能扛住活。

现有的测试题为什么不够用

在这篇论文出现之前，业内已经有一些评测文档抽取能力的基准了，但它们各有各的短板。

早期的基准比如SROIE、DocILE，测试的是"固定本体抽取"，说白了就是题目提前定好了，比如"收据识别"永远只认那几个固定字段：商家名、金额、日期。这类基准测不出AI能不能理解一份全新的、用户自己定义的复杂模式，因为现实中企业的需求千变万化，不可能为每种文档单独训练一个模型。

后来出现的几个"模式引导"类基准，比如Contextual AI的ExtractBench（和这篇论文重名，但是完全不同的团队做的两件事）、Extend公司的LongArray、Micro1的LongExtract-50、VAREX，各自盯住了问题的一个侧面。有的测试模式复杂度，但只覆盖了五个共享模式；有的专注长列表的完整性，但公开的测试集只有几十份文档；还有的干脆给每份文档单独配一个模式，这样就没法测试"同一套抽取任务能否在不同长相的文档上稳定发挥"。

更关键的是，这些基准里，没有一个同时具备四个条件：测试超长文档的记录完整性、包含真实的扫描件和手写文档、既测词级又测页级的定位精度、还把每页的处理成本算进去。

这就好比考驾照，以前的考试要么只在停车场里绕桩，从不上真实马路；要么只考真实路况，但从不计算你加了多少次油、花了多少钱。ExtractBench想做的，是一场既有真实复杂路况、又要算总成本的完整考试。

这份考卷长什么样

ExtractBench这份"考卷"规模不小：370份文档，总共4869页，横跨8个业务领域，67种文档类型。

这些文档不是随便找来的。研究团队特意选取了金融（基金持仓表）、能源（得州铁路委员会的各种申报表）、政府采购与海关文件、汽车估值报告、供应链单据、医疗理赔单、法律破产文件、房地产结算单等八大类，每类都尽量贴近企业实际会遇到的文档形态。

这份基准最巧妙的设计，是给每份文档都打上了五套独立的标签，用来精确定位AI失败的原因。

第一套是任务挑战标签，标注这份文档"难在哪"。分为三类：长列表完整性（T1，考验能不能把几千行记录一条不落地抓全）、大海捞针（T2，考验能不能从一份很长的文档里，精准挑出寥寥几个真正要的字段，而不被文档里大量的相似干扰信息带偏）、密集文档（T3，考验能不能处理挤满标签、空格、勾选框、手写笔迹的表单，而不会"脑补"出根本不存在的答案）。

第二套是感知挑战标签，标注这份文档"是怎么被拍下来的"。包括旋转或纯图像扫描（P1）、普通扫描件（P2）、手写笔迹（P3）。

第三套是表格结构标签，专门盯着表格这个"重灾区"。因为企业要抽取的大部分数据都活在表格里，从持仓明细到发票明细行，而表格失败起来又特别隐蔽：一个系统可能把每个单元格里的值都读对了，但拼装出来的整体结构却是错的。这套标签细分了合并表头（S1）、表头不在顶部的透视布局（S2）、跨页表格（S3）、超大表格（S4，超过一千行）、单元格里塞进整张小表格（S5）。

第四套是文档长度标签，短（10页以内）、中（11到50页）、长（超过50页）。

第五套是业务领域标签，就是前面提到的八大行业分类。

为什么要拆得这么细？因为一个笼统的总分，根本没法告诉你系统到底输在哪里。

这就像去医院体检，如果报告只给你一个"健康指数78分"，你完全不知道该看哪个科室；但如果报告拆成血压、血糖、肝功能、心电图分别打分，你就知道具体该找哪个医生。ExtractBench做的正是这种"分科室体检"，让每一个低分都能追溯到明确的病因，而不是笼统地说"这个系统不太行"。

如果不这样拆分标签会怎样？后果是你没法诊断问题。比如一个系统在长文档上表现差，你根本不知道是因为文档太长导致的截断，还是因为文档里表格结构太复杂导致理解错误，还是因为手写字迹让OCR失效。这三种原因需要完全不同的解决方案，混在一起报一个总分毫无意义。

标准答案是怎么来的：三条不同的流水线

要评测AI做得好不好，前提是你得先有一份"标准答案"，而且这份标准答案本身必须靠谱。这事说起来简单，做起来极其麻烦，尤其是当文档又长又密的时候，人工逐字核对既慢又贵，而且如果只拿某一个AI系统的输出当标准答案，那就等于让考官抄袭了某个考生的答案卷，结果自然会偏向那个考生。

研究团队针对三种不同来源的文档，设计了三条不同的标准答案生产流水线。

**第一条流水线针对真实文档。**

先由人工草拟一份候选模式，标明每个字段该怎么填，然后让好几个来自不同公司、不同技术路线的抽取系统同时跑一遍。如果所有系统在某个字段上给出的答案完全一致（包括都认为该字段是空的），这个值就直接被采纳为候选标准答案。

如果各系统给出的答案不一致，这时候会启动两个独立的编码智能体去诊断分歧的原因：是模式描述本身写得有歧义，导致大家理解不同；还是某几个系统单纯读错了。前者需要回头修改模式描述，加上别名、格式要求、位置提示、"别和这个字段搞混"的说明，直到重跑几次结果收敛；后者则需要人工介入，对着原始文档裁决谁对谁错。

这个过程听起来像不像多个法官交叉质证，然后由一个专家仲裁团队去判断哪些证词是可信的、哪些需要重新调查？如果只让一个法官（也就是单个AI模型）说了算，那这个法官自己的偏见和盲区就会原封不动地写进判决书里。用多个独立系统交叉验证，本质上是用"系统间的分歧"作为一个信号，去揪出哪里可能存在错误或者歧义，而不是简单地相信某一方。

**第二条流水线针对超长的合成列表文档。**

这类文档太大了，比如一份基金持仓表动辄几千行，人工标注既慢又容易看错。研究团队的做法很巧妙：反过来做，先把数据造出来，再把文档"画"出来。

具体流程是，先从一份真实的申报文件里提取记录布局的模式（比如基金持仓表、破产债权人名单），然后生成完整的结构化内容（记录、字段、空值、合计数），再让一个编码智能体研究这份真实文档的字体、栏位、页面细节，写出渲染代码，把这些结构化内容"画"成一份逼真的PDF。因为渲染是用测量后的实际尺寸来分页的，而不是死板地规定"每页多少行"，所以长记录会自然占更多空间，标题也不会和它下面的条目脱节。

标准答案怎么来？既然PDF是从已知的数据渲染出来的，那每个值的页码和文字框位置，直接从渲染过程里读出来就行，天生精确，不需要人去标。最后再用机械检查和多系统审计来抓渲染代码里的bug。

这套方法的巧思在于顺序倒过来了。你可以把它想象成拍电影时先写好剧本再拍摄，演员说的每句台词、站的每个位置都是提前设计好的，所以事后你可以精确地告诉观众"第37分钟这句台词是谁说的"，因为这本来就是照着剧本安排的，不需要有人事后逐帧去记录。如果反过来，先有一部拍好的电影，再让人去标注每句台词的说话人，那工作量会呈几何级数增长，而且还容易出错。

**第三条流水线针对扫描表单。**

这是唯一一条完全靠人工逐字核对的流水线。因为表单往往涉及手写字迹和模糊的勾选标记，机器难以独立判断，必须有人盯着看。

流程是先根据空白表单模板草拟模式并冻结，然后让最多五个系统对每个字段投票，有分歧的字段交给一个必须先看原始页面才能裁决的仲裁智能体处理，再由指定的流水线给每个字段提出一个候选文字框位置，最后人工标注员逐一确认、修改、置空或者重新画框。

最终产出了169份人工核实的文档，其中84%的核实字段带有人工标注的定位框，剩下的大多是表单本身就是空白的字段，压根没东西可框。

三条流水线的可信基础各不相同：真实文档靠多系统交叉一致，合成列表靠渲染过程本身的精确性，扫描表单靠人工核实。这也决定了哪些指标能在哪些文档上测量，值的正确性到处都能测，但词级定位精度只能在标注过的文档上测。

怎么打分：不只是对错，还要看定位

评测抽取系统，光看"对不对"还不够，还得看"能不能证明"。

这篇论文用的核心指标叫统一值F1，一句话解释就是把每个抽取出来的输出，拆解成一个个最小单元（每个标量字段算一个，数组里每条记录的每个子字段也各算一个），然后逐个比对是否和标准答案匹配，再用精确率、召回率、F1值来综合衡量。

对于数组（比如一份持仓表里的多条记录），比对方式很讲究，因为记录的顺序未必和标准答案一致。这里用的是一种叫匈牙利算法的最优匹配方法，把预测的记录和标准答案的记录做全局最优的一一配对，让总的错配数量最小。这就好比把一副打乱的扑克牌和一副排好序的扑克牌做比较，你不会死板地按位置去比第一张对第一张，而是先找出哪张牌该配哪张牌，再看整体配对下差了多少张。

值的比较也有归一化规则，日期统一转成ISO格式，字符串会合并多余空格，但除此之外一律要求精确匹配，没有数字容差，也不用大模型当裁判去"宽松判断"。缺失值的处理也很关键，如果本该是空的字段，系统正确返回了null，这算对；如果系统漏填了一个本该有值的字段，这算错，而且这个错误会同时拉低精确率和召回率。

除了值本身对不对，ExtractBench还专门测了溯源能力，也就是抽取出的每个值，是否能准确指向文档里的原始位置。这里用了两级指标。

**词级定位F1**要求预测的文字框和标准答案的文字框在IoU（交并比，衡量两个矩形框重叠程度的指标，0.5表示重叠一半以上才算命中）达到0.5以上，而且对应的值必须正确，一个框得再准，如果值本身是错的，也不算数。

**页级定位F1**要求宽松一些，只要指对了页码就行，不需要精确到具体位置。

为什么要分两级？因为在真实审核场景里，光知道"答案大概在第37页"和知道"答案就在这一行这几个字"，审核效率是天壤之别。前者相当于告诉你"钥匙在客厅"，你还得满屋子翻；后者相当于直接告诉你"钥匙在沙发第二个抱枕下面"。

十四个系统同台竞技，结果出人意料

研究团队一共测试了14个抽取系统，分成三大类。

第一类是商业VLM（视觉语言模型，能同时理解图像和文字的大模型），把整份文档当图片喂给模型，让它一次性生成结构化输出，代表有GPT-5.4 Nano和Gemini 3.5 Flash，还有一些自己部署的开源模型。

第二类是编程智能体，代表是Claude Code Opus 4.8和Codex GPT-5.5。这类系统的工作方式更像一个真人程序员，它们可以查看文档、写代码、跑一遍验证、再修改，是一种反复迭代的工具调用循环，而不是一次性生成答案。

第三类是专用抽取API，包括Reducto Deep Extract、Extend Max Context、Datalab，以及研究团队自己的LlamaExtract（分成经济版、智能体版、智能体增强版三个档位）。这类系统是专门为文档处理流程打造的托管服务。

结果最戳人的地方，在于长文档上的表现分化。

Gemini 3.5 Flash在短文档上准确率高达87.9%，看起来相当能打，但换成长文档，直接掉到27.9%，几乎腰斩再腰斩。这不是个别现象，几乎所有一次性生成的商业VLM都出现了类似的断崖式下跌。

反观LlamaExtract Agentic Plus，短文档96.6%，长文档94.4%，几乎没有掉分。Claude Code Opus 4.8的表现也相对稳健，长文档上还能保持88.1%。

这个数据说明了什么？说明这些一次性生成的模型，本质上是"读一遍就交卷"，一旦文档长度超过它们能处理的上下文范围，它们不会去想办法分批读、迭代补全，而是直接在某处"截断"，然后自己都不知道漏了一大截。

用一个具体场景来体会这个差距。假如一份文档里有100条记录需要抽取，短文档系统可能读完全部100条只错1条，看起来准确率99%，很唬人。但当记录数变成1000条，如果系统在读到第300条左右就"力竭"了，剩下700条记录压根没被处理，那么哪怕它把已经读到的300条全部读对了，实际召回率也只有30%左右。而这种失败模式在整体F1分数上看，往往不如直接读错几个数字来得直观和显眼，因为漏掉的记录看起来就像"从来不存在"一样安静。

研究团队专门做了精确率和召回率的拆分分析，发现商业VLM在长文档上，精确率和召回率的差距（也就是论文里叫的Δ值）能拉到57.2个百分点，比如Gemini 3.5 Flash在长文档上精确率83.7%但召回率只有26.5%。这个巨大的落差直接印证了前面说的猜测：这些模型在遇到超长文档时，"抓到的都对，但抓的太少"。

再看成本。LlamaExtract Agentic Plus每页只要8.1美分，就拿到了全场最高的95.6%总体F1，而两个编程智能体虽然也表现不错（Claude Code 87.1%，Codex GPT-5.5 93.6%），但成本分别高达16.2和27.8美分每页，是LlamaExtract Agentic Plus的两到三倍还多。

换句话说，花更多钱不一定能买到更好的结果。这个发现有点反常识，因为大多数人的直觉是"贵的肯定好"，但论文用九个商业模型家族内部的对比进一步验证了这个观点：GPT系列从入门级Nano到旗舰版GPT-5.5，质量确实是单调上升的（74.9%到88.7%），但价格也从0.21美分暴涨到6.86美分，投入产出比在后半段急剧下降。而Gemini系列更夸张，从入门级到旗舰版价格涨了20多倍，质量却几乎原地踏步（79.6%到78.2%，甚至还微跌了）。Claude系列更是完全非单调，中间档Sonnet反而比顶配Opus分数更高。

这告诉我们一件事：模型的档位、价格标签，和它实际抽取质量之间，并没有你以为的那种线性关系。挑系统不能只看"贵不贵"，得看具体场景下的实测表现。

表格里的坑：超大表格是照妖镜

在所有的挑战维度里，表格结构里的"超大表格"这一项，最能把系统的真实水平筛出来。

论文数据显示，面对超过一千行的巨型表格，几乎所有商业VLM得分都掉到10%以下，Datalab和Extend Max Context也大幅下滑到32.7%和24.8%。而LlamaExtract Agentic Plus（95.9%）、Reducto Deep Extract（95.3%）、Claude Code Opus 4.8（87.8%）三家表现稳健。

这个反差说明什么？说明面对超大表格，绝大多数系统的策略是"读到哪算哪"，没有一套系统性的策略去保证把表格从头读到尾。这就好比让一个人抄写一本电话簿，如果他没有一个"抄完这页翻下一页，一直到最后一页"的明确计划，很容易抄到一半就以为完成任务了，然后停下来交卷。

跨页表格（S3）是这个问题的温和版本，难点变成了要在页面断裂的地方，把表格的连续结构给续上，很多系统在这里也会掉链子。

而"透视布局"（表头不在顶部，S2）反而是所有结构标签里区分度最小的一个，因为大部分领先系统在这方面处理得都还不错。

论文还专门指出，密集文档（T3）里有一类特殊情况，叫"大模式"（T3.e），指的是模式本身超过150个叶子字段的情况，比如W-2工资单、复审版W-14表格、1040报税表这类字段极其繁多的文档。结果显示，有七个系统在这类文档上得分低于50，很大程度是因为它们直接"拒绝"处理这么大的模式，输出为空。具体来说，Gemini对152个字段的W-2表格干脆不返回任何结果；Lift、Gemma4、Reducto、Extend对全部18份1040报税表都返回空。但Codex GPT-5.5、Qwen3.6 35B-A3B以及全系列LlamaExtract都完整处理了每一份这类文档，且得分都在80以上。

这说明模式大小本身也是一个系统的"能力天花板"，有些系统压根撑不住太大的表格，这是一个实实在在的部署限制。

溯源能力：目前最大的短板

前面提到，ExtractBench不仅测值对不对，还测能不能溯源。这部分的结果，是整篇论文里最让人清醒的一块。

先说一个基本事实：商业VLM和编程智能体，默认根本不返回任何来源证据。也就是说，无论Gemini、GPT还是Claude Code、Codex，抽取出来的值再准，你都没法知道它是从文档哪里来的。它们在词级和页级定位上的得分都是0，没有例外。

这意味着，如果你的业务需要"可审计"的抽取结果（比如财务审计、合规检查这种必须让人能追溯每个数字来源的场景），单纯用这些模型是不够的，必须额外接一个定位组件，或者干脆换成专门支持定位的抽取API。

即便是支持定位的专用API，词级定位和页级定位之间也存在明显落差。LlamaExtract Agentic Plus的页级定位F1能到84.9%，相当不错，但换成词级定位，直接掉到46.4%，接近腰斩。Datalab的落差更悬殊，页级48.5%对词级仅有2.0%。

这说明什么？说明"知道答案在哪一页"这件事相对容易，但"精确指出答案在这一页的哪个位置"要难得多。这就像有人告诉你钱包丢在了图书馆，这个信息有用，但真正节省你时间的是有人直接告诉你钱包就在三楼靠窗那张桌子的第二格抽屉里。

而在长文档场景下，这个落差还会进一步放大。Extend Max Context的页级定位F1从短文档的61.7%直接归零，Datalab也是同样的崩溃模式。相比之下，Reducto Deep Extract更稳健一些，从72.6%降到67.3%，而LlamaExtract Agentic Plus始终保持领先。

论文最后总结说，即便是表现最好的系统，词级定位F1也只有46.4%。这意味着，让AI准确抽取数值这件事，已经算是相对成熟的技术了，但让AI可靠地把每一个数值和它的原始出处精确对应上，仍然是一个远未解决的开放问题。

论文里几个具体案例，看得更清楚

论文附录里给了几个真实的对比案例，比抽象的分数表格更直观。

有一个例子是一份被扫描降质处理过的破产服务清单，里面有250个当事方、总共1457个值要抽取。研究团队截取了前两条记录（8个字段）做对比。LlamaExtract Agentic Plus全部8个值都抽对了，还成功定位了其中7个。而Lift 9B读错了姓名和地址，只对了3个；Codex GPT-5.5把邮箱地址里的空格都吞掉了，把"DOR@ALTO-INV.COM"这种正常邮箱写成了粘连的乱码，只对了1个；Extend Max Context出现了两处字符级的小错误，对了6个。

另一个例子是一份医疗理赔汇总单，里面有三条理赔记录和它们对应的服务明细行。GPT-5.4 Nano把表格的表头文字当成了实际数据去抽取，这是一个挺典型的"把标签当内容"的错误。Claude Code Opus 4.8则是漏填了所有的"允许金额"字段。Datalab把理赔状态错误地复制填进了本该留空的服务明细行状态字段里。

第三个例子是一份打字机打出来的得州铁路委员会P-18表格，里面的字段大多靠虚线引导线对齐，而不是画在规规矩矩的表格线里。Gemma4 26B把好几个沿着虚线排列的数值整体"错位"下移了一行；Codex GPT-5.5把地名短语错误地合并进了城镇名和郡名字段；Datalab干脆漏掉了处置井名称和许可证号这两个字段。

这些案例说明，AI在处理非标准排版、字符间距不规律、表头与内容错位这些"看起来简单实则暗藏陷阱"的版式时，仍然会犯一些让人哭笑不得的错误，而这些错误往往在总分层面很难被看出来，只有拆到具体字段才能发现问题所在。

这项研究给我们的启示

回过头看，这篇论文最重要的贡献，其实不是"评出了谁最强"，而是提供了一套能精确定位问题原因的诊断工具。

三年前，学术界评价一个抽取系统好不好，往往就是给一个笼统的准确率数字。但这篇论文告诉我们，同一个系统在短文档上可能考94分，换成超大表格立马跌到个位数，中间的落差信息，如果不做细粒度拆分，是完全看不出来的。

对于企业来说，这个启发是实际的。假如你正打算给公司引入一套AI文档处理系统，光看厂商宣传的"整体准确率95%"是不够的，你得先弄清楚自己的文档属于哪种挑战类型，是长列表、还是密集表单，还是需要在长文档里精准挑出几个关键字段，再针对性地去看对应场景下的实测表现。

这篇论文之后，这个方向大概率还会继续细化。比如更早的Extend LongArray关注的是长数组的记录完整性，Micro1的LongExtract-50关注长统计报告，而ExtractBench把这些拆开的维度第一次系统性地拼到了一起，同时纳入了成本这个变量。可以预见，接下来的评测基准会进一步往"精细定位+成本敏感+多模态融合"的方向去演进，因为企业最终要的从来不是一个漂亮的准确率数字，而是一个既准又便宜又能审计的系统。

写在后面

读到那个词级定位F1只有46.4%的数字时，我停下来想了一会。这意味着即便是这场评测里表现最好的系统，让它去证明"这个数字确实是从文档这个位置抽出来的"，也有超过一半的机会指错地方。这和我们平时对AI"越来越聪明"的直觉有点错位，抽取值本身这件事似乎已经被解决得相当好了，但"证明我为什么这么说"反而成了更难的那道题。

这让我想起一个类似的现象：很多时候，得出正确答案和解释清楚推理过程，其实是两种完全不同的能力，前者靠模式匹配就能做到，后者需要真正理解结构和上下文的关联。AI在文档抽取上似乎也走到了这个分岔口。

还有一个细节值得单独说一说：论文里提到，长文档场景下精确率和召回率的落差能拉到57个百分点，也就是说很多模型"说对的都对，但说得太少"。这种失败方式很安静，它不会报错，不会输出乱码，只是悄悄地少交了一部分答案。而这恰恰是最危险的一种失败，因为它不会触发任何警报，直到某个审计的人发现少了一笔账。

如果这套评测标准能推广开，下一个值得追问的问题是：当系统学会了在长文档里稳定定位每一个值的来源之后，人类审核员在这个流程里还剩下什么工作？

Q&A

Q1：ExtractBench是什么？

A：ExtractBench是一个专门评测AI系统"模式引导抽取"能力的基准测试集，包含370份企业真实文档、4869页内容，覆盖8个业务领域和67种文档类型，同时测量抽取准确率、来源定位能力和处理成本。

Q2：为什么商业大模型在长文档上表现会大幅下降？

A：因为这些模型大多是一次性读完文档就交卷，没有分批处理或反复核对的机制，一旦文档超出它们能稳定处理的长度范围，就会在某处悄悄截断，漏掉后面大量记录，而且系统自己不会发现这个问题。

Q3：花更多钱用更贵的AI模型，抽取效果一定更好吗？

A：不一定。论文测试发现，LlamaExtract Agentic Plus花8.1美分每页就拿到了全场最高的95.6%准确率，反而比价格是它两三倍的编程智能体表现更好，说明价格和效果之间并不是简单的正比关系。