上下文：AI的「工作记忆」

上下文：AI的「工作记忆」

当你与一位AI助手对话时，有没有想过它是如何“记住”你们之前的交流内容的？它如何知道十分钟前你提到的那本书的名字？它如何在长篇文档中找到你刚才指出的那段话？这些看似简单的行为背后，隐藏着一个深刻的问题：AI模型是如何理解和使用上下文的？

这不仅仅是技术细节问题。如果不理解上下文的工作原理，你就无法理解为什么有时候AI会“忘记”重要信息，为什么长对话会变得“健忘”，为什么精心设计的提示词有时有效有时失效。上下文，就像人类的工作记忆一样，是AI理解世界、处理信息的第一线战场。

本章将从认知科学和计算机科学双重视角出发，彻底回答“上下文到底是什么”这个问题。我们会看到，AI的上下文与人类的工作记忆之间存在着惊人的类比关系；我们会深入Transformer架构内部，理解自注意力机制是如何让模型“看到”上下文中的每一个词的；我们还会探索位置编码的数学本质，理解为什么上下文窗口的大小直接决定了模型的能力边界。通过一个完整的对话补全实例，你将直观感受到上下文如何影响模型的输出质量。

准备好了吗？让我们开始这场关于AI“记忆”的探索之旅。

认知科学视角：工作记忆与长期记忆的类比

人类大脑处理信息的方式，为我们理解AI提供了宝贵的启示。在认知科学中，心理学家的一个核心发现是人类记忆系统分为多个层次，其中最关键的两层是工作记忆（Working Memory）和长期记忆（Long-term Memory）。

工作记忆是我们在任意时刻有意识思考时使用的记忆系统。它容量有限——心理学研究表明，普通人一次只能在大脑中同时保持7±2个信息组块。这就像电脑的内存（RAM），是高速但容量有限的临时存储空间。当你心算"25×17"时，你需要在工作记忆中保持中间结果，这就是工作记忆在发挥作用。

长期记忆则像是大脑的硬盘。容量几乎无限，但读取速度慢，需要通过复述、联想等方式将信息从工作记忆转移到长期记忆存储。你昨天吃的午餐内容可能已经模糊，但高中时期最好的朋友的名字却能存储数十年，这就是长期记忆的特点。

AI的上下文机制与人类工作记忆有着深刻的对应关系。当用户向模型输入一段文字时，这段文字就进入了模型的“上下文窗口”——这是一个有限的、临时的存储空间，模型可以快速访问其中的任何位置。上下文窗口的大小（比如4K tokens、128K tokens）就对应着人类工作记忆的容量限制。

但类比不能止步于此。让我们深入思考一下差异。

人类工作记忆的特点是选择性注意。在一间嘈杂的咖啡馆里，你可以专注于面前朋友的对话，同时自动过滤掉周围的噪音。认知科学称之为“鸡尾酒会效应”——大脑会主动筛选哪些信息进入工作记忆的核心区域。

AI的上下文机制也有类似的选择性，但实现方式完全不同。在Transformer架构中，这种选择性通过注意力机制实现。模型并非平等地对待上下文中的每一个词，而是会根据当前任务的需要，动态地决定应该“关注”哪些词。这种关注程度通过注意力权重来量化——一个在当前位置看来更重要的词会获得更高的权重。

让我们用一个具体例子来感受这个过程。假设上下文是这段话：

> "我昨天在图书馆借了一本《百年孤独》，作者是加西亚·马尔克斯。这本书讲述了布恩迪亚家族七代人的故事。"

如果现在的问题是“作者是谁”，模型会激活对“加西亚·马尔克斯”的高注意力权重；如果是“这本书讲述了什么”，权重会集中到“布恩迪亚家族七代人的故事”。同一个上下文，在不同任务下，模型内部的“注意力分布”是不同的。

这种机制让AI拥有了一种“弹性”的工作记忆——容量有限，但访问是灵活的、任务相关的。人类工作记忆也是弹性的：我们可以在有限容量内灵活组合信息，但组合方式受到注意力资源的限制。

理解了这个类比，我们就获得了一个重要的直觉：设计好的上下文，就是帮助模型更高效地使用它有限的工作记忆资源。这意味着你要把最重要的信息放在容易被注意到的位置，要清除无关的干扰信息，要让信息的组织方式符合模型的“认知习惯”。

Transformer自注意力机制：上下文如何被「看见」

如果说认知科学的类比给了我们直觉，那么要真正理解上下文的工作原理，我们必须深入Transformer架构的核心——自注意力机制（Self-Attention Mechanism）。

