第24回　RAG 评估指标——如何衡量检索与生成质量

磨刀不看火光亮，先问锋口可伤人。
检索若是凭感觉，十次上线九次坑。

上回我们把 RAG 的四步跑通：切、嵌、找、写。
可工程里最常见的争吵，不是“能不能做”，而是：

你说检索更好了，哪里更好？
你说回答更可靠，凭什么可靠？
你说模型变强了，还是只是 prompt 变花了？

所以这一回讲评估。
不讲玄虚，只讲“能算出来、能复现、能对比”的东西。

2024 有专门综述把 RAG 的评估与基准当成独立议题：
因为 RAG 是“检索+生成”的组合，坏点多，指标也得拆开看。¹

一、先把账本分两栏：检索分与生成分

把 RAG 的质量拆成两栏最清楚：

1）检索质量（Retriever）

检索问的是：
证据找得对不对、找得全不全。

常见指标：

Recall@k：前 k 条里有没有包含正确证据
MRR：正确证据排得靠不靠前
nDCG：如果有多级相关性标签，整体排序好不好

2）生成质量（Generator）

生成问的是：
回答是否准确、是否与证据一致、是否可引用。

常见指标（高二直觉版）：

Answer correctness：答案对不对
Faithfulness / Groundedness：有没有“证据里没有的话”
Citation precision/recall：引用是否指对了段落，漏不漏引用

看官注意：
检索好不等于生成好。
检索把证据送到了，生成也可能读错、拼错、甚至硬编。

所以评估必须“两栏并行”。

二、四个最常用的维度：相关性、准确性、一致性、可用性

综合起来，RAG 评估常用四维：

Context Relevance（上下文相关性）：检索到的段落是否真相关
Answer Relevance / Correctness（答案相关/正确）：答案是否解决了问题
Faithfulness（忠实度）：答案是否被检索证据支持
Utility（可用性）：答案是否清晰、完整、可执行

2024 的工作也开始强调“引用准确性”与“幻觉类型”的细分标注，用来更精细地定位错误来源。比如 RAGTruth 提供了较大规模的幻觉标注样本，便于评估“看起来像真但不被证据支持”的情况。²

三、离线评估与在线评估：一个像考试，一个像上战场

离线评估（Offline）

有标准题与标准答案：

给定问题与标准证据
看检索是否召回证据
看回答是否正确且引用到位

优点：可复现、可回归。
缺点：题库容易被“刷题”，且真实世界问题千奇百怪。

在线评估（Online）

真实用户、真实文档、真实噪声：

关注延迟、成本、满意度
关注失败率、重试率、投诉率
关注知识库漂移后的鲁棒性

优点：贴近现实。
缺点：很难把变量控制住，容易“今天好明天差”。

工程上通常两条腿走路：
离线守底线，在线看收益。

四、极简可跑代码：用 Recall@k 与 Faithfulness 做个小算账

我们造一个玩具数据集：

每个问题有一个“正确证据句子”
检索器给出 top-k 证据
生成器给出一个回答，并标注它“引用了哪条证据”

我们计算：

Recall@k：是否召回正确证据
Faithfulness（玩具版）：回答是否只使用证据里出现过的关键词

import re


QA = [
    {
        "q": "RAG 的关键是什么？",
        "gold_ctx": "RAG 的关键是外部证据与可引用回答。",
        "retrieved": ["RAG 的关键是外部证据与可引用回答。", "分块会影响检索质量。"],
        "answer": "关键是外部证据，并且回答要能引用证据。",
    },
    {
        "q": "余弦相似度表示什么？",
        "gold_ctx": "余弦相似度衡量向量夹角，夹角越小越相似。",
        "retrieved": ["工具调用需要参数校验。", "余弦相似度衡量向量夹角，夹角越小越相似。"],
        "answer": "它衡量向量夹角，夹角越小越相似。",
    },
    {
        "q": "工具调用最怕什么？",
        "gold_ctx": "工具调用最怕参数乱填与错误不回传。",
        "retrieved": ["RAG 会引入新的幻觉风险。", "分块不是越短越好。"],
        "answer": "工具调用最怕参数乱填与错误不回传。",
    },
]


