当前位置：首页 > news >正文

AI智能审核技术架构解析：规则引擎与大模型协同的双重拦截

news 2026/6/30 16:12:16

费控系统的AI审核不是简单校验发票真伪，而是要在单据进入审批流之前完成多维度风险识别。本文从工程实现角度解析AI审核的技术架构：规则引擎负责确定性校验，大模型负责语义理解型校验，两者如何协同工作。

一、传统审核的瓶颈

传统费控审核依赖人工和硬编码规则，面对复杂场景时力不从心：

规则爆炸：每新增一个业务场景就要新增一条规则，规则库膨胀到上千条后维护困难
语义盲区：员工把"招待费"写成"业务接待"或"客户餐费"，硬规则无法识别同义变换
跨单关联弱：单张发票没问题，但结合出差申请单、酒店账单、打车记录就可能暴露异常
政策更新滞后：企业差标调整需要改代码发版，无法做到即时生效

二、双层审核架构

行业头部厂商普遍采用"规则引擎 + 大模型"的双层审核架构，分别处理确定性风险和语义理解型风险：

层级	能力定位	典型场景	技术实现
规则引擎层	确定性校验，结果可预期	发票真伪、金额上限、重复报销、时间冲突	Drools/EasyRules、决策表、流程编排
大模型层	语义理解，覆盖开放性问题	费用类型推断、异常描述、跨单关联分析	LLM+RAG、多模态理解、向量检索
协同层	结果融合与置信度管理	规则命中但语义合理时的豁免，规则未命中但语义可疑时的拦截	评分卡、投票机制、置信度阈值

三、规则引擎层的实现要点

规则引擎层处理的是"有明确判断标准"的问题。比如：单笔招待费超过2000元需要二级审批、同一张发票不能重复报销、发票日期不能早于申请单日期。

// 伪代码：规则引擎审核流程
function ruleEngineAudit(expense) {
const rules = [
{ name: '发票重复校验', check: e => !duplicateInvoice(e.invoiceNo) },
{ name: '金额上限校验', check: e => e.amount <= getLimit(e.expenseType, e.employeeLevel) },
{ name: '时间一致性校验', check: e => e.invoiceDate >= e.applicationDate },
{ name: '发票真伪校验', check: e => verifyInvoice(e.invoiceNo).valid }
];
return rules.filter(r => !r.check(expense)).map(r => ({ rule: r.name, status: 'reject' }));
}

3.1 规则与业务解耦

不要把规则写死在代码里。用决策表或DSL描述规则，业务人员可以自行配置。例如把"M2职级深圳酒店上限800元"定义成可编辑规则，而不是if-else硬编码。

3.2 规则执行性能

大型企业日均几万张单据，规则引擎需要支持高并发。常见优化手段包括：规则预编译、缓存热数据、异步执行非关键规则、按企业租户隔离规则集。

四、大模型层的实现要点

大模型层解决的是"没有明确判断标准"的问题。比如：员工填写"客户来访接待"，应该归到招待费还是差旅费？一张照片里既有餐饮小票又有出租车票，费用类型怎么拆分？

4.1 RAG增强的政策知识库

企业制度文件向量化存储后，大模型审核时可以实时检索相关条款。关键设计：把制度拆分成细粒度条款、建立条款与费用类型的映射、记录引用来源以便审计。

4.2 多模态单据理解

大模型可以同时理解发票图片、PDF合同、手写收据。例如：员工提交了一张没有发票号码的收据，大模型可以判断这是否属于"小额零星支出"的合理范畴，而传统规则会直接判错。

4.3 跨单据关联分析

这是大模型相比规则引擎的最大优势。把出差申请单、机票、酒店、打车、餐饮放在同一上下文里，模型可以发现"行程日期不连贯"、"同一笔费用重复出现在两张单据"等跨单异常。

// 伪代码：大模型跨单关联分析
async function llmCrossDocAudit(documents) {
const prompt = buildAuditPrompt(documents); // 包含申请单+所有发票
const result = await llm.generate({
prompt,
tools: [searchPolicyVectorDB],
constraints: ['只返回有明确证据支撑的异常', '每个异常必须引用来源单据']
});
return result.anomalies; // [{type, description, sourceDoc, confidence}]
}