在落地 RAG（Retrieval-Augmented Generation）系统时，大家通常会关心两个问题：

  1. 模型说得对不对？，生成的回答是否靠谱、是否胡编乱造？
  2. 检索找得准不准？，检索到的文档是否真和问题相关？

参考 LlamaIndex 所提供的一套比较完整的评估思路，可以把 RAG 的评估拆成两大块：

  • 响应评估（Response Evaluation）：关心“回答本身”的质量；
  • 检索评估（Retrieval Evaluation）：关心“检索到的文档/上下文”的质量。

下面我们按这两个维度展开，看看 RAG 系统可以如何系统地评估。

为什么 RAG 的评估比传统模型更麻烦？

传统机器学习任务，比如分类、回归，预测结果往往是一个类别或一个数值， 大家习惯用准确率、MSE、AUC 之类的指标，定义清晰、算起来也简单。

RAG 不太一样，体现在下面几个方面：

  • 输出是自然语言，不是一个固定维度的数；
  • “正确答案”本身可能不唯一；
  • 很多时候没有现成的标注数据（ground truth）。

因此，如果只指望人工打分，既费时间又难统一标准。 为了解决这个问题，LlamaIndex 引入了一系列 基于大语言模型的评估模块， 用 LLM 来帮助我们判断一段回答“好不好”“靠不靠谱”。

一个重要特点是： 很多评估模块不强制依赖人工标签，而是结合「查询 + 上下文 + 生成回答」这三者，交给 LLM 进行对比与打分。

响应评估

围绕生成结果，LlamaIndex 提供了多个角度的评估模块，你可以按自己的需求选择组合使用。

1. 正确性（Correctness）

  • 核心问题：生成的答案是否与参考答案一致？
  • 需要标签：需要提前准备好标准答案。
  • 适用场景：FAQ、考试题、带明确标准答案的知识库问答。

在有 ground truth 的前提下，可以让 LLM 对“预测答案 vs 标准答案”做语义对比，而不是只比字符串是否完全相等。

2. 语义相似性（Semantic Similarity）

  • 核心问题：答案在语义层面是否“说的是同一件事”？
  • 需要标签：同样需要参考答案。
  • 区别于正确性：不要求逐字逐句一致，更关注“意思是否对得上”。

这种方式对表述多样性更友好，比如一个答案更口语，一个更正式，只要语义一致，就可以判为相似。

3. 忠实性（Faithfulness）

  • 核心问题：回答是不是老老实实“基于检索到的上下文”？有没有凭空瞎编（幻觉）？
  • 需要标签：不需要明确标准答案，只需要检索到的上下文。
  • 判断方式：让 LLM 对比「回答」和「上下文」，确认回答中的关键事实是否能在上下文里找到依据。

忠实性是 RAG 系统的“生命线”：检索已经给了材料，如果回答还是胡说，那说明生成过程出了问题。

4. 上下文相关性（Context Relevancy）

  • 核心问题：检索到的上下文是否真的和用户查询相关？
  • 需要标签：可以不需要标签，只用「查询 + 上下文」交给 LLM 来判断相关性。

这个指标虽叫“上下文相关性”，本质上是站在检索效果的角度看：你找来的文档到底靠不靠谱、有没有跑题。

5. 答案相关性（Answer Relevancy）

  • 核心问题：生成的答案是否围绕用户的查询在说话？有没有答非所问？
  • 需要标签：不一定需要，只看「查询 + 回答」。
  • 典型问题：模型开始讲一大堆背景，但对用户关心的点只是一笔带过。

这类评估能帮助我们发现：回答虽然“看上去挺聪明”，但对实际问题没什么帮助。

6. 指南遵循（Guideline Adherence）

  • 核心问题：回答是否遵守特定的规则或风格要求？比如：

    • 不要输出隐私信息；
    • 不要给医疗建议；
    • 必须用中文回答；
    • 必须附带引用链接等。

在需要满足合规要求或统一风格的系统中，这一指标尤其重要。

三、检索评估

响应评估解决的是“生成好不好”，但前提是你先要搜到好材料。检索模块本身也需要独立评估。

检索评估通常依赖一组 （问题，相关文档）或（问题，文档排名） 的数据集， 然后用各种排名指标来衡量检索性能。典型步骤大致分两步：

  1. 数据集生成

    • 从非结构化文本语料库出发，合成或构建（问题，上下文）对；
    • 标注哪些文档（或片段）是“相关的”。

  2. 检索评估

    • 使用你的检索器对这组问题进行搜索；
    • 计算 Hit-rate、MRR、Precision、Recall、AP、NDCG 等指标。

