IDP 智能文档处理：从字段提取到可用的业务记录

IDP（智能文档处理）的价值，在于减少重复录入，同时把错误数据挡在业务系统之外。整套流程应围绕 4 项任务展开：判断文档类型、提取字段、校验数值与内容，并在归档或入账前，将异常交给人工处理。

对运营或财务负责人来说，最先值得实现的成果，是一条经过核验、附有原始凭据的草稿记录。自动付款、合同解读和供应商审批，需要分别决策。先从每天最耗时的工作入手：读附件、复制字段、找到正确的文件夹。

本文所述能力与限制已于 2026 年 10 月 26 日依据厂商文档核实。下文试点方案是一套建议的评估方法，并非产品性能基准测试。

IDP 智能文档处理如何运作？

IDP 将文档转化为可用的业务记录，并把无法确定的情况交给人工复核。 可以把它理解为一名拿着核对清单的档案员：先辨认收到的材料，再抄录相关信息、逐项检查规则，最后把仍有疑问的材料交给有权判断的人。

输入可能是栏位固定的结构化表单，也可能是版式因供应商而异的半结构化发票，或没有固定结构的邮件。输出则可能进入财务系统、合同台账或业务案件处理队列。AWS 的 IDP 概述将分类、提取、校验和集成列为这一完整流程的组成部分。

一套实用的发票处理流程可以这样设计：

1. 分类。 判断附件是发票、贷项通知单、对账单，还是其他材料。如果一个文件包含多份文档，应先拆分，再提取字段。
2. 提取。 读取供应商、发票号码、日期、币种、总额和明细行。保留原始文件，以及每个值对应的来源页码或页面区域。
3. 校验。 检查必填字段、计算结果、重复记录和供应商档案。总额即使识别无误，也可能来自另一张发票。
4. 分流。 将通过验收的记录归档到允许写入的位置。缺少采购订单、总额不一致或分类不确定的情况，交给明确指定的复核人。

这些都是需要主动设计的职责，不能假定每个提取 API 都已提供。API 是软件用来请求服务的接口；它可以返回字段，却并不了解你的审批制度。

文件标识应始终与记录绑定。否则，哪怕信息提取完全正确，只要找不到支撑这条记录的原始文档，业务流程仍然会出问题。

大语言模型和视觉模型让 OCR 有了哪些变化？

关键变化是：提取信息可以依据语义和页面上下文，不再只依赖字段出现的位置。 OCR，即光学字符识别，负责从图像中读取文字。基于模板的提取器再按已知位置或版式规则查找字段。大语言模型（LLM）能够理解语言；视觉语言模型还可以接收图像输入。

例如，供应商可能把“应付金额”从页面右下角移到顶部附近的汇总框。固定位置的规则因此需要调整。接到“找到应付总额”指令的模型，可以结合标签和周围内容判断，但仍可能选错金额。

Google Document AI 的 Custom Extractor 支持通过基础模型，按照预先定义的 schema 提取信息。schema 就是希望模型返回的字段定义；提取时可以选择零样本或少样本方式，也就是不提供任务示例，或只提供少量示例。因此，托管提取服务早已超出仅靠模板的旧模式。Google 的 Custom Extractor 文档说明了可用的方法。

结构化输出解决的是另一类问题：让响应符合规定的数据结构。日期字段用字符串表示、总额用数值表示，确实更方便软件处理，但格式正确并不能证明信息取自正确位置。应当区分结构校验与业务校验：前者检查是否符合 schema，后者检查字段值在业务上是否可以接受。

智能文档处理适合哪些业务场景？

选择首个落地流程时，先看能否清楚定义什么才算正确答案。 边界明确的提取任务，比“处理我们所有的文书工作”更容易评估。

在应付账款场景中，可以根据发票生成应付单草稿、匹配供应商，并标记重复记录。银行账户信息发生变更时，即使印在文档上的账号清晰可读，也不应自动接受。

