私有化RPA+AI落地实践：数据不出域与踩坑经验

前阵子客户抛过来一个需求，一句话就把我们堵死了：这套自动化方案做可以，但所有数据必须留在内网，连一张截图都不能传出去。客户是做金融业务的，用户资料、流水、信贷材料全是敏感数据，合规部门在项目启动前直接划了红线——数据不出域。原先他们想过直接用云端的RPA平台和AI识别接口，毕竟上手快、效果也不错，但合规评估阶段就被毙了。于是我们只能从零搭一套私有化部署的 RPA+AI 体系，把流程机器人、OCR识别、大模型问答全部搬进客户机房。整个项目从POC到落地用了三个多月，踩了一堆文档里根本查不到的坑。这篇文章就是把这套方案的完整落地过程、关键配置和踩坑经验整理出来，给同样准备做私有化自动化的团队做个参考。

如果你是RPA工程师、AI实施人员，或者正在帮金融、政务、医疗这类管控严的行业做降本增效，这篇文章应该能帮你少走不少弯路。我会把需求背景、架构选型、组件配置、数据安全落点以及真实遇到的故障和排查过程都写出来，偏实操，尽量不废话。

1. 需求解析：为什么"数据不出域"成了自动化的硬门槛

1.1 合规压力不是闹着玩的

先说客户的真实处境。这家金融机构每天要处理大量客户开户材料、信贷审批附件和发票凭证，很多文件里直接包含身份证号、手机号、家庭住址这些敏感个人信息。按照监管要求，这些数据必须存储在境内且受控区域内，未经授权不得向外部传输。也就是说，哪怕只是把一张带客户信息的图片传到云端做一次OCR识别，也属于"数据出境"，在合规上是过不了关的。

我们最开始也试着说服客户：云端RPA不是能配置SLAT和隐私协议吗？数据传到云端后加密存储，是不是可以接受？但合规部门的回复很干脆：只要有"出域"这个动作，不管后面加密不加密，就是不行的。所以项目的第一条原则就定了：所有采集、处理、存储环节，都必须发生在客户自己的网络环境里。

1.2 云端方案与私有化方案的关键权衡

既然云端方案被否，那是不是就直接拍板私有化？其实也不是。我们在前期做了一个相对完整的对比，把两种方案在几个核心维度上的差异列了出来，最后才围绕"数据不出域"这个最高优先级去倒推决策。

对这家客户来说，合规权重远高于成本，所以私有化是没有悬念的。但我也要提醒一句：如果你所在行业没有这么强的监管压力，业务数据也不太敏感，云方案的成本和便捷性确实是巨大优势，不必为了"私有化"而私有化，两种路线各有适用场景。

1.3 方案边界：哪些环节必须私有，哪些可以保留外部能力

这里要特别说明一个容易做过头的地方：很多团队一上来就想把所有的AI能力都私有化，什么OCR、自然语言处理、大模型全都要内网跑一套。但实际上，并不是所有环节都会碰到敏感数据。比如一些公开资料的爬取整理、脱敏后的统计报表分析，这类场景如果硬要私有化，反而浪费GPU资源和维护成本。

我们当时和客户定了一个边界：凡是可能接触原始敏感数据的环节，必须是私有化；凡是只处理脱敏后数据或公开信息的环节，可以沿用成熟的外部工具。这个边界画清楚之后，整个方案的规模和预算就压缩了不少。所以做这类项目时，与其一开始就追求"全私有"，不如先做数据分级，再决定哪些能力该布局在内网。

2. 整体架构设计：一套跑在客户内网的自动化中枢

2.1 三层架构：控制层、执行层、AI能力层

整个私有化RPA+AI系统，我们的设计思路是拆成三个逻辑层：控制层、执行层、AI能力层。控制层负责流程编排、任务调度、权限管理和监控告警；执行层是跑在各台PC或服务器上的机器人客户端，按控制台下发的指令去操作各类业务系统；AI能力层则是独立的模型推理集群，提供OCR识别、表格抽取、大模型问答、向量检索等原子能力。

