token 与分词:为什么模型看文本的方式很奇怪

当你向语言模型敲入一个句子时,你看到的是词语。模型看到的却不是。在任何"思考"发生之前,你的文本就被切成了称为 token 的片段,而模型实际处理的,正是这些 token——不是字母,也不是词语。这单单一个翻译步骤,解释了数量惊人的、否则令人费解的行为:为什么模型会数错一个词里的字母、为什么有些语言处理起来更贵、为什么你的输入会比你预期更早撞上长度限制,以及为什么粘贴一个奇怪的字符串有时会产出奇怪的输出。一旦你弄懂了分词,许多模型的怪癖就不再是谜了。

token 究竟是什么

一个 token 是一段文本——通常是一个常见词、一个词的片段、一个空格加词,或单个字符。它是模型读和写的单元。一个短的常见词如 "the" 往往是一个 token。一个更长或更罕见的词可能被拆成好几个:像 "tokenization" 这样的词可能变成 "token" + "ization",而一个不寻常的人名可能碎成许多小片。

关键的洞见是,token 既不等同于词语,也不等同于字符。它们居于两者之间。模型对语言的全部视野,都是由这些块搭建起来的。当它生成一个响应时,它是一次产出一个 token,每一个都基于在它之前来到的那些 token 来选择。它没有任何一刻是以字母或整句为基本单元来工作的。

究竟为什么要把文本切开

把整词、或单个字符喂给模型,似乎会更简单。可两个极端都会引发问题,而分词是个折中。

如果你用整词,你的词表会大得吓人,而你仍会不断遇到从未见过的词——拼写错误、新俚语、技术术语、人名。模型将无从处理它们。

如果你用单个字符,词表会很小,而且没有任何东西会是未知的,但每一段文本都会变成一个非常长的序列,模型还得从原始字母里从头学起意义。那既浪费又缓慢。

分词折中了两者。常见词为求高效而拥有它们自己的 token。罕见词被拆成更小、可复用的片段,于是模型可以通过组装熟悉的碎片来处理任何东西——即便一个它从未见过的词,因为它见过那些碎片。这就是为什么模型能优雅地应对新词:它们生来就是为了从子词部件中重新拼凑意义。

为什么模型"看文本的方式很奇怪"

关键的后果在此:因为模型在 token 上运作,某些对人来说轻而易举的任务,对模型来说却变得奇怪地困难。

想想数一个词里的字母、把它倒过来、或注意到两个词押韵。对你来说,这些是关于单个字母的。但模型可能是把整个词当成一个单一 token 收到的——一个不透明的块,内部没有可见的字母。让它数一个词里有几个 r,就像让一个人去数一个他只把它认作一个整体形状的符号里有几个字母。那信息技术上可以恢复,但它逆着模型表征文本的方式。这就是许多"AI 不会拼写"轶事背后的真正原因。这不是愚蠢;而是字母层级的结构,被模型所读的那些单元本身部分地藏了起来。

同样的效应也解释了为什么模型在精确的字符操作、某些逐位写出的算术,以及那些取决于一个字符串确切内部构成而非其意义的任务上,可能不太靠谱。

为什么同样的文本花费不同的量

token 也是度量和计费的单元。模型的使用和定价通常以 token 来计,而非词或字符。这有一些值得内化的现实后果。

不同语言以非常不同的效率分词。一种在分词器训练中代表充分的语言,其文本倾向于每个意思打包进更少的 token,而其他语言——或分词器处理起来效率较低的文字——可能需要多得多的 token 来表达同样的内容。结果是,同一个意思在一种语言里处理起来,可能比在另一种里明显更贵。代码、结构化数据,或满是不寻常符号的文本也是同理:它可能碎成比同样可见长度的纯散文更多的 token。

对于典型的英语散文,一条常被引用的粗略经验法则是,平均一个 token 相当于略少于一个词——但把任何这样的比率都当成一个宽松的参考,而非一个常数。知道 token 数的唯一可靠办法,是用那个具体模型的分词器去度量它,因为每个模型家族的分词方式可能不同。

token 与上下文窗口

每个模型都有一个上下文窗口:它在一次交流中能接收并产出的最大 token 数,输入和输出合计。那个限制是以 token 度量的,这就是为什么同一个窗口会因你往里放什么而感觉更大或更小。

这也是为什么长文档任务需要小心。一份在屏幕上看着中等的文档,可能消耗远超你猜测的窗口份额,尤其当它是一种分词起来啰嗦的语言,或满是格式和符号。当你在设计任何处理大型输入的东西时,以 token 而非以页或字符来思考,能让你不至于被一个被截断的输入、或一个悄无声息超出限制的请求弄个措手不及。

现实中的启示

一旦 token 成了你心智模型的一部分,有几个习惯会自然而然地随之而来:

• 别随随便便让模型做字母层级的"手术"。 数字符、倒转字符串及类似任务,都和 token 表征对着干。如果你需要它们被可靠地完成,就倚靠一个工具,而非模型的直觉。
• 以 token 而非以词来估算长度, 当你逼近一个上下文限制或盯着成本时——并且对任何重要的东西去度量而非去猜。
• 预期成本和长度会因语言和内容类型而异, 并据此做预算,而不是假定各语言之间是对等的。
• 别过度信任视觉长度。 一团看着短的代码或符号可能是 token 密集的;一长段纯散文可能比它看起来更轻。

总结

token 是你的文本和模型之间的隐藏层。模型所读和所写的一切,都是由这些块构成的——通常是词和词的碎片——它们作为一个折中而被选定,介于笨重的整词词表和低效的逐字符处理之间。正是这个折中,让模型能优雅地处理任何文本,但它也藏起了字母层级的细节,这就是为什么精确的拼写和字符任务会把它们绊倒。它让 token 成为度量长度、成本和上下文限制的天然单元,也解释了为什么同一个意思在一种语言里会更贵。你很少需要直接去查看 token,但把它们记在心里,能把一整类奇怪的模型行为变成可以预料的东西。