2.5 秒和两毛钱，降级顺序是一份产品决策

B 端客服 RAG，单次会话 3.2 轮，链路是检索、重排、大模型生成。实测 P95 首字 4.8 秒、单会话成本 0.42 元；合同写的是 P95 ≤ 2.5 秒、单会话 ≤ 0.20 元，超了要赔付。可用手段一堆：缓存、小模型路由、减少召回与重排、流式输出、并行检索、降级为纯检索答案、转人工。

这道题最容易答成「让工程优化一下」。但手段清单里每一项都在拿质量换数字，换多少、按什么顺序换、哪些不许换，是产品签字的事。

本系列第 8/10 篇 · 上一篇：搜索能查、推荐能逛、客服能办，Agent 增量在哪 · 下一篇：两百份文档、日均八条反馈，飞轮从哪儿转起

先把 4.8 秒拆开

我给一个待验证的构成假设，而不是结论：

段	假设占比	可排查手段
接入、鉴权、权限过滤	10%	链路 trace 分段计时
查询改写 / 意图判断	12%	关掉改写跑固定问题集对比
检索（多路召回）	20%	串行改并行、看单路耗时分布
重排	18%	关重排跑消融，看耗时与 nDCG 变化
上下文组装与截断	5%	记录送入 token 数
首 token 生成	30%	换档位模型对比 TTFT
网络与排队	5%	峰值并发压测

产品侧验证不要求写代码，要求的是分层埋点 + 消融实验：固定 100 条真实问题，逐项关掉改写、关掉重排、直连缓存，各跑一遍，看每段到底贡献多少毫秒、以及关掉之后质量掉多少。没有这张表就拍板砍重排，跟不看指标改 prompt 是一回事。

另外要问一句：2.5 秒是首字还是完整返回？合同里写「首字」和写「答完」，方案完全不同。这个反问通常能看出候选人有没有真的对过 SLA。

三档降级矩阵

档	触发条件	采用手段	用户可感知的变化	兜底
A 高频事实型 / 标准 SLA	命中缓存或意图简单	缓存 + 小模型路由 + 召回条数减半 + 跳过重排	几乎无感，答案更短、引用仍在	纯检索答案 + 原文链接
B 复杂多跳 / VIP SLA	需多文档、客户标记重要	并行检索 + 保留重排 + 流式输出；仅在超预算时减片段	先出字、结论可能分两段给出	「已确认部分 + 待补标记」，可一键转人工
C 故障或成本超预算	接口异常、当日预算触顶	降级为纯检索答案，明确标注「未生成总结」	变化明显：没有生成式结论	排队 + 人工坐席，带上下文转接

三档的关键不在手段，在触发条件必须提前写死并进监控，不能等 P95 飘了再由值班同学临场决定。而且每档的「用户可感知变化」要写在产品说明里：B 档用户看到的是流式分段，不是变慢；C 档用户看到的是明确标注，不是一段读起来像结论、实际没经过生成的话。

有些东西不能降

我列四条硬约束：引用必须可追溯到原文、不得编造事实、权限隔离不得绕过、涉及金额与承诺的答案不得由降级链路生成。

换句话说，降的是生成方式与呈现形态，不是事实约束。A 档可以没重排，但引用的片段必须还在；C 档可以不给总结，但不能给一段没校验过的总结。这条边界一旦松了，成本指标会很好看，直到某天客服把一条降级答案发给了客户。

流式输出改善的是哪个指标

它改善的是感知延迟（TTFT），不减少总完成时长，也不减少 token 成本——多数实现里因为分块反而略贵。所以指标必须分开记：

• TTFT / P95 首字：合同里那 2.5 秒，流式能直接改善。
• P95 完整返回时长：衡量用户真正等多久，流式帮不上，甚至可能更长。
• 单会话成本：按 3.2 轮的实际分布算，流式不影响分母。

只报首字延迟的验收报告，是最常见的一种自欺。我会在同一个面板上放三行，验收要求首字达标、完整时长不恶化、成本不超预算，三者同时成立。

取舍顺序与上线验收

排序原则很简单：先砍不产生质量收益的调用，再动会掉质量的环节。缓存 → 意图路由（简单问题走小模型）→ 串行改并行 → 减少送入片段数 → 最后才考虑动重排和生成模型。前两步通常就能吃掉大半成本，且质量几乎不掉；一上来就砍重排，是把最有效的手段留到最后、把最伤质量的放在第一步。

上线前必须跑两个口径：

1. 峰值并发压测：按合同口径统计 P95 TTFT 与 P95 完整时长，同时记录各档降级触发率；触发率超过设定比例（比如 C 档 > 5%）就说明容量没配够，不能靠降级蒙混验收。
2. 降级后质量验收：用固定评测集分别跑 A/B/C 三档，要求每档的引用正确率与无答案误答率不低于阈值，且成本按 3.2 轮分布取 P95 而非均值——均值会把长会话的赔付风险平均掉。

追问：客户坚持「绝不降级」

先承认这句话里合理的部分：他真正不能接受的多半不是「降级」这个词，而是没被告知的质量变化。所以我把不可降级的四条硬约束单独列进合同附件，写明这四条在任何情况下都不变，其余是分档服务等级。

然后给三个可选商业方案，让他自己选：提高单价以预留峰值资源、放宽 SLA 到 3.5 秒、或者接受「超预算时转人工 + 明确告知」。把赔付成本、预留资源成本、转人工成本三个数字摆在一起，比争论「要不要降级」有效得多。

最后一条要提前说清：完全不降级意味着故障期只能排队或失败，这两者也是体验降级，只是没写在合同里。把它讲明白，是产品该担的责任。

我会怎么看答案

及格：罗列缓存、小模型、流式等手段。良好：会拆耗时、会给分档策略、能区分感知延迟与真实延迟。优秀：把降级顺序定性为产品决策、写出不可降级的硬约束、验收用 P95 而非均值、并且能把「绝不降级」翻成商业条款与责任边界。

一个典型失分：为了达标把召回条数和重排一起砍掉，却不测引用正确率。SLA 达标了，产品也就废了。

成本压到最后，压的不是数字，是「哪些体验一分钱都不能省」的那份清单。

预算谈完，轮到最容易被 PPT 带跑的一题：没有数据的时候，飞轮从哪儿转起。