我从真实RAG学到的6个评估指标

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

曾经有一段时间，构建一个RAG系统感觉简单得令人怀疑。

分块文档。 生成嵌入。 把它们放进向量数据库。 设置 top_k = 5。 调用LLM。

这种方式似乎在一段时间内有效。然后你将系统投入真实环境。

查询变得混乱。文档不一致。有些问题需要来自多个来源的信息。用户会问原始评估集里没有的问题。突然，一个在基准测试中表现优秀的配置开始产生感觉奇怪不可靠的答案。

我在为企业级RAG工作流进行检索调优时，就遇到了这类问题。

我们增加了检索深度，因为系统遗漏了相关信息。检索指标提高了。召回率上升。纸面上看，检索器看起来更好了。

但答案变得更差了。

更多的上下文并没有产生更好的答案。在某些情况下，效果恰恰相反。模型接收到了与冗余段落、松散相关内容以及偶尔相互冲突的证据混合在一起的相关信息。

就在那一刻，我不再把RAG评估简单地看作：

"我们是否检索到了正确的文档？"

而是开始这样思考：

"我能证明RAG管道的每个阶段都在完成它的任务吗？"

这种转变听起来微妙。其实不是。

因为一旦你开始调试生产级RAG系统，你很快就会发现检索质量、排序质量、答案质量、真实性、延迟和成本都是同一个工程问题的不同维度。

这就引出了我经常听到的一个问题：

如何系统地调整chunk size和top-k？

我今天的答案与几年前完全不同。

我不再从以下方面开始：

"使用512个token的chunk和top-k 5。"

我从以下方面开始：

将其视为离线优化问题，定义真实标签，衡量正确的指标，理解权衡，在未见数据上验证，然后验证改进在生产中是否有效。

在这篇文章中，我将介绍我在评估RAG系统时发现最有用的六个指标：

Recall@K、nDCG、MRR、真实性、延迟和成本。

但更重要的是，我将解释为什么每个指标存在，它能暴露什么类型的故障，以及当你试图将RAG原型转化为生产系统时，这些指标如何协同工作。

1、我首先检查的是检索

当答案开始变差时，我的第一反应是回到RAG管道的起点。

在质疑提示之前。在更改LLM之前。在添加另一个代理之前。

我想回答一个非常基本的问题：

系统是否真的找到了它需要的信息？

因为在任何RAG系统中都有一个基本限制：模型无法使用从未被检索到的证据。

这让我看到了调试检索时查看的第一个指标：

1.1 Recall@K — 我们是否检索到了所需的证据？

Recall@K回答了一个看似简单的问题：

在所有与查询实际相关的信息中，我们的检索器设法将多少带入了前K个结果中？

这就是调查开始变得有趣的地方。例如，想象一个ITSM助手收到这个问题：

"支付服务在数据库故障转移后失败了。我应该遵循什么恢复程序？"

假设我们的真实标签显示有五个信息片段与回答该问题相关。检索器返回了其前五个结果，但只有这五个相关证据中的四个出现在检索集合中。

那么：

Recall@5 = 4/5 = 0.80

所以我们的检索系统有80%的Recall@5。这个数字立即告诉我一些重要的信息。

系统不一定是因LLM不好而失败，而是可能因为它所需的五分之一的证据从未到达生成阶段，这给了我们第一条调试规则：

在尝试让LLM回答得更好之前，确保你给了它正确的证据来回答。

这也是我不将 top_k = 5 视为通用最佳实践的原因。

如果将K从5增加到10，Recall@K从0.80提高到0.94，我就学到了一些有用的东西：检索器可能有相关证据，但我当前的检索深度太浅了。

但这带来了第二个问题。

当那些额外的六个结果大多是噪声时会发生什么？

这正是我接下来陷入的兔子洞，也是nDCG和排序质量变得重要的地方。

1.2 nDCG：我们是否将最有用的证据排在了前面？

找到相关信息只是问题的一部分。我们还需要知道这些信息在排序中的位置。

考虑同一查询的两个检索结果。

在第一个系统中，高度相关的运行手册出现在位置一，然后是另一个相关程序，接着是几个不太有用的块。

在第二个系统中，相同的运行手册出现在位置八，之前是一系列松散相关的文档。

两个系统可能都有可接受的召回率。但它们并不等价。

这就是归一化折损累计增益（nDCG）变得有用的地方。与简单的二元相关性指标不同，nDCG可以考虑分级相关性，并奖励将高度相关的结果放在排序顶部附近的系统。Järvelin和Kekäläinen的原始折损增益工作正是围绕这一思想设计的：相关性很重要，但位置也很重要。

对于RAG，一旦我们引入重排序，这变得尤为重要。

如果我检索了20个候选者，只将最好的五个传递给LLM，那么这20个候选者的排序突然变得非常重要。

一个具有出色召回率但排序较差的系统可能在候选池中的某个地方包含正确的证据，但仍然无法将其传递到最终上下文中。

这给了我一个有用的区别：

