8. 2024：上下文变长，AI 开始处理成套资料

来源：大模型技术演进

2024 年 2 月 15 日，Google 发布 Gemini 1.5。在发布材料中，一份 402 页的阿波罗 11 号登月任务记录被交给模型，作为回答问题、关联事件和细节的依据。同一次发布还展示了围绕一部 44 分钟默片进行分析的能力。这些是厂商公布的演示，不是本文作者的实测。Gemini 1.5 原始发布公告

那份任务记录，让一个原本抽象的指标变得具体起来。几百页材料意味着一段持续发生的历史：不同的人在不同时间说话，一项判断可能在后面被修正，一个细节的意义需要联系前后的事件才能看清。人们开始期待，AI 不只是解释一段摘录，还能帮助自己进入一整批材料，沿着问题往返查阅。

这与最初体验聊天机器人的惊讶有所不同。此前，人们常问：“它怎么知道这么多？”现在，一个新的问题变得有吸引力：“我把这些资料交给它，它能帮我发现什么？”模型已有的知识依然重要，但本次提供的材料开始承担更多工作。

这种变化也触及了应用开发中的日常困难。面对一本长书、一组研究报告或一个代码项目，用户往往需要先挑选片段，再复制到对话里。摘录太少，背景不够；复制太多，又会超过限制。更长的上下文让开发者有机会重新安排这一步：把更完整的材料放到模型面前，再围绕材料设计问题。

不过，发布会展示与普遍可用之间仍有距离。Gemini 1.5 首发时，百万 token 窗口属于面向有限开发者和企业客户的实验性预览；公告提到的千万 token 则是研究测试。不能把这些数字理解为当日所有用户都能使用的产品规格。首发时的访问范围

要理解 2024 年的分量，需要把这次演示放进此前的积累，以及随后真正开放给开发者、进入资料产品的过程里。

长上下文并不是在 2024 年突然出现的

2023 年 5 月 11 日，Anthropic 已将 Claude 的上下文窗口扩展到 100K token，并宣布通过 API 提供，尚未接入的开发者仍需申请访问。官方当时做过一个演示：把《了不起的盖茨比》全文放进输入，改动其中一处句子，再让模型找出异常。这个例子把长输入和具体任务连在了一起，但找回一处改动，仍然不同于完整理解整本小说。Claude 100K 公告

到当年 11 月，更多开发者开始获得长输入的选择。11 月 6 日，OpenAI 公布具有 128K 窗口的 GPT-4 Turbo，向付费 API 开发者提供预览；11 月 21 日，Claude 2.1 将窗口扩展到 200K，API 已可用，网页产品中的 200K 使用范围则限定于 Claude Pro。GPT-4 Turbo 公告、Claude 2.1 公告

因此，2024 年的变化不宜写成“模型第一次能读长文”。更值得注意的是，容量继续扩大，访问范围继续拓展，围绕长材料的应用也变得更具体。

2024 年 6 月 27 日，Google 宣布向所有开发者开放 Gemini 1.5 Pro 的 200 万 token 窗口；此前在 I/O 公布这一容量时，访问仍通过候补名单进行。从实验演示到开发者能够调用的能力，中间经历了分阶段开放。Gemini API 6 月更新

下面的几个节点，记录的是各自产品或接口的历史开放状态，不是一份能直接判定综合能力高低的排行榜：

时间	代表节点	当时需要分清的范围
2023 年 5 月	Claude 100K	API 已提供；新接入仍需申请
2023 年 11 月	GPT-4 Turbo 128K、Claude 2.1 200K	前者为 API 预览；后者网页长窗口限 Pro
2024 年 1 月	Kimi 开放平台公测，moonshot-v1 最高 128K	模型 API 与助手产品分别理解
2024 年 2 月	Gemini 1.5 百万 token 演示与预览	有限访问，不能等同全面开放
2024 年 6 月	Gemini 1.5 Pro 200 万 token	向所有开发者开放访问

其中，Kimi 的日期与 API 容量来自月之暗面在 2025 年 2 月发布的官方回顾，而非当日公告。它明确记录：开放平台于 2024 年 1 月 31 日开启公测，推出最高支持 128K 的 moonshot-v1 系列。Kimi 官方回顾

中文市场里的 Kimi，把长材料变成一个鲜明的产品入口

