1. 项目概述当确定性规则遇上非确定性智能最近在做一个挺有意思的项目核心是把传统的规则引擎和现在火热的混元大模型给“焊”在了一起。听起来有点抽象对吧简单来说就是让一个做事一板一眼、绝对靠谱的“老员工”规则引擎和一个思维活跃、能举一反三的“天才实习生”大模型搭档干活。这个组合的目标很明确既要保证业务核心流程的绝对稳定和可控这是规则引擎的强项又要能灵活处理那些规则写不完、甚至根本预料不到的复杂场景这是大模型的舞台。为什么非得这么干因为纯靠规则系统会越来越笨重。业务每变一次就得吭哧吭哧改一堆if-else维护成本高响应还慢。而纯靠大模型心里又没底它今天这么答明天可能就那么答了用在生产环境的关键决策上谁敢打包票所以我们琢磨出的这条路子本质上是在寻找一种“确定性骨架”与“智慧大脑”的平衡。骨架撑起主体保证不走形大脑填充血肉让系统更聪明、更人性化。这个实践特别适合风控审核、智能客服决策、个性化推荐策略等既要求严谨流程又需要智能判断的场景。2. 架构设计与核心思路拆解2.1 为什么是“规则引擎大模型”这个组合不是拍脑袋想出来的而是为了解决实际工程中的几个核心痛点。痛点一规则的“长尾效应”与维护噩梦。在复杂的业务系统中比如金融信贷审批核心规则如“年龄需大于22岁”可能只占20%但为了覆盖各种边界情况和特殊场景你需要编写80%的复杂、琐碎甚至相互冲突的规则。这些规则相互嵌套形成一个“规则网”任何改动都可能引发意想不到的连锁反应。Drools这类规则引擎虽然通过将业务规则从代码中分离实现了逻辑与数据的解耦并提供了高效的Rete算法进行匹配但规则的编写和维护依然高度依赖领域专家且无法处理规则未定义的“未知情况”。痛点二大模型的“黑盒”与不确定性。混元这类大模型能力强大能理解自然语言进行推理和生成。但你若让它独自处理一个严谨的审批流程它可能会因为提示词Prompt的细微差别、模型本身的随机性temperature参数影响或训练数据偏差给出不一致甚至错误的判断。在生产环境中这种不确定性是不可接受的。解决方案分层决策与职责分离。我们的架构核心思想是“分层”。将整个决策流程视为一个管道Pipeline规则层确定性骨架处理所有明确的、已定义的、必须严格执行的逻辑。例如硬性合规检查、基础数据校验、流程路由。这一层输出是二元的通过/拒绝或结构化的如评分、标签且100%可预测、可审计。大模型层智慧大脑接管规则层无法覆盖或处理不好的部分。例如复杂信息抽取与理解从用户冗长的描述中精准提取关键事件、情绪和诉求。模糊场景裁决规则判断结果为“边缘案例”或“需人工复核”时由大模型提供辅助决策建议。自然语言生成与交互根据规则执行结果和大模型分析生成个性化、人性化的答复或报告。异常模式发现分析历史决策数据发现潜在的新规则模式反哺给规则层进行优化。这样规则引擎确保了基础效率和稳定性大模型则提供了灵活性和智能上限。两者通过清晰的接口和数据契约进行协作。2.2 技术选型与组件考量规则引擎选型Drools的得与失我们选择了Drools主要是看中其成熟度和强大的社区生态。它的核心优势在于高效的Rete算法对于大量规则的匹配性能优于简单的顺序判断。DSL领域特定语言允许业务人员用接近自然语言的格式编写规则提升了可读性。决策表对于条件组合固定的规则如费率表用Excel格式管理非常方便。与Java生态无缝集成作为Java项目集成成本低。注意Drools的学习曲线并不平缓特别是理解其工作内存Working Memory、议程Agenda和执行流程需要时间。另外对于超大规模、动态更新的规则集其规则文件的版本管理和热更新需要精心设计通常需要结合Git和配置中心。可视化规则编辑这是提升运营效率的关键。我们并没有完全自己造轮子而是基于开源组件进行二次开发实现了一个Web版的规则编辑器。运营人员可以在界面上通过拖拽条件节点、配置参数来定义规则后端将其转换为Drools原生的DRL文件。这一步极大地降低了业务人员参与规则维护的门槛。大模型层选型混元与备选方案混元大模型在中文场景、知识问答和逻辑推理上表现不错且提供了稳定的API。选择它主要基于API易用性与稳定性文档清晰SDK完善对于企业级应用稳定性比追求极致性能更重要。成本可控有明确的计价模式便于进行项目预算和成本核算。功能对齐其多轮对话、函数调用Function Calling能力与我们的架构契合。当然这不是唯一选择。架构上我们保持了对大模型的抽象。通过定义统一的LLMService接口我们可以轻松切换后端模型。例如对于需要本地部署、数据隐私要求极高的场景可以集成Ollama部署的Llama 3或Qwen模型对于简单的任务也可以使用OpenAI或Anthropic的API。LangChain或LlamaIndex这类框架可以帮助我们管理不同的模型提供商和构建复杂的链Chain但在我们的架构中由于规则引擎已经承担了主要流程控制我们对大模型的调用相对直接因此选择了更轻量级的自定义封装。3. 核心细节解析与实操要点3.1 规则引擎的“骨架”如何搭建规则引擎不是简单地把if-else搬出来而是需要一套工程化的设计方法。领域模型设计是基石你的规则作用于什么数据这需要定义一个清晰的、富含业务语义的领域对象模型。例如在信贷审批场景你需要一个LoanApplication贷款申请对象里面包含Applicant申请人信息、Income收入证明、CreditReport信用报告等嵌套对象。这些对象将被插入到Drools的“工作内存”中供规则匹配。// 示例领域对象 public class LoanApplication { private String id; private Applicant applicant; // 包含年龄、职业等 private double amount; private int term; private ListIncomeRecord incomes; private CreditReport creditReport; private String status; // 规则引擎会修改这个状态 // getters and setters }规则的组织与分类不要把所有规则写在一个文件里。我们按业务域和决策阶段进行拆分rules/validation/基础校验规则如数据完整性、格式。rules/compliance/合规性硬规则如反洗钱名单检查。rules/risk/风险评分规则输出一个风险分数。rules/routing/流程路由规则决定下一步是自动通过、转人工还是触发大模型分析。这种分类便于管理、测试和权限控制比如合规规则只能由法务人员修改。规则的编写技巧善用salience属性控制规则执行优先级。通常否决性规则如黑名单检查优先级最高。避免规则循环激活规则右部then部分修改了工作内存中的事实可能导致其他规则被重新激活设计不当会引起死循环。要谨慎修改触发当前规则的事实。使用逻辑插入insertLogical在需要基于一定条件临时推导出新事实时使用当条件不再成立时Drools会自动收回该事实有助于管理内存和逻辑状态。3.2 大模型“大脑”的接入与提示工程大模型不是魔法你需要清晰地告诉它要做什么。这就是提示工程。设计系统角色System Role每次调用大模型API时我们都会在消息列表开头赋予它一个明确的角色这能极大地稳定其输出。你是一个专业的金融风控分析助手。你的任务是仔细分析用户贷款申请中的软性信息并结合给定的基础规则判断结果提供是否批准的辅助建议。你必须严格基于提供的事实进行分析不得捏造信息。你的输出必须是结构化的JSON格式。这个角色指令限定了模型的回答范围和风格。构建高质量的上下文Context大模型需要信息才能工作。我们会把规则引擎处理后的结构化信息以及从原始文本中提取的关键片段作为上下文喂给模型。## 申请信息 - 申请人张三35岁自由职业者。 - 申请金额20万元期限3年。 - 收入情况近半年银行流水显示月均收入约1.5万元但波动较大。 - 信用报告无逾期记录信用分680中等。 - **规则引擎初步判断**规则校验通过但风险评分模块给出“中等风险”标签触发人工复核规则。 ## 用户补充说明来自申请表单 “我是一名独立设计师项目收入有季节性但年度总收入稳定。本次借款用于购置专业设备预计能提升未来收入。” ## 你的任务 请分析申请人的职业稳定性和还款意愿给出是否建议批准贷款的简要理由不超过200字并按以下JSON格式输出 { suggestion: approve | reject | need_more_info, confidence: 0.8, // 置信度0-1之间 reasoning: 你的分析理由... }函数调用Function Calling的妙用对于需要触发具体业务动作的场景我们利用大模型的函数调用能力。例如当模型分析认为“需要补充收入证明”时它可以调用一个预定义的requestAdditionalDocument()函数我们的系统接收到这个调用请求后就会自动向用户发起材料补交通知。这实现了从“分析”到“行动”的闭环。3.3 两者之间的数据流转与协同协议这是整个架构的“粘合剂”设计好坏直接决定系统是否顺畅。状态标志位设计我们在核心的领域对象如LoanApplication中设计了一系列状态标志位作为两个引擎之间的“通信信号”。public class LoanApplication { // ... 其他字段 private String ruleEngineStatus; // “PASSED”, “REJECTED”, “NEED_REVIEW” private String reviewTriggerReason; // 规则引擎触发复核的原因码 private LLMReviewResult llmReviewResult; // 大模型分析结果的封装对象 private String finalDecision; // 最终决策 }规则引擎执行完毕后会设置ruleEngineStatus和reviewTriggerReason。下游的决策协调服务根据这些状态决定是否调用、以及如何调用大模型。决策协调服务这是一个轻量的服务层它不包含业务逻辑只负责流程编排接收业务请求初始化领域对象调用规则引擎。解析规则引擎输出。如果状态为NEED_REVIEW则根据reviewTriggerReason组装对应的提示词模板调用大模型服务。接收大模型返回的结构化结果如JSON将其解析并更新到领域对象。执行最终的决策逻辑这里可能是一个简单的规则如“规则拒绝则最终拒绝规则通过且大模型建议批准则最终批准”也可能是一个更复杂的加权投票机制。这个最终逻辑本身也可以配置成一条高优先级的规则放在Drools中执行实现逻辑的集中管理。异步与降级考虑大模型调用可能耗时较长几秒对于实时性要求高的场景可以采用异步策略规则引擎快速返回“已提交复核”后续结果通过消息队列或WebSocket推送。同时必须设计降级方案当大模型服务不可用时系统能自动 fallback 到纯规则流程或直接转人工保障核心业务不中断。4. 实操过程与核心环节实现4.1 环境搭建与基础配置我们以Spring Boot为基础框架进行集成。Drools集成在pom.xml中添加依赖dependency groupIdorg.kie/groupId artifactIdkie-spring/artifactId version7.73.0.Final/version /dependency配置KieContainerBean让它从类路径或指定的Git仓库加载我们的规则文件.drl,.xlsx决策表。Configuration public class DroolsConfig { Bean public KieContainer kieContainer() { KieServices ks KieServices.Factory.get(); KieFileSystem kfs ks.newKieFileSystem(); // 从指定目录加载所有规则文件 ResourcePatternResolver resourcePatternResolver new PathMatchingResourcePatternResolver(); Resource[] resources resourcePatternResolver.getResources(classpath*:rules/**/*.drl); for (Resource resource : resources) { kfs.write(ResourceFactory.newUrlResource(resource.getURL())); } KieBuilder kieBuilder ks.newKieBuilder(kfs).buildAll(); KieModule kieModule kieBuilder.getKieModule(); return ks.newKieContainer(kieModule.getReleaseId()); } }大模型服务抽象定义LLMService接口public interface LLMService { LLMResponse chatCompletion(LLMRequest request); JsonNode functionCall(LLMRequest request, ListTool tools); }实现HunyuanServiceImpl内部使用混元官方SDK或封装HTTP客户端。同时可以写一个OllamaServiceImpl作为备用或用于本地测试。4.2 核心决策流水线实现以下是决策协调服务中核心方法processApplication的简化伪代码Service public class DecisionOrchestrationService { Autowired private KieContainer kieContainer; Autowired private LLMService llmService; Autowired private ApplicationRepository appRepo; public LoanApplication processApplication(LoanApplication app) { // 阶段1: 规则引擎执行 KieSession kieSession kieContainer.newKieSession(); kieSession.insert(app); kieSession.fireAllRules(); // 触发所有匹配规则 kieSession.dispose(); // 阶段2: 根据规则结果判断是否需要大模型介入 if (NEED_REVIEW.equals(app.getRuleEngineStatus())) { // 根据复核原因码选择提示词模板 String promptTemplate selectPromptTemplate(app.getReviewTriggerReason()); // 填充模板构建完整的LLM请求 LLMRequest request buildLLMRequest(app, promptTemplate); // 调用大模型 LLMResponse response llmService.chatCompletion(request); // 解析响应更新申请对象 LLMReviewResult reviewResult parseLLMResponse(response); app.setLlmReviewResult(reviewResult); // 触发最终决策规则可能是一条单独的规则 executeFinalDecisionRule(app); } else { // 规则引擎已有明确结论通过/拒绝直接作为最终决策 app.setFinalDecision(app.getRuleEngineStatus()); } // 保存并返回结果 appRepo.save(app); return app; } private void executeFinalDecisionRule(LoanApplication app) { // 可以再次创建一个简单的KieSession只包含最终决策的规则 // 或者直接在这里编写简单的Java逻辑 if (REJECTED.equals(app.getRuleEngineStatus())) { app.setFinalDecision(REJECTED); } else if (APPROVE.equals(app.getLlmReviewResult().getSuggestion())) { app.setFinalDecision(APPROVED); } else { app.setFinalDecision(MANUAL_REVIEW); } } }4.3 规则可视化编辑器的前端对接前端使用React/Vue通过组件库构建规则画布。当用户拖拽配置完一个规则节点例如“申请金额 10万”前端会将其序列化为一个JSON结构。这个结构描述了规则的条件Left Hand Side, LHS和动作Right Hand Side, RHS。后端提供一个/rule/compile接口接收这个JSON将其转换为Drools DRL语法。转换器需要处理各种操作符、字段类型和内置函数。生成的DRL文件会被保存到规则仓库如Git并触发一个规则重载的机制例如通过Drools的KieScanner或发送一个刷新事件到KieContainer。实操心得规则可视化不是为了取代DRL而是为了降低入门门槛。复杂的、性能关键的规则仍然建议直接编写DRL。可视化编辑器产出的DRL一定要有回显和预览功能让高级用户能够看到并微调生成的代码这是一个很好的“兜底”和学习机制。5. 常见问题与排查技巧实录在实际开发和上线过程中我们踩了不少坑也积累了一些排查经验。5.1 规则引擎侧典型问题问题1规则不生效或执行顺序不符合预期。排查步骤检查事实插入用日志或调试器确认你的领域对象是否被正确插入到KieSession中。常见错误是插入了对象但对象内部为null的字段没有初始化导致规则条件匹配不上。检查规则条件语法DRL语法严格特别是字段类型和操作符。Customer(age 18)和Customer(age “18”)天差地别。检查salience和agenda-group高salience的规则优先执行。如果使用了agenda-group需要显式调用kieSession.getAgenda().getAgendaGroup(“group-name”).setFocus()来激活该组规则。查看规则匹配情况启用Drools的日志级别为DEBUG可以看到哪些规则被激活Activation这非常有用。技巧为重要的规则在RHS部分添加日志输出如System.out.println(“规则[高风险检查]被触发应用于客户” $customer.getName());这是最直接的调试方式。问题2性能瓶颈规则匹配慢。排查步骤分析规则复杂度规则条件中是否包含大量的eval()或复杂的函数调用这些会严重拖慢匹配速度。尽量将计算移到规则外部以事实属性field的形式插入。检查事实数量是否向工作内存中插入了过多不必要的事实只插入与当前会话相关的事实。审视Rete网络过于复杂的规则交叉引用会导致Rete网络膨胀。考虑使用ruleflow-group或agenda-group对规则进行分段执行减少单次匹配的规则数量。技巧使用Drools提供的StatelessKieSession替代StatefulKieSession如果场景允许。前者在执行后不保留会话状态开销更小。5.2 大模型侧典型问题问题1大模型响应不稳定时好时坏。排查步骤固定随机种子和温度在API调用中明确设置temperature0.1甚至0和seed参数。这能极大减少生成结果的随机性使输出更确定。审查提示词提示词是否模糊、有歧义是否提供了足够的上下文和示例尝试使用“少样本学习”Few-shot Learning在提示词中给出几个输入输出的例子。检查上下文长度是否超过了模型的最大上下文窗口超长的上下文可能导致模型忽略前面的关键指令。做好文本摘要和精炼。模型本身波动接受大模型服务本身可能存在的不稳定性。对于关键应用实现重试机制和多个模型的fallback策略。技巧建立“提示词版本库”。每次对提示词的修改都记录版本和测试结果。当模型行为异常时首先回滚到最近一个稳定的提示词版本进行对比测试。问题2大模型输出格式不符合要求JSON解析失败。排查步骤强化格式指令在提示词中明确要求并使用三重反引号标记JSON部分。例如“你的输出必须是如下JSON格式不要有任何其他解释json {...}”。使用函数调用如果API支持优先使用函数调用功能。模型会返回一个结构化的函数调用请求其参数就是你定义的JSON Schema解析成功率接近100%。后处理与容错在解析JSON的代码中加入健壮的容错逻辑。例如使用JsonNode进行宽松解析或者使用正则表达式从返回文本中提取JSON片段。记录解析失败的原始响应用于优化提示词。技巧在开发阶段用一个“提示词测试沙盒”页面快速验证不同提示词下模型的输出格式稳定性这是提高效率的利器。5.3 协同与系统集成问题问题规则与大模型判断冲突如何裁决这是架构设计之初就要想好的。我们的策略是“规则优先大模型辅助”。规则引擎的硬性拒绝如黑名单是最终裁决没有商量余地。对于规则引擎标记为“需复核”的灰色地带大模型的建议会与规则引擎的风险评分等输出一起呈现给最终决策者可能是另一个规则也可能是人工。我们设计了一个“置信度加权”机制大模型输出的confidence分数会作为一个权重因子影响最终决策分数。同时所有决策路径都必须完整记录日志包括规则触发轨迹和大模型的输入输出以满足审计和可解释性要求。问题如何对这套混合系统进行测试测试需要分层进行单元测试单独测试每一条核心DRL规则。使用Drools的测试工具给定输入事实断言输出结果。集成测试测试规则集与大模型服务的集成。这里需要Mock大模型服务模拟其返回各种预定好的响应如批准、拒绝、需要更多信息来验证整个决策流水线的逻辑是否正确。端到端测试使用历史数据或构造的测试用例运行完整的系统验证最终业务结果。大模型专项测试构建一个涵盖边界案例、对抗性问题的测试集定期如每周用生产环境的提示词跑一遍监控大模型输出质量的变化漂移。这套“规则引擎大模型”的架构本质上是在追求一种“可控的智能”。它承认大模型的不完美用规则的确定性为其划定舞台和底线同时也利用大模型的泛化能力突破规则系统的僵化边界。在实施过程中最深的体会是技术融合的成功一半在于技术选型和架构设计另一半在于对业务场景的深度理解——你必须非常清楚业务的哪些部分必须“铁板一块”哪些部分可以“灵活应变”。这个分界点的把握才是项目成败的关键。