引言

在过去两年中，“上下文窗口” (context window) ——即 AI 模型一次能处理的文本量——发生了爆炸式增长。我们迅速从仅能阅读长篇文章的模型 (4k token) ，迈向了能够消化整个图书馆的庞然大物 (100 万+ token) 。像 Gemini-1.5-pro 和 Claude 3 Opus 这样的模型承诺一次性处理海量信息。另一方面，检索增强生成 (RAG) 系统则承诺从数百万份文档中筛选出我们要找的确切内容。

但是，巨大的上下文窗口带来了一个巨大的问题: 我们如何知道模型是否真的理解了它所读的内容?

到目前为止，标准的测试是“大海捞针” (Needle-in-a-Haystack) 挑战。你将一个随机事实 (针) 隐藏在大量文本 (草垛) 中，然后让模型找到它。如果模型检索到了这个关键信息，它就通过了测试。虽然有用，但这项任务非常初级。它测试的是检索能力，而非推理能力。这相当于 AI 版的“Ctrl+F”。

现实世界的任务很少是寻找单个句子。它们通常涉及阅读数十份文档，综合信息，识别重复趋势，并且——至关重要的是——引用来源。

在 Salesforce AI Research 最近发表的一篇题为 Summary of a Haystack: A Challenge to Long-Context LLMs and RAG Systems 的论文中，研究人员引入了一个新的、更为严格的基准。他们认为，为了真正测试下一代 AI，我们需要超越寻找“针”。我们需要要求模型对“草垛”进行摘要。

这篇文章将探讨“草垛摘要” (Summary of a Haystack，简称 SummHay) 框架，这是一种评估长上下文推理的新颖方法。它揭示了一个令人不安的事实: 尽管炒作不断，但在处理复杂的综合与引用任务时，当今最顶尖的模型仍然大大落后于人类的表现。

背景: 评估危机

要理解为何 SummHay 是必要的，我们首先必须审视长上下文大语言模型 (LLMs) 和 RAG 系统的现状。

竞争者: 长上下文 vs. RAG

目前有两种基于大型数据集回答问题的方法:

  1. 长上下文 LLM (Long-Context LLMs) : 你将整个语料库 (例如 100 份文档) 直接输入到模型的提示词 (prompt) 中。模型一次性“阅读”所有内容。
  2. RAG (检索增强生成) : 检索算法扫描语料库，选出最相关的几个片段，然后仅将这些片段输入给 LLM。

这两种方法旨在解决同一个问题，但比较它们却很困难。RAG 效率高，但可能会遗漏上下文。长上下文模型能看到所有内容，但可能会不堪重负 (即“迷失在中间”) 。

现有基准的问题

现有的基准测试通常陷入两个陷阱:

  1. 太简单: 像“大海捞针”这样的任务只需要检索特定的文本字符串。它们不测试跨多个文档聚合信息的能力。
  2. 太主观: 传统的摘要基准依赖于人类编写的“金标准”摘要。然而，将 AI 的摘要与人类的摘要进行比较是非常困难的。像 ROUGE (计算单词重叠) 这样的指标与实际质量的相关性很差。此外，对于海量数据集 (10万+ token) ，创建人类参考摘要极其昂贵且缓慢。

研究人员意识到，为了大规模评估复杂的推理能力，他们需要一种生成“草垛”的方法，在这种方法中，他们能确切知道摘要应该是什么样子的，而不依赖于主观的人类写作。

SummHay 方法: 合成真理

这篇论文的核心创新在于一个合成数据生成管道。研究人员不是采用现有的真实世界文档并试图评估其摘要，而是基于一组结构化的事实从头开始创建文档。

因为文档是他们生成的，所以他们确切知道哪些事实出现在哪份文档中。这有效地将主观的“摘要”任务转化为客观的“覆盖率和引用”任务。

第一步: 子主题和洞察 (Insights)

该过程始于一个高层级的主题，例如“学生讨论考试策略”。LLM 将其分解为不同的子主题 (例如，“学习技巧”、“压力管理”) 。

对于每个子主题，系统会生成具体的原子事实，称为洞察 (Insights) 。 洞察是一条独立的信息，通常包含特定的实体或数字。

  • *子主题: * 压力管理。
  • *洞察: * “一名学生建议每天早上使用‘Calm’冥想应用 15 分钟。”

第二步: 文档生成 (构建草垛)

一旦定义了洞察，系统就会生成实际的文档 (即草垛) 。一个草垛包含大约 100 份文档，总计约 100,000 个 token。

最聪明的地方在于: 系统通过程序决定哪些洞察进入哪份文档。

  • 文档 1 可能包含“Calm 应用”洞察和“番茄工作法”洞察。
  • 文档 2 可能包含“Calm 应用”洞察和“抽认卡”洞察。
  • 文档 3 可能根本不包含任何相关洞察。

