RAG 系统上线三个月用户反馈有时候答得挺好有时候胡说。最要命的是你没法跟老板解释有时候是多少。检索质量、生成质量、幻觉比例全凭体感。后来我把 RAGAS 这套指标context_precision / context_recall / faithfulness / answer_relevancy接进了评测管线每个版本发布前跑一轮 golden set 回归效果立竿见影上线前就能发现检索召回掉了 12 个点而不是等用户骂完才发现。这篇文章把四个指标的实现原理、评测管线的搭建、以及跑了半年踩过的坑一次说清楚。为什么选 RAGAS 而不是自己写评估自建评估最大的坑是你以为你在测质量其实你在测 prompt 的措辞。自己定义指标本质上就是写一个 LLM-as-judge但 judge 的判定标准、输出格式、打分逻辑全是拍脑袋换个说法结果就漂。RAGAS 的价值在于指标定义贴近生产语义忠实度、召回、精度判定 prompt 经过社区大量调优且开源可审计——不满意可以改 prompt而不是从零发明。DeepEval、TruLens 也都看过RAGAS 在检索评估这个维度上定义最细下文细说跟 LangChain / LlamaIndex 生态集成也顺。四个指标各自的实现原理先理解每个指标到底在算什么这决定了你拿到分数后怎么解读。context_precision上下文精度衡量检索结果里有用的片段排得多靠前。做法是让 LLM 对每个检索片段逐个判定是否与问题相关输出 VERDICT再按位置加权求和——排在前面的相关片段权重高。它直接对应用户翻到第几条才看到正确答案的体验。context_recall上下文召回衡量检索结果有没有漏掉关键信息。做法是从参考答案里用 LLM 抽取原子事实claims再逐个判定每个 claim 是否被检索上下文覆盖。这个指标的上限由你的参考答案质量决定——参考答案本身不全召回永远上不去。faithfulness忠实度衡量生成答案有没有编。做法是从生成答案里抽取 claims再逐个判定每个 claim 是否被检索上下文支持。不支持的 claim 就是幻觉。这是判断胡说的硬指标比人工抽查可靠得多。answer_relevancy答案相关性衡量答案是否答非所问。做法是让 LLM 从答案反推若干问题再算这些问题与原问题的 embedding 相似度。注意它只测相关性不测正确性分数高不代表答对了。一句话总结四个指标的分工precision 和 recall 管检索faithfulness 管幻觉answer_relevancy 管跑题。检索挂了还是生成挂了看指标组合就能定位。评测管线的架构单跑一个脚本出分数没有意义评测要进管线才有效果golden set人工标注覆盖核心场景 │ ▼ 批量执行 RAG固定 retriever generator 配置 │ ▼ 指标计算RAGASLLM-as-judge │ ▼ 报告 回归门禁P50/P90 对比基线超阈值 CI 拦截关键点golden set 必须人工标注每条包含 question、reference标准答案、以及可选的 reference_contexts。合成数据只能做补充不能替代人工——后面踩坑部分会说为什么。代码实践RAGAS 0.4.x 评测脚本注意 RAGAS 0.3 之后 API 大改过metric 从模块级对象变成了类实例evaluate的签名也变了。网上大量 0.2 的教程直接跑会报TypeError。下面这段基于 0.4.3# pip install ragas0.4.3 langchain-openai import json from ragas import EvaluationDataset, evaluate from ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall, ) from ragas.llms import LangchainLLMWrapper from ragas.embeddings import LangchainEmbeddingsWrapper from langchain_openai import ChatOpenAI, OpenAIEmbeddings # 1. 准备 golden set每条含 question / answer / reference / retrieved_contexts samples [ { user_input: 订单状态同步失败后重试机制最多执行几次, response: 最多重试 3 次每次间隔指数退避3 次后进入死信队列。, reference: 订单同步失败后触发重试上限 3 次采用指数退避策略超限进入死信队列等待人工处理。, retrieved_contexts: [ 重试机制默认上限为 3 次间隔按指数退避递增。, 超过重试上限的消息会写入死信队列由运维人工处理。, ], }, # ... 至少 30~100 条覆盖核心场景 边界 case ] dataset EvaluationDataset.from_list(samples) # 2. judge 模型单独配置建议固定一个别换来换去 llm LangchainLLMWrapper(ChatOpenAI(modelgpt-4o, temperature0)) emb LangchainEmbeddingsWrapper(OpenAIEmbeddings(modeltext-embedding-3-small)) # 3. 跑指标raise_exceptionsFalse 防止单条失败中断全量 result evaluate( datasetdataset, metrics[context_precision(), context_recall(), faithfulness(), answer_relevancy()], llmllm, embeddingsemb, raise_exceptionsFalse, ) df result.to_pandas() print(df[[user_input, context_precision, context_recall, faithfulness, answer_relevancy]].describe())跑完看分布而不是看均值df[faithfulness].quantile([0.5, 0.9])。P50 反映典型水平P90 反映最差那批——上线拦的是 P90不是 P50。噪声敏感度自己补的测试RAGAS 经典四件套里没有直接的噪声敏感度指标但这个维度很重要检索系统抽风返回一堆无关片段时你的生成会不会被带偏做法是主动注入噪声做对比实验import copy def inject_noise(sample, noise_chunks, ratio0.5): 往检索上下文里掺入无关片段模拟检索召回质量劣化 s copy.deepcopy(sample) n max(1, int(len(s[retrieved_contexts]) * ratio)) s[retrieved_contexts] s[retrieved_contexts] noise_chunks[:n] return s noise_chunks [ 无关系统部署要求最低 8 核 16G 内存。, 无关客服工单的 SLA 是 4 小时响应。, ] noisy [inject_noise(s, noise_chunks) for s in samples] noisy_result evaluate(datasetEvaluationDataset.from_list(noisy), metrics[...], ...) # 对比faithfulness 掉 10 个点 生成被噪声带偏需要加固 prompt 约束这个实验能直接回答检索召回劣化到 50% 时用户体感会差多少是给老板看的最有说服力的一张图。踩坑记录坑现象解法judge 模型换来换去分数漂移 10 个点无法对比版本judge 模型、prompt 全部锁定只动被测系统参考答案偷懒context_recall 永远 60 分上不去参考答案按原子事实标准写全缺一条漏一条只看均值单条幻觉被平均掩盖看 P50/P90 分布 单独统计 faithfulness0.8 的样本中文评测用默认 prompt判定结果不稳定自定义 judge prompt 中文化明确判定标准检索/生成一起改出问题不知道怪谁固定 generator 测检索固定 retriever 测生成分开回归RAGAS 版本升级API 报错、指标结果不可比锁版本进 requirements升级前先跑基线对比成本也要算4 个指标跑 100 条样本LLM 调用量大约 1000~1500 次precision 每条按检索片段数多次调用faithfulness/recall 各含 claim 抽取 逐条判定。用 GPT-4o 单轮评估成本在 3~5 美元量级可接受要压成本就把 judge 换成能力够用的开源模型比如 Qwen 系列但换完必须重新定基线。工具怎么选工具定位适合场景RAGAS指标定义最细检索评估强离线 golden set 回归RAG 专项评测DeepEval测试框架感强Pytest 集成好想写用例即代码的团队TruLens在线反馈回路 可视化需要 tracing 和线上监测LangSmith全链路 tracing 评测已经深度用 LangChain 的团队我的建议离线回归用 RAGAS 打底线上监测接 TruLens/LangSmith 看实时漂移两者互补不冲突。总结与进阶方向评测这件事投入产出比最高的顺序是先建 50 条高质量 golden set → 跑通 RAGAS 四件套 → 定 P90 基线 → 接 CI 回归门禁。做完这四步RAG 的质量就从体感变成了数字。进阶方向三个一是自定义 judge prompt让判定标准贴合你的业务比如区分轻微不准确和严重幻觉二是用合成数据扩 golden setLLM 生成 人工抽检把覆盖场景从 50 条扩到 500 条三是把线上用户反馈点赞/点踩回流成在线评测信号做持续监测。如果你也在做 AI 应用RAG / Agent / LLM不知道质量怎么测——我最近在给 AI 应用做免费质量体检出一份可执行的测评报告检索命中率、回答忠实度、噪声敏感度等维度感兴趣可以直接私信我。
