刚刚阅读时长 13 分钟

没有评测的 RAG 系统只是猜测：2026 年分别衡量检索与生成的实操指南

你上线了一个 RAG 管线。现在：它真的在正常工作吗？大多数团队回答不了这个问题，因为他们只测最终答案、把整条管线当黑盒。本文是经过来源核查的 2026 年 RAG 评测实操指南——独立诊断检索与生成的四个指标（上下文精确率、上下文召回率、忠实度、答案相关性）、离线与在线的分工、生产忠实度阈值（约 0.75），以及为什么一个你没在评测的 RAG 系统，是一个你在猜的系统。

人工智能 developer-tools 模型新闻

RAG 评测实操封面

本文是生产 RAG 集群的第三篇，完成诊断 → chunking → 评测的闭环。RAG 没有解决幻觉——它只是把它搬了家命名了失败模式。每 512 个 token 不是 chunking 策略修了第一大失败模式。本文用告诉你这些修法到底有没有生效的纪律闭环——评测。

我通读了 RAG 评测文献后的结论很直接：一个没有评测的 RAG 系统不是你在运营的系统——是你在猜的系统。这个猜感觉合理，因为产出看起来合理。但"看起来合理"是生产 RAG 里最危险的词，因为让答案看起来对的同一种流畅性，也让错误答案看起来对。分辨两者的唯一办法是测量，而有用测量的唯一办法是把指标分到那两个能独立失败的两层上：检索和生成。

核心原则：分别测量检索与生成

这是 RAG 评测里最重要的一个想法，也是整个集群的结缔组织。回忆诊断篇的数据点：当 RAG 失败，约 73% 的失败在检索。如果你只测最终答案，你分不清一个坏答案来自坏检索（模型忠实复述了错误上下文）还是坏生成（模型忽略或超出了好上下文）。这两个失败模式需要完全不同的修法，而单一端到端指标无法区分它们。

这隐含的纪律是：把检索层和生成层当作两个独立的东西评测，各自带各自的指标，每次都这样。检索指标告诉你对的上下文回来了吗。生成指标告诉你模型正确使用那个上下文了吗。两者一起，定位失败；分开，你只剩猜测。

真正重要的四个指标

2026 的规范 RAG 指标集——由 Ragas 开创、被 DeepEval、Phoenix 及更广生态采纳——是四个指标，两层各两个。

检索层指标（我们取到了对的上下文吗？）

上下文精确率。 取回的 chunk 里，有多少真的与查询相关？高精确率意味着检索器没有用不相关噪音污染上下文窗口。低精确率意味着模型得从垃圾里提取信号。
上下文召回率。 语料里存在的相关 chunk 里，检索实际找到了多少？高召回意味着检索器没有漏掉含答案的那个 chunk。低召回意味着模型从来就没机会——对的上下文在你的索引里，但检索器没把它带上来。

这两个相互张力，就像任何精确率/召回率对。收紧检索提升精确率可能降低召回（你取更少、漏掉一些相关 chunk）。放松它提升召回可能降低精确率（你取更多、包括不相关噪音）。对的平衡取决于你下游对噪音的容忍度，而这正是生成指标衡量的。

生成层指标（模型正确使用上下文了吗？）

忠实度。 答案里的每个声明都有检索上下文支撑吗，还是模型超出了上下文（经典 RAG 幻觉）？这个指标抓的是诊断篇命名为"RAG 没有消除幻觉——它搬了家"的失败模式。一个忠实的答案待在上下文里；一个不忠实的答案伸到外面，哪怕外面的碰巧为真。
答案相关性。 答案真的回应了被问的问题吗？一个模型可以对不相关的上下文完全忠实，仍产出无用的答案。答案相关性抓的是"你回答了某个东西，但不是我问的"的失败。

纪律：四个都追踪。一个检索指标高但忠实度低的 RAG 系统有生成问题（模型超出上下文）。一个忠实度高但上下文召回低的系统有检索问题（模型忠实复述不完整上下文）。四个一起告诉你修哪层；任何子集都让你在猜。

生产阈值：忠实度约 0.75

从业者文献里一个有用的具体锚点：约 0.75 或更高的忠实度分数是常见的生产部署阈值（DataVLab 2026 RAG 评测指南有引用）。低于它，模型编造得频繁到用户会注意到，你不该在没有调查清楚原因前上线。

这个阈值不是法则——你的容忍度取决于用例。一个医疗或法律 RAG 系统应当比内部文档搜索工具要求更高忠实度。但 0.75 是有用的清醒检查：如果你的忠实度低于它，你有值得在上线前解决的问题；如果远高于它，忠实度大概不是你的瓶颈，你应该看检索召回。

离线评测 vs 在线评测

2026 的 RAG 评测栈分两种模式，你都需要。

