UiPath 文档理解（Document Understanding）实战：发票与单据抽取的工程要点

很多企业上 RPA，最先卡住的不是流程建模，而是单据。采购单、发票、报关单、合同，版式五花八门，字段位置一年一变。用固定坐标去抓，机器人上线三个月就开始天天改；用纯 OCR 转文本，转出来的文字没有结构，下游系统还是接不进去。

UiPath 的文档理解（Document Understanding，下文简称 DU）就是冲着这一类问题去的：把非结构化的单据变成带字段名的结构化数据，再喂给后面的自动化流程。这一篇把它的工程要点讲清楚，不讲营销话术，只讲落地时要决定的几件事。如果你已经在用 UiPath，或者正在评估它能不能处理你们的单据，这篇按你的视角写。

一、先判断：哪些单据值得上文档理解

不是所有单据都该上 DU。先用一个简单标准筛一遍：版式是否固定、字段是否稳定。

单据类型	版式特征	建议做法
系统导出的固定模板报表	列位、字段名几乎不变	正则或模板提取器就够，不必上机器学习
同一供应商的发票	季度级版式微调	模板提取器能撑一阵，但要预留改版成本
多家供应商的自由格式发票	版式各异、字段顺序不固定	上机器学习提取器，靠样本训练
扫描件、拍照件、套打单据	有噪声、有印章遮挡	先做 OCR 质量评估，再决定抽取方案

一个常被忽略的判断：要看单据是不是"同一来源多种版式"。如果是同一家 ERP 导出的，往往字段语义稳定，只是排版不同，机器学习提取器迁移成本低。如果是从不同供应商收来的，那就要准备足够的样本覆盖。样本不够，模型在验收时好看，上线后容易掉。

我们在《UiPath 自动化工程化实战》那篇里强调过：稳定化的核心是"可预期"。单据处理和选择器一样，真正要防的是版式漂移。把 DU 当成一条需要监控的流程来设计，比把它当成一次性的识别任务要稳妥得多。

二、文档理解的四步骨架

无论用哪种抽取器，DU 的流程骨架基本是四步：分类、抽取、校验、训练。每一步都能单独调参，也单独出问题。

步骤一：分类（Classification）

进来的单据要先知道"这是什么"。是发票还是采购单，是哪家供应商的。分类错了，后面抽什么字段都错。分类可以用关键字规则，也可以用分类模型。多来源、多类型的单据，靠规则容易漏，用模型更稳，但也要准备分类样本。

步骤二：抽取（Data Extraction）

这是核心。系统按字段定义去取数：发票号、金额、税额、供应商名称、行项目。抽取得准不准，取决于两件事：抽取器选得对不对，以及字段定义写得细不细。字段定义（Taxonomy）里要写清别名、格式和取值范围，比如"金额"在不同单据里可能叫"价税合计""合计金额""Amount"，都要列进去。

步骤三：校验（Validation）

低置信度的字段交人工确认。这一步通常落在 Validation Station 或 Action Center 上，让人对着原图和系统识别结果做修正。校验不是"兜底补丁"，而是数据质量的主闸门：没有它，错误字段会直接进下游，比机器人卡住更难发现。

步骤四：训练（Training）

人工校验后的结果可以回流成训练样本，让模型下一轮更准。这一步决定了系统是越用越聪明还是越用越歪。回流要有纪律：只把校验通过、业务确认过的样本喂回去，脏样本回流会污染模型。

三、抽取器怎么选：模板、正则还是机器学习

这是落地时首先要拍板的。UiPath 提供几类提取器，差异不在"谁更强"，在"适合什么"。

提取器	适合场景	维护成本
模板提取器（Form Extractor）	版式固定、字段位置稳定	版式一改就要重画锚点
正则提取器（Regex-Based）	字段有固定模式，如统一社会信用代码	规则好写，跨版式容易失效
机器学习提取器（ML Extractor）	版式不固定、多家来源	靠样本，需准备训练与评估集
大模型提取器	语义复杂、需要理解上下文	取决于模型供给与数据出域要求

选型的一个经验：能用模板解决的，别急着上模型。模板的可解释性强，字段为什么错一眼能看出来，商务上也好向审计交代。只有当版式真的不可控，才上机器学习提取器，并准备对应的样本库。

数据出域是另一条硬约束。涉及个人身份信息或商业敏感的单据，优先考虑自托管模型，让上下文和模型都在内网处理。公有云方案在识别效果上往往更快拿到新能力，但数据流向要写进评估清单，由安全与合规一起确认。具体支持方式与版本以厂商官方文档为准。

四、置信度阈值与人工校验站的配合

很多人把"置信度"当成一个可以随便设的数字。实际要分字段看。

金额、税额这类决定钱和税的字段，阈值要设高，宁可多交人确认，也不要让一个错数字进总账。供应商名称、日期这类字段，阈值可以放低，错了也容易在对账时发现。

