Token、上下文与多轮对话

Token 是文字进入模型时使用的单位

人阅读文字时会看词、句子和段落；语言模型通常先通过一个叫“分词器”的组件，把文本转成 Token 序列。Token 可以对应一个词、词的一部分、一个字符或其他片段，再用编号表示，方便模型计算。

这不是固定的字数换算。不同模型可能使用不同分词器，同样一句中文在不同模型里可能得到不同数量的 Token。标点、空格、英文缩写和代码也会影响划分。因此，看到“支持多少 Token”时，不能直接当作“支持多少个汉字”。

你无需手工给文本分词。知道这个单位的用途就够了：服务通常用它描述输入输出长度，许多接口也用它统计用量。图片和音频可能另有计量方式，具体需要看所用模型的说明。

上下文包括什么

上下文（context）是模型本次处理时能够使用的信息。它可能包括系统规则、用户问题、选取的历史对话、上传材料中的文字，以及工具刚刚返回的结果。它并不限于输入框中最后一句话。

假设你先说“请把这段通知改写成三句话”，模型给出结果后，你继续说“再自然一点”。第二句话本身没有完整任务，但应用如果把上一段对话一起交给模型，它就能知道要修改哪段通知。

如果新请求没有携带这些内容，也没有通过应用的状态机制取回，模型就不能可靠地知道它们。聊天看起来连续，是应用管理对话的结果，不能理解成模型有一份无限且自动可靠的人类记忆。

上下文窗口为什么有限

模型或服务对一次能处理的信息有容量限制，常被称为上下文窗口。长材料、历史消息、工具结果和输出可能共同占用相关限制；输入和输出怎样共享额度，各服务的规定不完全一样。

超过限制时，应用可能报错，也可能选择较近的消息、压缩历史，或只检索相关片段。你看到页面里仍保存着十万字聊天，不代表模型这次完整看到了十万字。

即使内容都放进去了，也不保证模型准确使用每个细节。旧日期与新日期混在一起、关键限制埋在大量闲聊中，都可能造成误用。窗口大小回答的是“能处理多少”，不直接回答“理解得是否准确”。

怎样组织上下文才更有帮助

对一个正在推进的任务，可以把当前状态整理为四项：目标、必须满足的条件、已经确认的事实、尚待解决的问题。例如“为12人找周日下午的场地，预算600元；A已确认关闭；接下来查B”。这比把过去每一次猜测都保留下来更清楚。

需要更新条件时，写明什么被替换，例如“活动改到周六，原来的周日安排作废”。需要新开对话时，重新提供仍然有效的材料。不要让模型从互相矛盾的历史里替你决定哪一个版本算数。

当资料多到无法每次完整提供时，可以先找相关部分，再交给模型回答。后面的知识库与 RAG 课程讲的，正是这种组织资料的方法。