增大 Tokenizer 词表：LLM 续写任务的新挑战与解决方案

语言模型 （LLM） 在自然语言处理中的应用越来越广泛，而通过增大 Tokenizer 的词表来提高压缩率，从而缩短串行长度、降低解码成本，是大家都喜闻乐见的事情。然而，这种方法在带来诸多优点的同时，也可能产生一些问题。本文将探讨增大词表后语言模型在续写任务中遇到的问题，并提出解决方案。

优劣分析

优点

1. 解码速度提升：由于 LLM 是自回归的，解码过程会随着序列长度的增加变得越来越慢。通过 「增大词表 → 提高压缩率 → 缩短串行长度」，可以减少相同文本对应的 tokens 数量，从而减少解码步数，提升解码速度。
2. 缓解 Exposure Bias：语言模型的训练方式通常是 Teacher Forcing，缩短串行长度能够缓解 Teacher Forcing 带来的 Exposure Bias 问题，从而可能提升模型效果。

缺点

1. 割裂字符联系：增大词表可能会割裂 token 与 token 之间在字符层面的联系，影响模型的泛化能力。例如，「太阳能」 和 「太阳」 都是词表中的一个词时，模型可能不知道 「太阳能」 是由 「太阳」 和 「能」 组成，从而难以完成一些子词相关的任务。
2. 续写问题：增大词表后，常见的命令或短语可能被视为单个 token，导致模型在续写时无法正确生成。例如，「import numpy as np」 被当作一个 token，用户输入 「import numpy」 时，模型无法续写出 「 as np」 。

续写问题

Armen Aghajanyan 分享了一个典型的例子：在训练代码模型时使用超大词表，导致 「import numpy as np」 变成了一个 token 。当用户输入 「import numpy」 时，模型无法续写出 「 as np」 。这种现象在自然语言模型中也很常见。例如，「太阳能」 和 「太阳」 都是独立的 token 时，用户输入 「太阳」 后，模型续写出的内容可能不符合用户的期望。

参考对策

虽然 Armen Aghajanyan 提到的问题确实存在，但笔者认为通过适当的处理，这个问题不仅可以解决，还能转化为增大词表的优点。以下是一个可行的解决方案：

基于词表的前缀搜索

假设用户输入了 「广州的白云」，Tokenizer 将其分为 「广州/的/白云」 。此时，如果直接将这三个词转换为 id 输入模型，模型可能无法续写出 「广州/的/白云机场」 等结果。因此，我们可以进行以下步骤：

1. 前缀搜索：对 「白云」 进行词表的前缀搜索，假设搜索结果为 「白云」 、 「白云机场」 、 「白云山」 、 「白云路」 四个词。
2. 计算条件概率：用 LLM 计算以下条件概率：
   [latex][p(\text{白云}|\text{广州, 的})p(\text{白云机场}|\text{广州, 的})p(\text{白云山}|\text{广州, 的})p(\text{白云路}|\text{广州, 的})][/latex]
3. 归一化与采样：将条件概率归一化后进行采样，决定续写内容。例如，采样结果为 「白云机场」，则输出 「机场」，并按照 「广州/的/白云机场」 进行续写。

这种方法不仅解决了 Armen Aghajanyan 所提到的问题，还能在词表压缩率高的情况下，一次性生成更多的字。特别地，回退操作只需在采样第一步进行，从第二步开始就不需要回退操作，计算量很少。

文章小结

本文介绍了增大词表后 LLM 在续写任务中可能出现的问题，并分享了参考的解决方案。通过结合基于 LLM 的续写和基于词表的前缀搜索，可以有效地解决续写问题，并将增大词表的缺点转化为优点。希望这些思路能为语言模型的进一步优化提供参考。