在合同场景中，可以提取合同主体、明确写出的日期，以及描述续约条件的原文段落。抄录通知期限，与判断该期限在多份修订文件下如何适用，是两种不同的工作。前者可以帮助运营负责人准备合同台账，后者则需要有明确责任归属的复核人判断。

在表单场景中，可以采集录入的文字和勾选标记，再检查是否填写完整。入职表单如果缺少必需的签名，就应保持未完成状态，不能靠推断补出一个答案。

在邮件场景中，应识别请求，并建立邮件与附件的关联。一封写着“请使用修订后的发票”的邮件，要求流程保留这种关系，而非把两份附件都提取成记录，造成重复。

同样的方法也可以用于理赔材料受理、货运单证或员工档案。判断标准始终要具体：需要什么值，证据在哪里，出现分歧由谁解决？

智能文档处理软件：买成品，还是自己搭建？

任务标准化时，优先购买完整的流程应用；特殊之处在于业务规则和写入目标时，再围绕提取服务自行搭建。 两条路线的差别，在于文档接收、校验、复核和系统集成中，有多少工作需要组织自行承担。

托管服务只是一个组件，不会自动变成开箱即用的财务流程。同样，“定制”也不意味着从零训练模型。你可以围绕托管提取器，搭建自己的文档接收和复核流程。

采购时，最有说服力的演示，是复核人能否对照原始文档完成一项异常处理。上传成功的动画，说明不了后面还剩多少工作。

智能文档处理厂商怎么选？也看看 LLM 原生路线

比较这些路线时，应以实际文档构成、证据要求和复核工作量为依据。 以下描述来自厂商已公开说明的能力；适用性判断属于选型建议，并非准确率排名。

Google Document AI：以处理器为核心，提供生成式提取选项

Google Document AI 是 Google Cloud 的文档处理服务。其处理器目录包括 OCR、Invoice Parser、Custom Extractor、Custom Classifier 和 Custom Splitter。Invoice Parser 提取发票表头与明细行字段；分类和拆分功能则负责识别文档类型及文档边界。Google 的处理器目录说明了各自的职责。

先从与任务匹配的预构建处理器开始；如果所需字段或文档类型不适用，再评估 Custom Extractor。其生成式路线支持按 schema 提取，并可选择提供示例或进行微调。Google 的评估还提供精确匹配与模糊匹配，因此比较结果前，要先约定哪些规范化处理可以接受。参见 Custom Extractor 文档。

需要认清的边界，是工作流仍由你负责：返回一个发票金额，并不等于完成供应商匹配、执行企业规则或解决异常。试点前，应确认所选处理器版本支持的语言、区域和文档类型。

Azure AI Document Intelligence：预构建模型与自定义模型

Azure AI Document Intelligence 是 Microsoft 的文档提取服务。文档列出的选项包括 Read 和 Layout、预构建发票与收据模型、自定义模板提取和神经网络提取，以及自定义分类。Microsoft 将自定义模板用于固定版式，将神经网络模型用于变化更多的文档。参见 Microsoft 的模型概述。

对于基于 Azure 的运营系统，先选用适合该文档的预构建模型。如果收到的材料包混有不同类型的文档，再加入自定义分类；如果所需字段不同，再评估自定义提取。

需要避免的误区，是以为识别出版式就完成了业务记录。Layout 能识别文字、表格和勾选标记，但应用仍需整理输出，使其符合目标系统的要求。Microsoft 在 Layout 指南中明确讨论了通过后处理，将跨页表格合并成一张表。

AWS 智能文档处理：Amazon Textract

Amazon Textract 是 Amazon Web Services 用于提取文档文字和数据的服务。AWS 文档介绍了文本检测、表单和表格提取，以及专门的发票和收据处理功能。其费用分析无需针对各供应商建立模板，即可提取发票日期、号码和总额等字段。参见 Textract 的发票与收据文档。

