一个团队把 AI 客服的账单砍掉了一半多，八周干净的工程活。三个月后客户满意度在掉、流失在涨，赔进去的钱是省下来的四到五倍。每一个单独的决策都对，合起来却造出一个监控看不见的质量黑洞。
2026 年关于 AI 成本，已经收敛出一套共识打法：简单查询路由给便宜模型，复杂查询留给强模型，账单降下来、质量保得住。这笔账是真的。陷阱也是真的。
作者复盘的第一个团队，上个季度把 AI 推理账单砍掉了一半多。八周干净的工程活，是整个工程团队追了一年的胜利。CFO 发了感谢信，团队在全员会上做了汇报，然后转去做下一个季度的优先级。
三个月后，客户满意度在掉、流失在涨，而省下来的钱和这部分质量损失是结构性绑在一起的。用作者的话说，这不算赢，只是把成本挪到了一个自己没在度量的地方。
这篇复盘有价值的地方，恰恰在于这个团队几乎什么都做对了。架构合理、监控到位、灰度规范，照着市面上每一篇成本优化指南做的，每一个单独的决策都站得住。问题出在：这些都对的决策合在一起，造出了一个现有监控架构看不见的质量黑洞。
在真正回答用户的主模型前面，加一个很小、很快的分类器模型。它不回答问题，只给每条进来的查询打个标：simple 还是 complex。simple 的转给便宜模型，complex 的继续走强模型。下面这张图就是这套结构。
这是一个 SaaS 产品的客服 AI agent，月活约 400 万。原本跑在单一强模型上，月账单进了六位数还在涨。下面几个数字，是他们上线前做的功课。
分类标准来自生产观察：simple 是反复见到的那类（账户查询、账单状态、密码重置、订单跟踪、营业时间），complex 是历来需要多步推理的那类（退款纠纷、套餐变更、集成排障、账单周期异常）。代表性一周里，大约 65% 判 simple、35% 判 complex。灰度也规范：5% → 10% → 25% → 50% → 全量，分六周走完，每一步指标都绿。
问题不在他们搭的东西，在他们测量的方式。路由上线前，整套评测架构建立在「我们跑的是单一模型」这个假设上，质量信号来自三处：每天约 200 条人工复查、每周约 12000 条的离线回归套件、产品内一个点赞点踩控件。路由上线后，这三个信号一个都没出错，但它们一起漏掉了同一件事。
人工复查没分档，65% 落在便宜模型上，简单查询的高分把聚合数拉高，难的那端被稀释看不见。离线回归套件是静态的，部署前六个月建的，反映理想分布，不是便宜模型现在真要扛的生产分布。反馈控件太稀，每 1000 次交互约 3 次点踩，信噪比低到除了大幅回归什么都测不出。三个盲区都不是路由引入的，是单模型时代就潜伏的；只要系统只有一个质量分布，它们不会误读。路由引入了第二个分布，旧架构没法把两者分开看。
诊断花了两周，作者从日志重建出一个「按档分层的质量视图」。便宜模型在派给它的查询里约 80% 表现良好，和当初的等质结论吻合。问题全在另外 20%。最清楚的例子是账单查询。
分类器被训成把「我这笔扣款哪来的」「我被扣了两次」识别为 simple，假设下游是「账户查询 + 发票检索」这个可靠组合。在 holdout 测试里这是真的。但在生产里，相当一部分这类查询底下藏着更复杂的意图。
更隐蔽的是后果怎么扩散。拿到错答案的用户不一定点踩，很多人直接放弃 agent、转去打人工客服电话。于是点踩信号低估了失败，失败的成本被转移到人工客服那一头，由另一个预算买单。agent 的自助解决率看着很稳，实际人工处理量在往上爬，但这两件事属于不同的成本中心，没有任何一个看板能同时看到。
the classifier is well-calibrated exactly where it does not need to be, and poorly calibrated exactly where it does. 分类器恰好在它不需要准的地方校准得很好，在它最需要准的地方校准得最差。— Pratik K Rupareliya, Towards Data Science
问题不在他们选的模型、用的 provider 或训的分类器，而在问题空间本身的形状。这一段最值得放慢看。
任何生产 AI 部署里，客户查询的难度服从幂律分布：大部分挤在简单中心，一小部分拖向又难、又模糊、又依赖上下文的长尾。前沿模型对简单中心是过度配置的：回答「你们几点开门」用不上那么强的能力。正是这种过度配置，让成本优化的机会真实存在。
麻烦在于，分类器没法在决策那一刻把简单中心和长尾分开。它看到的是查询的表面形态，而长尾就藏在「看起来简单」的表面底下。下面这张图把这件事画出来了。
除了校准错位，还有两个机制叠在上面：
自信地失败（fail confidently）。前沿模型的失败往往是可恢复的：它会 hedge、会反问、会暴露自己的不确定，从而提示人介入。小模型常常给出一个完整、像模像样、表面自洽、却答错了真实意图的回答。这种错比一个犹豫的回答更难被识别成错，于是潜伏得更久。
漂移。生产查询分布会演化：新产品上线、新客户群进来、新失效模式出现。在六个月历史流量上训的分类器，会随分布偏离训练集而误路由越来越大比例的查询。省钱保持稳定，因为路由仍以同样比例发给便宜模型；质量成本悄悄涨，因为分类器越来越判错「哪些查询真的简单」。
三个机制叠加，几乎没给系统留下自我纠正的余地。便宜模型那档把简单的大头处理得很好，在隐藏的长尾上不透明地失败，再随分布漂移进一步退化。这正是它是 Pareto 陷阱、而不只是一次有噪声的优化的原因：几何是结构性的。
把账一起算，质量损失的成本影响保守估计是省下钱的四到五倍。但关键不只是倍数，是这两笔账记在了不同的部门。
满意度的累计影响最终在两处显形：灰度期间和 agent 交互过的客户，90 天回访满意度明显低于灰度前的基线人群；6 个月留存对照基线下行，最暴露于失效路由的客户分段掉得最狠。从漂移开始到团队找上作者，中间隔了整整一个季度。下面是这条时间线。
复盘完第一个案例，作者去其他有可见度的部署里找同一个模式，很快浮出两个。三个案例的模式一致：省钱真实且可测，质量损失真实但现有架构测不出来。
客服里答错可以恢复，受监管行业里答错可能就是一次违规。任何长尾成本高或受约束的场景，Pareto 陷阱都会被放大。
能更早抓住这类问题的诊断方法并不复杂，但它要求在路由层上线之前就改测量架构。作者给了三处具体补充，每一层都揭示其余两层看不到的失败。
两点提醒：一是事后补这些测量比上线时一起建难得多，上线前建大约要三个工程师周，出了质量问题再补往往要重建当初没采集的数据；二是测量架构比路由决策本身更重要：有好的分档观测的团队可以安全地试激进路由，因为他们会抓到漂移；没有的团队在规模化下任何路由层都不安全。
如果「分类器预路由」是 Pareto 陷阱，作者给出的替代方案明显更好，但有它自己的代价。核心差别是：谁来做「这条查询要不要升级」的决策。
这个模式把失败模式反转了。那些便宜模型本会「自信答错」的难题，现在以低置信度的形式浮出来、触发升级。在作者对那个客服案例的推演里，建模出的省钱幅度和预路由方案大致同一区间，而长尾质量明显更好。两个增强还能叠加复利：Shadow scoring，对一小比例流量并行跑强模型探测漂移；Quality-weighted routing，把观测到的满意度信号回灌进阈值调参，让级联随分布演化自适应。
级联的代价是实打实的：升级查询的延迟约等于便宜模型加强模型之和，明显比预路由差；成本更难提前预估，因为取决于生产置信度分布；实现复杂度也更高，因为校准便宜模型的置信度本身不平凡。这些代价值得权衡，但它们换来的是级联守得住、预路由守不住的那条质量底线。
Cascades trusts the model itself to know what it does not know. 预路由信任的是一个看不见关键信息的分类器；级联信任的是模型自己知道它不知道什么。— Pratik K Rupareliya, Towards Data Science
那个第一个团队最终落到一个稳定架构：不确定性级联加按档分层观测。月推理成本稳定在比优化前基线低约 35%，比预路由方案纸面上省得少，但客户满意度回到了实验前水平，两层一起算，部署的净产品价值明显为正。
团队从中得到的教训不是「成本优化是错的」，而是：成本优化是一个关于该把这个权衡交给系统哪一层的选择。预路由信任的是一个看不见关键信息的分类器；级联信任的是模型自己知道它不知道什么。便宜的那个优化，是悄悄拖垮产品的那个；架构上诚实的那个，是能在长尾里活下来的那个。在生产 AI 里，两者的差别通常是一个季度的客户满意度。
Towards Data Science · 2026-06-27 · 作者 Pratik K Rupareliya（Intuz 联合创始人兼策略负责人，18 年+ 企业 AI / IoT / 云落地经验，700+ 项目）。
这是一篇带顾问视角的第三方复盘，发表在社区投稿平台，作者所在公司经营企业 AI 落地服务。文中三个部署均为匿名案例，关键数字（省约 $100k/月、赔约 $400–500k/月、94% 等质、质量损失 4–5 倍、最终成本低于基线约 35%）只有这一个一手来源，外部无法独立复核，本文按「某生产部署复盘」对待，不作审计级断言。真正扛得住的是它的机制论证：长尾压缩、自信失败、漂移、三层观测、不确定性级联，本文叙事也以机制为主。