毫秒都去哪了：一份 RAG 的延迟预算表
用户感受到的不是你的架构，而是一个数字。多数团队说不清这个数字是从哪来的。在它真的变慢之前，用户早就觉得它慢了。
发生了什么
用户反馈助手很慢。团队对模型做性能分析，发现生成是瓶颈，花了一个迭代优化它。感知延迟几乎没变——因为真正的问题是串行链：检索在等查询改写，重排在等检索，没有任何一步是并行的。
为什么落地团队要在意
延迟是一份预算，和所有预算一样，第一件事是搞清楚钱花在哪。一次典型 RAG 请求有五个阶段——查询理解、检索、重排、组装、生成——在健康的系统里分别大约是 20 到 60 毫秒、20 到 60、40 到 150、可忽略、300 到 900。有两个数字比总耗时更重要：首 token 时间（用户真正感知到的）和 p99（用户记住的）。
该做什么
在优化任何东西之前，先分阶段埋点——多数团队对哪一段占主导的判断是错的。然后找出那些串行执行、其实可以并行的步骤：查询改写和向量化可以和元数据查询同时跑。在优化重排器本身之前，先减少送进重排器的候选数量。 在缓存上要做得激进一些：给定语料版本下检索和重排都是确定性的，而客服类问题的重复率远高于团队预期。
最便宜的一招
流式输出。首 token 时间既是个技术决策也是个产品决策——400 毫秒吐出部分答案，体感上明显快于 1400 毫秒给出完整答案。这通常是性价比最高的感知性能优化，只要一个下午。