跑 RAG 项目最让人憋屈的不是什么结果都检索不到而是系统明明召回了一大堆看着高度相关的片段相似度分数一个个都高得吓人最后生成出来的答案却错得离谱。我前段时间在调一个内部知识库问答系统模拟项目X用户问报销审批需要几个工作日检索模块返回了七八段报销流程相关的内容分数字体漂亮结果模型答了个部门负责人审批需要 1-2 个工作日直接把财务复核和打款到账两个环节给吞了。这不是孤例几乎每个做 RAG 落地的人都会撞上这种检索到了相似内容但答案就是不对的鬼问题。这篇文章把我排查这类问题的完整思路、诊断手段和修复方案梳理一遍希望能帮你少走几个弯路。1. 先搞清楚相似不等于正确1.1 检索系统的语义相似到底是什么要理解这个问题的根源得先看向量检索干了什么事。现在主流的 RAG 方案都是把文档切成块用 embedding 模型把每一块文本映射成一个高维向量用户提问的时候把 query 也映射成向量然后在向量空间里找距离最近的几个块。这里面的核心假设是语义上相近的文本在高维空间里距离也会比较近。这个假设在大方向上是成立的但它有一个容易被忽略的短板embedding 模型学习的语义相近和人类判断的这段文字能回答这个问题完全是两码事。比如用户问系统宕机了怎么处理向量检索可能召回一段讲系统宕机的常见原因分析的文章里面全是为什么宕机、怎么预防宕机就是没有宕机之后第一步该做什么。从语义层面看这段内容确实跟 query 高度相关但它不包含回答问题所需的事实信息。我用一个更生活化的类比来理解你在搜索引擎里搜西红柿怎么吃结果搜到一篇文章《西红柿的十大常见做法》标题看着完美命中但正文讲的全是用西红柿做番茄酱的工业流程。搜索引擎确实没骗你它真的检索到了相似内容——可你要的答案是凉拌西红柿怎么调味。RAG 里的向量检索也一样它保证召回的内容和问题在同一个话题域但不保证召回的内容就是能直接支撑答案的论据。1.2 从检索到回答的四个失环节点既然相似和正确是两码事那我们排查问题的时候就得把 RAG 这条链路拆开来看。我习惯把一个完整的 RAG 回答过程分成四个节点数据准备节点原始文档被切分成 chunk这个环节如果切得不合理关键信息可能被切断。检索召回节点embedding 模型计算相似度选出 top-k 个 chunk这个环节可能出现伪相关或者真正有用的 chunk 因为相似度不够高被刷掉。上下文编排节点召回的 chunk 被拼进 prompt塞给大模型这个环节可能出现信息排挤关键内容被无关内容淹没。生成回答节点大模型根据 prompt 里的上下文生成答案这个环节可能出现幻觉或者模型迷信自己的参数记忆不理会检索到的内容。答案错误一定是这四个节点中至少一个出了问题。很多人的第一反应是我的检索器该换了但实测下来最坑的反而是第一和第四个节点。我后面会详细展开。2. 五大元凶为什么相似内容带不来正确答案2.1 分块硬切答案被拦腰截断这是最常见、也最隐蔽的问题。为了迁就 embedding 模型的输入长度限制通常是 512 或 1024 token很多人在做 RAG 的时候会对文档做固定长度的切分。逻辑上没错但实际操作时经常从句子中间、甚至表格单元格中间直接下刀。我记得某次排查报销审批需要几个工作日这个问题时问题出在一份 PDF 报销制度里有一张表格列着部门负责人审批1-2 个工作日财务复核1-3 个工作日打款到账1-5 个工作日。因为表格的行数据是按嵌入换行符切分的第一行被切到了 chunk A后两行被切到了 chunk B。检索 报销审批需要几个工作日 的时候chunk A 因为包含审批两个字相似度分数最高被召回但它的内容只有部门负责人审批1-2 个工作日模型不知道后面还有两行自然只能回答1-2 个工作日。解决方案倒不复杂切分时优先按语义边界走段落、标题、列表项、表格行都可以作为切分边界如果必须用固定长度也要设置 10% 到 15% 的重叠区域避免信息断在边缘。2.2 向量相似度的伪相关陷阱embedding 模型不是万能的它对某些关键信息的感知能力远没有我们想象的强。三个典型盲区否定词和程度词支持 A 功能和不支持 A 功能在向量空间里的距离可能非常近因为两个句子共享了绝大部分词汇和句法结构embedding 模型在这种细粒度语义上很容易翻车。专有名词和精确编号比如V2.3.1、订单号 SO-20241108这类 token在 embedding 空间里几乎不携带语义信息。你问V2.3.1 修复了哪些 bug检索器更可能召回大段讨论修复 bug的文本而不是那个真正列出 V2.3.1 变更日志的文档。文档长度偏差长文档的向量会向多个方向平均化短文档的向量更集中。这会导致长文档在相似度计算中常常被低估真正包含答案的长文档反而排不到前面。这里还有一个新手常踩的坑拿相似度分数 0.8当检索可靠的标准。不同 embedding 模型的分数量纲完全不同甚至同一模型在不同向量库Chroma 返回的是 distance 越小越相似FAISS 默认是相似度越大越像里含义都不一样。绝对值没有意义只有排序有参考价值。2.3 上下文里的信息排挤效应假设检索模块确实召回了包含正确答案的 chunk问题也未必解决。现在大模型的上下文窗口动辄几十万 token但很多 RAG 实现会把 top-k 拉到 10 个甚至 15 个 chunk 拼进去。表面上看给模型的信息越多越好实际效果往往相反。原理在于 transformer 的自注意力机制和信息密度之间有个天然的矛盾当上下文塞进大量与问题无关的噪声时模型会被分散注意力关键信息在注意力矩阵里的权重会被稀释。换句话说正确答案明明在上下文里但模型没看见它。我做过一个对比实验同一份文档一个问题分别喂 top5 和 top15 的检索结果。top5 的回答正确率更高top15 反而因为混入了两个语义相似但不相关的 chunk导致模型在几个候选解释之间犹豫最终给出一个模棱两可的答案。这不是模型变笨了而是信息过载导致的注意力涣散。2.4 模型的先验知识在干扰回答大模型在预训练阶段就积累了大量知识。RAG 的设计初衷是让模型在推理时优先依赖检索到的外部信息而不是依赖参数记忆。但实际提示词如果不做强制约束模型很容易自我发挥。典型场景是开放域问题。你问什么是量子纠缠模型可能根本不看检索上下文直接凭预训练记忆回答。如果这时候知识库里恰有一篇内部技术文档对量子纠缠有不同于主流定义的描述模型大概率还是选择它记忆中最顺的那套说法而不是知识库里的答案。更麻烦的是先验知识和上下文内容互相矛盾时模型会倾向于和稀泥——它会尝试把两个来源的信息糅在一起生成一个表面平滑、实则错误的答案。这就是我在文章开头提到的报销审批案例里模型把审核和打款时间混在一起的原因。2.5 提示词和生成参数没有约束住模型这其实是 2.4 的直接延伸。很多 RAG 提示词只写了一句请根据以下内容回答问题这种松散的指令给了模型太大的自由裁量空间。另一个重要变量是解码参数。temperature 设置过高时模型在 open-ended 生成任务上的表现尚可但在 RAG 这种要求忠实于给定资料的任务上过高的温度会放大幻觉风险。我见过有人直接用默认 temperature1.0 跑 RAG结果随机性大得离谱同一问题两遍答案不一样。调低到 0.1~0.2 之后忠实性立刻提升。3. 怎么定位问题到底出在哪一段链路我一直强调先定位再修复。如果拿到一个回答错误的 case 就急匆匆去换 embedding 模型或者改 chunk 大小大概率是瞎折腾。下面这四步诊断法是我在实际项目中固定下来的流程。3.1 第一步把检索结果摊开来看先在代码里打印出召回的每一个 chunk 和对应的相似度分数人工读一遍判断这个 chunk 到底包含不包含答案。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings vector_db Chroma( persist_directory./kb, embedding_functionOpenAIEmbeddings() ) query 报销审批需要几个工作日 hits vector_db.similarity_search_with_score(query, k5) for idx, (doc, score) in enumerate(hits): print(f Chunk {idx 1} | score: {score:.4f} ) print(doc.page_content[:300]) print()这一步做好之后你会看到两个典型结果一是所有召回 chunk 里根本没有答案问题出在召回链路二是召回 chunk 里有答案但模型没答对问题出在生成链路。两者修复方向完全不同。3.2 第二步两个对照实验切分故障域如果光靠肉眼判断还不够就做两个对照实验。实验 A检查生成链路是否健康。人为构造一个 prompt把标准答案直接用context标签塞进去看模型能不能从里面准确抽取出答案。prompt 请仅根据以下资料回答用户问题。如果资料中没有答案请直接回复资料中未找到答案。 资料 报销审批流程部门负责人审批需1-2个工作日财务复核需1-3个工作日打款到账需1-5个工作日。 /资料 用户问题报销审批需要几个工作日 如果这个实验模型都能答错那说明生成环节的提示词或模型配置有硬伤跟检索器没关系。如果答对了那就证明答案喂到嘴边模型是能说对的问题大概率出在检索端。实验 B检查检索链路是否健康。把 top-k 缩小到 1只让检索器返回相似度最高的那个 chunk看模型回答质量。如果 top1 就答对了说明检索器没问题是多个 chunk 混在一起互相干扰如果 top1 错而 top5 对说明排序有问题真正有用的 chunk 排太靠后。3.3 第三步单独验证召回链路如果确认问题在召回链路把同一问题做几个同义改写看检索结果的稳定性。比如报销审批要多久、审批报销单需要几个工作日、报销打款什么时候到账如果这几个改写召回的 chunk 差异很大可能是 embedding 模型对领域词汇理解不够或者原始文档的切分粒度有问题。这种场景下可以试试换更强的 embedding 模型也可以考虑切换分块策略后面展开但不要一次改多个变量。一次只改一个才能准确判断哪个改动有效。3.4 第四步单独验证生成链路如果确认问题在生成链路优先检查提示词是否写清楚了忠实性约束然后把 temperature 调低到 0.1~0.2同时把 top-p 同步调低。这两个参数会明显降低模型自由发挥的倾向。还有一个我习惯用的技巧在提示词后面加一句在回答末尾用标签列出你参考的是哪几个资料片段。这个技巧有两个好处一是强制模型在作答时检索一遍上下文中的来源信息二是方便你从输出反推它是否真正使用了检索内容。如果模型给出的引用编号跟实际使用的 content 对不上说明它在编造来源提示词约束还是不够强。4. 实战修复一套能落地的正确做法诊断完之后就要动刀了。下面这套方案不是理论全是我在模拟项目里实际验证过的组合拳。注意不要一次性全上按优先级逐个生效。4.1 混合检索把精确匹配捡回来向量检索擅长语义泛化但不擅长精确匹配。要解决专有名词、编号、版本号这类召回盲区最直接的方法是引入 BM25 这种基于关键词的检索器把两者结果做融合。我这里用的是 RRFReciprocal Rank Fusion原理非常简单对每个文档根据它在两种检索结果中的排名计算一个融合分数排名越靠前分数越高最后按融合分数排序。from rank_bm25 import BM25Okapi def reciprocal_rank_fusion(bm25_results, vector_results, k60): fused {} for rank, doc_id in enumerate(bm25_results): fused[doc_id] fused.get(doc_id, 0) 1.0 / (k rank) for rank, doc_id in enumerate(vector_results): fused[doc_id] fused.get(doc_id, 0) 1.0 / (k rank) return sorted(fused.items(), keylambda x: x[1], reverseTrue)RRF 的好处是不需要调权重天然避免了BM25 和向量分数量纲不一致的问题。实际效果上混合检索对包含精确编号和专有名词的 query 提升非常明显召回的 MRR平均倒数排名能涨 10% 到 20%。4.2 重排模型粗召回之后再精排双塔结构的 embedding 模型为了追求检索速度牺牲了一定的精度。它给每个文档算一个向量query 算一个向量靠向量距离排序这种方案做第一轮粗召回是划算的但做精排往往不够用。我的做法是两段式检索先用 embedding BM25 粗召回 top50 的候选再用 cross-encoder 重排模型在候选集里精排取 top5 给生成模型。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-large) pairs [[query, doc.page_content] for doc in candidate_docs] scores reranker.predict(pairs) # 按重排分数降序取前5个 top_indices scores.argsort()[::-1][:5]cross-encoder 的原理是把 query 和文档拼成一个序列直接送进模型让模型对它们的关系做精细判断精度比双塔高不少代价是速度慢。但在粗召回 50 条 精排 5 条这种组合下整体延迟通常还能控制在可接受范围内。如果你的 RAG 是给内部员工用而不是 C 端高并发强烈建议上一套重排。4.3 分块策略从源头保护信息完整性前面提到固定长度切分很容易切坏表格、列表和段落。我的分块策略是分层的结构化切分优先如果文档有 Markdown 标题、章节结构按章节切。一个章节内部再按段落切保留段落完整性。语义边界兜底如果没有明确标题按句号、问号、换行符这些自然边界切避免在句中被切断。重叠区域补齐不管怎么切都让相邻 chunk 有 50~100 字符的重叠防止边界上的关键信息被漏掉。父子 chunk 方案这是 LangChain 里常用的一种 pattern小 chunk 负责检索大 chunk 负责给模型提供完整上下文。检索命中一个小 chunk 时把它所属的父级章节一并返回。这样既保证了检索精度又避免了信息断裂。报销审批那个 case我用父子 chunk 方案改造之后检索命中的小 chunk 显示财务复核在下一段再把父级整章内容拼给模型模型一次性答全了三个环节的时间。这个改动解决了很多答案一半对一半错的问题。4.4 提示词与生成策略让模型只信上下文提示词是最后的防线。不是简单加一句请根据以下内容回答问题而是要明确告诉模型资料之外的任何信息都不能用。我在项目里验证过一段比较稳妥的提示词模板你是一个严格依据资料回答问题的问答助手。请遵守以下规则 1. 只能使用资料中的信息回答用户问题禁止使用你自己的知识。 2. 如果资料中没有足够的信息回答问题请明确回复资料中未找到足够信息。 3. 回答时请保持简洁并在结尾用ref标签列出你参考的资料片段编号。 4. 不要对资料中的信息做任何推断或补充。 资料 ... /资料 用户问题...这套提示词至少做了三件事约束了信息源、给出了不知道的兜底出口、强制了引用溯源。实测下来幻觉率明显下降。生成参数方面我建议 temperature 调到 0.1top_p 调到 0.3 左右。虽然这会让回答变得保守、缺少多样性但 RAG 场景的核心需求是准确且忠实不是有创意。要创意就换个场景别在问答里赌概率。4.5 评估闭环不能只靠肉眼调参大多数 RAG 项目死在没有评估体系。你今天改了一个 embedding 模型看起来这个 case 就好了但你不知道另外三十个 case 是不是全军覆没。所以一定要建一个最小可用评估集。做法不复杂把历史上出过问题的 30~50 个问答对整理成一个测试集每个问题手工标注标准答案。每次改完检索或生成策略把整个测试集跑一遍统计三个指标忠实度答案中的每个断言是否能从检索到的上下文中找到依据。上下文相关性检索出的 chunk 和问题之间的相关度。回答相关性答案本身是否准确回答了问题。这三项正好对应前面说的检索、上下文编排、生成三个环节。你可以用成熟的评估框架比如 RAGAS也可以自己写个脚本让一个强模型按这三个维度给结果打分。关键不是工具而是每次改动都有可比较的回归结果而不是靠肉眼感觉好像变好了。5. 常见问题速查表与避坑经验5.1 症状排查速查表我把这些年遇到的检索相似但答案错误情况整理成一张速查表排查的时候直接对号入座。现象优先排查方向诊断手段建议解法检索分数很高但答案完全跑偏召回内容伪相关人工读召回 chunk 是否含答案混合检索 重排检索分数低但 chunk 里其实有答案embedding 模型不匹配或分块切坏同义改写 query 对比召回稳定性换 embedding 模型 / 调整分块检索到答案模型还是答错生成链路不忠实实验 A 人工喂标准答案强化提示词约束 / 调低温度答案对一半错一半chunk 切断了完整信息检查表格、列表是否被切断父子 chunk / 重叠切块同一个问题两次答案不一致解码随机性太高固定随机种子多次测试降低 temperature / top_p专有名词、编号频繁召回失败纯向量检索的精确匹配盲区尝试搜索V2.3.1这类 query引入 BM25 混合检索5.2 几个我踩过的坑第一不要迷信高分。我已经数不清有多少次被相似度 0.87迷惑最后发现那个 chunk 只是跟问题共享了大量关键词实际信息完全没用。分数排序只能告诉你哪些 chunk 在语义上靠近不能告诉你答案是不是在这里面。第二不要过度堆 top-k。把 top-k 从 5 调到 10不会让答案变好只会让上下文更拥挤。我现在的经验是粗召回可以多召精排后最多给模型喂 5~8 个 chunk再多就要靠重排模型帮你筛选了。第三不要在没评估集的情况下反复改参数。RAG 是多个环节耦合的系统改一个参数有时会从别的地方冒出新的问题。没有评估回归你等于蒙着眼睛在迷宫里瞎走。第四一定要区分检索问题和生成问题。我发现很多人在排查时第一反应永远是我的检索没做好结果花了大量时间调 chunk 和 embedding最后发现是提示词少写了一句禁止使用你的先验知识。先诊断再开刀磨刀不误砍柴工。最后分享一个我最近才彻底想通的经验RAG 系统的答案质量本质上是检索到的信息质量和生成模型忠实度的乘积任何一环是零整体就是零。别再单独盯着检索到了相似内容这一步把上下游串起来通盘看才能真正解决答案总是错的困境。