当前位置：首页 > news >正文

RAG 重排序观测性：召回多不代表答案稳

news 2026/7/7 2:51:56

RAG 重排序观测性：召回多不代表答案稳

一、RAG 质量问题经常藏在重排序阶段

RAG 系统出错时，团队通常先看向量召回：是不是没召回到相关文档？但很多问题其实出在重排序阶段。召回到了正确文档，却被 reranker 排到后面；无关但文字相似的片段排在前面；权限过滤后候选变少，模型只能基于残缺上下文回答。

召回多不代表答案稳。RAG 质量要看检索、过滤、重排序、截断和生成的完整链路。只看最终答案，很难知道是哪一步出了问题。

二、RAG Trace 要记录候选变化

每个阶段都应该记录候选数量和 TopK 变化。

flowchart TD A[用户问题] --> B[向量召回 Top50] B --> C[权限过滤] C --> D[重排序 Top10] D --> E[上下文截断] E --> F[模型生成] D --> G[候选评分记录]

如果权限过滤后只剩两条文档，答案质量差就不一定是模型问题。观测数据要能让团队看到上下文是怎么变少的。

三、重排序日志要保留摘要而不是全文

下面是一个候选记录结构。

public record RagCandidate( String docId, double recallScore, double rerankScore, boolean permitted, int tokenLength ) {}

生产日志不适合保存全文文档，但可以保存 docId、分数、权限结果、长度和命中片段摘要。这样既能排障，又能控制敏感信息风险。

四、评估要分开看召回和排序

RAG 评测不要只看最终回答准确率。要分别看 recall@k、rerank hit rate、上下文覆盖率和答案引用命中率。召回低说明向量或分块有问题，排序差说明 reranker 或特征设计要调，引用错说明生成阶段没有正确使用证据。

还要关注截断策略。重排序后 TopK 文档可能总 token 太长，进入模型前还要裁剪。如果裁剪规则只按顺序截断，可能把关键段落砍掉。重排序观测要延伸到最终进入 Prompt 的片段。

线上反馈也要回流。用户点“答案无用”时，系统应该保存当次候选链路。没有失败样本，RAG 优化只能靠猜。

最后，重排序模型升级要灰度。新 reranker 看起来离线分数更高，但可能偏好更长文档、更新文档或某类格式。线上要按问题类型观察，不要只看总体平均。

分块策略也会影响重排序。段落太短，候选缺少上下文；段落太长，相关内容被无关内容稀释。重排序观测里要记录 chunk 大小和命中位置，才能判断问题是排序模型，还是文档切分本身。

还要区分“答案错”和“证据不足”。如果候选文档本身没有覆盖问题，生成模型再强也只能猜。系统可以在上下文覆盖率不足时明确拒答或提示需要人工补充资料，而不是强行生成看似完整的答案。

最后，RAG 调优要保留基线。每次改 embedding、reranker、分块或 Prompt，都要和上一版在同一评测集上对比。没有基线，优化很容易变成凭感觉换参数。

观测面板最好展示一次查询的候选瀑布。研发能看到每个阶段剩下哪些 docId、分数如何变化、哪些被权限过滤、哪些因 token 超限被截断。可视化不是为了好看，而是减少定位时间。

还要记录用户问题改写。很多 RAG 系统会先把用户问题改写成检索 query，如果改写偏了，后面召回和排序都会偏。重排序观测不能只从召回结果开始，问题改写也要进入 trace。

RAG 重排序还面临多语言、多领域适配的问题。通用 reranker 在特定领域（如法律、医疗、金融）的表现可能不如预期，因为训练数据和目标领域的语义分布存在差异。观测系统需要能够按领域、按语言、按问题类型分解重排序效果，而不是只看全局指标。如果某个领域的 rerank hit rate 明显偏低，可能需要 fine-tune reranker，或者为该领域单独训练排序模型。这种细分分析能力是 RAG 系统从"能用"到"好用"的关键。

重排序的计算成本也需要纳入观测范围。Reranker 模型通常比 embedding 模型更重，延迟更高。在生产环境中，需要监控重排序的 P50/P95/P99 延迟、GPU 利用率（如果用 GPU 推理）、以及超时率。如果重排序成为端到端延迟的瓶颈，可能需要优化模型（如量化、蒸馏）、减少重排序候选数量、或者采用多级排序策略（先用轻量模型粗排，再用重量模型精排）。观测数据要能支撑这些工程决策。