Recall告诉我证据是否被找到。nDCG告诉我证据是否被智能地排序。

1.3 MRR：我们多快找到了第一个有用的结果？

还有一些情况，我不需要每个相关文档。我需要快速获得一个强有力的结果。

考虑查询：

"什么命令可以重启服务X？"

如果正确的运行手册排名第一，那与在位置十找到同一运行手册有很大不同。

平均倒数排名（MRR通过关注第一个相关结果的位置来捕捉这一点。

对于单个查询：

RR = 1 / 第一个相关结果的排名

位置一的相关结果给出RR为1.0。在位置二，它变为0.5。在位置五，它变为0.2。

MRR在评估集上对此行为取平均值。

我不将MRR作为检索质量的唯一定义。但当我关心检索器多快浮现有用答案时，它非常有用。

所以我现在有三个不同的问题：

Recall@K：我们是否检索到了证据？

nDCG：我们是否很好地排序了证据？

MRR：我们多快浮现出第一个有用的结果？

然后出现了使整个问题更有趣的生产问题。

更多的检索上下文正在使答案变差

我们对RAG的直觉通常是假设更多上下文更安全。

如果五个块不够，检索十个。如果十个不够，检索二十个。但语言模型的行为不一定如此。有一个点，额外的上下文停止有用并开始变成噪声。

你可以检索一个高度相关的运行手册，但然后用十四个松散相关的文档、一个过时的程序和两个相互冲突的指令来包围它。

检索器可能得分更好。答案可能仍然变得更差。

这也是候选K和最终K之间的区别变得重要的地方。

生产架构可能如下所示：

第一阶段故意广泛检索，因为我想要高召回率。重排序器然后缩小候选集，LLM只接收最高价值的上下文。

这与简单地检索五个块并直接传递给模型有着根本不同的架构。它引出了另一个不可忽视的指标。

1.4 真实性：模型是否保持在检索证据的基础上？

假设检索器完美执行，正确的运行手册被检索到。重排序器将其放在顶部，上下文相关，LLM仍然添加了一个在检索材料中不存在的声明。

例如，也许运行手册说：

"在验证数据库连接后重启服务。"

生成的答案说：

"在验证数据库连接并清除Redis缓存后重启服务。"

如果在检索上下文中没有关于Redis的证据，那么额外的声明就是不受支持的。检索系统完成了它的工作，而生成系统引入了一个不受支持的声明。

这就是真实性变得重要的地方。我将真实性视为一个简单的问题：

答案中的声明是否得到了提供给模型的证据的支持？

诸如RAGAS和ARES之类的框架明确分离了检索/上下文质量、真实性和答案相关性等维度，而不是将RAG响应视为一个不可区分的分数。这很重要，因为一个系统可以检索到正确的信息，但仍然生成一个没有正确基于证据的答案。

这里还有另一个在企业系统中很重要的微妙区别。

真实性与正确性不同。

假设知识库包含一个过时的密码策略，说密码每60天过期。

模型检索该文档并回答：

"密码每60天过期。"

答案可能完全忠实于检索到的来源，但它仍然可能是错误的。

所以我通常区分：

真实性：答案是否得到了检索上下文的支持？

正确性：答案是否根据预期的真实来源实际正确？

在评估具有不断变化的知识库的生产系统时，这种区别变得极为重要。

1.5 延迟：用户实际能负担得起多少质量？

一旦检索系统开始在离线状态下良好运行，另一个问题就出现了。质量只有在系统能够在产品约束内交付时才有用。

想象两种配置：

1. 配置 答案准确率 检索延迟A 91% 120ms B 93% 650ms

如果我只关心答案准确率，配置B看起来更好。

但B是否实际更好取决于应用程序。

对于具有严格响应时间期望的交互式助手，额外的延迟可能是不可接受的，而且检索延迟只是总响应时间的一部分。

生产请求可能涉及：

所以当我评估延迟时，我想了解各个阶段和端到端响应，我还关心分布而不仅仅是平均值。

平均延迟为400ms的系统仍然可能有P95为1.8秒。

这与P50、P95和P99保持一致较低的系统有着非常不同的用户体验。

这就是为什么延迟从一开始就属于RAG评估框架，而不是在架构已经最终确定后才被视为运营指标。

1.6 成本：当我们将其扩展到数百万查询时会发生什么？

最后一个指标是原型转变为产品时不可避免的那个。

成本。

增加top-k不仅影响检索。

它可以增加：

• 重排序器处理的候选数量；
• 最终上下文的大小；
• LLM输入token；
• 延迟；
• 基础设施消耗。

假设平均块包含600个token。

当：

最终K = 5

我们注入大约：

5 × 600 = 3,000

个检索到的token到提示中。

增加到：

最终K = 15

我们大约有：

15 × 600 = 9,000

个检索到的内容token。

这是三倍的检索上下文，在小规模时，这可能不可见，但在数百万请求时，它变成了一个产品决策。这就是为什么我不再认为 top_k 只是一个检索参数。

Top-k同时影响质量、延迟和经济性。

2、真正的优化问题