如果周边应用已经运行在 AWS 上，且文档字段符合其支持的操作，Textract 是值得优先测试的候选。应选择对应的操作，而不是把所有文档都当成纯文本处理。

需要避免的误区，是认为一个置信度分数就能替你作出业务决定。AWS 建议根据应用的敏感程度设置阈值，并将不确定的结果交给人工审查。它还提醒，合并单元格和不规则表格可能导致提取结果不一致。参见 Textract 最佳实践。

LLM 原生路线：模型、schema 与复核队列

OpenAI API 是 LLM 原生方式的一个已有文档说明的例子：软件将文档发送给模型，要求模型按规定结构返回字段。处理 PDF 时，支持视觉的输入方式会同时提供提取出的文字和页面图像。参见文件输入文档。

应用负责定义字段、要求提供证据引用，并决定找不到字段值时如何处理。应允许返回缺失状态，同时说明“原文未提供”或“无法辨认”等原因，不要强迫模型填满所有空白。还应对照原文件核验证据引用，不能默认模型生成的页码引用就是正确的。

OpenAI 文档说明了受支持的结构化输出遵循 schema 的能力，同时明确指出，字段值仍可能出错，模型拒绝响应或响应不完整的情况也需要处理。参见 Structured Outputs 文档。本站的结构化输出指南解释了模型与应用之间的数据约定。

当缺失的能力是结合上下文提取信息，且有人能持续维护流程时，可以选择这条路线。它的边界在于落地运营：即使已有提示词和 JSON 响应，评估、重试、复核、存储，以及安全地写入目标系统，仍由你负责。

Dext：把适用范围放在记账业务内

Dext 是用于采集记账凭据的应用，适合待处理材料主要为收据和账单的情况。其文档说明，它会提取供应商或客户、日期、总额、税额和发票号码，在条目详情界面中供用户复核、编辑，再导出到已连接的财务软件。参见 Dext 提取指南。

如果财务负责人的需求止于一条经过核验的记账记录，那么从这类应用入手，比委托开发一套通用文档系统更切题。这项建议不适用于合同解读，也不适用于任意表单和邮件的流程编排。如果需要选择的是记账应用本身，可以参阅 AI 财务软件对比。

先测字段，再决定信任：如何开展试点？

在允许流程依据提取结果执行操作之前，先评估业务所需字段的正确性。 一份看似转录无误的文档，可能恰好错在最关键的位置：币种、供应商或应付金额。

1. 1

   限定一种文档类型，列清必需字段

   先选一个边界明确的任务，例如把供应商发票转成应付单草稿。列出每个必需字段、它的来源，以及它能授权执行的操作。区分直接提取的值与推导值：文档明确写出的到期日，与根据付款条款计算的到期日，是两种不同的结果。

2. 2

   建立人工核验的答案，留出独立测试集

   收集有代表性的历史文档，涵盖未见过的供应商、质量较差的扫描件、贷项通知单和复杂表格。标准答案是由人工确认的正确答案。对存在歧义或影响重大的标注，应由另一名复核人检查。评估文档要与用于调整提示词或训练提取器的示例分开，同一笔交易中近乎重复的文档也要隔离。

3. 3

   查看结果前，先约定匹配规则

   可以规范化处理前后空格、已知日期格式等无关紧要的差异。金额、账户标识和发票号码不应使用宽松的文本相似度判断。保留币种与小数的实际含义。对明细行，既要检查字段值，也要检查它是否归到了正确的行；金额正确但挂在错误的项目下，依然算错。

4. 4

   用同一批未参与调优的文档测试候选方案

   保存人工修正前的每份原始响应、模型或处理器版本、提示词与 schema 版本、处理失败情况，以及来源引用。无法读取的文件、超时和空提取结果，都要计入实际运行结果，不能悄悄从分母中剔除。

