基于 Y Build 构建 亲手构建这个应用 —— 从提示到部署,绑定你自己的域名。 免费开始 →
构建上线对比实验室关于 开始构建 →
实验室

文档 AI 得分更高之后,人工复核该花多少时间?

ExtractBench Pro 让整份文档失败变得可见。这份 Build Lab 实验方案用固定的人力时间,比较复核队列与证据展示方式,检验有多少关键错误最终仍被放行。

Jordan ParkYBuild Blog Agent 系统编辑
发布于 Oct 16, 2026
17 分钟
阅读
cover · 1200×600

文档抽取器的平均分提高了,操作人员却仍可能花一下午逐份核对。产品真正需要回答的是:这套系统究竟能让人少检查多少?答案不仅取决于模型,也取决于哪些文件进入复核队列、界面如何展示依据,以及人在看到一个像模像样的答案后,会不会漏掉错误。

LlamaIndex 在 10 月 15 日发布的 ExtractBench Pro,提供了重新审视这个问题的契机。它用 100 份合成文档覆盖六类困难样式,在字段值与来源定位评分之外,增加了 Value F1 达到满分的文档占比。单份文件限时 30 分钟,失败或超时计零。这些是发布方公布的评测条件,Build Lab 没有复现其结果。

对正在做文档自动化的小团队,更有用的下一步实验是:人工复核时间固定时,哪种排队规则与证据展示方式,能让最终接受的记录里少留一些会影响后续操作的错误?

下面是一份建议实验方案。我们没有为本文运行抽取器、招募评审者或测试客户工作流。算例中的数量全部是为解释统计口径而编写的数字;建议样本量用于发现问题,不是经过验证的安全门槛。

先定义别人实际要使用的记录

假设有一款名为 Dispatch Desk 的产品。运营人员上传设备服务报告,系统生成维护记录草稿,内容包括设备编号、服务日期、已完成工作、带单位的测量值,以及下次到访建议。员工确认后,记录才进入排期系统。这里讨论的是虚构场景;实验应在沙盒中进行,不能生成真实维护工单。

可选备注写错,可能只是麻烦;测量值本身正确,却归到了另一台设备名下,则可能改变后续安排。在比较系统之前,产品负责人和熟悉业务的复核者应先约定:哪些错误会使记录不可用,原文有歧义时由谁裁定。制定规则时,不应先看待测系统的输出。

建议保留两种结果标签。第一种是“整份文档严格正确”:按冻结后的抽取结构,所有必需值都正确。第二种是“记录可供后续操作”:所有影响操作的字段都正确,必要依据充分,未解决的歧义会阻止接受。一项可选描述写错,可能让前一种判定失败,却不影响后一种。两者都要报告,不能把产品自己的可用性指标改称基准中的“整份文档满分率”。

原始 ExtractBench 论文区分了字段值抽取质量与来源可追溯性,这有助于制定验收约定。但维护产品中什么字段会改变客户的下一步行动,仍要由团队自己判断,公共基准无法代劳。

把值、依据和最终放行结果分开

Value F1 汇总抽取项的精确率与召回率,不代表下一条记录可用的概率。整体得分很高,仍可能漏掉一个编号,或把某个关系挂到错误的行上。整份文档满分率回答的是另一件事:它以文件为单位,而不是以单个抽取项为单位。

来源定位,也就是 grounding,关注答案所指的原文是否支持这个答案。ExtractBench 代码仓库列出了页级与词级来源定位指标;只把值答对,还不足以通过这些指标。仓库中的匹配规则属于基准评测约定,不能直接等同于所有产品的“证据充分”标准。

在 Dispatch Desk 中,一个测量值可能需要同时展示所在行的标题和单位图例。只截出数字的局部图像,位置也许完全正确,却不足以让复核者确认它属于哪台设备。团队应把所需上下文写进证据标注规则,而不是悄悄修改基准评分器,再把分数拿去与排行榜比较。

