我看到现在很多团队调了很久RAG最经常遇到的问题就是向量库里明明捞出了一堆相似片段甚至Top 1 结果看起来就是跟问题高度相关最后生成出来的答案却是错的有些还错得挺离谱。这个现象非常典型它是 RAG 系统链路中多个环节共同作用的结果两台字幕一叠加问题就暴露了。今天我就专门把这个坑拆开来讲每一步对应什么潜在问题、怎么排查、怎么解决希望帮你少走不少弯路。可以先打个比方你让一个助理去书架上找“红烧肉怎么做”他给你抱来一本讲五花肉挑选的书。相关吗相关。但你的问题是“步骤”他给你的是“食材标准”。RAG 的朴素逻辑本质上就是这样——它检索的是语义相关不直接保证信息完备。所谓“检索到了相似内容”有时候一点都不代表“检索到了能回答问题的内容”。很多团队在这里误判了方向一直在调检索甚至去换向量模型结果发现水面之下还压着一整套问题。1. 先看清 RAG 的完整链路别把“检索结果”当成“答案正确的前提”1.1 链路拆解每一个环节都会埋雷一个标准的 RAG 流程大致是文档解析 → 分块chunking→ 向量化embedding→ 向量召回retrieval→ 重排rerank→ 上下文组装prompt building→ 大模型生成generation。很多人理解的 RAG 就是“召回 生成”两步但实际上从文档解析开始每个环节都会往结果里注入误差。检索相关度高只是其中一个中间指标它不承担“最终答案正确”的全部责任。你得把整条链路当成一条河流来看任何一个环节污染了下游再努力也白费。我在实际调试中见过很多案例检索端指标刷得很漂亮Hit Rate 90% 以上但端到端人工评测一看错误率还是高。原因就藏在两个地方检索到的“相似”片段是否真的包含答案以及大模型拿到相似片段后是否真的会按片段回答。这两件事都不过关那表面上游刃有余的 RAG 只是在自嗨。1.2 “相似”与“可用”的差异向量空间近不等于信息完备向量检索的核心是计算语义向量之间的相似度。生活化一点理解你在高维空间里找“邻居”找到的几个邻居在谈论同一个话题但谈论的侧面、详略、颗粒度可能完全不同。比如你问“如何重置密码”检索到的内容讲“密码策略的复杂度要求”——两个片段都围绕“密码”但一个讲操作流程一个讲安全规范。向量距离近是因为话题相近不是因为没有答。这里要认真区分两个概念主题相似topical similarity和答案完备性answer sufficiency。前者是检索系统的事儿后者是资料组织方式的事儿。判断一份检索结果能不能用标准不是“相不相似”而是“把这段内容交给一个不知道答案的人他能否直接从里面解锁答案”。这个标准很多团队压根没建立过所以问题一出现就变成玄学。1.3 一个很常见的误导性“相似”关键词重叠但信息层级错位还有一种很隐蔽的情况用户的问题里包含某些关键词这些关键词刚好在某一页文档里高频出现于是被召回。但文档讲的是这个概念的定义、背景、发展历史不是用户要的那个即时操作说明。比如问“如何排查服务启动失败”召回的内容全是“服务启动失败的常见原因分类”——分类看懂了但还是不知道怎么查具体日志。这时候用户的感受就是系统确实明白我在问什么但它就是没有正面回答。这个错位不是“相似度算错了”而是文档的组织结构没有和用户的信息需求对应起来。处理思路也不是单纯换 embedding 能解决的而是要回到文档处理层把面向“问题”的内容密度做出来。2. 分块策略检索到了“块”但答案不在块里2.1 切分粒度两难块太小没上下文块太大全是噪声分块策略是 RAG 里最容易被低估的环节。块太小比如 128 token 以下语义可能过于局部一个完整的事件或步骤被打散到两三个块里。结果就是你要检索的问题是“A 和 B 的关系”但文档里相关的描述横跨了两块每一块单独检索都没法完整覆盖答案。块太大呢比如 1024 token 以上一个块里可能容纳了三四个子话题向量化出来的表征会被“平均掉”。检索时看着相关度还行但真正对答案有用的句子被淹没在大量周边信息里。大模型在长上下文里“大海捞针”的准确率远没有想象中那么高——上下文越长注意力稀释越严重。从我自己的实践经验来看分块没有万能最优值但起步可以用这几个经验参数通用文本 512 token、有明确结构的文档 384 token、代码类 256 token 左右。关键是不要闭眼硬切要做基于结构的切分。2.2 结构切分与“父子块”策略让答案稳准狠地落在一个块内更好的做法是“结构感知切分”先按 Markdown 标题、HTML 标签、PDF 章节等文本骨架把文档切成大段再在大段内部按长度切小块同时保留大段和小块的关联关系。这样能做两件事检索可以基于小块精准度高语义聚焦但送入模型时把小块所属的整段父级内容一起带上上下文完整这就是经典的parent-child chunking父子分块策略。我用下来之后发现它对那种“答案在一段话里但精准句子分散”的文档特别管用。比如一份操作手册用户问的是“重启后配置是否保留”如果只检索到一句“配置会保留在持久化目录”模型可能不敢确定但如果你把所在的整节“配置持久化机制”全喂进去模型就有足够的上下文给出肯定答案。另外重叠窗口overlap也得设建议重叠 10%~20% 的 token 量避免谓语动词或者关键术语正好卡在切分边界上。这种“边界截断”造成的检索失败特别不显眼因为大部分时候只有个别 case 会踩中但它会让你找不到规律。2.3 表格、列表、代码块的反切分处理像表格、列表、代码块这类强结构内容用普通文本切分方式极其容易损坏。Markdown 表格如果按行切开向量化后表格语义基本就废了代码块切开后语法都断了检索到也看不懂。我的个人做法是识别出这类块整体作为一个不可分割的 chunk 单元如果整体太长就用语义完整的位置作为切分点比如表格按行组分代码按函数切而不是粗暴按字符数切。另外对表格这类内容还可以做一步“表格转文本”的旁路副本让向量化模块更容易获取表格内的语义。3. 上下文组装模型“看到了”正确内容却把它当成干扰信息3.1 指令边界不清参考材料被模型当成了“闲聊素材”这是 RAG 调试里一个极其隐蔽、但极其关键的点。有时候检索没问题分块也没问题错误出在prompt 怎么把检索结果和问题组织在一起。如果你只是简单拼接“下面是一些文档片段请回答用户问题”模型确实会参考但它不一定会严格依赖这些片段。它可能会混合自己的内部知识甚至把检索片段里不相关的边角料也纳入推理。我习惯在 prompt 里非常明确地声明三层结构“以下是可能包含答案的参考文档片段”“请仅基于这些片段回答如果片段中没有足够信息请直接说‘资料中未找到相关信息’”“用户问题……”你别觉得这太啰嗦实测下来这种指令边界的明确性能显著提升忠实性faithfulness。模型不是不会读资料而是它默认拥有“自由发挥”的权限。你把权限收紧了它才会乖乖按资料作答。3.2 上下文噪声和“位置偏差”正确答案被相似内容淹没另一个组装层面的坑是你把 Top 5 甚至 Top 10 的结果全部塞进去但这些结果里可能只有两个是有用的其他都是“差不多的干扰项”。大模型面对这种场景时容易被多数噪声带偏尤其是正确答案不在上下文开头或结尾时中间的片段容易被弱化。位置偏差lost in the middle不是传闻是确实存在的行为特征。解决办法有这么几个方向顶部放最相关的 1~2 个片段把握“多少人看开头”的注意力红利片段之间用明确的 XML 标签或清晰分隔符隔开甚至加上编号在 prompt 里写明“上下文中有多个片段请优先参考编号靠前的片段”最硬核的方案上下文压缩把每个片段先用 LLM 抽取出与问题最相关的部分再拼装发给最终生成模型3.3 上下文窗口超限导致的“静默截断”还有一种非常现实的情况你的检索结果拼起来太长了而模型的上下文窗口有限系统会在组装时做截断。截断默认是从尾部开始砍掉也就是说最晚拼接进来的片段可能直接被丢掉了。如果你把检索结果按相关度由高到低排列那么被砍掉的通常是最不相关的这还好但如果你把问题放在最后面有些实现会从中间抽掉内容或者截断发生在更早的位置那就没法保证正确答案一定还在上下文里。我实际踩过一次拼接了 6 个片段加一个很大的 system prompt总 token 数超了窗口结果其中恰好包含正确答案的那个片段被截断模型给出的答案就变成了胡扯。排查方式也简单把最终发给模型的 prompt 完整打出来自己看一眼到底哪些内容真的被送进去了。很多“AI 答错”的 case其实问题出在“AI 根本没见过正确答案”。4. 重排环节检索 TopK 不等于“值得给模型看的 TopK”4.1 召回是广撒网重排才是精挑细选向量召回的核心是用 embedding 算相似度它本质上是个“粗筛”。因为 embedding 压缩了大量语义信息它擅长判断“领域相近”但不擅长细粒度判断“这个片段是否真的直接支撑了问题答案”。重排rerank就填补了这个空白。它通常在召回之后把 Top 20~50 的候选片段交给一个更精细的模型做二轮打分选出最值得进入上下文的 Top 3~5。这套组合拳非常值得加进系统里因为它能直接过滤掉“主题相似但不可用”的片段。要是跳过这步那你的大模型就不得不忍受很多低质量上下文答案出错概率自然上升。4.2 常见误区用同一个 Embedding 模型做重排等于白做有些团队嫌麻烦会用召回阶段同一个向量模型再算一次相似度然后把分数排个序就认为完成了重排。这个做法基本无效——同一个模型学到的表征是一致的它自己摸不准的细微差别你让它再打一次分也不可能翻案。真正有效的重排模型是专门训练的 cross-encoder交叉编码器它会把“问题 候选段落”拼在一起做深度交互判断粒度远比双塔式 embedding 细得多。这类模型在小参数量下也能提供可感知的效果提升值得在系统中当成独立组件引入。4.3 轻量级但有效的重排落地思路如果你暂时没法上很重的外部模型也可以做一个“规则 小模型”的混合重排规则层过滤掉与问题实体重叠过少的候选给包含问题关键词精确匹配的片段加分给与问题类型匹配的片段加分问步骤加分给 How-to 类结构、问原因加分给带“因为/所以”的段落模型层接入一个小型的交叉编码器模型做打分排序阈值层低于设定相关度阈值的片段直接丢弃别硬塞给生成模型这一层加完之后端到端准确率通常会有明显提升尤其是“看着相关但没用”的片段被挡在上下文之外之后模型答非所问的概率会下降一大截。5. 不要忽略 LLM 本身的推理与忠实性问题5.1 上下文有答案但模型选择“相信自己的记忆”你能想象一个场景吗检索命中精准上下文里也确实有答案但模型给出的却是另一个说法。为什么因为大模型的自身参数里也存有相关知识。当上下文和它的内部知识冲突时模型不一定会选择上下文尤其当上下文表述不够明确、不够“权威感”时它可能倾向于依赖自己更“自信”的记忆。这与模型的忠实性faithfulness水平有关。解决思路不只是改 prompt还可以上下文片段中把核心答案的表述写得直白一些降低模型二次解读的负担在 prompt 中用“以下资料是唯一可信来源禁止使用预训练记忆”这类强约束更严格一点生成前增加一个可控的“按资料改写”步骤让模型先抽取要点再组织语言减少自由发挥空间5.2 多跳问题与隐性推理缺口另一种答错场景非常有意思检索到的每个片段单独看都对但问题需要融合两段信息才能解。比如用户问“项目 A 的负责人是否也在项目 B 中担任职务”第一段资料里有项目 A 的负责人名单第二段资料里有项目 B 的人员名单但两段内容没有明确说“同一人”。模型可能需要做一次跨越片段的实体消解与推理此时如果上下文太长它容易“忘了”关联直接答出一个错误结论。这类多跳问题对 RAG 来说是硬骨头。实操手段有两个一是拆解问题为子问题做多轮检索再合并答案二是把多段相关上下文以结构化小结的形式压缩成一个更精炼的证据链再让模型做最终推理。想要一次拼接就得到好结果非常依赖模型自身推理能力本质上不是单靠 RAG 就能解决的。5.3 学会“拒绝回答”比硬答更值钱在很多业务场景里资料库本来就没有答案但模型还是会“编一个合理但错误的回答”。这其实是最伤系统信誉的。我在调系统时总是建议团队把“无法回答”当成一个合法且重要的输出。给模型明确的权限和话语模式比如“如果资料中无直接信息请回答‘根据现有资料无法确认’”同时不要诱导模型强行给结论。很多错误答案并不是系统不够智能而是它太好强了。承认自己没找到答案往往比硬答更能保住系统整体的可信度。6. 系统性排查方法五分钟定位“检索对而答案错”的根因6.1 四步排查法快速定位错因如果你也遇到“检索相似但答案错误”建议别瞎猜按下面顺序做排查拆出检索结果单独看把检索返回的 Top 5 片段直接打出来人工判断其中是否真的有能直接回答问题的内容。如果没有——问题出在检索/分块层别怪大模型。丢开检索直接做人工构造测试把已知正确答案对应的原文片段手动放进 prompt 里不经过检索直接让模型回答。如果这个时候模型答对了说明生成层没问题锅在检索或重排如果答错了锅在组装或模型面对上下文的处理方式。把最终完整 prompt 打出来看确认正确答案是否真的进了上下文有没有被截断、被放在奇怪的位置、被噪声淹没。逐步消融实验只留正确答案片段、加一个干扰片段、加全部候选片段一步步观察模型回答如何变化定位到底是“噪声干扰”还是“指令不明确”。6.2 错误类型归类一次标注胜过一次猜测我建议团队内部做一版简单的错误分类标注每次人工看 bad case 都归一下类检索缺失、上下文截断、组装指令糊涂、模型推理不足、资料本身陈旧。做完一百条 bad case 之后你会看到明显的分布而不是一直停留在“模型好笨”这种模糊结论上。我见过一个客服问答场景团队天天在换 embedding 模型效果一直反复。后来我们做了 bad case 归类发现 60% 的错误其实是答案分布在多个段落而分块直接把关联信息切散了。后来把分块策略换成父子分块 增大重叠窗口端到端指标直接提升了十多个百分点。这就是归类分析的价值。6.3 建立端到端评测集别只盯检索指标很多团队会跟踪召回率RecallK和平均排名倒数MRR但这都是中间指标。真正要想让系统变好必须建一个端到端评测集每个样本包含一个用户问题、一份标准答案、一个评测标准比如用规则核对关键词或靠人工打分或用更强的模型当裁判。有了端到端评测集你才能知道“某个改动到底是帮倒忙还是真提升”。比如重排模型加了之后召回率可能变化不大但端到端准确率上涨那就是有效改动。别让中间指标绑架你的判断。7. 常见问题速查表症状、原因、对策一表清症状可能环节核心原因解决建议检索出来的内容相关但没有直接答案分块 / 文档组织答案被切散或落在不同段落使用父子分块、结构感知切分检索结果瞬间但模型答非所问上下文组装指令边界不清、噪声片段过多明确 prompt 指令、限制片段数量、加 separators正确答案在上下文中但刚好被截断上下文长度管理超窗口后静默截断打印最终 prompt 检查压缩或选用更大窗口模型相关片段排在后面Top 片段全是水货重排缺失没有 rerank 或用了同模型打分引入交叉编码器模型设置相关性阈值上下文正确但输出与上下文冲突生成模型忠实性模型过于依赖内部知识强约束“只允许基于资料回答”必要时加抽取步骤多段资料都对但合一起答错推理链路多跳推理能力不足拆分子问题、做多轮检索、上下文压缩资料里没有答案模型胡编生成模型拒答机制缺乏拒答约束显式声明“资料不足时直接说明无法确认”检索 TopK 里全是相似干扰项向量检索粒度embedding 只擅长粗筛降低直接送入模型的片段数引入 rerank 精排每块都有相关内容但不够充分分块粒度不足块太小或上下文缺失调整 chunk 大小到 512 左右增加重叠窗口表格/列表内容答得差分块处理方式强结构内容被切断按结构整体切块表格转文本旁路处理这表基本覆盖了常见的“检索对但答案错”场景。你可以拿它对着自己的 bad case 分类能省掉很多自行摸索的时间。8. 个人实操经验一个让我彻底改变认知的案例最后分享一个印象很深的项目经历。某知识问答系统当时的问题是从向量库里检索到的结果“看起来不错”但人工评估答案正确率一直只有 60% 多团队一度认为是大模型不够聪明准备换更大的底座模型。我们做了全链路的逐层排查之后发现真相是复合型的一部分答案分布在两个相邻段落里被切分切断了另一部分是因为上下文拼接时超出窗口正确答案被静默截掉还有一部分是 prompt 里没有明确“信息不足就直说”的指令模型在资料不充分时强行脑补。当时我们把分块策略改成结构感知 父子分块又把 prompt 指令重写了一遍加入“仅基于资料回答、无法确认时明说”的约束再把 Top 结果从 8 个砍到 4 个同时做了个简单重排过滤。整套组合拳下来同样的大模型没换答案正确率从 60% 出头拉到了 85% 左右。这个项目之后我再也不说“这个模型不行”这种话了——大部分时候不是模型不行是 RAG 的链路没拉通。如果你也在调 RAG我的建议是先别执着于换模型、换向量库把分块策略、上下文组装、重排、忠实性约束这四件事逐一做扎实再回头看那些“奇怪”的错误你会发现原来答案就藏在自己眼皮底下。
