LLM+RPA智能合规架构：企业风控的自动化进化

每年做合规审计的时候都是企业风控部门最头疼的时候。一堆合同要过、几百张报销单要核、供应商资质要重新审查人工一个个过既慢又容易漏。更麻烦的是那些真正藏得深的合规风险——比如合同里夹带的不合理条款、报销单背后的关联交易、供应商之间的隐秘股权关系——往往要靠“人肉”经验才能嗅出不对劲。我见过不少企业尝试用传统RPA机器人做合规管控结果发现机器人只能按固定规则跑遇到语义模糊、需要判断的场景就抓瞎了。最近我在一个企业数字化改造的模拟项目里落地了一套基于LLM大语言模型加RPA的智能化合规架构结合“实在Agent”这类能自主决策的智能体框架把原来靠人工拍脑袋判断的合规审核环节变成了“规则引擎兜底、大模型推理判断、机器人自动执行、人工只处理高危异常”的流水线。这篇文章把整套架构的拆解思路、核心模块的落地细节、以及我实操中踩过的坑都梳理一下给正在被合规管控折磨的同行们一个可参考的路线。1. 项目背景与需求拆解1.1 人工合规管控的典型漏洞到底在哪做这类型项目之前得先搞清楚一个核心问题人工管控为什么会漏我接触的多数企业合规审核其实都有标准流程但战线拉太长、人手不够、业务压力大流程执行就打折扣了。比如合同审核法务部一个人一天要过几十份合同重点条款能看过来就不错了那种藏在附录里的风险条款、前后矛盾的定义、不合理的违约责任分配很容易扫一眼就放过去。再比如费用报销财务审核看票据齐全度、金额是否超限但报销背后的业务合理性——为什么这家供应商的报价比市场价高出一截为什么同一家供应商连续三个月出现——靠人工去逐条深挖根本不现实。除了效率问题人工管控还有一个结构性的短板标准不一致。同样一份合同A审核员觉得这条免责条款没问题B审核员认为必须修改最后批不批全看撞到谁手上。这种不一致性在审计的时候特别尴尬同一个风险点不同月份的处理方式完全不一样外审一查就暴露了。1.2 传统自动化RPA为什么只能打半场很多人一听“合规自动化”第一反应就是上RPA。不可否认RPA在处理“规则明确、流程固定、系统操作重复”的场景上确实高效——自动登录系统、抓取页面数据、比对表单字段、提交审批这些事机器人做得又快又准。但合规审核的难点从来不在“流程执行”而在“风险判断”。判断需要理解上下文、需要看语义、需要综合多方信息做推理传统的RPA脚本只能做字段级的关键字匹配比如“合同金额是否超过100万”“发票号码是否存在”一旦遇到“这个条款是否显失公平”“这个报销人和供应商是否存在潜在利益关联”这类需要深度理解的问题传统RPA就无能为力了。所以在项目设计初期我就明确了方向RPA不是不需要而是不能只靠RPA。用RPA解决“执行层”的问题——把跨系统的数据抓齐、把重复动作自动跑完、把结果推送到审批流用LLM解决“判断层”的问题——规则不好覆盖、标准不统一、需要语义理解的审核动作全部交给大模型来推理。这就是LLMRPA组合打法的核心逻辑。1.3 项目目标与约束条件基于上面的分析我在项目启动时定了几个明确目标第一把合规审核的覆盖范围从“抽查”变成“全量”每一份合同、每一张报销单、每一个供应商都过一遍机器审核第二把审核标准的执行统一到大模型推理上消除人工判断的差异性第三高危风险必须保证零漏判大模型的每个判断结果都要有依据说明方便人工复核。同时还有一个约束条件——企业的核心业务系统不能动不能用改造ERP的方式来做合规只能在现有系统外层套一个“合规检查大脑”所以RPA作为桥接层是必然选择。2. 架构设计与技术选型解析2.1 总体架构LLM、RPA与Agent怎么分工协作整套架构如果画成一张图最底层是企业的各类业务系统——OA审批流、财务系统、CRM、供应商管理平台再往上是RPA执行层负责跟这些系统打交道读数据、写数据、触发操作。RPA之上是Agent决策层这是核心它接收RPA采集来的原始数据进行LLM推理判断输出审核结论。最上层是人工复核台只有Agent判断为“高风险”或“无法判断”的项目才会推到这一层人工只需要处理小比例的异常单。这里“实在Agent”扮演的角色是LLM与RPA之间的“调度中枢”。它把RPA采集到的非结构化数据——合同PDF、发票图片、审批意见、供应商公开信息——做结构化处理然后根据不同的合规场景合同审核、费用风控、供应商准入选用不同的Prompt策略和推理链路。Agent还负责维护整个审核任务的上下文记忆比如某份合同上一轮修改了第三条条款下一轮审核时Agent要能记得这个修改结果不能每次重新推理。2.2 为什么选LLMRPA而不是纯LLM或者纯RPA有人会问既然LLM这么能干能不能让大模型直接把所有事都干了理想情况下可以但现实是——大模型接触不到企业内部系统的数据。它没有权限登录你的OA读不到你的财务数据库更没法在审批流里提交一个审核结果。LLM是一个“绝顶聪明的分析师”但它是个没有手脚的分析师。RPA恰好补上了“手脚”“分析师看完报表后指示机器人去执行具体操作”。反过来纯RPA的问题是“手脚很勤快但脑子不够用”只能按写死的规则跑遇到规则没覆盖到的情况就崩了。所以LLMRPA的组合本质上是“大脑手脚”的配合。LLM负责认知——理解条款、识别风险、对比政策RPA负责行动——采集数据、触发流程、回填结果。Agent则把这两者粘合成一个闭环感知RPA采集数据—推理LLM分析判断—执行RPA提交操作—反馈结果回传Agent更新上下文。2.3 数据流与控制流的路径设计我重点讲一下数据流的设计这里是容易翻车的地方。合规审核依赖的数据源非常杂内部系统里有合同台账、报销单、供应商资质文件外部互联网有企业的工商信息、涉诉记录、行政处罚公告、新闻舆情。RPA要从这些异构来源里把数据全部捞出来统一清洗成LLM能吃进去的格式这一步工作量占比其实是最重的。我用的方案是RPA负责原始采集把PDF、Word、网页、系统界面上的数据全部抓成长文本或表格Agent做数据清洗和规范化把杂乱的原文切分成“字段内容”的结构化格式带上来源标签然后填充到Prompt模板里。控制流上采用“两级判定”第一级是规则引擎用硬规则快速过滤比如合同金额超限、发票号重复、供应商证照过期命中规则的直接标记异常第二级才是LLM深度判断处理规则引擎无法覆盖的语义类风险。这样设计的好处是节省LLM的调用成本毕竟大模型按Token计费能省则省。3. 核心模块实操实现3.1 合规规则库的知识工程建设LLM不是万能的它需要知道“什么算风险”这就需要做知识工程。我的做法是先拉着合规部、法务部做了三轮访谈把企业现有的合规制度、业务红线、历史审计发现的问题全部整理出来编成一本结构化的“合规知识手册”。这本手册不是给人看的而是用来构建规则库和Prompt指令集的。规则库分成两部分一部分是“刚性规则”可以直接写成代码或规则引擎配置例如{ rule_id: R001, rule_name: 合同金额超限审查, rule_type: hard_rule, condition: contract_amount 5000000, action: 直接标记高风险并推送人工复核, priority: P0 }另一部分是“柔性规则”需要LLM来解读例如“合同争议解决条款是否对己方不利”“付款条件是否明显缺乏合理性”这类规则写不成代码只能转化成语义化的Prompt指令通过Few-shot示例让模型学会识别。这里有个心得柔性规则的Prompt示例要尽可能用历史真实案例正例反例各给3到5条模型学出来的判断标准才贴合企业自身业务。3.2 RPA与LLM的接口设计与数据清洗实操中最大的坑在数据清洗。合同PDF看起来是文本但很多扫描件实际上是图片RPA抓出来之后是乱码发票上的关键字段位置不固定OCR软件识别精度也不稳定。我整理了一套清洗管线分三步第一步是格式标准化。所有采集到的文件统一转成文本扫描件先过OCR引擎图片类的证据单独存放文本内容抽取出来用于审核。第二部是字段抽取与对齐。用LLM从长文本中抽取关键字段——合同编号、签约主体、金额、日期、违约条款内容——输出成JSON格式{ contract_id: HT-2024-0892, signing_parties: [某某科技有限公司, 某某实业发展有限公司], contract_amount: 820000, amount_currency: CNY, sign_date: 2025-06-15, key_terms: { 违约责任: 若甲方延期交付每延迟一日按合同总额0.5%支付违约金但最高不超过合同总额30%, 争议解决: 双方争议应提交某某仲裁委员会仲裁 } }第三步是语义校验。字段抽取后不能直接进审核流程要先做一轮自洽性检查比如合同金额前后是否一致、签约主体名称与工商登记是否匹配逻辑上站不住的数据直接打回重新采集。这套管线跑通之后RPA采集的数据质量稳定了很多LLM的判断准确率也上来了。3.3 智能审核引擎与人工复核闭环审核引擎是整个架构的决策核心。我设计了一套多级审核链路第一级规则引擎——毫秒级响应把明显的硬性问题直接拦住第二级LLM推理——处理语义类风险每次推理要求模型先给出“判断依据”再给出“风险等级”和“整改建议”例如对合同做风险分析时LLM输出要求严格缩写以下格式风险等级高 风险摘要争议解决条款约定仲裁地为对方所在地仲裁委员会且适用对方所在地法律对己方可能产生不利影响 判断依据合同附录B第7.2条明确约定“仲裁机构为乙方所在地某仲裁委员会适用乙方所在地法律”。鉴于本合同履行地为甲方所在地该条款增加了甲方的维权成本与不确定性。 处理建议建议修改争议解决条款将仲裁地变更为甲方所在地仲裁委员会或中立地点的仲裁机构或在商务谈判中争取适用合同履行地法律。第三级人工复核——只处理高风险单和模型置信度偏低的单。这里要单独说下置信度机制因为LLM天生不会说“我不会”它就算不确定也会硬给一个结论。我的方案是让模型在推理前先做一轮“已知信息充分度自评”信息不足时强制要求触发补充采集不能直接下结论。3.4 审计日志与全链路追溯合规系统本身也要过审计这一关。系统跑出的每一条审核结果都要能追溯到“谁在什么时间看了什么数据基于什么规则或者模型得出了什么结论”。我在这套架构里做了全链路日志具体包括几个维度基础的日志字段包含任务流水号、输入数据快照、命中的规则编号、LLM推理的原始输入和输出、执行时间戳以及操作人账号。输入数据快照这块比较关键因为合同、发票这类原始文件可能会在后续被替换或删除如果没有留底审计的时候就没法还原当时的判断场景。我把每个审核任务关联的原始文件全部做了副本存储权限上只有审计管理员可读业务人员改不了。数据层面还做了一层完整性校验日志记录里的关键字段每批次都生成哈希值防止内部篡改日志的情况。这套设计一开始觉得有点过度设计结果后来真的有监管检查要求复现某个月的审核情况全链路日志直接派上了大用场。4. 典型业务场景实战拆解4.1 合同条款合规审查场景合同审核是这套架构跑通后最稳定的场景。流程大概是这样的RPA机器人每天定时从OA系统里扫描新建的合同审批单把合同正文PDF下载到本地同时抓取合同台账里的关联业务信息比如项目编号、预算金额、申请人部门。Agent收到材料后先做字段抽取标准化成结构化数据然后送进两级审核链路。第一级规则引擎跑硬规则比如合同金额超出部门预算范围、合同缺少法人签字页、合同有效期早于当前日期这些都是即查即决。第二级LLM做深度条款审查重点检查五类风险违约责任失衡、知识产权归属不清、保密条款缺失或过弱、争议解决条款对己方不利、付款条件明显不合常理。LLM跑出来的结果直接在审批流里生成一条风险评估记录作为法务审批时的辅助参考。推到这个阶段我踩过一个坑一开始Prompt设计得过于笼统让模型“请审查本合同是否存在法律风险”模型输出的内容也很泛泛什么都能找出点问题但什么都说不到点上。后来改成拆分子任务——先看违约责任是否对等再看争议解决条款逐个审查每个维度单独出结论最后汇总。效果差别非常大。4.2 费用报销单据智能风控场景费用报销的合规难点在于“真实合理性”。一张发票本身是真的、金额没超标、审批流程也走完了但背后可能涉及虚构业务、关联方套现、重复报销。传统RPA做报销审核最多查一下发票号是否重复、抬头是否匹配更深层的利益关联判断根本查不出来。我在这个场景里设计了几个增强点一是报销人与供应商的关联关系识别把报销单上的供应商名称与工商大数据里的股权关系做匹配如果发现报销人是该供应商的股东、监事或亲属持股系统自动标记为高风险。二是报销合理性判断LLM会结合报销人岗位、出差记录、项目背景综合分析比如一个销售岗位的人报销了一笔大额技术服务费模型会提示“该支出与岗位职责关联性存疑建议补充业务说明”。三是连号发票检测RPA从历史报销库里筛查同一批次开出的连号发票命中直接预警。4.3 供应商准入与关联交易识别场景供应商准入审核信息量很大一家供应商要审营业执照、行业资质、财务报表、涉诉记录、股东结构、是否被列入严重违法失信名单。而且中介机构、代理公司、关联公司之间的嵌套关系非常隐蔽人工去查非常耗时。这套架构在这个场景的做法是RPA每天自动去外部数据源抓取供应商相关的工商变更、涉诉信息、行政处罚公告并定时把供应商的全部股东链条拉取下来做股权穿透分析。LLM负责把股权穿透结果跑出来的模型数据进行语义解读识别是否存在直接或间接的关联关系以及是否形成竞合关系。输出结果综合风险等级、判断依据、建议动作直接推送给采购审批人。这个场景实际跑起来准确率还不错关键是RPA定时抓取外部信息的能力要稳定这块后面单独展开讲。5. 常见问题与排查技巧实录5.1 大模型幻觉导致误判率偏高怎么办合规场景对误判率极其敏感模型把没问题的合同判定为高风险业务部门会烦死把有问题的合同放过去更是不可接受。我跑了大概两个星期之后就遇到幻觉问题——模型煞有介事地写“合同第4.3条存在违约风险”我去翻原文根本没有这条这种“一本正经地胡说八道”最可怕。排查之后发现根源在Prompt太开放。我调整了几个地方第一强制模型在输出判断依据时带上原文引用并且明确指出出自合同的哪一条哪一款没有原文佐证的风险结论自动降级为“建议关注”而不是“高风险”。第二在推理前增加一轮“条款确认”步骤让模型先从原文中提取出认为有风险的条款原文再基于这些原文做分析相当于先用分隔符把内容锁定。第三对于无法完全确定的高风险结论默认走人工复核而不是直接拦截宁可多人工看一张单也不能错杀。5.2 RPA机器人不稳定、流程中断怎么办RPA的稳定性很多情况下取决于被自动化系统的稳定性。页面改版了、弹窗变多了、网络慢了几秒都可能让RPA流程中断。我遇到过最头疼的是企业OA系统升级后登录页结构变了所有RPA任务集体罢工。后来总结了两条经验一是所有RPA操作尽量走接口而不是走界面操作能和系统API对接的操作优先用API万不得已才用UI自动化接口的稳定性远高于界面识别。二是给RPA任务加“看门狗”机制每个执行步骤都有超时控制超时自动重试重试三次还失败就发告警消息给运维人员而不是让机器人静默卡死。5.3 人工复核任务积压、处理不及时系统上线初期会遇到一个尴尬局面机器审核确实发现了不少问题但人工复核岗忙不过来高风险单积压审批流被堵死。合规部门的人本来就少不可能天天坐那看机器推过来的单子。解决办法是给复核台做“分级路由”。P0级别的单可能涉及刑事风险、重大财务造假的必须24小时内处理直接推送邮件加短信提醒P1级别的单存在显著合规瑕疵但不涉及重大违法48小时内处理即可安排在复核台排队P2级别的单模型置信度低但风险不明确不强制时限攒到一定数量后批量处理。这样一分级人工压力就下来了紧急问题也能保证及时响应。5.4 性能与成本怎么平衡LLM调用成本是按Token算的如果每一份合同都丢给大模型做全文推理成本会非常夸张。我测试过一篇二十页的合同全文推理大概消耗两万多Token按商业模型的价格算下来不便宜。成本优化的方向有几个第一规则引擎前置过滤能通过硬规则直接判断的单子不调大模型实测下来大概能挡掉四成左右的单子。第二全文太多就做分段切片只送关键条款进LLM推理比如违约条款、争议解决条款、知识产权条款这些合规风险高发地段单独送背景信息支持性内容不送。第三高频相似的场景用模型蒸馏做轻量化处理前置部署一个小参数模型只有小参数模型判断不了的时候才调用大模型兜底。6. 实操心得与扩展方向这套LLMRPA智能化合规架构上线运行之后我感触最深的一点是转型的真正价值不是把人工审核这份工作干掉而是把人从低价值的重复劳动里解放出来。机器把八成的合同初审、发票核对、信息采集全部跑完了合规人员只需要盯着剩余两成的异常案件做深度分析。原来一个合同审核员一天看二十份合同加班到晚上九点现在一天只需要精审五六份高风险合同反而有精力把每单的背后逻辑摸透。我个人比较推荐的做法是在推广这套系统时不要一上来就追求“自治化全流程”而是先用六到八周做“辅助审核”模式机器只出结论和依据不直接拦截业务让合规部门的人用实际案例去校验模型。校验数据攒够了再逐步调高机器直接拦截的比例给业务部门一个适应期也给模型调优留出数据积累的时间。后续可以扩展的方向其实不少。我目前正在研究的是把时间线拉长做“持续合规监控”不只做单据触发式的检查而是让Agent定期主动扫描业务数据发现中长期的风险趋势——比如某类供应商的准入材料有效期快过期了、某个部门的费用结构出现异常波动。另一个方向是用多Agent协同应对更复杂的跨部门合规场景比如一个Agent管合同、一个Agent管资金流、一个Agent管供应商当两个Agent交叉感知到同一主体关联异常时自动联合研判。这套架构的想象空间很大而且最关键的是它不需要推翻企业现有的IT系统是在旧系统外面加一层“合规智能大脑”对大多数企业来说落地门槛比想象中要低很多。