当AI忘记了对话的开头：上下文危机的故事
第 1 章：当AI忘记了对话的开头：上下文危机的故事
想象这样一个场景：你在深夜加班，为明天上午十点的重要产品演示做最后准备。你打开AI助手，开始了一场漫长的对话——先是讨论产品定位，然后分析竞品数据，接着调整演示文稿的结构，重新设计关键页面的措辞，又临时起意加入了新的功能演示环节，并在演示中途顺手让AI帮你润色了几句开场白，让它帮你预测了几个可能的提问并准备了回答。
三十七分钟后，你对AI说：“等等，我刚才开篇讲的那个关于用户痛点的故事，数据来源是哪个报告来着？”
屏幕那头沉默了半秒。
AI回复道：“抱歉，我不太清楚您指的是哪个报告。能请您提供更多细节吗？”
你的手指悬在键盘上方，愣住了。
三十七分钟的对话，无数次来回修正，几十个精心打磨的段落——AI对这一切似乎只剩下模糊的印象，却唯独记不住那句你反复强调的开场故事，记不住那个故事背后的数据支撑。你不得不重新打开那份报告，找到那组被你引用了三次的关键数据，再把它粘贴进对话里。
这不是AI在“装傻”。这不是它故意给你制造麻烦。这甚至不是传统意义上的“模型能力不足”——它能写诗、能编程、能分析财报，但在这个深夜，它确确实实地“失忆”了。
这就是上下文遗忘（Context Forgetting），或者说，上下文危机的故事。
这是一个几乎每个深度使用AI的人都会遇到的现象：对话进行到某个长度之后，AI开始出现前后不一致、遗漏关键信息、忘记早先结论等问题。更令人困惑的是，这种“遗忘”并不是均匀发生的——有些信息似乎被牢牢记住，有些则像沙子一样从模型的“记忆”中滑落。我们以为AI拥有“理解”对话的能力，却发现在某种程度上，它只是在玩一场复杂的“文字接龙”，而这场游戏的规则，由一个叫做“上下文窗口”的隐形边界所决定。
本章将从这个令人沮丧的真实场景开始，剖析AI“遗忘”现象背后的根本原因。我们将揭示上下文窗口如何像一个容量有限的容器，限制着AI的“工作记忆”；我们将理解Transformer架构中的注意力机制为何会在长上下文中顾此失彼；我们还将通过一位产品经理的亲身经历，看看上下文问题如何在实际业务中造成真实的损失。
最终，我们将引出本书的核心概念——上下文工程（Context Engineering）——一套系统性的方法论，教我们如何在有限的上下文空间内，最大限度地释放AI的潜力。这场关于“记忆的炼金术”的探索，从理解AI为什么会忘记开始。
---
什么是上下文窗口：模型的“工作记忆”
要理解AI为什么会忘记，我们首先需要理解一个最基础的概念：上下文窗口（Context Window）。
在大型语言模型的世界里，上下文窗口指的是模型一次能够处理的输入和输出的总长度限制。这个长度不是用“字数”来衡量的，而是用Token来计算的。
Token：AI阅读世界的方式
Token是文本处理的基本单位，但它们并不是简单的“一个字”或“一个词”。在大多数情况下，一个Token大约等于0.75个英文单词，而在中文处理中，一个Token通常对应一到两个汉字。这意味着当我们说一个模型有“100K上下文窗口”时，它能处理的文本大约相当于一部《老人与海》的长度——听起来似乎不少，但如果你真正开始与AI进行一场详细的产品讨论，或者让AI帮你review一段几百行的代码，你很快就会发现这个“容量”并不宽裕。
为什么不用“字数”而用“Token”？因为Token是一种语义切分的方式。英文中"unhappiness"可能是一个Token，而"un"+"happ"+"iness"如果分开训练可能会变成多个Token。更重要的是，Token是模型实际“看到”和“处理”的单位——无论是输入给你的提示词，还是模型生成的每一个字，都需要占据上下文窗口的空间。
让我们用一个具体的例子来感受Token的消耗速度：
```python
这段看似简短的对话，Token消耗可能超出你的预期
系统提示：约 500-800 tokens（如果包含详细的角色定义和约束）
system_prompt = """你是一位资深的产品策略顾问，擅长帮助科技公司制定产品路线图。 你的分析应该基于实际数据和行业最佳实践... [此处省略200字详细说明]"""
用户的第一条消息：约 150 tokens
user_message_1 = "我在做一个面向中小企业的SaaS产品，目前有500家付费客户..."
AI的回复：约 200 tokens
ai_response_1 = "恭喜你达到500家客户的里程碑！这个规模说明你已经验证了核心价值假设..."
用户追问：约 120 tokens
user_message_2 = "但我发现大客户流失率比较高，月流失率大概8%，这正常吗？"
AI分析：约 350 tokens
ai_response_2 = "8%的月流失率确实偏高。以SaaS行业的一般标准..."
仅仅这一轮对话，加上之前的上下文，可能已经消耗了2000+ tokens
```
对话继续下去，Token会不断累积。每一次回复，无论长度如何，都会加入上下文的“账单”。当对话进行到足够长，模型的注意力——我们稍后会详细讨论这个机制——就必须开始“做取舍”了。
不同模型的上下文窗口差异
上下文窗口的大小因模型而异，并且随着时间推移不断扩展。以下是一些主要模型的上下文窗口对比：
| 模型系列 | 典型上下文窗口 | 约合中文文字数 | 约合英文单词数 | |---------|--------------|--------------|--------------| | GPT-3.5 | 16K tokens | 约12,000字 | 约12,000词 | | GPT-4 (早期) | 8K tokens | 约6,000字 | 约6,000词 | | GPT-4 (更新) | 128K tokens | 约96,000字 | 约96,000词 | | Claude 2 | 100K tokens | 约75,000字 | 约75,000词 | | Claude 3 | 200K tokens | 约150,000字 | 约150,000词 | | Gemini 1.5 | 1M tokens | 约750,000字 | 约750,000词 |
这些数字看起来很惊人——Gemini 1.5的百万级Token上下文几乎能容纳整部《战争与和平》。但正如我们将在后文中看到的，上下文窗口的容量和有效利用这个容量的能力是两回事。就像一个人可以站在一个巨大的图书馆里，但如果他只有短暂的记忆力和有限的理解力，那些书籍的内容并不会自动变成他的知识。
更关键的是，上下文窗口不仅仅是你输入的内容，还包括模型的所有输出。每次AI回复你，它之前生成的所有文字也会留在上下文里，被计入窗口限制。这就是为什么长对话会像滚雪球一样——对话越长，每一轮新回复所需的“空间”就越大，可用空间就越小。
为什么上下文窗口是有限的？
你可能会问：为什么不把上下文窗口做得更大？理论上，更大的上下文窗口意味着更强的记忆能力和更连贯的对话体验。
答案在于计算成本。
当前主流的大型语言模型都基于Transformer架构。在这个架构中，每一次处理文本都需要进行所谓的“注意力计算”——每个Token都需要与其他所有Token进行交互，以确定哪些信息是重要的、应该被“关注”的。
当上下文窗口长度为N时，注意力计算的时间复杂度是 $O(N^2)$。这意味着如果上下文长度翻倍，所需的计算量会增加四倍；如果上下文长度增长十倍，计算量会增长一百倍。在实际部署中，这种二次方增长的计算成本是天文数字。
此外，推理过程中的内存消耗也随上下文长度线性增长。你需要将整个上下文加载到GPU显存中，而一块顶级的H100 GPU也只有80GB的显存。即使是128K的上下文，也需要复杂的内存管理和优化技术。
因此，上下文窗口的大小是能力、成本和工程可行性之间的权衡结果。这不是模型设计者的短视，而是一个根本性的技术约束——这个约束塑造了我们使用AI的方式，也催生了本书要讨论的“上下文工程”这门新学科。
---
注意力机制的局限：为什么Transformer会“分心”
上下文窗口定义了模型能“看到”多少内容，而注意力机制（Attention Mechanism）决定了模型如何“理解”和“利用”这些内容。要理解AI为什么会在长对话中遗忘，理解注意力机制的工作原理至关重要。
自注意力：Transformer的核心
Transformer架构的核心创新是自注意力机制（Self-Attention）。与传统序列模型（如RNN）逐个处理Token不同，自注意力允许模型在处理当前Token时，同时“关注”上下文中的所有其他Token。
用更直观的话说：当模型读到一句话中的某个词时，它不仅仅理解这个词本身的含义，还会考虑这个词与句子中其他词的关系。比如在“猫坐在垫子上”这个句子中，模型需要知道“猫”是主语，“坐”是动作，“垫子”是地点——这种关系的建立就依赖于注意力机制。
自注意力的数学表达涉及Query（查询）、Key（键）和Value（值）三个向量。简单来说：
- 每个Token在上下文中“查询”相关信息时，会产生一个Query向量
- 上下文中每个Token“提供”信息时，会产生一个Key向量
- 模型实际“使用”的信息内容由Value向量给出
两个Token之间的“关联度”由Query和Key的点积决定，这个点积经过Softmax归一化后，就是我们说的“注意力权重”。这个权重决定了在处理某个Token时，模型应该多大程度上“参考”另一个Token的信息。
$$Attention(Q, K, V) = softmax\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$
这个公式的美妙之处在于，它让模型能够自动学习哪些信息是重要的，哪些是可以忽略的。但它的局限性也源于此——注意力是一个零和游戏。当上下文中只有一个Token时，模型可以投入100%的注意力在它身上。当有1000个Token时，模型必须在它们之间分配注意力总量。
长上下文中的“注意力稀释”
理论上，如果模型能够对上下文中所有Token均匀分配注意力，那么更长的上下文就意味着更多的信息、更强的能力。但实际情况恰恰相反——在实践中，注意力权重的分布往往是高度不均匀且扭曲的。
研究者们发现了一个被称为“中间丢失”（Lost in the Middle）的现象：当关键信息位于上下文的中间位置时，模型对其的关注度显著低于当这些信息位于开头或结尾时。这不是因为模型在物理上“看不到”中间的内容，而是注意力机制的特性导致了这种偏差。
具体来说：
首因效应（Primacy Effect）：出现在上下文开头的Token往往获得更高的注意力权重。这部分是因为这些Token在自注意力的计算中参与了更多的“传递”——越早出现的Token在后续Token的注意力计算中被更多地引用，形成了累积优势。
近因效应（Recency Effect）：同样，最近出现的内容也往往被更好地记住。这是因为在当前的计算中，最近的Token距离更近，在注意力矩阵中的位置更“近”，信息传递的路径更短。
中间遗忘（Middle Forgetting）：而位于上下文中间的内容，尤其是当上下文很长时，往往只能获得有限的注意力。模型可能“知道”这些内容存在，但在实际生成回答时难以有效利用它们。
这就像人类的短时记忆——我们倾向于记住开头和结尾的事情，而中间的事情往往被遗忘。区别在于，人类的大脑容量是固定的，而AI的上下文窗口虽然可以扩展，但注意力机制的偏差是架构性的，无法通过简单增加窗口大小来克服。
注意力计算的资源竞争
除了位置偏差，还有另一个更根本的问题：计算资源的有限性。
即使注意力权重能够完美均匀分布，当上下文达到一定长度时，每个Token分到的“注意力预算”也会变得微乎其微。想象一下，如果你需要同时处理一百个人的请求，你能给每个人的关注时间只有几秒钟；如果你需要同时处理一千个人，这种关注会变得多么表面。
在Transformer中，这种“关注不足”体现为模型对上下文中不同区域的“理解深度”差异。开头和结尾的内容可能被建模得非常充分，而中间的内容可能只留下一个模糊的“印象”。这解释了为什么AI有时能精确引用对话开头说过的话，有时却完全遗漏了中间某个明确的结论。
更糟糕的是，注意力计算的不均匀性不是固定的——它会受到具体内容的影响。有些模式会被模型“记住”，有些则会被“忽略”，而这种区分的标准对于普通用户来说往往是不透明的。一个你精心构建的论点在模型看来可能只是噪音，而某个随口提到的细节反而被记住了。
这种行为特征意味着，在实际使用中，我们不能简单地将所有信息塞进上下文就期待模型能够恰当处理。我们需要主动设计上下文的结构，引导模型的注意力流向，确保关键信息不会被“稀释”或“覆盖”。这正是上下文工程的核心挑战之一。
---
位置偏差与上下文断裂：两种不同的遗忘
在理解了注意力机制之后，我们可以更精确地分析AI“遗忘”的具体模式。观察表明，AI的上下文遗忘至少有两种截然不同的机制：位置偏差导致的渐进遗忘和上下文断裂导致的碎片化问题。这两种问题虽然表现相似，但根源不同，需要不同的应对策略。
位置偏差：越远越模糊
位置偏差（Positional Bias）是我们在上一节讨论的注意力不均匀分布的直接结果。在长对话中，早期的对话内容会逐渐“褪色”，变得不那么清晰和可靠。
这种遗忘有几个特征：
渐进性：遗忘不是突然发生的，而是在对话进行过程中逐渐加剧。用户在对话开头提到的信息，在第50轮时可能只是“模糊”，在第100轮时可能就“完全消失”了。
选择性：并非所有早期信息都会被遗忘。模型可能忘记了你列出的三个竞品分析要点中的一个，却记住了你用其中一个要点反驳了另一个。这种选择性使得问题更难诊断——你可能以为模型“记住了主要内容”，但实际上某个关键细节已经丢失。
条件依赖性：早期信息能否被记住，取决于它在后续对话中被引用的频率和方式。如果一个观点在后续对话中反复被提及，它更可能被保留；如果它只是一个“一次性”的事实，它很可能会在注意力竞争中落败。
用一个比喻来说，上下文窗口就像一条传送带，早期的内容不断被推向边缘。当传送带很长时，边缘的内容只能获得很小的曝光度；而当传送带上堆满新内容时，旧内容被“看到”的机会就更少了。
上下文断裂：主题切换的代价
与位置偏差不同，上下文断裂（Context Fragmentation）是一种结构性问题，它发生在对话涉及多个主题或任务时。
考虑这样一个场景：你先让AI帮你分析一份数据报告（主题A），然后切换到讨论产品路线图（主题B），之后又回到报告但这次关注另一个指标（主题A'），然后突然问起技术实现方案（主题C）。
在这场对话中，模型需要同时维护多套“上下文状态”：
- 主题A的数据发现
- 主题B的路线图讨论
- 主题A'的新数据关注点
- 主题C的技术要求
当上下文窗口填满时，这些不同主题的信息会相互竞争“空间”。模型可能把主题A的某个具体数字和主题B的某个功能需求搞混，或者把主题C的技术约束套用到主题A的数据解释上。
更严重的是，当用户在不同主题之间快速切换时，模型需要“重新定位”——理解当前问题指的是哪个主题、哪个时间段的信息。这种重新定位本身就是一种认知负担，会增加错误的风险。
上下文断裂的另一个表现是隐含上下文的丢失。在连贯的讨论中，很多信息是“共享知识”不需要明说的——比如双方都知道在讨论哪个产品、哪个功能、哪个时间段。但当上下文断裂后，这些隐含信息可能变得模糊，导致模型基于错误的假设进行回复。
真实对话中的遗忘模式
让我们用一个简化的例子展示这两种遗忘的交互：
``` 用户: 我们公司有三个主要产品线：A、B、C。Q3我们重点推广产品A。 AI: 明白了，Q3推广重点是产品A。有什么具体目标吗？
用户: 产品A在医疗和教育两个行业都有应用，医疗客户更看重安全性，教育客户更看重易用性。 AI: 差异化定位很好。医疗客户关注安全性，教育客户关注易用性。
用户: 帮我分析一下Q3的用户增长数据 AI: 好的，我来帮您分析Q3的用户增长情况...[分析产品A的增长数据]
用户: B和C的情况怎么样？ AI: 关于产品B和产品C的增长数据...[开始分析]
用户: Q3我们投入了很多在C的海外市场扩张上 AI: 是的，Q3海外市场对产品C的贡献很大...[混淆了时间线，之前分析时没有提及这个信息]
用户: 我刚才说Q3重点是推广产品A，你怎么在说C的海外市场？ AI: 抱歉，您说得对。Q3的重点确实是产品A。让我更正...
用户: 还有，我最开始说的三个产品线分别是什么？ AI: 您提到的是...呃...产品A、B...还有什么呢？我记得有三个，但具体名称... ```
在这个虚构但高度真实的对话片段中，我们可以观察到：
- 第一次遗忘：Q3海外市场信息——这是一个**位置偏差**问题，这个信息出现在中间位置，没有被充分关注
- 第二次遗忘：三个产品线的名称——这可能是**上下文断裂**问题，早期的基本信息在多次主题切换后变得模糊
这个例子说明，在复杂的真实对话中，两种遗忘模式往往交织出现，使得问题更难以诊断和解决。
---
真实业务的代价：一位产品经理的故事
理论的讨论总是相对轻松的，但上下文遗忘的真正严重性只有在真实业务场景中才能充分体现。让我讲述一位产品经理——我们暂且称她为林晓——的真实经历。
林晓在一家快速成长的B2B SaaS公司担任高级产品经理。她负责的产品是一个面向连锁零售企业的库存管理系统，已经服务了超过2000家客户。2023年秋天，公司决定开发一个重要的新功能：智能补货推荐——利用AI分析历史销售数据、库存水平和供应链信息，自动生成补货建议。
这个项目的技术负责人建议使用大型语言模型来处理部分逻辑——特别是将用户输入的自然语言查询（如“这个月生鲜类的补货策略应该怎么调整”）转换为系统能理解的参数，以及生成易于理解的分析报告。
项目进行得很顺利。技术团队搭建了基础架构，产品团队设计了用户交互流程，在小规模测试中也取得了不错的效果。问题出现在一次关键的客户演示中。
演示的灾难
那天是给一个大客户——一家拥有300多家门店的连锁超市——做功能演示。对方的采购总监、IT负责人和几个区域经理都到场了。林晓和公司的技术负责人一起做演示。
演示的核心流程是：先用当前系统做一个基础补货分析，然后展示新功能如何“理解”用户的自然语言问题，并给出更智能的建议。
前十五分钟一切正常。林晓展示了几个基本查询，