今天小编分享的科学经验：大神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。
一些特殊字元，如 <pad>、<unk> 等。
研究人员还发现，词汇表较大的模型，" 训练不足 "token 的数量也会明显增多。
因为大词汇表意味着更稀疏的 token 分布和更细粒度的 token 切分，这必然会导致更多低频 token 和无意义的 token 残片，增加 " 训练不足 "token 的比例。同时，大词汇表也给模型训练带来了更大的优化难度。
值得注意的是，论文提到，基于相同 tokenizer 的模型表现相似，而不同的 tokenizer 实现、配置、训练数据，会导致不同模型间 " 训练不足 "token 的明显差异。
论文认为，优化词汇表结构和 tokenizer 算法，是解决 token 训练不足问题的关键。
他们也提出了一些建议：
确保 tokenizer 训练数据、模型训练数据和模型推理中输入数据的预处理完全相同。
确保模型训练数据和 tokenizer 对齐，尤其是在从头训练新的基础模型时。
对于单字节 token，要么词汇表包含所有 256 个字元且不允许重复，要么排除 13 个 UTF-8 中不出现的字元（0xC0/0xC1，0xF5-0xFF）。
训练 tokenizer 后，通过对词汇表进行编码和解码来检查无法访问的 token，以确保正确处理手动添加的 token。
在 Hugging Face 上发表 tokenizer 的 " 快速 " 和 " 慢速 " 版本时，确保它们输出相同。
训练基础模型时，在小型测试中检查训练不足的 token，重新考虑分词方法和数据。在不同语料库上运行测试，也可以发现导致主训练数据中 " 故障 " 输入的预处理错误。
论文地址：
https://arxiv.org/abs/2405.05417
— 完 —
点这里关注我，记得标星哦～
一键三连「分享」、「点赞」和「在看」
科技前沿进展日日相见 ~
>
