要确定 RAG 系统性能不佳的问题出在检索还是生成环节，首先需要单独隔离和评估每个组件。第一步，使用如 **recall@K**（在前 K 个结果中检索到的相关文档比例）或 **precision@K**（前 K 个文档中有多少是相关的）等指标评估检索准确性。例如，如果用户询问“气候变化的原因是什么？”，而系统检索到关于天气模式而不是温室气体的文档，那么 recall@5 分数就会很低。这表明检索未能提供正确的上下文，直接影响了生成器生成准确答案的能力。使用标注数据集或手动检查可以验证检索到的文档是否与查询意图一致。如果检索持续表现不佳，可能需要改进嵌入模型、调整分块大小或优化搜索算法。
接下来，通过向生成组件提供**人工精选的相关文档**来测试其生成能力，并评估输出质量。如果即使输入了高质量文档，生成器仍然产生错误或不连贯的答案，问题很可能出在这里。例如，如果系统正确检索到一份文档，其中说明“CO2 排放是气候变化的主要驱动因素”，但生成的答案却是“甲烷是主要原因”，则表明生成器误解或产生了幻觉。这可以使用如 **BLEU 分数**（用于衡量文本相似度）或**事实准确性检查**等指标进行衡量。常见的修复方法包括在特定领域数据上微调语言模型、调整温度/提示策略或添加后处理规则来约束输出。
最后，分析检索和生成之间的交互作用。即使 recall@K 分数不错，但糟糕的排序（例如，在 K=5 的设置中将关键文档排在第 5 位）也可能导致生成器优先处理相关性较低的文本。注意力热力图或显著性分数等工具可以揭示生成器是否专注于检索内容的正确部分。例如，如果一个医疗 RAG 系统检索到了正确的药物剂量指南，但生成器忽略了关于禁忌症的关键句子，问题可能同时存在于排序和生成环节。通过迭代地改进这两个组件——例如对检索到的文档进行重新排序或在提示中添加上下文权重——可以弥补这些不足。通过系统地隔离和压力测试每个阶段，开发人员可以 pinpoint root causes 并有效地分配资源。