魚羊 發自 凹非寺
量子位 | 公衆号 QbitAI
關于大模型分詞（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億美元。
自動檢測LLM中訓練不足的token
研究人員提出的方法主要包括三個步驟。
首先，通過檢查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
— 完 —
量子位 QbitAI · 頭條号
關注我們，第一時間獲知前沿科技動态簽約