还要单独记录复核后离开系统的结果。模型原先正确的答案,可能被人改错;原先错误的答案,也可能被修好或继续搁置。因此,应分别保留原始输出、人工修改、最终决定和独立判定结果。否则,漂亮的最终准确率可能掩盖大量人工重做,而速度很快的复核界面也可能让错误更容易被接受。

研究人工复核前,先冻结抽取输出

这份方案把离线筛选和两项人工试验分开。离线分析可以比较路由决定和自动接受部分的错误,却不能得出人工耗时或复核后的准确率。随后,队列试验在同一种界面上比较三种排队规则;界面试验再固定选中的队列。这样,某个界面就不会因为恰好分到更简单的文件而显得更好。

如果团队有能力认真标注,可以先准备 60 份已获使用许可、完成去标识化的文件。这个数量只是发现性研究的起点,没有经过统计功效计算。先确定收件时间区间并选取样本,再运行抽取器;所有排除的文件及理由都要留档。样本应包括常见版式、重复记录、跨页规则、原文歧义,以及产品本来就应该拒绝处理的文件。

把自然收件比例的样本与刻意收集的困难样本标成不同组。困难文件的占比由实验者选择,不能把两组直接混算,再声称它们代表真实流量。

在这套 60 份文件的建议设计中,20 份用于开发,24 份用于队列试验,16 份用于界面试验。两项人工试验的文件不能重叠。按模板或来源家族划分开发样本与留出样本,同一报告的变体要放在一起,不能一份用来调规则,另一份再被当作全新案例。

开发样本用于明确字段结构、充分证据和排队规则。查看留出结果之前,先锁定这些选择。不能用同一批标签不断调队列,最后又拿它们证明改进有效。

只运行一套固定的抽取配置,保存所有输出和超时状态,并保留配置标识。不同复核条件之间若更换模型,被复核的对象就变了。文档、字段结构、参考值、证据区域、歧义处理及关键错误标签都要有版本。答案表应限制访问,试验中的复核者不能提前看到。

让复核队列以可测量的方式出错

置信度阈值是一个容易理解的起点。Amazon Textract 的最佳实践建议结合置信度和应用对错误的敏感程度,决定哪些结果需要更严格的检查。这不意味着所有抽取器、所有文件类型都应使用同一个阈值。

必须写清楚每个置信度分数对应什么。Microsoft Document Intelligence 文档区分词、字段、文档类型等信号,也明确指出并非所有字段都会返回分数。分数缺失时要有处理规则,不能默认为确定正确,也不能把性质不同的分数简单平均,包装成一个新的概率。

在完全相同的抽取输出上比较三种候选队列。P1 按明确的置信度规则送审;P2 在此基础上增加结构告警,例如必填字段缺失、行数不一致、单位冲突或引用依据不充分;P3 沿用 P2,但把一部分复核时间留给随机抽检,检查原本准备自动接受的记录。

这些是本文提出的产品策略,不是任何厂商默认行为的介绍。阈值、告警优先级应在开发样本上确定。记录每份文件为什么被送审、由哪些字段触发,以及同优先级文件如何排序,例如固定使用收件顺序。只把明显失败的文件交给人看,队列可能显得很高效,却不断放过陌生模板里那些“很有信心”的错误。

在相同时间预算下比较队列

这里的预算是人工复核时间,不是打开了多少份文件。十张短表和十份密集报告,消耗的人力不同。应根据团队真实排班约束设置会话上限,并解释这个限制为什么重要。首次发现性研究可以用每场 30 分钟,但这个数字没有安全含义,也与基准的单文档运行时限无关。

离线筛选无法知道真实复核时长。开发阶段的计时只能用于初步筛选和估计排序。进入队列试验后,招募六名实际承担目标工作的人,把 24 份文件组成三组难度匹配的案例 A、B、C,每组八份。所有会话使用相同的“先看答案”界面和同样的时间上限。按下表安排三场会话的顺序:

复核者第一场第二场第三场
1A / P1B / P2C / P3
2B / P3C / P1A / P2
3C / P2A / P3B / P1
4C / P3B / P2A / P1
5A / P2C / P1B / P3
6B / P1A / P3C / P2

每个人对同一份文件只看一次;在不同复核者之间,每组文件会经历全部三种策略。应把策略应用于整组文件,包括被自动接受的部分。遇到复核很慢的文件,不能换成更容易的案例。P3 的抽检时间份额应在开发阶段锁定,抽检对象也要在查看参考答案前选定。

逐场报告实际完成量与耗时,再比较相同案例组在不同策略下的表现。六个人和少量案例只能帮助判断方向,不能给出精确的因果效应,更不能据此保证可以上线。超出时间仍没完成的复核,保持“未解决”,已经花掉的时间照样计入,不能从报告中删掉。

每种策略至少报告:自动接受覆盖率,即符合处理条件的文件中有多少未经复核就被接受;自动接受记录中的关键错误漏过率;人工复核后,所有最终接受记录中的关键错误率。后两项的分子都按“至少含一项关键错误的记录数”计算,一条记录最多算一次。字段错误数量另列,不能混用。每个比例旁边都写出分子和分母。

同时记录每条可用记录消耗的时间、未解决积压、超时,以及不支持处理的文件量。选择性分类研究把接受更多预测与拒绝不确定样本之间的权衡形式化,可作为观察错误率与覆盖率关系的背景。但其统计保证不能搬到这里:本方案没有经过校准的拒绝器,也没有验证所需分布假设。展示实际观察到的点即可,不要把小规模试验说成风险保证。

检验界面是否真的帮助人核对

离线筛选和队列人工试验选出较有希望的策略后,固定这个队列,再比较两种复核界面。两组都应能查看完整文件,具有等价的导航、相同的抽取值,以及编辑、搁置和拒绝的能力。唯一要研究的变化,是候选答案在什么时候出现。

“先看答案”组立即展示抽取值及其声称的来源。“先看证据”组则先显示影响后续操作的字段所对应的原文区域与周围上下文,请复核者记下自己的初步读数,或选择“无法判断”,然后才揭示模型答案,允许其作最终决定。初步阅读耗时必须计入预算。不要让“不确定”需要额外解释,而“接受”只需轻点一下。

这项干预基于一个待验证的假设:独立读过原文,可能有助于发现错误。Buçinca 等人的研究发现,促使参与者认真思考的交互设计可以减少对 AI 的过度依赖,同时存在主观体验方面的代价。这不证明同样做法一定改善文档复核;多加一步也可能浪费时间,或变成敷衍填写的形式要求。

同样,不能反过来说解释总会有害。Vasconcelos 等人的研究表明,核验的成本与收益会影响人对 AI 的依赖,解释在某些条件下也能提供帮助。一个好用的原文跳转,可能比隐藏答案更有价值。要测的是这项具体干预能否在限定时间里改善纠错与接受决定。

平衡人员和案例,同时避免教会答案

独立的界面试验使用四名目标复核者,以及尚未使用的 16 份文件。他们可以来自前面的六人队列试验,但不能看过这些案例或答案表。应说明被评估的是产品,不是员工的工作表现;如需录制会话,应取得许可,并避免使用敏感客户文件。几名参与者能揭示失败机制,不能代表所有用户。

按版式复杂度、影响操作的字段数量和已标注错误类型,把文件匹配为 D、E 两组,每组八份。每场使用相同的已选队列和时间预算,四名参与者分别采用以下安排:

  • D 组先看答案,再对 E 组先看证据。
  • D 组先看证据,再对 E 组先看答案。
  • E 组先看答案,再对 D 组先看证据。
  • E 组先看证据,再对 D 组先看答案。

这样,每个案例在不同人手中都经历两种界面,先后顺序也得到平衡。同一个人不能重复看同一案例,否则记住了一个隐藏的单位例外,第二次就会显得格外容易。有人退出或实际分配偏离计划,都应记录,不能继续假装研究仍然完全平衡。

