RAG系统的评估方法

第一节为什么RAG评估不能使用传统的NLP指标

1、BLEU\ROUGE 就是单纯的比价内容文字重叠，不懂语义。一个答案可能有多种说法，正确的答案可能几乎没有重叠数据。BLEU一算分就是0。
2、完全无视检索上下文：BLEU只看输出答案和结果像不像，根本不考虑生成内容是不是从检索结果来的。
3、幻觉问题：传统指标无法检测RAG中的看起来有据可依，实际在胡说的问题。

第二节目前常用的主流评估指标

RAGAS:

Faithfulness （忠诚度）

输入：问题、检索文档、得到的答案
评估范围：0~1（越高越好）
流程：

1、将生成的答案进行拆分成原子声明。
2、使用LLM逐条对比检索文档中是否有对该声明支持。
3、计算得分：被支持声明 / 所有声明

例子：
假设你做了一个企业内部知识库 RAG，专门回答公司产品问题。

用户问题：我们的智能手表 X1 的防水等级是多少？可以游泳吗？
参考内容（假设只有一条）：
「根据产品说明，智能手表 X1 的防水等级是 IP68，适合日常淋浴、洗手和雨天使用，但不建议长时间浸泡，也不适合游泳或潜水。」
答案A:

「根据产品说明，智能手表 X1 的防水等级是 IP68，适合日常淋浴、洗手和雨天使用，但不建议长时间浸泡，也不适合游泳或潜水。」
拆成原子声明：
防水等级是 IP68 → 上下文明确支持
适合日常淋浴、洗手、雨天 → 支持
不建议长时间浸泡 → 支持
不适合游泳或潜水 → 支持

→ 所有声明都能从上下文直接推断出来，Faithfulness ≈ 1.0
答案B:

「智能手表 X1 的防水等级是 IP68，可以游泳，甚至支持浅潜到 5 米。很多用户反馈戴着它去海边玩都没问题，电池续航也特别强。」
拆成原子声明：
防水等级是 IP68 → 支持
可以游泳 → 上下文明确说「不建议……游泳」，直接矛盾，不支持
支持浅潜到 5 米 → 上下文完全没提深度，属于捏造
很多用户反馈戴着它去海边玩都没问题 → 上下文没有任何用户反馈内容，纯幻觉
电池续航也特别强 → 上下文只谈防水，完全没提电池

→ 只有第 1 条被支持，其余都是幻觉或矛盾信息，Faithfulness 很低。Faithfulness ≈ 1 / 5

总结: 这个指标知识评估回答的答案对于文档的忠实度，但是不一定保证答案正确，例如如果文档中地球是平的，但是答案中说地球是圆的，因此忠实度较低。如果答案也是地球是平的，即使是错误答案，忠实度也会高。
低分说明的问题：生成模型hallucination（幻觉）严重，或者prompt有问题，没有强制要求根据给定参考上下文回答问题。

Answer Relevancy（答案相关性）

含义：生成的答案是否真正回答了用户的问题（是否跑题、答非所问、信息冗余但不相关）
输入：原始问题 + 生成的答案
评估范围：0 ~ 1（越高越好）
流程：

1、首先让大模型根据答案反向生成N个问题
2、计算原始问题和生成问题之间的余弦相似度
3、得分 = N个问题和原始问题的平均相似度得分

例子：
假设你做了一个公司内部 HR 知识库 RAG，员工用来查询公司政策。

用户问题：公司今年的年假天数是多少？入职满一年之后能休息几天？
检索到的上下文：

「正式员工入职满一年后，每年享有 10 天带薪年假。入职未满一年的员工按实际工作月数折算。」

答案A：「根据公司规定，正式员工入职满一年后，每年享有 10 天带薪年假。入职未满一年的员工则按实际工作月数折算。」
LLM反向生成的问题可能是「公司年假政策是什么？」「入职满一年有几天年假？」的问题，和原问题高度相似。因此得到的Answer Relevancy ≈ 0.95~1

答案B: 「公司非常重视员工福利，我们有完善的五险一金、补充商业保险，还有每年的团建活动和节日礼品。另外公司食堂的饭菜也不错，大家反馈都挺好的。」
此时LLM反向生成的问题可能就是「公司有哪些员工福利？」「公司食堂怎么样？」「公司有没有团建活动？」等等，这些问题和用户问的问题语义相似度极低，Answer Relevancy ≈ 0.2~0.4

总结：
本身就是利用LLM给LLM生成的答案进行方向推到，来评估一个LLM生成的内容是否符合语义。

低分说明的问题：

可能是检索到的上下文把相关，也可能是生成阶段prompt设计不好，导致模型瞎回答。

Context Relevancy(上下文精确度)

含义：检索到的文档片段中，和对回答问题有用的片段有多少？以及有用的片段是否排在前面。
输入：原始问题 + 检索文档
评估范围：0 ~ 1（越高越好）

流程：

1、LLM挑选出文档中对回答有用的句子
2、得分计算公式:

$\text{Context Precision} = \frac{\sum_{k=1}^{K} (\text{Precision@k} \times v_k)}{\text{有用 chunk 的总数量}}$