Transformer是当前大语言模型的主流架构，由Google的研究人员在2017年提出。它的核心创新在于完全抛弃了传统的循环神经网络结构，转而采用注意力机制来处理序列数据。这一设计决策直接导致了上下文能力的飞跃。

自注意力的本质是建立序列内部各元素之间的关联。在处理一段文本时，自注意力允许模型在生成每一个输出时，考虑输入序列中的任意其他位置。想象你在读一篇文章——当你遇到代词“他”时，你需要回顾前文找到这个代词指的是谁。传统的循环网络通过逐步传递隐藏状态来处理这种依赖关系，但这会导致信息在长距离传递中衰减。注意力机制则允许模型直接“查询”任何之前出现过的词，无论距离多远。

具体来说，自注意力机制通过三个关键的向量来实现：查询（Query, Q）、键（Key, K）和值（Value, V）。这三个名字来自信息检索领域的类比：

• **查询**是你当前正在处理的词想要寻找的信息
• **键**是每个词用来被匹配的特征
• **值**是实际包含的信息内容

注意力计算的核心公式可以简化为：

$$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

其中 $d_k$ 是键向量的维度。这个公式做了什么？它首先计算查询和所有键之间的相似度（通过点积），然后用softmax将这些相似度转换为概率分布（注意力权重），最后用这些权重对值向量进行加权求和。

结果就是：对于序列中的每个位置，模型都会得到一个“上下文感知的表示”——它不仅包含该位置本身的语义，还融合了根据当前任务相关性加权后的其他位置信息。

用一个具体的比喻来理解。假设你是一个侦探，正在分析一封信件。每读到一个词，你不是孤立地理解它，而是会问：“这个信中的词和之前读到的哪些词有关联？关联程度如何？”自注意力就是让AI侦探能够系统化地完成这个任务——对于每个词，它都能精确地量化与其他词的关联强度。

让我们通过一个可视化来感受注意力权重的分布。考虑这个句子：

> "因为山姆很累，他决定早点休息。"

对于代词"他"，注意力权重会高度集中在"山姆"上，因为"他"指代的就是山姆。如果用注意力矩阵可视化，你会看到在"他"这一行，"山姆"那一列会有一个非常高的值。

这种机制对于理解上下文至关重要。注意力权重就是模型“看到”的上下文关系。当我们在讨论上下文工程时，一个核心任务就是设计输入的格式和内容，使得在目标任务上，模型能够自然地将注意力集中在正确的信息上。

多头的艺术也是值得理解的。现代Transformer通常使用多头注意力（Multi-Head Attention），即并行运行多组QKV变换。这相当于模型从多个“角度”同时审视上下文关系——一个头可能关注句法依存关系，另一个头关注语义相似性，还有一个头关注位置邻近性。这种并行多视角的处理让模型能够捕获上下文中不同类型的依赖关系。

理解自注意力机制后，我们获得了第二个重要直觉：好的上下文工程，要考虑如何让模型更容易建立正确的注意力连接。这意味着信息应该组织成模型容易发现关联的结构，相关的概念应该靠近放置，指代关系要清晰明确。

位置编码与上下文窗口的数学本质

我们已经知道注意力机制允许模型灵活地访问上下文中的任意位置。但这里有一个关键问题：序列中词的顺序本身也是一种信息，而自注意力机制本身是“位置无关”的。

仔细看前面的注意力公式，你会发现它只依赖于词的内容向量（Q、K、V），而没有考虑词在序列中的位置。如果不加入位置信息，“狗咬人”和“人咬狗”在模型看来可能是完全相同的（只是词序不同），这显然是不合理的。

这就是位置编码（Positional Encoding）存在的意义。研究者们需要在不破坏注意力机制的前提下，向模型注入序列位置信息。

最直观的方法是使用数字下标：给每个位置分配一个整数（1, 2, 3, ...）。但这种简单的方法有两个问题：一是模型可能学到虚假的位置关系（比如位置100和位置101之间的差值总是1），二是训练时见过的最大位置限制了模型的外推能力。

Transformer的原始论文采用了正弦位置编码：

$$PE_{(pos, 2i)} = \sin\left(\frac{pos}{10000^{2i/d_{\text{model}}}}\right)$$

$$PE_{(pos, 2i+1)} = \cos\left(\frac{pos}{10000^{2i/d_{\text{model}}}}}}\right)$$

这个精妙的设计利用了正弦波的周期性。不同频率的正弦波组合可以编码任意大的位置值，而且模型可以从这些固定频率中学习到相对位置关系（因为 $\sin(A-B)$ 和 $\cos(A-B)$ 可以由 $\sin A, \cos A, \sin B, \cos B$ 推导出来）。

