RAG 系统上线后，最常听到的一句话是："我测了几个问题，感觉效果还可以。"

这个"感觉"在 Demo 阶段没问题，但在生产环境是致命的。真实线上问题远比测试复杂：用户问法千变万化，召回结果时好时坏，大模型偶尔胡说，知识库更新后效果可能变差，Prompt 改了一行也可能影响回答质量。没有评测体系，每次改动都是盲人摸象。

本文介绍如何用 Ragas 把 RAG 系统的质量评估从主观感受变成可量化的数据。

为什么需要自动化评测
人工测试最大的问题是不可复现。今天问 20 个问题看起来不错，明天换一批问题回答开始跑偏，后天改了 Prompt 又不知道到底变好了还是变差了。

RAG 系统不是普通接口。普通接口看返回码、字段、耗时就够了；RAG 还要看：答案有没有答到点上？是不是基于资料回答的？召回内容是否相关？有没有漏掉关键知识？有没有胡编乱造？

这些东西靠肉眼看，很难持续稳定。

Ragas 是什么
Ragas 是专门评测 RAG 应用效果的开源框架，核心指标包括：

Faithfulness：答案是否忠于召回资料，用于检测幻觉
Answer Relevancy：答案是否回答了用户的问题
Context Precision：召回内容中有多少是真正有用的，且是否排在前面
Context Recall：回答问题所需的关键资料有没有被检索出来
Answer Correctness：答案最终是否正确，通常需要标准答案
Ragas 的一大优势是支持 reference-free evaluation，部分指标不依赖人工标准答案。真实业务里很多问题没有现成答案，比如"这个活动为什么投放效果不好""客户投诉应该怎么处理"，Ragas 可以用自动化指标判断回答是否忠于上下文、是否相关、召回是否有效。

核心指标通俗解释
Faithfulness 抓的是答案里的说法能不能在上下文里找到依据。

用户问："公司报销打车费需要什么条件？"

知识库写："工作日加班超过晚上 9 点，可以申请打车报销。"

模型答："工作日加班超过晚上 8 点即可报销，并且周末也可以报销。"

"晚上 8 点"和"周末也可以报销"都不是资料里说的，Faithfulness 就会给低分。

Answer Relevancy 看的是回答有没有围绕用户问题展开，不是事实对不对。

用户问："如何申请发票？"

模型答："发票是企业财务管理的重要凭证，发票分为增值税普通发票和专用发票……"

这段话可能没错，但没有告诉用户怎么申请，Answer Relevancy 就会给低分。

Context Precision 评估检索器是否能把相关 chunk 排在不相关 chunk 前面。

用户问："密码忘了怎么重置？"

系统召回 5 个片段：密码重置流程、登录失败处理、修改手机号流程、公司简介、产品价格说明。

第 1 个很相关，第 2 个有点相关，第 4 和第 5 没什么用。Context Precision 低，说明召回里垃圾内容太多，会导致 Prompt 被无用内容占满，大模型抓不到重点。

Context Recall 检查回答这个问题需要的关键资料有没有被检索出来。

用户问："试用期离职需要提前几天通知？"

标准资料有两段：试用期员工提前 3 天通知；正式员工提前 30 天通知。

如果系统只召回了正式员工提前 30 天，没召回试用期提前 3 天，Context Recall 就会给低分。资料没召回，模型大概率只能猜。

实战：搭建评测流水线
评测不是只看最终答案，要拆成两段看：检索有没有找对资料？生成有没有基于资料回答？

第一步：准备评测数据集

评测数据集一般包含：

question：用户问题
ground_truth：标准答案
contexts：召回上下文
answer：模型回答
category：业务标签
difficulty：难度等级
不要一上来追求几千条。先做 50 条核心问题、100 条高频问题、200 条线上真实问题，关键是质量不是数量。

问题要分层：高频简单问题、多条件组合问题、容易混淆问题、跨文档问题、需要拒答的问题、知识库无答案的问题。分层能让你知道系统到底弱在哪里。

第二步：跑 RAG 链路，收集中间结果

一次问答最好记录：requestId、user_query、rewrite_query、retrieved_chunks、rerank_score、final_context、prompt、model_answer、model_name、temperature、token_usage、latency、知识库版本、Prompt 版本、Embedding 模型版本、切片策略版本。

