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

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

优劣分析

优点

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

缺点

割裂字符联系：增大词表可能会割裂token与token之间在字符层面的联系，影响模型的泛化能力。例如，“太阳能”和“太阳”都是词表中的一个词时，模型可能不知道“太阳能”是由“太阳”和“能”组成，从而难以完成一些子词相关的任务。
续写问题：增大词表后，常见的命令或短语可能被视为单个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输入模型，模型可能无法续写出“广州/的/白云机场”等结果。因此，我们可以进行以下步骤：

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

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

文章小结

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