RAG 应用怎样用检索评估区分召回和生成问题

RAG 应用出现“回答不对”时，先别急着换模型。更稳妥的做法是把一次回答拆成检索和生成两段：先看资料有没有被找回来，再看模型有没有根据这些资料回答。这样才能判断问题应该回到切分、召回、重排，还是回到提示词、上下文组织和生成模型。

本文采用一组固定评估样本来说明这个拆分方法。官方资料中，RAG 评估同时覆盖文档检索与答案生成；常见指标包括 context_recall、context_precision、faithfulness 和 answer_correctness。

官方资料地址：https://docs.nvidia.com/nemo/microservices/26.3.1/evaluator/metrics/rag.html

先把一次回答拆成可评估样本

最小样本不要只保存“问题”和“最终回答”，至少保留四类字段：用户问题 user_input、检索出的片段列表 retrieved_contexts、模型回答 response，以及人工整理或可信数据集提供的参考答案 reference。前两类主要用于看检索，后两类主要用于看生成。

可以把样本整理成 JSONL。下面的结构只是评估数据的组织示例，不代表已经在本机执行：

{
  "user_input": "企业报销单需要保留多久？",
  "retrieved_contexts": [
    "财务制度：报销凭证按档案制度归档。",
    "差旅制度：出差申请需要部门负责人审批。"
  ],
  "reference": "应依据适用的档案制度确认保存期限。",
  "response": "报销单需要永久保存，并且所有出差都必须审批。"
}

这个例子故意保留了两种容易混淆的片段：第一段与保存期限相关，第二段只说明审批。评估时不要把“检索到了片段”直接等同于“检索正确”，还要看它是否覆盖答案所需要的事实。

用检索指标判断有没有找对资料

context_recall 关注参考答案中的关键信息是否能在检索上下文中找到。它低时，常见原因是查询改写不准确、切片丢失上下文、向量召回范围过窄，或者重排把真正相关的片段挤出了 top-k。

context_precision 关注取回的片段里有多少是相关的。它低而 context_recall 尚可，通常说明资料虽然找到了，但噪声太多：相邻章节、相同关键词但不同业务对象的内容，都会挤占上下文窗口。

如果评估工具提供 context_relevance，它更适合回答“这些上下文对当前问题是否相关”。而在传统检索数据集里，还可以使用 recall@k、ndcg@k 等指标直接评价排名质量。关键是固定同一个 k，否则不同实验之间没有可比性。

def classify_retrieval(recall, precision):
    # 这里只做排障分桶，阈值应由团队的历史回归集决定。
    if recall 

不要把上面的 0.6 当成通用标准。它只是示例阈值，真实项目应按业务风险、样本难度和历史版本分布设定。

用生成指标判断回答是否站得住

当检索指标已经正常，回答仍然错误，就要看生成侧。faithfulness 或 response_groundedness 主要检查回答中的事实能不能被检索上下文支持。如果上下文没有“永久保存”的依据，回答却直接下了这个结论，忠实度就会暴露问题。

answer_correctness 需要参考答案，关注回答是否达成了正确结论；answer_relevancy 更关心是否直接回应用户问题，是否出现绕题、遗漏或不必要的重复。这几个指标不能互相替代：回答可能很贴题，却没有依据；也可能完全依据上下文，却没有回答用户真正问的范围。

sample = {
    "question": "企业报销单需要保留多久？",
    "contexts": ["报销凭证按档案制度归档。"],
    "answer": "应依据适用的档案制度确认保存期限。",
    "ground_truth": "应依据适用的档案制度确认保存期限。"
}

# 评估器需要的字段名应以具体平台或 SDK 文档为准。
required = ["question", "contexts", "answer", "ground_truth"]
missing = [key for key in required if not sample.get(key)]
if missing:
    raise ValueError("评估样本缺少字段：" + ", ".join(missing))

这里的字段检查只是为了说明输入边界。不同评估服务可能使用 user_input、retrieved_contexts、response 和 reference 等名称，接入前要按目标服务的数据格式映射。

用故障矩阵定位优化方向

实际排查时，可以把检索质量和回答质量放在一起看：

这里最容易踩的坑是只看最终答案准确率。最终指标下降，可能是召回没覆盖，也可能是上下文中混入了相似但冲突的内容；如果不保留中间字段，优化就只能靠猜。

把评估接入固定回归集

建议先做一套小而稳定的回归集，而不是一开始追求很大的题库。每条样本固定问题、参考答案和必要的相关片段；每次改切片、embedding、重排、提示词或模型，都用同一批样本比较。

1. 先固定样本字段和参考答案口径，明确哪些结论必须命中。
2. 固定检索的 top-k，分别记录 recall、precision 或 nDCG。
3. 固定生成参数和评估模型，记录 faithfulness、relevancy、correctness。
4. 保存每条样本的分数与上下文，不只保存均值；均值会掩盖少数高风险问题。
5. 把一次变更对应到一个优化假设，例如“减少噪声”或“补齐召回”，避免同时改太多变量。

常见问题

召回率高，为什么答案还是错？

召回率只说明参考信息进入了候选上下文，不代表上下文排序足够好，也不代表模型会忠实使用它。继续看 precision、faithfulness 和回答中的具体断言。

没有人工参考答案还能评估吗？

可以先评估检索排名和上下文相关性，但没有 reference 时，answer_correctness 与 context_recall 的解释范围会变窄。高风险场景仍应补充人工标注或可信答案。

应该先优化检索还是先换模型？

先看分数模式：recall 或 precision 明显低时先处理检索；检索稳定但 faithfulness 低时再处理上下文组织、提示词和生成模型。这样每次改动都有可解释的目标。

RAG 评估的重点不是找一个“总分”，而是让每个分数都能回答一个具体问题：资料找全了吗、资料相关吗、回答有依据吗、回答真的正确吗。