Ragas 怎么评测 RAG：Faithfulness、Context 和测试集先建好

Ragas 是很多 RAG 评测教程里会出现的工具。用户搜索“Ragas RAG evaluation”“faithfulness”“context precision”时，通常已经不满足于“看起来回答不错”，而是想知道知识库到底有没有检索到对的资料，回答是否忠实于上下文。

这篇是草稿，正式发布前需要核对 Ragas 最新官方文档。更通用的测试集设计可以看 RAG 评测集怎么做，检索排错可以看 RAG 检索不到内容怎么办。

适合谁

适合已经搭好 RAG 原型，想评估效果的人。比如 Dify、LangChain、LlamaIndex、FastGPT、Pinecone、Chroma 或自建知识库。

也适合客户项目验收。客户问“这个知识库准不准”，你不能只演示几个成功问题，而要拿出测试集、指标和失败案例。

不适合谁

不适合资料还没整理、检索链路还没跑通的项目。评测工具不能替你修复坏资料。

也不适合把自动分数当唯一标准。Ragas 指标有帮助，但复杂业务仍然需要人工复核。

第一步：准备测试集

RAG 评测要先有问题、答案、上下文或正确来源。测试集可以从真实用户问题、客服记录、内部 FAQ、失败反馈和人工设计边界题中整理。

不要只准备简单题。要包含常见问题、相似问题、找不到答案、旧版本资料、权限边界和容易误导模型的问题。

第二步：理解常见指标

Ragas 官方 metrics 文档提供多种评测指标，常见方向包括回答是否基于上下文、上下文是否相关、答案是否有帮助等。

新手可以先关注三类问题：检索片段是否对，回答是否忠实，答案是否满足用户问题。不要一开始追求所有指标。

第三步：区分检索和生成

RAG 错误通常分两类：检索没有召回正确资料，或者模型拿到了正确资料但回答错。评测时要把两者分开。

如果 context precision 或 recall 不理想，先查 chunk、embedding、metadata 和 Top K。如果 faithfulness 不理想，查提示词、引用规则和模型输出。

第四步：建立版本对比

每次改模型、embedding、chunk、rerank 或提示词，都要用同一组测试集对比。否则你只知道“好像变了”，不知道到底变好还是变坏。

客户项目里，版本对比记录可以作为验收依据。它比口头承诺更可靠。

第五步：保留人工复核

自动评测能提高效率，但不能完全替代人工。尤其是行业知识、政策条款、合同、医疗、财务和人事内容，人工判断仍然必要。

建议把自动分数用于筛查，把人工复核用于关键样本和失败案例。

常见错误

常见错误是没有测试集就谈评测。另一个错误是只看总分，不看具体失败样本。

还有一种错误是把评测结果当成绝对真理。LLM-as-judge 和自动指标都有局限，必须结合人工抽检。

客户项目里，Ragas 的价值不是给一个漂亮分数，而是帮助你建立改进节奏。每次优化 chunk、embedding、Top K、rerank 或提示词，都用同一批问题跑一遍，比较失败样本是否减少。分数只是入口，失败样本才是下一步工作。

验收时建议把测试集分成三类：基础问题、边界问题、找不到答案的问题。基础问题看系统是否能正常回答，边界问题看系统是否会混淆资料，找不到答案的问题看系统是否会承认依据不足。这三类都过，RAG 才更接近可上线。

风险提醒

评测数据本身可能包含客户问题、文档片段和业务答案。存储和分享测试集时要注意权限和脱敏。

如果使用外部模型做评测，也要确认客户是否允许把样本发送出去。

发布前还要确定评测频率。早期可以每次修改知识库、embedding、chunk 或提示词后都跑一次；稳定后可以按周或按发布批次跑。评测不是一次性验收，而是知识库维护的一部分。

具体步骤

第一步，整理真实问题和正确来源。第二步，运行 RAG 系统并保存回答与上下文。第三步，选择 Ragas 指标。第四步，跑评测并查看失败样本。第五步，按检索问题和生成问题分类修复。第六步，保留人工复核和版本对比。需要测试集模板可以进入 工具导航。

免责声明

本文只用于技术学习和项目预评估，不构成准确率、安全、合规、评测结论或商业效果承诺。正式验收前，应由人工核对 Ragas 官方文档、客户数据授权和评测标准。