企业官网建设流程全解析

异步 RAG 延迟评估：拆开等待时间再优化

RAG 请求慢，不代表模型生成慢。排队、权限查询、向量检索、重排、首个 token 等待和流式发送，都会躲在“总耗时”这个大口袋里。先把时间拆开，才不会把优化做在最安静的地方。

为一条请求串起 trace

入口创建请求标识，并传给检索、模型客户端和流式响应。每个 span 记录开始、结束、取消和错误原因；敏感文本不必进 trace，保留长度、版本和状态即可。排队时间要单独记，它往往比某个函数的执行时间更能解释用户的等待。

异步不是把所有事一起跑

可并行的步骤可以并行，但检索结果尚未就绪就无法可靠重排，模型流式输出也不能无限制积压。给每一段设置总时限、并发上限和取消传播；调用方离开后，后台工作要能停下来。

用固定样本分别观察命中缓存、检索为空和模型超时的路径。优化前后都保存配置与原始 trace。别只报一个平均值，用户遇到的通常是那条排队最长的请求。