RAG 延迟预算：把检索、重排和生成放进同一条性能决策链

RAG 的用户感知延迟来自一整条链路：鉴权、query 改写、向量召回、全文召回、权限过滤、重排、上下文组装、模型首 token 和流式输出。只把模型换快一点，往往无法解决用户仍要等待数秒的问题。性能优化的第一步是为任务设置端到端预算，再决定每一段可以花多少时间。

按任务而不是按接口设置 SLO

“问答接口 P95 小于 5 秒”太粗。查一条工单、比较十份合同、生成带引用的排障步骤，复杂度和风险不同。为每类任务定义首个有效反馈时间、完整答案时间和允许的降级行为。例如低风险帮助中心查询可在 800 毫秒内展示已检索来源，复杂分析可以更慢但必须展示进度。

预算拆分后，团队才知道问题在哪：检索 150 毫秒、重排 400 毫秒、模型首 token 1.2 秒、生成 3 秒，还是权限服务偶发 2 秒。每段都应有 trace 和 P50/P95/P99，不能只统计总耗时。尾延迟常由少数慢依赖、长上下文或重试引起，平均值看不出来。

不是所有请求都需要 multi-query、跨编码器重排和十几个候选 chunk。对简单事实查询，可以走缓存或少量混合检索；对高价值、低置信度或需要引用的任务，再启用更深的召回和重排。策略的输入应是任务类型、风险、query 特征和当前系统负载，而不是一套固定 pipeline。

设定候选上限、重排上限和上下文 token 预算。候选越多不一定更准，常见结果是 reranker 更慢、模型上下文更长、答案反而被噪声稀释。每增加一道处理，先在评测集上证明质量收益，再决定它是否值得消耗延迟和成本。

系统繁忙或依赖变慢时，可以跳过可选重排、缩小候选、返回检索结果摘要或要求用户缩小范围；但不能跳过权限过滤、引用校验或写操作确认。把“可降级的质量增强”和“不可降级的安全边界”写成明确策略，避免压力下为了快而泄露资料或编造答案。

缓存也需要预算意识。缓存 query 改写、嵌入和低风险检索结果可以减少重复开销，但缓存 key 必须包含权限和索引版本。命中陈旧或跨权限缓存比慢一点更糟。对缓存命中、失效和回源耗时分别观测，才能判断缓存到底在改善哪个阶段。

流式 UI 让用户更早看到来源和过程，但不能掩盖后端持续变慢。每次性能优化后，比较任务完成率、用户取消率、人工接管和引用质量，而不只看基准压测。一个更快却更少引用证据的 pipeline，可能降低了整体价值。

延迟预算的作用是让团队能做取舍：哪里值得花 300 毫秒换准确率，哪里应立即返回澄清，哪里必须等待授权。把这些取舍变成可观测策略，RAG 才能在规模增长后仍保持稳定体验。

只用短 query 和固定文档集压测，会低估权限过滤、长上下文、缓存未命中和并发重排的代价。压测集应包含高频简单问答、长问题、精确字符串、跨文档比较和高风险拒绝场景，并按真实比例混合运行。记录资源使用、队列等待和依赖错误，而不是只看单机 QPS。

当预算被突破时，先确认是流量变化还是系统回归。为检索、重排和生成分别设置容量告警，并保留能重放的 trace 样本。性能问题如果无法复现，就很难判断应该扩容、改策略还是修某个慢查询。可复现的性能证据比一次偶然的基准数字更有价值。

发布性能策略时使用小流量灰度，并保留旧策略作为对照。若新策略缩短了首 token 时间却提高了用户追问或引用缺失率，就不应只因速度更快而扩大。性能预算最终是产品质量预算的一部分，必须和正确性、安全性一起做发布决策。

定期复核每个预算是否仍符合真实流量，避免曾经合理的默认值在文档规模、模型上下文或权限规则变化后变成新的瓶颈。

把预算变化写进发布说明。业务团队可能愿意接受某类复杂问题多等一秒来换取更完整的引用，但不愿接受简单查询无故变慢。提前说明受影响的任务类型、回滚条件和观察指标，能让性能优化从基础设施实验变成有共同预期的产品决策。