记忆的开始：一个简单对话的启示

记忆的开始：一个简单对话的启示

---

从「昨天的会议」问题看上下文的重要性

周一的早晨，阳光透过落地窗洒进开放式办公室。林悦揉了揉眼睛，打开电脑，准备开始新一周的工作。她的第一件事是打开邮箱，查看周末积压的邮件。然后，她点开了公司内部的AI助手——一个被设计用来帮助员工处理日常事务的智能系统。

「昨天的会议讨论了什么？」她随口问道。

屏幕上的对话框里，光标闪烁了几秒，然后AI助手回复了这样一段话：「根据我的记录，我们在上周四下午两点举行了一次项目评审会议。会议主要讨论了Q3季度的产品规划，涵盖了用户增长目标、技术架构升级计划以及市场营销策略三个核心议题。在用户增长方面，团队确定了月活用户增长15%的目标，并讨论了通过新功能上线和渠道优化来实现这一目标的路径……」

林悦愣住了。

她问的是「昨天的会议」，但AI给出的却是「上周四的会议」。更让她困惑的是，AI描述的会议内容听起来很详细、很专业，但她完全没有印象——因为她根本没有参加那场会议。她要问的是昨天上午10点那场只有五个人参加的小范围讨论，关于即将上线的用户调研功能该如何设计优先级。

这就是AI系统面临的记忆困境。

林悦的这个问题看似简单，却触及了AI系统最核心的挑战之一：如何跨越时间保持「记忆」，如何理解人类对话中隐含的上下文信息。当我们问「昨天的会议」时，我们假设AI知道我们指的是哪一场会议、我们参加了哪场会议、我们关心的是会议中的哪些具体内容。但对于当前的AI系统来说，这个「昨天的」需要被精确地理解为相对于某个特定时间点的、我们有权限访问的、符合特定条件的某一次会议记录。

这不是AI不够聪明，而是它缺乏我们人类理所当然拥有的那种「记忆」能力。我们的大脑会自动记录、关联、索引我们经历过的每一件事，并在需要的时候快速检索。但AI系统不一样——它只「记得」在当前对话窗口中呈现过的信息，或者说，只「记得」它被设计能够访问的那一部分数据。

让我们把时间拨回到林悦问出那个问题之前，看看在这个看似简单的问答背后，到底发生了什么。

---

上下文在AI系统中的角色

当林悦输入「昨天的会议讨论了什么？」这句话时，一个复杂的处理流程在AI系统内部启动了。

首先，这句话被分解成一个个最小的语义单元——token。在自然语言处理的世界里，token是模型理解和处理文本的基本单位。一个token可能是一个完整的汉字，也可能只是一个标点符号，或者是某个被词典收录的常用词组。以中文为例，「昨天的会议讨论了什么」这句话大约会被分解成10到12个token，每个token都携带着一定的语义信息。

这些token进入了AI模型的注意力机制（Attention Mechanism）——这是近年来深度学习领域最重要的创新之一，也是让大语言模型（Large Language Model, LLM）变得「智能」的关键技术。注意力机制的核心思想是：当模型处理一个token时，它需要「注意」到与这个token相关的其他token，包括前面的和后面的。

想象一下你在阅读一篇文章。当读到「他」这个词时，你会自动回溯前文，找到这个「他」指的是谁。这种回溯和关联的能力，就是注意力机制在做的事情。但与传统阅读不同的是，AI模型的注意力可以同时关注到上下文窗口内的所有token，并且通过数学计算（主要是点积注意力机制）来衡量每个token对当前任务的重要程度。

然而，这里有一个关键的限制：上下文窗口（Context Window）。

上下文窗口指的是模型在一次处理过程中能够「看到」的最大token数量。这就像是一个有限宽度的窗口，模型只能通过这个窗口来观察和处理信息。窗口之外的token，模型是「看不见」的，或者说，在模型看来，它们根本不存在。

不同模型有不同的上下文窗口大小。早期的GPT-3模型的上下文窗口约为4096个token，大约相当于3000个英文单词或2000个中文字符。新一代模型的上下文窗口已经扩展到了数十万甚至上百万token。但无论这个窗口有多大，它始终是有限的。这意味着，如果一段信息超出了上下文窗口的范围，模型就无法直接「记住」它。

回到林悦的场景。当她问「昨天的会议讨论了什么」时，AI系统需要知道：第一，「昨天」指的是什么时间点；第二，她参加的是哪场会议；第三，那场会议讨论的具体内容是什么。这些信息从哪里来？

