长上下文语言模型评估体系探析 原创 精华

编者按： 如今，AI模型的上下文窗口正以惊人的速度扩大——从2018年的区区512个token到现在的200万token。这种跨越式发展不仅仅是数字的变化，更代表着全新的应用机会：律师可以让AI快速分析数千页的法律文书，医生能够基于完整的病历做出更精准的诊断，研究人员可以同时处理数百篇学术论文...但问题是，我们如何确保这些超长上下文模型真的"理解"了如此庞大的信息量？

作者从三个维度详细阐述了长上下文模型的评估方法——信息检索能力评估、深度分析能力评估、上下文学习能力评估。作者基于实际研究案例，系统地展示了这些评估方法的应用场景和局限性。

作者 | Yennie Jun

编译 | 岳扬

近年来，语言模型的上下文窗口大小呈指数级增长，此图由原文作者制作

01 Introduction

大语言模型的上下文窗口 —— 即它们一次性能够处理的文章长度 —— 一直在以指数级速度增长。

2018 年，BERT[1]、T5[2] 和 GPT-1[3] 等语言模型能够处理的输入 token 数量上限为 512 个。而到了 2024 年夏季，这一数字已飙升至 200 万个 token（在公开可用的 LLMs 中）。这一变化对我们有何影响，我们又该如何评估这些能力越来越强的模型呢？

1.1 大上下文窗口究竟意味着什么？

最新发布的 Gemini 1.5 Pro 模型能够接收高达 200 万个 token[4]。但 200 万个 token 究竟代表什么呢？

假设大约每 4 个单词转换为 3 个 token，那么 200 万个 token 几乎可以囊括完整的《哈利·波特》和《指环王》系列小说。

这张图表展示了 Gemini 1.5 的 200 万 tokens 上下文窗口能够容纳多少本《哈利·波特》和《指环王》书籍。此图表部分灵感来源于 2024 年 3 月的这张精彩的信息图表[5]。该图由原文作者制作

这些数字指的是公开模型中可用的上下文窗口。尽管 Gemini 1.5 Pro 模型目前公开可用的上下文窗口为 200 万个 token，但它能够处理多达 1000 万个 token[6]。

正如一位 Reddit 用户所说，这意味着可以将 1000 篇科学论文纳入 Gemini 的 1000 万 token 上下文窗口中，以开展创新研究[7]。

1.2 大上下文窗口为何至关重要？

扩大上下文窗口的意义，不仅仅在于让构建 LLMs 的公司能够相互竞技。长上下文模型在现实世界中的应用场景广泛，以下是一些例子：

• 法律研究：律师可以将完整的案例经过、先例和法规输入模型，在几秒钟内就能获得全面的分析，而非耗费数小时甚至数日进行人工审查。
• 财务分析：将多年的财务报告、市场动态和经济指标输入AI，就能立即获得深入洞察。
• 医疗诊断：医生能够输入患者的全部医疗记录，包括医疗检测结果、治疗记录和高清医学影像，以实现更精确的诊断和个性化治疗方案。
• 教育领域：学生可以将整本教材和课程资料输入模型，获得定制化的知识点解释和跨学科的知识串联。

然而，这些使用案例也引起了人们的担忧。如果不当使用，处理海量个人数据的能力可能会带来前所未有的监控和隐私侵犯。随着这些能力的提升，制定强有力的伦理规范和安全保障的需求也日益迫切。

02 我们该如何评估上下文窗口大小不断增加的 LLMs？

拥有超长上下文窗口的模型是近期的发展趋势。因此，研究人员正在尝试开发新的评估方法，以判断这些模型的性能。这些评估方法旨在对长上下文模型的能力与局限性进行基准测试，并探讨扩展上下文窗口所带来的利弊。

核心观点是，拥有更长输入上下文的模型应当能够完成那些之前难以或无法完成的任务。

评估场景

本文将探讨研究人员考虑用于评估长上下文模型的以下三种方法：

1. 从长篇文档中提取信息
2. 对长篇文档进行深入分析（推理和概括）
3. 为即时模型训练提供上下文学习支持