为什么要把AI能力单独拆一层，而不是直接嵌进RPA机器人里？原因有两个。第一，RPA机器人往往分布在不同的机器上，如果每台机器都装一套AI模型，资源利用率会很低，而且模型更新时还得逐台升级维护；把AI能力集中部署成服务，机器人通过统一接口去调用，模型更新只需在服务端发布一次。第二，AI能力层集中放之后，可以统一做权限控制、日志审计和数据脱敏策略，这正好呼应客户"数据不出域"的要求——所有数据交互都被限定在这一层可控的调用链里。

2.2 网络分区与安全边界设计

在私有化项目里，网络规划直接决定后续的安全性和稳定性。我们把客户机房划分成三个网络区域：管理区、执行区、数据区。管理区部署RPA控制台和运维跳板机，执行区部署各业务线的机器人实例，数据区部署数据库、AI推理服务器和文件归档存储。

区域之间的访问关系是严格受限的：机器人要访问数据区，不能直连数据库，只能通过数据区封装的API服务接口去读写；控制台和执行区之间也走专用的内部通道，其他端口一律不开放。这样做的好处是，即使某台机器人被攻破，攻击者也只能触达该机器人本身能访问的有限接口，无法横向移动到整个数据区。客户的安全团队当时加了不少ACL规则，虽然一度给我们调试带来了麻烦（后面会写），但从最终审计角度看，这个网络隔离设计是过关的。

2.3 AI能力的私有化选型

AI能力层是整个方案的亮点，也是最容易出问题的地方。OCR我们选的是PaddleOCR系列，准确率高、中文支持好，而且可以离线部署、商用不受限。对于发票、合同这类带版面的文档，单靠OCR检测文字还不够，还需要版面分析和表格结构还原，我们对照使用了PP-StructureV2，识别结果基本能满足后道字段抽取的需要。

语义理解这块，客户需要一个知识库问答能力和一个文本抽取能力，我们就直接上了可私有化部署的中文大模型。当时在Qwen和ChatGLM两个系列里选了Qwen，主要看中它的工具调用能力和中文指令遵循效果。推理部署用的是vLLM框架，支持continuous batching，并发效率明显优于原生transformers。向量检索用的Qdrant，轻量，性能也够用，部署在Docker里非常省事。

2.4 高可用设计：不能因为一台机器挂掉让全流程停摆

自动化的一个讽刺之处在于：人手工处理时，出点小问题还能灵活应对；一旦上了机器人，任何单点故障都可能让整条流程卡死。所以我们从设计之初就把高可用纳入了范围。控制台部署成双节点，通过共享数据库实现任务状态同步，一个节点发生故障，另一个节点能接住任务重启调度。执行区的机器人则按业务量做了多实例冗余，比如发票处理流程同时部署了3个机器人实例，由控制台统一分配任务。

AI推理这块，GPU服务器暂时只有一台，但我们用vLLM做了单机多实例部署，并配置了负载均衡，即使一个推理实例崩溃，另一个还能承接后续请求。数据层的Redis做主从，MySQL做了双机热备。这套高可用配置谈不上多豪华，但至少能做到"单点故障不中断核心流程"。

3. 核心组件选型与参数配置

3.1 RPA引擎选型：商业版还是开源版

RPA引擎是项目的基础底座。市场上可以选商业RPA，比如影刀、金智维、UiBot这些，优势是组件封装完整、报错提示友好、有技术支持；也可以选开源方案，比如由RPA框架改出来的自动化工具、n8n这类工作流引擎，优势是成本低、可深度二次开发。

考虑到客户要求严格的审计和售后支持，我们最终选了商业RPA产品。很多人会觉得RPA不就是一个"录屏回放"工具吗？其实不然。企业级RPA平台的价值在于：控制台可以统一管理几百个机器人的调度，所有操作形成审计日志，流程版本可以追溯回滚。这些能力在一个人用的时候无所谓，但放到合规场景下就是硬需求。商业产品功能到底更完善，出了问题也找得到人。

3.2 大模型和OCR的私有化部署要点

大模型部署是这次项目里参数要求最细的部分。客户选择的模型尺寸是7B级别，具体是Qwen2.5-7B-Instruct。为什么选7B而不是更大的13B或72B？一个原因是客户只有一台GPU服务器，四个核心业务要共用算力；另一个原因是7B模型配合量化后，7B模型在单卡16GB显存的A10上就能跑起来，部署门槛低、延迟可控。如果想追求更高准确率，13B甚至70B当然会更强，但需要更充足的GPU资源，硬件成本会成倍增长。