阈值的设定要跟着校验站的能力走。如果你们有人工校验的人力，阈值可以激进一点，让系统多交一些 borderline 的字段给人；如果没有人力，阈值要保守，先把高把握的字段自动过，剩下的整单转人工。这里没有标准答案，取决于你们每天进来的单据量和复核人手。

一个容易踩的坑：把整体置信度当验收指标。一张单整体 0.9，可能金额那一项只有 0.6。验收要看字段级，尤其是决定业务动作的几个关键字段，不能看平均数。

五、表格与多页单据

行项目（line items）是发票抽取里最麻烦的部分。一张发票可能十几行，列还对不齐，跨页还断行。

处理表格时，先确认提取器对你们这类表格的支持程度，再用真实样本测。跨页断行、合并单元格、小计与合计混排，都是常见的失效点。验收阶段要专门准备带长表格、带跨页的单据，不要只用单页样本。

多页单据还要先定"分页逻辑"：哪几页属于同一张单，附件算不算正文。这个逻辑不清，抽取会把不同单的字段混到一起，错误更难排查。

六、中文单据的特殊处理

中文场景有几个坑，英文文档里很少提，但实际很常见。

• 印章覆盖关键字段。红色公章压在金额或账号上，OCR 容易把印油当成笔画。先做印章检测与去噪，或要求上游提供无章版。
• 竖排与混合排版。部分老式单据、合同抬头有竖排文字，通用 OCR 的方向识别要单独验证。
• 套打与多层单据。一页纸上多联、多框，字段边界靠人眼经验，机器容易串格。这类要画清字段区域，必要时拆分处理。
• 手写批注混排。审批人手写的金额、备注，和印刷体混在一起。要不要识别手写，要和业务流程确认，不是技术上能识别就要识别。

这些问题的共同点是：不能靠厂商的 demo 集下结论。demo 用的是干净样本。验收一定要用自己的、带噪声的、最近半年的真实单据，按单据类型分开统计召回和字符准确率。

七、把它当成一条要监控的流程

DU 上线不是终点。版式会变，供应商会增加，模型会漂移。要像监控 RPA 流程一样监控它：

1. 盯字段级召回，不盯整体准确率。关键字段的召回率一旦下滑，说明版式或来源变了，要回去看样本。
2. 盯人工复核率。复核率突然升高，往往是某类新单据进来，模型没见过。这是加样本的信号。
3. 保留原图与识别结果。出错了要能回放：哪张单、哪个字段、系统识成什么、人改成什么。没有这条链，排查只能靠猜。
4. 回流有纪律。只回流校验通过、业务确认的样本，定期清理脏样本，避免模型被带偏。

这几点和工程化那篇的思路一致：自动化能不能规模推广，不靠它上线时多亮眼，靠它漂移时能不能被及时发现和修回来。

八、上线后的四把尺子

验收和日常运营都用同一组指标，别换口径。

指标	含义	说明
字段级召回	该抽出的字段抽出了多少	按单据类型分开统计，关键字段单独看
首过率	不用人工介入就走完的单据比例	反映自动化真正接住了多少量
人工复核率	需要人确认的单据比例	突然升高往往是新来源或版式漂移
单笔处理成本	含模型调用与人工复核的每单成本	判断是否值得继续扩量的核心

这四把尺子里，我建议把首过率当主指标。它同时反映了模型能力和校验阈值设得合不合理：太低要么模型没训好，要么阈值太松导致大量 borderline 字段被自动放过（或太紧导致全交人工）。单笔处理成本放第二位，它决定这个方案能不能从试点扩到全量。

九、三个反复出现的误区

误区一：认为 DU 能完全替代人工录入。对版式可控、字段标准的单据，自动率可以很高；对自由格式、带噪声的，人工校验站仍是主闸门。把"可替代"当"已替代"，上线后会反复救火。

误区二：只拿干净样本做验收。demo 集和真实单据是两回事。验收要用带噪声、带印章、带跨页的真实样本，按类型分开统计，别信一个总体准确率。

误区三：把 OCR 当文档理解。OCR 解决"图上有字"，文档理解解决"哪个字是哪个字段"。没有字段定义和校验，转出来的文本下游还是接不进去。两者是上下游关系，不是替代关系。

结语

文档理解不是把单据"读出来"就完事。它真正的工程价值在于：把非结构化输入变成可信的结构化数据，并且让这个过程可监控、可回流、可审计。选型上，固定版式别硬上模型，自由版式别舍不得上模型；运营上，置信度要分字段设，验收要看字段级，复核率要当警报看。

最后提醒一句：文中涉及的提取器类型、自托管能力与版本支持变化较快，具体功能、计价与数据出域要求以 UiPath 官方文档、合同条款与你们自有环境的测试结果为准。准备 PoC 时，建议直接带上最近半年的真实单据，按上述四把尺子验收。