在中国市场，Kimi 是这一阶段不可忽略的产品。长上下文不再只出现在面向开发者的规格表里，也成为普通用户认识一个助手的理由。

2024 年 3 月 18 日的同期报道记录，月之暗面宣布围绕“200 万字”长上下文开启 Kimi 产品内测，并允许用户申请体验。这里记录的是当时的发布消息与产品定位；本文未获得可访问的原始公告，也没有对这一容量进行独立测试，因此不把宣传中的“无损”解释为对任何材料都能准确理解，更不把内测写成全面开放。当时的发布报道

这个入口为什么容易被理解？因为用户手头原本就有需要处理的长材料。让助手围绕一本手册、一批笔记或多份报告回答问题，比泛泛地问“你有什么能力”，更容易连接到实际需要。用户也更容易判断答案有没有读到自己关心的地方。

从产品设计看，可以这样理解它的意义：长上下文让竞争从“回答一个问题”，进一步走向“围绕一套材料持续工作”。 这是一种对应用方向的分析，不能据此推出长窗口就是当时产品增长的唯一原因。

还要留意宣传口径的差别。“200 万字”描述自然语言材料的规模，128K token 描述模型接口的窗口；不同语言、文本结构与分词器，会改变文本对应的 token 数量。它们不能按固定比例换算，更不能据此推断 Kimi 网页内测和公开 API 在同一时刻拥有相同上限。

上下文窗口，到底扩大了什么

可以先把上下文理解为：模型在当前这次计算中能够参考的指令、问题和材料。 对一个应用来说，它可能包含用户刚提出的要求、保留下来的聊天历史、上传文档的内容，以及检索或工具返回的结果。

上下文窗口则规定了可处理范围的上限。Token 是模型使用的处理单位，不必对应一个汉字或一个完整单词。文本中有代码、英文缩写、数字和标点时，分词结果也可能变化。图片、音频和视频进入多模态模型后，还会以相应的表示占用处理资源，不能用纯文字的直觉简单估算。

这道上限扩大后，一个直接变化是：模型有机会在同一次回答中参考更多背景。问题不再必须被拆成互相孤立的短片段。前面定义过的术语、后面出现的反例，以及分散在多份文件中的条件，可以被放进同一个输入范围。

但窗口长，不意味着输出同样长。模型或接口通常还有单独的输出限制；具体如何计算输入和输出预算，要看对应版本的说明。能够输入一本书，也不能直接推导出它能一次生成一本同样长的书。

更长的输入也不等于永久记忆。今天把一组学习笔记放进上下文，并不会自动更新模型参数。明天是否还能参考它们，取决于应用有没有保存材料，并在需要时再次提供。用户在界面上看到一个持续存在的笔记库，背后仍然需要文件存储、资料选择和上下文组织。

这与前几篇的分工一致：模型提供处理能力，产品安排资料和交互。长窗口扩大了模型这次能够看见的范围，没有替代应用对资料的管理。

从一段摘录，到成套资料，任务本身发生了变化

接着第 7 篇的个人复习助手看。假设你已经保存了半年的笔记，其中包括课程记录、做题错误和小项目总结。现在想知道：“哪些概念我反复弄错，它们之间有没有共同原因？”

这是一个用于解释设计的假设项目，并非本文对某个产品的实测。

如果助手每次只看到当前一段笔记，它可以解释这段内容，却很难判断“反复”。把经过选择的一整组记录交给模型，它才有机会对照不同时间的描述，找出同一个误解在不同任务里的表现。

任务由此从局部处理，变成了跨材料关联。例如，某篇笔记说“模型记住了上传文件”，另一篇把 RAG 写成“训练自己的模型”。助手如果同时看到它们，就有机会提出一个值得复习的共同问题：你是否把本次提供的上下文、外部资料检索和参数训练混在了一起？

这里的价值来自完整背景。用户不必事先知道所有关联在哪里，系统才有机会帮忙发现联系。但“有机会”仍需要检验：它可能遗漏一次关键错误，也可能把措辞相近、含义不同的记录合并起来。

长上下文也可以改变比较任务的组织方式。比较两版项目要求时，直接提供完整的两版文档，有助于同时参考修改前后的限定条件；逐段摘要再比较，则可能在摘要阶段先丢掉细节。另一方面，完整文档包含的大量无关内容，也可能让任务更费时。选择哪种方式，要看你需要保留什么信息。

