乐产功场丨薛利华：RAG 答错了，先别急着怪大模型

【摘要】RAG 答错时，问题不一定出在大模型。系统可能没有召回正确资料，也可能把关键证据排在后面，或在生成答案时丢失条件、弱化例外、混合口径。产品经理要先把“答错了”拆回召回、重排、生成三段链路，再判断该改哪一层。

试点会上，业务方把一张截图甩到群里：“这个答案又错了。”

截图里，员工问的是：“去外地参加培训，住宿到底按什么标准报销？”系统很快给了答案，还引用了差旅制度里的住宿标准表。技术同学看完后，第一反应是：是不是模型理解错了，要不要换一个更强的模型？业务方的反应更直接：知识库都接了，为什么还会答错？

产品经理这时不能只盯着最终答案，也不能马上把问题归到大模型身上。真正要追问的是：系统有没有找到培训管理办法里的例外说明？正确资料有没有排在模型能看见的位置？模型拿到资料后，有没有把“差旅标准”和“培训例外”揉成一个看起来顺、业务上却偏的答案？

RAG 答错，表面看是一句回答错了，背后可能卡在三段链路：召回、重排、生成。只有把错误拆回这三段，团队才知道该改资料、改检索、改排序，还是改答案组织方式。

01｜答错先看链路

很多团队看到 RAG 答错，第一反应就是看模型。模型是不是不够强，提示词是不是没写好，回答格式是不是要再调一下。这个反应很自然，因为用户看到的就是最后一句答案，最容易把问题归到“模型没答好”。

但 RAG 的回答不是模型单独完成的。用户提问后，系统要先理解问题，再去知识库里找资料，把资料筛出来、排出来，再交给模型组织成答案。最终答案错了，可能是模型表达偏了，也可能是前面根本没有拿到该看的资料。

比如用户问培训住宿报销，系统只找到了差旅制度，没有找到培训管理办法里的例外条款。这个时候，即使模型表达再自然，也只能基于不完整证据生成答案。团队如果直接怪模型，就会把真正的问题盖过去。

产品经理要先把“答错了”这句话拆开：是资料没找对，证据没排对，还是答案组织偏了？拆开以后，讨论才会从情绪化的“模型不行”，变成可推进的链路排查。

02｜先看召回：资料找没找对

第一步先看召回：系统有没有找到应该找到的资料。很多 RAG 答错，看起来像模型理解差，实际是系统一开始就没把正确资料找回来。用户问的是一个完整业务场景，系统却只召回了其中一类资料。比如“外地培训住宿怎么报销”，系统只找到了差旅标准表，却没有找到培训管理办法里的适用范围和例外说明。答案有引用，但引用只支撑了一半问题。

这类问题不能只看“有没有召回结果”。召回到一堆资料，不代表召回到了正确资料。产品经理要追问：正确资料是否已经进了知识库？这类用户问法能不能命中对应资料？系统召回的是当前有效资料，还是旧制度、弱相关说明、相似场景材料？

前面我们已经看过切片和真实问法，它们都会影响召回；这一篇只把它们放回链路归因里看：系统到底有没有找到该找的资料。如果召回层已经错了，后面的重排和生成都很难救回来。系统拿不到正确证据，模型只能在错误或缺失资料上继续组织答案。

03｜再看重排：证据排没排对

第二步看重排：资料找到了，还不够，关键证据还要排到模型真正能用的位置。很多时候，正确资料已经被找到，但被排在了后面。系统前几条召回结果里放着旧 FAQ、泛化说明、相似制度，真正能回答问题的那条有效口径排得很靠后。模型拿到的是前面的弱相关内容，答案自然会被带偏。

比如员工问“试用期员工有没有年假”。知识库里既有旧员工手册，也有新版制度，还有一份部门转发的简化说明。系统确实找到了新版制度，但前面排着旧手册和简化说明。模型生成答案时，很可能优先吸收前面的材料，最后给出一个看似折中的说法：一般不享受，但特殊情况可以申请。这样的答案听起来稳，业务上却可能错。

产品经理不用讨论算法细节，重点是推动团队把检索结果摊开：正确资料排第几？前几条材料是否都能支撑当前问题？有没有弱相关资料挤掉了关键证据？有没有旧资料、相似资料、过程材料干扰了答案？

召回解决“找没找到”，重排解决“排没排对”。如果正确证据已经出现，却没有被放到合适位置，问题就不该继续停留在“模型不好”这个层面。

04｜还看生成：答案有没有组织偏

第三步再看生成：当前面两步都基本成立时，才进入模型如何组织答案的问题。有些错误发生在生成层：资料找对了，关键证据也排到了前面，但模型在组织答案时，把适用条件说丢了，把例外条款说轻了，把不同资料里的口径揉在一起，或把资料里没有明确说的内容补成了确定判断。

还是培训住宿的例子。系统可能同时拿到了差旅制度和培训管理办法，资料本身没有问题。但模型回答时，只强调“住宿按差旅标准执行”，没有说明“公司统一组织培训时要看培训管理办法的例外规则”。这时问题从资料查找转向答案组织：证据已经在场，答案却没有把条件、例外和适用范围讲清楚。

生成层常见的偏差有三类。第一类是条件丢失，把只适用于某些场景的规则说成通用规则；第二类是例外弱化，把真正决定答案的例外条款轻轻带过；第三类是口径混合，把两段资料里的不同边界揉成一个含混结论。它们都可能让答案看起来完整，实际已经偏离业务口径。

产品经理在生成层重点看最终答案是否贴着证据。可以追问三件事：答案有没有新增资料里没有的判断？有没有把多个条件混成一个结论？有没有把适用范围、例外情况、版本边界说丢？

走到这一层，团队才有理由讨论模型表达、答案组织和回答约束。如果前面召回和重排都没查清，就直接调生成，容易把链路问题伪装成表达问题。

05｜推动团队链路归因

产品经理真正要推动的，是让团队形成一套更清楚的归因顺序。看到 RAG 答错，可以先把会议里的讨论从“模型行不行”拉回三组问题：第一，系统找到了哪些资料，有没有漏掉真正相关的资料；第二，正确资料排在什么位置，前面有没有弱相关或旧资料干扰；第三，模型基于哪些资料组织答案，偏差到底发生在哪一句、哪一个条件、哪一个适用范围上。

这个顺序能帮团队少走很多弯路。召回没找对，就先回到资料范围、切片、索引和问法匹配；重排没排对，就看证据排序和干扰材料；生成组织偏了，再讨论答案约束、表达边界和模型组织能力。

这里有一个很重要的取舍：继续换模型、调模型，还是先把答错拆回链路证据。前者看起来动作更快，后者更容易找到真正问题。产品经理的价值落在这里：把“答错了”变成团队能排查、能定位、能推进的具体问题。

链路归因能帮团队先判断问题大概卡在哪，但答案里有引用、有来源，也还不等于真正可信。下一篇，我们继续看：RAG 有引用，不代表答案就可靠。

#RAG #RAG设计 #AI产品经理 #产品经理 #知识库 #召回 #重排 #生成 #链路归因 #企业AI