RAG 系统上线前最大的坑是demo 能过、生产翻车问三个问题都答得漂亮一上真实流量就暴露——检索召回错文档、回答里混入上下文没有的信息、用户换个问法直接答非所问。根因是大多数团队把 RAG 当普通 CRUD 应用测只验证接口通不通从不量化答得对不对。本文用 Ragas 搭一套可落地的 RAG 评测体系检索侧看 context precision / context recall生成侧看 faithfulness忠实度与 answer relevancy再叠加 noise sensitivity噪声敏感度把感觉还行变成一组可对比、可设门禁的数字。选 Ragas 而不是自研评判器原因有三它的忠实度指标基于 NLI自然语言推理判定而非简单关键词匹配能识别上下文没有但回答编造的幻觉检索侧指标按位置加权能定位召回对了但排太靠后这类检索排序问题内置测试集生成器TestsetGenerator没有标注人力也能起步。同类工具对比工具定位强项适合场景RagasRAG 深度评测NLI 忠实度、检索指标、测试集生成RAG 系统上线评估、检索优化迭代DeepEvalLLM 应用通用评测G-Eval 自定义指标、pytest 集成单轮问答/生成类应用、CI 集成promptfooPrompt/Agent 回归YAML 配置、prompt 版本对比、红队Prompt 迭代回归、多模型对比自研 LLM-as-judge高度定制贴合业务口径有评测团队、指标口径独特时指标拆解每个分数到底在算什么faithfulness忠实度回答有没有编造把模型回答拆成若干 claims断言逐条判断能否从检索到的上下文中推出能推出的占比就是 faithfulness。实现上常用 NLI 模型或 LLM-as-judge 做蕴含判定。这条指标直接对应幻觉上下文没提支持7天无理由退货回答里写了该 claim 判为不忠实分数被拉低。注意它只约束与上下文一致不约束上下文本身对不对——所以必须和检索侧指标一起看。context_precision / context_recall检索命中率context_precision对每个检索回来的 chunk 判断是否与问题相关按位置加权——排在前面的相关 chunk 权重更高。这个指标能暴露检索结果里混着无关文档或相关文档排太靠后的问题直接关联 chunk 切分粒度、embedding 模型、top-k 设置。context_recall以参考答案为基准看参考答案中的关键信息有多少能从检索上下文中找到证据。它衡量该召回的有没有召回全上下文切太碎或 embedding 不匹配时这里先掉分。noise_sensitivity噪声敏感度检索混入无关 chunk 时回答质量受多大影响。把评测集中的上下文替换成带噪声的版本再测一遍分数掉得越多说明系统对噪声越敏感。敏感度高通常意味着 prompt 缺少只依据给定上下文作答的硬约束或者重排rerank没起作用。RAG 应用最容易在这条指标上翻车检索召回 5 个 chunk只有 2 个相关模型照样把另外 3 个里的内容缝进回答。answer_relevancy回答与问题的相关程度。答非所问、答了一堆通用套话都会在这里暴露。它和 faithfulness 是正交的相关但编造faithfulness 低或者忠实但跑题relevancy 低都要分别处理。落地代码完整评估脚本import os from ragas import evaluate from ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall, noise_sensitivity, ) # 单条样本结构问题、检索到的上下文、模型回答、参考答案 # 参考答案只用于 context_recall 等指标线上评估可从生产日志抽样后人工标注 samples [ { user_input: 我们公司的报销流程是什么, retrieved_contexts: [ 报销需在每月25日前提交OA审批并附发票原件。, 差旅报销额度高铁二等座住宿每晚不超过500元。, ], response: 报销需在每月25日前提交OA审批附发票原件。住宿每晚不超过500元。, reference: 报销需在每月25日前提交OA审批附发票原件住宿额度每晚500元。, }, # ... 实际评估 50~200 条 ] result evaluate( datasetsamples, metrics[ faithfulness, answer_relevancy, context_precision, context_recall, noise_sensitivity, ], ) print(result) # 各指标总分 逐条明细哪个样本哪条指标挂了跑完看两样东西总分用于趋势对比逐条明细用于定位问题样本。只报总分不查明细等于白测——评测的价值在失败样本里。自定义业务指标DeepEval G-Eval通用指标覆盖不了业务口径时用 G-Eval 自定义。比如客服场景要单独盯是否给出了可执行的下一步动作from deepeval.metrics import GEval from deepeval.test_case import LLMTestCase actionable GEval( name可执行性, criteria回答必须给出用户当下能直接执行的下一步动作否则扣分, evaluation_steps[ 提取用户问题的核心诉求, 检查回答是否包含明确、可执行的动作时间/路径/条件, 若只给解释不给动作得分不超过3满分5, ], modelgpt-4o, ) case LLMTestCase( input发票丢了还能报销吗, actual_output可以但需要写情况说明并由部门负责人签字确认。, retrieval_context[发票丢失需提交书面情况说明经部门负责人签字后可报销。], ) actionable.evaluate(case)自定义指标的口径要写成步骤而不是一句笼统标准LLM-as-judge 才能稳定复现。同一组 evaluation_steps 跑两遍结果波动超过 0.5 分说明口径写得太模糊。Prompt 回归门禁promptfooRAG 系统迭代最频繁的是 prompt。每次改 prompt 都全量回归不现实用固定测试集 门禁断言# promptfooconfig.yaml prompts: - prompts/rag_v2.txt - prompts/rag_v3.txt providers: - id: openai:gpt-4o config: tools: [rag_retriever] # 挂真实检索链路 tests: ../../eval_sets/rag_cases.yaml assert: - type: llm-rubric value: 回答必须只基于提供的上下文不得编造上下文之外的信息 - type: contains-any value: [提交OA审批, 25日前]实践中的坑判分模型与被测模型同源分数会虚高。GPT 判 GPT 有自我偏好忠实度普遍虚高 0.05~0.1。评测集不大时这点虚高足以掩盖一次真实回归。至少让判分模型与被测模型不同源或定期抽 20 条人工复核校准偏差。faithfulness 对长回答不敏感。回答越长 claims 越多单条严重编造被稀释。生产环境建议对关键 claim涉及金额、时间、操作路径的断言单独统计错误率而不是只看总分。context_recall 依赖参考答案质量。参考答案写得太简略recall 虚高写得太细recall 虚低。参考答案统一按覆盖问题所需全部关键事实的标准写且由同一人/同一规范产出。评测集少于 30 条没有统计意义。指标波动 ±0.1 很常见30 条以下无法区分是回归还是噪声。起步 50 条稳定后扩到 200 条线上从生产日志随机抽样 人工标注比纯合成数据更接近真实分布。成本控制。200 条样本 × 5 个指标用 gpt-4o 判分单次约 5~8 美元日常回归用便宜模型如 gpt-4o-mini 级别跑全量发现问题再用强模型复核。先小样本验证指标稳定性再放量。阈值经验值按 100 条评测集指标健康区间低于阈值时的排查方向faithfulness≥ 0.85检查 prompt 是否有只依据上下文约束、检索是否混入噪声context_precision≥ 0.7chunk 切分粒度、embedding 模型、top-k、是否缺 rerankcontext_recall≥ 0.8索引切分是否丢失信息、embedding 与问题域匹配度noise_sensitivity≤ 0.2加强 prompt 约束、上 rerank、过滤低分 chunkanswer_relevancy≥ 0.8问题理解、query 改写、指令跟随评测体系长什么样测试集(50-200条) ──► RAG 应用(检索生成) ──► {question, contexts, response} │ ▼ 指标计算 (LLM-as-judge / NLI) │ ▼ 报告: 各指标分数 失败样本明细 错误分类 │ ▼ CI 门禁: faithfulness 0.85 / precision 0.7 → 阻断合并接 CI 时建议告警先行、门禁后置先跑两周观察指标自然波动范围再按均值 - 2σ设硬门禁避免指标本身的抖动天天打断发布。进阶方向Agent 评测RAG 升级成多步 Agent 后指标从单轮回答质量扩展到轨迹正确性、工具调用成功率、中间步骤成本Ragas 与 DeepEval 都在补这块能力生产数据回流线上日志 → 自动聚类失败案例 → 扩充评测集形成评测集越用越准的闭环评测集版本化测试集本身要纳入版本管理换测试集后分数不可跨版本对比RAG 评测的底线是每个指标都要能回答这个数字变差意味着系统哪里坏了。数字本身没有价值定位问题的能力才有。如果你也在做 AI 应用RAG / Agent / LLM不知道质量怎么测——我最近在给 AI 应用做免费质量体检出一份可执行的测评报告检索命中率、回答忠实度、噪声敏感度等维度感兴趣可以直接私信我。 RAG 质量评测：用 Ragas 量化检索命中率、回答忠实度与噪声敏感度
RAG 系统上线前最大的坑是demo 能过、生产翻车问三个问题都答得漂亮一上真实流量就暴露——检索召回错文档、回答里混入上下文没有的信息、用户换个问法直接答非所问。根因是大多数团队把 RAG 当普通 CRUD 应用测只验证接口通不通从不量化答得对不对。本文用 Ragas 搭一套可落地的 RAG 评测体系检索侧看 context precision / context recall生成侧看 faithfulness忠实度与 answer relevancy再叠加 noise sensitivity噪声敏感度把感觉还行变成一组可对比、可设门禁的数字。选 Ragas 而不是自研评判器原因有三它的忠实度指标基于 NLI自然语言推理判定而非简单关键词匹配能识别上下文没有但回答编造的幻觉检索侧指标按位置加权能定位召回对了但排太靠后这类检索排序问题内置测试集生成器TestsetGenerator没有标注人力也能起步。同类工具对比工具定位强项适合场景RagasRAG 深度评测NLI 忠实度、检索指标、测试集生成RAG 系统上线评估、检索优化迭代DeepEvalLLM 应用通用评测G-Eval 自定义指标、pytest 集成单轮问答/生成类应用、CI 集成promptfooPrompt/Agent 回归YAML 配置、prompt 版本对比、红队Prompt 迭代回归、多模型对比自研 LLM-as-judge高度定制贴合业务口径有评测团队、指标口径独特时指标拆解每个分数到底在算什么faithfulness忠实度回答有没有编造把模型回答拆成若干 claims断言逐条判断能否从检索到的上下文中推出能推出的占比就是 faithfulness。实现上常用 NLI 模型或 LLM-as-judge 做蕴含判定。这条指标直接对应幻觉上下文没提支持7天无理由退货回答里写了该 claim 判为不忠实分数被拉低。注意它只约束与上下文一致不约束上下文本身对不对——所以必须和检索侧指标一起看。context_precision / context_recall检索命中率context_precision对每个检索回来的 chunk 判断是否与问题相关按位置加权——排在前面的相关 chunk 权重更高。这个指标能暴露检索结果里混着无关文档或相关文档排太靠后的问题直接关联 chunk 切分粒度、embedding 模型、top-k 设置。context_recall以参考答案为基准看参考答案中的关键信息有多少能从检索上下文中找到证据。它衡量该召回的有没有召回全上下文切太碎或 embedding 不匹配时这里先掉分。noise_sensitivity噪声敏感度检索混入无关 chunk 时回答质量受多大影响。把评测集中的上下文替换成带噪声的版本再测一遍分数掉得越多说明系统对噪声越敏感。敏感度高通常意味着 prompt 缺少只依据给定上下文作答的硬约束或者重排rerank没起作用。RAG 应用最容易在这条指标上翻车检索召回 5 个 chunk只有 2 个相关模型照样把另外 3 个里的内容缝进回答。answer_relevancy回答与问题的相关程度。答非所问、答了一堆通用套话都会在这里暴露。它和 faithfulness 是正交的相关但编造faithfulness 低或者忠实但跑题relevancy 低都要分别处理。落地代码完整评估脚本import os from ragas import evaluate from ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall, noise_sensitivity, ) # 单条样本结构问题、检索到的上下文、模型回答、参考答案 # 参考答案只用于 context_recall 等指标线上评估可从生产日志抽样后人工标注 samples [ { user_input: 我们公司的报销流程是什么, retrieved_contexts: [ 报销需在每月25日前提交OA审批并附发票原件。, 差旅报销额度高铁二等座住宿每晚不超过500元。, ], response: 报销需在每月25日前提交OA审批附发票原件。住宿每晚不超过500元。, reference: 报销需在每月25日前提交OA审批附发票原件住宿额度每晚500元。, }, # ... 实际评估 50~200 条 ] result evaluate( datasetsamples, metrics[ faithfulness, answer_relevancy, context_precision, context_recall, noise_sensitivity, ], ) print(result) # 各指标总分 逐条明细哪个样本哪条指标挂了跑完看两样东西总分用于趋势对比逐条明细用于定位问题样本。只报总分不查明细等于白测——评测的价值在失败样本里。自定义业务指标DeepEval G-Eval通用指标覆盖不了业务口径时用 G-Eval 自定义。比如客服场景要单独盯是否给出了可执行的下一步动作from deepeval.metrics import GEval from deepeval.test_case import LLMTestCase actionable GEval( name可执行性, criteria回答必须给出用户当下能直接执行的下一步动作否则扣分, evaluation_steps[ 提取用户问题的核心诉求, 检查回答是否包含明确、可执行的动作时间/路径/条件, 若只给解释不给动作得分不超过3满分5, ], modelgpt-4o, ) case LLMTestCase( input发票丢了还能报销吗, actual_output可以但需要写情况说明并由部门负责人签字确认。, retrieval_context[发票丢失需提交书面情况说明经部门负责人签字后可报销。], ) actionable.evaluate(case)自定义指标的口径要写成步骤而不是一句笼统标准LLM-as-judge 才能稳定复现。同一组 evaluation_steps 跑两遍结果波动超过 0.5 分说明口径写得太模糊。Prompt 回归门禁promptfooRAG 系统迭代最频繁的是 prompt。每次改 prompt 都全量回归不现实用固定测试集 门禁断言# promptfooconfig.yaml prompts: - prompts/rag_v2.txt - prompts/rag_v3.txt providers: - id: openai:gpt-4o config: tools: [rag_retriever] # 挂真实检索链路 tests: ../../eval_sets/rag_cases.yaml assert: - type: llm-rubric value: 回答必须只基于提供的上下文不得编造上下文之外的信息 - type: contains-any value: [提交OA审批, 25日前]实践中的坑判分模型与被测模型同源分数会虚高。GPT 判 GPT 有自我偏好忠实度普遍虚高 0.05~0.1。评测集不大时这点虚高足以掩盖一次真实回归。至少让判分模型与被测模型不同源或定期抽 20 条人工复核校准偏差。faithfulness 对长回答不敏感。回答越长 claims 越多单条严重编造被稀释。生产环境建议对关键 claim涉及金额、时间、操作路径的断言单独统计错误率而不是只看总分。context_recall 依赖参考答案质量。参考答案写得太简略recall 虚高写得太细recall 虚低。参考答案统一按覆盖问题所需全部关键事实的标准写且由同一人/同一规范产出。评测集少于 30 条没有统计意义。指标波动 ±0.1 很常见30 条以下无法区分是回归还是噪声。起步 50 条稳定后扩到 200 条线上从生产日志随机抽样 人工标注比纯合成数据更接近真实分布。成本控制。200 条样本 × 5 个指标用 gpt-4o 判分单次约 5~8 美元日常回归用便宜模型如 gpt-4o-mini 级别跑全量发现问题再用强模型复核。先小样本验证指标稳定性再放量。阈值经验值按 100 条评测集指标健康区间低于阈值时的排查方向faithfulness≥ 0.85检查 prompt 是否有只依据上下文约束、检索是否混入噪声context_precision≥ 0.7chunk 切分粒度、embedding 模型、top-k、是否缺 rerankcontext_recall≥ 0.8索引切分是否丢失信息、embedding 与问题域匹配度noise_sensitivity≤ 0.2加强 prompt 约束、上 rerank、过滤低分 chunkanswer_relevancy≥ 0.8问题理解、query 改写、指令跟随评测体系长什么样测试集(50-200条) ──► RAG 应用(检索生成) ──► {question, contexts, response} │ ▼ 指标计算 (LLM-as-judge / NLI) │ ▼ 报告: 各指标分数 失败样本明细 错误分类 │ ▼ CI 门禁: faithfulness 0.85 / precision 0.7 → 阻断合并接 CI 时建议告警先行、门禁后置先跑两周观察指标自然波动范围再按均值 - 2σ设硬门禁避免指标本身的抖动天天打断发布。进阶方向Agent 评测RAG 升级成多步 Agent 后指标从单轮回答质量扩展到轨迹正确性、工具调用成功率、中间步骤成本Ragas 与 DeepEval 都在补这块能力生产数据回流线上日志 → 自动聚类失败案例 → 扩充评测集形成评测集越用越准的闭环评测集版本化测试集本身要纳入版本管理换测试集后分数不可跨版本对比RAG 评测的底线是每个指标都要能回答这个数字变差意味着系统哪里坏了。数字本身没有价值定位问题的能力才有。如果你也在做 AI 应用RAG / Agent / LLM不知道质量怎么测——我最近在给 AI 应用做免费质量体检出一份可执行的测评报告检索命中率、回答忠实度、噪声敏感度等维度感兴趣可以直接私信我。