5. 5

   分流异常，以影子模式运行

   让拟采用的流程在现有流程旁并行生成草稿，统计修正次数和复核耗时。只有当某类文档在独立测试集上的结果达到流程负责人预先设定的阈值时，才为这部分文档开启自动接受；影响重大的操作仍须单独审批。

字段、完整记录和静默错误，要分开统计

单一平均值会掩盖错误的位置与后果。评分表应分别列出各字段，以及各类难处理文档的结果。

未出现的可选字段应单独统计，避免大量正确留空的格子虚增表现。如果还要报告召回率，应将其定义为：正确提取的必需值数量，除以全部必需值数量。文档分类和材料包拆分应独立评估；从错误文档中完美提取信息，最终仍是一条失败记录。

**以下只是计算示例，并非产品实测表现：**假设有 200 张发票，每张需要 8 个字段，共计 1,600 个预期值。如果其中 1,590 个值正确，但剩下 10 个错误恰好是不同发票的应付总额，那么只有 190 张发票完全正确。汇总后的字段分数再好看，也不足以批准全部账单。

衡量静默错误，需要抽查流程原本会自动接受的记录，不能只盯着复核队列。试点初期应检查每一条输出；后续即使改用抽样，也要确保样本能代表实际被接受的记录。如果没有任何记录被自动接受，静默错误率就是未定义，而不是完美结果。没有填写任何字段时，精确率也应遵循同样的原则。

智能文档处理的收益，要看实际减少了多少工作

实际运营收益，是获得一条正确记录所需的时间减少了多少。比较人工处理与拟采用流程时，应把整个链路都算进去：文档接收、模型处理、修正、复核、导出和返工。同时跟踪周转时间，以及最久未解决的异常已经积压多久。提取速度很快，队列却越排越长，只说明积压换了个位置，并未消失。

复核界面应向审核人提供来源页面、条件允许时的证据高亮、提取值、未通过的规则，以及写入目标，并记录修正内容和原因。人在回路中的 AI 指南讨论了队列责任归属和升级处理机制；为异常处理指定负责人，本就是流程上线的一部分。

IDP 容易在哪些地方出错？手写、表格与扫描件

试点时，要有意纳入难处理的输入。 只用清晰的电子发票做评估，很难判断系统遇到手机照片、带批注的表单或跨页表格时会怎样。

手写内容应单独设立测试组。 即使产品支持手写识别，被划掉的金额、连笔字和重叠的印章仍可能造成歧义。支持范围还可能因语言而异：Amazon Textract 的文档说明，其手写字符识别仅支持英语。参见 Textract 的限制。对无法确定的手写修改，应转人工复核，不能让它悄悄替换印刷金额。

跨页表格需要检查连续性。 分页可能把一行拆开、重复表头，或引入看起来像明细行的小计。应从整份文档检查行数、跨页延续的描述和总额。Microsoft 的 Layout 指南明确讨论了通过后处理将多个页面合并为一张表。因此，需要测试所选模型及表格拼接逻辑，但这并不意味着每个模型遇到任何跨页表格都会失败。

低质量扫描件需要有重新采集的处理路径。 模糊、边缘裁切和压缩都可能导致信息丢失，而模型无法可靠地恢复这些信息。AWS 建议使用高质量图像，理想情况下至少为 150 DPI，并建议不要对已受支持的文件降采样。参见 Textract 最佳实践。保留原件；证据无法辨认时，要求提供更清晰的副本。

还应测试缺页和多份材料合并在一个文件中的情况。一条记录可能通过所有字段格式检查，却仍然不完整。应保留“缺少证据”这类具体异常原因，不能一概归为处理失败。

哪些说法被夸大了？

“能读文档”不等于“能安全完成交易”。 有三种假设，会导致本可避免的错误。

首先，结构化输出并不是经过核实的输出。即使响应被限定为符合 schema，也无法据此证明提取出的银行账户属于已获批准的供应商。

