RAG检索总答非所问？问题可能出在重排序环节，这里有完整解法

“召回了但没答对”的真相

做RAG的企业常遇到一个诡异现象：知识库里明明有答案，模型却回答得支离破碎。排查后往往是检索环节出问题——粗排（向量召回）返回了相关度不够的片段，而精排（ReRank）不是没做，就是做得很潦草。重排序，恰恰是决定RAG回答质量的上限环节。

为什么单靠向量不够

向量检索的优势是快和语义泛化，但它有两大短板：一是对”关键词精确命中”不敏感，比如用户搜”价格表”而文档里写”报价单”，向量可能反而召回别的；二是小段落容易被打散，真正的答案段落反而排不到前面。所以必须引入精排。

一套完整的检索精排方案

第一层：粗排召回。 用小向量模型快速召回Top 100候选，保证召回率。参数不宜过小，宁可多召回，把判断工作留给精排。

第二层：精排ReRank。 用专门的交叉编码器（cross-encoder，如bge-reranker、Cohere Rerank）对这100条做细粒度打分，重排序后取Top 5~10。cross-encoder对”查询与文档的相关程度”建模更精细，准确率远高于单纯的向量相似度。

第三层：混合检索。 把向量召回和BM25关键词召回的结果合并，再做精排。这能同时兼顾语义理解和精确匹配，是生产级RAG的标配。

第四层：阈值与去重。 给精排分数设一个最低阈值，低于阈值的文档直接丢弃——宁缺毋滥。同时合并语义重复的段落，避免给模型塞进互相矛盾的冗余片段。

怎么判断ReRank有没有用

用一组带标注的测试问题，对比”不加ReRank”和”加ReRank”的回答命中率。一个务实的指标是答案准确提取率：正确答案片段是否出现在最终喂给模型的Top-K里。如果加了ReRank后命中率明显提升，说明你的精排链路是有效的；如果没提升，问题可能出在数据切块或粗排召回上。

结语

RAG的性能瓶颈往往不在模型，而在检索链路。把重排序从”可选项”升级为”必选项”，再配上一套可复现的评测集，你的知识库回答质量会肉眼可见地提升。