RAG系统评估实战：使用Ragas和DeepEval构建高质量检索增强生成应用

构建高质量的 RAG 应用需要系统的评估方法。本文介绍如何使用 Ragas 和 DeepEval 进行 RAG 系统评估。

为什么需要评估 RAG？

RAG 系统的质量取决于多个因素：

检索文档的相关性
生成答案的准确性
答案对上下文的忠实度
回复的完整性和有用性

关键评估指标

1. 上下文精确度 (Context Precision)

衡量检索到的上下文与问题的相关程度。

2. 忠实度 (Faithfulness)

衡量生成答案与检索上下文的一致性。

3. 答案相关性 (Answer Relevance)

衡量答案与问题的相关程度。

4. 上下文召回率 (Context Recall)

衡量检索到所有相关信息的完整程度。

使用 Ragas 评估

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy

# 准备评估数据
dataset = {
    "question": ["问题1", "问题2"],
    "answer": ["答案1", "答案2"],
    "contexts": [["上下文1"], ["上下文2"]],
    "ground_truth": ["标准答案1", "标准答案2"]
}

# 运行评估
results = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy]
)

使用 DeepEval 评估

from deepeval import evaluate
from deepeval.metrics import FaithfulnessMetric

metric = FaithfulnessMetric()
test_case = LLMTestCase(
    input="问题",
    actual_output="实际答案",
    retrieval_context=["上下文"]
)

evaluate([test_case], [metric])

评估流程最佳实践

建立基准: 使用标准数据集建立评估基准
持续监控: 定期运行评估，追踪性能变化
迭代优化: 根据评估结果调整系统参数
A/B 测试: 对比不同配置的效果

常见问题与优化

问题：忠实度低

优化 prompt 设计
减少幻觉的生成策略
增加上下文的约束

问题：相关性低

改进检索策略
调整 embedding 模型
优化查询重写

总结

系统的评估是构建高质量 RAG 应用的关键。通过 Ragas 和 DeepEval，我们可以量化评估结果，持续优化系统性能。

评估指标的选择：不要全跑

Ragas 和 DeepEval 提供 20+ 指标，但全跑既慢又贵。优先级建议：

首批必跑（解释 80% 质量问题）：

Faithfulness：回答是否基于上下文（幻觉检测）
Answer Relevance：回答是否切题
Context Precision：检索的 top-K 文档是否相关

第二轮优化时加：

Context Recall：是否漏召关键文档
Answer Correctness：相对 ground truth 的对错
Answer Similarity：与参考答案的语义相似度

专项问题诊断时加：

Hallucination metric：单独识别幻觉
Toxicity metric：内容安全
Bias metric：公平性

评估集的构建：从线上日志开始

最实用的评估集来源：

收集最近 30 天线上 query 与回答
人工标注 200-500 条作为基线
按业务类型分层（FAQ、技术问答、政策咨询等）
每月补充 20-30 条新增 case，避免评估集过时

不要追求"完美的 5000 条评估集"——业务 3 个月变一次，标注很快就失效。持续更新的小集合 远胜一次性的全集。

Ragas vs DeepEval 的真实差异

两个工具的定位差异：

维度	Ragas	DeepEval
指标体系	RAG 专用指标丰富	通用 LLM 指标 + RAG
自定义指标	支持	强（Pytest 风格）
集成 CI/CD	一般	强
中文支持	一般	较好
性能	中等	快
学习曲线	中	低

离线评估与在线监控的结合

评估不能只离线跑，必须接入在线流量：

离线评估：每晚跑历史 query 样本，给出趋势报告
在线 A/B 测试：新版本上线时 5% 流量对比，看指标变化
在线实时监控：监控 Faithfulness 与 Answer Relevance 的滑动平均，异常告警

单纯离线评估的问题是"评估集与线上分布漂移"——你优化的可能是过去的问题，线上却是新问题。

评估成本的控制

跑一次完整评估的成本可能比想象中贵：

Ragas 一条 Faithfulness 需要 2-3 次 LLM 调用
500 条评估集 × 3 指标 = 4500 次 LLM 调用
用 GPT-4 评估：$20-50/次
用本地模型：慢但便宜

降本策略：

用小模型评估大多数指标（qwen2.5-7b、llama3.1-8b）
评估集分层抽样（不必每次都跑 500 条）
增量评估（只跑新 case）
指标缓存（同一 query 不重复评）

评估指标的"陷阱"

几个常见的指标误读：

Faithfulness 高 ≠ 答案正确：可能忠实于错的上下文
Answer Relevance 高 ≠ 回答完整：可能答得切题但不深入
Context Precision 高 ≠ 检索好：可能只是因为候选集大
指标提升 ≠ 用户体验提升：指标是代理，最终要看用户反馈

多指标一起看，关注"指标与人工评分的相关系数"，不要单指标优化。

与人工评估的结合

再好的自动评估也无法替代人工，关键节点的 judgment 必须人来做：

每月抽 50 条做人工评分
计算自动评分与人工评分的 correlation
相关性 < 0.6 的指标要重新审视定义
人工评估的 case 进 prompt 改进 backlog

工具是手段，不是目的。Ragas/DeepEval 帮你量化，人帮你定义"好"。

选型决策表

你的场景	推荐工具	理由
纯 RAG 评估	Ragas	指标专业度高
整体 LLM 应用评估	DeepEval	覆盖范围广
团队 Python 测试习惯	DeepEval	Pytest 风格
多语言/中文场景	DeepEval	中文更稳
需要快速自定义指标	DeepEval	API 更灵活

不要纠结"哪个工具更好"。先跑通一个，把"度量"这件事做起来，再优化指标体系。