业务智能体实战笔记:分层消除不确定性(五·终)｜完全脱离 LLM 的确定性判定 + 评测闭环

业务智能体实战笔记:分层消除不确定性(五·终)完全脱离 LLM 的确定性判定 评测闭环在之前的几篇笔记中我们探讨了如何通过分层架构、规则引擎、知识图谱等手段来降低智能体在业务场景中的不确定性。但很多朋友问有没有一种办法让智能体彻底摆脱LLM的“猜谜游戏”直接给出确定的结果答案是有这篇最终篇我将带大家实现一个完全脱离LLM的确定性判定系统并搭建评测闭环来验证效果。## 为什么需要“确定性判定”先来回顾一下痛点在金融风控、医疗诊断、工业质检等场景中LLM的“概率性输出”简直就是灾难。比如- 用户问“我的贷款申请被拒的原因是什么”LLM可能回答“可能是信用评分不足”但实际原因是“收入证明缺失”。- 客服场景中LLM说“我帮您查询一下”然后开始胡编乱造。这些不确定性会直接导致业务损失。所以我们希望在关键决策点上用纯代码逻辑替代LLM让结果100%可复现、可审计。## 分层架构中的“确定性层”回顾下我们的分层设计-感知层处理用户输入语音转文字、OCR等-推理层LLM负责理解意图、生成策略-执行层调用API、操作数据库-判定层完全脱离LLM用规则数据驱动判定层的核心是所有业务规则都写成可执行的代码不依赖任何外部模型。下面我们通过一个贷款审批场景来演示。## 代码示例1确定性规则引擎假设我们要判断一个贷款申请是否通过规则如下- 信用分≥600通过- 信用分在500-599之间需要人工审核- 信用分500拒绝- 若用户有逾期记录则直接拒绝python# deterministic_loan_checker.py完全脱离LLM的贷款规则引擎所有判定逻辑均为确定性代码无任何概率输出class LoanRuleEngine: def __init__(self): # 定义黑名单规则硬编码也可从数据库加载 self.blacklist [张三, 李四] def check_credit_score(self, score: int) - str: 信用分判定返回确定性结果 if score 600: return APPROVED elif 500 score 600: return MANUAL_REVIEW else: return REJECTED def check_overdue(self, overdue_days: int) - bool: 逾期检查有逾期直接标记为高风险 return overdue_days 0 def evaluate(self, applicant: dict) - dict: 综合评估返回结构化判定结果 name applicant.get(name, ) score applicant.get(credit_score, 0) overdue applicant.get(overdue_days, 0) # 第一步黑名单检查确定性 if name in self.blacklist: return { decision: REJECTED, reason: 黑名单用户, code: BLACKLIST } # 第二步逾期检查确定性 if self.check_overdue(overdue): return { decision: REJECTED, reason: f存在逾期记录({overdue}天), code: OVERDUE } # 第三步信用分判定确定性 decision self.check_credit_score(score) if decision APPROVED: return { decision: APPROVED, reason: f信用分{score}达标, code: CREDIT_OK } elif decision MANUAL_REVIEW: return { decision: MANUAL_REVIEW, reason: f信用分{score}需人工审核, code: NEED_REVIEW } else: return { decision: REJECTED, reason: f信用分{score}不达标, code: CREDIT_LOW }# 测试用例if __name__ __main__: engine LoanRuleEngine() # 用例1黑名单用户 applicant1 {name: 张三, credit_score: 700, overdue_days: 0} print(engine.evaluate(applicant1)) # 输出REJECTED # 用例2信用分达标 applicant2 {name: 王五, credit_score: 650, overdue_days: 0} print(engine.evaluate(applicant2)) # 输出APPROVED # 用例3信用分中等但有逾期 applicant3 {name: 赵六, credit_score: 550, overdue_days: 10} print(engine.evaluate(applicant3)) # 输出REJECTED因为逾期关键点这段代码中没有任何if random或概率逻辑每个分支都对应明确的业务规则。当LLM输出“用户信用分不足”时我们实际调用的是这个引擎而不是让LLM自己判断。## 评测闭环从“感觉”到“数据”光有确定性还不够我们需要一个闭环来验证1.单元测试每个规则都有对应的测试用例2.回归测试修改规则后自动运行所有历史用例3.效果监控统计正确率、误判率、漏判率下面是一个简单的评测框架python# evaluation_framework.py确定性判定的评测闭环包含单元测试 回归测试 统计报告import jsonfrom datetime import datetimeclass EvaluationFramework: def __init__(self, rule_engine): self.engine rule_engine self.test_cases [] # 存储所有测试用例 self.results [] # 存储测试结果 def load_test_cases(self, file_path: str): 从JSON文件加载测试用例 with open(file_path, r, encodingutf-8) as f: self.test_cases json.load(f) print(f已加载 {len(self.test_cases)} 个测试用例) def run_all_tests(self) - dict: 运行所有测试用例返回统计报告 passed 0 failed 0 details [] for i, case in enumerate(self.test_cases): input_data case[input] expected case[expected] # 执行判定 actual self.engine.evaluate(input_data) # 比较结果 is_match actual[decision] expected[decision] if is_match: passed 1 else: failed 1 details.append({ case_id: i, input: input_data, expected: expected, actual: actual }) # 生成报告 report { timestamp: datetime.now().isoformat(), total: len(self.test_cases), passed: passed, failed: failed, pass_rate: f{(passed/len(self.test_cases))*100:.2f}%, failed_details: details } return report def regression_test(self, new_rules: dict None): 回归测试如果修改了规则重新运行所有历史用例 print(开始回归测试...) report self.run_all_tests() if report[failed] 0: print(回归测试失败以下用例需要关注) for detail in report[failed_details]: print(f 用例{detail[case_id]}: 期望{detail[expected]}实际{detail[actual]}) else: print(回归测试全部通过) # 保存报告 with open(fregression_report_{datetime.now().strftime(%Y%m%d_%H%M%S)}.json, w) as f: json.dump(report, f, ensure_asciiFalse, indent2) return report# 使用示例if __name__ __main__: from deterministic_loan_checker import LoanRuleEngine engine LoanRuleEngine() evaluator EvaluationFramework(engine) # 模拟加载测试用例 test_data [ {input: {name: 正常用户, credit_score: 700, overdue_days: 0}, expected: {decision: APPROVED}}, {input: {name: 黑名单用户, credit_score: 800, overdue_days: 0}, expected: {decision: REJECTED}}, {input: {name: 逾期用户, credit_score: 650, overdue_days: 5}, expected: {decision: REJECTED}}, ] # 手动添加测试用例实际中应从文件加载 evaluator.test_cases test_data # 运行测试 report evaluator.run_all_tests() print(f通过率: {report[pass_rate]}) # 模拟修改规则后的回归测试 print(\n--- 假设修改了规则 ---) evaluator.regression_test()这个框架可以-自动验证每次修改规则后一键运行所有用例-生成报告包含失败详情方便定位问题-支持增量新规则加入后历史用例仍可复用## 如何与LLM协同你可能会问那LLM还有什么用答案是LLM负责“翻译”规则引擎负责“判定”。完整的流程是1. 用户问“为什么我的贷款被拒”2. LLM理解意图提取关键信息姓名、申请号等3.LLM调用规则引擎而不是自己推理4. 规则引擎返回确定性结果如“信用分不足”5. LLM将结果包装成自然语言回复这样LLM的“不确定性”被限制在第一步理解用户意图而核心业务逻辑完全由代码掌控。## 总结这篇最终篇的核心思想是在业务智能体中用确定性代码替代LLM做关键决策。通过分层架构我们将“判定层”完全独立出来用规则引擎评测闭环确保结果100%可信。几个关键收获1.确定性优先凡是能用代码规则解决的问题绝不交给LLM2.评测闭环没有评测的确定性都是空话必须建立自动化测试体系3.分层协同LLM负责模糊理解代码负责精确执行各司其职最后送给大家一句话智能体的终极目标不是让LLM无所不能而是让每个决策都有据可查。希望这系列笔记能帮你在业务中真正落地智能体而不是停留在“玩具阶段”。全系列完