到这时，原始的面试问题开始看起来非常不同。

"如何调整chunk size和top-k？"实际上不是在问两个数字。

它是在问你如何设计实验。

我可能会从一个包含200个代表性查询的评估数据集开始，涵盖多个类别：

• 故障排除；
• 程序性查询；
• 事件和RCA问题；
• 策略问题；
• 模糊问题；
• 多跳问题；
• 边缘情况。
• 领域专家将建立相关性判断。

然后我可能会测试：

Chunk sizes: 256, 512, 1024, 2048
Overlap: 64, 128, 256
候选K: 5, 10, 20

这给出：

4 × 3 × 3 = 36

种配置。

对于每种配置，我不会只衡量一个分数。

我会收集：

Recall@K
nDCG@K
MRR
答案正确性
真实性
延迟
成本

然后我会寻找质量/延迟/成本权衡，而不是自动选择具有最高召回率或F1的配置。

3、RAG实验可能产生非常违反直觉的结果

想象我们得到以下结果：

如果我只看召回率，我会选择C。但C产生了最差的答案。

为什么？

因为额外的检索信息显然没有帮助生成层。事实上，它可能在伤害它。

配置B有趣得多，因为它没有最高的召回率。

但它有最高的nDCG、最高的答案准确率、最高的真实性，以及相对较小的延迟和成本惩罚。

这正是我会进一步研究的那种配置，这也是为什么我不喜欢这句话：

"最佳RAG配置是具有最高检索分数的那个。"

没有这样的通用规则。最佳配置是为目标应用程序优化正确目标的那个。

4、RAG系统失败时我寻找什么

这是我目前使用的调试框架。

如果：

Recall@K较差

我调查分块、嵌入、索引、元数据过滤器、查询构建和检索策略。

如果：

Recall好但nDCG差

我调查排序和重排序。

如果：

检索指标好但答案准确率差

我调查上下文构建、上下文排序、提示设计和生成。

如果：

答案看起来正确但不受支持

我调查真实性和基础性。

如果：

质量好但延迟不可接受

我分析管道的每个阶段。

如果：

质量好但成本太高

我调查候选K、最终K、chunk size、上下文压缩、缓存、模型选择和提示/token效率。

这将RAG调试转变为更系统化的东西。

5、我在生产中实际想要的评估循环

最终状态不是运行一次的基准。我想要一个持续的评估循环：

这特别重要，因为生产查询很少表现得完全像精心策划的基准查询。用户表达方式不同，文档变化，策略变化，新服务被引入，边缘情况出现，因此评估集必须随产品一起演变。

生产成为新评估案例的来源。

6、在成熟的RAG系统中我会衡量什么

到这时，我的RAG记分卡通常看起来像这样：

没有单一指标能讲述整个故事。这是我从那次生产调试中学到的教训。

7、我现在在调整任何RAG系统之前会问的问题

当有人问：

"我们应该使用什么chunk size和top-k？"

我的第一个回答不是一个数字。而是一个问题：

"我们在优化什么，我们的评估数据集是什么样的，检索错误的成本是什么？"

一旦这些问题有了答案，配置就变成了实验结果。

也许是：

512 tokens
128 overlap
候选K = 20
最终K = 5

也许是：

1024 tokens
64 overlap
候选K = 10
最终K = 4

也许语义分块优于两者，或者重排序器使最终K的选择比初始候选K重要得多。

没有我不经测量就信任的通用值，对我来说，这是构建和调试RAG系统的更大教训：

RAG系统不是因为检索更多而好。不是因为检索更快而好。也不是因为LLM产生令人信服的答案而好。

当它始终检索正确的证据，适当地排序它，给模型适量的上下文，生成正确且基于证据的答案，并且在真实产品的延迟和成本约束内完成所有这些时，它才是好的。

这就是构建RAG管道和工程化生产RAG系统之间的区别。

8、结束语：停止凭猜测调整RAG

我与RAG系统合作得越多，我就越确信没有神奇的chunk size，没有通用的top-k，也没有单一指标能告诉你RAG系统是否生产就绪。

一个提高Recall@K的配置仍然可能损害答案质量。一个具有出色检索的系统仍然可能生成不受支持的声明。一个高度准确的系统如果在规模上延迟或成本不可接受，仍然可能失败。

真正的工程挑战是在检索覆盖范围、排序质量、基于证据的生成、延迟和成本之间找到与你实际服务的工作负载的正确平衡。

这就是为什么我更喜欢这样的评估循环：

构建有代表性的真实标签 → 基准检索 → 评估排序 → 衡量端到端答案质量 → 验证延迟和成本 → 在未见数据上测试 → 监控生产 → 将故障反馈回评估集。

到那时，chunk_size=512 或 top_k=5 就不再是一个猜测。

它是有证据支持的结果。

对我来说，这就是构建RAG管道和工程化生产RAG系统之间的区别。

原文链接：6 RAG Evaluation Metrics I Learned to Respect After Debugging a Production RAG System

汇智网翻译整理，转载请标明出处