因此，成套资料的应用不能只停在“支持上传很多文件”。还要明确用户要做的是查找、比较、归纳，还是追踪变化；这些任务对证据范围的要求并不相同。

NotebookLM，把资料组织与核查做成使用体验

第 5 篇介绍过 NotebookLM 在 2023 年的起点。到了 2024 年 6 月 6 日，Google 宣布它升级使用 Gemini 1.5 Pro，并扩展到 200 多个国家和地区。更新增加了 Google Slides 与网页 URL 等来源，还让内联引用可以直接定位原文段落，提供常见问题集（FAQ）、简报和学习指南等资料组织方式。NotebookLM 6 月公告

这些变化说明，模型的容量指标需要经过产品设计，才能变成用户能够反复使用的工作方式。用户需要知道自己选了哪些来源，回答依靠哪一段，以及接下来怎样把材料整理成有用的成果。

比如，面对几份课程笔记，摘要可以帮助进入主题；学习指南可以把材料转成复习线索；原文定位则帮助判断一句总结有没有依据。生成和核查靠得更近，用户就更容易在阅读中修正理解。

这里也有一个必须保留的区别：NotebookLM 使用某个长上下文模型，不能证明它把用户上传的全部内容在每轮都原样塞进窗口。上传限制、来源组织和模型调用策略，是产品层面的设计，不能单凭底层规格倒推内部实现。

同样，后来的音频概览等功能属于后续演进，不应回填到这个 6 月版本。历史中值得记录的，是当时已经明确出现的组合：更强的材料处理能力，与来源管理、文档组织和核查入口一起进入产品。

长上下文和 RAG，为什么会继续共存

看到窗口增长，一个自然的问题是：既然整份材料都能放进去，第 5 篇介绍的检索还有必要吗？

答案取决于资料范围和任务。长上下文改善的是“这次可以提供多少材料”；RAG 处理的是“从外部资料里应该选择什么”。它们作用的位置不同。

如果你已经明确要比较两份不太长的文档，完整提供它们可能是一种直接的设计。应用少了一层片段筛选，也减少了相关内容在检索阶段被漏掉的机会。如果资料是不断增长的数万份文件，就不能指望每次都把整个库交给模型：不仅可能装不下，也会重复处理大量不相关内容。

两者组合，可以先检索出相关文档，再把更完整的章节、邻近段落或多份相关材料放进长窗口。检索负责缩小范围，长上下文保留更充分的背景，生成模型再综合回答。这是一种应用设计思路，不是某款产品内部机制的断言。

仍用复习助手比较：

用户的问题	材料选择更需要考虑什么
“哪条笔记记录了那次 DNS 报错？”	找到具体记录，关键词与语义检索都可能有价值
“本周五篇笔记中，哪些概念互相关联？”	保留已知的五篇材料及其上下文，便于跨篇比较
“我两年的学习方向怎样变化？”	需要覆盖不同时间的代表材料，不能只取几段相似文本

第三个问题尤其说明，窗口和检索都需要围绕任务设计。只把前几份文档放满窗口，不等于覆盖两年；只取最相似的几个片段，也未必足以代表整体。按时间组织资料、分阶段归纳，再回到原文核对，可能比单纯加大输入更合适。

长上下文没有让资料解析失去作用。表格的行列关系、版本标签和段落顺序如果在导入时被破坏，更大的窗口只会容纳更多已经损坏的材料。前面知识库篇讨论的输入质量问题，仍然存在。

装得下、找得到、推理得对，是三个层次

长窗口的演示中，“大海捞针”测试经常出现：把一条目标信息埋在很长的文本里，再问模型能否找回。它帮助检验信息检索，却不能独自代表所有长材料任务。

2023 年 7 月公开的《Lost in the Middle》研究，考察了多文档问答和键值检索。作者发现，在所测模型与任务中，相关信息的位置会显著影响表现，放在开头或结尾往往比放在中部更容易利用。这项结果提醒人们关注实际利用能力，但不是对所有未来模型的永久定律。Lost in the Middle 原始论文

2024 年 4 月公开的 RULER，则将评测扩展到多项信息查找、多跳追踪和聚合等任务。它追问的是：模型即使能找回一条信息，能否同时处理多条线索，再完成关联和统计？研究中，较简单检索任务的好成绩并没有自动延续到更长、更复杂的输入。RULER 2024 年初稿

