最近好几个正在做 RAG 落地的朋友来找我聊的都是同一个让人头大的问题检索结果明明看着很相似向量相似度分数也不低大模型最终给出的答案却还是错的有时错得离谱甚至跟正确方向完全相反。这种“相似但错误”的现象几乎是每个做检索增强生成应用的人都会撞见的坎。这篇文章把常见的原因和排查路径完整梳理一遍希望能帮你少走几个月的弯路。内容适合正在做 RAG 应用、调试问答助手或者准备进一步优化生成效果的开发者。1. 先别急着换模型把 RAG 链路拆开看1.1 四个环节各自扮演什么角色很多人一遇到答案不对第一反应是“底层模型太弱”马上想换个更大的模型。这个思路不能说全错但很可惜RAG 的错误很少是单点问题导致的。一个完整的 RAG 流程至少包含四个环节检索召回、召回结果重排、上下文组装、生成推理。每个环节都有自己独立的逻辑也都可能埋下错误。检索召回负责从小到大候选库里找“相关内容”。它判断的是相似度不是正确答案。重排环节负责调整顺序把自认为更相关的片段排到前面。上下文组装负责把选出来的片段变成大模型能读懂的文本这中间牵扯到截断、去重、排序、格式拼接。生成推理则是大模型基于上下文输出答案。问题在于前一个环节的错误会顺着链路往下传而且会被后一个环节放大。检索排序稍微偏一点把不重要片段排到前面组装时又把它放在了显眼位置大模型很可能就会朝着这个“高频噪声”去组织答案。1.2 链路越长问题越隐蔽我见过一个典型的客服问答系统用户问“某设备保修期多久”检索返回的第 1 条是“该设备不提供保修服务”第 2 条是“保修期内充电器损坏可免费更换”。第 2 条跟问题表面更相似向量分数更高系统就把第 1 条排到了后面。模型读完上下文后回答“充电器损坏可以免费更换”用户追问“整机呢”系统哑火。表面看是模型答错了实际上检索排序、上下文组装、生成输出三个环节都有问题。真正的答案“不提供保修服务”虽然被召回但没有被模型充分使用。这就是 RAG 项目排查起来最麻烦的地方你很难一眼看出是哪个环节掉了链子。我的建议是先不要把“答案错误”当成一个孤立现象而是当成一条流水线上的偏差逐段排查。2. 检索端的陷阱相似内容为什么救不了答案2.1 语义相似不等于事实一致“相似”这个词本身就是问题所在。基于向量的检索系统衡量的是“语义距离”它算出来的是两个句子在向量空间里离得有多近并不是两个句子在事实层面上是否一致。向量模型擅长捕捉共现关系、主题倾向、词面信息。它知道“保修”和“设备”“维修”“客服”这些词经常一起出现所以“设备不提供保修服务”和“设备保修期多久”这两个句子会被认为是高度相似的。但在人类看来这两句话一个是拒绝一个是询问事实方向恰恰相反。我做过一个测试把一组意思完全对立的句子放进同一个 embedding 模型里算相似度结果“这个套餐包含 100 分钟通话”和“这个套餐不包含 100 分钟通话”之间的向量距离竟然非常小。原因是两个句子除“不”字外全部相同向量模型把这个差异压得很低。放到 RAG 场景里就是一个致命缺陷检索系统把“该型号不提供保修”当作正确答案召回模型在生成时如果依赖这种表面相似性就会把否定信息漏掉。这个问题的排查方式很朴素把问题直接丢给检索系统看返回的片段是否真的“足够支撑答案”。如果你发现返回片段里存在否定、数值、时间、条件这些对结果极其关键的语义元素不要指望 embedding 能帮你正确排序。这类场景需要额外做规则兜底或者在分块时保留更多上下文让模型有足够信息区分“是”和“不是”。2.2 分块方式直接影响答案质量分块是大多数人忽略的隐形杀手。很多快速 Demo 直接用固定长度切分比如每 500 个 token 切一块遇到句子边界直接截断。这样切出来的片段检索时很有可能命中一个“含有正确答案但没有上下文”的碎片。举个例子某用户手册里写“保修期为一年。充电器、电池属于易损件保修期为三个月”。如果切成“保修期为一年。充电器、电池属于易损件”和“保修期为三个月”两块用户问“充电器保修期多久”检索更容易命中第二块“保修期为三个月”却拿不到第一块里“充电器、电池属于易损件”这个限定条件。模型可能把整机一年的保修期答成三个月。分块策略不是越细越好也不是越大越好。块太小语义上下文被切断块太大正确答案被淹没在大量无关内容里。一般建议先按文档自身结构切分比如标题、段落、表格行尽量保证一个语义完整的事件落在一个块内。如果原始文档结构不清晰再考虑用固定长度加重叠窗口的方式重叠部分可以一定程度上弥补截断损失。我常用的一个经验值是把块大小限制在模型最大输入长度的 20% 到 30% 左右。假设一个模型最多支持 4096 token那分块可以往 800 到 1200 token 的方向去尝试。这样既不会让碎片太碎也不会让检索噪声太大。但这个值必须结合业务问题验证不要照搬。2.3 topK 不是越大越好topK 同样是个需要反复测试的参数。K 值太小正确片段可能没被召回K 值太大无关片段会被一起塞进上下文干扰模型判断。我更倾向于把它理解成“证据充足度”和“噪声容忍度”之间的取舍。我在自己的测试集上做过一组对比数据大概是这样topK正确片段被召回率最终答案准确率现象370%52%有些正确片段压根没进上下文588%73%准确率明显上升1086%61%噪声增多模型开始被干扰这里不需要纠结具体数值关键是观察“增加 K 值之后准确率反而下降”的现象。这通常意味着噪声对生成的影响已经超过了新增信息带来的收益。那种“多给点材料模型就能答对”的想法在长上下文模型里往往不成立。模型处理多文档时很容易把注意力分配给位置更靠前、格式更显眼的片段而不是真正承载答案的片段。3. 组装上下文同样内容不同的放法结果天差地别3.1 上下文窗口越大模型越容易在中间迷失很多人把上下文窗口当成货物仓库觉得塞得越多模型可用的信息就越多。这个理解在 RAG 场景里会让你吃大亏。大模型在回答时不会均匀地看每个 token注意力机制天然会更关注开头和结尾的内容对中间部分的利用率很低。也就是说哪怕你把正确答案排到了 context 的中间位置它也极有可能被模型忽略掉。最怕看到的一种上下文结构是先放一段系统提示词中间塞 8 个毫不相关的检索片段最后才放用户问题。这样一来真正有用的信息被埋在中间地带模型要找答案就像在一堆杂物堆里捞针捞不到才是正常的。我的建议是在组装阶段就把“用户问题”和“关键证据”放在最显眼的位置。你可以先放系统指令再放用户问题然后紧跟着放检索内容其中按相关性从高到低排列。这样模型在开头部分就能建立“问题在哪”的概念后面读到相关内容时更容易对应上。3.2 给检索内容一种明确的“证据身份”很多时候模型把资料当作背景信息一掠而过是因为它分不清哪些是资料原文、哪些是用户问题、哪些是它自己的记忆。解决方式很直接用清晰的格式把证据标注出来告诉模型“这些是事实依据”。我在实践中非常推荐这种模板请严格依据以下资料回答用户问题。 如果资料中没有充分依据请直接回答“资料不足”不要自行编造。 资料 {将检索片段逐条编号每条单独一行} 用户问题{问题} 回答前请先用不超过50字概括你依据的是哪一条资料再给出最终答案。“依据哪一条资料”这个要求非常重要。它不是为了给用户看而是逼着模型在生成之前先做一步“证据定位”。我实测下来加上这行之后模型编造答案的比例明显下降。理由很简单模型在生成时如果被要求“先引用来源”它需要在内部做一个检索行为相当于给它加了约束。3.3 重复信息与矛盾信息的处理多路召回的情况下同一个答案可能出现在多个片段里而且可能出现矛盾版本。比如 A 片段写“保修期一年”B 片段写“保修期三年”。如果两段都塞进上下文模型经常会在两个矛盾证据之间摇摆然后选一个更迎合问题倾向的。这种情况需要在组装前做一步轻量去重和冲突检测。最简单的方案是如果两个片段相似度极高只保留更完整的那一个如果两个片段同时出现但关键属性存在冲突要么通过规则把包含更多限制条件的片段排前要么在提示词里明确要求“当资料之间矛盾时以更具体、更晚更新的资料为准”。这个动作看起来很普通却是很多线上 RAG 系统从一开始就漏掉的一环。4. 生成阶段的深水区为什么模型拿到了证据还是答错4.1 模型自带的知识库与检索证据打架大模型本身是一个庞大的参数化知识库。即使你不给它任何外部资料它也能说出不少关于某个设备的常识。问题恰恰出在这里当外部资料与模型内部记忆不一致时模型不一定选择外部资料。比如某个内部系统的版本已经升级到 V3但模型训练时停留在 V2。你检索到的资料写“新增了自动退款功能”模型却根据旧记忆回答“不支持自动退款”。这种错误很难通过调整检索解决因为检索已经成功把正确资料送进上下文了模型就是不听。针对这种情况我会在系统提示里增加一句“你的内部知识仅用于辅助理解回答一律以当前提供的资料为准”。这句话不能保证百分之百生效但确实能显著提升中间层模型对检索证据的依从度。如果模型能力太弱连这种指令都遵循不了那问题就回到了模型选型上不是 RAG 的锅。4.2 输出格式错误导致的“假答案错误”有一种答案错误非常冤模型推理是对的但输出形式不符合要求被规则或人工判成错。比如要求“只回复 A/B/C/D”模型却回复“我认为是 A因为根据资料...” 。再比如要求输出 JSON模型输出中多了几行提示文字。这类问题跟检索是否相似无关纯粹是指令遵循和格式约束问题。解决方式有两个方向。一是给 few-shot 示例让模型照着示例格式输出二是引入一个轻量输出校验器在模型输出后做结构检查不合格则做一次格式修正。第二种方式在真实业务里更稳因为大模型的输出风格很难用几条规则彻底约束。4.3 多证据之间需要显式推理步骤当问题需要综合多个资料时模型出现错误的风险会显著上升。比如“根据资料说明该设备的保修政策与上一代产品有何不同”模型需要先提取两代产品各自的政策再逐项比较。如果只给一段长资料让它直接输出它很容易在中间环节丢失信息最后给出一个看似合理但细节对不上的结论。更稳妥的做法是让模型分步处理。在提示词里明确要求“先提取每一代产品的保修描述再逐项对比最后总结差异”。这个过程把隐式的推理负担显式化了模型不需要自己判断“该怎么综合”只需要按步骤执行。虽然不是完美的推理框架但实测下来能有效降低综合错误的概率。5. 一套可复用的排查流程从现象定位到根因5.1 构建一份“最小评估集”排查 RAG 问题不能靠感觉需要有一组固定的测试样本。你先准备 30 到 50 条有代表性的问题每条问题配上标准答案、答案来源文档、可能混淆的相似片段。这组测试集就是你排查和回归的基准。重点是要加入“相似但不合理”的负例。比如用户问“是否支持快充”知识库里有一个片段讲“不支持快充”另一个片段讲“支持 65W 快充”。这种能制造认知冲突的样本比单纯的正例更能暴露系统问题。有了评估集之后每次修改分块、topK、提示词都跑一遍错误率变化曲线很快会告诉你哪里有效、哪里无效。5.2 分环节定位像调试代码一样调试 RAG定位 RAG 问题的时候我喜欢用“单变量法”。第一先绕过生成阶段直接把测试问题发给检索接口检查前几个召回片段里有没有包含正确信息。如果没有问题出在检索或分块环节。如果有继续下一步。第二固定检索结果不变换不同的提示词模板和上下文组装方式。这一步能判断问题是不是出在模型没读懂资料或者没按指令执行。第三固定提示词不变调整 topK 和重排逻辑观察生成结果变化。如果答案波动明显说明组装和检索排序在互相拉扯。这三个步骤不需要做得很复杂但会帮你在五分钟之内缩小排查范围。很多人卡在“答案不对但不知道怪谁”的泥潭里其实就是因为跳过了这个分层定位的过程。5.3 一个实际案例的处理过程我记录过一个智能硬件客服知识问答的案例现象是用户问“更换电池服务收费标准”系统经常答成“电池保修期内免费更换”。表面上看是生成错误但深入排查后发现三层问题叠加。首先原始材料里关于电池的保修和收费信息在一个表格里表格被固定长度分块切成两半检索召回时只能命中“免费更换”那一半丢掉了“保修期外收费标准”那一半。其次prompt 没有要求模型区分保修期内外模型默认把“免费更换”推广到了所有场景。第三topK 只设为 3正确的收费标准排在第四位压根没进入上下文。处理方式是把表格按行分块并保留表头信息topK 调到 5提示词里增加一个条件判断“用户是否明确处于保修期外若资料无法区分请追问”。调整后在测试集上错误率从 25% 左右降到了 3%。这个案例最有价值的地方在于没有换模型没有换向量库仅仅是修了分块、组装和指令三个环节。6. 从根上减少这类错误的设计习惯6.1 把检索结果当成证据链而不是资料堆我建议你从一开始就养成“证据链”思维。每次召回结果不应该只是给模型一堆文本而是对应到结论的佐证哪一句回答了问题哪一句提供了限制条件哪一句是干扰项。在选型时优先考虑那些能输出引用来源、能提供原文片段的检索组件。后续如果要做答案溯源这个基础会让你省非常多力气。6.2 面向答案设计分块和索引先别急着调 embedding 模型先想想你的知识库里 80% 的问题长什么样。如果多数问题都围绕产品参数那分块最好按参数表或条目来切如果多数问题是流程性操作分块最好围绕“步骤”来切。面向答案设计分块、面向查询设计索引听起来像是正确的废话但很多项目是从“把文本按固定长度切一切”开始的后来返工成本惨痛。6.3 给生成环节加一道校验闸门最稳妥的做法不是把希望全押在生成模型上而是在生成之后加一道校验。可以用一个轻量模型做忠实性检查让大模型逐句判断“答案里的关键数字、时间、限定条件是否能在资料中找到原文依据”。发现不一致就打回重新生成或者标记为低置信度结果。这个校验器不用多聪明哪怕只是规则匹配关键词也存在价值。它能兜住相当一部分“模型自信满分但答案找不到来源”的错误。线上系统里这种不确定性提示通常比硬答一个错误结果要安全得多。说真的踩过几次坑之后我最大的感受是RAG 的问题往往不在某一个环节而在链路之间的衔接。检索正确只是必要条件不是充分条件。与其到处找新模型不如先把分块、组装、指令这三样基本功打磨好。我的经验是六成以上的“相似但错误”问题通过调整分块和提示词就能解决根本不需要换底层模型。最后再分享一个小技巧把错误答案的“错法”分类记录下来比如“否定关系没识别”“条件限制被忽略”“证据被中间位置淹没”你会很快找到自己系统里最值得修的地方。