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

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。

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

相关推荐

【提示词生命周期管理】：按时间线划分的7个阶段+12个SLO指标，企业级AI应用必建的提示治理框架

mba硕士论文格式模板范文

mba毕业论文模板

更多资讯

Telegraf 集成 systemd 凭据存储（systemd-creds）实现安全的明文凭据注入

记住我功能的安全隐患与防御实践

SymPy 梁弯曲分析完全指南：用奇异函数求解 Beam 与 Beam3D 的支座反力、剪力弯矩与挠度

oneTBB aggregator 基础接口详解：基于操作聚合的互斥执行机制

Zoom MCP「搜索即行动」模式实战：基于 knowledge-work-plugins 的会议语义搜索、资产提取与 REST 交接指南

SymPy 丢番图方程求解指南：用 diophantine 函数求整数解与参数化通解

今日更新

基于高阶循环谱的MPSK载波频率估计与MATLAB实现

MiniPdf方：.NET开源Office转PDF的高效解决方案

Solon AI v3.10：Java全栈智能体开发框架解析

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？