财务共享中心每个月要处理接近三万份单据其中很大一部分是合同扫描件、手写报销单、跨部门传递的审批附件这类非结构化材料。传统RPA能做的只是按规则分拣、命名、归档真正需要理解内容的环节还是得靠人工逐项录入。当时业务提了一个很直接的需求能不能让RPA在流程里直接看懂这些材料把关键字段自动抽出来减少人工录入量。紧跟着又来了一个硬性约束——所有数据不允许出内网更不允许调用公有云上的任何AI接口。换句话说要做成这件事不只是解决一个RPAAI的技术串联问题还要在整个私有化部署的架构下保证数据不出域。项目折腾了几个月上线之后整体稳定中间踩了不少坑今天把方案设计和排障过程整理出来供正在做同类事情的朋友参考。1. 为什么必须私有化数据合规、流程效率与看得懂的诉求这个项目启动的起因其实是一个很典型的业务矛盾流程自动化早就有了但自动化停留在规则执行这一层真正消耗人力的是那些需要人眼去判断、去提取信息的环节。1.1 传统RPA的边界规则到了尽头人就得到场过去的RPA机器人能做的是非常确定的操作登录系统、下载报表、按文件名规则归档、填写固定格式的Excel模板。可一旦输入变成一张模糊的增值税发票扫描件或者一份手写的出差报销单传统RPA就哑火了。它不知道发票代码在哪一行也不知道住宿费和餐费在语义上有什么区别更不用说遇到印章盖住关键数字时如何容错。这些场景在财务流程里占比不低大概有30%到40%的单据需要人工介入而人工介入恰恰是月末结账最大的时间开销。1.2 数据不出域是底线不是一个可以讨价还价的选项最开始也讨论过要不要直接用云端的通用大模型API或者OCR云服务方案评审的时候就被合规部门直接否了。原因很直接单据里有供应商名称、合同金额、银行账号、员工身份证号、手机号这些属于企业内部敏感信息一旦上传第三方服务风险不可控出了问题也难以追溯。类似的限制在很多制造业、金融类企业都存在甚至有些客户明确要求网络物理隔离不给任何公网出口。所以从第一天起技术选型的核心约束就定死了所有数据链路必须在本地闭环模型推理、数据存储、日志审计全部内网完成。1.3 从自动化到智能化要解决的三个问题明确了底线之后业务和技术的目标变得非常清晰就是要让机器人在私有化环境下同时具备三种能力识别能力能从扫描件、照片里提取文字和表格结构解决图像输入的问题。理解能力能根据上下文语义把提取出来的文本归类到正确字段比如区分合同总金额和已付款金额。执行能力理解完之后还能按照业务规则把数据写入ERP、OA完成整条链路。这三件事分别对应OCR、AI模型、RPA执行器。整条链路必须在私有化环境里跑通同时要保证性能稳定、可运维、可审计。2. 整体方案设计解耦RPA、AI服务和知识库的三层架构方案从设计之初就确定了一个原则任何一个环节都可独立替换、独立扩容。RPA不该直接绑定某个具体的AI实现AI服务也不该因为某个业务流程的变更而跟着改代码。所以整体拆成了三层。2.1 三层架构的职责划分第一层是RPA执行层承担流程编排、页面操作、数据回写。我们用的是影刀RPA原因后面讲。第二层是AI服务层统一封装OCR、文本抽取、语义理解等能力对内网提供HTTP接口RPA通过标准API调用不感知底层模型细节。第三层是基础资源层包括GPU推理服务器、向量数据库、对象存储和日志系统。分层的好处在项目中期体现得特别明显。一开始OCR用的是自研的PaddleOCR服务后来换成商业OCR引擎RPA那边的代码几乎没动因为AI服务层对外的接口协议始终是传一张图返回结构化JSON。这就是先用接口约束把边界切开的收益。2.2 关键选型为什么用了这些组件选型阶段拉了一张对比表逐项过了一遍。核心组件选了四类组件类型选型方案选择理由RPA工具影刀RPA中文生态好、社区活跃、支持私有化部署团队上手快OCR引擎PaddleOCR初期→ 商业OCR后期开源自部署成本低但复杂版面精度不稳定后来换商业引擎大模型推理Qwen系列开源模型 vLLM中文能力强、开源可控、vLLM吞吐表现好向量数据库Milvus支持私有化、千万级向量检索性能稳定、有权限管理选型时有一个容易被忽略的点RPA工具必须支持在无人值守模式下稳定运行。有些RPA产品演示时很漂亮但一跑长任务就崩无人值守场景下没人盯着重启这是灾难。影刀当时打动我们的一点是调度能力比较成熟支持失败重跑和队列管理这在财务月末批量处理场景里几乎是刚需。2.3 数据链路从单据进入系统到结果回写整条链路的时序是这样的RPA机器人定时扫描共享文件夹发现新增扫描件。机器人把扫描件传给AI服务层请求OCR识别和字段抽取。AI服务层返回结构化JSON包括发票号、金额、日期、供应商等字段。RPA根据置信度做分流置信度高的直接写入ERP草稿单置信度低的转入人工复核队列。所有请求和响应记录写入审计日志图片文件加密存储。一个关键设计是置信度分流。不是所有单据都能被AI完美识别与其让AI硬着头皮给一个可能错误的结果不如设定阈值低置信度的单据转人工。这个机制救了项目很多次因为业务部门对错误数据的容忍度是零但对机器处理不了转人工接受度很高。3. 踩坑实录从模型部署到RPA调用的四大深坑方案设计得再漂亮落地的时候坑还是一个接一个。挑四个最典型的记录一下每个都花了不止一天的时间处理。3.1 GPU算力估算失误并发一上来就OOM第一个坑是压测阶段暴露的。开发环境只有一张A100单线程调用模型跑得很流畅我以为生产环境上两张卡就够了。结果生产环境刚上线财务月末批量处理RPA开了8个并发任务同时调用AI服务GPU显存直接被打满进程OOM重启一堆单据卡在中间状态。排查过程很痛苦。一开始以为是代码有内存泄漏查了半天发现是并发估算的问题。单张A100跑量化后的模型单个请求峰值显存约6GB一张卡全速跑大约能扛3个并发。生产环境只有一张A1008个并发任务显然超了。解决思路分三步加并发控制AI服务层增加请求队列和信号量限流最大并发数设置为2多余的请求排队等待。模型量化从FP16切到INT4量化单请求显存占用降到2.5GB左右吞吐量还提升了一些。RPA侧调整把8并发降为4并发每个任务等待AI响应的时间拉长但整体吞吐没有明显下降因为瓶颈是GPU算力而不是RPA线程数。这个坑的本质是开发环境单请求验证和生产环境多并发之间的巨大差异。建议任何人在做容量规划时一定要拿生产环境真实的请求大小和并发数做压测不要拿样例数据估。3.2 OCR精度翻车低分辨率扫描件、盖章遮挡与手写体OCR是另一个大坑。PaddleOCR在标准打印体文档上表现很好但真实的财务单据远比标准文档复杂低分辨率扫描件有些分公司用的老式扫描仪扫出来的发票分辨率只有100dpi文字边缘发虚识别率惨不忍睹。盖章遮挡发票上盖了红色公章恰好盖住发票号码的关键数字识别出来是乱的。手写体报销单上的手写签名、手写金额普通的印刷体OCR模型根本处理不了。针对这几个问题我们做了一层图像预处理再进OCR流程超分辨率重建用一个小模型对低分辨率区域做增强把100dpi的图像提升到200dpi的效果。印章检测和去除先用目标检测模型定位红色印章区域提取红色通道信息并移除再做文字识别。这个策略对红章遮挡场景效果明显。手写金额单独走一个手写识别模型识别结果和阿拉伯数字比对不一致时转人工复核。调完以后打印体发票关键字段的识别准确率从92%提升到98.5%手写体的准确率从不到80%提升到90%左右。这个阶段最大的心得是OCR不是单点问题预处理、检测、识别、后校验每一步都可能放大或缩小最终错误率别指望一个模型解决所有格式。3.3 RPA与AI服务的同步调用超时、重试和幂等性第三个坑出在接口交互层听上去是小事实际坑惨了。AI服务对大文档处理耗时不稳定短则3秒长则30秒。RPA默认的HTTP请求超时时间是10秒于是经常出现RPA那边已经报错AI服务这边还在跑再重试就产生重复请求。解决这个问题我们把同步调用改成了异步任务模式RPA提交识别任务到AI服务服务返回一个task_id。RPA轮询查询任务状态状态为成功或失败时退出轮询。AI服务内部做幂等处理同一个task_id只处理一次重复提交直接返回已缓存的结果。处理完响应后RPA进入轮询等待模式彻底解决了同步等待超时的问题。同时AI服务加了Redis缓存相同图片重复提交直接命中缓存省了不少算力。这个调整看似多写了一个异步循环实际上省掉了大量超时重试导致的资源浪费。3.4 私有化知识库的召回质量chunk切分、向量化和混合检索项目后期给AI服务加了一个私有化知识库存放财务制度文档、发票模板说明、历史审核规则目的是让大模型在抽取字段时能参考企业内部规范。第一次上线效果很差模型回答经常引用不相关的文档段落抽取的字段反而变得更不稳定。逐个排查下来问题出在两个地方chunk切分太粗暴。最初的实现是按固定长度512字切分把完整的条款、表格切断语义不完整向量召回的时候匹配到的都是残片。后来改成按章节标题和段落语义切分chunk大小控制在256到512个token之间同时保留10%的重叠度召回准确率明显上升。仅靠向量召回的局限。企业内部文档里很多关键词比较罕见比如特定系统名称、部门缩写向量化之后很难匹配准确。改成了混合检索方案先做BM25关键词召回再做向量召回两路结果融合后统一打分排序。效果从偶尔能查到相关制度变成了稳定命中对应条款。4. 数据不出域的四道防线网络、存储、权限与审计数据不出域不能停留在口号上要落到技术实现上。我把它拆成四道防线每一道都花了专门的精力去落实。4.1 网络隔离让数据没有出口最根本的一层是网络。AI服务、OCR引擎、向量数据库全部部署在内网不配置公网IP出口方向通过防火墙策略禁止访问互联网。这等于从物理逻辑上掐断了数据出域的可能。RPA机器人运行在指定的内网终端同样不允许访问外网。网络层面还做了端口白名单业务系统之间的通信只开放明确需要的端口。4.2 数据存储加密与本地化所有涉及单据的数据都存储在企业自建的对象存储里包括原始扫描件、OCR中间结果、AI返回的结构化数据。存储启用加密密钥由企业内部密钥管理系统统一托管。向量数据库中的文档向量也存在内网除了内网服务账号外部无法访问。数据传输方面全程走内网HTTP双向证书认证没有走公网DNS解析所有东西都在内网域名内闭环。4.3 权限控制最小权限原则系统里的每个角色能访问的数据范围严格收敛。RPA机器人只有访问共享扫描文件夹和ERP草稿写入的权限没有权限去查看历史归档。AI服务账号只能访问数据存储里指定目录的图片和文档不能跨目录访问。审计日志单独存放在独立的日志系统只有审计员有权限读取RPA管理员也无法修改日志防止内鬼篡改记录。4.4 审计日志每一步都留下痕迹所有关键操作都记录了审计日志包括文件访问记录、AI服务调用记录、结果回写记录、人工复核操作记录。日志格式统一包含操作人、操作时间、操作对象、操作类型和IP来源。有了这套审计体系任何一个单据都能从进入系统追溯到谁处理过它。这对于财务场景尤为重要因为很多审计问题需要回答为什么这个发票被自动录入了。需要注意的是日志不只是给合规看的也是后期排查问题的核心手段。遇到AI产生误判的情况完整的日志链路能快速定位是OCR错了、模型错了、还是数据源本身有问题。5. 上线后的实际效果与后续扩展系统上线运行了三个完整账期效果比预期的要实在。5.1 效果数据效率提升和人工介入率指标上线前上线后单张发票平均处理时间8分钟人工录入45秒RPAAI自动月末批量单据处理周期3个工作日1.5个工作日人工介入率100%约12%关键字段抽取准确率-98.5%打印体效率提升是一方面更重要的是月末结账的压力降下来了。财务团队在高峰期不再需要加两个周末的班可以把人力投到异常单据的复核和业务沟通上。5.2 运维注意事项模型更新、监控与备份私有化部署的AI服务运维方式和传统RPA完全不同。模型更新要重新走测试、灰度发布流程不是热更一个配置文件就能搞定。我们的做法是新模型先在测试环境跑一个账期的历史数据准确率不低于当前模型才允许替换。同时GPU服务做了监控告警显存使用率、平均响应时间、队列积压数超过阈值就触发钉钉告警。向量数据库每天备份一次防止数据损坏。5.3 后续扩展从字段抽取到AI Agent目前这个方案能稳定运行离不开RPA做执行、AI做理解的分工。下一步想把范围扩大做一个更偏AI Agent的尝试让AI不仅抽取字段还能根据抽取结果做判断和决策比如判断发票重复报销、合同金额异常波动。RPA在这里的角色继续下沉为手脚AI Agent负责大脑的调度和决策。这个方向上我认为重点是处理好Agent的自主性边界。私有化环境下的AI Agent必须严格限制在预设的流程节点内做决策所有决策结果留痕关键操作仍然要人复核。扶持它当助手可以暂时还不能让它完全自主操作业务系统。做技术方案尤其是涉及私有化部署和数据安全的时候有一件事比技术细节更重要——从一开始就把数据边界、权限边界、审计边界想清楚。技术选型可以换架构可以调但数据治理的框架动了就会牵扯大量合规和信任问题。我在这个项目里最大的体会是RPAAI的私有化落地真正的难点不在模型精度也不在RPA脚本而在如何让所有参与者业务、合规、运维都清楚地知道数据在哪、谁碰过、结果可不可信。把这些基准线立住了后面的智能化扩展才有底气。