vLLM启动我们大致用的是这样的参数配置：

python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen \ --host 0.0.0.0 \ --port 8000 \ --dtype float16 \ --gpu-memory-utilization 0.92 \ --max-model-len 8192

显存利用率设到0.92，是为了尽量把KV cache留足，避免长文档处理时因为上下文太长而频繁触发recompute。max-model-len设8192，对于大多数业务文档已经够了。并发方面，vLLM的continuous batching能动态调度请求，我们实测单卡可以稳定支持8路并发，单次生成500个token左右的响应，平均延迟在2到4秒之间。

OCR部署就轻量一些。PaddleOCR本身是Python框架，也可以用Paddle Serving封装成HTTP接口。我们采用了服务化部署，方便RPA机器人统一调用，同时把识别请求排队管理起来，防止突发任务打爆服务。模型选用的PP-OCRv4中文模型加表格结构识别模型，识别精度在实际业务单据上达到了95%以上。

3.3 向量数据库与知识库配置

知识库问答功能需要一套完整的"文档入库-向量化-检索-生成"链路。文档进来后先切分成小块，然后调BERT类中文嵌入模型生成向量，再写入向量数据库。我们选的嵌入模型是BAAI/bge-m3，在中文语义匹配上表现稳，模型体量也不算大。向量库用Qdrant，以Docker方式部署：

docker run -d --name qdrant \ -p 6333:6333 \ -v /data/qdrant:/qdrant/storage \ qdrant/qdrant

Qdrant的检索性能在百万级向量规模下依然能保持在几十毫秒级别，客户现阶段数据量也就几十万条切片，完全够用了。入库流程用Python脚本把PDF、Word、Excel统一解析成文本，再按固定步长切块并保留段落标题作为上下文信息，检索的时候用混合检索（向量召回+关键词过滤）来提升准确率。

3.4 硬件资源规划清单

给一份我们当时规划的参考配置，方便读者对照评估：

这套配置下来，硬件成本大概在十几万元量级，和云服务按年的费用比起来确实不便宜，但考虑到数据资产的安全价值，客户认为是划算的。如果你的数据量更大、并发更高，GPU服务器需要扩容到多卡，执行机也要按场景增配。

4. 数据不出域的落地保障：从流程设计到审计闭环

4.1 数据全生命周期的管控思路

"数据不出域"不是靠某一台防火墙就能实现的，关键要看数据在每个环节的流向。我们把整个生命周期分成采集、传输、处理、存储、销毁五个阶段，每个阶段都明确约束。采集阶段，机器人只读取业务系统授权范围内的数据，超出范围直接跳过并记录异常；传输阶段，数据只在客户内网通过内部API流转，不经过任何公网出口；处理阶段，AI服务在隔离网络内完成推理，日志中不记录原始报文；存储阶段，原始文件落到客户指定的归档存储，按保留策略自动执行清理；销毁阶段，超过效期的敏感数据由定时任务物理删除并生成销毁证明。

4.2 一个典型流程的数据流拆解

拿"发票识别与费用自动入账"这个场景来举例。原流程是财务每天从报销系统下载电子发票，人工核对发票真伪、提取金额和供应商信息，再录入财务系统。私有化改造后，流程变成：

1. 机器人定时登录报销系统，把待处理的发票PDF下载到内网指定目录；
2. 机器人调用OCR服务对PDF进行识别，提取发票号码、金额、日期、销售方等信息；
3. OCR结果传给大模型做字段归一化校验，剔除明显识别错误；
4. 机器人把结构化结果回填到财务，系统完成自动入账；
5. 原始PDF和识别结果按日期归入归档库，保留90天后自动清理。

这个链路里，所有的数据都只在客户内网的三个区域之间流转，没有一次出网请求。这一点在项目汇报时，客户安全团队是认的。

4.3 敏感数据脱敏与动态替换

即使数据不出域，我们也建议在日志和展示层做脱敏处理。比如发票里的销售方税号、客户电话、开户行账号等字段，在系统中显示时只保留前几位和后几位，中间用星号替代。RPA机器人运行过程中，控制台录制的屏幕截图也会包含业务信息，我们在配置里直接关闭了截图上传功能，或者截图后立即在本地加密存储，而不是上报到控制台，避免敏感信息在管理端二次暴露。