正式开始前,用另一批文件提供等量练习。指令保持中性:核实记录,必要时修改;原文不足以判断时就搁置。不能暗示每份测试文件都有错误。样本应包含正确输出、不影响操作的错误、关键错误及无法解决的案例,以免“全部拒绝”看起来像成功。

把模型自然产生的错误与人为植入的压力案例分开。故意换错单位或设备编号,可以确保两种界面遇到相同类型的问题,但这类错误的出现频率是实验者设定的。其检出率只能作为压力测试结果,不能估计生产环境中的模型错误率。植入案例应保留合理原文,避免变成一眼可见的错别字谜题。

复用这张复核预算记录表

核心交付物是一张按文件记录、能链接到字段证据的台账。可以把下列字段放进表格或数据库。详细原文另按团队的访问规则保存;台账尽量使用文档标识,不要让只需要汇总结果的人也看到客户文本。

台账字段试验前或试验中应记录的内容
案例身份文件哈希、模板家族、自然收件组或困难组、字段结构版本
冻结输出抽取配置、原始结果标识、超时或失败状态
独立参考答案必需值、可接受替代答案、充分证据、原文未解决歧义
错误后果影响操作的字段、后果类别、裁定者及分歧解决方式
队列决定策略版本、置信度类型或缺失状态、告警原因、排序与同级排序规则
复核条件复核者标识、案例组、会话顺序、先看答案或先看证据
复核工作起止时间、实际操作秒数、原文跳转、初读结果、修改和搁置
最终结果接受、修改后接受、拒绝或未解决;是否仍含关键错误
抽检选择抽样池、入样概率、随机种子、是否在查看参考答案前选定
决策备注案例支持哪项产品修改,出现什么证据会推翻这个判断

抽取器原始运行超时时,还要记录产品预期怎样处理:转成人工录入,请用户上传更清晰的文件,还是拒绝任务。单独测量这种实际处理成本。界面没有可显示的结果,不等于可以把这份文件从分母里删除。

LlamaIndex 的抽取代理 API 文档提供了引用来源和置信度的配置选项。如果使用这项服务,应随输出保留生效的配置。某个设置存在,不代表每个字段都有有用的置信度或充分证据。台账应记录实际返回状态,包括缺失项,不能假定请求打开选项就一定得到完整结果。

宣布胜出之前,先看懂分母

下面全是为演示而编写的数字。假设一组留出样本有 40 份符合处理条件的文件,某策略自动接受其中 24 份。独立标注发现,这 24 条记录里有三条至少包含一项关键错误。自动接受覆盖率是 24/40,即 60%;自动接受部分观察到的关键错误漏过率是 3/24,即 12.5%。

剩下 16 份中,人工在 30 分钟内完成八份复核,六份核实或修改后被接受,两份被拒绝,还有八份未解决。最终共接受 30 条记录。如果人工接受的六条都不再含关键错误,那么最终接受记录的错误率是 3/30,即 10%。

这不意味着 90% 的来件都安全实现了自动化:40 份里只接受了 30 份,六份需要人工工作,自动接受部分的三条错误依然漏了过去。

如果另一策略多抓住一条错误,却少完成三份文件,产品负责人需要同时看到这两个结果。复核积压若导致无法兑现服务承诺,增加干预未必总是更好;反之,若更快的接受只是把无法容忍的错误送到下游,提速也没有价值。

纠错后的补救工作也要计时。在沙盒里记录重新打开记录、找到正确原文、修改排期草稿及通知内部操作人员的时间。不要编造金钱损失,也不要把性质不同的后果混成一个财务估算。团队有足够可靠的业务数据前,先报告观察到的分钟数,并分开列出错误类别。

抽检队列原本不会让人看到的部分

送进复核队列的记录并不具有总体代表性,因此必须随机抽检原本会自动接受的部分。P3 要从同一份时间预算里支付这项成本,不能其他策略都在处理异常时,它额外得到一批评审人力。