后来的模型发展出了更灵活的位置编码方案。RoPE（Rotary Position Embedding，被LLaMA等模型采用）使用旋转矩阵来实现位置编码，它的一个关键优势是能够让注意力权重只依赖于两个token之间的相对距离。ALiBi（Attention with Linear Biases）则直接在注意力分数上加上与距离相关的线性偏置，避免了显式的位置编码学习。

理解了位置编码，我们就可以正式定义上下文窗口的概念。

上下文窗口指的是模型一次能够处理的 token 序列的最大长度。这里的“token”是文本处理的基本单位——对于英文，大约是4个字符或一个单词的一部分；对于中文，通常是1-2个汉字。GPT-4的上下文窗口据报道达到了128K tokens，Claude 3支持200K tokens，而很多开源模型还停留在4K-8K的水平。

上下文窗口的大小是模型设计时确定的硬件和算法约束。在计算注意力时，每个位置都要与所有其他位置交互，时间复杂度是 $O(n^2)$，其中 $n$ 是序列长度。这意味着将上下文窗口翻倍，理论上计算量会增加四倍。这就不难理解为什么更大的上下文窗口意味着更高的训练和推理成本。

数学上，上下文窗口决定了模型能够“同时考虑”的信息范围。超过窗口的历史信息，在标准的自注意力计算中是完全不可见的。这就是为什么我们在长对话后期问一个关于开头提到内容的问题时，模型可能会“忘记”——那个信息根本没有进入当前的上下文窗口。

这个限制产生了上下文工程中一个核心挑战：如何在有限的上下文窗口内，放置最相关的信息。这不仅仅是量的问题，更是组织和策略的问题。

上下文长度与模型能力的Scaling Law

在人工智能领域，有一个被反复验证的规律：模型的能力与模型规模、数据规模和上下文长度之间存在着可预测的幂律关系。这就是著名的Scaling Law。

OpenAI的研究人员在2020年的论文《Scaling Laws for Neural Language Models》中首次系统性地描述了这一现象。他们发现，模型的测试损失（可以理解为预测误差）随着模型参数量、数据集大小和计算量的增加，呈现出平滑的幂律下降趋势。

延伸到上下文长度，研究同样发现了类似的关系。更大的上下文窗口允许模型：

1. 处理更长的文档和对话：这是最直接的能力扩展。128K上下文可以一次处理整本书，而4K上下文只能处理一篇文章。

2. 建立更长的依赖关系：在生成一段文字时，模型可能需要引用开头提出的主题、中间定义的概念和结尾的结论。更大的上下文窗口让这种长距离引用成为可能。

3. 进行更复杂的推理：多步骤推理需要模型在推理过程中同时保持多个中间状态。上下文窗口就像是工作记忆的容量——容量越大，能够同时追踪的逻辑链条就越长。

但这里有一个重要的微妙之处：上下文长度的增加，并不自动带来能力的等比例提升。研究发现，如果只是简单地增加上下文窗口而不相应调整训练策略，模型在超出训练时使用的最大长度后，外推能力会急剧下降。模型可能会在新的位置编码上看似正常地运行，但注意力机制已经无法正确建立远距离的依赖关系。

这催生了长上下文训练（Long Context Training）技术的发展。关键思路包括：

• **渐进式训练**：先用短序列训练，再用逐渐增长的序列长度微调
• **位置编码插值**：将超出训练范围的位置编码“压缩”到训练过的范围内
• **稀疏注意力**：不计算全部 $n^2$ 的注意力，而是只计算局部的或选择性的注意力

这些技术让现代模型能够在超长上下文中保持有效。例如，Claude 3 Opus的200K上下文窗口并非简单的技术噱头——它意味着模型可以同时分析一部中篇小说的全部内容，并在其中进行精确的信息检索和多处内容的关系分析。

对于上下文工程的实践者来说，Scaling Law给了我们一个重要的指导原则：上下文长度是要规划的资源。你应该清楚你的任务需要多大的上下文——太小则信息不足，太大则可能引入干扰且浪费计算资源。更重要的是，你应该学会在有限的上下文中优化信息密度和位置。

对话场景中的上下文失效问题

现在让我们把镜头拉回日常应用。你可能已经注意到，即使模型宣称支持超长上下文，在实际对话中仍然会出现各种“失效”问题：

• 模型在长对话的后期突然忘记了开头的约定
• 在上下文中明确提到的信息，模型仍然“不知道”
• 模型混淆了不同用户/不同会话的信息
• 当上下文接近窗口上限时，模型开始“发疯”

