大神Karpathy强推,分词领域必读:自动钓鱼让大模型“发疯”的token,来自Transformer作者创业公司
关于大模型分词(tokenization),大神Karpathy刚刚推荐了一篇必读新论文。
主题是:自动检测大模型中那些会导致“故障”的token。
简单来说,由于大模型tokenizer的创建和模型训练是分开的,可能导致某些token在训练中很少、甚至完全没出现过。这些“训练不足”(under-trained)的token会导致模型产生异常输出。
最经典的例子,就是SolidGoldMagikarp——
这个单词一度让ChatGPT“胡言乱语”。只要prompt里包含这个词,ChatGPT就开始文不对题,生成一些混乱的输出:
现在,来自Cohere的研究人员针对这个问题,提出检测“故障”token的有效方法,他们还发现:在多个主流开源大语言模型上,包括Llama系列、Mistral系列在内,训练不足的token都在不同程度上普遍存在。
p.s. Cohere是Transformer最年轻作者Aidan Gomez创办的公司,此前推出了Command R系列开源大模型。去年6月,该公司估值达到了22亿美元。
研究人员提出的方法主要包括三个步骤。
首先,通过检查tokenizer词汇表并观察其编码/解码行为,来分析tokenizer,找出其中特殊类别的token,比如不完整的UTF-8序列等。
然后,根据模型架构计算识别指标,找出嵌入向量异常的token,列入“训练不足”候选名单。
举个例子,对于tied embedding模型,利用一组已知的未使用的embedding,通过主成分分析去除unembedding矩阵中的常数成分。
接着计算其余token和这些未使用embedding的余弦距离,作为“训练不足”指标。
而对于non-tied embedding的模型,可以直接采用embedding向量的L2范数来检测。
最后,通过特定prompt来进行验证,看看候选token们是否确实超出了训练数据的分布,会引发异常输出。
将该方法应用于多个主流的开源大语言模型后,研究人员发现,训练不足能让大模型“发疯”的token在这些大模型上普遍存在,他们一口气就挖出了数千个。
常见类型包括:
单字节token,尤其是UTF-8标准中未使用的字节,如0xF5-0xFF;字节对编码(Byte-Pair Encoding,BPE)过程中,出现的一些未充分训练的中间token。一些特殊字符,如
研究人员还发现,词汇表较大的模型,“训练不足”token的数量也会明显增多。
因为大词汇表意味着更稀疏的token分布和更细粒度的token切分,这必然会导致更多低频token和无意义的token残片,增加“训练不足”token的比例。同时,大词汇表也给模型训练带来了更大的优化难度。
值得注意的是,论文提到,基于相同tokenizer的模型表现相似,而不同的tokenizer实现、配置、训练数据,会导致不同模型间“训练不足”token的明显差异。
论文认为,优化词汇表结构和tokenizer算法,是解决token训练不足问题的关键。
他们也提出了一些建议:
— 完 —
- 免责声明
- 本文所包含的观点仅代表作者个人看法,不代表新火种的观点。在新火种上获取的所有信息均不应被视为投资建议。新火种对本文可能提及或链接的任何项目不表示认可。 交易和投资涉及高风险,读者在采取与本文内容相关的任何行动之前,请务必进行充分的尽职调查。最终的决策应该基于您自己的独立判断。新火种不对因依赖本文观点而产生的任何金钱损失负任何责任。