在理想情况下，如果林悦和AI的对话从上周就开始了，所有的会议信息都已经在上下文窗口中，那么AI或许能够准确回答。但现实往往是：林悦可能只是第一次打开这个AI助手，或者她上周的对话已经被系统清理以节省资源，或者她想问的是另一个完全不相关的会议。在这种情况下，AI只能「猜测」或「编造」一个看起来合理的答案——这就是AI领域著名的幻觉问题（Hallucination）。

这种「记不住」的问题，在AI研究社区被广泛讨论。有学者将其称为「上下文记忆的脆弱性」，有实践者称之为「上下文窗口的诅咒」，而在本书中，我们将其定义为上下文工程的起点——如何有效地管理和利用上下文窗口，让AI系统能够「记住」它需要记住的信息，「理解」它需要理解的语境。

---

上下文工程：超越提示工程的新范式

在深入讨论上下文工程之前，我们需要先厘清一个常见的误解：上下文工程与提示工程（Prompt Engineering）是什么关系？

提示工程是指设计和优化输入给AI模型的指令文本，以获得更好的输出结果。一个典型的提示工程案例可能是：「请用简洁的语言解释量子计算，不要超过100字」——这是在给定任务和约束条件下的指令优化。

上下文工程的范围远比提示工程更广。它不仅仅关注如何撰写一条好的指令，还关注如何组织、呈现和管理AI系统需要处理的全部信息——包括对话历史、用户画像、任务背景、外部知识引用等等。

打个比方：如果把AI系统比作一个职场新人，提示工程就像是教他怎么说得体的话，而上下文工程则是为他准备一份完整的工作档案，包括他的职责范围、他负责的项目、他的协作伙伴、他的工作习惯等等。一个优秀的职场新人需要的不只是一句得体的开场白，更需要对自己所处的环境有清晰的认识。

让我们通过一个具体的例子来理解这种区别。

假设你是一家电商公司的产品经理，你需要AI助手帮你分析用户反馈。以下是两种不同处理方式的对比：

仅使用提示工程的方式：

``` 请分析以下用户反馈，提取出主要的产品改进建议。

反馈内容： 1. 退货流程太复杂了，找不到退货入口 2. 希望商品详情页能显示更多尺码对照信息 3. 支付方式能不能加上微信 4. 快递太慢了，等了一周才到 5. 客服回复太慢，等了两个小时才有人回应 ```

这种方式下，你每次都需要手动复制粘贴反馈内容，而且AI完全不知道你的产品是什么、你面临的主要问题是什么、你过去做过哪些改进。

使用上下文工程的方式：

首先，在系统层面配置好以下信息：

• 产品类型：时尚服饰电商平台
• 核心业务流程：浏览→加购→下单→支付→物流→售后
• 当前版本：V2.3.1（最近一次更新：两周前）
• 已收集的用户反馈数量：本周新增127条
• 已知问题：支付渠道投诉占32%，物流投诉占28%

然后，在用户层面配置：

• 角色：产品经理，关注功能迭代优先级
• 当前任务：分析本周用户反馈，制定下季度改进计划
• 偏好：喜欢数据驱动的分析报告

最后，在任务层面输入：

``` 请分析本周新增的用户反馈，按照“紧急-重要”矩阵分类，并给出优先级建议。 ```

在这种配置下，AI不仅知道要分析什么，还知道为什么这些反馈重要、应该如何评估优先级、以及如何将反馈与产品路线图对齐。

这就是上下文工程的力量：它不是在单次交互中优化一条指令，而是在系统层面构建一个完整的「理解框架」，让AI能够在这个框架内进行有意义的推理和决策。

本书的核心目标，就是教你如何构建这样的「理解框架」——如何有效地收集、组织、呈现和管理AI系统所需的各种上下文信息，让它真正成为你工作中可靠的智能助手。

---

context window、token与attention：三位一体的核心机制

要深入理解上下文工程，我们需要先搞清楚三个核心概念之间的关系：context window（上下文窗口）、token（标记）和attention mechanism（注意力机制）。这三个概念相互依存，共同决定了AI系统的「记忆」能力和「理解」深度。

token：信息的最小单元

如前所述，token是AI模型处理文本的基本单位。但token的具体定义比你想象的要复杂一些。

在早期的分词方式中，中文通常被按字或按词切分。一个字算一个token，一个双字词算两个token。但这种方式的问题在于，语义被强行割裂了。「机器学习」这个四字词组如果被切成「机器」「学习」两个token，模型可能会分别理解「机器」和「学习」这两个概念，而忽略它们组合后产生的专业含义。