def recall_at_k(item, k):
    top = item["retrieved"][:k]
    return 1 if item["gold_ctx"] in top else 0


def keywords(s):
    toks = [w for w in re.split(r"[^0-9A-Za-z\u4e00-\u9fff]+", s) if w]
    stop = {"的", "是", "与", "并且", "要", "能", "越", "更", "最", "什么"}
    return {t for t in toks if t not in stop and len(t) >= 2}


def faithfulness_toy(item):
    ctx = " ".join(item["retrieved"])
    ctx_kw = keywords(ctx)
    ans_kw = keywords(item["answer"])
    if not ans_kw:
        return 1.0
    hit = sum(1 for t in ans_kw if t in ctx_kw)
    return hit / len(ans_kw)


if __name__ == "__main__":
    for k in [1, 2]:
        r = sum(recall_at_k(x, k) for x in QA) / len(QA)
        print("Recall@%d =" % k, round(r, 3))
    f = sum(faithfulness_toy(x) for x in QA) / len(QA)
    print("Faithfulness(toy) =", round(f, 3))

你会看到第三个样本：

Answer 看起来对
但检索没召回正确证据

这在真实系统里最危险：
用户会以为“RAG 已经验证过”，其实没有证据。

所以工程里常见一个硬规矩：
证据不足就要敢于说“我不知道/需要再查”。

五、评估的陷阱：指标上升，不代表用户更爽

看官记住三个常见陷阱：

只盯检索指标：召回高了，但上下文更长更杂，生成反而更乱
只盯生成正确率：短问题变好，长问题依旧容易“半真半假”
只盯离线分数：上线后知识库变动、用户提问变了，指标就失灵

所以评估要与“失败模式”绑定：
你想减少哪类错，就要设计能抓住那类错的指标与样本。

2024 的评估综述也强调了：RAG 的评估不仅是分数，更是对“检索-生成耦合错误”的拆解与诊断。¹

六、小结：没有评估，RAG 就是“自我感觉良好”

这一回的结论很朴素：

先把评估拆成检索与生成两栏
再用指标把失败模式钉住
离线守底线，在线看收益
指标不是终点，诊断才是目的

下一回（第25回）我们升级 RAG 的第一刀：
不是先改检索器，而是先改“问题”。
让问题问得更像文档，检索自然更准。

欲知后事如何，且听下回分解。

幻觉核查

RAG 评估作为独立议题：可核对 2024 综述对指标、基准与挑战的归纳。¹
RAGTruth 的标注规模与目标：可核对其论文摘要对“response/span-level hallucination labels”的描述。²
本回的 Faithfulness(toy) 为教学用简化度量，不等同于学术/工业标准。

逻辑审计

与第23回衔接：第23回讲流程，本回讲“如何判断流程做得好不好”。
与导读一致：导读强调“事实校验”，本回把校验拆成可量化指标并指出“证据不足仍硬答”的高风险。
为后续铺路：第25–27回将通过查询变换、重排与模块化提升指标；第28回把评估延伸到延迟与成本；第29回讨论长上下文带来的新权衡。

引用与溯源

Yu, H. Evaluation of Retrieval-Augmented Generation: A Survey arXiv:2405.07437 (v2: 2024-07-03) https://arxiv.org/abs/2405.07437 ↩ ↩² ↩³
Niu, C., et al. RAGTruth: A Hallucination Corpus for Developing Trustworthy Retrieval-Augmented Language Models arXiv:2401.00396 (v2: 2024-05-17) https://arxiv.org/abs/2401.00396 ↩ ↩²

第24回 RAG 评估指标——如何衡量检索与生成质量