检索不准的时候如何进行合理的排查？排查的顺序是什么

P1 · rag

🏷 标签：rag, retrieval, debugging, troubleshooting

1️⃣ 考察意图

面试官想看的不是你会背“分块-嵌入-检索”的流程，而是你能否在真实生产环境中，面对“检索不准”这个模糊问题，快速定位根因并给出可落地的修复方案。这是典型的系统设计 + debug 类型题目，刁钻点在于：候选人容易一上来就调模型或改参数，而忽略了“先确认问题类型”和“数据质量”这两个最基础但最高频的坑。答好了能展示你的系统化 debug 思维、对 RAG 整条链路 trade-off 的理解，以及从日志/指标反推问题的工程能力。

2️⃣ 标准答

排查检索不准，核心原则是从外到内、从数据到模型、从召回到排序。推荐按以下顺序逐层排查：

第一步：确认问题类型——召回不足还是排序不准？

看用户反馈或日志：如果用户问“XX 是什么”，模型答“没有相关信息”，大概率是召回不足（Recall 低）；如果答了但答非所问或信息冗余，可能是排序不准（Precision 低）。
用指标量化：在离线评估集上算 Recall@K 和 Precision@K。如果 Recall@5 < 0.7，优先排查召回；如果 Recall@5 > 0.9 但 Precision@5 < 0.5，优先排查排序。
实际坑：很多团队只看 Recall 不看 Precision，导致检索出一堆无关文档，模型被噪声淹没。解法是同时监控 NDCG@K。

第二步：检查数据质量——这是最容易被忽略的根因

分块（Chunking）：分块太大（>512 tokens）会导致语义混杂，太小（<64 tokens）会丢失上下文。常用策略是递归字符分割（RecursiveCharacterTextSplitter），chunk_size=256-512，chunk_overlap=20-50 tokens。为什么这么做：overlap 能保证跨块语义连续性，但过大（>100 tokens）会引入冗余，降低检索效率。
元数据完整性：检查文档是否有标题、时间、来源等元数据。如果检索时只靠 embedding 相似度，没有元数据过滤（如时间范围），容易召回过时信息。解法：在向量数据库（如 Milvus）中建标量索引，用 filter 缩小搜索范围。
噪声数据：检查是否有重复文档、乱码、无关段落（如广告）。实际落地的坑：某次线上检索不准，排查发现是因为爬虫把网页的“相关推荐”模块也抓进来了，导致 embedding 被污染。解法是加一层规则过滤（如长度 < 50 字符的 chunk 直接丢弃）。

第三步：检查检索策略——embedding 模型和检索算法

Embedding 模型：是否与领域匹配？通用模型（如 text-embedding-ada-002）在垂直领域（如医疗、法律）效果差。解法：用领域数据微调一个 BGE 或 E5 模型，或者用多任务模型（如 BAAI/bge-large-en-v1.5）。为什么这么做：通用模型对专业术语的语义区分度低，比如“心肌梗死”和“心绞痛”在通用空间里距离很近，但领域模型能拉开。
检索算法：只用稠密检索（如 HNSW）还是混合检索（稀疏+稠密）？HNSW 的 efConstruction 和 M 参数影响召回率和速度。工程取舍：efConstruction 越大（如 500），建索引越慢但召回率越高；M 越大（如 32），内存占用越高但检索精度越好。实际坑：某次线上 Recall 低，发现是因为 HNSW 的 ef_search 设成了 10（默认 40），导致只搜索了局部邻居。解法是调大 ef_search 到 100-200，并配合混合检索（BM25 + 稠密向量加权，权重 0.3/0.7）。
查询改写（Query Rewriting）：用户 query 可能太短或太模糊。解法：用 HyDE（Hypothetical Document Embeddings）先生成一个假设文档，再用其 embedding 去检索；或者用 LLM 做 query 扩展（如“苹果” -> “苹果公司股票 2024”）。

第四步：检查排序阶段——Reranker 和阈值

Reranker 模型：是否用了 cross-encoder（如 BGE-reranker-v2-m3）？如果只用 embedding 相似度排序，精度不够。为什么这么做：cross-encoder 能对 query 和文档做深度交互，比双塔（bi-encoder）更准，但速度慢（通常只 rerank top-50 结果）。
阈值设置：相似度阈值设得太高（如 >0.9）会漏掉相关文档，太低（如 <0.5）会引入噪声。解法：在验证集上画 PR 曲线，选 F1 最高的点作为阈值。实际坑：某次线上发现阈值 0.7 时 Precision 很高但 Recall 低，用户反馈“找不到信息”。解法是降阈值到 0.5，并配合 reranker 过滤掉低分文档。