现代大语言模型通常采用子词分词（Subword Tokenization）的方法。常见的算法包括BPE（Byte Pair Encoding）和WordPiece。这种方法的核心思想是：让token既不要太长（否则词汇表会过于庞大），也不要太短（否则无法捕捉有意义的语义单元）。

以GPT系列使用的BPE算法为例。它首先将所有字符初始化为token，然后递归地合并最频繁出现的字符对，形成新的token。最终形成的词汇表通常包含数万个到数十万个token。在中文处理中，这通常意味着一个汉字可能被编码为一个token，但常见的词组、双字组合甚至四字成语也可能被作为一个整体token来处理。

这种分词方式有一个重要的实际意义：token的数量直接影响API调用的成本和处理时间。一个英文句子通常对应3到4个token（平均每个单词1.3个token左右），而一个中文字符串对应的token数量取决于常用词组的覆盖率。在实际开发中，你需要使用各模型提供的分词工具来准确计算token数量。

context window：信息的容量边界

context window定义了模型在单次推理过程中能够处理的token总数。这个总数包括两个部分：输入上下文和输出上下文。

当你向ChatGPT发送一条消息时，这条消息加上之前的对话历史（如果有的话）构成了输入上下文。模型生成的回复则是输出上下文。大多数模型的context window限制是针对两者的总和而言的。

例如，假设一个模型的context window是4096 token，你在一次对话中已经发送了3500 token的历史消息，那么模型理论上只能生成最多596 token的回复（实际会更少，因为还需要预留一些空间给系统指令和格式标记）。

context window的大小对AI系统的能力有决定性的影响。较小的context window意味着模型只能「记住」最近的对话内容，历史的细节会很快被遗忘。较大的context window则允许模型处理更长的文档、维持更久的对话、以及在更广泛的上下文中进行推理。

但这里有一个关键的非线性关系需要理解：并不是说context window越大，AI就越智能。

这种非线性体现在多个层面。首先是边际效用递减。当context window从1K扩展到4K时，AI处理短文档的能力显著提升；但当context window从128K扩展到1M时，对于大多数实际任务而言，这个提升并不明显——因为很少有任务真正需要模型同时处理如此大量的文本。

其次是注意力分散问题。当context window很大时，模型需要在更多的token中分配注意力，这可能导致它更难准确地「注意到」真正重要的信息。这就引出了第三个概念——注意力机制的作用。

attention mechanism：信息的关联方式

注意力机制是理解大语言模型工作原理的核心。它解决了这样一个问题：当模型处理当前token时，应该「关注」前面的哪些token？

早期的序列处理模型（如RNN、LSTM）使用的是隐状态传递的方式。信息从一个token传递到下一个token，模型通过隐状态来「记住」之前的内容。但这种方式的问题是：信息在传递过程中会逐渐衰减，早期的内容很难被长期记住。

2017年，Google的研究者提出了Transformer架构，引入了自注意力机制（Self-Attention）。在自注意力机制中，每个token都可以直接「关注」到上下文窗口内的任意其他token，不受距离限制。这就像是构建了一个全连接的神经网络，让每个词都可以与上下文中的每个词建立关联。

具体来说，自注意力机制通过计算注意力分数（Attention Score）来衡量token之间的相关性。计算过程大致如下：

1. 对于每个token，模型生成三个向量：Query（查询）、Key（键）和Value（值） 2. 对于当前的token，用它的Query与上下文窗口内所有token的Key做点积运算 3. 对点积结果进行Softmax归一化，得到注意力权重 4. 用这些权重对所有token的Value进行加权求和，得到最终的输出

这个过程可以用以下公式表示：

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

其中 $d_k$ 是Key向量的维度，用于控制点积结果的缩放。

理解这个机制对于上下文工程至关重要。因为attention本质上是一种信息选择机制——它决定了在浩如烟海的上下文中，模型把注意力放在哪里。

当你在设计上下文时，你需要考虑的是：如何组织信息，让模型能够正确地把注意力放到它应该关注的地方？

例如，如果你想让AI分析一段长文章中的关键观点，你可以选择在上下文开头提供「本文核心观点是……」这样的摘要，帮助模型快速建立对文章的整体认知。这本质上是在引导模型的注意力方向。

反过来说，如果你提供的上下文过于杂乱、缺乏组织，模型可能会被无关信息分散注意力，导致它忽略真正重要的内容。这就是上下文工程中一个核心的原则：质量重于数量。与其塞入大量未经整理的信息，不如提供精心组织的、结构清晰的上下文。

