评估 RAG 和长上下文 LLM 输出的质量

来源：互联网时间：2026-08-21 13:59:23

介绍

如何衡量长上下文LLM输出和RAG结果的质量？Salesforce为此专门打造了一个数据集和评估框架，目的就是为了精准衡量生成输出的准确性。

大致思路是这样的：Salesforce设计了一套程序，用来创建包含重复见解或信号的文档“干草堆”。然后，一个叫SummHay（干草堆摘要）的任务被抛出来——要求系统生成一份摘要，不仅要识别出所有相关见解，还得准确引用源文档。

由于对预期的见解和引用都了如指掌，Salesforce就能对摘要的覆盖率和引用质量进行自动评估打分。

他们在对话和新闻两个领域分别搭建了这样的“干草堆”，并测试了10个LLM和50个RAG系统。结果很有意思：SummHay这个任务对现有系统来说仍然是个硬骨头，哪怕最好的系统，也落后人类表现（56%）十多个百分点。

SummHay的价值还不止于此，它还能用来研究企业RAG系统和长上下文模型中的位置偏差。Salesforce的设想是，未来会有系统能在SummHay上追平甚至超越人类的表现。

坦白说，虽然RAG和长上下文LLM都号称能解决“回答大量文本中的查询”这个问题，但一直以来，它们之间缺乏一个可以直接对比的常见任务，这让评估变得非常棘手。

最近的一些测试，比如让模型在长篇文档里找一小块信息，对新一代大语言模型来说已经不够看了——很多顶尖模型都能做到近乎满分。换句话说，测试的复杂性需要升级了。

Salesforce的提议很直接：把摘要任务当作评估长上下文模型和RAG系统的试验台。

为什么？因为摘要天然需要基于大量背景信息进行推理，还需要仔细掂量哪些内容更重要。

过去针对摘要的评估工作，尤其是在相关性评估上，主要都聚焦在单文档摘要，或者输入内容只有1000-2000个token的任务上。即便是更长的对话和多文档新闻摘要，通常也限制在1万个token左右。

更棘手的是，摘要评估长期以来一直受困于两个问题：一是参考摘要的质量参差不齐，二是自动评估指标与人类判断的相关性很差。

传统做法是把候选摘要和“黄金标准”参考文献做对比，认为重叠越多质量越好。但这套方法在长上下文环境下根本行不通，因为获取高质量的参考文献本身就是一件成本极高的事。即便最好的内容覆盖率自动指标，也常常和人类判断对不上号。

为了解决这个问题，Salesforce转向了合成数据生成。看看下面的图片：他们的方法是为特定主题生成大量文档（也就是“干草堆”），并确保某些信号会在不同的文档中反复出现。

关键在于，通过精确控制哪些见解出现在哪些文档中，Salesforce就能自动确定查询对应的相关见解。而SummHay任务要求系统总结这些见解并引用来源，最后根据预期见解的覆盖范围和引用的准确性来打分。

SummHay 方法示意图

这些“干草堆”主要在两个领域生成：对话和新闻文章。每个干草堆通常包含100份文档，总计约10万个token。Salesforce总共生成了10个干草堆，每个大约有10个查询，最终凑出92个SummHay任务。这套流程是可扩展的，未来还可以嫁接到其他领域。

SummHay的评估协议主要盯住两点：系统输出对参考见解的覆盖率，以及引用质量。通过人工标注验证，这个协议在知识丰富的标注员之间保持了很高的可重复性（相关性达到0.77）。

随后，Salesforce又尝试了基于LLM的自动化评估。结果发现，虽然相关性水平略低（0.71），但评估成本却降低了将近50倍。这显然是一个很诱人的权衡。

Salesforce在SummHay上建立了人类表现的基准，然后对50个RAG系统和10个长上下文LLM进行了大规模评估。

对所有被评估的系统来说，SummHay都是一项艰巨的挑战——没有任何一个模型能达到接近人类水平的性能。即使给模型开“上帝视角”（提供哪些是相关文档的完美信号），情况依然如此。
即便有了上述优势，模型在总结见解和准确引用来源上，仍然跟人类表现差得远。
在RAG管道和长上下文LLM之间做选择时，必须考虑一个核心权衡：

RAG系统通常能提供更好的引用质量，也就是说，它们能更准确地引用具体文档或来源。但代价往往是洞察覆盖率的下降——也就是全面捕获和总结所有相关信息的能力会打折扣。

相比之下，长上下文LLM可能覆盖的见解更全面，但它的引用质量不够精确，容易出错。
使用更先进的RAG组件（比如重排序器）可以提升任务的端到端性能，这也从侧面印证了SummHay是评估整体RAG系统的一个好选择。
位置偏差实验确认了“中间丢失”现象的普遍存在——大多数LLM都倾向于关注上下文窗口顶部或底部的信息，而中间的内容则容易被忽略。这才是挑战真正棘手的地方。