RAG项目上线后效果还行，但用户总说“答非所问”，怎么排查？

先看召回后有没有做rerank，很可能相关文档被无关的挤后面了，调下prompt让它优先用高分片段试试。

先看prompt里有没有明确要求“只根据召回内容回答”，模型可能压根没把检索结果当回事。

先看下prompt是不是没把召回内容喂进去，再查chunk切得碎不碎，我之前就是切太碎导致答非所问。

先别急着换模型，把chunk调小点试试，很多时候是召回太杂把生成带偏了。

这种“召回有但生成不用”的情况太典型了，十有八九是chunk切得太碎或者prompt没把上下文约束住。我之前也踩过，Top-5里文档都对，但模型就是爱自己发挥，后来加了rerank把最相关的两条顶上去，再在prompt里明确说“只根据下面内容回答”，立马好很多。建议你先打印一下实际喂给LLM的完整prompt，看它到底看到了啥，比盲调参数快多了。

我遇到过几乎一样的情况，最后发现是prompt里没把召回文档的边界说清楚，模型把几篇文档混在一起瞎编。你可以先把Top-5的文档单独喂给模型，看它到底用没用，如果还是跑偏，那基本就是prompt的问题。另外chunk太大也容易让无关内容稀释掉关键信息，先试试调小到300-500再配合rerank，一般能救回来不少。

这个“检索到了但生成没用上”的情况太常见了，很多时候真不是召回的问题。你Top-5里有相关文档却输出请假流程，我第一反应是chunk切得可能把报销和请假的内容混在同一个块里了，生成模型看到上下文里两个主题都有，就容易抓错重点。可以先把召回的chunk原文打出来看看，是不是那块文本本身就模棱两可。另外prompt里最好明确要求“只根据以下资料回答，资料没提到就说不知道”，不然模型很容易自由发挥。还有个容易被忽略的点是，LangChain默认的stuff策略会把所有召回文档一股脑塞进去，文档一多模型注意力就散了，试试限制到Top-2或者加个rerank先过滤一遍。我上次类似问题最后是靠调chunk overlap加rerank解决的，embedding模型本身反而没换。你可以先做个消融实验，固定其他变量单独调chunk大小，看召回内容的纯净度有没有变化。

你这个情况太典型了，我们团队上个月刚踩过一模一样的坑。Top-5里明明有正确文档，生成却答偏了，大概率不是召回的问题，而是中间那层没衔接好。建议你先别急着换rerank，先把召回的原文和最终prompt里的context都打出来对比一下，很多时候是chunk切得太碎导致语义断裂，模型拿到半截话自然理解偏。另外你那个“怎么报销”返回“请假流程”的例子，我怀疑是embedding对这类流程性短query区分度不够，可以考虑给query加点业务关键词扩展。还有个容易被忽略的点是prompt里对context的使用指令太弱，模型倾向于用自己的先验知识瞎编，试试在system prompt里明确要求“只依据以下文档回答，文档没提到就说不知道”。如果这些调完还不行，再上rerank也不迟，bge-reranker-base性价比挺高的。最后建议你搞个小评测集，把bad case固定下来，不然改来改去全靠感觉。

先别急着换模型，把召回的那几篇文档和最终prompt拼出来看一眼，大概率是context塞太多把关键信息淹了。

“答非所问但召回里有正确文档”这个现象太典型了，我上个月刚踩过一模一样的坑。你描述的情况大概率不是embedding或者chunk的锅，因为Top-5已经命中了，说明检索阶段基本及格。真正的问题往往出在生成阶段——LLM拿到5个chunk之后，可能被其中某个语义相近但主题不同的片段带偏了，尤其是“报销”和“请假”在向量空间里距离可能很近，都是HR流程类。建议先把prompt里的上下文顺序和标注方式改一下，给每个chunk加上来源标题或类别标签，让模型能区分哪段是讲报销的。另外你可以在prompt里明确要求模型先判断“哪段文档与问题最相关”，再基于那段回答，这个coT式的引导对开源模型效果挺明显的。如果还不行，再考虑上rerank，但别一上来就换模型，先把现有链路的信息利用充分。还有个容易被忽略的点：你的chunk里是不是把报销和请假写在同一段里了？如果文档本身没按主题切干净，检索出来就是混的。

先看prompt里有没有把召回文档塞进去但模型忽略了，加个rerank再试试，chunk大小影响没那么大。

先看prompt里有没有明确要求只依据召回内容回答，很多时候是模型自己加戏了。