大模型的输入输出也要做约束。我们在Prompt层加了严格指令，要求模型只输出结构化字段，不输出任何原文解释；同时在代码层对模型输入做过滤，如果检测到身份证号、银行卡号这类数据出现在请求中，会先做掩码替换再送模型推理，这样即使模型日志被审计，也无法还原完整信息。做法不算复杂，但很有效。

4.4 审计与追溯闭环

私有化环境里，审计能力直接决定项目是否能让合规部门拍板。我们用RPA控制台自带的操作日志，记录了每个机器人什么时间、在哪台机器上、调用了哪些流程、处理了哪些文件，配合API层的请求日志，可以完整还原某一条数据的处理轨迹。另外，我们专门开发了一个审计报表模块，每周自动生成数据访问统计、异常操作告警、模型调用量概览，发给客户的安全管理团队。

这里有个容易忽略的点：审计日志本身也包含敏感信息。如果日志以明文保存，那再严格的流程也会在"记录"这个环节泄露数据。所以我们对日志内容也做了脱敏和加密存储，查询时校验操作人权限，确保只有授权管理员能访问。

4.5 模型微调与训练数据隔离

客户后续想提高模型对自身业务文档的理解能力，提出用内部的历史文档做一次微调。这块我们特别谨慎，因为微调训练数据里的敏感信息量非常大。方案是准备了一个"训练数据加工流水线"，先把原始文档接入内部解析服务，识别出敏感字段后统一替换成虚拟占位符；再将加工后的纯文本数据送入训练环境，全程不经过任何外部工具。训练完成后，模型权重直接存入客户内网模型仓库，调用方不再保留训练样本副本。

这样一圈下来，"数据不出域"不再是一条口号，而是落到了流程里每一个可审计的步骤上。

5. 实操过程：从POC到上线的完整环节

5.1 先选一个能快速见效的业务场景

POC阶段我们没着急铺开，而是先选了一个业务痛点最突出、ROI最容易量化的场景来验证方案：发票识别与费用自动入账。客户的财务团队每天要处理大约300张报销发票，手工模式下每张发票从下载、识别、核对到入账需要3到5分钟，遇到发票模糊或者供应商名称不规范的情况，耗时会翻倍。这个场景数据敏感度高、流程标准、人工痛点清晰，非常适合作为智能自动化的首个试点。

我们当时定了一个POC验收目标：机器人代替90%的人工操作，单张发票平均处理时间压缩到30秒以内，字段识别准确率达到95%以上，且全程无外部网络交互。目标量化后，后面所有开发和验收都更有方向。

5.2 流程拆解与分支规则设计

把财务的人工操作一步步拆开后，我们形成了流程图式的规则描述：

• 定时任务每天早上9点触发，机器人从报销系统拉取前一日新增的发票列表；
• 对每一张发票PDF，先做格式校验：能解析出"发票号码"则继续，否则进入异常队列；
• 调用OCR识别全部文本后，用正则表达式预处理，抽取"发票号码、开票日期、金额、销售方"关键字段；
• 调用大模型做字段规整，返回统一JSON结构；
• 回到财务系统填写报销单，附件关联原始PDF；
• 如任何环节校验失败，机器人不做强制处理，而是转人工复核队列。

值得强调的是，自动化的边界要清晰。当时我们定的原则是：异常单据不强行推进，必须交给人工确认。这样既保证了自动化率，又不会因为个别脏数据导致一条错误单据入账。

5.3 RPA调用AI服务的代码示例

由于RPA产品本身支持Python扩展，我们把AI服务调用封装成了一个Python工具模块，机器人流程中通过"执行Python脚本"组件来调用。核心调用代码如下：

