一、项目背景

某省级国资集团每年流转的采购单据、报销单据、合同附件超过数十万份，过去依赖财务与采购共享中心的十几名审核员逐张肉眼核对。单据类型杂、合规规则多（预算科目、供应商黑白名单、合同条款、发票三单匹配），人工审核平均每张耗时约 3-5 分钟，旺季积压严重，且肉眼易漏，审计抽查发现的漏审率长期在 1.5% 上下浮动。我们当时评估过纯大模型方案，但大模型能"读懂"单据却无法操作业务系统——它既不能从 ERP 拉取历史数据，也不能把审核结论写回流程。于是这个项目里我们采用了 RPA（机器人流程自动化）与大模型协同的架构：RPA 负责"手和脚"，大模型负责"脑"，两者通过一个轻量的 AI 网关编排串联。

二、落地场景

整体链路是一条流水线：RPA 定时从共享邮箱、网盘及 OCR 中间件抓取待审单据，统一转成结构化待审任务；大模型节点完成语义合规审核与关键要素抽取（供应商名称、金额、税号、付款条款、预算科目）；判定结论与抽取结果通过 AI 网关回传给 RPA，由 RPA 执行"写回 ERP 审核字段 / 推送待办 / 挂起转人工"等操作。我们采用的这套 AI 私有化部署底座在本地 GPU 集群上跑推理，单据数据全程不出域，满足国资客户对数据驻留的硬性要求。流程里模型与 RPA 各司其职：模型只产出"建议结论 + 置信度 + 命中规则"，绝不直连写库，所有写操作收敛在 RPA 侧，职责边界清晰。

我们当初也对比过"纯大模型 Agent 直接调 API 写系统"的路线，但考虑到国资客户对操作可追溯、可回滚的强要求，最终拍板让 RPA 做唯一执行通道：模型任何结论想落地，都必须经过 RPA 的二次校验与人工可干预节点。这个取舍让上线第一周就拦下了一批"模型自信但事实有误"的误判，避免了直接写库后难以撤销的尴尬。对账口径也统一收敛到 RPA 侧，财务每月核对时发现差异能直接定位到具体机器人任务号，排查时间从原来的大半天缩短到十分钟级。

三、关键技术挑战与解决思路

挑战一：单据要素抽取与校验

不同来源的单据板式千差万别，OCR 中间件导出的字段经常错位、缺项。我们没有让大模型直接"凭印象"抽取，而是先做字段级 schema 约束，把抽取目标固化成 JSON schema，再要求模型严格按 schema 输出。对于金额、税号这类高敏感字段，叠加一道确定性校验：税号走正则与校验位算法，金额与发票明细做交叉求和，校验失败即降权。配置片段如下：

{
  "fields": ["supplier_name","tax_no","amount","budget_code","pay_term"],
  "constraints": {"amount": "sum(match_invoice_items)","tax_no":"regex+checksum"}
}

实践里这个 schema 约束把要素缺项导致的二次补抽率从约 8% 降至约 2%，相当于每月少返工数千张单据。

挑战二：规则与模型协同判定

纯规则引擎覆盖不了"合同措辞模糊""备注里有隐藏冲突"这类语义问题，纯模型又不可控。我们采用"规则前置、模型兜底、双判融合"的策略：确定性规则（黑白名单、预算超限、三单金额不一致）先跑，命中即直接判拒；规则放行后再交由大模型做语义合规审查，输出风险分与命中的合规条款。最终结论由编排层按权重融合，规则判拒优先级高于模型建议。这样约 70% 的标准单据走规则秒级判定，只有长尾语义类问题才消耗大模型算力，整体推理成本可控。

挑战三：RPA 与模型异常回退

模型推理偶发超时或返回非法 JSON，RPA 若照常回写会污染业务数据。我们在 AI 网关的编排层设了三道防线：模型调用超时（>8s）自动切备用小模型；连续两次解析失败则整单挂起；RPA 侧对每个写回动作做前置幂等校验，避免重复审核。关键路由规则：

fallback:
  primary: qwen-72b-instruct
  backup: qwen-14b-instruct
  timeout_ms: 8000
  on_parse_fail: hold_and_alert

上线后模型侧异常单的自动回退比例稳定在约 0.4%，无一例误写，审计追溯链路完整。

挑战四：人在回路抽检

全自动审核必须留抽检口子。我们设计了置信度分桶：高风险（命中语义疑点）自动转人工；中风险按约 5% 随机抽检；低风险自动通过但留痕。抽检结果回流成难例样本，每周进微调数据池。这样人在回路既兜住了长尾风险，又持续给模型喂真实错例，使下一版模型的语义命中率逐步爬升。

四、效果数据

该项目运行约一个季度后的脱敏示意数据如下：

案例片段（已脱敏）： 一张采购单据被大模型标记"付款条款与框架协议冲突"，置信度 0.63（中风险），触发随机抽检。RPA 日志显示：2024-11-08 14:22:03 [RPA] fetch ticket T20241108-3391 -> [MODEL] risk=0.63, hit=PAY_TERM_CONFLICT -> [GATEWAY] route=hold_for_spotcheck -> [RPA] push to manual queue人工复核确认供应商在备注中把"月结 30 天"改成了"货到即付"，属实质性变更，最终驳回并挂起，回退链路全程未触达 ERP 写库。

五、可复用经验总结

• RPA 管操作、模型管理解：写库、拉数、点页面一律交给 RPA，模型只产出结构化结论，职责边界是这套架构能稳跑的前提。
• 异常一定回退人工：任何模型超时、解析失败、低置信度都要有显式挂起与告警，宁可少自动审一张，不能误写一条。
• 规则与模型分层：确定性规则先跑吃住大头，模型只补语义长尾，算力成本与可控性双优。
• 人在回路要留痕回流：抽检结果必须沉淀为难例，否则模型永远停在初版。
• 对账口径要单一出口：审核结论的写回与对账以 RPA 为准，模型不直接碰账，出了问题能按任务号秒级定位，而不是在模型日志里大海捞针。

结语

单据审核这类"规则多但重复"的场景，恰恰是 RPA 与大模型互补最自然的落点。把操作留给机器人、把判断留给模型、把兜底留给人，三者通过网关编排成闭环，比任何单一技术都更经得起生产考验。