AI 赋能传统审批流规则引擎与大模型混合判定的工程落地一、审批系统的局限性当规则引擎遇到合理的例外传统审批系统的工作原理是if...else 堆砌。金额超过 5000 需要二级审批金额超过 10000 需要三级审批加班申请由直属领导审批出差申请由部门总监审批。规则清晰执行死板。问题在于现实永远比规则复杂。一份 4950 元的采购申请差 50 元触发二级审批拆成 3 张 1650 元的子申请后轻松绕过——规则引擎防不住恶意合规。一份紧急的运维变更审批卡在凌晨 2 点的审批人睡眠中——规则引擎不知道紧急的真正含义。大模型在这些场景下提供了一种不同的判定方式理解语义而非匹配规则。它可以看出来自同一供应商的三张相邻单子可能是拆单可以判断凌晨 2 点的紧急运维确实需要自动通过。但这里有一个根本矛盾审批系统需要确定性大模型本质上是概率系统。graph TB IN[新审批提交] -- RE[规则引擎初审] RE -- D1{规则命中?} D1 --|命中且明确| OUT1[直接通过/拒绝] D1 --|命中但不确定br/或未命中| LLM[LLM 语义分析] LLM -- CONF{置信度 0.85?} CONF --|是| OUT2[自动判定] CONF --|否| HUMAN[人工审核] HUMAN -- FEED[反馈数据] FEED -- LLM subgraph 规则引擎层 RE D1 OUT1 end subgraph AI 增强层 LLM CONF OUT2 end style HUMAN fill:#ffd43b,color:#000 style OUT1 fill:#51cf66,color:#fff style OUT2 fill:#4dabf7,color:#fff本文将设计一套规则引擎与大模型混合的审批判定架构核心目标是规则引擎保障确定性大模型处理模糊边界。二、混合判定的架构设计三层递进式的责任分配混合判定的核心在于明确每一层的职责边界Layer 1 — 规则引擎确定性处理明确的、可枚举的规则。如金额 10000 触发二级审批、特定类型审批由特定角色处理。这一层必须 100% 准确零容忍误判。Layer 2 — LLM 语义分析辅助判定处理规则无法覆盖的模糊场景。输入是审批表单的结构化数据 申请人的历史行为摘要输出是判定结果 置信度分数。置信度 0.85 的判定自动执行 0.85 的转人工处理。Layer 3 — 人工兜底最终裁决当 LLM 置信度不足时回归人工审批。人工的每次判定都会被记录作为后续微调 LLM Prompt 或 Few-shot 示例的依据。三层之间的数据流是单向的。规则引擎先执行只有未被规则覆盖的 case 才流向 LLM。LLM 的输出不回流到规则引擎——避免 LLM 的不确定性污染规则引擎的确定性。LLM 的 Prompt 设计是关键。不是让 LLM自由发挥而是给一个结构化的判定框架基于以下审批信息和申请人历史判断此申请应该 1. 自动通过需要明确理由 2. 转人工审核需要指出不确定的点 判定维度 - 金额是否与历史模式一致 - 时间是否合理 - 申请人与审批事项是否匹配 - 是否有拆单嫌疑 输出格式 { decision: auto_approve | human_review, confidence: 0.0-1.0, reason: ... }三、工程实现规则引擎 LLM 的组合管道// approval-pipeline.ts interface ApprovalRequest { id: string; type: purchase | overtime | travel | refund; amount: number; applicantId: string; department: string; description: string; items?: Array{ name: string; amount: number }; } interface RuleResult { matched: boolean; decision: approve | reject | escalate | null; rule: string | null; } interface LLMResult { decision: auto_approve | human_review; confidence: number; reason: string; } // Layer 1: 规则引擎 class RuleEngine { private rules: Array(req: ApprovalRequest) RuleResult []; addRule(rule: (req: ApprovalRequest) RuleResult) { this.rules.push(rule); } evaluate(req: ApprovalRequest): RuleResult { for (const rule of this.rules) { const result rule(req); if (result.matched) { return result; } } return { matched: false, decision: null, rule: null }; } } // 预设规则 function amountThresholdRule(req: ApprovalRequest): RuleResult { if (req.amount 100000) { return { matched: true, decision: escalate, rule: amount_threshold_100k }; } if (req.amount 500) { return { matched: true, decision: approve, rule: small_amount_auto }; } return { matched: false, decision: null, rule: null }; } function departmentLimitRule(req: ApprovalRequest): RuleResult { const deptLimits: Recordstring, number { engineering: 50000, marketing: 20000, hr: 10000, }; const limit deptLimits[req.department] || 5000; if (req.amount limit) { return { matched: true, decision: escalate, rule: dept_limit_exceeded }; } return { matched: false, decision: null, rule: null }; } // Layer 2: LLM 分析 class LLMAnalyzer { private apiKey: string; constructor(apiKey: string) { if (!apiKey) throw new Error(API key is required); this.apiKey apiKey; } async analyze(req: ApprovalRequest, history: string[]): PromiseLLMResult { const prompt this.buildPrompt(req, history); const response await fetch(https://api.openai.com/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${this.apiKey}, }, body: JSON.stringify({ model: gpt-4o-mini, messages: [ { role: system, content: this.systemPrompt() }, { role: user, content: prompt }, ], temperature: 0.1, response_format: { type: json_object }, }), }); if (!response.ok) { // LLM 不可用时降级为人工审核 return { decision: human_review, confidence: 0, reason: LLM service unavailable }; } const data await response.json(); return JSON.parse(data.choices[0].message.content) as LLMResult; } private systemPrompt(): string { return 你是一个审批辅助系统。基于审批信息判断是否可以自动通过。 自动通过的条件金额合理、描述清晰、与历史行为一致、无拆单嫌疑。 如果存在任何不确定因素返回 human_review。 输出 JSON: { decision: auto_approve | human_review, confidence: 0.0-1.0, reason: string }; } private buildPrompt(req: ApprovalRequest, history: string[]): string { return 审批信息 - 类型: ${req.type} - 金额: ${req.amount} - 部门: ${req.department} - 描述: ${req.description} - 项目: ${JSON.stringify(req.items)} 申请人近期行为 ${history.slice(0, 10).map((h, i) ${i 1}. ${h}).join(\n)} ; } } // 混合管道 class ApprovalPipeline { private ruleEngine: RuleEngine; private llmAnalyzer: LLMAnalyzer; constructor(apiKey: string) { this.ruleEngine new RuleEngine(); this.ruleEngine.addRule(amountThresholdRule); this.ruleEngine.addRule(departmentLimitRule); this.llmAnalyzer new LLMAnalyzer(apiKey); } async process(req: ApprovalRequest, history: string[]): Promise{ source: rule | llm | human; decision: string; detail: string; } { const ruleResult this.ruleEngine.evaluate(req); if (ruleResult.matched ruleResult.decision) { return { source: rule, decision: ruleResult.decision, detail: 规则命中: ${ruleResult.rule}, }; } const llmResult await this.llmAnalyzer.analyze(req, history); if (llmResult.confidence 0.85 llmResult.decision auto_approve) { return { source: llm, decision: approve, detail: llmResult.reason, }; } return { source: human, decision: pending_review, detail: llmResult.reason, }; } }核心设计规则引擎优先执行LLM 只处理未被规则覆盖的 case。LLM 异常时有降级策略转人工。response_format: { type: json_object }保证 LLM 输出的结构稳定性。四、风险防控与工程边界误判风险LLM 可能将违规审批判定为通过。我们的防御措施是置信度阈值0.85 人工兜底。但这个阈值是经验值可能需要在实际运行中根据误判率调整。建议先用历史数据回测找到最优阈值。数据安全风险审批数据可能包含敏感信息薪资、报销明细。如果使用外部 LLM API需要对敏感字段脱敏或使用本地部署的模型。不适用场景金融合规等需要严格审计留痕的场景——规则引擎 人工审批是目前唯一合规方案审批量极低的场景 10 条/天——引入 LLM 的维护成本超过人工审批成本需要实时解释能力的场景——LLM 的解释是概率性的法律场景需要确定性的解释审计要求每次 LLM 的判定都需要完整记录输入、输出、模型版本、置信度。这不是技术需求而是合规需求。五、总结规则引擎 LLM 混合判定的核心价值是确定性留给规则模糊性留给大模型风险留给人工兜底。落地路径先在非关键审批类型如小额采购审批中试点收集一周的 LLM 判定 vs 人工判定差异计算误判率和召回率。确认 LLM 的置信度分布后逐步扩展到更多审批类型。技术的意义不是替代人的判断而是让人的判断用在最有价值的地方。少即是多——让 AI 过滤掉 80% 的常规 case让审批人专注于真正需要判断力的 20%。