备注：以上列举并不全面。如需全面了解长上下文模型的基准测试，请访问 Awesome LLM Long Context Modeling 的 Github 页面[8]。

2.1 从长篇文档中提取信息

Greg Kamradt[9] 提出的“大海捞针（Needle in a Haystack）”测试[10]，是评价长文本信息检索效率的一种流行手段。该方法通过将一句与上下文不符的语句（即“针（needle）”），随机插入不同长度的文本段落（即“海（haystack）”）中，以此考察模型在不同深度下检索信息的能力。

例如，将“The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park on a sunny day”这句话，嵌入到 Paul Graham 的文章之中。

该测试旨在衡量 LLMs 在日益增大的上下文内，定位具体信息的能力。

Greg Kamradt[9] 设计的原始“大海捞针”图表，用于检验 LLMs 在检索深层次信息方面的能力。通过将这句不协调的句子（“针”）置于不同长度的文本片段（“海”）的各个层级，我们可以评估不同 LLMs 在寻找这些信息时的表现。

“needle in a Haystack”的多种变体

研究人员设计了几种不同的测试，以探究信息检索的各个方面：

• 多“针”测试：在冗长的文档中散布多个“针”句子（由 Langchain[11] 提出，并在 NeedleBench[12] 中进行实验）。
• 多模态搜索：根据描述，在一堆无关的图片中寻找目标图像。
• 音频搜索：在长达五天的音频信号中识别出一段简短的音频（该测试在 Gemini 1.5 技术报告[13]中提出）。在此测试中，一段包含“the secret keyword is needle”这句话的音频片段，被隐藏在接近五天（107小时）的音频信号中。
• 视频搜索：在一部长达 10.5 小时的视频中，找到含有特定文字的单帧画面（同样在 Gemini 1.5 技术报告[13]中描述）。在这个测试中，一张显示“The secret word is needle”文字的画面，被嵌入到了由七部完整的 AlphaGo 纪录片拼接而成的视频中。

Gemini 1.5 论文中介绍了基于视频的“Needle in a Haystack”，图片来自《Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context》（第 110 页）

“Needle in a Haystack”方法的局限与影响

尽管“Needle in a Haystack”方法应用广泛，但它也存在一些局限性：

• 首先，这是一个模拟任务，可能与现实世界的应用场景不符。
• 其次，它仅评估信息的查找能力，而不涉及逻辑推理或理解能力。
• 再者，随着上下文范围的扩大，对所有可能的“海”大小和“针”位置的组合进行评估，其成本将越来越高。

尽管存在这些缺陷，该测试却凸显了长上下文模型的一项重要功能：即能从海量数据中迅速搜寻和提取信息。这一功能的重要性不容小觑，它不仅能提升研究效率，还能达到前所未有的数据分析水平——甚至可能用于监控。

值得注意的是，这种信息检索方式与检索增强生成（RAG）不同，它是在一个连贯的大型上下文中进行，而不是从外部资源中提取信息。

2.2 对长篇文档进行深入分析（推理和概括）

尽管" Needle in a Haystack "测试主要关注信息检索能力，但还有其他评估方法用于检测大语言模型在处理长篇内容时的推理、解读和综合信息的能力。这些评估方法旨在检验模型是否能够进行更高级的推理，而不仅仅是寻找数据的具体位置。

以下是属于此类的几种评估方法：

文学问答任务

书籍是长篇文档的经典例子。NOVELQA[14] 这样的基准测试就是用来评估模型处理文学小说的能力，文档长度可达 200K 个 tokens。这个测试包含了针对 88 本英语小说的问题（这些问题由人类编写），涵盖了公版书和受版权保护的作品。其他数据集，比如NoCha[15]，也采取了相似的评估方式。

在这里插入图片描述

插图说明：这张图表展示了来自 NovelQA 数据集[14]的两个示例问题，这些示例取自《NovelQA: Benchmarking Question Answering on Documents Exceeding 200K Tokens》[14]一文。

在含有隐蔽相关信息的长篇文章中进行逻辑推理

FlenQA[16] 通过将相关信息嵌入到较长的非相关信息中，生成了多个不同长度的上下文版本。这种方法有助于我们了解，随着上下文长度的增加，大语言模型的处理能力如何逐步下降。

