RAG 评估实操：用 RAGAS 量化检索质量
"调 RAG 没有 eval 集，就是凭感觉。本文用 RAGAS 框架，讲清四个核心指标（context precision/recall、faithfulness、answer relevancy）各自在测什么、怎么建评测集、怎么跑、怎么用结果定位问题——让'我感觉变好了'变成'召回率从 0.72 提升到 0.91'。"
本文要点
- 主题聚焦：大模型、RAG
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
做 RAG 最让人抓狂的是：你换了个切分策略，感觉回答"好像"变好了，但又说不上来是不是真的——下次换回旧的也没人发现。没有评估的 RAG 优化，全凭手感。 RAGAS 就是来治这个病的：它把"检索质量"和"生成质量"拆成几个可量化的指标，让每次改动都有客观分数。
一、先想清楚：评估的是什么
一个 RAG 系统从 query 到答案，有两段独立的质量：
- 检索段：该召回的内容，召回了没有？召回的，相关的有多少？
- 生成段：回答是否忠于召回内容（不幻觉）？是否切题？
RAGAS 的精髓就是把这两段分开打分，这样你才知道：回答不好，到底是检索没找到（要改切分/召回），还是模型没好好用找到的内容（要改 prompt/模型）。
二、四个核心指标
RAGAS 用四个指标，各自测一件事：
| 指标 | 测什么 | 方向 |
|---|---|---|
| Context Precision | 召回的上下文里，相关的占比（精度） | 越高越好 |
| Context Recall | 该召回的内容，召回了多少（召回率） | 越高越好 |
| Faithfulness | 答案是否都能在上下文里找到依据（防幻觉） | 越高越好 |
| Answer Relevancy | 答案是否切题（不跑题、不啰嗦） | 越高越好 |
诊断逻辑：
- Context Recall 低 → 检索没找全。改切分（更细/更合理）、改 query 改写、加混合检索。
- Context Precision 低 → 召回了一堆无关的。加 rerank、减小 top-k、改 embedding。
- Faithfulness 低 → 模型在编造，没用上下文。强化 prompt（"只根据上下文回答，找不到就说不知道"）、换更遵循指令的模型。
- Answer Relevancy 低 → 答非所问。改 prompt（明确问题边界）、检查 query 改写有没有跑偏。
先看 Context Recall（能不能召回到），再看 Faithfulness（有没有瞎编）——这两个是最关键的基础。Precision 和 Relevancy 是优化期再调的。
三、建评测集：最难但最值的一步
RAGAS 需要一个评测集，每条至少包含：
{
"question": "MCP 协议默认的传输方式有哪些？",
"ground_truth": "stdio 和 HTTP（Streamable HTTP/SSE）两种。",
"contexts": ["...（可选，不提供则由 RAGAS 从你的检索结果填）"],
"answer": "（可选，不提供则由评估用的 LLM 生成）"
}
建集的三个来源：
- 真实用户问题（最好）——从日志/客服里捞用户真实问法，最贴近实际分布。
- 人工编造——覆盖典型场景、边界、易错点。
- LLM 辅助生成——把文档喂给模型，让它"针对这段内容出题 + 给标准答案"，再人工筛。
规模：50–200 条就够起步。少了不统计显著，多了标注成本高。覆盖度比数量重要——要覆盖简单/复杂/多跳/模糊/边界各类问题。
ground_truth 不必是标准答案原文，关键是判定要点（答案里应包含哪些关键事实）。
四、跑起来
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
context_precision, context_recall,
faithfulness, answer_relevancy,
)
# data: 你的评测集,每条跑过 RAG 后补上 contexts 和 answer
dataset = Dataset.from_list([...])
result = evaluate(
dataset,
metrics=[context_precision, context_recall, faithfulness, answer_relevancy],
)
print(result) # 各指标的平均分
RAGAS 用"LLM 当裁判"自动打分（需要你提供一个 LLM），省去人工逐条判。注意：
- 裁判模型要够强。用弱模型当裁判，分数不可信。一般用比你被测系统更强的模型做裁判。
- faithfulness 的判定最依赖裁判能力，裁判模型不行这个分就飘。
- 跑一次要花 token（N 条 × 多次裁判调用），评测集别动辄上千条。
五、用结果定位问题
跑完拿到四个分，不要只看总分。按维度切片看 bad case：
- 按问题类型切片：多跳问题的 recall 是不是特别低？→ 多跳检索要单独优化。
- 按文档来源切片：某类文档召回率低？→ 那类文档的切分/embedding 有问题。
- 看低分 case 的具体内容：faithfulness 低的，看模型在编什么；recall 低的，看漏召了哪段。
评测集 + bad case 分析，才是真正的优化引擎。 分数告诉你"哪里不行"，bad case 告诉你"为什么不行"。
六、把 eval 接进开发循环
RAGAS 的终极用法是进 CI/定时跑：
- 改 prompt / 换 embedding / 调切分 → 跑评测 → 分数下降就拦下（或至少记录）。
- 定期跑一次，监控线上回归（模型 API 升级、文档库变化可能导致分数漂移）。
- 每次发现线上 bad case，补进评测集 → 防止同类问题再次回归。
这样 eval 集会越用越有代表性，系统越用越稳——这是 RAGAS 长期价值的真正所在。
七、几个常见误区
- 只看 answer relevancy。它最容易"看起来高"（模型答得顺），但掩盖了检索和忠实度问题。四个指标要一起看。
- 裁判模型和被测模型同一个。自己判自己，分数虚高。用更强的独立模型当裁判。
- 评测集一成不变。业务变了、文档库变了，老评测集失去代表性。要持续更新。
- 追求分数 100。从 0.7 到 0.85 容易，从 0.95 到 0.99 极难且收益递减。看 ROI，够用就停。
小结
RAG 优化的成熟度，看一件事就够了：你改完之后，能不能说出"召回率从多少变到多少"，而不是"感觉好了"。 RAGAS 就是帮你把感觉变成数字。
四个指标（context precision/recall、faithfulness、answer relevancy）各管一段，建一个 50–200 条的评测集，跑起来，按维度切 bad case。把这套循环跑顺，你的 RAG 才从"玄学调试"走进"工程优化"。这件事的前期投入（建集、接 eval）有点重，但一旦建好，后续每一次改动都受益——是 RAG 项目里 ROI 最高的基础设施。
Related