RAG 系统答不准九成问题不在大模型智商也不在 Embedding 精度而在检索质量。向量相似度不等于语义相关、切片丢了上下文、Top-K 塞满噪音 —— 这三件事叠加模型即使拿到了包含答案的片段也会脑补。标准修复路径是向量粗召回 50 条→Rerank 精排取 3-5 条→只把高置信片段喂给模型质量永远比数量重要。一、真实痛点向量库命中了答案却还是错的做问数系统的团队大概率都踩过同一个坑用户提一个问题去向量库检索Top-K 返回的片段明明白白包含了答案关键词甚至整句话都在那儿可大模型生成出来的结果依然一本正经地胡说八道。第一反应通常是换大模型、换 Embedding 模型或者调 Prompt。但把整个链路拆开排查后会发现问题往往出在检索环节本身 ——向量搜索搜到了不代表模型能答对。这不是某一家模型的问题而是 RAG 架构的共性缺陷。下面把三个最核心的根因拆开讲并给出可直接落地的排查步骤。二、根因一向量相似度不等于语义相关性向量搜索的底层是数学。一段文本被转成 Embedding 向量存入 Qdrant 或 Milvus本质上是高维空间里的一个坐标搜索就是找离提问最近的几个点。但 近 不代表 对。举个具体例子。用户问公司去年哪个月亏损最严重 向量搜索可能返回这样一段公司去年业绩增长迅猛但在 7 月份因为供应链问题导致了小幅亏损相较于 6 月份的盈利…… 从数学上看这段话包含 去年 亏损 月份相似度评分极高但如果它没有给出具体亏损额度或者上下文其实在讲盈利预测模型读到这段后缺乏足够事实支撑为了完成任务就会结合训练数据开始脑补。数学上的距离过滤不掉逻辑上的噪音。这是 RAG 最容易被忽视的第一层陷阱。三、根因二碎小切片变成 孤儿片段上下文断裂RAG 通常要对文档做 Chunking。为了省 Token很多团队把块大小设到 200 字甚至更小。向量搜索确实精准命中了包含答案的那一句话但这句话可能是一个孤儿切片。比如命中的片段是它的维护费用大约是每年 5 万元。 模型看到这句话是懵的它是谁如果检索没有把上一段提到的设备型号一起带回来模型在生成时由于指代不明就会随机指派一个它认为可能的对象或者干脆编一个。这种由文档切分导致的上下文断裂是 搜到了也答不准 的重灾区。尤其在问数系统里业务文档里充满了 该系统 上述指标 如表所示 这类指代表达小块切片几乎必然丢上下文。四、根因三Top-K 噪音与 迷失在中间为了提高召回率很多人喜欢把 Top-K 设得很大一次塞 10 个甚至 20 个切片给模型觉得数据够多里面总归有正确答案。实则不然。大模型有一个被反复验证的特性叫Lost in the Middle迷失在中间当上下文过长且掺杂大量似是而非的无关信息时模型会表现得像注意力涣散的学生可能被 Top-1、Top-2 里的噪音带偏反而忽略藏在 Top-5 里的关键事实。信息过载的直接后果是 ——正确答案就在 Prompt 里模型还是给出错误回答。喂给模型的片段越多信噪比越低生成质量越差。五、可执行的排查与修复步骤遇到 RAG 答不准按下面四步走比盲目调 Prompt 有效得多。第一步检查切片策略。不要用固定 200 字的硬切。推荐父子块Parent-Child Chunking用 200-300 字的小块做向量召回命中后返回其父块800-1200 字作为实际上下文喂给模型。这样既保证召回精度又保留了上下文。对包含表格、列表的文档要按语义边界切不能按字符数硬切。第二步控制 Top-K 数量。生成阶段只喂 3-5 个高置信片段不要超过 8 个。如果担心漏召回把召回阶段和生成阶段分开召回阶段取 Top-50生成阶段只取精排后的 Top-3-5。第三步引入 Rerank 重排器。向量搜索属于双塔模型把问题和文档分别编码算余弦相似度快但看不出深层逻辑关系Rerank 模型如 BGE-Reranker属于交叉编码器把提问和候选文档拼在一起深度比对能识别出 关键词很多但根本没回答问题 的片段。标准流程是向量召回 50 条→Rerank 打分→取 Top-3-5 喂模型。这一步能过滤掉 90% 以上的干扰信息。第四步给 Rerank 设分数阈值。这是很多团队漏掉的细节。Rerank 不是加了就完事要设一个最低分阈值比如 0.3需根据自己数据集标定低于阈值的片段直接丢弃不要硬凑 Top-K 数量。否则 Top-1 可能仍是弱相关片段模型照样答错。六、三种检索策略效果对比表格策略召回方式生成输入上下文完整性抗噪音能力适用场景固定小块 直接 Top-K200 字硬切取 Top-1010 个小块差频繁断指代弱简单 FAQ、短问答父子块 直接 Top-K小块召回、父块生成取 Top-55 个父块中中中等复杂度业务文档父子块 Rerank 阈值小块召回 Top-50→Rerank→阈值过滤取 Top-33 个高置信父块好强问数系统、企业知识库、合规问答从实际项目数据看第三种策略相比第一种答案准确率通常能提升 30%-50%而 Token 消耗反而下降因为喂给模型的片段更少更精。七、两个容易被忽略的工程细节第一评估要靠标注集不能靠 感觉对。很多团队调 RAG 参数全凭肉眼看几条结果这是盲人摸象。正确做法是构建 20-50 条标注问答集覆盖简单题、指代题、多跳推理题、对抗性问题每次改配置都跑一遍召回命中率和答案正确率用数据说话。我们团队在扩充对抗性测试集时试过用龙虾 PROhttps://longxiapro.com/批量生成刁钻问法来压测召回质量能快速暴露切片和重排环节的薄弱点。第二问数系统要把 表结构检索 和 文档检索 分开。问数场景里用户问题既要匹配业务文档指标定义、口径说明又要匹配数据库表结构表名、字段名、注释。这两类内容混在同一个向量库里检索模型很容易被表结构里的字段名带偏。建议分库检索、分别 Rerank最后在 Prompt 里明确区分 业务口径 和 数据结构 两部分上下文。八、结论向量数据库本质上是一个模糊索引它解决的是 从海量文档里快速找到可能相关的片段而不是 保证找到的片段一定能回答问题。如果你的 RAG 系统还在胡说八道别急着换大模型按顺序排查切片是不是丢了上下文Top-K 是不是全是噪音有没有 Rerank 和分数阈值给大模型喂的数据质量永远比数量重要。能用 3 个精准片段说清楚的事绝对不要塞 10 个片段。如果发现召回内容总是差那么一点意思加上 Rerank 并设好阈值这一步的收益往往比调优一个月 Prompt 都大。