128K 上下文到底是什么意思？大模型的“记忆容量”可能和你想的不一样

如果平常经常用大模型，大概很难绕开这些数字：

32K、128K、200K、1M……

每隔一段时间，总会有模型厂商站出来宣布：

我们的上下文又变长了！

然后参数表里的数字越来越离谱，给人一种非常朴素的感觉：

上下文越长，是不是就代表模型记性越好？

再进一步：

128K 上下文，是不是代表模型脑子里最多只能装 128K 的东西？

我之前其实也很容易这么理解。

毕竟“上下文窗口”这个名字听起来就很像某种内存容量：

1
模型脑袋
2
┌────────────────────┐
3
│ 最大记忆容量：128K │
4
└────────────────────┘

塞满之后：

抱歉主人，脑容量已满，请购买 256K 豪华扩容包 (0x0)

但真往下面研究后会发现，Context Window（上下文窗口）并不是这么回事。

它和“模型聪不聪明”“模型知道多少东西”“模型记忆力有多强”，其实是几件不同的事情。

这篇先不碰 Transformer 底层，也不讲那些一眼看过去就容易让灵魂暂时离开身体的公式。

我们先把最基本的逻辑理清楚。

先说 Context 到底是什么#

Context（上下文），平常翻译成“上下文”。

但在大模型这里，它不只是语文课上那种：

请联系上下文理解作者思想感情。

它更准确的意思是：

模型在当前这一次任务里，可以直接拿来参考的信息。

比如我们正在聊天。

前面我说：

这个项目数据库用 PostgreSQL。

聊了十几轮之后又问：

那连接池怎么配比较好？

如果前面那句“使用 PostgreSQL”还在模型当前的 Context 里，那么模型就能直接把这个条件拿过来继续用。

实际上，一个大模型应用里的 Context 往往比我们眼睛看到的聊天记录复杂得多。

里面可能有：

用户之前说的话
模型之前的回复
System Prompt（系统提示词）
上传的文件
搜索结果
Agent 的工具调用结果
程序日志
当前任务需要临时塞进去的其他资料

所以我现在更喜欢把 Context 理解成：

模型当前工作桌上摊着的所有资料。

注意这里有两个关键词：

当前。

以及：

摊在桌上。

它并不代表这些东西已经永久刻进模型脑子里了。

那 Token 又是什么？#

然后就轮到另一个经常被拿来当单位，却很容易让人迷糊的东西：

Token（词元 / 标记）。

128K 上下文里的这个 K，数的就是 Token。

不过“词元”这个翻译多少有点骗人。

看到“词”，很容易以为：

一个词就是一个 Token？

并不是。

Token 更接近：

模型把文本切碎之后，真正拿去计算的基本单位。

比如一段文字，经过 Tokenizer（分词器） 处理以后，可能被拆成很多 Token。

一个 Token 有时候是：

一个英文单词
一个单词的一部分
一个汉字
几个字符
一个标点
某种特殊符号

具体怎么切，和模型使用的分词方式有关。

所以：

128K Token

并不等于：

128K 个汉字。

更不能直接说：

等于多少页 PDF。

有时候英文一个长单词能被拆成好几个 Token；中文、代码、标点的情况又不一样。

所以以后看到：

“支持 128K 上下文”

最安全的理解就是：

这套模型和推理系统允许当前任务里存在大约 128K 个 Token。

Context Window：一张摊给AI的桌子#

接下来就是今天真正的主角：

Context Window（上下文窗口）。

这里的 Window 当然不是 Windows 的窗口 (0x0)。

它表示的是：

模型一次运行时，允许直接处理和参考的上下文范围。

我觉得最好理解的方式还是：

把模型想象成坐在一张桌子前工作。

现在可可萝要帮主人分析一个项目。

桌子上可能摆着：

PRD
源代码
API 文档
历史讨论
测试日志
错误记录

如果桌子只能放 10 本资料，那么其他东西就暂时放不上来。

如果桌子扩大十倍，就能同时摊更多东西。

这就是大 Context Window 最直接的价值：

一次能把更多资料放到模型面前。

32K 的桌子小一点。

128K 大一点。

1M：

主人直接给可可萝租了个仓库。

听起来很爽。

但问题也从这里开始了。

桌子变大，不代表人也突然变聪明了#

这是我觉得整个概念里最关键的一点。

我们很容易下意识把：

上下文大

理解成：

模型记忆力强。

但实际上：

Context Window ≠ Intelligence

也就是：

上下文窗口大小，不等于模型智力。

同样：

Context Window ≠ Model Knowledge

上下文窗口也不等于模型拥有多少知识。

模型训练时学到的编程、语言、数学、常识，并不是每天像聊天记录一样全部塞在 Context Window 里面。

那些能力主要已经融进模型参数里了。

Context 更像：

这次考试允许带多少资料进考场。

而模型本身的能力则是：

坐在考场里的这个人到底会不会做题。

于是就会出现一个很有趣的情况。

学生 A：

只允许带 20 页资料，但本身很强。

学生 B：

允许推一辆购物车的资料进去，但本人看见题目就开始挠头。

那显然不能说：

B 的上下文大，所以 B 一定更聪明。

大上下文只是：

给了模型更多“可参考信息”。

它没有自动送模型一颗新脑子。

“能看到”和“能用好”是两回事#

假设现在有两个模型。

参数表都写着：

128K Context Window。

然后我给它们塞同样一份 100K Token 的大型项目记录。

