Token 是大语言模型处理文本的最小意义单位，作为原始文本与数字表示之间的桥梁。解析了 Token 的定义、特点及映射机制，探讨了其在上下文窗口、训练数据及成本计算中的影响。同时介绍了 Tokenization 的七种类型、面临的挑战以及应对长度限制的策略，展望了多模态 Token 技术的发展方向。
在大语言模型（LLM）的世界里，Token 是一个基础且重要的概念。它是模型可以理解和生成的最小意义单位，是模型处理文本的基础单元。它就像是模型世界里的'积木块'，模型通过对这些'积木块'的操作来理解和生成文本。根据所使用的特定标记化方案，Token 可以表示单词、单词的一部分，甚至只表示字符。
例如，对于英文文本，'apple'可能是一个 Token，而对于中文文本，'苹果'可能是一个 Token。但有时候，Token 并不完全等同于我们日常理解的单词或汉字，它还可能是单词的片段，比如'playing'可能被拆分为'play'和'ing'两个 Token。
为了让模型能够处理这些 Token，它们会被赋予数值或标识符，并按序列或向量排列，然后被输入或从模型中输出。简单来说，Token 是原始文本数据和 LLM 可以使用的数字表示之间的桥梁。
这里有一些帮助理解 Token 长度的经验法则：
在 OpenAI 的 API 参数中，max_tokens 参数指定模型应该生成一个最大长度为 60 个令牌的响应。可以通过 https://github.com/openai/tiktoken 来观察 token 的相关信息。
我们可以先用 OpenAI 的 playground 来看一个例子：'Dec 31, 1993. Things are getting crazy.'
使用 GPT-3 tokenizer 将相同的单词转换为 token:
词汇表将 Token 映射到唯一的数值表示。由于 LLM 使用数字输入，所以词汇表中的每个 Token 都被赋予一个唯一标识符或索引。这种映射允许 LLM 将文本数据作为数字序列进行处理和操作，从而实现高效的计算和建模。
为了捕获 Token 之间的意义和语义关系，LLM 采用 Token 编码技术。这些技术将 Token 转换成称为嵌入的密集数字表示。嵌入式编码语义和上下文信息，使 LLM 能够理解和生成连贯的和上下文相关的文本。
像 Transformer 这样的体系结构使用 self-attention 机制来学习 Token 之间的依赖关系并生成高质量的嵌入。
Token 级别的操作是对文本数据启用细粒度操作。
LLM 可以生成 Token、替换 Token 或掩码 Token，以有意义的方式修改文本。这些 Token 级操作在各种自然语言处理任务中都有应用：
在将文本发送到 LLM 进行生成之前，会对其进行 tokenization（标记化）。每个模型都以不同的方式执行这一步骤，例如，GPT 模型使用字节对编码（BPE）。Token 会在 tokenizer 发生器的词汇表中分配一个 id，这是一个将数字与相应的字符串绑定在一起的数字标识符。
例如，'Matt'在 GPT 中被编码为 Token 编号（13448），而'Rickard'被编码为两个标记，'Rick'，'ard'带有 id（8759, 446），GPT-3 拥有 1400 万字符串组成的词汇表。
不过，Token 的设计也存在一些局限性：
（'3000'），（'3'，'100'），（'35'，'00'），（'4'，'500'）。这种数字分块的不一致性或许就是为什么基于 GPT 的模型并不总是擅长数学计算的原因之一，因为模型难以对数字形成统一、准确的理解和处理方式。（'once'、'upon'、'a'、' '）。然而，'once on a time'被编码为 （'once'，'upon'，'a'，'time'）。因为'time'是带有空格的单个 Token，所以将空格添加到提示词将影响'time'成为下一个 Token 的概率。这说明文本中的空格在 Token 化过程中也会产生影响，模型对于带有空格和不带有空格的相同文本片段，会生成不同的 Token 序列，进而可能影响模型的输出结果。上下文窗口是模型一次可以处理的 Token 的最大数量。如果要求模型生成的 Token 数量超过上下文窗口，它将在块中这样做，这可能会导致块之间失去一致性。
例如，当我们与大模型进行对话时，如果输入的文本过长，超出了模型的上下文窗口限制，模型可能无法完整地理解整个输入文本的上下文信息，从而使得生成的回答在连贯性和准确性上出现问题。不同的大模型具有不同大小的上下文窗口，一些先进的模型不断拓展上下文窗口的大小，以提高对长文本的处理能力。
模型的训练数据中 Token 的数量是模型已经学习的信息量的度量。然而，模型的响应是更'一般'还是'详细'与这些 Token 数量没有直接关系。模型响应的普遍性或特异性更多地取决于它的训练数据、微调和生成响应时使用的解码策略。对不同数据进行训练的模型往往会产生一般性的响应，而对具体数据进行训练的模型往往会产生更详细的、针对具体情况的响应。例如，对医学文本进行微调的模型可能会对医学提示产生更详细的响应。
解码策略也起着重要的作用。修改模型输出层中使用的 SoftMax 函数的'temperature'可以使模型的输出更加多样化（更高的温度）或者更加确定（更低的温度）。在 OpenAI 的 API 中设置 temperature 的值可以调整确定性和不同输出之间的平衡。
需要记住，每一个语言模型，不管它的大小或者它被训练的数据量如何，只有它被训练的数据、它被接收的微调以及在使用过程中使用的解码策略才可能是最有效的。为了突破 LLM 的极限，可以尝试不同的训练和微调方法，并使用不同的解码策略。同时，要注意这些模型的优缺点，并始终确保用例与正在使用的模型功能保持一致。
将文本划分为不同 token 的正式过程称为 tokenization。tokenization 捕获文本的含义和语法结构，从而需要将文本分割成重要的组成部分。
tokenization 是将输入和输出文本分割成更小的单元，由 LLM AI 模型处理的过程。tokenization 可以帮助模型处理不同的语言、词汇表和格式，并降低计算和内存成本，还可以通过影响 token 的意义和语境来影响所生成文本的质量和多样性。根据文本的复杂性和可变性，可以使用不同的方法进行 tokenization，比如基于规则的方法、统计方法或神经方法。
OpenAI 以及 Azure OpenAI 为其基于 GPT 的模型使用了一种称为'字节对编码 (Byte-Pair Encoding, BPE)'的子词 tokenization 方法。
BPE 是一种将最频繁出现的字符对或字节合并到单个标记中的方法，直到达到一定数量的标记或词汇表大小为止。BPE 可以帮助模型处理罕见或不可见的单词，并创建更紧凑和一致的文本表示。BPE 还允许模型通过组合现有单词或标记来生成新单词或标记。词汇表越大，模型生成的文本就越多样化并富有表现力。但是，词汇表越大，模型所需的内存和计算资源就越多。因此，词汇表的选择取决于模型的质量和效率之间的权衡。
基于用于与模型交互的 token 数量以及不同模型的不同速率，大模型的使用成本可能大不相同。例如，截至 2023 年 2 月，使用 Davinci 的费率为每 1000 个令牌 0.06 美元，而使用 Ada 的费率为每 1000 个令牌 0.0008 美元。这个比率也根据使用的类型而变化，比如 playground 和搜索等。因此，tokenization 是影响运行大模型的成本和性能的一个重要因素。
tokenization 涉及到将文本分割成有意义的单元，以捕捉其语义和句法结构，可以采用各种 tokenization 技术，如字级、子字级 (例如，使用字节对编码或 WordPiece) 或字符级。根据特定语言和特定任务的需求，每种技术都有自己的优势和权衡。
LLM 已经扩展了处理多语言和多模式输入的能力。为了适应这些数据的多样性，已经开发了专门的 tokenization 方法。通过利用特定语言的 token 或子词技术，多语言标记在一个模型中处理多种语言。多模态标记将文本与其他模式 (如图像或音频) 结合起来，使用融合或连接等技术来有效地表示不同的数据源。
tokenization 在 LLM 的效率、灵活性和泛化能力中起着至关重要的作用。
通过将文本分解成更小的、可管理的单元，LLM 可以更有效地处理和生成文本，降低计算复杂度和内存需求。此外，tokenization 通过适应不同的语言、特定领域的术语，甚至是新兴的文本形式 (如互联网俚语或表情符号) 提供了灵活性。这种灵活性允许 LLM 处理范围广泛的文本输入，增强了它们在不同领域和用户上下文中的适用性。
tokenization 技术的选择涉及到粒度和语义理解之间的权衡。单词级标记捕获单个单词的意义，但可能会遇到词汇表外 (OOV) 术语或形态学上丰富的语言。子词级 tokenization 提供了更大的灵活性，并通过将单词分解为子词单元来处理 OOV 术语。然而，在整个句子的语境中正确理解子词标记的意义是一个挑战。tokenization 技术的选择取决于特定的任务、语言特征和可用的计算资源。
真实世界的文本数据通常包含噪音、不规则性或不一致性。tokenization 在处理拼写错误、缩写、俚语或语法错误的句子时面临挑战。处理这些噪音数据需要健壮的预处理技术和特定领域的 tokenization 规则调整。此外，在处理具有复杂编写系统的语言时，tokenization 可能会遇到困难，例如标志脚本或没有明确词边界的语言。解决这些挑战通常涉及专门的 tokenization 方法或对现有 tokenizer 的适应。
tokenization 是特定于模型的。根据模型的词汇表和 tokenization 方案，标记可能具有不同的大小和含义。例如，像'running'和'ran'这样的单词可以用不同的标记来表示，这会影响模型对时态或动词形式的理解。不同模型训练各自的 tokenizer，而且尽管 LLaMA 也使用 BPE，但 token 也与 ChatGPT 不同，这使得预处理和多模态建模变得更加复杂。
我们需要知道当前任务的 token 使用状况，然后，面对大模型的 token 长度限制，可以尝试一些解决方案。
这里采用 OpenAI 的 API，使用 langchain 应用框架来构建简单应用，进而描述当前文本输入的 token 使用状态。
from langchain.llms import OpenAI
from langchain.callbacks import get_openai_callback
llm = OpenAI(model_name="text-davinci-002", n=2, best_of=2)
with get_openai_callback() as cb:
result = llm("给我讲个笑话吧")
print(cb)
对于 Agent 类型的应用而言，可以用类似的方法得到各自 token 的统计数据。
from langchain.agents import load_tools
from langchain.agents import initialize_agent
from langchain.agents import AgentType
from langchain.llms import OpenAI
llm = OpenAI(temperature=0)
tools = load_tools(["serpapi","llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)
with get_openai_callback() as cb:
response = agent.run("Who is Olivia Wilde's boyfriend? What is his current age raised to the 2023?")
print(f"Total Tokens: {cb.total_tokens}")
print(f"Prompt Tokens: {cb.prompt_tokens}")
print(f"Completion Tokens: {cb.completion_tokens}")
print(f"Total Cost (USD): ${cb.total_cost}")
像 GPT-3/4，LLaMA 等这样的大模型有一个最大 token 数量限制，超过这个限制，它们就不能接受输入或生成输出。
一般地，我们可以尝试以下方法来解决 token 长度限制的问题：
虽然 token 传统上代表文本单位，但是 token 的概念正在超越语言要素的范畴。最近的进展探索了其他模式 (如图像、音频或视频) 的标记，允许 LLM 与这些模式一起处理和生成文本。这种多模式方法为在丰富多样的数据源背景下理解和生成文本提供了新的机会。它使 LLM 能够分析图像标题，生成文本描述，甚至提供详细的音频转录。
tokenization 领域是一个动态和不断发展的研究领域。未来的进步可能集中于解决 tokenization 的局限性，改进 OOV 处理，并适应新兴语言和文本格式的需要。而且，将继续完善 tokenization 技术，纳入特定领域的知识，并利用上下文信息来增强语义理解。tokenization 的不断发展将进一步赋予 LLM 以更高的准确性、效率和适应性来处理和生成文本。
Token 是支持 LLM 语言处理能力的基本构件。理解 token 在 LLM 中的作用，以及 tokenization 方面的挑战和进步，使我们能够充分发挥这些模型的潜力。随着继续探索 token 的世界，我们将彻底改变机器理解和生成文本的方式，推动自然语言处理的边界，促进各个领域的创新应用。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online