分层消除不确定性(五·终)｜完全脱离 LLM 的确定性判定 + 评测闭环

概述前文三层方案仍会让LLM参与判断流程存在概率性出错风险第四层核心思路把结构化运算、业务口径校验全部交由工程代码执行LLM仅负责识别用户意图、编排工具调用参数不参与任何数值、业务规则判定。整套方案由三部分构成存在明确依赖顺序data_filter通用结构化数据处理解决算错、漏字段、图表错乱业务硬约束兜底LLM无法识别的专属业务口径评测闭环提供量化跑分能力让所有优化动作可验证、可迭代。全文最大复盘结论如果重新落地业务智能体第一件事搭建评测闭环再做业务逻辑优化能大幅缩短迭代成本。一、什么算「完全脱离 LLM 」本层与前三层核心差异本层处理不依赖 LLM。LLM 仍负责意图识别与工具编排但不再接触数据、不做数值运算、不判业务规则。四层路径核心区别汇总如下分层阶段 LLM参与形式 核心定位前置拦截第二篇 LLM不做决策仅消费拦截结果 提前过滤无效/高危请求收窄决策空间第三篇 LLM主导决策可选范围被压缩 降低模型选错概率兜底修复第四篇 LLM先输出结果代码事后校验纠错 事后修复模型错误确定性判定本篇 LLM完全不进入判断链路 纯代码执行计算、口径校验统一分工原则LLM定「做什么」工程侧定「怎么算」。举例用户提问“统计6月工单完成量并生成柱状图”LLM仅识别需求输出data_filter工具调用参数过滤、分组、计数、绘图全部由Java代码执行模型全程不接触原始数据、不做任何数学运算。二、data_filter结构化数据从 LLM 侧完全搬到工程侧背景痛点LLM在文本流中处理结构化数据存在天然缺陷数据量大易漏字段、分组统计串维度、排序逻辑混乱仅靠提示词无法根治。解决方案新增纯Java工具data_filter将所有结构化数据运算迁移至工程层LLM仅负责发起工具调用、传递操作参数过滤、聚合、排序、绘图等确定性计算全部由代码承载。2.1 五大原子操作ToolCallback对外仅暴露5类基础算子支持自由链式组合LLM无需在上下文内完整推演全链路仅需分步下发指令操作 输入参数 输出 业务用途filter 字段 条件表达式 过滤后数据子集 缩小数据集范围group_count 分组维度字段 {分组值: 统计数量} 按维度聚合计数sort 排序字段 升降序标识 完整有序数据集 数据排序count 无基于当前上下文数据集 数据总行数 统计总量to_chart 图表类型 字段映射关系 标准化图表JSON 生成可视化图表组合调用示例用户需求筛选2026年6月工单按工单状态分组统计输出柱状图执行链路filter(创建时间2026-06) → group_count(status) → to_chart(柱状图)to_chart彻底解决前文图表JSON字段错位问题固定映射规则由代码维护不再依赖LLM拼接图表结构。2.2 三条核心隔离约束三条约束共同将数据、计算逻辑与LLM彻底隔离保障结果稳定原始数据不经过LLM统一从SessionContext读取SessionContext为会话级隔离存储单用户单次查询的数据独立存放多用户并发不会串数据。data_filter入参仅携带字段名、条件不含原始业务数据规避海量业务数据挤占上下文token杜绝LLM转述数据时丢字段、篡改数值、丢失小数精度。仅处理存量数据不负责底层数据查询数据查询由MCP/Skill业务工具完成查询结果写入SessionContext后data_filter才可触发。实现关注点分离业务工具负责“取数”data_filter负责“加工数”职责互不越界。中间操作回写上下文终态操作不落地中间操作filter/sort处理完成后替换SessionContext当前数据集支持连续链式调用无需LLM记忆上一步结果终态操作count/group_count/to_chart输出结论供LLM组装回答不更新上下文不可作为后续计算原料。2.3 LLM与工程侧完整协作流程用户输入业务查询PreprocessEngine 预处理实体识别 消歧有歧义则短路追问LLMReactAgent ReAct 循环识别意图判断需要获取数据LLM 发出 tool_call调用 mcp_* 或 skill_* 工具获取原始业务数据工具执行完成后结果经 ToolResultNormalizer 归一化为 {records, total, summary} 并写入 SessionContext以 threadId 为 key可选LLM 再次发出 tool_call调用 data_filter 对 SessionContext 中的数据进行 filter → group_count → sort → to_chart 等二次加工data_filter 的中间结果回写 SessionContext支持链式调用LLM 综合所有工具返回结果生成最终自然语言回复。2.4 收益说明对照实验条件200条结构化数值类测试用例仅替换原生LLM计算逻辑、接入data_filter模型、提示词、采样参数完全不变。准确率提升Delta10~13pt收益来源一次性解决数值计算错误、字段遗漏、图表结构错乱三类高频问题把结构化数据处理从概率系统转为100%稳定的确定性系统。局限性data_filter 仅处理已加载至 SessionContext 内存的数据集不连接数据库、不做 SQL 优化。超大数据集万行级需由上游 MCP / Skill 先做分页预取再写入上下文data_filter 本身不解决数据量问题。三、特定场景硬约束data_filter解决通用数值运算问题但仍存在大量业务专属口径场景无法通用化处理必须在代码层硬编码约束兜底。本节围绕三点展开硬编码必要性、低成本管理方案、暂缓落地规则引擎的理由。3.1 必须硬编码的三类场景核心矛盾业务真值口径属于企业内部定义无法通过通用语言语义让LLM稳定识别这类场景存在三大共性业务口径与通用语义割裂例如工单场景“完成”通用语义仅代表结束但业务明确限定status0LLM无法自主推断业务状态定义无天然语义映射通路。错误无异常告警隐蔽性极强工具调用流程正常、返回格式合规仅业务数字错误普通响应校验只能识别格式崩溃无法判断业务口径对错模型无法自主纠错。容错代价严重不对称单次正确回答无正向感知一次口径错误会直接丧失用户对产品数据可信度软约束“大概率正确”无法抵御此类高风险场景。3.2 硬编码的价值取舍硬约束本质将业务口径判断从概率LLM体系迁移至确定性代码。优势if-else规则100%稳定触发、无语义漂移、可单条单元测试、支持回归验证短板新增业务规则需要服务发版灵活性弱。企业BI智能体场景下“保证核心指标绝对准确”优先级高于快速迭代该取舍具备工程合理性。3.3 硬约束轻量化管理记账法不急于抽象、不直接上规则引擎采用低成本文档记账管控硬约束持续膨胀避免无边界补丁堆积。新增任意一条硬约束同步记录5项信息Markdown表格即可落地硬约束 ID 业务口径 为什么 LLM 判断不了 理想解法 引入日期HC-001 工单场景完成指 status0 语料里完成的语义与业务状态无桥可通 BI 层暴露口径元数据,替代硬编码 2026-06-15HC-002 本月以创建时间完成时间双口径回答 LLM 无法可靠选择时间维度,业务上两者都可能是用户意图 需求侧规定统一表述,或在 BI 层拆成两个显式指标 2026-06-20配套落地规范维护人后端开发复盘周期每2周统一梳理约束清单抽象触发阈值同类约束累计≥8条启动公共抽象层设计。字段作用说明硬约束ID唯一编号用于复盘、需求追溯业务口径清晰描述本条规则校验范围为什么LLM判断不了留存原始痛点避免后续盲目回退软约束理想解法沉淀长期优化方向积累多条后提炼公共抽象引入日期观察约束增长密度密集新增代表需要顶层抽象。3.4 暂缓落地规则引擎的原因当硬约束积累到一定数量极易产生“配置化规则引擎”的想法但现阶段不推荐优先落地规则引擎仅将代码补丁迁移至YAML配置未解决“新增业务口径就要新增一条规则”的底层问题系统复杂度无下降业务人员缺乏数据建模能力自行配置极易产生口径冲突配置规则无配套单元测试变更后无法自动回归校验多层规则解析增加查询链路开销拖慢数值查询响应速度。最优路径先记账沉淀场景规律待共性模式浮现后再做抽象层设计而非提前搭建配置系统。3.5 收益说明对照实验条件基于已上线data_filter能力仅新增状态拦截、双时间补跑两类硬约束其余逻辑不变。准确率提升Delta2~4pt分数提升幅度有限但核心价值是拦截“一次错误就丢失用户信任”的高危业务场景量化分数无法体现该隐性价值。四、评测闭环全系列最关键的经验教训整套优化体系唯一后悔的决策评测闭环搭得太晚。前期靠人工观察和感觉调参浪费了大量时间。如果重新做一遍我会先把评测搭起来再动其他任何东西。4.1 真值集共建机制开发测试协同真值集是评测体系核心基准单一方独立搭建都会出现偏差固定协作流程测试人员输出全覆盖测试用例定义每条用例标准期望结果覆盖边缘、模糊、多维度组合查询开发人员校验期望结果的工程可行性、业务口径正确性与测试对齐标准双方达成共识后结构化存储用例支持自动化脚本批量读取跑分。协作价值互补测试保障场景覆盖度开发规避无法稳定复现的无效用例。真值集构建还需保证数据分布均衡70% 来自线上真实用户 query30% 为人工构造的边界与长尾 case避免纯合成数据导致的离线高分、线上衰减。4.2 多维度跑分判定口径先统一准确率口径准确率 判定通过的用例数 ÷ 评测用例总数 × 100%。单条用例「通过」指实际输出与期望值的偏差落在下述容差范围内。查询分为数值型、分类型、聚合百分比三类不能使用同一套判定标准统一设计容差规则适配业务天然误差时间戳精度、聚合窗口、四舍五入。单数字判定公式∣expect−actual∣≤max(0.5, expect×0.5%)逻辑说明大数采用0.5%相对误差小数采用0.5绝对差值兜底兼顾两类场景合理性。示例1预期值10000允许误差50业务口径微调、四舍五入全部兼容示例2预期值3允许误差0.5不会因差值1误判小数量场景失败。百分比合计校验整体合计允许2%误差区间。容差设计初衷拒绝严格全等匹配避免把业务无差异的正确结果判定为失败容差区间经过业务侧确认可吸收工程侧无关扰动。4.3 选用外挂Python评测脚本的原因内部Java框架仅支持LLM软评分改造数值精确打分改造成本高、周期长外挂Python是低成本落地方案具备三大优势判定完全确定性同一用例多次跑分结果一致无随机波动零推理成本无需调用裁判LLM批量跑分无额外token开销问题可审计直接输出「期望数值 vs 实际数值」快速定位口径错误。极简脚本目录参考可直接复制落地eval/├── truth_dataset.json # 真值测试用例库├── run_eval.py # 批量跑分主程序├── judge_logic.py # 数值容差判定函数└── report_output.txt # 跑分结果、失败用例日志judge_logic.py 核心判定函数def is_match(expect: float, actual: float, tolerance_pct: float 0.005) - bool:“”“大数比例、小数绝对一个阈值覆盖两端”“”threshold max(0.5, abs(expect) * tolerance_pct)return abs(expect - actual) threshold4.4 放弃LLM裁判选用真值集的核心理由业界主流方案分为「LLM裁判打分」「真值基准打分」本文选择后者LLM裁判存在三大硬缺陷结果不稳定同一用例两次跑分得分不一致评估误差叠加无法区分是优化失效还是裁判模型波动运行成本高每条用例额外发起一次LLM调用大规模评测集成本成倍上涨不适合数值场景数值对错是二元客观事实LLM主观评判会引入模糊误差。核心结论能使用确定性基准判定的场景绝不引入概率化LLM作为评判标准数据库查询得到的真值具备唯一性是最