AI工作流在企业审批场景的复盘规则引擎LLM混合判定的工程经验一、为什么审批场景需要AI传统企业审批流程纯粹靠规则引擎——金额5000需要部门经理审批、合同类型采购需要法务审核。规则覆盖了约75%的审批决策但剩下25%的灰色地带如外包人员出差费用是否合理、合同条款中的非标准风险无法用规则描述。2025年中实施了一个规则引擎LLM的混合审批系统。规则引擎处理确定性逻辑75%LLM处理需要语义理解的灰色地带25%。这个比例后来被验证为最优资源分配。二、混合判定的核心设计规则引擎部分 —— 处理75%的确定性场景规则引擎不是if-else。选用了DroolsJava规则引擎的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规则引擎的确定性决策confidence1.0直接出结果不经过LLM。LLM部分 —— 处理25%的灰色地带当规则引擎无法匹配或匹配后confidence1.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。