这创建了一个精确的“黄金映射 (Gold Mapping) ”。研究人员知道，如果模型被问及“压力管理”，它必须提到 Calm 应用，并且它必须引用文档 1 和文档 2。

图解: 展示了根据输入场景合成草垛文档的步骤: 先创建子主题和洞察，随后生成文档。一旦草垛合成完毕，即可用于在查询聚焦的摘要任务上对 LLM / RAG 系统进行基准测试。

如图 1 所示，该流程从抽象概念流向具体文档。这种合成方法确保了“洞察在文档间重复”，模仿了现实世界的研究过程，即多个来源可能会证实同一个事实。

第三步: 任务

模型被赋予草垛 (或通过 RAG 访问草垛) 和一个查询，例如: “总结关于压力管理的洞察。”

关键在于，提示词指示模型:

  1. 生成一个洞察要点列表。
  2. 引用每一个来源文档 , 这些文档必须对该洞察有贡献，并使用特定的格式 (例如 [Doc 1, Doc 2]) 。

评估协议: 覆盖率、引用和联合得分

因为研究人员掌握了地面实况 (洞察与文档的映射关系) ，他们不需要询问人类“这个摘要读起来好吗？”，而是可以通过数学计算准确性。

他们引入了三个关键指标:

1. 覆盖率得分 (Coverage Score)

这衡量的是召回率。模型是否找到了与查询相关的所有洞察？

  • 如果有 5 个预期洞察 (例如: Calm 应用、深呼吸、散步等) ，而模型列出了其中的 3 个，它将获得部分分数。
  • 评分是细粒度的: 一个洞察可以是“完全覆盖”、“部分覆盖”或“未覆盖”。

2. 引用得分 (Citation Score)

这衡量的是归因能力。对于模型成功找到的每一个洞察，它是否引用了正确的文档？

  • 这是通过精确率 (Precision) 和召回率 (Recall) 计算出的 F1 分数。
  • 精确率: 模型引用的文档是否确实包含该洞察？ (避免幻觉) 。
  • 召回率: 模型是否引用了所有包含该洞察的文档？ (全面性) 。

3. 联合得分 (Joint Score)

这是终极指标。它结合了覆盖率和引用。要获得高联合得分，模型必须找到信息并且正确归因。如果模型产生幻觉捏造事实，得分为零。如果它找到了事实但引用了错误的文档，分数会大幅下降。

候选摘要 (右) 针对参考洞察 (左) 的覆盖率评估示例。每个参考洞察通过映射到单个候选要点来分配覆盖率得分。映射要点的引用用于计算引用得分。总分是所有参考洞察的平均值。附录 A.7 中还有四个额外示例。

图 2 可视化了这种评分方式。左侧是“参考洞察”——即地面实况。右侧是 AI 生成的“候选摘要”。评估过程将 AI 的要点映射到参考洞察，以检查准确性。

自动化裁判

手动评估这些输出太慢了。研究人员验证了 GPT-4o 可以作为自动化裁判。他们将 GPT-4o 的评分与人类标注者进行了比较，发现了高度相关性。

表 1: SummHay 手动和自动评估的可复现性与成本。我们计算了覆盖率相关性、链接准确率和评估成本。

表 1 显示，GPT-4o 与人类标注者达到了 0.716 的相关性，这对于基准测试来说已经足够可靠，同时将每批次的成本从 325 美元 (手动) 降低到了大约 7 美元 (自动) 。

实验与结果: 现实检验

研究人员在两个领域 (新闻和对话) 测试了 10 个最先进的 LLM (包括 GPT-4o、Claude 3 Opus、Gemini 1.5 Pro) 和 50 种不同的 RAG 配置。

结果总结如下，揭示了 SummHay 对当前的 AI 来说是一个残酷的考验。

1. 人类仍然更胜一筹

最惊人的发现是最佳 AI 系统与人类表现之间的差距。

人类在 SummHay 任务上的表现预估，绘制了参与者在两小时会话中于 Oracle 设置下完成任务随时间变化的情况。

图 3 追踪了人类标注者执行任务的过程。在 2 小时的会话中，人类 (橙色和绿色线) 稳步提高了他们的引用和联合得分，最终达到了约 56% 的联合得分。

相比之下，请看下方的表 2 。 在现实设置下 (使用 Rerank3 检索) ，任何 AI 系统取得的最佳“联合得分”仅为 36.0% (Gemini-1.5-pro) 。

