AI工作流在企业审批场景的复盘：规则引擎+LLM混合判定的工程经验-港品优选

AI工作流在企业审批场景的复盘：规则引擎+LLM混合判定的工程经验

一、为什么审批场景需要AI？

传统企业审批流程纯粹靠规则引擎——"金额>5000需要部门经理审批"、"合同类型=采购需要法务审核"。规则覆盖了约75%的审批决策，但剩下25%的"灰色地带"如"外包人员出差费用是否合理"、"合同条款中的非标准风险"无法用规则描述。

2025年中实施了一个"规则引擎+LLM"的混合审批系统。规则引擎处理确定性逻辑（75%），LLM处理需要语义理解的灰色地带（25%）。这个比例后来被验证为最优资源分配。

二、混合判定的核心设计

规则引擎部分 —— 处理75%的确定性场景

规则引擎不是if-else。选用了Drools（Java规则引擎）的Golang移植版本，支持声明式规则定义：

rule "费用审批-金额阈值" when $req: ApprovalRequest( type == "expense", amount > 5000, amount <= 10000 ) then $req.setAction("require_manager_approval"); $req.setConfidence(1.0); end rule "费用审批-部门预算" when $req: ApprovalRequest(type == "expense") $dept: Department(name == $req.department, budgetRemaining < $req.amount) then $req.setAction("reject"); $req.setReason("部门预算不足"); $req.setConfidence(1.0); end

规则引擎的确定性决策（confidence=1.0）直接出结果，不经过LLM。

LLM部分 —— 处理25%的灰色地带

当规则引擎无法匹配（或匹配后confidence<1.0）时，进入LLM流水线：

class HybridApprovalPipeline: def __init__(self, rule_engine, llm_client, human_queue): self.rule_engine = rule_engine self.llm = llm_client self.human_queue = human_queue async def process(self, request: ApprovalRequest) -> Decision: # 第一层：规则引擎 rule_result = await self.rule_engine.evaluate(request) if rule_result.confidence >= 1.0: return rule_result # 确定性返回 # 第二层：上下文构建（关键！） context = await self._build_context(request) # 第三层：LLM判定 llm_result = await self.llm.evaluate(request, context) # 第四层：置信度阈值判断 if llm_result.confidence >= 0.85: decision = llm_result.to_decision() self._log_llm_decision(request, decision, llm_result.reasoning) return decision else: # 低置信度升级到人工 return await self._escalate_to_human(request, llm_result) async def _build_context(self, request: ApprovalRequest) -> dict: """构建LLM判定的上下文——信息越全准确率越高""" return { "request": request, "historical_similar": await self._get_similar_approvals(request), "department_budget": await self._get_budget(request.department_id), "company_policy": await self._get_relevant_policy(request.type), "applicant_history": await self._get_user_approval_history(request.user_id), }

三、上下文构建的数据工程

LLM判定准确率高度依赖输入的上下文质量。一个审批请求在进入LLM之前，需要构建如下上下文数据：

申请人历史数据：此员工过去12个月的审批通过率、异常审批次数、平均审批金额
相似历史审批：最近100条同类型审批的决策结果及理由
部门预算：当前预算剩余、已用比例、与去年同期对比
公司政策：与此审批类型相关的文字政策（从公司Wiki检索）

这些上下文数据的构建涉及到多个数据源的聚合，平均耗时约2秒——是整体延迟的主要贡献者。

四、效果与风险管控

运行数据（6个月）：

日均处理审批：约800条
规则引擎处理比例：73%（直接返回）
LLM处理比例：22%
人工审核比例：5%
LLM判定准确率（与人工审核结果对比）：91%
平均处理时间：规则引擎<100ms, LLM约3.2秒, 人工约4小时

风险管控机制：

LLM决策必须附带推理过程（Chain-of-Thought）。审批日志中记录完整的"为什么这样判定"，供人工抽查。
异常检测规则——规则引擎永远不会被绕过。即使LLM给出了PASS决定，如果触发"金额>部门月预算的30%"，仍强制升级到人工。
A/B对照实验：5%的LLM判定请求同时发送给人工审核，计算一致率。月度一致率低于90%时触发LLM Prompt调整。
回滚能力：LLM的Prompt通过版本管理，任何时候可以回滚到上一版本。一次Prompt更新导致"差旅费用审批"的拒绝率从8%跳到22%（因过度严格），15分钟回滚恢复。

五、总结

规则引擎+LLM混合审批的核心经验：

75/25的分工比例是关键。确定性的事情用规则引擎（零延迟、零幻觉），非确定性的事情用LLM（语义理解）。不要让LLM做规则引擎能做的事——浪费算力且引入不必要的幻觉风险。
上下文质量决定LLM准确率。投入在数据聚合上的工程时间（约总工期的40%）是系统正确性的基础。
强制推理过程记录。LLM判定不可解释就无法在企业环境中落地。Chain-of-Thought推理链是审批审计的必要条件。
永远的兜底：规则引擎的安全红线。无论LLM判定什么，违反安全规则的审批必须被拦截。

最大的经验教训：在审批场景中，LLM不是替代规则引擎，而是填补规则引擎的空白。试图用LLM替代所有审批逻辑会导致：成本失控（每条审批都调LLM，月费上万美元）和风险失控（LLM幻觉导致的错误审批）。混合方案把两者的优势结合——确定性交给规则，模糊性交给AI。

企业官网建设流程全解析