RAG 检索不准怎么排查：召回、混合检索与重排序
检索是 RAG 的核心。检索质量差，生成的内容就是“垃圾进，垃圾出”（Garbage In, Garbage Out）。
1. 基础检索：相似度搜索 (Similarity Search)
这是常见的基础模式：使用索引和查询采用的相似度度量，取一组候选结果。Cosine 相似度是可选方案之一，实际度量需要与 Embedding 模型、向量归一化方式和数据库配置保持一致。
- 优点：速度快，捕捉语义关联。
- 缺点：对于专有名词、精确匹配（如“错误码 503”）效果不佳。
2. 进阶检索：混合检索 (Hybrid Search)
混合检索 = 向量检索 (Dense) + 关键词检索 (Sparse/BM25)
向量检索擅长语义理解，关键词检索擅长精确匹配。两者结合，互补短板。 不同搜索引擎和向量数据库对稀疏检索、过滤与融合的能力不同，接入前应按当前版本文档和真实语料验证，不能只根据产品类别推断。
Golang 伪代码逻辑
// 1. 并行执行两路搜索，候选数量由经过评估的配置决定
// Goroutine A: 向量检索
// Goroutine B: BM25 关键词检索
// 2. 结果融合 (Reciprocal Rank Fusion, RRF)
func RRF(denseResults, sparseResults []Result, rankConstant float64) []Result {
scores := make(map[string]float64)
// rank 应从 1 开始；rankConstant 是待评估并记录的配置，不是质量阈值。
for rank, doc := range denseResults {
scores[doc.ID] += 1.0 / (rankConstant + float64(rank+1))
}
for rank, doc := range sparseResults {
scores[doc.ID] += 1.0 / (rankConstant + float64(rank+1))
}
// 排序返回
return SortByScore(scores)
}这段代码只表达融合思路。生产实现还要处理同一文档的 Chunk 去重、稳定排序、空结果、超时、部分失败和权限过滤，并通过离线评估选择候选数量与融合参数。
3. 精排：重排序 (Re-ranking)
粗召回的候选中可能包含不相关或重复内容。重排序模型可以对 (Query, Chunk) 重新打分，再根据上下文预算和评估结果选择证据。重排序不是必然提升质量：模型语言、领域、输入上限、延迟和失败降级都需要验证。
流程：
- Retrieval：召回足够覆盖答案证据的候选集。
- Filter / Deduplicate：执行权限过滤、版本过滤和去重。
- Rerank：使用经过验证的模型或规则重新排序。
- Context Build：根据上下文预算选择片段，并保留引用元数据。
不要直接复制某个相关性分数作为阈值。不同模型的分数不可直接横向比较，应在固定评估集上观察排序质量、无答案行为、延迟和成本，再确定截断规则；模型或版本变化后重新校准。
4. 检索不准的排查顺序
先保存最终送给模型的 Chunk ID、排名、来源版本和过滤原因，再沿链路定位：
| 现象 | 首先检查 | 不要先做 |
|---|---|---|
| 明明有文档却零结果 | 索引是否成功、租户/权限/版本过滤是否过严 | 直接提高相似度阈值 |
| 专有名词或错误码找不到 | 清洗是否保留原文、关键词索引和分词配置 | 只更换生成模型 |
| 主题相近但没有答案证据 | Chunk 边界、查询表达、候选覆盖和重排 | 只扩大最终 Prompt |
| 召回大量重复片段 | Overlap、父子 Chunk、融合去重 | 把所有重复片段交给模型 |
| 召回正确但回答错误 | 上下文顺序、截断、引用约束和生成阶段 | 继续调召回参数 |
| 某些用户能搜到不该看的内容 | 授权来源和服务端过滤是否在召回前生效 | 依赖 Prompt 要求模型保密 |
解析与清洗问题回到 文档导入与清洗，边界问题回到 文本切分与 Chunk Size。每次只改变一个主要变量，并使用 RAG 评估方法比较候选版本，才能知道改善来自哪里。
5. 权限、引用与失败降级
- 权限条件应由可信身份映射为服务端过滤表达式，并同时约束向量、关键词、缓存和重排候选。
- 过滤最好尽可能早地进入检索；若基础设施只能后过滤，要验证候选不足和侧信道风险。
- 每个结果保留
document_id、版本、标题路径、定位和访问范围，生成引用后再校验引用确实来自本次授权候选。 - 向量、关键词或重排任一路超时，不应静默伪装成完整成功。可以按已评估的策略降级、返回“证据不足”，并记录降级原因。
- 查询、候选文本和日志可能含敏感信息，追踪默认记录 ID、耗时、版本和结果统计，而不是完整正文。
总结
混合检索和重排序是常见选项，不是所有 RAG 的固定标准配置。简单语料可能只需一种检索；精确标识符、跨语言或领域术语场景则可能从混合检索获益。最终方案必须由代表性评估集、权限正确性、延迟和成本共同决定。
回到 RAG 专题查看学习顺序；下一步阅读 RAG 评估方法建立回归基线，或用 RAG 生产化检查清单核对检索、权限、引用和降级证据。完整项目连接见 企业级 RAG 知识库。