标准回答
先判断是「召回不到」还是「排序靠后」（独占一行）
这是 RAG 调试的分水岭。准备一批带标注（query → 应命中文档）的检索评测集，看 Recall@k：若正确文档根本不在 top-k 里，是召回问题；若在 top-k 里但排名靠后没被用上，是排序问题。两类病因和解法完全不同。
召回阶段排查
若召回不到：检查 embedding 模型是否匹配业务领域与语言（通用模型在专业/中文语料常偏弱）、分块 粒度是否过大（稀释语义）或过小（丢上下文）、query 是否需要改写/扩展（口语化、含指代、过短时召回差），以及是否该上混合检索（向量+关键词 BM25）补齐稀有词与精确匹配。
排序阶段优化
若正确文档已召回但排名靠后：引入 reranker（交叉编码器）对 top-k 精排、调整相似度阈值与返回数量、避免阈值过高把正确结果过滤掉。
索引与数据一致性
检查向量索引是否随知识库更新而重建、文档与向量 id 是否对齐、有无漏建或脏数据、chunk 元数据/过滤条件是否误伤目标文档。
常见误区
⚠️ 常见踩坑
不先用 retrieval 指标区分召回还是排序问题，就盲目加 rerank 或换 embedding——若根本没召回到，rerank 救不回来；以及只看最终回答好坏，不单独评估检索环节。
追问
追问 1：为什么要把检索评测和最终回答评测分开？
最终回答受检索、Prompt、模型多个环节共同影响，端到端指标差时无法定位根因。单独评测检索（Recall@k、MRR、命中率）能直接判断「料有没有取对」，把问题隔离到检索环节，避免在生成端反复调 Prompt 却治不了「巧妇难为无米之炊」。
追问 2：query 改写在什么情况下最能提升召回？
当用户 query 短、口语化、含指代或与文档用词不一致时最有效：可做 query 扩展/同义改写、多查询生成（multi-query）覆盖不同表述、对话场景做指代消解补全上下文，或用 HyDE 生成假设答案再检索。本质是缩小 query 与文档的语义/词面鸿沟。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。
🛠️ AI 工具