给最高频的 AI 环节做成本工程:意图识别与可控性梯度路由

意图识别是每个请求都要经过的环节,也是全站调用量最大的 AI 环节。它的单位成本和尾延迟会被流量放大到全局——所以它的设计目标不是"最聪明",而是"每一层只为它该解决的问题付费"。

事实说明
经验来源
本文来自我在一个生产级 AI 助手里设计「意图识别 + Agent 路由」中枢的实践,已剥离具体业务,只保留可迁移的工程方法。
判断边界
分层结构是通用的,但具体哪些走关键词、哪些需要 LLM、阈值定在哪,取决于你的意图分布,需要用自己的离线 eval 集校准。

为什么这一环值得单独做成本工程

AI 助手的能力越多,"用错能力"的代价越大:本该精确计算的任务走自由发挥可能算错结果,简单问候却走多步推理白白多花几倍延迟和成本。请求分发是整个产品的调度中枢——它不直接产生任何答案,但决定了每个答案由谁、以什么方式、花多少成本产生。它做得好用户感知不到,做不好用户感知到的是"答非所问"和"莫名其妙地慢"。

更要命的是它的位置:每个请求必经。一个只在 1% 请求上出现的环节,单位成本高一点无所谓;但一个 100% 请求都要过的环节,它的单位成本和 P99 延迟会被流量整整放大一个量级。所以我没把它当成"加个分类器",而是当成一个需要认真做成本工程的高频环节。

给最高频的环节做成本工程,本质是:零成本兜大头、按需付费处理长尾、故障永远有保底。

成本分层的意图识别:三层结构

核心思路是每一层只为它该解决的问题付费:

第一层 · 关键词匹配(零成本)
明确的问题毫秒级分类,不花一分钱。匹配规则有语言学打磨——英文按词边界、单字中文要求精确、泛词命中自动降级——把误判压在工程层面而非模型层面。
第二层 · 小模型兜底(按需付费)
只有模糊的问题才调用一次轻量 LLM 分类,并注入最近两轮对话理解追问——上轮问了 A,这轮只说"那 B 呢"也能接住。
第三层 · 熔断保底(永远可用)
分类 LLM 故障时跨实例熔断,自动落到默认意图——分类器可以降级,但服务不能不可用。

这套结构的产品含义是:大头流量(明确问题)零成本秒级处理,只有长尾的模糊问题才付费,而且即便付费那一层挂了,也有一个永远可用的默认意图兜底。把一个高频环节的单位成本压到接近零,靠的不是更便宜的模型,而是让大多数请求根本不调用模型。

可控性梯度:和钱相关的收紧,开放问答放开

意图识别只解决"听懂他要什么",下一步是"决定谁来办、给多大自由度"。我把执行路由做成一条"越靠前越可控、越靠后越灵活"的优先级链,核心原则是和精确计算、规则强相关的任务收紧自由度,开放问答放开自由度

路径适用自由度
固定工作流 Pipeline涉及精确计算、报表的任务模型只负责最后表达,不参与流程决策——可控、可测试、可追责
单步直答明确的简单查询一次调用直答,结构化数据预取好——最快路径留给最高频问题
人工拦截 HITL用户要求转人工中断流程、收集联系方式、生成工单——AI 知道该退场的时机
多步推理(带预算)开放性问题模型自主决定步骤顺序,但步数和超时双预算封顶——灵活但不放飞

路由的本质是给每类业务风险定"自由度预算"。这套判定逻辑还经历过一次关键升级:早期用拼凑的数值"置信度"做阈值,后来升级为语义化的匹配质量档位(强关键词命中 / LLM 语义判断 / 弱匹配 / 默认兜底)——让路由决策从"数字玄学"变成"可解释的档位",每个请求为什么走这条路径都能向运营讲清楚。

指标必须有业务语义
把路由判定从一个拼凑的浮点"置信度"换成"匹配质量档位",看起来只是命名问题,实际是把黑盒决策变成可向非技术同事解释的规则。一个你自己都说不清为什么是 0.63 的阈值,迟早会变成线上事故的根因。

把对话执行做成"并发安全 + 永不全挂"的状态机

分类和路由只是"决定怎么办",真正把一次对话从进到出跑完的是一张编排状态图:安检 → 分类 → 记忆与知识检索 → 路由 → 执行 → 输出安检 → 存记忆。这一层是典型的"做好了没人感知、做错了全是事故",价值全在两件横切的脏活上。

一是会话级串行:同一会话同一时刻只放一个在途请求。否则两条消息并发会把"读历史→追加→写回"搞乱、把记忆写串,多轮对话就开始"精神分裂"。这是用户感知不到、但缺了就会零星出灵异 bug 的底座。

二是永不全挂的降级链:记忆挂了、知识库挂了、某家模型挂了、底层编排框架报并发错——每一种都有兜底(降级注入 / 空上下文继续 / 切兜底模型 / 返回一句友好的"稍后再试"而不是 500)。判断一个 AI 编排成不成熟,要看它的失败路径,而不是正常流程。

一个真实的框架踩坑:不报错、只是悄悄变贵

这个坑值得每个用"自动编排"框架的人警惕。路由这一步有两个并行的上游(加载记忆、检索知识),编排框架按"上游各触发一次"的语义调度,两个上游不在同一拍完成,就会让后半条链路整个跑两遍——一轮对话扣两份 token、记忆写重复。

这种 bug 最阴险的地方是它不报错,只是悄悄变贵、变乱,靠端到端回归测试才能钉死。它给我的教训很具体:用任何"自动编排"的框架,都要搞清楚它的隐性调度语义,不能只看业务逻辑对不对。框架替你做的调度,也是你要负责的成本。

衡量:编排的"正确"无法靠肉眼验收

编排模块有个反直觉的难点:同一个问题走错路径,答案往往也像模像样,只是更贵或更慢。所以它的质量保障必须依赖断言式 eval 集,而不是抽查对话。我实际盯的几类信号:

分类质量
意图分类准确率(离线 eval 用例集,含路由断言,每次改动回归)。
成本健康度
LLM 兜底触发率升高 = 关键词覆盖出现缺口,是运营补关键词的信号;熔断开启次数。
路径分布
工作流 / 单步 / 多步 / HITL 各路径占比与延迟分位——单步占比是"高频问题是否走在最快路径上"的直接度量。

总结:每一期都建立在上一期被验证的基础上

这套中枢的演进顺序我会原样推荐:一期先用零成本的关键词验证"分发"这个骨架能不能跑通 → 二期把意图规则和 Agent 配置化,让运营自助扩展、新增能力不发版 → 三期才上 LLM 兜底分类处理长尾,并把路由判定升级为可解释的匹配质量档位。每一期的投入都建立在上一期被验证的基础上,而不是一开始就上全套。

如果只记一句:给最高频的 AI 环节做成本工程,是把"零成本兜大头、按需付费处理长尾、故障有保底"这三句话落进架构里。流量会放大一切——它会放大你的浪费,也会放大你的克制。

欢迎通过邮件和我交流:shaoyanyan91@163.com