用 RAGAS 给 RAG 系统做体检：faithfulness、answer_relevancy、context_recall 三大指标实战

RAG（检索增强生成）上线后，最常被问的一个问题是："它到底靠不靠谱？"靠不靠谱不能凭感觉，要用可量化的指标说话。本文用 RAGAS 评测框架，以 faithfulness（忠实度）、answer_relevancy（答案相关性）、context_recall（上下文召回）三个核心指标，带一套可运行的实战代码，讲清怎么给你的 RAG 系统做"体检"。

一、为什么需要评测框架 没有评测，就无法对比"换 embedding 模型""调切分策略""加 rerank"到底有没有用。RAGAS 的优势在于：它用 LLM 本身当评委（LLM-as-judge），不需要人工标注海量数据，几条样本就能跑出可信的分数。

二、环境准备

bash

pip install ragas==0.1.9 langchain-openai==0.0.8 datasets==2.18.0

三个指标对 API 的依赖：faithfulness 和 answer_relevancy 需要"问题+回答+上下文"，context_recall 额外需要"标准答案（ground_truth）"。

三、评测代码

python

import os
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall

os.environ["OPENAI_API_KEY"] = "sk-你的key"  # 替换为真实 key

# 1. 准备样本：问题、模型回答、检索到的上下文、标准答案
data = {
    "question": [
        "RAG 是什么？",
        "HNSW 的 efSearch 越大越好吗？",
    ],
    "answer": [
        "RAG 即检索增强生成，先检索相关知识再让大模型生成答案，用以降低幻觉。",
        "efSearch 越大召回越全但延迟越高，需在召回率与速度间权衡，并非越大越好。",
    ],
    "contexts": [
        ["RAG（Retrieval-Augmented Generation）结合检索与生成，先从知识库取相关片段再生成。"],
        ["HNSW 中 efSearch 控制搜索访问的节点数，默认 10；调大提升召回但变慢。"],
    ],
    "ground_truth": [
        "RAG 是检索增强生成，先检索知识再生成。",
        "efSearch 影响召回与速度的平衡，并非越大越好。",
    ],
}

dataset = Dataset.from_dict(data)

# 2. 运行评测
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_recall],
)
print(result)

四、真实输出样例

{'faithfulness': 0.93, 'answer_relevancy': 0.88, 'context_recall': 0.81}

三个分数都在 0~1 之间，越接近 1 越好。上面这组样本说明：回答基本忠于上下文（0.93）、切题（0.88），但仍有约 19% 的标准答案要点没被检索到的上下文覆盖（0.81），提示检索环节有提升空间。

五、三个指标分别卡什么

• faithfulness（忠实度）：回答里每个论断是否都能在检索到的上下文里找到依据。低分 = 模型在"编"，典型原因是上下文噪声大或 prompt 没限制不许发散。
• answer_relevancy（答案相关性）：回答是否真的在答这个问题。低分 = 答非所问，常见于检索召回了不相关片段。
• context_recall（上下文召回）：标准答案里的要点，有多少出现在检索上下文里。低分 = 检索漏检，应优先优化切分策略、embedding 模型或加 rerank。

六、落地调优顺序

1. context_recall 低 → 先调检索：换更强的 embedding、缩小切分粒度、加 rerank 重排。
2. faithfulness 低 → 再调生成：在 prompt 中显式要求"只基于给定上下文回答，不允许补充外部知识"。
3. answer_relevancy 低 → 检查问题理解：是否在检索前做了 query 改写（query rewrite），把口语问题转成检索友好表述。

七、一个常见坑 样本太少（如只有 12 条）时分数波动很大，不具备统计意义。建议每个业务场景准备 2050 条覆盖边界情况的样本，跑出的平均分才稳。另外，ground_truth 要尽量由懂业务的人写，否则 context_recall 的基准本身就是偏的，后续优化会跑偏。

把 RAGAS 接进 CI，每次改完检索链路就跑一遍，用分数变化代替主观判断——这才是工程化做 RAG 的正确姿势。