RAG排查基础教程（非常详细）：从小米二面题看检索不到如何定位，收藏这篇就够了！

1. 题目分析做过 RAG 系统的人都知道上线之后最头疼的不是模型幻觉而是检索不到想要的东西。“我明明上传了这个文档为什么问不出来”。检索不到意味着后面的生成环节再强也是徒劳。而这个问题之所以难排查是因为 RAG 的检索链路是一条多环节串联的管道——文档处理、向量化、检索召回、结果过滤任何一个环节出了问题最终表现都是一样的用户问了系统答不上来。所以排查的核心思路是沿着数据流方向从前往后逐层定位。像查水管漏水一样从水源开始一段一段检查哪段没水就是哪段出了问题。1.1 先看源头文档到底进来了没有很多时候根因出奇地简单——文档压根没有正确入库。入库脚本跑挂了、某些 PDF 解析失败静默跳过了、或者入库过程中途异常退出只进了一半这些情况在生产环境中比想象的常见得多。排查方法很直接去向量数据库里查文档总数和预期对比。如果数量不对翻入库日志找报错。数量对了也不能放心还要看切分Chunking质量。切分策略直接决定了每个 Chunk 的语义完整性——切得太大一个 Chunk 里混了好几个主题语义不聚焦切得太小上下文丢失单个 Chunk 读起来都不知道在说什么。最坑的是把关键信息切断了比如一个完整的表格被劈成两半用户问相关问题时两个 Chunk 单独看都不完整自然匹配不上。实际操作中随机抽几个 Chunk 看看内容是否连贯基本就能判断切分策略有没有问题。还有一个容易踩的坑是元数据Metadata错误。如果系统在检索时加了元数据过滤比如按时间、按部门筛选而文档的元数据字段缺失或格式不对本该被检索到的内容就会被静默过滤掉。用户问2024年的销售数据但文档的时间戳字段是空的——这种 bug 不看元数据根本发现不了。1.2 再看向量化语义表示对不对文档入库没问题下一步看向量化环节。这个环节的核心问题是文档和查询是否被正确地映射到了同一个语义空间。最低级但最常见的错误是模型不一致。文档入库时用的 text-embedding-ada-002后来升级换成了 bge-large-zh但存量文档没有重新向量化——新查询和老文档在两个完全不同的向量空间里相似度计算毫无意义。这种问题在系统迁移或模型升级时特别容易出现排查时第一件事就是确认入库和查询用的是同一个模型、同一个版本。模型一致了还要看模型能力是否匹配场景。通用 Embedding 模型在专业领域医疗、法律、金融的表现往往不够好因为这些领域有大量专业术语和特定的语义关系通用模型没见过或者理解不准确。中文场景用英文为主的模型也会打折扣。解决方案是换更适合的模型中文场景 bge、m3e 系列表现不错或者用领域数据对 Embedding 模型做 fine-tune。还有一种更隐蔽的问题查询和文档的表述方式差异太大。用户问怎么退货文档里写的是退货流程客户需在收到商品后7日内联系客服……。语义是相关的但一个是口语化的短问句一个是正式的书面长段落向量距离可能比预期大得多。应对这个问题有几个经典策略。查询改写Query Rewriting用 LLM 把口语化查询改写成更接近文档风格的表述再去检索。HyDEHypothetical Document Embeddings让 LLM 先根据查询生成一段假想的答案文档用这段假想文档的向量去检索——文档对文档的匹配通常比问题对文档更准确。或者反过来在入库时对每个 Chunk 生成假想问题检索时用问题对问题的方式匹配。1.3 三看检索召回找到了但排不上来向量化没问题但结果还是不理想问题往往出在检索参数配置上。这一层的排查思路是逐个放宽限制看哪个参数卡住了召回。相似度阈值是第一个嫌疑人。很多系统会设一个阈值只返回相似度高于阈值的结果。阈值设得太高比如 0.85一些相关但不是完全匹配的内容就被过滤掉了。排查时把阈值临时调低到 0.5 或 0.6看是否能检索到——如果能说明阈值过严。TopK是第二个。TopK 设为 3但相关内容排在第 5 位用户就看不到。把 TopK 调到 20看相关内容是否出现在后面的位置。如果出现了问题不是检索不到而是排序不够靠前这时候需要优化的是排序策略而不是检索本身。元数据过滤条件也要检查。临时去掉所有过滤条件做一次纯向量检索如果能找到内容说明是过滤条件把它排除掉了。最后是索引参数。向量数据库的近似最近邻索引HNSW、IVF 等为了加速检索会牺牲一定的召回率。如果 HNSW 的 ef_search 或 IVF 的 nprobe 设置过小可能漏掉相关内容。对比精确检索暴力遍历和索引检索的结果就能判断是不是索引参数的问题。1.4 最后看重排序和后处理前面都没问题还有一个容易被忽略的环节——Rerank 和结果后处理。很多 RAG 系统在向量检索之后会用 Reranker 模型对结果重新排序。如果 Reranker 判断失误可能把真正相关的内容降到很后面。排查方法是对比重排序前后的结果列表看相关内容的排名变化是否合理。去重逻辑过于激进也是一个常见坑。多个 Chunk 来自同一文档的不同段落去重逻辑可能只保留了第一个把其他相关 Chunk 都丢掉了。还有一个容易被忽视的点送入 LLM 的上下文被截断。检索到了 10 个相关 Chunk但因为上下文窗口限制只送了前 3 个进去真正回答问题的内容在第 7 个 Chunk 里——用户觉得检索不到其实是检索到了但 LLM 没看到。1.5 排查的工具和方法论有了排查思路还需要趁手的工具。Trace 系统是最基础的保障。每次检索都应该记录完整链路原始查询、改写后的查询、检索到的 TopK 结果含相似度分数和 Chunk 内容、重排序后的结果、最终送入 LLM 的上下文。LangSmith、LangFuse 都能做到这一点。有了 Trace排查时不用猜直接看数据就知道问题出在哪一步。同时最好还要有对比实验。怀疑 Embedding 模型不行换一个跑同样的查询对比。怀疑切分策略有问题用不同策略重新入库对比效果。每次只改一个变量就能精确定位问题。最后当然可能还需要人工标注测试集。准备一批典型查询标注每个查询应该检索到哪些文档用这个测试集跑召回率和准确率。这样优化前后的效果对比就有了客观依据而不是凭感觉说好像好了一点。2. 参考回答RAG 检索不到时我的排查思路是沿着数据流方向从前往后逐层定位。首先看文档处理环节确认文档是否正确入库、Chunk 切分是否合理、元数据是否完整这一层的问题最致命也最容易被忽视。然后看向量化环节重点检查入库和查询用的 Embedding 模型是否一致模型能力是否匹配场景以及查询和文档的表述差异是否过大——如果是表述差异问题可以用查询改写、HyDE 或假想问题生成来缓解。接着看检索召回环节逐个放宽相似度阈值、TopK、元数据过滤条件和索引参数定位是哪个参数卡住了召回。最后看重排序和后处理对比 Rerank 前后的结果看是否有误判检查去重逻辑和上下文截断问题。工具层面我会依赖 Trace 系统记录每次检索的全链路数据用对比实验验证假设用人工标注的测试集量化评估效果。整体原则就是每层都有明确的检查点和验证方法靠数据定位而不是靠猜。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】