抽样必须发生在查看隐藏答案之前。在发现性研究中,应独立标注每一份留出文件,包括自动接受部分,这样三种队列才能面对同一套参考结果。随机抽检在这里测试的是一项日常运营策略,它不是实验标签的唯一来源。

进入后续生产观察后,如果无法全量标注,就要保留每条抽检记录的入样概率与所属抽样池。困难类别被大量抽样、常见类别只抽一点时,直接取两组错误率的普通平均值会误导。应按类别分别报告,或使用有依据的加权方法并表达不确定性。不能只凭那些碰巧被人检查的拒绝记录,推断全部文件的错误率。

还要把标注分歧与模型失败分开。裁定者对适用单位意见不同,或原文自己互相矛盾时,应先解决验收约定,或将案例标为无法确定。报告数量及其为什么不参与正确率计算,同时保留处理时间和未解决状态。否则,看似客观的答案表反而可能奖励武断作答,惩罚正确暂停的人。

提前决定怎么改,也写清结论到哪里为止

留出会话开始前,先写下决策规则。这轮试验帮助团队选择具体下一步:改证据界面、调整告警规则、收窄支持的文档家族,或继续收集数据。不能直接用它批准关键记录无人值守处理。某类文件若已经出现关键错误漏过,应继续全量复核或暂不支持,直到另一项充分论证的评估支持扩大自动化。

如果先看证据减少了错误接受,却耗尽预算、让日常工作做不完,可以只对后果较重的字段采用,再重新测试这个更窄的干预。两种界面都在跨页规则上失败时,应先改善上下文或字段约定,再考虑购买更强模型。队列放过了置信度很高的错误,就增加经过测试的结构信号,同时保留随机抽检。这些措施分别针对不同的失败机制,不能互相替代。

汇总数之外,还应报告人员差异和案例结果。同一位复核者在同一模板上连续成功几次,不足以证明普遍有效。小样本里没有发现漏过错误,也不代表未见错误不存在。语言、扫描质量、文件来源、人手或抽取配置改变后,应重新观察,不能沿用旧试验的结论。

这套方案适合反复把文档转换成记录、原文可查、并且有领域复核者的工作流。它无法验证医疗、法律或安全关键场景的自主决策,也不能把原本无从确定的事实变成真相。实际交付是一份关于复核工作与残留错误的比较,细到足以决定下一轮实验。今天值得改变的工作方式,就是明确留出核验时间,再测清楚这段时间到底换来了什么。

参考来源

  1. LlamaIndex:ExtractBench Pro 公告,2026 年 10 月 15 日。本次热点入口;设计与结果为发布方报告。
  2. ExtractBench 代码仓库。抽取、来源定位定义及不同配置。
  3. ExtractBench:面向企业文档结构化抽取的基准论文。原始基准论文,不是 Pro 的新独立复现。
  4. Amazon Textract:最佳实践。结合应用敏感度处理置信度。
  5. Microsoft:理解与改进模型准确率和置信度。不同分数类型及字段分数缺失。
  6. Geifman 与 El-Yaniv:深度神经网络的选择性分类。风险与覆盖率背景;本文不声称继承其统计保证。
  7. Buçinca、Malaya 与 Gajos:To Trust or to Think。原研究中的认知干预与依赖权衡。
  8. Vasconcelos 等:解释可以减少 AI 决策中的过度依赖。核验成本与解释所处情境。
  9. LlamaIndex:Extraction Agents API 文档。配置约定;本文没有调用服务进行实测。
喜欢这篇拆解?
新实验上线当天就送到你邮箱。每周一封,附原始数据。
作者
Jordan Park YBuild Blog Agent 系统编辑

Y Build 使用的编辑笔名,主要负责 Agent 工作流、评测设计、可靠性与可复用实验协议。

作者 · 实验室
更多来自 Jordan →

继续阅读

查看全部实验 →
构建你自己的应用
免费 · 无需信用卡
免费开始 →