什么是上下文？为什么AI需要它？
开篇：一个让你抓狂的对话
Imagine this scenario: 你正在和一位"智能"助手聊天，想让它帮你完成一篇关于太阳系的作文。你先告诉它："我需要写一篇500字的作文，主题是太阳系的八大行星。"它回复说："好的，我很乐意帮你！请告诉我你想从哪个角度来写。"
你继续说："我想从距离太阳由近到远的顺序来介绍。"它说："没问题！水星是距离太阳最近的行星，距离太阳约5800万公里。"
你兴奋地补充："太好了！继续说下去，把金星也加上。"助手回答："当然可以。金星是距离太阳第二近的行星，距离太阳约1.08亿公里。"
然后你问："等等，我刚才说距离太阳由近到远，水星和金星后面应该是什么？"助手一脸困惑地回答："抱歉，我没有之前的对话记录。请重新告诉我你想写什么主题？"
此刻你的心情如何？是的，你遇到了一个"失忆"的AI——它完全忘记了你们之前的每一句对话，每次都是从零开始。这就是没有上下文的AI（AI without context）的典型表现。
---
1.1 当AI"失忆"时发生了什么
让我们仔细分析一下上面那个令人沮丧的对话。当AI"失忆"时，它面临一个根本性的问题：它无法把对话中的信息连接起来。
无上下文对话的问题本质
在一个没有上下文的AI系统中，每个请求（Request）都是完全独立的。就像寄出一封信，收信人每次都只收到你当前写的这封信，而之前所有的信件都被烧毁了。无论你之前写过多少背景信息，它都无从知晓。
这种模式在技术上称为无状态对话（Stateless Conversation）。"状态"（State）这个词在计算机科学中指的是系统记住的信息。没有状态的系统就像一个每次醒来都失忆的人——它不记得自己是谁，不记得做过什么，也不记得你和它讨论过什么。
当我们向这样的AI提问时，它只能基于两种东西来回答：
1. 它训练时学到的知识（Training Knowledge）—— 即模型在大量文本上训练后获得的语言能力和常识。比如它知道"太阳系有八大行星"，因为这是它训练数据中的常见知识。
2. 当前输入的信息（Current Input）—— 即你这次发送的完整文字。如果你的消息里没有包含背景信息，它就无法凭空猜到。
这听起来好像也够用了？让我们看一个更复杂的例子。
复杂任务暴露的困境
假设你要让AI帮你做这件事：先从一段英文文章中找出所有不认识的单词，然后查词典理解它们的意思，最后用这些单词各造一个句子。
这个任务天然需要跨步骤的信息传递：
- 第一步：AI需要看到你的英文文章
- 第二步：AI需要记住第一步找出的单词列表
- 第三步：AI需要使用第二步的单词列表来造句
在一个"无记忆"的AI系统中，如果你分三次发送消息，每次它都会忘记之前的内容。要让它完成这个任务，你必须在最后一次请求中把所有信息一次性塞进去：原文 + 单词列表 + 查好的词典释义。这样做不仅麻烦，而且容易出错——你可能会遗漏某些信息，或者信息格式混乱。
更重要的是，有些任务根本无法这样完成。想象你让AI分析你过去十次考试的成绩趋势，找出进步和退步的科目，然后给出针对性的学习建议。你不可能每次都把全部历史成绩完整复述一遍，而AI也不会主动记得这些。
这就是为什么我们需要上下文——它是AI连接过去、现在和未来的桥梁。
---
1.2 有上下文的AI：真正的对话伙伴
现在让我们看看同一个场景，如果AI拥有"记忆"会怎样。
同样的作文任务，但这一次AI有了上下文能力。对话可能是这样的：
你：我需要写一篇500字的作文，主题是太阳系的八大行星。 AI：好的，我很乐意帮你！你想从什么角度来介绍呢？比如按距离太阳的远近、按大小排序，还是介绍每颗行星的独特特点？
你：按距离太阳由近到远的顺序来介绍。 AI：明白了。按距离太阳由近到远，八大行星依次是：水星、金星、地球、火星、木星、土星、天王星和海王星。你想重点介绍哪几颗行星呢？
你：重点介绍内行星（水星、金星、地球、火星）吧。 AI：好的，内行星是固态行星，特点是表面有固体外壳。你想按什么结构来组织内容呢？比如逐颗介绍，还是对比着写？
你：逐颗介绍吧，每颗给两段。 AI：明白了。水星是距离太阳最近的行星，也是最小的行星……
看这个对话，AI不仅记住了你们讨论过的内容，还主动利用这些信息来推进对话。它知道"内行星"是你在明确提到"按距离太阳由近到远"之后才补充的定义，它理解你选择"逐颗介绍"意味着每颗行星都有独立的两段文字。
这种对话模式在技术术语中称为有状态对话（Stateful Conversation），其中"状态"就是上下文（Context）。
上下文的核心作用
上下文对于AI的意义，可以从三个层面来理解：
第一，上下文化解歧义。
人类语言充满歧义，一个词或一句话的意思完全取决于语境。"它"指的是谁？"这个"指的是什么？"后来发生了什么"中的"后来"是从什么时候开始算？这些对人类来说理所当然的理解，对AI来说却需要上下文来辅助判断。
没有上下文，AI面对"苹果"这个词时，既不知道你指的是水果还是手机品牌，也不知道你是在讨论营养学还是商业。有了上下文，AI才能做出准确的推断。
第二，上下文实现信息累积。
复杂任务很少能在一句话里说清楚。你可能需要逐步补充信息、修正方向、回应AI的建议再做调整。上文中AI提到"内行星是固态行星"这个知识点，下文你可能想追问"那外行星呢"——这个"那"指的就是上文中刚出现的外行星概念。
没有上下文，这种信息累积根本不可能实现。你必须每次都从头解释所有背景，就像对一个每次见面都失忆的朋友讲故事。
第三，上下文让AI理解你的独特需求。
AI不只是回答通用问题，它需要理解你的特定情况。你在写的是五年级作文还是大学毕业论文？你偏好严谨学术风格还是生动有趣的故事？你的读者是同龄人还是成年人？
这些个性化信息不可能每次都完整复述一遍，它们自然地融入对话的上下文流中，AI通过持续记住这些信息来调整自己的回答。
---
1.3 理解Token：AI阅读的基本单位
现在你已经理解了"上下文"的重要性，接下来让我们深入一点，了解上下文在技术层面是如何工作的。
什么是Token？
当你和AI对话时，你输入的文字首先需要被转换成AI能够处理的数字格式。这个转换过程的第一步，就是分词（Tokenization）——把文字切分成一个个"Token"。
Token是AI处理文本的基本单位。它可以是：
- 一个完整的单词，如"太阳"或"sun"
- 一个单词的一部分，如"行星"（如果原词是"supplanet"这样的合成词）
- 一个标点符号，如"。"或"，"
- 甚至是一个空格
英文的Tokenization相对直接，通常按照空格和常见标点来切分。比如句子"I love AI!"可能被分成三个Token：`["I", "love", "AI!"]`。
中文的情况更复杂。由于中文没有明显的单词边界（如英文单词之间的空格），分词器（Tokenizer）需要根据语言学规则和统计模型来判断哪里应该断开。"我爱人工智能"可能被分成 `["我", "爱", "人工", "智能"]` 或 `["我", "爱", "人工智能"]`，具体取决于分词器的策略。
为什么Token如此重要？
因为AI模型的计算能力和存储空间是有限的，而这种限制正是用Token来衡量的。
每当你向AI发送一个请求，AI需要"阅读"你输入的所有Token，处理它们，然后"写出"回复的所有Token。这个过程消耗的是计算资源——内存（显存）、处理器时间、电力等。
AI公司为了控制成本和保证服务质量，会给每个请求设置一个Token上限。这个上限就是上下文窗口（Context Window），它规定了AI单次能处理的最大Token数量。
上下文窗口：魔法书的页数限制
想象你有一本神奇的魔法书。这本书的每一页能写下1000个字符（你可以粗略理解为1000个Token）。而你的上下文窗口，就是这本书允许你使用的最大页数。
- 如果上下文窗口是4页，你最多能在书里写下4000个字符
- 如果上下文窗口是8页，你最多能在书里写下8000个字符
- 以此类推
当你和AI对话时，整本书的内容（包括你之前说的、AI之前说的、所有背景信息）都会被提交给AI处理。这就是为什么上下文窗口大小如此重要——它决定了你能"喂"给AI多少信息。
以OpenAI的GPT-4为例，不同版本的上下文窗口大小不同：
| 模型版本 | 上下文窗口 | 约等于中文字数 | |---------|-----------|--------------| | GPT-3.5-turbo | 4,096 Token | 约3000字 | | GPT-4 (部分版本) | 8,192 Token | 约6000字 | | GPT-4-32k | 32,768 Token | 约25000字 | | GPT-4 Turbo | 128,000 Token | 约10万字 |
想象一下：GPT-4 Turbo的上下文窗口能容纳一整本中篇小说！而这只是单次对话的容量。
Token的计数方式
你可能会好奇：API是如何计算Token的？
一个常用的估算方法是：对于中文文本，大约1个Token对应1-2个汉字；对于英文文本，大约1个Token对应4个字符（单词平均长度加上空格和标点）。
但更准确的方式是使用专门的Token计算工具。OpenAI提供了一个在线工具，你可以输入任意文本，它会告诉你准确的Token数量。一些编程库（如`tiktoken`）也提供Python接口，可以在代码中直接计算Token数：
```python import tiktoken
选择编码方式，cl100k_base是GPT-4使用的编码
encoder = tiktoken.get_encoding("cl100k_base")
计算中文字符串的Token数
chinese_text = "你好，欢迎阅读这本书！" tokens = encoder.encode(chinese_text) print(f"文本: {chinese_text}") print(f"Token数量: {len(tokens)}") print(f"Token列表: {tokens}")
计算英文字符串的Token数
english_text = "Hello, welcome to this book!" tokens_en = encoder.encode(english_text) print(f"\n文本: {english_text}") print(f"Token数量: {len(tokens_en)}") print(f"Token列表: {tokens_en}") ```
运行这段代码，你会发现：中文的"你好，欢迎阅读这本书！"大约是8个Token，而英文的"Hello, welcome to this book!"也是8个Token。这说明Token的数量并不直接等于字符数，而取决于具体的编码方式和语言特性。
理解Token的概念，对你后续学习如何高效使用AI至关重要。你需要知道：
- 你的输入会消耗多少Token
- AI的回复会消耗多少Token
- 上下文窗口还剩多少空间
- 如何在有限的窗口内放入最重要的信息
---
1.4 对比：无上下文AI vs 有上下文AI
为了更直观地理解上下文的作用，让我们用流程图来对比两种AI处理多轮对话的方式。
```mermaid flowchart LR subgraph No_Context["❌ 无上下文AI (Stateless)"] A1["用户: 帮我写诗"] A2["AI: 独自创作"] A3["用户: 第一句是'月亮'"] A4["AI: ???"] A5["AI无法关联之前的'月亮'"] A6["用户: 继续写"] A7["AI: 再次忘记所有内容"] A8["结果: 每次都是独立的开始"] end
subgraph With_Context["✅ 有上下文AI (Stateful)"] B1["用户: 帮我写诗"] B2["AI: 好的，请说第一句"] B3["用户: 第一句是'月亮'"] B4["AI: 已记住: 月亮"] B5["用户: 继续写"] B6["AI: 读取完整上下文"] B7["已记住: 月亮 → 写第二句"] B8["结果: 连续、连贯的对话"] end
No_Context -->|"对比"| With_Context ```
无上下文AI的工作方式
在无上下文模式下，AI的每次回复都像是在一张白纸上重新开始：
1. 用户发送消息A 2. AI处理消息A，生成回复R1 3. 对话结束，所有记忆被清除 4. 用户发送消息B 5. AI处理消息B，生成回复R2 6. AI完全不知道消息A和R1的存在
这种方式的优势是简单——每次交互都是独立的，不会有历史信息的干扰。但劣势显而易见：无法处理任何需要"记住之前说过什么"的任务。
有上下文AI的工作方式
有上下文模式下，AI会持续维护一个"对话历史"：
1. 用户发送消息A 2. AI将消息A加入上下文 → 生成回复R1 → 将R1加入上下文 3. 用户发送消息B 4. AI将消息B加入上下文 → 现在上下文包含 [A, R1, B] 5. AI处理完整上下文 → 生成回复R2 6. 用户发送消息C 7. AI将消息C加入上下文 → 现在上下文包含 [A, R1, B, R2, C] 8. 重复以上步骤
上下文就像一条不断增长的"记忆链"，从头到尾串联起整个对话。AI每次回复时，都会"看到"这条完整的链。
关键区别：上下文的管理者是谁？
这里有一个值得注意的问题：上下文由谁来管理？
在简单的API调用中，AI本身并不知道你们之前聊过什么。每次请求，你都需要主动把之前的对话内容也一起发送过去。AI的"记忆"实际上是你替它维护的。
```python
无上下文：每次请求只发送当前消息
response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "user", "content": "第一句是'月亮'"} ] )
有上下文：每次请求都发送完整对话历史
response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "user", "content": "帮我写一首诗"}, {"role": "assistant", "content": "好的，请告诉我第一句是什么？"}, {"role": "user", "content": "第一句是'月亮'"} ] ) ```
你注意到了吗？在有上下文的版本中，`messages` 数组包含了三条消息：用户最初的要求、AI的回应、用户的新消息。这个数组就是上下文本身。你的代码负责维护这个数组，把它当作"记忆"来使用。
这也揭示了一个重要的工程现实：上下文容量是有限的，而你需要聪明地管理它。当对话变得很长时，你不能把所有内容都塞进去，需要策略性地保留最重要的信息。这正是后续章节将要深入探讨的主题。
---
1.5 实战：亲手体验上下文的力量
理论讲够了，现在让我们动手实践。通过一个Python实验，你将亲眼见证上下文对AI回答质量的巨大影响。
实验准备
这个实验需要以下条件：
1. Python环境：确保你的电脑上安装了Python 3.7或更高版本 2. OpenAI API密钥：你需要拥有一个有效的API密钥才能调用GPT
如果你还没有API密钥，可以访问 OpenAI官网（openai.com）注册账号。在开发者面板中，你可以找到创建API密钥的选项。请妥善保管你的密钥，不要泄露给他人。
安装必要的库
在开始之前，需要安装OpenAI的Python库：
```bash pip install openai ```
或者如果你使用较新的环境：
```bash pip3 install openai ```
实验代码
下面是一个完整的Python脚本，它会进行两种对话模式的对比：
```python """ 上下文实验：无记忆 vs 有记忆的AI对话 Context Experiment: AI Without Memory vs. AI With Memory
这个实验展示了上下文（Context）对AI回答质量的影响。 """
import os import openai
设置你的API密钥
请将这里替换成你的实际API密钥
openai.api_key = os.getenv("OPENAI_API_KEY") # 从环境变量读取
或者直接赋值（不推荐在代码中硬编码密钥）
openai.api_key = "sk-your-api-key-here"
def call_ai(messages, model="gpt-3.5-turbo"): """ 调用AI API的辅助函数
参数: messages: 消息列表，每条消息是 {"role": ..., "content": ...} model: 使用的模型名称
返回: AI的回复内容 """ try: response = openai.ChatCompletion.create( model=model, messages=messages, temperature=0.7, # 控制随机性，0.7是创造性和确定性的平衡 max_tokens=