表 2: SummHay 结果摘要，包括人类表现、RAG 系统和长上下文 LLM。结果使用三个指标报告: 覆盖率 (左) 、引用 (中) 和联合 (右) 得分。Full 对应输入整个草垛时的模型性能，而 Rand、Vect、LongE、KWs、RR3、Orac 对应 RAG 系统的检索组件。模型按 Oracle 联合得分排序。对于每个模型，#W_b 报告每个要点的平均字数。

  • (注意: 表中的 “Orac” 代表 Oracle——即上帝视角/预言机模式，这是一种作弊模式，模型只获得完美的文档。即使有这种不公平的优势，模型也仅勉强达到人类的表现，这表明存在推理缺陷，而不仅仅是检索缺陷。) *

2. RAG 与长上下文的权衡

数据揭示了工程师在选择 RAG 和长上下文窗口时面临的一个有趣困境。

  • 长上下文 LLM (“Full” 列) : 这些模型通常在引用方面表现挣扎。当一次性阅读 100k token 时，像 GPT-4o 和 Claude 3 Opus 这样的模型很难准确指出哪个文档贡献了哪个具体要点。它们在“Full”设置下的联合得分通常很差 (GPT-4o 为 16.2) 。
  • *例外: * Gemini-1.5-pro 在全上下文设置下的表现明显优于其他模型 (联合得分 51.0) ，这表明其长上下文架构目前在归因任务上更胜一筹。
  • RAG 系统: 使用检索器 (如 “RR3” - Cohere Rerank 3) 显著提高了引用得分。通过过滤噪音并只给 LLM 提供相关的 15k token，模型犯的归因错误更少。然而，严格的检索往往会降低覆盖率 , 因为检索器可能会在 LLM 看到之前意外过滤掉相关文档。

结论: 如果你需要 AI 知道一切 (覆盖率) ，请使用巨大的上下文窗口。如果你需要 AI 负责任并准确引用来源 (引用) ，高质量的 RAG 管道目前是更安全的选择。

3. “迷失在中间”现象

文档的顺序重要吗？是的。研究人员重新洗牌了草垛，将相关文档放置在上下文窗口的顶部、中部或底部。

表 3: 全上下文设置下 LLM 的联合得分，基于文档的排序方式。文档可以是随机顺序，或者排序使得相关文档位于上下文窗口的顶部或底部。

表 3 (此处引用图像集中的表 3) 显示了显著的位置敏感性 。

  • GPT-4o 和 Claude 3 Opus 在相关信息位于底部 (接近提示词的末尾) 时，表现比位于顶部时高出近 10 分。
  • Gemini-1.5-pro 则有相反的偏好，更喜欢信息位于顶部 。

这种“位置偏差”证实了模型并不是均匀地处理 100k+ 的 token 窗口。它们在开头或结尾有注意力峰值，往往会略过埋在中间的信息。

讨论与启示

“Summary of a Haystack” 论文为 AI 行业提供了一次现实检验。虽然营销材料吹嘘“1000 万 token 窗口”和“完美召回”，但在该上下文中执行有用工作的能力却是另一回事。

这对学生和研究人员的重要性

  1. 召回 \(\ne\) 推理: 仅仅因为模型能复述书中隐藏的密码，并不意味着它能写出读书报告。我们需要停止对简单的检索能力感到印象深刻。
  2. 引用很难: 幻觉仍然是一个主要问题。在 SummHay 测试中，模型经常捏造引用，或未能引用明显包含信息的文档。对于学术或企业应用来说，这是一个关键的故障点。
  3. 整体 RAG 评估: SummHay 提供了一种测试整个管道的方法。通常，开发者会分别测试检索器和生成器。SummHay 测试最终结果: 用户是否得到了正确的答案以及正确的证据？

未来方向

作者指出，即使是他们的“人类表现”预估 (56%) 也不是硬性上限——那是在时间限制下完成的。然而，最先进的模型落后 20 分的事实表明我们还有很长的路要走。

未来的系统需要在两个特定领域进行改进:

  1. 主动推理: 模型需要更好地识别信息何时在文档之间重复并进行综合，而不是仅仅将文档视为一堆不相连的单词。
  2. 归因机制: 我们可能需要架构上的改变或特定的微调，以强制模型在生成文本时追踪一条信息的来源位置。

结论

随着我们进入“无限上下文”时代，我们的基准必须进化。“Summary of a Haystack” (SummHay) 为这种进化提供了蓝图。通过使用合成数据为复杂的摘要任务创建客观的地面实况，它暴露了当前 LLM 和 RAG 系统的局限性。

挑战已经设下: 下一代模型能否阅读整个图书馆，理解叙事，并像人类研究员一样精确地引用其来源？目前，答案是“还不行”。但多亏了像 SummHay 这样的基准，我们现在有了一把衡量进步的尺子。