在 FlenQA 的一个任务示例中，相关信息（以深红色表示）被穿插在大量无关信息之中。此图表摘自《Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models》[16]一文。

针对特定领域的逻辑推理

• 医疗领域：LongHealth[17] 基准测试采用了 20 个虚构的病例（每个病例包含 5-7 千字），以此来评估模型在医学推理方面的能力。
• 金融领域：DocFinQA[18] 则通过让模型处理长达 150 页的金融文档（包含超过 100K 个 tokens）来对其进行挑战。

总结摘要任务

对于大语言模型而言，能够有效地压缩长篇文档的内容是一项至关重要的能力，因为它可以让用户在不阅读全部内容的情况下，快速掌握大量文本中的关键信息。这一点在研究领域、商业分析和法律实践中尤为重要，这些领域的专家经常需要将大量资料精炼为简洁的报告。

但是，如何评价总结摘要的质量是一项复杂的任务。总结摘要不仅要求对全文有深刻的理解，还要求能够精准地识别并整合关键信息。 什么样的总结摘要算是优质，往往取决于个人主观判断和具体上下文。

目前，总结摘要质量的评估多依赖于将模型的输出与人工编写的总结摘要进行对比，这种方法并不完美，可能无法涵盖所有合理的总结摘要方式，也可能会忽略那些用词不同但含义准确的总结摘要。

为了应对这些挑战，LongBench[19] 和 ∞Bench[20] 等基准测试应运而生。LongBench 涵盖了多种文档类型（如政府报告、会议纪要、新闻报道）的摘要任务，文档长度可达 15K 字；而 ∞Bench 则进一步拓展了摘要任务的挑战边界，包含长度可达 100K 个 tokens 的文档。尽管这些基准测试颇具价值，但该领域仍在探索更为有效的评估方法，以便更精准地评价高质量总结摘要的细微差别。

若想深入了解这一主题，可以查阅《An Empirical Survey on Long Document Summarization: Datasets, Models, and Metrics》[21]这一文章。

2.3 为即时模型训练提供上下文学习支持

长上下文模型最酷的应用之一便是在上下文学习（ICL）方面的增强能力。ICL 技术使得模型能够即时从提示词中的示例中学会处理新任务。得益于更大的上下文窗口，我们现在能够纳入成百上千的训练样本，甚至是那些复杂且篇幅较长的任务，比如文本摘要。

这项技术改变了游戏规则。它让开发人员可以跳过针对特定领域的模型微调，直接通过 ICL 让模型迅速适应新任务。

Many-shot ICL

DeepMind 针对多样本 ICL[22] 的研究表明，当提示词中包含更多示例时，模型在不同任务上的表现有显著提升。通过扩充到成百上千的示例，模型能够克服预训练中的偏见，并处理更为复杂的问题。

通过在提示词中增加更多的示例（即“shots”），相同的 LLM 模型在多种任务上都能展现出更好的性能。例如，将情感分析任务的示例从 32 个增加到 2048 个，模型的表现提升了 18.2 %。此图摘自《Many-Shot In-Context Learning》[22]。

这一理念不仅仅局限于性能提升。Anthropic 公司在其“Many-shot Jailbreaking”[23]项目中的研究发现，虽然仅凭几个样本无法突破模型的安全防线，但是如果有数百个样本，就能做到这一点——这一发现既展示了这种方法的威力，也揭示了其潜在的风险。

例如，我们可以看到，仅仅几个样本是无法诱导 LLM 生成有害内容的，但是当样本数量增加到数十个甚至数百个时，就能让模型忽视其“安全围栏”。此图来自于《Many-Shot Jailbreaking》[23]。

翻译低资源语言

在低资源语言的翻译方面，长上下文模型展现出了非凡的价值。在 Gemini 1.5 的技术报告[13]中，以 Kalamang 语为例，这种语言的使用者不足200人，网络资源也非常有限。通过向模型输入 500 页的语法资料、一个包含 2000 个词条的双语词汇表以及 400 个对照句子（总共 250 k个 tokens），模型不仅能翻译 Kalamang 语，还能进行语音转录。

