系列说明:这是「业务智能体准确率从 65% 到 85%」系列的第一篇,共 5 篇。首篇讲主线和全景,后 4 篇按四层方法论分别展开。文末有系列导读。
结论先说
准确率从 65% 提升到 85%,三四周,由我独立完成。
核心思路------把不确定性从 LLM 侧转移到工程侧。
- 这不是事后总结,是多次迭代提示词、发现收益递减后,形成的整套调优思路;
- 它覆盖全部 11 个模块,可拆分为四层逻辑:前置拦截 LLM、收窄 LLM 决策空间、兜底修复 LLM 异常、完全脱离 LLM 的确定性判定;
- 后续 4 篇会分层讲解,本篇只讲主线、架构、收益全景,和最后悔的一件事。
收益最大 :LLM 不擅长结构化数据处理,通过 data_filter 将全部结构化运算迁移至工程侧,单项提升 10pt 以上。
最后悔:评测闭环搭建太晚,搭建后迭代节奏清晰,前期无量化调优浪费大量时间。这两点正文会详细展开。
背景
我们的 AI 基础能力平台接入了各家主流 LLM,产出各类 AI 能力,包括通用业务智能体。业务智能体与运维业务结合落地时,发现准确率低,低到没法交付 。我独立承担了提升业务智能体准确率这项任务,三四周,准确率从 65% 提升到 85% 以上。业务实际使用 Qwen,底层框架是 Spring AI Alibaba 的 ReactAgent。
下面交代评测集、打分口径、时间跨度三件事,作为全文的可信度地基。
评测集:分智能体独立维护的真值集------智能体 A 覆盖工单场景多类统计意图,智能体 B 覆盖巡检场景多类查询意图。
打分口径 :端到端任务完成率------意图识别 → 工具调用 → 答案组织,三段都对才算对。这个分不是我自己打的------独立测试人员做的全面端到端测试,外挂 Python 评测脚本提供数据支撑,人和工具协作打出的最终验收分。
为什么按 85% 报 :实际准确率在 85% 以上、部分场景到 95%,但其中一部分是特定场景硬约束贡献的------能过评测集,但换个数据分布不一定稳。按可迁移的下沿报,才对得起读者能否复用。
时间跨度:三四周。
核心思路:把不确定性从 LLM 侧转移到工程侧
所有动作均围绕一条主线:保留 LLM 擅长的语义工作,将它不擅长的处理下沉至工程侧。
每遇到一个问题,先问自己------这件事该 LLM 做,还是工程侧做?
- 生成一段自然语言回答 → LLM 侧
- 从上百条工单里数出「已完成」有多少条 → 工程侧
- 把用户口中的「上个月」翻译成
startTime/endTime→ LLM 侧 - 判断「上个月」到底指创建时间还是完成时间(业务口径) → 工程侧
判断准则还要再加一条:LLM 能做的事,不代表就该让它做。业务智能体这类场景,错答的损失远大于计算成本------能放到工程侧就放到工程侧。
四层方法论:全篇的骨架
四层是同一条主线在不同环节的具体化,方向不同,意图一致。
| 层次 | 判断依据 | 系列篇章 |
|---|---|---|
| 一、前置拦截 LLM | 在推理前挡住不可靠判断 | 第 2 篇 |
| 二、收窄 LLM 决策空间 | 保留语义决策,收窄候选范围 | 第 3 篇 |
| 三、兜底修复 LLM 异常 | 事后判定异常输出并纠错 | 第 4 篇 |
| 四、确定性判定 | 完全脱离 LLM,交由工程侧执行 | 第 5 篇 |
第一层:前置拦截 LLM
代表动作:消息预处理(业务对象消歧、格式规范化)、两步 RAG 里的前置强制检索、工具选择前的状态歧义拦截。
这一层的原则是按"事后能否兜底"划线:可事后判定和修复的问题,交给后置校验;事后无从识别的问题,必须在推理前拦截。
漏检索是典型的后一类------模型基于缺失信息生成看起来完整的回答,响应里没有任何特征让代码判定"这次漏了检索"。类似地,LLM 虽然支持自主澄清,但慢、贵、不稳三条决定了业务智能体不能把口径确认交给模型自己判断,必须提前统一。
第二层:收窄 LLM 决策空间
代表动作:提示词工程、采样参数收窄(temperature/top_p 从通用对话挡收到工具调用挡,presence_penalty 归零贴住检索内容)、业务数据预加载、工具信息分层注册。
这一层保留 LLM 的决策权,只是压缩它能出错的空间。65% → 75% 的第一阶段红利,主要来自提示词工程 + 采样收窄 + 消息预处理三件事的同期动作。但它有天花板------我在提示词上改了 59 版才认清:越写越多、越细、越场景化,智能体反而更不听话。
采样这块有一个反直觉的现场,值得在总纲里点一下。
一开始我按业界「通用对话」的经验值起步,顾虑是「过锐会失稳、表达机械」。评测闭环搭起来后,把参数收到「工具调用类任务」更收敛的一档------失稳没出现,反而更稳。
事后想清楚,是原来的顾虑场景错配了。低温失稳的经验来自创作型任务:答案空间宽、需要多样性。业务智能体恰恰相反:答案空间窄、tool_call 是 JSON 协议、输出是短结论。场景对了,收敛档就是天然更稳的档位。
采样层真正做收窄的是三件正交的事:temperature + top_p 的双重约束(logits 尖化 + 词表截断,叠加不是重复),再加 presence_penalty 归零贴住检索内容。至于并行 tool_call 关掉、group 层温度覆盖、响应层规整包装------它们是平台侧的正交能力,和"为什么低温稳"没有因果关系,不要混进采样的账里。
细节和 59 版提示词的坑放在第 3 篇。
第三层:兜底修复 LLM 异常
代表动作:工具加强(自定义字段纠错、参数校验)、响应验证(伪代码检测、假阴性检测、图表数据静默对齐)、双时间字段的加法式补跑。
前两层都是事前------挡在前面或收窄空间。第三层承认一件事:再压再挡,模型仍会出现异常输出,必须有兜底。
响应验证里最典型的是「伪代码异常」:模型没真调工具,却直接把工具调用表达式当答案返回给用户,比如输出一行 (某工具名(status=0, groupBy='none')) 就结束了。我用三个条件同时命中来判定:短(< 200 字符)+ 表达式占比高(> 40%)+ 本次 toolResult 为空------三条同时命中才判异常,少一条都会误伤正常场景。三个阈值来自「异常 = 短 + 复读 + 未执行」的画像,画像变了要重标。
这一层的价值不完全体现在分数上------它把非确定性故障从「偶发投诉」降级成「链路自动处理」,可观测、可回归、可迭代 ,这对交付信心的提升比分数本身重要得多。细节放在第 4 篇。
第四层:完全脱离 LLM 的确定性判定
代表动作:data_filter(结构化数据处理)、特定场景硬约束(业务口径钉死)、评测闭环(真值集 + 数值容差)。
第四层最纯粹------动作完全脱离 LLM ,是主线最深的应用。data_filter 是一个纯 Java 的 ToolCallback,对外只暴露五个原子操作(filter/group_count/sort/count/to_chart);数据不由 LLM 传,而是从 SessionContext 里读------LLM 定「做什么」,工程侧定「怎么算」。这一步同时解决了算错、漏字段、图表乱三类结构化数据错误。
评测闭环也在这一层------不走「LLM 当裁判」的主流路线,用真值集加数值容差硬判定。数据库查询的结果是唯一的,能用确定性判定的地方,别请概率过来当裁判 。细节放在第 5 篇,也是「最后悔的一件事」所在。
全景架构图
链路图如下,后 4 篇的模块可在图上定位。图里只保留每个模块动过的关键节点,省略了权限、审计、熔断等与准确率不直接相关的通用组件。
flowchart TB User用户消息 Preprocess消息预处理\
消歧 · 短路 · 追问\
第 2 篇 Preload数据预加载\
SessionContext\
第 3 篇 FactoryBusinessAgentFactory\
意图路由 · 旁路开关\
第 3 篇 subgraph ReactAgentReactAgent 运行时 HookHook 链\
两步 RAG · 硬约束前置\
第 2 · 5 篇 LLMLLM 推理\
采样收敛 · 串行\
第 3 篇 InterceptorInterceptor 链\
响应验证 · 伪代码检测\
第 4 篇 end subgraph Tools工具适配器层 McpMcpAdapter\
回写 SessionContext SkillSkillAdapter DataFilterdata_filter\
5 个原子操作\
第 5 篇 end BackendMCP Server · Skill 引擎 · DB Frontend前端渲染\
图表静默对齐\
第 4 篇 Eval外挂 Python 评测\
真值集打分\
第 5 篇 User --> Preprocess --> Preload --> Factory --> Hook --> LLM --> Interceptor LLM -.tool_call.-> Tools Mcp --> Backend Skill --> Backend DataFilter -.读.-> Preload Tools -.结果.-> LLM Interceptor --> Frontend Frontend -.真值集对齐.-> Eval style DataFilter fill:#fff3cd,stroke:#856404 style Eval fill:#d1ecf1,stroke:#0c5460 style Preload fill:#d4edda,stroke:#155724
图里三个高亮:
- 黄色的
data_filter:收益最大的一步,单算 10 分以上 - 蓝色的评测闭环:最后悔搭晚的一件事
- 绿色的 SessionContext:把不确定性从 LLM 侧转移到工程侧的关键载体------工具间流转的数据不进 LLM,只在工程侧流转
四层与图上节点的对应:
- 前置拦截 LLM → 消息预处理、Hook 链前置
- 收窄 LLM 决策空间 → 预加载、意图路由、采样参数
- 兜底修复 LLM 异常 → Interceptor 链、前端静默对齐
- 完全脱离 LLM → data_filter、评测闭环
收益归因:收益分布在哪些环节
按收益段分四段,每段对应四层里的一层或几层。细账留给后 4 篇,首篇只做全景。
读表方式先说清楚 :下面表里的 Delta 是分开归因 的估算值,加总会超过实际 20pt------因为同期动作会被分别计入,不能直接相加。看每一段的相对权重比看加总更有意义。
| 收益段 | 累计 Delta(估算) | 主要对应四层 |
|---|---|---|
| 起点红利(65% → 75%) | +9 ~ +16pt | 第二层:收窄 LLM 决策空间(提示词 + 采样 + 消息预处理三件事同期) |
| 头部(单模块提升幅度最大) | +10pt 以上 | 第四层:确定性判定(data_filter 单算) |
| 腰部(工具处理) | +6 ~ +10pt | 第二层 + 第三层(工具注册 + 工具加强) |
| 尾部(每层各压一点) | +5 ~ +10pt | 第一层 + 第四层(预加载、两步 RAG、响应验证、硬约束) |
所有 Delta 均为估算,非精确测量。加总超过 20pt,三个原因:
- 同期动作的 Delta 会重复计入:起点红利里,提示词工程、采样收窄、消息预处理是同期动作,合计对应 65% → 75%。但它们各自那行的 Delta 加起来会超过 10pt,分开归因,加总不能再当独立收益读
- 相互抵消的负 Delta 没进表:比如提示词砍掉场景化那次是负向调整,归入起点红利的净收益里,但表里没单独列一行
- 精确分账靠评测闭环才能做 :如果评测闭环早点搭起来,每一行的 Delta 都能压到 ±2pt 以内、加总也能对齐 20pt------这也正是我唯一后悔的一件事
每一步的相对权重,比绝对数字更值得关注。按收益排序看:
- 头部 :data_filter 单算 10pt+------结构化数据处理彻底工程化,是全过程单模块提升幅度最大的一步
- 腰部:工具注册 + 工具加强合计约 6 ~ 10pt,是收益次高的一段
- 起点红利:提示词工程 + 采样收窄 + 消息预处理合计约 9 ~ 16pt,是必要地基,不是重复动作------继续压就撞墙
- 尾部:数据预加载、两步 RAG、响应验证、硬约束各 1 ~ 4pt,单独看都不惊艳,合起来是「每层把不确定性各压一点」的底盘
业界看到「提示词 +10pt」这种数字要小心:那通常是把预处理、采样、少样本的功劳一起算进去了。单靠提示词能拿到的天花板要保守得多------第 3 篇会展开这段账。
最后悔的一件事:评测闭环搭得太晚
我用外挂 Python 脚本做真值集回归跑分。这一步我做得太晚------前面几步靠人工观察和感觉调参,浪费了大量时间。
有一次教训特别深:砍掉某个提示词后,那类场景准确率反而下降 。来来回回反复很多次,我才意识到------没有评测闭环的调优就是猜谜。
评测闭环搭起来之后我才想通几件事:
- 正确率提升有了依据:前面每一步的 Delta 不再靠手感,可以直接跑一次量化。这也是为什么起点红利那段的账只能靠事后回忆估算------评测闭环没搭起来,提示词、采样、消息处理三者的功劳只能靠拆解归因,拆不精确
- 迭代周期从数小时缩短到数分钟:改一版跑一遍全量评测集,几分钟出结果,不用人工挨个试
- 防止回退:改一处涨了另一处跌了,人工肉眼看不出来,评测集能立刻发现
所以「评测闭环」这一步在系列里是压轴出场,但它不是补丁,是前提条件------前面十步能拿到手的所有 Delta,都建立在评测能量化的基础上。
如果重新做一遍,我会先把评测搭起来,再动其他任何东西。这不是感慨,是路径依赖------评测搭起来之后每一步都有据可依,搭之前只能靠感觉。
评测闭环本身怎么搭、真值集怎么建、数值容差公式 abs(expect - actual) ≤ max(0.5, expect × 0.5%) 怎么定、为什么不走 LLM 判分,放在第 5 篇------那一篇是本系列的压轴。
系列导读
后 4 篇按四层方法论分讲,每一篇独立成篇,可以单独看,也可以按顺序追下来。
第 2 篇:前置拦截 LLM
覆盖:消息预处理(业务对象识别 + 格式规范化 + 同步阻塞式消歧)、两步 RAG(前置强制检索替代 Agentic RAG)、工具选择前的状态歧义拦截。
关键判断:代码能兜住的决策才优化,兜不住的抢在前面。这一篇会解释「Agentic RAG 为什么听起来聪明实际不可控」------LLM 在「要不要检索」这件事上,行为不可预测,而且响应里看不到「我漏检索了」的信号,没法用代码兜住。
第 3 篇:收窄 LLM 决策空间
覆盖:提示词工程(59 版的教训、CoT/few-shot/role-play 三件套怎么用)、采样参数收窄(为什么"通用对话挡位"在业务智能体场景下场景错配、分两轮走的完整故事)、业务数据预加载(为什么不塞 RAG、不塞提示词)、工具信息分层注册(≤20 全量 / >20 两阶段路由 / >50 tag 检索的三档设计)。
关键判断:这一层能拿到 65% → 75% 的第一阶段红利,但有天花板。撞墙了别硬撞,别把三个模块的 Delta 一路累加。
第 4 篇:兜底修复 LLM 异常
覆盖:工具加强(自定义字段纠错 MCP 描述、参数校验的三种典型错法、值改写这条为什么后悔做了)、响应验证(伪代码检测的三条件为什么必须同时命中、200 字符和 40% 匹配率两个阈值怎么定的、图表数据静默对齐为什么没做成闭环)、双时间字段的加法式补跑。
关键判断:再压再挡 LLM 还是会抽风,你得有兜底。这一篇会讲一个反例------「值改写」是我做过、事后觉得越界的一件事,比精度损失更严重的是透明度损失。
第 5 篇:确定性判定 + 评测闭环(最后悔的一件事)
覆盖:data_filter(5 个原子操作 + 3 条关键约束 + 数据不进 LLM 的完整设计)、特定场景硬约束(为什么必须硬编码、为什么不做规则引擎、硬约束「记账法」模板)、评测闭环(真值集怎么建、数值容差公式怎么定、为什么外挂 Python 而不是 LLM 判分、真值集漂移怎么处理)。
关键判断:能用确定性判定的地方,别请概率过来当裁判。评测闭环这段是全篇的元教训------如果重新做一遍,这一篇的动作会是第一步而不是最后一步。
首篇结尾
一个业务智能体从 65% 提升到 85% 以上,靠的不是模型换代,不是提示词魔法,是每一层把不确定性各压一点。
- 前置拦截 LLM,挡住它没法可靠判断的东西
- 收窄 LLM 决策空间,压缩它能出错的候选集
- 兜底修复 LLM 异常,把异常输出变成可回归的链路事件
- 该完全脱离 LLM 的地方,别请概率过来当裁判
四层之间没有单点突破,合起来才形成「稳」这个字。
这条路能不能继续往上走?我现在的判断是:继续沿着这条主线,把 BI 问数封 MCP、硬约束抽象层这些数据侧和业务侧的最后几层压缩做完 ,应该还能再往上走一段。至于再往上,就要看模型能力自己进化到什么程度了。工程侧压得越紧,留给模型自己发挥的空间就越小------收敛的另一面是天花板。这条主线也有它的边界,只是暂时还没走到。
留一个开放问题给你 :如果你也在做业务智能体调优,现在最想把哪一层不确定性搬到工程侧?尤其想聊聊那种看起来聪明、实际不稳的方案------你踩过的坑,可能就是我下一版方向的起点。
下一篇聊「前置拦截 LLM」------消息预处理、前置强制检索、状态拦截。