RAG（检索增强生成）系统上线前，最难回答的问题是：它到底答得准不准？靠人工抽检几条问答既不可持续、也不可回归。RAGAS 是一套开源的 RAG 评估 框架，用 faithfulness（忠实度）、answer_relevancy（答案相关性）、context_precision（上下文精度）与 context_recall（上下文召回）四个核心指标，把”检索增强生成质量”量化成可比较、可回归的分数，让每次知识库、分块策略或提示词的改动都有数据支撑。本文手把手跑通一次端到端 RAGAS 评估。
一、为什么 RAG 必须被量化评估
传统单元测试只能验证”代码有没有报错”，却验证不了”模型有没有胡说”。RAG 链路里至少有两段不确定性：检索器召回的上下文是否切题，生成器是否真的基于上下文作答还是凭空编造。这两段一旦失守，用户看到的就是一本正经的幻觉。靠人眼抽查 20 条问答，永远覆盖不到长尾；而把评估做成可自动运行的脚本，每次发版前跑一遍，就能把质量红线变成工程约束。这正是 RAGAS 存在的价值——它把”答得好不好”翻译成四个可计算的指标。
二、RAGAS 四大核心指标拆解
RAGAS 的指标设计恰好对应 RAG 链路的两个环节：检索质量（context_*）与生成质量（faithfulness / answer_relevancy）。理解每个指标在”考什么”，才能看懂评估报告。
| 指标 | 考察环节 | 越高代表 | 是否需要标准答案 |
|---|---|---|---|
| faithfulness 忠实度 | 生成 | 答案全部能从上下文推出、无编造 | 否（仅需上下文） |
| answer_relevancy 答案相关性 | 生成 | 答案切题、没有答非所问 | 否 |
| context_precision 上下文精度 | 检索 | 靠前的相关片段确实有用 | 是（需 reference） |
| context_recall 上下文召回 | 检索 | 标准答案需要的证据都被召回 | 是（需 reference） |
2.1 Faithfulness 忠实度：模型有没有编故事
忠实度衡量答案中的每一条 claim 是否都能在给定上下文里找到依据。它是 RAG 最该盯紧的指标——一旦分数掉下来，说明生成器在”自由发挥”。实现上 RAGAS 会用 LLM 把答案拆成若干陈述句，再逐句回查上下文，统计可被支撑的比例。
2.2 Answer Relevancy 答案相关性：答非所问没
相关性考察答案是否真正回应了问题。即使完全忠实于上下文，如果模型绕开问题本身，相关性也会很低。该指标用”用答案反推问题、再比对原问题相似度”的思路打分，无需人工标准答案，适合大规模自动化。
2.3 Context Precision / Recall：检索器到底行不行
这两个指标需要一份”标准答案参考”（reference），用来判断检索器召回的片段是否包含回答问题所需的证据、以及有用片段是否排在前面。它们直接反映你的向量库、分块大小和 top-k 设置是否合理，是优化检索阶段的第一抓手。可参考 向量检索评测实战：Recall@K 与 RAG 质量度量 里 Recall@K 的检索侧度量思路做交叉验证。
三、环境准备与评测数据集构造
RAGAS 基于 HuggingFace datasets 的 Dataset 结构，每条样本需要四个字段：问题、答案、检索到的上下文列表，以及（用于 context_* 指标）标准答案参考。先装依赖：
# 安装核心依赖
pip install ragas datasets langchain-openai
# 如果你打算用本地模型当"判官"，再装 Ollama 适配
pip install langchain-ollama
构造评测集时，建议从真实用户问题里抽样，并保留人工标注的标准答案。样本量不必大，50~200 条就足以看出趋势；关键是覆盖你的长尾场景，而不是只挑简单的。
from datasets import Dataset
samples = {
"question": [
"公司年假怎么计算？",
"报销单超过 5000 元需要谁审批？",
],
"answer": [
"入职满 1 年享 5 天年假，每多 1 年加 1 天，上限 15 天。",
"超过 5000 元需部门总监审批，超过 2 万元需财务副总裁审批。",
],
"contexts": [[
"年假制度：入职满 1 年 5 天，每满 1 年加 1 天，封顶 15 天。",
"报销审批：<5000 直属领导；5000~20000 部门总监；>20000 财务副总裁。",
]],
"reference": [
"入职满一年可休 5 天年假，逐年递增，最多 15 天。",
"5000 元以上由部门总监审批，2 万元以上由财务副总裁审批。",
],
}
dataset = Dataset.from_dict(samples)
四、用 RAGAS 跑一次端到端评估
把数据集和评估指标传给 evaluate，RAGAS 会自动调用”判官模型”给每条样本打分，最后汇总成均值。下面用 OpenAI 兼容接口作为判官，实际生产里完全可以换成自建模型（见下一节）。
from ragas import evaluate
from ragas.metrics import (
faithfulness, answer_relevancy,
context_precision, context_recall,
)
result = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result)
# 输出示例: faithfulness=0.94, answer_relevancy=0.91,
# context_precision=0.88, context_recall=0.90
输出是一组 0~1 的分数。单独看绝对值意义不大，关键是把它接入 CI，和上一版本做对比——只要 faithfulness 或 context_recall 跌幅超过阈值，就阻断发版。
五、用本地模型当”判官”，省钱又可控
评估过程本身要大量调用 LLM，全走云端 API 成本不低，且数据要出网。RAGAS 支持用 LangChain 包装任意模型，包括本地 Ollama 部署的开源模型。搭建私有知识库与推理链可参考 2026 年搭建私有 AI 知识库：Dify + Ollama 本地部署完整教程，推理引擎选型见 大模型推理引擎怎么选：vLLM/SGLang/Ollama。
from langchain_ollama import ChatOllama, OllamaEmbeddings
from ragas.llms import LangchainLLMWrapper
from ragas.embeddings import LangchainEmbeddingsWrapper
# 用本地 qwen2.5 当判官 LLM，nomic-embed-text 当嵌入
local_llm = ChatOllama(model="qwen2.5:14b", base_url="http://localhost:11434")
local_emb = OllamaEmbeddings(model="nomic-embed-text", base_url="http://localhost:11434")
evaluator_llm = LangchainLLMWrapper(local_llm)
evaluator_emb = LangchainEmbeddingsWrapper(local_emb)
result = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
llm=evaluator_llm,
embeddings=evaluator_emb,
)
本地判官对显存有要求，14B 级别建议至少 12GB 显存；显存紧张可降到 7B，但分数会与云端模型存在系统性偏差，做版本对比时务必固定同一判官，否则数字不可比。本地量化部署要点见 本地大模型量化部署：GGUF 与 llama.cpp 调优。
六、把评估做成 CI 可回归的质量防线
评估只有跑进流水线才有生命力。把上面的脚本封装成 pytest，给每个指标设最低门槛，再挂到 GitHub Actions，每次改知识库或提示词都自动跑。CI 基础可参考 GitHub Actions 实战：从零搭建 CI/CD 流水线。
# test_rag_eval.py
import pytest
from ragas import evaluate
from ragas.metrics import faithfulness, context_recall
def test_rag_quality(dataset, evaluator_llm, evaluator_emb):
r = evaluate(dataset, metrics=[faithfulness, context_recall],
llm=evaluator_llm, embeddings=evaluator_emb)
assert r["faithfulness"] >= 0.85, "忠实度跌破红线，疑似幻觉"
assert r["context_recall"] >= 0.80, "召回不足，检索需要优化"
| 指标 | 建议下限 | 跌破意味着 |
|---|---|---|
| faithfulness | 0.85 | 生成器开始编造，优先排查提示词 |
| answer_relevancy | 0.80 | 答非所问，检查问题与上下文对齐 |
| context_recall | 0.80 | 检索漏召，调整分块 / top-k / 向量库 |
| context_precision | 0.75 | 召回噪声大，前置过滤或重排 |
七、常见误区与排障
落地 RAGAS 时几个高频坑：用同一份数据既训练又评估导致分数虚高；判官模型和生成模型混用造成偏差；只盯总分忽略单项；以及样本量太小导致波动大。下面给出排查清单。
| 现象 | 可能原因 | 对策 |
|---|---|---|
| faithfulness 持续偏低 | 提示词未强制”仅依据上下文” | 加入”不得超出上下文作答”约束 |
| context_recall 上不去 | 分块过大或 top-k 太小 | 减小分块、提升 top-k、加混合检索 |
| 各次运行分数抖动 | 判官 LLM 温度未清零 | 固定 temperature=0 与随机种子 |
| 本地判官偏差大 | 模型能力弱于云端 | 统一判官版本，仅做环比 |
八、与向量检索评测的关系
RAGAS 的 context_* 指标关注的是”召回的内容对不对”，而 向量检索评测实战：Recall@K 与 RAG 质量度量 介绍的 Recall@K 关注的是”在前 K 条里是否命中”。两者是互补视角：Recall@K 帮你调检索器参数，RAGAS 帮你看最终生成质量。建议先用向量检索评测把召回基线打好，再用 RAGAS 做端到端验收，形成”检索—生成”双保险。多智能体编排场景里的可靠性保障思路，也可对照 AutoGen 实战：用多智能体编排框架构建协作式 AI Agent 一起看。
结语
RAG 不是”接个向量库就能上线”的玩具，它的质量需要被持续度量。RAGAS 把忠实度、相关性、上下文精度与召回变成可回归的数字，让检索增强生成从玄学走向工程。把它接进 CI，你的每次改动都能带着数据底气上线。
