RAG评测怎么做才不白费功夫：别再盯着'召回率'了

📅 2026/9/26 ✍️ 小文 📖 约 1 分钟

从检索质量、生成忠实度到端到端任务成功率，一套可落地的RAG评测体系，含RAGAS、TruLens等工具选型与自动化评测管线搭建方法。

一个残酷的现实

大部分团队的 RAG 评测停留在两个动作：跑几个问题看回答像不像样，然后调 chunk_size 和 top_k。结果就是改了半天参数，业务效果原地踏步。

问题出在哪？你在优化检索指标，但业务关心的是任务成功。 两者经常脱节。

三层评测体系

一个成熟的 RAG 评测应该分三层，每层回答不同的问题：

第一层：检索质量（Retrieval）

回答”找到对的资料了吗”。关键指标：

  • Recall@k：标准答案所在的文档是否出现在返回的前 k 条里。这是检索的上限，检索不到，后面再强也白搭。
  • Precision@k：返回的结果里有多少是相关的。太高召回、太低精度的结果会给模型塞垃圾。
  • MRR / NDCG：相关结果排得越靠前越好，衡量排序质量。

第二层：生成质量（Generation）

回答”基于找到的资料，答得对吗”。这里最容易被忽视的是忠实度（Faithfulness）——模型有没有编造资料里没有的内容。

  • Faithfulness：答案中的每个论断是否都能在检索到的上下文中找到依据。
  • Answer Relevance：答案是否切题，没有答非所问。
  • Context Precision：检索到的上下文里相关内容的占比。

第三层：端到端任务成功率（E2E）

回答”用户的问题真的解决了吗”。这才是老板关心的一层。

指标因场景而异：客服场景看”问题解决率”和”转人工率”，法律场景看”引用准确率”，代码场景看”答案可执行率”。

RAGAS：快速起步的工具

RAGAS 是开源社区最常用的 RAG 评测框架，它能自动计算 Faithfulness、Answer Relevance 等指标，不需要人工标注。

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

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_precision],
)
print(result)

优点：上手快，指标开箱即用，用 LLM 做裁判。 缺点：LLM 裁判本身会出错，且不同模型评分不可比。关键是要固定裁判模型，否则指标漂移。

构建评测数据集：最难也最关键的一步

工具有了，数据没有，一切都是空的。常见做法：

  1. 从真实日志采样：挑 200–500 条真实用户问题，人工写标准答案和应检索到的文档 ID。
  2. 合成数据增强：用大模型基于知识库生成问答对，人工审核过滤。注意合成数据有分布偏差，不能只用它。
  3. 难例集（Hard Set）：专门收集那些当前系统答不好的问题，这部分最能反映改进效果。

建议维护三个集合：Golden Set（稳定基准）、Hard Set（难例）、Live Set（滚动真实样本）。

自动化评测管线

手动跑评测不可持续。把它接进 CI/CD：

# .github/workflows/rag-eval.yml
- name: Run RAG Eval
  run: |
    python eval/run_eval.py --dataset eval/golden.jsonl
    python eval/check_threshold.py --min-faithfulness 0.85

每次改动 prompt、换 embedding 模型、调 chunk 策略，都自动跑一遍。Faithfulness 低于阈值就阻断合并，避免”感觉变好了”其实变差了。

五个常见误区

误区一：只测检索不测生成。 检索 Recall 高不代表回答对，模型可能无视了检索内容。

误区二：用 LLM 裁判但不验证裁判。 先让 LLM 打分，再抽 50 条人工核对，看看裁判和人类的吻合度。吻合度低就换裁判模型或改评测 prompt。

误区三：评测集和线上分布不一致。 用论文问答集训练，上线却是客服场景，指标毫无意义。

误区四：只看平均值。 平均 Faithfulness 0.9 很漂亮，但可能有一批问题得分 0.3。要看分布和最低分。

误区五：忘了成本与延迟。 一个 Faithfulness 0.95 但每次请求 8 秒、花费 $0.5 的方案，业务可能根本无法接受。评测必须带上延迟和质量-成本曲线。

一个实用的上线检查表

  • 有 200+ 条人工标注的 Golden Set
  • 固定了裁判模型和评测 prompt 版本
  • 三层指标都有监控，且接入告警
  • 每次变更自动跑评测，设质量红线
  • 定期用真实流量更新 Live Set
  • 记录延迟 P50/P95 和单次成本

结语

RAG 评测的本质，是把”感觉不错”变成”数据证明不错”。检索、生成、端到端三层缺一不可，而固定的评测集和自动化的管线是让评测真正产生价值的前提。别等到上线后用户投诉，才发现自己的 RAG 一直站在原地。

🏷️ #RAG#评测#LLMOps#检索增强
📤 分享到