这两项研究与产品演示放在一起，形成了一个更成熟的判断方式。窗口标称长度告诉你输入可能被接受；检索表现告诉你特定信息能否被找回；跨材料任务则进一步检验模型是否正确使用了这些信息。

假设学习记录中有三条信息：“最初准备做 PDF 导入”“试用版暂时只支持粘贴”“后来确认下个月再评估 PDF”。助手找到每条记录，仍可能错误总结为“现在已经支持 PDF”。问题不在材料没放进去，而在它没有正确处理时间和状态。

判断自己的应用，不妨让问题覆盖这几个层次：能否定位一条明确记录，能否比较两份要求，能否解释一项结论由哪些材料支持。结果要能回到原文检查，尤其要看否定、例外和后来的修订。这些是帮助理解质量的任务例子，不是要求读者现在安装一套评测系统。

容量变大以后，等待和成本进入设计中心

读一整套材料与读几段摘录，通常需要不同的计算资源。许多生成式语言模型先处理输入，再逐步生成输出；这两段常分别称为 prefill 和 decode，可以先理解为“处理已有材料”与“继续生成回答”。

用户看到的等待也有两种：提交后多久开始出现第一个字，以及开始回答后生成得多快。长输入会让前一段工作更突出；不能只观察文字流出速度，就判断整次任务是否快。

月之暗面与清华研究者在 2024 年的 Mooncake 论文中，讨论了服务 Kimi 时如何分离输入处理与生成、管理 KV cache 并调度请求。第 7 篇已经介绍过 KV cache，它保存部分计算结果，减少重复计算。这里的发展说明，长上下文成为服务能力，还依赖推理基础设施。Mooncake 2024 年初稿

论文的性能实验采用请求轨迹重放和替代模型，本文不把实验增幅写成全部真实业务的实测提升。对入门者更有价值的认识，是容量、速度和同时服务多少用户，需要共同考虑。

如果用户围绕同一份长手册连续问十个问题，每次重新处理全部输入，会产生重复工作。Google 在 2024 年 6 月开放 200 万 token 的同一公告中，也介绍了 Gemini API 的上下文缓存，用来减少多次请求共享相同输入时的成本。当时的缓存发布说明

缓存复用的是计算或服务状态，不等于模型永久学习了材料，也不能保证回答正确。它是否省钱、省多少，以及是否需要承担存储费用，要按对应服务的历史或当前规则判断；本篇不拿今天的价格倒推 2024 年的使用成本。

因此，一个好用的资料助手往往需要做选择：哪些内容本次必须完整保留，哪些可以先检索，哪些计算值得复用，哪些结果要让用户核对。更大的窗口提供了空间，应用设计决定空间怎样被使用。

2024 年留下的变化，是资料成为工作的中心

从阿波罗任务记录的演示，到 Claude、Kimi 的长材料入口，再到 NotebookLM 的来源组织，这一阶段让 AI 应用有了一个更清晰的对象：用户正在处理的一套资料。

模型能力的发展，让更完整的背景有机会进入同一次任务；API 的开放让开发者能够构建自己的应用；引用、检索、缓存和推理服务，则帮助把这种能力变成可持续使用的过程。它们没有互相替代，而是在不同位置补齐同一项工作。

对于准备开发个人项目的人，一个重要变化是：不必只围绕“生成一段内容”设计功能，也可以围绕“帮助用户理解已有材料”设计体验。发现关联、比较版本、追踪学习变化，都可以成为具体目标。判断有没有做到，仍然要回到材料和用户真正需要的结果。

长上下文扩展了信息的规模，接下来的变化还会扩展信息的形态。文档里的图表、相机拍到的画面、正在发生的语音对话，逐渐进入同一条应用发展线。下一篇将讨论 GPT-4o、Gemini 等模型，看看 AI 能看、能听之后，人与软件的交互怎样进一步变化。

---

本文属于第 0 部分“大模型发展史”；全系列观察截止日期为 2026 年 10 月 3 日。产品与接口能力按文中历史阶段理解。复习助手、项目记录和文档比较均为教学构造示例，不是产品实测结果。

---

上一篇：07｜2023—2024：模型可以下载和改造，开放生态扩大开发选择

下一篇：09｜2024：模型能看、能听，交互从文字走向多模态

返回：第 0 部分大纲