里面有：

当前需求
旧需求
废弃方案
新方案
测试记录
一堆日志
一些已经被否决的讨论

模型 A 看完以后说：

当前最终方案是 PostgreSQL，前面的 MySQL 只是历史讨论，所以这里应该按 PostgreSQL 继续设计。

很好。

模型 B：

根据上下文，我建议使用 MySQL。

我：

啊？

B：

因为第 63 页提到过。

我：

那句话下面三行不是写着“该方案已废弃”吗？

这时候两个模型：

1
Model A：128K
2
Model B：128K

规格看起来完全一样。

但实际使用体验已经天差地别。

于是这里又会出现一个概念：

Effective Context（有效上下文）。

“Effective”一般翻译成“有效的”。

不过这里不是说：

超过某个位置以后的 Token 变成了无效 Token。

它更接近：

模型到底能在多长、多复杂的上下文里，稳定地把信息用对。

所以：

Maximum Context ≠ Effective Context

也就是：

最大允许输入长度，不等于模型实际能够同等质量利用的信息范围。

这一点非常重要。

因为厂商参数表一般很方便告诉你：

我支持 128K。

但参数表通常不会顺手再写一句：

“顺便说一下，塞到后面以后我可能有点找不到北。”

可可萝从大量新旧资料中连接出当前有效线索，区分 Maximum Context 与 Effective Context

那上下文是不是越大越好？#

这个问题就不能简单回答“是”或者“不是”了。

大上下文当然有非常明显的好处。

比如：

阅读长文档
看大型代码仓库
分析一整套项目资料
处理超长聊天
跑长时间 Agent
阅读字幕、日志、论文

如果 Context Window 太小，有些资料甚至连上桌的资格都没有。

比如你现在要分析：

80K Token 的代码和文档。

模型最大上下文：

32K。

那不是“分析得好不好”的问题。

而是：

有一大半压根进不来。

所以大上下文首先解决的是：

有没有机会看到更多资料。

这当然很有价值。

但它没有自动解决第二个问题：

看到这么多以后，能不能处理好。

一百万张纸都摆上来了，然后呢？#

我们继续用桌子这个比喻。

假设原本桌上只有十张纸。

其中一张写着：

数据库使用 PostgreSQL。

让你找出来。

很简单。

现在桌子巨大无比，上面有一百万张纸。

其中：

2000 张提到 PostgreSQL
3000 张提到 MySQL
500 张是旧版本
100 张是测试数据
30 张互相矛盾
还有 80 万张和当前问题关系不大

真正有效的最终结论藏在中间。

这时候问题已经不是：

“桌子够不够大？”

桌子早就够大了。

新的问题变成：

你到底找不找得到正确的那张？

以及更麻烦的：

如果答案不是写在某一张纸上，而是需要把第 3 万、18 万、52 万和 91 万张纸的信息组合起来才能推出来呢？

这就开始进入我们下一篇要讨论的东西了。

所以 128K 到底代表什么？#

到这里其实可以给 128K 下一个很简单的定义：

128K Context Window 表示这套模型和推理系统，一次任务允许直接带入大约 128K Token 的上下文。

它首先描述：

“能带多少资料进来。”

而不是：

“模型有多聪明。”

也不是：

“模型永久能记多少东西。”

更不是：

“128K 以内绝对聪明，128001 就突然脑死亡。”

把这几个概念拆开之后，很多模型参数就会好理解很多。

以后看到：

1M 超长上下文！

第一反应可以先是：

哦，桌子挺大。

然后再继续问：

桌前坐着的是谁？

不过新的问题也来了#

如果上下文窗口只是桌子大小，那么：

为什么桌上的资料越来越多以后，模型有时候反而会开始漏信息、搞混关系，甚至被已经废弃的旧内容带跑偏？

我们平常经常说一句：

“模型的注意力有限。”

但 Attention（注意力机制）到底是什么意思？

真的存在一种：

“模型只有 100 点注意力，一百万 Token 一人分一点，最后谁都分不到”

这样的东西吗？

为什么：

在 100 万 Token 里找一句暗号

和：

根据分散在 100 万 Token 中的十几条信息完成推理

其实是两种完全不同的难度？

下一篇我们就继续拆这个问题：

《上下文越长越好吗？为什么大模型“看得见”，却不一定“用得好”》

这一篇先记住一句话就够了：

Context Window 决定有多少资料能摆到模型面前，而不是模型面对这些资料时究竟能有多聪明。

桌子可以买大的。

脑子这种东西，目前还没有“加购 512K 智力扩展包”这种好事 (*/ω＼*)

系列文章#

这是「大模型上下文」系列，四篇按顺序读会更顺：

128K 上下文到底是什么意思？大模型的“记忆容量”可能和你想的不一样（本文）
上下文越长越好吗？为什么大模型“看得见”，却不一定“用得好”
为什么 128K 模型塞不进第 128001 个 Token？真正拦住它的可能根本不是模型
如果不管模型会不会胡说八道，大模型理论上能拥有无限上下文吗？

参考资料#

Vaswani, A. et al. (2017), Attention Is All You Need Transformer 架构的经典原始论文。
OpenAI, What are tokens and how to count them? 用于了解 Token 的基本概念，以及文本长度和 Token 数量为什么不能简单一一对应。
Hugging Face Transformers Documentation, Tokenization algorithms 介绍 BPE、WordPiece、Unigram 等常见 Tokenization（分词）方式。

音乐

音乐