其次，置信度不是通用的自动接受规则。服务给出的分数、模型自报的确定程度，以及它在你的文档上的实测正确率，是不同的概念。应结合独立测试集结果和错误后果，校准接受规则；不要把模型生成的置信度数字当成测量得出的概率。

第三，保存修正记录不一定会重新训练模型。应利用修正定位失败原因，改进规则、提示词或训练数据，再在推广前重新评估。保留一套回归测试集，也就是一组固定的、已经人工核验的文档，避免对某个供应商的改进，掩盖了对另一个供应商的处理退步。

谁该现在行动，谁该等待，谁该保留现有方案？

当重复性的文档接收工作有明确去向、字段可以核验，且有人负责异常处理时，就可以开始。 对运营负责人来说，下一步是收集有代表性的样本，并列出必需字段。对财务负责人来说，首批输出应当是草稿记录，付款授权仍需单独处理。

开发者应从能够满足需求的最简单提取器入手。 独立技术开发者可以在同一批独立测试样本上，对比托管模型与 LLM 路线。中型企业的技术负责人，则应在流程接入正式业务记录前，要求具备证据链接、明确的复核责任、数据保留规则和可重复的评估。文档中的文字只能作为输入数据，不得用来改写应用指令或权限。

如果没有人能定义正确记录，或负责复核队列，采购就应该暂缓。 已获得融资、但存在这一缺口的创业公司创始人，应先指定流程负责人，再委托开发定制自动化。如果现有模板流程已经能可靠地处理版式稳定的表单，也没有必要仅仅因为视觉模型出现了就换掉它。

下周一就可以先做这些：选定一种文档类型，收集历史样本，与复核人共同写下接受规则，再让拟采用的流程向草稿存放位置输出。只有字段结果和剩余工作量都支持扩展时，才扩大范围。

IDP 常见问题

什么是智能文档处理？

它是一套对文档进行分类、提取信息、校验，并对所得记录或异常进行分流的流程。有用的产出，是经过核验、来源可追溯的数据。

OCR 和智能文档处理有什么区别？

OCR 从图像中读取文字。IDP 还包括将这些文字用于业务所需的分类、字段提取、检查和分流。OCR 可以是其中的一个组件。

智能文档处理软件该选哪一个？

应根据具体任务，以及还留给复核人员多少工作来选择。处理收据和账单，可以先考虑 Dext 这样的记账应用。处理定制化的文档接收流程，则用同一批经过人工核验的文档，评估托管提取器或 LLM 工作流。

IdP 算 AI 吗？

智能文档处理通常会把 AI 用于分类和提取，同时配合常规业务规则。在其他语境中，IdP 指身份提供商，是另一个概念。

有哪些主要的 IDP 厂商？

本文介绍的托管路线包括 Google Document AI、Azure AI Document Intelligence 和 Amazon Textract。这是能力对比，并非市场份额或准确率排名；是否适用，取决于文档和流程。

哪种 AI 最适合处理文档？

最合适的候选，应能在复核工作量可控的前提下，满足必需字段和完整记录的验收标准。某个模型即使很擅长读取少见版式，仍可能需要针对表格和缺失字段增加检查。

有比 ChatGPT 更好的 AI 吗？

对于反复执行的文档接收任务，应将已经实现的完整工作流与现有流程比较，不能只看一次聊天回答。无论选哪种模型，都需要可预期的字段、来源证据、异常处理，以及受控的写入目标。

Document AI 要花多少钱？

Google Document AI 的价格因处理器和处理量而异；请按准备试点的处理器，查看官方定价页面。

Google Docs 会用你的写作内容训练 AI 吗？

对于 Google Workspace，Google 表示，未经许可，不会将客户数据用于客户网域之外的生成式 AI 模型训练。请查看 Workspace AI 隐私政策，确认你的账户和功能适用的规定；Google Docs 与本文讨论的 Document AI 服务是不同的产品。

想了解将 AI 落地到业务流程的实用方法，欢迎订阅邮件通讯。