import requests import json def ocr_invoice(pdf_path: str) -> dict: api_url = "http://192.168.10.20:8080/invoice/ocr" with open(pdf_path, "rb") as f: resp = requests.post(api_url, files={"file": f}, timeout=30) resp.raise_for_status() return resp.json() def extract_fields(ocr_text: str) -> dict: api_url = "http://192.168.10.20:8000/v1/chat/completions" prompt = f"""你是财务发票字段抽取助手。请从下面的OCR文本中抽取字段，只输出JSON： {{ "invoice_no": "发票号码", "invoice_date": "开票日期(YYYY-MM-DD)", "amount": "金额(数字)", "seller": "销售方名称" }} OCR文本： {ocr_text[:2000]} """ payload = { "model": "qwen", "messages": [{"role": "user", "content": prompt}], "temperature": 0.1, "max_tokens": 256 } resp = requests.post(api_url, json=payload, timeout=30) data = resp.json() return json.loads(data["choices"][0]["message"]["content"])

这里有两个细节：OCR超时我们设了30秒，防止单个文件卡死整个队列；传递大模型的内容截取了前2000个字符，避免超出模型上下文限制。在机器人流程里，我们还会对返回的金额字段做一次正则校验，确保它是两位小数的数字格式，防止大模型输出"12,300元"这种不能被系统直接识别的结果。

5.4 上线前的Smoke Test：把核心链路跑透

我们参考了社区里提到的"smoke test"思想，没有一上来就直接全量跑，而是先做冒烟测试。冒烟测试范围包括：

• 定时任务能否正常触发；
• 下载发票文件是否能成功；
• OCR服务能否在限定时间内返回结果；
• 大模型抽取的字段能否通过规则校验；
• 异常队列的消息通知是否能正常发出。

冒烟测试只需要准备10张不同类型的发票，目的是把所有主干组件都点亮。这一步帮我们提前发现了两个问题：一个是某台机器人权限配置过低，无法写入归档目录，另一个是大模型对多页PDF的OCR内容拼接不完整。这两个问题在正式上线前都修掉了。

5.5 灰度发布与人工复核机制

正式上线时，我们没有让机器人直接全量接管，而是采用灰度策略：前两周机器人只处理20%的发票，且所有识别结果都要经过财务人工复核；确认准确率达到预期后，再逐步提升到50%、80%、最终100%。人工复核这块我们用了一个极简的处理界面，机器人把识别字段和原图并排展示给复核员，复核员只需要点击"通过"或"修改"即可，几乎不增加额外工作量。

灰度过程中我们发现，大模型对某些特殊供应商名称的规整结果不稳定，比如会把"中国石油化工股份有限公司"简写成"中石化"，而财务系统里这两者对不上。于是我们在流程里加了一步"供应商名称模糊匹配"，先尝试在系统里查找到完全一致或高度相似的记录，找不到就转人工。这个改动直接把字段正确率从93%拉到了98%以上。

6. 踩坑实录：那些文档里查不到的细节

6.1 GPU显存OOM，问题出在并发数

上线第一周，用户反馈大模型识别偶尔会报错，查看服务器日志发现是"CUDA out of memory"。我们的第一反应是并发请求太多，于是把vLLM的并发上限从8调低到4，观察了一会儿，OOM概率确实下降了，但还没有完全消失。后来才发现，问题不只是并发数，还在于有些长文档把max_model_len占满了，KV cache分配不够用了。最后我们做了两处调整：一是把max-model-len从8192降到4096，二是限制单请求输入长度不超过3000字。这样调整后，OOM问题基本绝迹。

6.2 中文OCR对表格和盖章区域的识别有误

PaddleOCR的通用识别效果不错，但在发票上经常出错，比如金额栏的"¥"符号和数字贴太近会被识别成"Y"；发票盖章区域的红色印章压住了文字，导致部分字段漏识别。这个问题靠调参数解决不了，我们最后引入了PP-StructureV2的表格识别功能，并针对常见的几类发票版式，人工标注了一批样本做了微调。微调数据量不大，200多张发票就见效了，识别准确率从90%提到95%以上。

6.3 多个机器人同时操作数据库，出现主键冲突

自动化率提上来之后，新的问题来了：三个机器人同时处理发票，回盘时一起往业务表里插数据，结果频繁报主键冲突和数据库锁等待。排查后发现是任务分配不均——控制台虽然给每个机器人派发了不同任务，但机器人处理完成后同时调用同一个"单据号生成"接口，生成逻辑又依赖数据库自增序列，竞争很激烈。

我们后来的方案是给每条机器人任务提前分配好单据号段，机器人只需要在本地按号段递增生成单据号，不再依赖实时数据库序列。这样一来，冲突率直接降为0。这种问题在单机器人的POC阶段根本不会出现，只有并发上了规模才会暴露，属于典型的"规模性踩坑"。

