生态工具篇难度 3⏱ 12 分钟概念
01RAG 评估
系统化评估 RAG 系统的检索质量与生成质量，定位瓶颈并指导优化。
RAG评估RAGASFaithfulnessContext Precision
更新于 2026-03-25rag-evaluation
用于系统化测量 LLM/Agent 系统输出质量与行为可靠性的指标体系和方法论
内容摘要
评估框架（Evaluation Framework）是一套系统化的指标体系 + 评估工具 + 工作流程，用来量化回答"你的 LLM/Agent 系统到底好不好用"这个问题。它不只看最终答案对不对，还关注中间推理过程是否合理、工具调用是否恰当、响应速度和成本是否可接受。
评估框架（Evaluation Framework）是一套系统化的指标体系 + 评估工具 + 工作流程，用来量化回答"你的 LLM/Agent 系统到底好不好用"这个问题。它不只看最终答案对不对，还关注中间推理过程是否合理、工具调用是否恰当、响应速度和成本是否可接受。
传统软件测试有明确的"对错"标准——函数输入 2+3 应该返回 5。但 LLM 系统的输出是自然语言，同一个问题可以有多种正确表述，也可能出现"看起来像回答但完全编造"的幻觉。更麻烦的是，Agent 系统还涉及多步骤推理和工具调用，每一步都可能偏离正轨。评估框架就是为了解决"LLM 输出没有唯一正确答案，怎么系统地判断质量"这个根本难题而诞生的。
与传统的 BLEU/ROUGE 等文本匹配指标不同，现代评估框架引入了 LLM-as-Judge（用一个 LLM 评判另一个 LLM 的输出）、多维度指标体系（准确性、忠实度、相关性等并行评估）、以及自动化评估管道（集成到 CI/CD 持续监控）。这使得评估从"上线前人工抽查"进化到"全生命周期自动化质量保障"。
| 结构 | 作用 | 说明 |
|---|---|---|
| 评估指标集 | 定义"好"的标准 | 确定要衡量哪些维度，如准确性、忠实度、相关性、延迟、成本 |
| 评估数据集 | 提供评测基准 | 包含查询、参考答案、上下文的标准化测试集 |
| 评估方法 | 决定"怎么打分" | 人工评估、LLM-as-Judge、规则匹配、或混合模式 |
| 评估工具链 | 执行评估计算 | RAGAS、DeepEval、Promptfoo 等开源框架 |
| 评估管道 | 持续监控质量 | 集成到 CI/CD，自动检测性能回退（regression） |
评估指标集是整个框架的核心，它定义了"好"的具体含义。不同场景需要关注不同维度：
评估数据集是评测的"考卷"。一个高质量的评估数据集需要包含：
样本量建议：快速验证 50-100 条，正式基准测试 200-500 条，生产级评估 1000+ 条。
三种主流评估方法各有适用场景：
人工评估：邀请标注人员对 Agent 输出打分。准确度最高，但成本贵、速度慢，适合构建基准数据集和关键场景验收。
自动评估（LLM-as-Judge）：用一个强 LLM（如 GPT-4、Claude）评判另一个 LLM 的输出。成本低、速度快，适合日常迭代和持续监控。但要注意 LLM 评委自身的偏见（如偏好冗长回答、位置偏见等）。
混合评估：先用自动评估大规模筛查，再对高风险或低分样本做人工复审。这是生产环境中最推荐的做法，研究表明混合方法比纯自动方法的整体质量提升约 40%。
评估框架的运作逻辑可以拆成三层：
第一层：定义评估维度与权重。 根据业务场景确定哪些指标最重要。例如搜索类 Agent 侧重准确性和延迟，知识库问答侧重忠实度和相关性。每个指标赋予权重，综合评分公式为：
$$Score = \sum_{i=1}^{n} w_i \cdot m_i$$
其中 $w_i$ 是第 $i$ 个指标的权重（所有权重之和为 1），$m_i$ 是该指标的归一化得分（0-1）。
第二层：执行评估。 将 Agent 的输出（或完整推理轨迹）送入评估器。评估器根据选定的方法（规则匹配、LLM-as-Judge、语义相似度等）计算每个维度的得分。关键区别在于评估粒度：
第三层：分析与反馈。 汇总评估结果，生成诊断报告，精确定位短板。例如"忠实度 0.6 但准确性 0.9"说明 Agent 能回答对但存在幻觉风险，需要优化 RAG 检索环节。
图中展示了评估框架的完整闭环流程。核心转折点在节点 6（是否达标）——这里形成了"评估-诊断-优化-再评估"的持续改进循环。三种评估方法在节点 3 分叉，实际项目中通常组合使用而非单选。
当前最流行的三个开源评估框架各有侧重：
| 维度 | RAGAS | DeepEval | Promptfoo |
|---|---|---|---|
| 核心定位 | RAG 管道专项评估 | 全场景 LLM 测试（RAG + Agent + 对话） | Prompt 工程 + 红队安全测试 |
| 指标数量 | 5 个核心 RAG 指标 | 60+ 指标（RAG、安全、Agent 等） | 基础 RAG + 安全指标 |
| 评分可解释性 | 只返回分数，不解释原因 | 自解释（Self-Explaining）：告诉你为什么扣分 | 只返回分数 |
| 技术栈 | Python | Python / Pytest | Node.js / YAML |
| CI/CD 集成 | 需手动配置 | 原生 Pytest 集成，开箱即用 | CLI 驱动，适合脚本化 |
| 合成数据生成 | 内置 QA 对生成 | 支持 | 不支持 |
| 红队安全测试 | 不支持 | 支持 | 强项（注入检测、越狱扫描） |
| 选型建议 | 只需评估 RAG 管道 | 需要全面的 LLM 测试体系 | 侧重 Prompt 迭代和安全合规 |
# 基于 ragas==0.2.x 验证（截至 2026-03）
# 最小示例：使用非 LLM 指标做离线评估，不依赖 OpenAI API Key
from ragas.dataset_schema import SingleTurnSample
from ragas.metrics._string import NonLLMStringSimilarity
from ragas.metrics import StringPresence
# 构造一个最小评估样本：response 对应模型输出，reference 对应参考答案或关键短语
sample = SingleTurnSample(
response="RAG 是检索增强生成，通过先检索再生成来减少幻觉。",
reference="检索增强生成",
)
# 指标 1：判断回答里是否包含关键短语（无需 LLM / API Key）
keyword_metric = StringPresence()
keyword_score = keyword_metric.single_turn_score(sample)
# 指标 2：计算回答与参考文本的字符串相似度（无需 LLM / API Key）
similarity_metric = NonLLMStringSimilarity()
similarity_score = similarity_metric.single_turn_score(sample)
print({
"string_presence": keyword_score,
"non_llm_string_similarity": similarity_score,
})
# 输出示例：{'string_presence': 1.0, 'non_llm_string_similarity': 0.4}
上述代码展示了 RAGAS 的另一种安全用法：在本地先使用 StringPresence 和 NonLLMStringSimilarity 这类非 LLM 指标做离线验证。这样可以先检查回答是否包含关键概念、以及与参考答案在字面层面的接近程度，不需要额外配置 OpenAI API Key。需要更强的语义评估时，再切换到 faithfulness、answer_relevancy、context_precision 等依赖评审模型的指标。
| 概念 | 与评估框架的区别 | 更适合关注的重点 |
|---|---|---|
| 基准测试（Benchmark） | Benchmark 是固定的"考试题库"（如 MMLU、HumanEval），评估框架是"考试制度"——包含出题、阅卷、分析全流程 | 关注标准化数据集和排行榜 |
| 可观测性（Observability） | 可观测性是"监控仪表盘"，记录系统运行时的 trace、日志、指标；评估框架是"质量审计"，主动测量输出好不好 | 关注实时监控、问题定位 |
| A/B 测试 | A/B 测试比较两个版本在真实用户上的表现差异；评估框架在离线数据集上全面度量系统质量 | 关注线上版本选择 |
核心区别：
| 常见误区 | 正确理解 |
|---|---|
| "准确率高就说明系统好" | 准确率只是一个维度。系统可能准确率 95% 但响应时间 10 秒、每次查询花费 0.5 美元——综合质量未必合格。必须多维度评估 |
| "LLM-as-Judge 可以完全取代人工" | LLM-as-Judge 适合大规模初筛，但在医疗、法律等高风险场景，以及构建基准数据集时，人工评估仍不可替代。混合方法效果最佳 |
| "一次评估通过就万事大吉" | 模型更新、知识库变动、用户行为变化都会导致性能漂移（drift）。评估必须集成到 CI/CD 持续运行，而非一次性工作 |
| "用同一套指标评估所有 Agent" | 搜索 Agent 看准确性和延迟，知识问答看忠实度和相关性，代码生成看功能正确性和安全性。指标权重必须按场景定制 |
参考答案：
Agent 系统与传统分类任务不同，它涉及多步推理、工具调用和自然语言生成。只看准确率会忽略几个关键问题：（1）回答正确但完全编造理由（忠实度低，存在幻觉风险）；（2）回答正确但耗时 30 秒（延迟不可接受）；（3）回答正确但调用了 20 次 API（成本过高）；（4）回答正确但与用户问的不是同一个角度（相关性低）。多维度指标体系能分别定位这些不同类型的问题，指导有针对性的优化。
参考答案：
建议以 DeepEval 为主 + RAGAS 为辅的组合方案。理由：（1）法律场景对准确性和忠实度要求极高，需要 RAGAS 的 RAG 专项指标（faithfulness、context_precision）精确检测幻觉；（2）法律场景同时需要安全性评估（防止泄露敏感信息）、合规性检查、多轮对话评估等，DeepEval 的 60+ 指标覆盖更全面；（3）DeepEval 的自解释评分能帮助法务团队理解"为什么这条回答被判为不合格"，便于审计追溯；（4）DeepEval 原生 Pytest 集成方便嵌入 CI/CD 持续监控。Promptfoo 侧重 prompt 迭代和安全红队，可以作为补充在安全测试环节使用。
参考答案：
高评估分 + 高用户投诉的矛盾通常指向以下问题：（1）评估数据集不具代表性——测试集覆盖的问题类型与真实用户提问差距大，存在分布偏移。改进方案：从生产日志中提取失败 trace，加入评估数据集；（2）关键维度缺失——只评估了忠实度，没评估用户真正关心的维度（如回答是否通俗易懂、是否完整、格式是否友好）。改进方案：增加"有用性""完整性""可读性"等指标；（3）LLM-as-Judge 与人类判断标准不一致——LLM 评委可能认为"基于上下文、语法正确"就算忠实，但用户期望更深层的理解。改进方案：用人工标注数据校准 LLM-as-Judge 的评分标准；（4）评估粒度不够——只做了最终答案评估（Black-Box），没检查推理轨迹。用户可能遇到"答案最终对了但中间经历了多次错误重试导致极慢"的问题。改进方案：增加轨迹评估（Glass-Box）和延迟分段监控。
优先展示同分类且标签更接近的内容，方便继续串联学习。
系统化评估 RAG 系统的检索质量与生成质量，定位瓶颈并指导优化。
通过多维量化指标对 Agent 的工具调用、推理、任务完成和安全性进行系统化评估
用视觉语言大模型直接"看图识字"，不只提取字符，还能理解文档结构和语义。