RAGAS 评估框架与 Python 代码实践

一、 核心概念 (Core Concepts)

RAGAS (Retrieval Augmented Generation Assessment) 是目前业界主流的专注于自动化评估 RAG（检索增强生成）系统质量的学术与工程框架。

1. 传统评估的痛点

• 暗箱操作/主观盲测：调整检索参数（如 Milvus 的 Top-K、混合检索权重）或更换 LLM 后，缺乏量化指标，上线效果全靠研发主观拍脑袋。
• 线上同步打分代价极高：直接在用户请求链路上让大模型当裁判，会严重阻塞业务吞吐，消耗大量 Token，且单次请求耗时极长。

2. RAGAS 的核心解决思路

• 解耦裁判与运动员：将评估设计为旁路异步审计系统。通过消息队列缓存线上真实数据，在后台由分布式任务或脚本调度大模型进行离线审计。
• LLM-as-a-Judge（大模型作为裁判）：利用能力更强、输出更稳定的大模型（如 GPT-4o、GLM-4）作为评委，基于量化的学术方法论，对被测 RAG 系统的输出进行自动化打分。

二、 实现原理与评估要点 (Implementation & Key Metrics)

RAGAS 的技术壁垒不在于复杂的数学算法，而在于评估提示词（Evaluation Prompts）的工程设计与结构化解析逻辑。它将评估拆解为四个黄金量化指标，分数区间均为 $0.0\sim 1.0$。

1. Faithfulness（忠实度 / 幻觉度）

• 定义：评估大模型生成的回答（Answer）是否严格基于检索到的上下文（Contexts），用于监控系统是否在胡说八道（幻觉）。
• 实现原理：
  1. 步骤一（文本拆解）：LLM 裁判将 Answer 拆解为多个独立的原子陈述事实（Statements）。
  2. 步骤二（NLI 断言）：LLM 裁判逐条对照 Contexts，判断每条陈述是否能被客观推导出来（返回 Yes=1 或 No=0）。
  3. 计算公式：
     $$\text{Faithfulness}=\frac{\text{被上下文支持的陈述数量}}{\text{总陈述数量}}$$

2. Answer Relevancy（答案相关性）

• 定义：评估生成的回答（Answer）是否切中用户问题（Question）的题意，用于拦截答非所问、说废话的现象。
• 实现原理：
  1. 反向提问：LLM 裁判根据现有的 Answer，反向倒推并生成 3 个可能对应的虚拟问题（Generated Questions）。
  2. 向量相似度计算：调用 Embedding 模型，计算这 3 个虚拟问题与用户真实 Question 之间的**余弦相似度（Cosine Similarity）**并取平均值。

3. Context Precision（检索精准度）

• 定义：评估 RAG 检索出来的知识切片（Chunks）是否都在刀刃上，优质的、包含答案的信息是否排在检索结果的最前面（Top 排名）。
• 实现原理：LLM 裁判逐一分析检索到的每一个 Context 块，评估其与真实问题（Question）或标准答案（Ground Truth）的相关性，并引入类似信息检索中 MAP (Mean Average Precision) 的计算机制，对排序靠前且有用的信息赋予更高的权重。

4. Context Recall（检索召回率）

• 定义：评估回答正确问题所需的外部核心信息，是否都被 RAG 系统成功从向量数据库里捞了出来。
• 实现原理：需要提供人工标注的真实标准答案（Ground Truth）。LLM 裁判拆解 Ground Truth 中的每一个核心知识点，并检查这些知识点是否都能在检索出的 Contexts 中被找到。

三、 RAGAS 自动化评估 Python 示例代码 (Python Implementation)

以下代码展示了如何使用 Python 的 ragas 与 datasets 框架，结合标准的 OpenAI 格式接口（以智谱 glm-4-flash 为例），对固定样本进行四项黄金指标的自动化打分。

import os
from datasets import Dataset
from langchain_openai import ChatOpenAI, ZhipuAIEmbeddings
from ragas import evaluate, RunConfig
from ragas.llms import LangchainLLMWrapper
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)

