检验整份文档是否真正能进入业务流程

概览

文档提取工具可能拿到很高的分数，团队却仍然无法直接使用结果。问题往往出在多个看似合理的字段必须同时正确。选择置信度门槛之前，不妨做一个小实验：衡量完整业务记录是否可用，而不只看单个字段。

以下实验完全是假设情景。数字用于说明决策方法，并非客户成果，也不是产品性能测试。

看结果之前先定验收标准

假设一家经销商要把供应商发票整理成应付账款审核人员可用的记录。只有供应商身份、发票编号、币种、总额和采购订单编号都与原件及相关主数据相符，记录才算准备就绪。通过这个测试不代表可以付款，原有审批控制仍须保留。

选取100张没有用于训练的发票。先由熟悉业务的审核人员标注必需字段，再请第二位同事共同解决有歧义的标注。样本既要包含普通文档，也要包含难例；保留分类，避免把刻意增加难度的样本误当成日常生产比例。

原创实验表：假设的样本构成，并非通用样本量建议。

固定提取版本、标准化规则和测试文档。事先约定怎样才算匹配，例如可忽略无关紧要的空格，但不能忽略币种差异。在标准化值旁保留原始文本，方便审核人员还原有争议的判断。

把两种分数放在一起看

Google Document AI文档介绍了依据已标注文档计算的精确率、召回率和F1，也提供单字段指标。文档同时说明，缺少适当标注或不受提取版本支持的标签，可能不计入汇总指标。因此，高汇总分数仍需配合覆盖范围检查。 Google Cloud，核验日期：2026年10月29日。

我们增加一项业务指标：完整记录就绪率，即所有必需检查都通过，且没有尚未解决的歧义。不要用各字段分数相乘来推算它，因为错误可能集中在同一张受损文档上。

原创结果表：20个字段错误分布在16份文档上。此处的字段正确率是自定义计数，并非Google的产品指标。

这种差别会直接影响运营。即使只有20个字段出错，仍有16条记录需要处理。缺失输出和处理失败也应计入文档总数；把它们排除，会让流程显得比实际容易。

不触碰真实付款，比较分流规则

先用独立的开发样本选择规则，再用留出的测试集评估已经固定的规则。在这个假设结果中，70条记录被送往下一步，30条被留待人工审核。独立复核发现，放行记录中有2条错误，暂留记录中有14条错误。

原创分流矩阵：放行的70条记录中有2条含错误；暂留30条记录，拦住了16条错误记录中的14条。

这应当触发业务讨论，而不是换来一张“通过”证书。漏出的两条错误只是无关紧要的描述，还是币种错了？团队能否在承诺的时限内审核30条记录？强制核对供应商身份，是否能发现单靠置信度遗漏的问题？

务必保留原始计数。100份文档不足以证明流程能够安全应对罕见而代价高昂的错误。扩大应用前，应补测更多供应商和语言，单独检查高影响错误，并在模型或版式发生重大变化后重新评估。真正有用的交付物，是适用边界清楚、有证据支持的分流决定，而非一个亮眼的百分比。