检索已经找到答案，为什么生成结果还是答错

检索找到了正确文档，生成答案仍可能出错。排查时应先确认正确条款是否进入模型最终收到的上下文，再检查模型是否完整使用了它。仅看检索页面里出现某个文件标题，就认定问题一定出在生成模型，会遗漏中间的排序、截断和组织环节。

先把“找到了”说具体

检索可能只找到文档中的相关段落，却没有找到支持结论的那一条；也可能初始候选中有正确证据，但后续排序把它排除。应保存原始问题、候选列表、最终上下文以及实际回答，让同一问题可以复现，而不是靠用户转述“它明明搜到了”。

例如问题是“外部培训取消后费用怎样处理”。文档中有一般退费规则，也有临近开课取消的例外。只召回一般规则不足以答完整。先由内容负责人标出必须证据，才能判断检索是否真的完成了任务。

按四个环节检查

同一个错误可能跨越多个环节，但应先找最早能够证明的缺口。若最终上下文根本没有例外，要求模型“更谨慎”不能稳定补回缺失证据；若上下文已完整包含例外，则可以继续检查回答结构和指令对证据的要求。

做一个缩小范围的对照

将已核对的必要证据单独提供给相同生成设置，再问同一道题。若此时能答对，说明原流程中的证据选择或组织值得优先排查；若仍答错，则重点查看模型是否理解条件、数字和对象。这个对照用于定位，不代表人工挑选证据的效果能直接推广到线上。

对照时保持问题、生成设置和输出要求不变。不要同时重写问题、换模型又删掉难例，否则无法判断是哪一处改动起作用。保留失败与成功的上下文，能让后续修复有具体目标。

验证修复没有制造新问题

修复后重跑原题，并加入只改变一个条件的近似题。例如把取消时间从开课前一天改为提前一周，检查答案是否随条件改变。若系统只是学会固定回复原题，单题通过并不说明规则已经正确理解。

最终记录应写清错误发生在哪个环节、依据是什么、修改了什么，以及还存在哪些未验证场景。把“检索相关”“回答忠实”“结论完整”分别检查，才能让内容编辑和技术调整各自承担可核验的工作，而不是笼统地说 AI 不够聪明。

参考资料

• RAG and Generative AI - Azure AI Search | Microsoft Learn
• Retrieval-Augmented Generation (RAG) Evaluators for Generative AI - Microsoft Foundry | Microsoft Learn