RAG上线后最常见的翻车现场检索回来的文档和问题八竿子打不着生成模型再强也只能一本正经地胡说。检索质量决定生成质量的下限——但绝大多数团队只测了接口通不通、响应快不快没人系统地测检索。本文给出一个可落地的RAG测试体系检索层用 Recallk / MRR / NDCG 做离线量化生成层用 LLM-as-Judge 评 Faithfulness 和 Answer Relevancy最后用 RAGAS 把整套流程固化下来接进 CI 做回归。检索层先量化找没找对RAG 的检索本质是一个排序问题给定 query系统从知识库召回 top-k 文档。测试它的方式和传统搜索引擎评测一脉相承核心是黄金数据集golden dataset一批人工标注的(query, 相关文档ID列表)对。有了标注三个指标就能算指标计算方式看什么Recallktop-k 中相关文档数 / 总相关文档数有没有漏召回Hit Ratetop-k 是否至少命中1个相关文档用户问题能否被回答MRR第一个相关文档排名的倒数相关文档排得多靠前实现不复杂几十行 Pythondef recall_at_k(retrieved_ids, relevant_ids, k): top_k set(retrieved_ids[:k]) return len(top_k relevant_ids) / len(relevant_ids) def hit_rate(retrieved_ids, relevant_ids, k): return 1.0 if set(retrieved_ids[:k]) relevant_ids else 0.0 def mrr(retrieved_ids, relevant_ids): for rank, doc_id in enumerate(retrieved_ids, 1): if doc_id in relevant_ids: return 1.0 / rank return 0.0实测经验别只报一个 k。业务上问答场景看 Hit Rate3知识库检索场景看 Recall10汇报时把 k1/3/5/10 全打出来趋势比绝对值有用。embedding 模型换版、chunk 大小调整、reranker 引入都是靠这几个数决定去留。另一个容易漏的维度是检索延迟分布向量检索的 p99 在数据量过千万后常从 20ms 飙到 200msHNSW 的 ef_search 参数就是拿召回率换延迟建议把 recallk 和 p99 画在同一张图上选参。生成层用 LLM 评 LLM检索对了不代表回答对。生成质量有两个核心指标Faithfulness忠实度回答中的每个事实点是否都能在检索到的上下文中找到依据。防幻觉的直接度量。Answer Relevancy答案相关性回答是否切题有没有答非所问、绕圈子。这两个指标没法用规则算——答案的语义相关性必须靠模型判断这就是LLM-as-Judge用一个强模型当裁判给评估 prompt让它按标尺打分。裁判 prompt 的写法直接决定评分质量关键是把标尺定义死你是严谨的评测员。判断以下回答中的每个陈述是否能由给定上下文直接支撑。 评分标准 - 1分回答存在明显的事实编造或与上下文矛盾 - 3分部分陈述有依据但存在推断过度或细节错误 - 5分所有陈述均可由上下文直接支撑无任何编造 只输出分数和一句理由格式{score: n, reason: ...}注意两个细节一是必须要求输出理由纯分数会让模型偷懒走捷径二是分数锚点要少3档就够5档以上模型自己都分不清边界评分方差会显著变大。RAGAS把评估工程化手动实现指标 自己写 judge prompt 能跑通但维护成本高。开源框架 RAGASexplodinggradients/ragas把上面这套打包好了检索指标和生成指标都内置from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall from datasets import Dataset eval_data Dataset.from_dict({ question: [退货政策是什么], answer: [支持7天无理由退货运费由买家承担。], contexts: [[根据《退货政策》第3条自签收之日起7天内可无理由退货。]], ground_truth: [签收后7天内可无理由退货。], }) result evaluate( eval_data, metrics[faithfulness, answer_relevancy, context_precision, context_recall], ) print(result.to_pandas())RAGAS 的 context_precision / context_recall 对应检索层质量contexts 里有多少有用信息、该召回的全没全faithfulness / answer_relevancy 对应生成层质量正好覆盖全链路。跑完会输出每个样本的分 整体均值直接落 CSV 归档。踩坑记录这套体系跑了大半年坑集中在三个地方1. Judge 模型自己的偏差。位置偏差答案越长分越低、长度偏差越长分越高、自偏好Claude 评 Claude 给分虚高。解法同一批样本用两个不同厂商的模型交叉打分只保留两模型都判定为 3 分以下的样本进问题清单打分 prompt 里明确忽略回答长度只评事实依据。2. 黄金数据集污染。标注样本一旦被写进知识库比如标注时把参考文档直接塞回了库指标会虚高到失去意义。黄金数据集要独立存放、独立版本管理评估时从知识库里排除这些文档。3. 指标漂移的误报。换 embedding 模型后 faithfulness 掉 2 个点先别急着回滚——先查是不是 judge prompt 里上下文格式变了RAGAS 对 contexts 的拼接顺序敏感再查样本里是否混入了知识库更新后的旧标注。指标先校准、后对比这个顺序不能反。还有一个工程建议评估集 100 条样本就够看出趋势不用追求上千条——LLM 打分成本高且 100 条 × 4 指标已经能稳定区分明显变差和噪声波动。总结与进阶方向一套可用的 RAG 质量测试体系 检索层离线指标Recallk/MRR/Hit Rate 生成层 LLM-as-JudgeFaithfulness/Answer Relevancy RAGAS 工程化封装 黄金数据集版本管理。这套东西接进 CI 后每次改 chunk 策略、换 embedding、调 reranker 都能在合并前看到质量影响把感觉变好了变成指标证明变好了。进阶方向有三条一是在线评估用用户反馈、追问率、复制行为等隐式信号做线上质量监控补离线指标的盲区二是评估集自动扩充用 badcase 聚类 人工抽检的半自动方式降低标注成本三是把 judge 换成更便宜的蒸馏小模型做预筛只有低分样本才上调大模型复核把评估成本再压一个量级。
RAG上线后最常见的翻车现场检索回来的文档和问题八竿子打不着生成模型再强也只能一本正经地胡说。检索质量决定生成质量的下限——但绝大多数团队只测了接口通不通、响应快不快没人系统地测检索。本文给出一个可落地的RAG测试体系检索层用 Recallk / MRR / NDCG 做离线量化生成层用 LLM-as-Judge 评 Faithfulness 和 Answer Relevancy最后用 RAGAS 把整套流程固化下来接进 CI 做回归。检索层先量化找没找对RAG 的检索本质是一个排序问题给定 query系统从知识库召回 top-k 文档。测试它的方式和传统搜索引擎评测一脉相承核心是黄金数据集golden dataset一批人工标注的(query, 相关文档ID列表)对。有了标注三个指标就能算指标计算方式看什么Recallktop-k 中相关文档数 / 总相关文档数有没有漏召回Hit Ratetop-k 是否至少命中1个相关文档用户问题能否被回答MRR第一个相关文档排名的倒数相关文档排得多靠前实现不复杂几十行 Pythondef recall_at_k(retrieved_ids, relevant_ids, k): top_k set(retrieved_ids[:k]) return len(top_k relevant_ids) / len(relevant_ids) def hit_rate(retrieved_ids, relevant_ids, k): return 1.0 if set(retrieved_ids[:k]) relevant_ids else 0.0 def mrr(retrieved_ids, relevant_ids): for rank, doc_id in enumerate(retrieved_ids, 1): if doc_id in relevant_ids: return 1.0 / rank return 0.0实测经验别只报一个 k。业务上问答场景看 Hit Rate3知识库检索场景看 Recall10汇报时把 k1/3/5/10 全打出来趋势比绝对值有用。embedding 模型换版、chunk 大小调整、reranker 引入都是靠这几个数决定去留。另一个容易漏的维度是检索延迟分布向量检索的 p99 在数据量过千万后常从 20ms 飙到 200msHNSW 的 ef_search 参数就是拿召回率换延迟建议把 recallk 和 p99 画在同一张图上选参。生成层用 LLM 评 LLM检索对了不代表回答对。生成质量有两个核心指标Faithfulness忠实度回答中的每个事实点是否都能在检索到的上下文中找到依据。防幻觉的直接度量。Answer Relevancy答案相关性回答是否切题有没有答非所问、绕圈子。这两个指标没法用规则算——答案的语义相关性必须靠模型判断这就是LLM-as-Judge用一个强模型当裁判给评估 prompt让它按标尺打分。裁判 prompt 的写法直接决定评分质量关键是把标尺定义死你是严谨的评测员。判断以下回答中的每个陈述是否能由给定上下文直接支撑。 评分标准 - 1分回答存在明显的事实编造或与上下文矛盾 - 3分部分陈述有依据但存在推断过度或细节错误 - 5分所有陈述均可由上下文直接支撑无任何编造 只输出分数和一句理由格式{score: n, reason: ...}注意两个细节一是必须要求输出理由纯分数会让模型偷懒走捷径二是分数锚点要少3档就够5档以上模型自己都分不清边界评分方差会显著变大。RAGAS把评估工程化手动实现指标 自己写 judge prompt 能跑通但维护成本高。开源框架 RAGASexplodinggradients/ragas把上面这套打包好了检索指标和生成指标都内置from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall from datasets import Dataset eval_data Dataset.from_dict({ question: [退货政策是什么], answer: [支持7天无理由退货运费由买家承担。], contexts: [[根据《退货政策》第3条自签收之日起7天内可无理由退货。]], ground_truth: [签收后7天内可无理由退货。], }) result evaluate( eval_data, metrics[faithfulness, answer_relevancy, context_precision, context_recall], ) print(result.to_pandas())RAGAS 的 context_precision / context_recall 对应检索层质量contexts 里有多少有用信息、该召回的全没全faithfulness / answer_relevancy 对应生成层质量正好覆盖全链路。跑完会输出每个样本的分 整体均值直接落 CSV 归档。踩坑记录这套体系跑了大半年坑集中在三个地方1. Judge 模型自己的偏差。位置偏差答案越长分越低、长度偏差越长分越高、自偏好Claude 评 Claude 给分虚高。解法同一批样本用两个不同厂商的模型交叉打分只保留两模型都判定为 3 分以下的样本进问题清单打分 prompt 里明确忽略回答长度只评事实依据。2. 黄金数据集污染。标注样本一旦被写进知识库比如标注时把参考文档直接塞回了库指标会虚高到失去意义。黄金数据集要独立存放、独立版本管理评估时从知识库里排除这些文档。3. 指标漂移的误报。换 embedding 模型后 faithfulness 掉 2 个点先别急着回滚——先查是不是 judge prompt 里上下文格式变了RAGAS 对 contexts 的拼接顺序敏感再查样本里是否混入了知识库更新后的旧标注。指标先校准、后对比这个顺序不能反。还有一个工程建议评估集 100 条样本就够看出趋势不用追求上千条——LLM 打分成本高且 100 条 × 4 指标已经能稳定区分明显变差和噪声波动。总结与进阶方向一套可用的 RAG 质量测试体系 检索层离线指标Recallk/MRR/Hit Rate 生成层 LLM-as-JudgeFaithfulness/Answer Relevancy RAGAS 工程化封装 黄金数据集版本管理。这套东西接进 CI 后每次改 chunk 策略、换 embedding、调 reranker 都能在合并前看到质量影响把感觉变好了变成指标证明变好了。进阶方向有三条一是在线评估用用户反馈、追问率、复制行为等隐式信号做线上质量监控补离线指标的盲区二是评估集自动扩充用 badcase 聚类 人工抽检的半自动方式降低标注成本三是把 judge 换成更便宜的蒸馏小模型做预筛只有低分样本才上调大模型复核把评估成本再压一个量级。
![洛谷 P7912：[CSP-J 2021 T4] 小熊的果篮 ← 双向链表](http://pic.xiahunao.cn/yaotu/洛谷 P7912：[CSP-J 2021 T4] 小熊的果篮 ← 双向链表)
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