案例：还是那个手表是否防水的案例
检索返回五个chunk(按照相似度排序):

排名,Chunk 内容,是否真正有用？
1,「智能手表 X1 采用 IP68 防水标准。可在淋浴、洗手、雨天使用。不建议长时间浸泡或用于游泳、潜水。」,有用（直接回答了问题）
2,「X1 手表支持心率监测、血氧检测和睡眠分析，续航可达 7 天。」,无用（完全在说其他功能）
3,「公司今年推出了三款新颜色：星空黑、月光白和极光蓝。」,无用
4,「X1 的充电接口采用磁吸设计，满电大约需要 1.5 小时。」,无用
5,「根据用户反馈，X1 在日常使用中防水表现稳定，但游泳时需谨慎。」,有用（补充了游泳相关信息）

真正有用的只有第1个和第5个chunk。具体计算得分。
假设判决结果：[1, 0, 0, 0, 1]

k=1：有用 → Precision@1 = 1/1 = 1.0
k=2：无用 → 跳过
k=3：无用 → 跳过
k=4：无用 → 跳过
k=5：有用 → Precision@5 = 2/5 = 0.4
有用 chunk 总数 = 2

因此分数=（1.0 + 0.4）/ 2 = 0.7

总结：
可见Context Precision 不只看「有没有召回有用内容」，更看重有用内容是否排在前面（排序质量 + 信噪比）。

分数低通常说明：embedding 效果一般、缺少 reranker、top-k 太大、chunk 切分不合理等。

Context Recall

含义：回答问题所需的所有关键信息，是否都已经被检索回来了（有没有漏掉重要证据）。
分数范围：0 ~ 1（越高越好）
流程：
1、准备问题和检索文档的数据集
2、把 ground truth（标准答案）拆成多个关键声明（claims），要判断「有没有漏掉」，就必须有一个参考标准（ground truth）来对比。
3、计算得分：= 被检索到的上下文支持的声明数量 / 标准答案中的声明总数

低分通常说明：检索召回不全（top-k 太小、chunk 切得太碎/太大、embedding 效果差、没有 hybrid search（混合搜索）等）。

个人疑问1：上下文搜到了五个，其实相关的就2个，这个内容有一多半都是不相关的，为什么还是满分呢？多余的检索到的内容岂不是浪费token？

解答1：
RAGAS 的 Context Precision 本质上是在计算「Average Precision（平均精度）」，它的核心目标是：
评估「有用的内容是否被排在前面」，而不是「整体噪声有多少」。然后RAGAS 的 Context Precision 故意没有把「噪声总量」作为主要惩罚点，主要原因如下：
1、它的定位是「排序质量指标」
2、实际工程中，噪声控制是靠其他手段完成的，而不是靠这个指标本身：

设置更小的 top_k（比如只取 3～5 个）
加相似度阈值过滤（低于某个分数直接丢弃）
使用 Reranker（交叉编码器）对结果重新排序并截断
监控平均 context token 数、成本等业务指标。

个人疑问2：RAGAS中的三个主要指标都是通过LLM来进行评分，那岂不是相当于LLM给自己打分？这样的评估真的有效果吗？

解答2：

确实在RAGAS中的主要指标的核心是LLM-as-Judge，表面上看起来像是模型在给自己打分。但这并不等于评估无效，关键在于我们怎么正确看待和使用它。
1、为什么有效？
* 在很多论文中，强模型作为裁判已经与人类评估的一致性达到80%，这已经接近两个不同人类评估者之间的一直水平。
* 对于RAG的Faithfulness类的任务，因为有明确的上下文作为参考，LLM做判断其实相对可靠，相关性也可以达到80%
* 相比于传统的NLP，这个LLM-as-Judge能够理解语义，已经是他最大的优势。

2、局限性
* 在有关研究中确实提到，用LLM作为裁判，这个模型更倾向于给自己风格相近的输出更高的分数。甚至同家族的。
* LLM更喜欢排在前面的答案，或者更长的答案
* 不同LLM做裁判给出的分数差异也很大。

所以在使用LLM的时候不能将他当作一个可规模化的近似人类评估。
3. 实际落地时怎么用才靠谱
* 方法论：分层评估
第一层：单独测Retriever（找对了吗）
第二层：单独测Generator（答对了吗）
第三层：端到端测试（整体评估）

第一步，单独测Retiever的时候，需要先构造数据集，一般有20~50条左右，覆盖常见问题、多文档综合体、知识库里没有答案的题等等，用来测试评估的Context Recall。
指标               测什么
Precision@K        Top-K里有多少相关的文档
Recall@K           相关文档被找到了几个
MRR                第一个相关文档排第几
NDCG               相关文档排的越靠前扽书越高

这一层评估完全不涉及LLM,纯信息检索指标

第二步测试Generator
直接跳过Retriever的过程，提供完美的文档（上一步的数据集），测试Faithness + Answer Relevance,如果根据提供的内容生成的仍然出错则说明是生成端的问题，则修改prompt等，排除检索干扰，精准定位。