RAG实战踩坑：别在排序算法上浪费时间，除非你的召回是对的

很多人在做RAG（检索增强生成）时有个误区，觉得回答不准确是因为排序（Ranking）没做好，于是陷入了不停更换 Embedding 模型或叠加 Reranker 的死循环。

我之前就走过这个弯路。为了优化检索结果，我连续三个月每两周换一次方案：从 BM25 到混合检索，再到各种 Cross-encoder 排序模型，甚至试了好几个不同的 Embedding 模型。结果是，每次调整后，文档的顺序确实发生了变化，但给出的答案依然是错的。

一个典型的场景是，用户问“为什么网关拒绝服务 X？”，不同的算法让结果在“术语表”、“Jira单”和“架构文档”之间跳来跳去。我一度以为架构文档排到了第五名就是进步，但事实上，只要它没排在第一，或者根本没进入 Top-K 候选集，对 LLM 来说几乎没有意义。

我意识到一个核心问题：排序算法只能在已有的候选集里排先后，它无法把一个根本没被选中的文档“变”出来。

现在我对检索流程的认知分成了三个层级，建议大家在调优时按这个优先级排查：

• Selection（筛选/召回）： 决定哪些文档有资格成为候选。如果这一步漏掉了正确答案，后面所有优化都是徒劳。
• Assembly（组装/切片）： 信息是如何被索引、结构化和连接的。切片策略不对，会导致语义碎片化，从而影响召回。
• Ranking（排序）： 在候选集中决定谁排第一。这是最后一步，也是最容易被过度优化的一步。

如果你发现更换了多种 Reranker 效果依然没提升，大概率问题出在第一层（召回）或者第二层（切片）。别把“排序”等同于“检索”，在候选集不对的情况下，优化排序只是在给错误答案“换件衣服”。