前阵子客户抛过来一个需求一句话就把我们堵死了这套自动化方案做可以但所有数据必须留在内网连一张截图都不能传出去。客户是做金融业务的用户资料、流水、信贷材料全是敏感数据合规部门在项目启动前直接划了红线——数据不出域。原先他们想过直接用云端的RPA平台和AI识别接口毕竟上手快、效果也不错但合规评估阶段就被毙了。于是我们只能从零搭一套私有化部署的 RPAAI 体系把流程机器人、OCR识别、大模型问答全部搬进客户机房。整个项目从POC到落地用了三个多月踩了一堆文档里根本查不到的坑。这篇文章就是把这套方案的完整落地过程、关键配置和踩坑经验整理出来给同样准备做私有化自动化的团队做个参考。如果你是RPA工程师、AI实施人员或者正在帮金融、政务、医疗这类管控严的行业做降本增效这篇文章应该能帮你少走不少弯路。我会把需求背景、架构选型、组件配置、数据安全落点以及真实遇到的故障和排查过程都写出来偏实操尽量不废话。1. 需求解析为什么数据不出域成了自动化的硬门槛1.1 合规压力不是闹着玩的先说客户的真实处境。这家金融机构每天要处理大量客户开户材料、信贷审批附件和发票凭证很多文件里直接包含身份证号、手机号、家庭住址这些敏感个人信息。按照监管要求这些数据必须存储在境内且受控区域内未经授权不得向外部传输。也就是说哪怕只是把一张带客户信息的图片传到云端做一次OCR识别也属于数据出境在合规上是过不了关的。我们最开始也试着说服客户云端RPA不是能配置SLAT和隐私协议吗数据传到云端后加密存储是不是可以接受但合规部门的回复很干脆只要有出域这个动作不管后面加密不加密就是不行的。所以项目的第一条原则就定了所有采集、处理、存储环节都必须发生在客户自己的网络环境里。1.2 云端方案与私有化方案的关键权衡既然云端方案被否那是不是就直接拍板私有化其实也不是。我们在前期做了一个相对完整的对比把两种方案在几个核心维度上的差异列了出来最后才围绕数据不出域这个最高优先级去倒推决策。对比维度云端RPAAI方案私有化RPAAI方案数据安全性数据传输到第三方服务器存在合规风险数据全程留在内网从源头规避出域首次投入成本按量付费起步不高需要采购服务器和GPU初期成本高性能与延迟依赖公网带宽高峰期可能不稳定内网调用延迟低且稳定运维复杂度服务商托管运维压力小需要自建运维能力持续投入人力定制化程度受平台功能限制较多模型和规则都可以深度定制审计要求日志在对方平台调取链路长日志全部自持审计追溯方便对这家客户来说合规权重远高于成本所以私有化是没有悬念的。但我也要提醒一句如果你所在行业没有这么强的监管压力业务数据也不太敏感云方案的成本和便捷性确实是巨大优势不必为了私有化而私有化两种路线各有适用场景。1.3 方案边界哪些环节必须私有哪些可以保留外部能力这里要特别说明一个容易做过头的地方很多团队一上来就想把所有的AI能力都私有化什么OCR、自然语言处理、大模型全都要内网跑一套。但实际上并不是所有环节都会碰到敏感数据。比如一些公开资料的爬取整理、脱敏后的统计报表分析这类场景如果硬要私有化反而浪费GPU资源和维护成本。我们当时和客户定了一个边界凡是可能接触原始敏感数据的环节必须是私有化凡是只处理脱敏后数据或公开信息的环节可以沿用成熟的外部工具。这个边界画清楚之后整个方案的规模和预算就压缩了不少。所以做这类项目时与其一开始就追求全私有不如先做数据分级再决定哪些能力该布局在内网。2. 整体架构设计一套跑在客户内网的自动化中枢2.1 三层架构控制层、执行层、AI能力层整个私有化RPAAI系统我们的设计思路是拆成三个逻辑层控制层、执行层、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/qdrantQdrant的检索性能在百万级向量规模下依然能保持在几十毫秒级别客户现阶段数据量也就几十万条切片完全够用了。入库流程用Python脚本把PDF、Word、Excel统一解析成文本再按固定步长切块并保留段落标题作为上下文信息检索的时候用混合检索向量召回关键词过滤来提升准确率。3.4 硬件资源规划清单给一份我们当时规划的参考配置方便读者对照评估设备配置用途数量GPU服务器单卡A10 16GB / 64GB内存 / 2TB SSDAI推理、向量检索1台应用服务器16核32GB / 500GB SSDRPA控制台、API服务2台RPA执行机8核16GB / 200GB SSD跑机器人实例4台数据库服务器16核64GB / 1TB SSDMySQL、Redis2台这套配置下来硬件成本大概在十几万元量级和云服务按年的费用比起来确实不便宜但考虑到数据资产的安全价值客户认为是划算的。如果你的数据量更大、并发更高GPU服务器需要扩容到多卡执行机也要按场景增配。4. 数据不出域的落地保障从流程设计到审计闭环4.1 数据全生命周期的管控思路数据不出域不是靠某一台防火墙就能实现的关键要看数据在每个环节的流向。我们把整个生命周期分成采集、传输、处理、存储、销毁五个阶段每个阶段都明确约束。采集阶段机器人只读取业务系统授权范围内的数据超出范围直接跳过并记录异常传输阶段数据只在客户内网通过内部API流转不经过任何公网出口处理阶段AI服务在隔离网络内完成推理日志中不记录原始报文存储阶段原始文件落到客户指定的归档存储按保留策略自动执行清理销毁阶段超过效期的敏感数据由定时任务物理删除并生成销毁证明。4.2 一个典型流程的数据流拆解拿发票识别与费用自动入账这个场景来举例。原流程是财务每天从报销系统下载电子发票人工核对发票真伪、提取金额和供应商信息再录入财务系统。私有化改造后流程变成机器人定时登录报销系统把待处理的发票PDF下载到内网指定目录机器人调用OCR服务对PDF进行识别提取发票号码、金额、日期、销售方等信息OCR结果传给大模型做字段归一化校验剔除明显识别错误机器人把结构化结果回填到财务系统完成自动入账原始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}, timeout30) 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, jsonpayload, timeout30) 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服务之间的通信端口全部汇总成表格统一提交审批。这里给后来者一个建议私有化项目的网络端口规划一定要在项目初期就做不要等联调时才发现不然会浪费大量时间。我把我们当时用到的端口整理成一个表格供参考通信方向协议端口用途控制台到执行机TCP9200任务下发与状态采集执行机到AI服务TCP8080OCR识别服务执行机到大模型服务TCP8000大模型文本抽取执行机到向量库TCP6333知识库检索运维到管理区跳板TCP22运维管理7. 常见问题速查与给后来者的建议7.1 私有化RPAAI项目常见问题速查表问题类型典型表现排查方向解决建议OCR识别错误金额、印章文字识别不准检查版本模型是否适合票据场景引入版面分析模型收集样本微调大模型结果不稳定字段抽取时对时错确认Prompt和温度参数规则前置模型兜底增加二次校验高并发卡顿大量任务同时执行变慢检查GPU显存、API超时设置使用并发调度框架控制并发上限数据库冲突主键重复、死锁检查多机器人同时写库逻辑预分配号段避免实时竞争网络不通服务间调用超时查看防火墙ACL是否放行提前整理端口清单并审批训练数据泄露微调后日志有敏感信息检查训练数据处理流程构建脱敏流水线日志去敏感化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往企业内网里搬希望能帮你少掉几次头发。这一行没有银弹无非是多想一点、多试一点、多踩点坑、再把自己的经验写出来分享给别人。