Demo 阶段的 RAG 很容易「看起来能用」：塞一个向量库，接一个大模型，问答就通了。但一旦上生产，三个问题会立刻浮出来——召回准不准、重排贵不贵、延迟扛不扛得住。

一、召回：别只靠向量

纯向量检索在语义相近但用词不同的场景很强，可一旦用户的 query 里带了专有名词、编号、精确措辞，稠密向量反而容易漂。实测里更稳的是混合召回：

  • BM25 / 全文检索抓精确命中；
  • Embedding 抓语义邻近；
  • 两路结果做融合（RRF 或加权），再进重排。

分层 + 重叠切片也很关键：切太碎丢上下文，切太大稀释相关度。

二、重排：值这个钱，但要卡预算

bge-reranker 这类交叉编码器能把初排的噪声压下去不少，代价是每个候选都要过一遍模型。实用的做法：

  1. 初排召回放宽（比如 topK=50）；
  2. 只对前 N（比如 20）做重排；
  3. 重排结果取前 5 喂给生成。

准确率的提升通常值这一步，但 N 要卡死，别让它吃掉你的延迟预算。

三、延迟：200ms 不是靠单点，是靠省

把 P95 推理链路压进几百毫秒，靠的不是某一个快，而是每一段都省：

环节 手段
检索 预计算 embedding、向量库分片、缓存热 query
重排 限候选数、批量推理
生成 路由到合适规格的模型、流式返回先给首字

小结

RAG 从 Demo 到生产，本质是从「能答」到「稳、准、快地答」。召回用混合、重排卡预算、延迟靠层层省——这三条是我反复验证有效的地基。

评测要跟上：groundedness、召回率、一致性、延迟，一个都不能只凭感觉。