这些现象的根源是什么？让我们逐一分析。

近因偏差与注意力稀释。虽然理论上模型可以访问上下文中的任何位置，但在实践中，注意力权重往往集中在最近的内容上。这类似于人类的“最近效应”——我们更容易记住最近发生的事情。如果你在对话开头提到了一个重要细节，但在后续几十轮对话中都没有再提及，这个细节被正确利用的概率会显著下降。

位置编码的外推问题。即使模型支持足够长的上下文，如果某个位置超出了训练时的最大位置，模型可能无法正确理解那个位置的信息关系。这导致上下文窗口的后半部分（尤其是接近上限的位置）可能“质量较低”。

信息密度干扰。当你塞入大量信息到上下文中时，有用信息可能被稀释。模型需要在整个上下文中进行注意力分配，过多的无关内容会分散模型对关键信息的注意力。这就像在重要的电话号码周围画上成百上千条线，重要的那条反而难以辨认。

计算资源的约束。在实际部署中，许多系统会对推理进行优化以降低成本。一种常见的做法是使用上下文压缩或滑动窗口，即只保留最近的一部分内容，丢弃更早的信息。虽然模型“支持”长上下文，但实际使用时可能只利用了最近的几千个tokens。

截断和系统限制。很多API和服务会对实际传递的上下文长度进行限制。即使模型能力足够，系统层面的配置也可能导致部分上下文信息被丢弃。

让我们看一个具体的失败案例：

> 系统：你是一个客服助手。 > > 用户：我们的订单号是ORD-2024-00123，需要修改收货地址。 > > 用户：新地址是北京市朝阳区建国路88号。 > > [...... 50轮对话后 ......] > > 用户：我的订单改好了吗？订单号是？ > > 助手：抱歉，我没有看到您的订单号。请提供订单号以便我帮您查询。

在这个场景中，订单号ORD-2024-00123在对话开头就提到了，但由于50轮对话的干扰，这个信息要么被上下文截断，要么在模型的注意力竞争中败下阵来。

如何解决这些问题？这就引出了上下文工程的核心策略：

策略一：重要信息显式重复。对于关键的事实（如订单号、用户ID、重要约定），在需要的时候重新提及。好的提示词设计会主动在当前问题附近包含这些关键信息。

策略二：结构化上下文组织。将信息按逻辑结构组织，让相关的内容放在一起。这帮助模型更容易建立正确的注意力连接。

策略三：定期总结和刷新。在长对话中周期性地进行上下文压缩——将之前的对话要点提炼成摘要，让模型在一个“刷新”后的上下文中继续工作。

策略四：使用系统消息和角色设定。利用系统级别的上下文（通常在每次交互中都会传入）来放置不变的重要信息，减少对话历史中的重复。

这些策略将在后续章节中详细展开。现在你已经理解了为什么会出现上下文失效，以及基本的应对思路。

实战：一个对话补全的注意力视角

让我们通过一个完整的实例，将本章的概念串联起来。考虑这个场景：

> 上下文：``` [系统] 你是一个代码审查助手。 [用户] 请审查以下Python函数： def calculate_discount(price, discount_percent): """Calculate the final price after discount.""" discount = price * discount_percent return price - discount

[助手] 这个函数计算折扣后价格的逻辑是正确的...

[用户] 但如果discount_percent是1.5，会发生什么？ ``` > > 问题：模型会如何处理这个问题？

从注意力机制的视角分析：

1. 系统消息获得稳定的基础注意力。作为固定上下文，系统角色设定会影响整个对话的风格和方向。

2. 代码块作为独立的语义单元。代码有明确的开始和结束标记（\`\`\`），模型会将代码视为一个整体单元进行处理。

3. 问题"会发生什么"的查询指向。当用户问"会发生什么"时，模型的注意力会集中在：

• 最近的对话内容（"1.5"这个具体数字）
• 代码块中的返回语句（`return price - discount`）
• 文档字符串中的"discount"概念

4. 潜在的问题识别。模型应该注意到：

• `discount_percent = 1.5` 意味着150%的折扣
• `price - price * 1.5 = -0.5 * price`，得到负数价格
• 这可能是一个输入验证缺失的bug

5. 上下文中的冗余信息。早期对话中关于"函数逻辑正确"的评价，对于回答当前问题作用不大，但可能作为上下文噪声轻微干扰注意力分布。

如果我们想要优化这个上下文的工程设计，可以考虑：

• 将问题改写为"如果输入是1.5而不是0.15会怎样？"

-