企业官网建设流程全解析

上个月一号早上，我习惯性打开控制台看账单，好家伙，客服机器人这个功能一个月烧掉的钱比它带来的转化还刺眼。我把调用日志抽样拉出来看了一圈，越看越不对劲——起码七成的提问是"你们几点下班""发票能开吗""帮我查下订单到哪了"这种一句话就能答完的事。而这些请求，全被我送进了自家最贵的旗舰模型。相当于我请了一位博士后坐在前台，专门回答"厕所在哪"。

于是我决定给项目加一层模型路由（model routing，模型路由，就是在请求进门时先分类，简单问题分给便宜的小模型，难的才请出大模型）。狠一点的做法叫级联调用（cascading，级联调用）：先一律让小模型上，答不好再自动升级找大模型救场。听着都很美，对吧？我第一次跑的时候还挺得意，觉得自己用 AI 管 AI，架构优雅得很——我让旗舰模型亲自当路由器，每个请求先问它一句"这题简单吗"，再决定分给谁。

结果跑了一周，账单比不加路由还高了 8%，平均响应时间也翻了一倍。原因特别朴素：路由这一步本身也是一次大模型调用，钱一分没少花，延迟还多出一截。同事看完我的架构图，憋了半天来了句：你这门卫的工资，比里面上班的还高。行，这话说得难听，但在理。

推翻重来，第二版我把路由器从"最贵的"换成了"最便宜的"。规则先上：高频 FAQ 命中的直接走模板答案，压根不进模型；剩下的请求用 embedding（向量嵌入，把文本变成一串数字，方便机器算相似度）加一个轻量逻辑回归分类器判断类型，成本约等于零；判断不准的一律默认给小模型。旗舰模型从"全员营业"变成了"只接疑难杂症"。这一版上线，路由本身的开销降到可以忽略不计。

然后我就撞上了第二个坑，也是这个方案里真正难的部分——"难度"这个信号，远没有想象中好判断。我一开始偷懒，拿"问题短=简单"当规则用，结果被现实教育了："帮我写周报"四个字，是生成类任务，小模型写出来就是一篇流水账，用户直接投诉；反过来，一段三百字的技术报错贴进来，看着挺唬人，其实是我们 FAQ 里躺了半年的已知问题。你看，长度根本不能代表难度，任务类型（是问答、生成还是推理）和领域熟悉度才是关键变量。我后来把分类器改成了按"任务类型+领域"打标，准确率才肉眼可见地爬上来。

（写到这儿插一句，产品同学听说账单砍了六成，第二天就兴冲冲跑来，想把省下的预算拿去做两个新功能。我赶紧把报表收起来——省下的钱是拿来填下次事故的，真不是拿来花的。）

光省钱还不行，路由错了得有安全网兜底。我们现在的设计是：小模型答完先过一道自查，置信度（confidence，模型对自身答案的把握程度）低就自动升级到大模型重答；用户点了"不满意"的案例会自动回流进标注池，每月喂回分类器重新训练一次。上线时是灰度放的，先切 10% 流量观察了一周，两类错误率都稳住了才全量。现在的状态是：七成流量走小模型，总成本降了六成多，答对率只掉了不到两个百分点，而且大半还是被兜底捞回来的。

说实话，路由这事到现在也没有标准答案。云厂商这两年都推出了托管路由服务，听着省心，实际是黑盒，分流逻辑一变你连招呼都不会收到；自己搭呢，分类器要持续养数据，业务一变方向，整套策略就得重新校准。另外也别神化这套玩法——小模型的能力上限摆在那，复杂推理、多轮长对话这类任务，路由器再聪明也该直接放行给大模型，硬省那点钱最后都是事故工单。

如果你手上也有项目在拿同一个旗舰模型硬扛全部流量，不妨先去抽一百条日志看看，说不定你会跟我一样，发现博士后正坐在前台。看完了记得回来聊聊：你的场景里，简单请求和硬核请求的比例是多少？你是愿意自己养一个分类器，还是干脆信云厂商的黑盒路由？评论区见，我是真的想知道大家这笔账都是怎么算的。