下面按指标简单拆一下。

1. Hit-rate（命中率）

定义：在检索结果中，是否至少出现过一个正确答案。

公式：

\[\text{Hit-rate} = \frac{\text{命中的查询数量}}{\text{总查询数量}}\]

优点：非常直观，适合快速判断“系统有没有基本找到相关文档”。

缺点：完全不管排名，只要“有就行”。

2. MRR（Mean Reciprocal Rank，平均倒数排名）

定义：关注第一个相关文档在检索结果中的位置。

公式：

\[\text{MRR} = \frac{1}{|Q|} \sum_{i=1}^{|Q|} \frac{1}{\text{rank}_i}\]

其中，$\text{rank}_i$ 是第 (i) 个查询中，第一个相关文档的排名。

优点：鼓励“把最有用的文档尽量排在前面”，特别适合用户只看前几条结果的场景。

缺点：只看“第一个”相关文档，其他相关文档分布如何不关心。

3. Precision（精确率）

定义：检索出来的文档里，有多少是相关的。

公式：

\[\text{Precision} = \frac{\text{检索出的相关文档数}}{\text{检索结果总数}}\]

优点：适合用户对“噪声”比较敏感的场景，希望看到的结果都比较干净。

缺点：不考虑那些“没被检索出来”的相关文档。

4. Recall（召回率）

定义：所有相关文档中，有多少被检索出来了。

公式：

\[\text{Recall} = \frac{\text{检索出的相关文档数}}{\text{所有相关文档数}}\]

优点：适用于不能漏的场景，比如合规审查、知识覆盖性测试。

缺点：高召回往往伴随更多噪声，精确率可能下降。

5. AP（Average Precision，平均精确率）

定义：综合考虑“相关文档在结果中的位置”和“每个位置的精确率”。

公式：

\[\text{AP} = \frac{1}{\text{相关文档总数}} \sum_{k=1}^{n} P(k) \cdot \text{rel}(k)\]

其中：

  • $P(k)$：截断到第 (k) 个结果时的精确率；
  • $\text{rel}(k)$：第 (k) 个结果是否相关的指示函数（相关=1，不相关=0）。

优点：在一定程度上同时兼顾了精确率、召回率和排序位置。

缺点：计算相对复杂一些，但对于需要精细分析检索质量的场景很有价值。

6. NDCG（Normalized Discounted Cumulative Gain）

定义：适用于“相关性有多级评分”的场景，用来衡量整个排名列表的质量。

公式结构：

\[\text{NDCG} = \frac{\text{DCG}}{\text{IDCG}}\]

其中：

\[\text{DCG} = \sum_{i=1}^{n} \frac{2^{\text{rel}_i} - 1}{\log_2(i + 1)}\]
  • $\text{rel}_i$：第 (i) 个结果的相关性评分（可以是 0、1、2、3……多级）；
  • $\text{IDCG}$：在理想情况下（完美排序）的 DCG，用来做归一化。

优点：可以表达“有的文档比另一些文档更重要”，且越靠前的高分文档贡献越大。

缺点：需要预先设计相关性等级，计算也稍微复杂一些。

四、评估工具的生态

在实际项目中，你不必从零实现全部评估逻辑，可以在 LlamaIndex 的框架之上，接入一些现成的第三方工具，例如：

  • uptrain
  • tonic_validate
  • deepeval
  • ragas
  • RAGChecker

它们各自提供了一些围绕 LLM/RAG 质量评估的能力，可以和 RAG 流程结合起来，用来做自动化回归测试、对比不同版本的检索器、监控线上质量变化等。

五、小结

如果把 RAG 看成“检索 + 生成”的流水线，那么：

  • 响应评估 关注：

    模型在“给答案”这一环节，是否正确、相关、忠实、合规？

  • 检索评估 关注：

    检索在“找资料”这一环节，是否找得到、找得准、排得好？

一个成熟的 RAG 评估体系，一般不会只盯着某一个指标，而是根据业务目标从上面这些模块中组合出一套“指标面板”，比如：

  • 用 Hit-rate / Recall 确认“有没有找到相关文档”；
  • 用 MRR / NDCG / AP 看“相关文档排得好不好”；
  • 再用 Faithfulness / Answer Relevancy / Guideline Adherence 来约束生成质量。

这样，你才能既知道“查得怎么样”，也知道“回答得怎么样”， 对整个 RAG 系统的优缺点有一个立体的认识，而不是只凭主观感觉拍脑袋。