ARTICLE · 1280048
RAG召回失败真相:文档里有答案,为什么就是搜不到?90%的人都踩了这个坑!
我是老九，一个一直在一线折腾技术和AI的人。AI难的不是跑通Demo，而是上线以后。记录一个个真实小问题：出现了什么、怎么排查、原因在哪、怎么解决。欢迎关注我！
不要错过文章最后的总结图呦！
当前章节：第六章｜RAG开始检索以后
当前小节：第一节｜搜不到
本篇问题：召回失败
知识库上线后，让人头疼的不是胡说八道。直接告诉用户：“知识库中没有找到相关信息。”文档里明明有答案。
文件上传成功，解析没错，向量数据库里有数据。答案去哪了？刚开始怀疑Embedding模型不够好，或向量数据库有问题。
文档里有答案，不等于这次检索把答案找出来了。
先查：用户提问，检索接口返回了什么？
假设日志显示：
检索问题：E07故障怎么处理？
Top K：3
第一条：设备通信接口说明，相似度0.82。
第二条：网络连接异常处理，相似度0.78。
第三条：通信模块日常维护，相似度0.75。
都挺相关，但没有一条包含E07的完整处理步骤。不是模型看到了答案不肯说，是检索阶段没有把正确内容交给模型。
继续查。
第一步，确认答案是否真的进入了索引。
前面聊过PDF解析、表格丢结构和Chunk切片。只要有一个出问题，原始文档里的答案就可能没有形成可检索的Chunk。
直接查入库记录，找到E07对应的原始文本、Chunk编号和向量状态。
如果E07这个Chunk不存在，就不是召回算法的问题。得检查解析和切片。如果Chunk存在，向量生成成功，再往下看。
第二步，检查检索范围有没有搞错。
向量数据库运行正常，检索接口也返回了结果，只是没在正确的数据范围里搜索。还有租户ID、文档状态、权限标签、设备型号等过滤条件。只要其中一个条件不匹配，正确答案就可能被排除。
在授权的测试环境里临时放宽过滤条件做对照。如果放宽后能找到，就要查具体是哪条条件过滤掉了它。
第三步，看看用户的问题和文档里的说法是不是差得太远。
用户问：“设备连不上了怎么办？”
文档写的是：“E07通信模块异常处理流程。”
我们知道这两句话有关联，但向量检索不保证都能准确建立这种联系。尤其是故障代码、产品型号、设备编号这些内容。业务含义很精确，单靠语义相似度未必可靠。
可以试着换一种问法。如果第二次能找到，第一次找不到，就说明问题可能在查询表达与文档内容的匹配上。可以考虑关键词检索和向量检索结合。
第四步，检查Top K和相似度阈值。
假设正确答案排在第五名，系统只返回前三条。那它自然进不了模型上下文。
相似度阈值也要检查。如果系统设置了较高的过滤阈值，正确答案即使参与了检索，也可能在返回前被丢弃。
不同向量数据库和检索配置返回的可能是相似度，也可能是距离。
阈值方向弄反了，越相关的内容反而越容易被过滤。
做一个验证：把检索接口的原始返回结果，和最终送给大模型的上下文对比。
有些系统检索到了正确Chunk，但后面还有重排、去重、Token预算裁剪等步骤。
为了避免反复排查，给知识库检索增加一条完整的追踪记录。至少能看到用户原始问题、实际检索词、知识库范围、候选Chunk、过滤和重排结果，以及最终交给模型的内容。
总结下，RAG回答问题，第一关不是模型会不会回答，而是系统能不能把正确资料找出来。
下次遇到“文档里明明有答案，AI却说找不到”，先看检索返回的Chunk。先确认答案有没有被召回，再决定下一步该查哪里。
如果你读着还行，欢迎点赞收藏关注；如果有不同的观点，也欢迎大家留言讨论。
