搞懂Token压缩术:如何让你的大模型输入更少、理解更多?在关注大模型技术时,你一定经常听到 Context Window(上下文窗口) 这个概念。
比如某些主流大模型的上下文窗口高达 40 万——这代表它一次最多能够处理 40 万个Token。请注意,这里说的是 40 万个 Token,而不是 40 万个字,也不是 40 万个词。
那么,究竟什么是 Token?它是怎么生成的?它和我们日常使用的字、词到底有什么关系?今天这篇文章,带你彻底看懂大模型背后的文字奥秘。
一、为什么大模型需要一个翻译官?
要理解 Token,首先要从大模型的基本运行原理说起。
本质上,大模型是一个巨大的数学函数,内部全都是矩阵运算。它输入的是数字,输出的也是数字,根本就无法直接理解人类的文字。
因此,在人类文字与大模型之间,必须站着一个翻译官——Tokenizer(分词器)。
Tokenizer 主要负责两个核心环节:
- 编码(Encoding): 把人类的文字转换为模型能听懂的数字。
- 解码(Decoding): 把模型输出的数字,再转回人类能看懂的文字。
1. 编码环节的两步走
当用户输入一句话时,Tokenizer 会执行两个具体步骤:
- 第一步:切分(Tokenization)。 把一句话切成一个一个最小的单位,这些切出来的碎片就叫做 Token。
- 第二步:映射。 因为模型只认数字,Tokenizer 会把每一个 Token 映射为一个对应的数字,这个数字就叫做 Token ID。
Token(文字)与 Token ID(数字)是一对一的关系,就像硬币的正反面,表达的内容完全一样,只是表现形式不同。
2. 解码环节
大模型在内部完成数学运算后,会吐出一个 Token ID。此时 Tokenizer 再次登场,将这个 Token ID 反向映射回文字。因为模型每次只输出一个 Token,所以解码阶段不需要进行复杂的切分,只需直接进行反向映射即可。
二、Token 是如何被创造出来的?
既然 Token 如此重要,那它是怎么来的?其实,Tokenizer 本身也是被训练出来的。
目前业界有很多实现 Tokenizer 的算法,比如 Google 常用的 Unigram,以及 OpenAI 和 Anthropic 多使用的 BPE(Byte Pair Encoding,字节对编码) 算法。
以 BPE 算法为例,其训练原理非常简单:从海量文章中,找出哪些字经常在一起使用,然后把它们合并为一个新的 Token。
- 初始化词表: 训练开始时,算法会把训练材料里所有出现过的单字都放进词表里,并为每个单字分配一个编号(Token ID)。
- 寻找规律并合并: 算法开始扫描文本。如果发现智和障这两个字经常形影不离,频率最高,算法就会执行合并,将智障作为一个不可分割的整体。
- 更新规则: 接着,把智障这个新词加入词表(分配新 ID),并在合并规则中记录下:
智 + 障 = 智障。 - 循环往复: 算法会继续扫描。比如发现人和渣经常在一起,就合并为人渣;甚至会把已经合并过的词再次合并,比如将人渣和智障合并为更长的词——人渣智障。
通过这种方式,Tokenizer 最终训练完成,它最核心的资产就是一张词表和一套合并规则。在后续实际面对用户提问时,它就会严格按照这套合并规则的顺序去切分文本。
三、Token压缩术:Tokenizer它不只是翻译官,更是压缩机
看到这里,你就能明白为什么 40 万个 Token 不等于 40 万个字了。
因为 Tokenizer 不仅是一个翻译器,它还是一个文字压缩机!
如果只用单字作为 Token,模型输入的序列会非常长,计算效率极低。但通过将常见词合并为单个 Token,原本由 9 个字组成的句子(例如:“你大爷喜欢人渣智障吗?”),经过 Tokenizer 的合并规则切分后,可能直接被压缩成了 4 个 Token。
Token 变少了,大模型的输入变短了,模型的训练和推理效率也就大幅提升了。
写在本文的最后
日常使用中,如何换算 Token?
在总体层面上,Token 与人类语言的字词之间存在着一个大致的换算比例:
- 汉字: 1 个 Token 大概能代表 1.5 到 2 个汉字。
- 英文: 1 个 Token 大概代表 4 个英文字母,或者说 0.75 个英文单词。
按照这个比例来换算: 如果一个大模型拥有 40 万 的 Context Window(上下文窗口),它实际上大致可以一次性处理 60 万到 80 万个汉字,或者约 30 万个英文单词。
掌握了这套文字压缩的换算概念,以后你在看各大模型的参数和技术文档时,心里就会有一杆更清晰的秤了!