第五步：迭代优化——完整流程反馈

收集线上 bad case，定期更新 embedding 模型或 reranker。
用 A/B 测试验证改动效果（如 Recall@5 提升 10% 以上）。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面排查：第一，先确认是召回不足还是排序不准，通过 Recall@K 和 Precision@K 量化；第二，检查数据质量，包括分块大小、元数据完整性和噪声数据，这是最高频的根因；第三，优化检索策略，比如用混合检索（BM25 + 稠密向量）和调 HNSW 参数，最后用 reranker 提升精度。总结一句：排查顺序是从外到内、从数据到模型，先解决数据问题再动模型参数。”

4️⃣ 高频追问 & 应对

追问 1：如果排查后发现是 embedding 模型的问题，但你们没有资源微调，怎么办？

用零成本方案：第一，换用更强的通用模型，比如从 text-embedding-ada-002 换成 BAAI/bge-large-en-v1.5，后者在 MTEB 上平均分高 5-10 点；第二，加查询改写，比如用 LLM 把用户 query 扩展成 3-5 个变体，分别检索后合并结果；第三，用混合检索，BM25 的稀疏向量能弥补稠密模型的领域盲区。如果还不行，考虑用 HyDE 生成假设文档，提升召回率。

追问 2：你怎么量化“检索不准”？有没有具体的指标和阈值？

用 Recall@K 和 Precision@K。比如在验证集上，如果 Recall@5 < 0.7，说明召回不足；如果 Precision@5 < 0.5，说明排序不准。更细的指标是 NDCG@K，能反映排序质量。阈值设定：在 PR 曲线上选 F1 最高的点，比如相似度阈值 0.6。线上监控时，用 p95 延迟和召回率变化作为告警信号。

追问 3：如果分块没问题，embedding 也换了，但 Recall 还是低，下一步查什么？

查检索算法的参数和索引结构。第一，检查 HNSW 的 ef_search 是否太小（默认 40，建议 100-200）；第二，看是否用了 IVF 索引，nlist 和 nprobe 参数是否合理（nlist=1000, nprobe=10 是常见起点）；第三，检查向量维度是否匹配（比如 embedding 模型输出 768 维，但索引设成了 512 维）。如果这些都没问题，考虑加一层多路召回，比如用不同 chunk 策略（滑动窗口 vs 语义分割）分别检索后合并。

5️⃣ 避坑 · 常见错误答法

❌ 一上来就说“调大 chunk size 或换 embedding 模型” → ✅ 先确认问题类型（召回 vs 排序），再查数据质量，最后才动模型参数。数据质量问题是 80% 的根因。
❌ 只提“用混合检索”但不说具体权重和为什么 → ✅ 给出具体 trade-off：BM25 权重 0.3-0.4，稠密向量 0.6-0.7，因为稠密模型对语义理解更好，但 BM25 能补关键词匹配的盲区。
❌ 忽略日志和指标，只凭感觉说“可能分块有问题” → ✅ 用 Recall@K 和 Precision@K 量化问题，再结合日志中的 bad case 定位具体 chunk 或 query。

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在 XX 项目中遇到过检索不准，通过分块优化和混合检索提升了 Recall@5 15%”切入，具体说怎么用日志定位问题、怎么调 HNSW 参数。
如果你只做过传统 NLP：用“信息检索中的 query 扩展和 BM25 调参”类比，强调你对召回率和精度的 trade-off 理解，以及如何用离线评估集验证。
如果你是校招无项目：聚焦“在开源 RAG 系统（如 LangChain）中复现过检索 debug 流程”，比如故意引入分块过大或 embedding 不匹配，然后按上述步骤排查并修复，展示系统化思维。
《Improving Retrieval-Augmented Generation with Hybrid Search and Reranking》——混合检索和 reranker 的实践指南
《BGE: A Family of Embedding Models for General-Purpose Retrieval》——BGE 模型论文，含领域微调方法
《HNSW: Hierarchical Navigable Small World Graphs for Approximate Nearest Neighbor Search》——HNSW 算法原论文，理解 efConstruction 和 M 参数
《HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels》——HyDE 论文，查询改写的经典方案
《LangChain Debugging Guide: Retrieval Troubleshooting》——LangChain 官方文档，含分块、检索、排序的 debug 示例

—— 本场面试完 ——