6.4 大模型"幻觉"没有彻底消除，只能靠规则兜底

大模型在抽取发票字段时偶尔会"一本正经地胡说八道"，比如把供应商名称抽错、金额多了个零。我们试过把温度降到0.1、在Prompt里强调"只能从原文抽取"，但偶尔还是会有漏网之鱼。有一天早上财务反馈，有一张发票的金额被抽成了"2300.00"，实际是"230.00"。

后来我们想明白了：大模型本身是一个概率模型，想靠Prompt完全消除幻觉不现实。正确做法是"规则前置、模型补充"——先用正则表达式在OCR文本中优先抓取发票金额，正则抓不到才交给大模型；大模型返回结果后，再用一系列校验规则检查，比如金额不能超过5万、日期不能晚于当天、销售方名称必须包含"公司"等。校验不通过就进人工队列。最终效果是，规则兜住了99%的错误，大模型只负责处理规则够不着的边界场景。

6.5 安全策略太严，AI服务连不上

客户的网络安全管理很严格，各区域之间默认只开放必要端口。我们调试的时候发现，机器人调用AI服务经常超时，后来查防火墙日志，发现安全团队只开放了80和443端口，我们用的端口号是8080和8000，全部被ACL拦住了。这事看起来小，但在项目现场非常容易卡住整个联调进度。

解决方式是和安全团队提前对齐端口白名单，把RPA控制台、执行机、AI服务之间的通信端口全部汇总成表格，统一提交审批。这里给后来者一个建议：私有化项目的网络端口规划一定要在项目初期就做，不要等联调时才发现，不然会浪费大量时间。我把我们当时用到的端口整理成一个表格，供参考：

7. 常见问题速查与给后来者的建议

7.1 私有化RPA+AI项目常见问题速查表

7.2 效果复盘：效率提升与团队协作

项目上线运行两个月后，客户的财务团队统计了一份数据：发票处理效率提升了约6倍，平均处理耗时从每张3到5分钟压缩到30秒以内；机器人自动完成的比例稳定在85%左右，剩余15%进入人工复核队列，这部分绝大多数是盖章遮挡、扫描模糊的低质量原图；字段识别整体准确率达到了98.1%，高于客户原定的95%目标。

从团队协作的角度看，最大的收获是RPA和AI团队终于不再各干各的了。之前RPA工程师只会做界面自动化，AI工程师专注于模型指标，两者很少有交集。这次项目逼着两边坐到一起：RPA工程师理解了模型的输出不是100%可靠，必须在流程层设计校验和兜底；AI工程师理解了业务场景里的"准确率99%"还不够，有时候那1%的错误会带来巨大的业务影响。这种融合是私有化智能自动化项目最有价值的地方。

7.3 给准备做这类项目的团队几个建议

最后说几点我在实际项目中沉淀下来的经验，每一条都是踩过坑换来的。

第一，开工前一定要把"数据边界"定义清楚。不要笼统地说"数据不出域"，要具体到哪个字段、哪个文件、哪个环节不允许出域，并且画成一张数据流图，让客户安全团队确认。这笔时间省不得。

第二，RPA不是万能工具，AI也不是。遇到流程不稳定、步骤过于灵活的业务，硬上自动化只会让自己陷入无穷无尽的异常处理中。选场景的原则是：低频复杂场景先不做，高频标准场景优先做。

第三，不要过度迷信大模型。当前阶段，大模型最强的能力是理解和生成，而不是精确计算和严格规则执行。在涉及金额、日期、编号这类强逻辑字段时，优先用正则和规则，大模型只做补充，这样才能把错误率控到生产可接受的范围。

第四，日志和审计要从第一天做起，而不是上线前补做。私有化项目的客户大多是强合规行业，如果你在POC阶段就拿出完整的审计方案，客户的信任度会明显提高。反过来，等客户主动问起审计日志时再补，哪怕技术实现完全一致，印象分会差很多。

这些经验不一定适合所有团队，但如果你也在准备把RPA和AI往企业内网里搬，希望能帮你少掉几次头发。这一行没有银弹，无非是多想一点、多试一点、多踩点坑、再把自己的经验写出来分享给别人。