# 1. 配置大模型与 Embedding（确保关闭 Temperature 以稳定输出 JSON 格式）
# 注意：此处以智谱 AI 为例，若使用 OpenAI，请替换对应的 base_url 和 api_key
llm = ChatOpenAI(
    model="glm-4-flash",
    temperature=0.0,  # 👈 必须设为 0.0，让大模型老老实实输出规范 JSON
    api_key="YOUR_ZHIPU_API_KEY",
    base_url="[https://open.bigmodel.cn/api/paas/v4/](https://open.bigmodel.cn/api/paas/v4/)"
)
ragas_llm = LangchainLLMWrapper(llm)

embeddings = ZhipuAIEmbeddings(
    model="embedding-3",  # 根据实际使用的模型填写
    api_key="YOUR_ZHIPU_API_KEY"
)

# 2. 准备测试数据集（包含 Question, Contexts, Answer, Ground Truth）
# 第二条样本的 answer 故意与 contexts 矛盾，用于观察 faithfulness 指标的下降
data_samples = {
    "question": [
        "人工智能的核心要素是什么？",
        "什么是向量数据库？"
    ],
    "contexts": [
        ["人工智能的三大核心要素通常被认为是：数据、算法和算力。这三者缺一不可，共同推动了深度学习的发展。"],
        ["向量数据库是一种专门用于存储、索引和查询高维向量数据的数据库系统。它在密集检索和 RAG 应用中起到了关键的连接作用。"]
    ],
    "answer": [
        "AI 的核心要素包括数据、算法以及算力。",
        "向量数据库就是一种关系型数据库，用来存普通的表格数据。"
    ],
    "ground_truth": [
        "人工智能的核心要素是数据、算法 and 算力。",
        "向量数据库是专门用来存储和快速检索高维向量数据的专用数据库。"
    ]
}

dataset = Dataset.from_dict(data_samples)

# 3. 配置运行参数（关闭 LangChain 默认的后台 Trace，防止 Windows 或特定 Python 环境下卡死）
os.environ["LANGCHAIN_TRACING_V2"] = "false"
os.environ["LANGCHAIN_HANDLER_TRACING"] = "false"

run_config = RunConfig(
    timeout=180,       # 设定单次请求超时时间
    max_workers=2,     # 设定并发 Worker 数量
    max_retries=3      # 失败重试次数
)

# 4. 执行评估
print("正在调用大模型评委进行自动化评估...")
result = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
    llm=ragas_llm,
    embeddings=embeddings,
    run_config=run_config,
    raise_exceptions=True
)

# 5. 输出评估结果
print("\n=== 整体平均得分 ===")
print(result)

print("\n=== 单条数据详细得分 (Pandas DataFrame) ===")
df = result.to_pandas()
columns_to_show = ["question", "faithfulness", "answer_relevancy", "context_precision", "context_recall"]
print(df[columns_to_show].to_string(index=False))

四、 总结与注意事项 (Summary & Precautions)

1. 核心注意事项：大模型裁判的采样温度（Temperature）必须设为 0.0

• ⚠️ 为什么 Temperature 必须设为 0？
  自动化评估系统高度依赖结构化解析。如果 temperature > 0，大模型生成文本的随机性会被放大，极易多吐出标点符号，或在 JSON 前后加上“好的，以下是分析”等口语化碎话。
• 致命后果：这会导致 Ragas 底层的强类型解析（如 Pydantic 或正则表达式）直接懵圈报错，频繁触发 Tenacity 重试机制 并陷入死循环，最终引发系统的 TimeoutError（超过 180 秒）从而导致程序直接崩溃。

2. 真实测试集样本（Dataset）的获取管道

在真实的企业级落地中，评估所需的测试集标准实践通常采用混合模式（Hybrid Pipeline），拒绝代码死写：

• 冷启动阶段：
  利用 RAGAS 的 Testset Generator 读取业务原始文档（如 PDF / Markdown），让大模型“以娃造娃”自动反向合成 50~100 条包含多跳、推理题目的基础基准测试集（Benchmark）。
• 灰度与演进阶段：
  系统上线后，后端网关开启异步流量双写投递到消息队列。业务专家登录“标注后台”，捞出用户报错、答非所问的典型 Bad Case 进行人工修正，将真实数据反哺录入标准测试集，形成持续进化的质量闭环。