类脑大模型“瞬悉“的tokenization化

目前的大模型只要没有做过手脚专门针对性的调试过，它必然会答错“groooooooot有几个o”这样的问题，其根本原因是大模型的tokenization机制导致的字符不可精确操作与计数。

中国的类脑大模型"瞬悉"（SpikingBrain-1.0）也使用了Tokenization技术。作为大语言模型的一种，它很可能遵循了类似的处理流程，即文本 → token → ID → embedding（向量）。tokenization对于大模型来说，几乎是必不可少的一步。

下面是一个表格，汇总了tokenization的主要作用、带来的问题以及常见的应对策略：

🔄 Tokenization为何近乎必需？

Tokenization之所以在大模型（包括"瞬悉"）中近乎必需，主要因为它是连接人类语言和机器计算的桥梁：

1. 文本数值化：计算机只能处理数字。Tokenization将文本转换成离散的token，进而映射为数字ID，最终转换为向量（Embedding），模型才能进行处理。
2. 计算效率：直接处理字符或单词级别，要么序列过长（字符），要么词表过大（单词）。子词分词（如BPE、SentencePiece）在两者间取得了平衡，能用较小的词表覆盖较大的语言范围，提高了计算效率。
3. 模型设计的基础：现代大模型（包括Transformer和"瞬悉"这类非Transformer架构）的输入通常都是token序列。模型的结构、注意力机制（或其替代机制）等都是基于token序列设计的。

⚠️ Tokenization带来的挑战

Tokenization虽然有效，但也确实会带来一些问题：

1. 字符不可精确操作与计数：分词后，原始的字符或词边界信息会丢失。例如，中文句子“苹果手机很好用”，不同模型的分词结果可能不同：
   • GPT-4可能分：['苹', '果', '手', '机', '很', '好', '用'] (7个token)
   • LLaMA可能分：['苹果', '手机', '很', '好', '用'] (5个token)
     这使得精确计算字符数变得困难，除非完全按照模型的分词器进行还原。
2. 语义碎片化：不合理的分词可能将有意义的词拆分成无意义的片段，影响模型对语义的理解。例如，将“人工智能”错误地拆分为“人工”和“智能”可能还能理解，但若拆分成“人”、“工”、“智”、“能”就可能丢失部分整体含义。
3. 计算成本与序列长度：Token的数量直接决定了模型的计算量。处理长文本时，token序列会很长，对模型的记忆体和计算能力要求很高。虽然“瞬悉”通过线性复杂度设计缓解了这个问题，但token序列长度仍然是需要关注的因素。

🛠️ 应对策略

对于Tokenization带来的问题，尤其是字符操作和计数不精确的问题，可以尝试以下方法：

1. 理解并接受差异：首先要明确模型的“token”不是天然的“词”或“字”，而是模型视角下的基本单元。在进行字符级精确操作时，需要使用模型相同的分词器进行处理和反向转换，而不是依赖简单的空格或标点分割。
2. 后处理与校正：模型输出后，可以根据需要对token序列进行后处理，例如连接特定的子词token、去除不必要的空格等，以生成更符合人类阅读习惯的文本。
3. 选择合适的分词器与模型：
   • 不同的分词器对同一文本的分词结果不同。如果你对字符边界有严格要求，可以尝试比较不同模型的分词方式，选择更符合你需求的。
   • 关注像“瞬悉”这类在长序列处理上有优势的模型，它们可能通过架构创新降低长token序列带来的负担。
4. 算法优化：“瞬悉”本身采用的线性复杂度设计，就是对传统Transformer平方复杂度的一种优化，旨在更高效地处理长token序列，这对缓解计算压力有帮助。

💎 结论

总的来说，Tokenization是目前大语言模型处理文本信息的一项核心且几乎不可或缺的技术，类脑大模型“瞬悉”也大概率使用了这一技术。

它虽然会带来字符操作不精确等问题，但通过理解其原理、利用相同分词器处理、并进行适当的后校正，是可以在很大程度上应对这些挑战的。同时，像“瞬悉”这类新型模型也在通过架构创新，努力优化长序列处理的效率。