最近半年我一直在做企业知识库类的RAG项目最头疼的不是把检索和生成管道跑通而是没办法说清楚系统到底好不好。给老板汇报的时候只能说还行感觉比上一版好自己心里其实没底。后来我把RAGAS引入到项目里用一套量化指标给RAG系统做体检才终于把凭感觉变成了看数据。这篇教程就完整记录一下我是怎么用RAGAS评估一个RAG系统的包括指标理解、测试集构建、代码实战和实际使用中踩过的坑。1. 为什么是RAGASRAG系统的体检报告到底该信谁1.1 你很可能正在用错误的方式判断RAG质量大部分人评估RAG系统的方式是人工抽检准备十几个问题一个个去问然后看一眼回答是否通顺、是否命中知识。这种方式不是没用而是有致命缺陷——量小、主观、不可复现。你今天觉得回答不错明天换个人来测可能就觉得不行你改了检索逻辑理论上应该变好但由于测试问题只有十几个波动一两次就完全掩盖了真实变化。你在判断的是这一版感觉如何而不是这个系统在多大程度上做好了这件事。传统NLP指标也顶不上。ROUGE、BLEU这类基于字符串重叠的指标对生成式任务几乎无能为力。同一个意思大模型可以用完全不同的措辞表达字面不重叠但语义一样ROUGE直接判死刑。RAG的生成部分本质是开放文本生成必须用能理解语义的方式去评估。RAGAS就是干这个的。它全称Retrieval Augmented Generation Assessment用一套定义好的指标把RAG系统的质量拆解成可计算的分数。核心思想是让大模型给大模型打分——用LLM作为裁判对检索和生成的不同维度进行判断。1.2 RAGAS是怎么工作的用大模型来给大模型打分RAGAS的做法在第一次接触时可能会有点颠覆认知它不依赖任何标准答案的字符匹配而是构造特定的评估Prompt让LLM扮演裁判角色。举个例子评估Faithfulness忠实度时会把用户问题、系统生成的回答、检索到的上下文这三样东西扔给裁判LLM。裁判LLM先把回答拆解成若干个独立的断言claim然后逐一判断每个断言是否能由给定的上下文推导出来。最后用被支持的断言数 / 总断言数得到这个样本的忠实度分数。这种思路最大的优势是能处理字面不同但语义相同的情况。回答里说该产品保修期为两年上下文里是自购买之日起24个月内提供保修服务裁判模型能识别这两者本质一致于是给高分。这在传统指标里根本做不到。当然这不意味着RAGAS完全不需要标注数据。至少你需要给每个测试问题提供一个ground_truth标准答案或标准上下文Context Recall这一类指标需要用它来度量检索到的信息覆盖了多少标准答案中的信息。1.3 RAGAS和其他方案的区别我见过一些团队自己写评估脚本本质上是手工提问逐条看回答然后记录一个Excel打分表也有团队用LangChain的QAEvalChain或者自己做简单的LLM-as-a-judge。RAGAS相对规范化的地方在于三点指标定义固定、计算逻辑透明、社区维护持续更新。它把评估这件事变成了一个统一框架而不是每个团队从零发明一套轮子。下面这张表是我整理的不同方案的对比方案自动化程度指标可解释性与RAG流程适配度上手成本人工抽检低主观高低ROUGE/BLEU高可解释但失真低低自建LLM裁判中依赖Prompt设计中中RAGAS高高高中所以我的建议是如果只是临时验证Demo人工抽检没问题如果要在项目里持续迭代、对比版本、给决策者看数据RAGAS是更值得投入的方向。2. 四个核心评估指标先搞清楚每个分数在衡量什么用RAGAS之前一定要先理解它的四个核心指标不然拿到报告也不明白分数说明什么。RAGAS的设计思路是把RAG拆成检索和生成两段分别评估质量。2.1 Faithfulness回答有没有睁眼说瞎话Faithfulness衡量的是生成回答中的每一个信息点是否都能从检索到的上下文中找到依据。计算方式大致是裁判LLM将回答拆分为若干个独立陈述对每个陈述打是否可被上下文支持的标签最终得分等于可支持陈述数除以总陈述数。我一开始对Faithfulness的理解有个误区觉得它是在衡量回答正不正确。其实不是。它只关心你是不是照着材料说话的。哪怕知识库里本身的信息是错误的只要回答忠实复述了这个错误信息Faithfulness依然是高分。接地气的说法是这个指标衡量是否靠谱远大于是否正确。在实际业务里我反而觉得这样是合理的——RAG首先应该防止模型凭空捏造事实性的对错是知识库内容质量的事两者职责不同。2.2 Answer Relevancy回答是否答非所问Answer Relevancy衡量的是生成回答和用户问题的相关性。这个指标的计算思路很有意思——它不完全直接打分而是先让裁判LLM根据给定的问题回答反过来生成若干个伪问题然后计算这些伪问题和原始用户问题的Embedding相似度取平均值作为相关性分数。原理在于如果一段回答和问题真正相关那么以这段回答为基础反推出来的可能问题应该和原问题长得很像如果回答是泛泛而谈或者答非所问反推出来的伪问题就会和原问题差得很远。这个指标对高质量废话非常敏感。你明明问A产品的价格模型回答了一大段关于A产品背景介绍的文字——这些字单独看非常正确但答非所问。Answer Relevancy会毫不留情地给低分。2.3 Context Precision检索是不是宁缺毋滥Context Precision衡量的是检索出来的上下文列表中与问题相关的信息排得是否靠前。这个指标背后的逻辑是RAG给LLM提供的上下文是有序的排在前面的内容对生成的引导作用更强。如果前面一大段都是无关文档有用的信息塞在很靠后的位置即使最终也被模型利用了整个管道的效率也很差——多余信息不仅浪费Token还容易引入噪声干扰模型判断。计算时会遍历检索到的每个上下文chunk判断它是否与问题相关然后计算一个基于位置权重的精度分数。简单理解相关的chunk越靠前分数越高无关chunk越少分数越高。它评估的是检索质量中的精确性维度。2.4 Context Recall该找的内容是否都找回来了Context Recall衡量的是标准答案ground truth中有多少信息点能在检索到的上下文中找到。计算方式是把标准答案拆解成若干断言逐一判断这些断言是否被检索上下文所覆盖。最终得分是被覆盖的断言数 / 标准答案总断言数。这个指标对应的是检索质量中的召回维度。业务场景中如果用户问这个产品的保修政策和退换货条件是什么知识库里这两块信息都有但你的检索管道只提到了保修政策遗漏了退换货那么Context Recall就会偏低。它是判断检索管道有没有漏东西的关键指标。2.5 指标关系和判读顺序这四个指标其实构成了一个清晰的诊断链路指标评估对象回答的核心问题分数低说明什么Faithfulness生成有没有编造模型没有忠实使用上下文Answer Relevancy生成有没有答非所问生成环节跑偏了Context Precision检索检索是否精准无关信息太多或排得太靠前Context Recall检索检索是否完整该捞的没捞到检索有遗漏实际判读报告时我的习惯是先看Faithfulness——如果它都很低说明生成端基本在瞎编后面三个都别看了先修提示词或模型。再看Context Recall和Precision——如果这两项低说明检索端有问题该去调整Embedding、切块策略和检索算法。最后看Answer Relevancy——如果前面的指标都正常只有它低可能是模型面对多个相关信息时选择了错误的侧重点。3. 动手前准备版本、环境与测试集构建3.1 环境安装与依赖版本RAGAS安装很简单pip一行搞定pip install ragas但有几个版本层面的坑需要提前说明。RAGAS的API在0.1.x到0.2.x之间变化较大尤其是指标的导入路径。0.2.x中context_relevancy被拆分成了context_precision和context_recall两个独立指标一些旧的metrics子模块路径也做了调整。我建议直接使用较新的0.2.x版本网上很多旧教程的代码跑不通多半是版本原因。除了RAGAS本身通常还需要安装datasets库来构造评估数据集以及LangChain或LlamaIndex二选一。RAGAS支持从LangChain的检索器接口直接接收数据实际项目里我都是配合LangChain用的pip install ragas datasets langchain openai如果你是自建管道不依赖LangChain也没关系RAGAS的核心只是接收结构化数据问题、回答、上下文列表完全可以脱离框架单独用。3.2 测试集从哪来合成生成与手工构造评估RAG需要测试集也就是一组问题标准答案标准上下文的数据。很多人卡在这步觉得标注太耗时。RAGAS提供了两种路径。路径一RAGAS自带的测试集生成器可以利用文档语料自动生成测试集核心思路是让LLM基于知识库文档内容生成若干类型的问答对。RAGAS把问题分成了简单、推理、多上下文几种演化类型模拟真实用户提问的复杂度from ragas.testset.generator import TestsetGenerator from ragas.testset.evolutions import simple, reasoning, multi_context generator TestsetGenerator.from_default( openai_generator_llmgpt-4o, openai_filter_llmgpt-4o ) testset generator.generate_with_langchain_docs( documents, test_size30, distributions{simple: 0.5, reasoning: 0.3, multi_context: 0.2} )这种方式适合快速拿到一批看起来像真实用户提问的问题缺点是生成成本较高且如果文档本身质量差生成的问题可能会比较奇怪。路径二从真实用户日志构造如果系统已经在线上跑了一段时间直接从日志里抽取用户真实提问再做人工标注或半自动标注。真实问题往往比合成问题更能体现系统在业务中的短板我在项目里的实测感受是真实问题构成的测试集评估结果对后续优化的指导意义更强。建议两条腿走路真实问题作为主干合成问题做补充。3.3 多少条测试数据才够用这个问题经常有人问但说实话没有标准答案。我的经验是10条以下统计波动太大只能做冒烟验证20-30条能看出相对趋势适合快速对比两个版本想得到比较稳定的分数、支撑上线决策至少50条以上。不过要注意RAGAS的每个指标都会有置信区间置信度较低时会在报告里提示如果你看到分数旁边跟着low confidence之类的标记就说明测试样本量太小别急着下结论。另外测试集也不是越复杂越好。里面应该有简单的问题也应该有跨章节推理的问题占比要贴近你业务的实际分布否则评估结果会有偏。4. 完整实战从加载文档到输出第一份评估报告4.1 最小可运行示例拿到分数RAGAS的evaluate()函数接受一个Hugging Face Dataset对象包含四个字段question问题、answer系统回答、contexts检索到的上下文列表、ground_truth标准答案。最小示例长这样from datasets import Dataset from ragas import evaluate from ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall, ) dataset Dataset.from_dict({ question: [这个产品的保修期是多久], answer: [该产品提供两年的质保服务。], contexts: [[产品自购买之日起享受24个月保修服务期间非人为损坏可免费维修。]], ground_truth: [该产品保修期为两年。], }) results evaluate( dataset, metrics[faithfulness, answer_relevancy, context_precision, context_recall] ) print(results)你需要在环境变量中配置OPENAI_API_KEY因为默认使用OpenAI模型作为裁判。跑完之后results里会有每个指标的总分也可以拿到单个样本的明细分数。第一次跑通后建议先看单个样本的明细别急着看总分——明细是定位具体问题最重要的抓手。4.2 接入自己的RAG管道以LangChain为例实际项目里不会手动构造字典而是要接进自己的RAG管道。我以LangChain为例说一下接入方式。核心思路是在原有管道的检索和生成之间插入数据采集。先准备好一批测试问题逐个调用管道把answer最终回答和contexts检索器返回的文档列表收集起来再组装成Dataset传给RAGAS。from datasets import Dataset from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy questions [这个产品的保修期是多久, ...] answers [] contexts_list [] for q in questions: # 假设已有 RAG 管道实例 result rag_pipeline.invoke(q) answers.append(result[answer]) # 取出检索到的文档内容列表 contexts_list.append([doc.page_content for doc in result[context]]) dataset Dataset.from_dict({ question: questions, answer: answers, contexts: contexts_list, ground_truth: ground_truth_list, }) results evaluate( dataset, metrics[faithfulness, answer_relevancy, context_precision, context_recall], )这里有个关键点容易被忽略contexts必须和RAG管道实际喂给LLM的上下文一致要么直接取检索器的返回要么取被LLM真正使用的那部分不能自己另外跑一个检索。否则你评估的就不是你的系统而是你想象中的一个理想系统。4.3 读懂报告评估结果怎么指导优化拿到分数不是终点对分数的正确解读才是关键。我举个实际例子。假设我的评估报告长这样指标分数Faithfulness0.85Answer Relevancy0.76Context Precision0.62Context Recall0.48Faithfulness有0.85说明模型基本在照本宣科没有大范围幻觉。Context Recall只有0.48说明有大量该检索到的信息漏掉了——问题大概率出在检索环节的召回能力上优先去调Embedding模型、切块策略、相似度阈值。Context Precision是0.62说明检索结果里掺杂了不少无关内容可能要在重排reranking上做文章。Answer Relevancy在0.76左右在Recall和Precision都不高的情况下这个分数其实已经不低了。有了这样的优先级就不至于拍脑袋改系统。一次只改一个变量重跑评估看对应指标的变化这个闭环是整个评估工作真正的价值所在。5. 我踩过的坑RAGAS实际使用中那些意想不到的问题5.1 LLM裁判不稳定同一组数据两次分数差别大RAGAS依赖LLM做裁判而LLM天然有随机性这导致同一个测试集跑两次分数可能出现几个百分点的波动。我第一次遇到时还以为是代码写错了排查了半天。解决思路主要有两个一是重复运行取平均比如同一组评估跑3次取Faithfulness等指标的平均值再用于对比二是设置较低的temperature比如0或接近0降低裁判模型的输出随机性。注意不能完全消除波动所以做版本对比时要在同一批次跑。我习惯把基线版本和新版本放进同一个evaluate()里跑保证所有样本使用同一轮裁判判断相对差距的可靠性高很多。5.2 Embedding模型和中英文混排对评估的影响RAGAS使用Embedding相似度计算Answer Relevancy所以Embedding模型的选择直接影响这个指标。如果你的业务数据是中英文混排一定要用对中英双语都有良好支持的Embedding模型不然伪问题和原问题的向量相似度可能整体失真。另一个细节是评估用的Embedding模型最好和业务检索用的Embedding模型区分开。业务Embedding要按检索效果选评估Embedding要按语义区分能力和语言支持选。混在一起用指标和业务耦合过深不利于定位问题。5.3 切块策略如何间接影响评估分数切块chunking是RAG系统的第一公里它的影响会传导到评估指标。我做过一组对比实验同样的文档和数据只是切块大小从256字符调整为512字符Context Recall提升了近10个百分点而Context Precision有轻微下降。原因是更大的chunk能覆盖更完整的信息降低了被切断导致的信息不完整概率但也引入了更多不相关内容。所以评估结果不是单纯告诉你现在好不好它还能帮你验证切块策略的取舍是否正确。在业务调优时我会把是否修改切块策略作为和是否更换Embedding同级的调优选项来考虑。5.4 多轮对话、Agent场景怎么评估RAGAS的核心指标主要面向单轮问答。我在多轮、Agent场景下用过一段时间经验是完全套用会得出失真的结论。多轮问题里上下文是动态累积的上一轮的检索结果会影响当前轮的生成。RAGAS单轮指标无法追踪这种链路。Agent场景更复杂可能有工具调用、状态跳转。RAGAS社区已经陆续在扩展多轮评估能力新增了面向Agent链路的评估指标但整体成熟度还在演化中。如果你做的是多轮RAG一个相对务实的过渡方案是把每一轮问答拆开当成一个独立的单轮样本去评估记录第几轮标签分轮次统计。这样虽然粒度粗糙一些但至少能看出对话变长后质量是否衰减。5.5 评估成本控制用LLM当裁判是有Token成本的。每个指标每次评估都会多次调用LLM测试集50条、4个指标跑一轮下来花费并不低。我在项目里做了几件事来控制成本日常开发调试阶段只用10-15条样本只跑Faithfulness和Answer Relevancy两个生成侧指标快速验证管道是否工作。阶段版本发布前或调参对比时才跑全量指标和全量测试集。数据变化大的情况下优先用演进式测试集的子集而不是每次都重新生成全部测试集。这样操作下来评估成本完全在可控范围内尤其是在更换了更便宜的裁判模型之后成本已经是我几乎不用再关心的问题。最后再分享一个小技巧RAGAS的单样本明细一定要留存下来。每次评估完把分数低的样本连同对应的上下文、回答、裁判判断过程一起记录到本地日积月累就会形成一份非常有价值的错误案例库。后续无论是调Prompt、换Embedding还是优化重排第一件事永远是回头翻这份案例库——它能直接告诉你系统最痛的点在哪里比任何指标都直观。