AI 聊天机器人如何工作：词元、上下文与遗忘

聊天机器人阅读你的话的方式与你写下它们的方式不同，它记住一段对话的方式也与人不同。它读取称为词元（token）的小块内容，把有限数量的词元放在上下文窗口中，然后逐个词元地构建每个回答。长对话中大多数奇怪行为——从丢掉指令到漏看文档中的一处事实——都源于这三个事实。

词元：模型实际读取的单位

在模型处理提示之前，一个称为分词器（tokenizer）的软件会把文本切分成词元。OpenAI 把词元描述为其模型处理文本的单位。一个词元可以代表一个字符、一个单词的一部分、一个完整的单词或标点符号，空格也会影响文本如何被切分。

这种切分与字数并不相同。常见的短词通常只占一个词元。更长或更罕见的词会拆成好几个。在一篇讲解 OpenAI 模型的文章中，“apple” 是一个词元，而 “hamburger” 是三个：“ham”、“bur” 和 “ger”。大小写和空格也有影响。OpenAI 指出，“red”、“Red” 以及带前导空格的版本，表示方式可能不同。Google 对 Gemini 模型给出了同样的图景：一个词元可以是像 “z” 这样的单个字符，也可以是像 “cat” 这样的完整单词；一个模型能使用的全部词元集合就是它的词表。

就英文而言，两家公司给出的粗略经验法则相近：

OpenAI：1 个词元约为 4 个字符，约为一个单词的四分之三；100 个词元约为 75 个单词。
Google（针对 Gemini 模型）：1 个词元约为 4 个字符；100 个词元约为 60 到 80 个英文单词。

两家公司都强调这些只是估算。同样的文本在不同的模型中可能产生不同的计数，其他语言也有所不同。词元也不只是文本。Google 指出，Gemini 的所有输入和输出都会被词元化，包括图片：两个维度都不超过 384 像素的图片为 258 个词元（更大的图片按 768×768 的图块平铺，每块 258 个词元），视频为每秒 263 个词元，音频为每秒 32 个词元。因此，一个大文件消耗的窗口可能远超可见文字所暗示的量。

一次一个词元：回答如何生成

聊天机器人不是从数据库里取出一个现成的答案。它是逐个词元地生成答案的。

在每一步，模型都会考察到目前为止的词元，产生一批可能的下一个词元及各自的权重。然后从这份列表中采样出一个词元，权重大的比权重小的更有可能被选中。这个新词元被加入序列，整个过程重复进行。生成在达到长度上限时停止，或者在模型产生一个特殊的停止词元时停止。

这个循环解释了两个熟悉的特点。同一提示在不同运行中答案可能不同，因为采样并不总是挑中权重最高的单个词元。而自信的语气并不是准确的证据：这个过程选出的是看似合理的续写，所以输出可以听起来流畅却仍然是错的。OpenAI 还区分了输入词元（在请求中提供的）、输出词元（由模型生成的）和推理词元（reasoning tokens）——一些模型在给出可见答案之前会在内部使用它们。推理词元不会显示出来，但计入输出用量，所以一个简短的答案消耗的词元可能比它的文本所显示的更多。

上下文窗口：有硬边界的工作记忆

上下文窗口是对模型在一次请求中能处理多少词元的限制。OpenAI 的说法很直白：窗口限制了一个请求中的词元数，模型另有一个单独的输出上限。窗口必须容纳系统指令、到目前为止的对话、提供的任何文件、工具返回的结果，以及留给回答（包括推理词元）的空间。

大小因模型和产品而异。Anthropic 的支持页面在 2026 年 10 月 7 日更新，称除其列出的较新模型外，Claude 在付费聊天方案上的上下文窗口为 200,000 个词元，约相当于 500 页或更多文本。那里列出的许多较新模型显示为 500,000 或 100 万个词元，具体取决于使用场景是聊天、Claude Code 还是 Claude Cowork。因此，一个产品上的头条数字并不自动适用于另一个产品。

更大的窗口有助于把长文档或长对话装进一次请求中。它并不创造永久记忆。当一次新聊天开始时，先前的对话并不在新窗口里，除非产品把它带过来，例如以摘要的形式。在一次聊天中跨轮次的”记住”，实际是早期轮次被作为上下文再次提供给下一个回答。

当对话接近上限时，各产品的溢出处理方式不同。Anthropic 表示，对于启用了代码执行的付费方案，Claude 会自动总结早期消息以腾出空间，并且总结后完整历史会保留备查。但摘要是一种压缩：当一段长交流变成一段简短回顾时，人名、确切数字和细小条件都有丢失的风险。OpenAI 针对过大的输入给出了类似的建议：缩短提示、移除重复的上下文、拆分大型输入，或者先对材料做总结。

为什么长对话会遗忘，以及为什么中间位置重要

长对话中的遗忘通常有三个原因之一。早期材料掉出了窗口，或被摘要取代了。它还在，但后来的指令与它冲突。或者，它还在、也没有被反驳，但模型没有很好地利用它。

第三个原因有一个被测量出来的名字：中间迷失（lost in the middle）。在 Liu 等人于 2024 年发表在 TACL 上的研究中，研究者给模型一个问题加上 10、20 或 30 段检索到的段落，其中只有一段包含答案。研究者把那一段移到不同的位置，其他什么都不改。

准确率形成了一个 U 形。在有 20 篇文档时，当答案段落排在最前面时，GPT-3.5-Turbo 答对的比例约为 75.8%；排在最后时为 63.2%；位于中间时为 53.8%。它在完全没有文档时的得分是 56.1%，所以在中间位置时，提供答案段落得出的结果反而比什么都不提供略差。在那项研究中，对于两个版本都能装下的输入，更大的上下文窗口并没有修复这一模式；把文档集从 20 篇增加到 50 篇，只让该模型的表现提高了约 1.5%。

较新的模型在简单的检索测试上表现更好，这一效应也因任务而异。但实用的教训仍然影响着厂商的指引。Anthropic 的长上下文技巧（在对该研究的报道中被总结）建议把长文档放在查询之前，并指出把查询放在最后，在 Anthropic 对复杂的、多文档输入的测试中，可将质量提高多达 30%。

如何顺应窗口工作，而不是与它对抗

有几个习惯直接源于上述机制：

在长提示的开头放上关键指令，并在结尾、靠近问题处再次重申任务和关键约束。
让提示保持在任务允许的范围内尽量简短。移除重复的背景、旧草稿和答案不需要的文档。
对于长文档，就具体章节提问，并引用你指的那段原文，而不要假设埋在中间的一处事实会被用上。
在非常长的聊天中，重述重要的人名、数字和决定，而不要依赖早期消息或自动摘要精确地保留它们。
新任务开一次新聊天。带着一段长而不相关的历史，会浪费窗口空间并增加相互竞争的指令。
对照外部来源核查重要输出。生成产出的是流畅的文本，而不是经过核实的文本。

小结

聊天机器人读取的是词元而不是词，就英文而言，每个词元约为 4 个字符或一个单词的四分之三。它通过一次采样一个词元来写作，并且只能使用该请求上下文窗口中能装下的内容。当一段长聊天看起来忘了什么，原因通常是窗口已满、摘要丢掉了某个细节，或者一处关键事实位于长提示的中间。更短的提示、重申的约束，以及放在开头或结尾附近的关键材料，是顺应这一设计而非与它对抗。而由于窗口中的一切都会发送给服务方，一次聊天对服务方本身从来都不是私密的；VPN 改变的是谁能监视连接，而不是服务方收到了什么。