离线评测 在部署前在策展数据集上跑。你建一组查询-上下文-答案三元组（这是我们评测集群的 golden set 纪律应用到 RAG），在你的管线上跑，算四个指标。离线评测是你抓住回归在它碰到用户前的方式——当你改 chunking、embedding、检索或 prompt，你重跑离线评测并检查指标有没有朝错误方向移动。Ragas、DeepEval、Phoenix 是这里的主力。

在线评测 在生产里、在真实流量上、持续跑。你抽样真实查询，给它们打分（通常用 LLM-as-a-judge，按我们的评审校准篇对照人类标签校准），并随时间追踪四个指标。在线评测是你抓住离线集没预测到的失败的方式——新查询类型、边界情况、漂移。LangSmith、Phoenix、FutureAGI 提供基础设施。

分工重要，因为两种模式抓不同的东西。离线抓你能预测的回归；在线抓你不能预测的。只有离线评测的团队对生产现实盲视；只有在线评测的团队在用户看到后才修。两者都需要。

它如何对接集群的其余部分

本文完结 RAG 集群的诊断闭环，并对外连接：

它衡量你选的 chunking 策略是否真的有效——上下文召回率是告诉你 chunking 对了的指标。
它定位诊断篇命名的失败——四个指标直接映射到那篇里的五个失败模式。
它把 golden set 纪律专门应用到 RAG——一个 RAG 评测集就是一组查询-上下文-答案三元组的 golden set。
它依赖评审校准纪律做在线评测——一个未校准的评审在生产里给忠实度打分是装饰，和其他地方一样。
它与按任务成本可观测性配对——质量（来自 RAG 评测）+ 成本（来自可观测性）是检索配置选择的完整决策矩阵。

营销稿不会写的锋利之处

几个值得知道的风险：

你的 RAG 评测集本身是一个 golden set，它会腐烂。 同样的刷新纪律适用：抽样真实生产查询、加边界情况、给集版本化。一个上线时冻结的 RAG 评测集几个月内就停止预测现实。
忠实度抓不到『事实上错但被上下文支撑』的答案。 如果你的检索上下文本身就错（陈旧来源、索引错误），模型可以忠实复述它、忠实度得高分、但事实上错。忠实度衡量的是 grounding，不是 ground truth。
四个指标不覆盖一切。 它们不衡量延迟、成本、安全、或 PII 泄露——这些在生产里都重要。把四个当作质量核心，而不是完整画面。
LLM 评审的 RAG 指标继承评审的偏见。 位置偏见、冗长偏见、自我偏好——当一个 LLM 给忠实度打分时全都适用。校准评审，否则你的忠实度分数是一种感觉。
聚合指标隐藏分布性失败。 一个平均忠实度 0.85 的系统，仍可能在某个具体查询类别上灾难性地差，只是被平均掉了。按查询类型切片指标，不只看聚合。

2026 年到底该怎么建

我会给一个团队的实操路径：

先建 RAG 评测集。 五十到几百个查询-上下文-答案三元组，从真实生产查询加人工边界情况。这是一切都依赖的资产。
在当前管线上离线跑四个指标。 用 Ragas 或 DeepEval。在改任何东西前先建立基线。
设一个生产忠实度阈值（从约 0.75 开始）。 不要在没有文档记录的理由下低于它上线。
在真实流量样本上加在线评测。 对照人类标签校准评审。随时间追踪四个指标。
用指标定位每次回归。 当质量下降，四个指标的分工告诉你该修检索还是生成。永远不要只从最终答案 debug。
按查询类型切片指标。 聚合平均隐藏导致事故的类别。
按节奏从生产刷新评测集。 一个不进化的 RAG 评测集会停止预测现实。

我的看法

2026 的故事是：RAG 评测是把一个你在运营的系统和一个你在猜的系统区分开的纪律。那四个指标——上下文精确率、上下文召回率、忠实度、答案相关性——并不奇异；它们是告诉你检索和生成两层是否真的在各自工作的最低可行插桩，彼此独立。一个测全四个、在真实评测集上、用校准过的评审、离线和在线都做的团队，能精确看见 RAG 在哪失败并修对的层。一个只测最终答案的团队，在黑暗里 debug。

如果你从本集群只记一件事：RAG 失败是分层的，RAG 评测也必须分层来匹配。每次都分别测检索和生成，否则你在猜该修哪层。

本文是生产 RAG 集群的第三篇、也是收官篇。从 RAG 没有解决幻觉——它只是把它搬了家起步看诊断，然后每 512 个 token 不是 chunking 策略看修检索第一大失败模式，再本篇看告诉你这些有没有生效的评测。关于这些指标依赖的更广评测纪律，见 LLM 评测集群。想找厂商的常驻参考，见我们的 AI 价格数据页。