评测结果差的时候，你要知道问题出在哪。是问题改写错了？检索没召回？重排序排错了？Prompt 太乱？模型幻觉？知识库本身没有答案？没有中间日志，评测只能告诉你"差"；有中间日志，评测才能告诉你"为什么差"。

第三步：选择评测指标

一套比较实用的指标组合：

检索阶段：Context Precision、Context Recall、Context Relevancy、TopK 命中率、MRR

生成阶段：Faithfulness、Answer Relevancy、Answer Correctness、Hallucination、格式合规

系统阶段：平均耗时、P95 耗时、Token 成本、失败率

最终你会得到一张评测报告：

指标    结果    说明
Context Recall    0.82    大部分关键资料能召回
Context Precision    0.61    垃圾召回偏多
Faithfulness    0.90    回答基本忠于资料
Answer Relevancy    0.78    部分回答绕远
Hallucination    0.08    幻觉率较低
平均耗时    2.3s    可以接受
P95 耗时    5.8s    高峰期偏慢
生产环境的五个评测场景
场景一：Prompt 改动前后对比

老版本："请根据资料回答用户问题。"

新版本："请严格根据资料回答，如果资料中没有答案，请回答无法确认。"

跑同一批评测集，对比 Faithfulness 是否提升、Answer Relevancy 是否下降、拒答率是否升高。Prompt 改完不是单纯变好，经常是幻觉降低了但拒答变多了，回答更安全了但可用性下降了。自动化评测帮你量化这些变化。

场景二：切片策略评测

三种方案：每 300 字切一片、每 800 字切一片、按标题层级切片。

用评测集跑一遍，看 Context Recall 哪个高、Context Precision 哪个高、Faithfulness 哪个高、Token 成本哪个低。切片太小容易丢上下文，切片太大容易塞进无关内容，自动化评测帮你找到平衡点。

场景三：Embedding 模型替换评测

同一批问题、同一套知识库、同一个 TopK，只替换 Embedding 模型。比较召回率有没有提升、相关性有没有提升、耗时有没有增加、存储成本有没有变化。如果 Context Recall 提升明显但 Context Precision 下降，说明新模型召回更广但噪声也变多，这时候可以配合 rerank。

场景四：重排序模型评测

先粗召回 30 条，再精选前 5 条给大模型。评测重点是 Context Precision、TopK 相关性、最终回答质量、整体耗时。如果加了 rerank 后 Context Precision 提升、Faithfulness 提升、耗时只增加 200ms，那就值得。如果只提升一点点但耗时增加 1 秒，就要谨慎。

场景五：上线前 CI/CD 自动拦截

每次改代码、Prompt、切片策略、检索参数、模型版本，都自动跑评测。设置阈值：Faithfulness 不能低于 0.85，Answer Relevancy 不能低于 0.80，Context Recall 不能低于 0.75，幻觉率不能高于 0.10，P95 耗时不能超过 6 秒。不达标就不允许上线。这就是 AI 应用里的质量门禁。

指标设计的两个原则
不要只看一个总分。很多团队做一个"综合得分"然后只看总分，这很危险。RAG 系统的问题是分层的。总分 85 看起来不错，但拆开看 Context Recall 只有 0.55、Faithfulness 有 0.95、Answer Relevancy 有 0.88，说明模型很听话但资料经常没找全。不拆指标，根本不知道问题在哪。

指标要和业务风险挂钩。普通 FAQ 重点看 Answer Relevancy、Context Precision；政策制度问答重点看 Faithfulness、Answer Correctness、拒答准确率；客服售后重点看业务口径、安全合规、幻觉率；金融法律医疗重点看拒答、风险提示、合规性、来源依据。

总结
Ragas 的价值不是只告诉你"好不好"，而是告诉你"哪里不好"。Faithfulness 低说明模型可能胡说，Context Precision 低说明召回垃圾内容太多，Context Recall 低说明关键资料没召回，Answer Relevancy 低说明回答没答到点上。这些信号对排查问题非常有帮助。

把 Ragas 集成到开发流程里，每次改动都有数据支撑，RAG 系统才能真正从"感觉还行"进化到"数据说话"。