---

上下文长度与AI能力的非线性关系

现在我们已经理解了context window、token和attention机制，接下来让我们通过几个对比实验，直观感受上下文长度对AI能力的影响。

实验一：短上下文场景

场景设定：用户向AI助手咨询一道家常菜——红烧肉的做法。

上下文长度：约200个token（用户输入+系统提示）

对话记录：

• 用户：红烧肉怎么做？
• AI：红烧肉是一道经典的家常菜，以下是基本做法：1. 选用五花肉，切成3厘米见方的块……

分析：

在短上下文场景下，AI的反应是快速且准确的。它能够根据用户的简单问题，提供一段标准化的回答。这种场景下的AI就像一个经验丰富的厨师，脑中存储着标准的菜谱，按步骤执行即可。

但问题在于：AI并不知道用户的具体需求。用户是厨房新手吗？有没有特殊的饮食限制（比如不能吃太油腻）？有没有特定的厨具（比如只有电饭煲）？这些个性化的信息，AI在短上下文下是无法感知的。

实验二：中等上下文场景

场景设定：延续上面的对话，用户说「我家里只有一个小炖锅，火力也比较小」。

上下文长度：约400个token（包含之前的对话）

对话记录：

• 用户：红烧肉怎么做？
• AI：红烧肉是一道经典的家常菜，以下是基本做法……
• 用户：我家里只有一个小炖锅，火力也比较小。
• AI：明白了，如果你用小炖锅且火力受限，建议以下几点调整：1. 肉块切小一些，2厘米左右……

分析：

在这个场景下，AI展现出了更好的「理解」能力。它注意到了用户提供的额外信息（小炖锅、火力小），并据此调整了回答。这是上下文窗口扩展带来的直接收益——模型能够「记住」之前的对话内容，并将其纳入后续的推理过程。

但请注意，这里仍然存在一个局限：AI的记忆仅限于当前对话窗口内的内容。如果用户关闭了这次对话，第二天重新开启，AI不会「记得」昨天的对话内容。

实验三：长上下文场景

场景设定：一个产品经理正在使用AI助手准备季度汇报。他需要AI帮他整理过去三个月的工作成果。

上下文长度：约50,000个token（包含：项目文档、用户反馈、会议纪要、邮件往来等）

对话记录：

• 用户：帮我整理一下这季度的工作成果，按项目分类。
• AI：好的。根据我整理的信息，你这季度主要负责了三个项目……

分析：

在长上下文场景下，AI能够处理远超短期记忆容量的信息。但这里出现了几个新的挑战：

第一，信息检索的准确性。当上下文达到数万token时，模型需要从中「找出」相关的段落。这涉及到上下文窗口内部的注意力分配问题。研究表明，当context window非常大时，模型对于远距离信息的召回率会下降——它可能「忘记」开头部分的内容。

第二，推理的连贯性。在处理大量信息时，保持推理链条的连贯性变得更加困难。AI可能会出现「前面提到的某个细节，后面忘记了」的情况。

第三，处理成本的增加。更长的上下文意味着更高的计算成本和更长的响应时间。在实际应用中，这需要在「信息完整性」和「响应效率」之间做出权衡。

非线性关系的三个层次

通过上述实验，我们可以总结出上下文长度与AI能力的三个非线性关系层次：

第一层：能力跃升期。当context window从极短（如几百token）扩展到适中（如几千token）时，AI的能力会有质的飞跃。它从只能处理单轮问答，进化到能够进行多轮对话、理解上下文延续、记住用户偏好。这个阶段的特点是：收益显著、问题不显著。

第二层：边际递减期。当context window继续扩展到数万token时，能力的提升开始变得不那么明显。大多数日常任务并不需要如此长的上下文。更重要的是，过长的上下文开始带来新的问题——注意力分散、信息遗忘、处理延迟。这个阶段的特点是：收益放缓、问题显现。

第三层：规模化瓶颈期。当context window扩展到数十万甚至百万token时，能力提升进入平台期。虽然技术上可以处理一本书的内容，但模型对于如此大量信息的理解和记忆能力并没有同步提升。这个阶段的特点是：技术可行、实用受限。

理解这种非线性关系，对于后续学习上下文工程的具体技术至关重要。因为上下文工程的核心思想不是「最大化」上下文长度，而是「最优化」上下文配置——在适当的上下文中，提供适当的信息，以支持模型完成特定的任务。

---

从「记忆缺失」到「外部记忆」：系统设计的新思路

让我们回到林悦的故事。面对