这种方法同样适用于其他低资源语言，并且随着示例数量的增加，翻译性能也在不断提升。对于濒危语言的保护和使用来说，这无疑是一个充满希望的新进展。

03 Discussion

对于更长上下文窗口的追求正在语言模型领域掀起一场激烈的竞赛，上下文窗口的规模正以惊人的速度扩张。这种扩张迫使我们需要开发新的评估手段，以便更准确地把握这些模型的实力与短板。

尽管已经涌现出了一批针对长上下文模型的评估基准（如 SCROLLS[24]、LongBench[19]、∞BENCH[20]等），但仍有许多疑问尚待解答：

• 规模的权衡：当上下文长度不断增加时，模型在安全性、偏见和指令执行方面的表现会如何波动？
• 多语种表现：大多数评估基准都着眼于英语（CLongEval[25] 等评估基准除外，其中也涵盖了中文的评估）。那么，对于非英语系的语言，随着上下文的增加，其表现又会与英语有何不同？
• 性能衰退：模型在处理更丰富上下文的同时，是否会牺牲掉某些特定能力，比如编程技能或是创造力？
• 现实影响：当模型能够处理整本书籍、完整个人经历，甚至是稀缺语言的详尽数据时，我们将面临哪些伦理和现实层面的挑战？

随着大语言模型（LLMs）的上下文窗口不断扩大，我们不仅要了解它们能做到什么，还要探究它们的基本特性可能会如何变化。

目前来看，这场追逐更大上下文窗口模型的竞赛还将持续升温。

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

About the authors

Yennie Jun

Machine learning engineer and AI researcher exploring my curiosity of the world through creative projects

END

本期互动内容 🍻

❓ #技术探讨# 你认为评估长上下文模型最重要的指标是什么？为什么？

🔗文中链接🔗

[1]​​https://arxiv.org/abs/1810.04805​​

[2]​​https://arxiv.org/abs/1910.10683​​

[3]​​https://cdn.openai.com/research-covers/language-unsupervised/language_understanding_paper.pdf​​

[4]​​https://developers.googleblog.com/en/new-features-for-the-gemini-api-and-google-ai-studio/​​

[5]​​https://www.reddit.com/r/OpenAI/comments/1buz5ju/geminis_context_window_is_much_larger_than_anyone/​​

[6]​​https://www.notion.so/Long-Context-Eval-Survey-fe3c69173f2e4eb0b5cd4c973f712626?pvs=21​​

[7]​​https://www.reddit.com/r/singularity/comments/1ausp2k/geminis_nearly_perfect_10_million_context_length/​​

[8]​​https://github.com/Xnhyacinth/Awesome-LLM-Long-Context-Modeling?tab=readme-ov-file#11-Benchmark-and-Evaluation​​

[9]​​https://twitter.com/GregKamradt​​

[10]​​https://github.com/gkamradt/LLMTest_NeedleInAHaystack​​

[11]​​https://blog.langchain.dev/multi-needle-in-a-haystack/​​

[12]​​https://arxiv.org/abs/2407.11963​​

[13]​​https://arxiv.org/abs/2403.05530​​

[14]​​https://arxiv.org/pdf/2403.12766​​

[15]​​https://arxiv.org/abs/2406.16264​​

[16]​​https://arxiv.org/pdf/2402.14848v1​​

[17]​​https://arxiv.org/pdf/2401.14490​​

[18]​​https://arxiv.org/pdf/2401.06915​​

[19]​​https://arxiv.org/pdf/2308.14508​​

[20]​​https://arxiv.org/pdf/2402.13718​​

[21]​​https://dl.acm.org/doi/10.1145/3545176​​

[22]​​https://arxiv.org/pdf/2404.11018​​

[23]​​https://www-cdn.anthropic.com/af5633c94ed2beb282f6a53c595eb437e8e7b630/Many_Shot_Jailbreaking__2024_04_02_0936.pdf​​

[24]​​https://arxiv.org/abs/2201.03533​​

[25]​​https://arxiv.org/abs/2403.03514​​

原文链接：

​​https://www.artfish.ai/p/long-context-llms​​