RAG效果评估2026：别再凭感觉说'答得还行'，一套可量化的评测体系

“答得还不错”——然后呢？

很多团队做RAG（检索增强生成）都卡在同一个坎：demo看着挺好，上线后答错却说不清错在哪。是检索没召回对的文档？还是召回了但模型理解错了？没有评测体系，优化就只能靠猜。这篇给你一套可落地的RAG评测框架。

先拆开：RAG出错有四种可能

• 召回失败：正确文档根本没被检索出来
• 排序失败：正确文档检索到了，但排在很后面被判丢
• 生成幻觉：文档里有答案，模型却编了别的
• 引用失败：答案对，但引用的来源是错的

不分层评测，你永远在治标不治本。

四个评测维度

一、检索层（Retrieval）

• Recall@K：前K个结果里有没有包含正确文档，衡量”找得到吗”
• MRR / NDCG：衡量正确文档排得够不够靠前
• Precision@K：前K个里有多少是相关的，太高说明噪音多

二、生成层（Generation）

• 忠实度（Faithfulness）：答案是否完全基于检索到的内容
• 答案相关性（Answer Relevance）：是否真的回答了问题
• 上下文相关性（Context Relevance）：检索的上下文是否切题

这三个正是RAGAS等框架的核心指标，可以用LLM当裁判自动打分。

三、端到端（End-to-End）

• 准确率：整体答对的比例
• 拒答率：遇到无答案的问题，是否老实说”不知道”（很重要！）
• 有害输出率：有没有给出错误或违规内容

四、成本与延迟

• P95延迟：检索+生成的尾延迟
• 单次成本：token花费，尤其是重排序和长上下文

好系统的标准不是”不犯错”，而是”错得少且知道错在哪”。

怎么构建评测数据集

• 黄金集：人工标注100~500条「问题-答案-来源」，作为基准
• 难例集：把线上真实答错的问题收集起来，专门回归测试
• 负样本：故意问知识库里没有的问题，测拒答能力
• 分层覆盖：按问题类型（事实、对比、推理、多跳）分类，避免只测简单题

数据量不用大，但要能代表真实分布。50条精标往往比500条粗标更有用。

自动化评测流程

建议搭一条CI流水线：

1. 每次改动（换模型、调prompt、改切分）都跑全量评测集
2. 用LLM裁判对忠实度、相关性打分
3. 和上一版本对比，指标下降就拦截合并
4. 记录每次变更对应的指标，形成可追溯的优化日志

这样做的价值在于：把”感觉变好了”变成”忠实度从0.78涨到0.86”。

常见坑

• 只测简单题：线上全是复杂的多跳问答，测试集却都是单事实
• 忽略拒答：模型什么都敢答，准确率虚高
• 裁判不靠谱：用弱模型当裁判，打分噪声比信号大，最好人工抽检校准
• 不测延迟：指标全绿，用户体验却卡到弃用

写在最后

RAG的优化是一场持续的工程，不是一次性的调参。先建立评测基线，再分检索、生成、端到端、成本四层定位问题，你才能把有限的精力用在真正的瓶颈上。没有度量，就没有优化——这句话在RAG上尤其成立。