今天小編分享的科學經驗：大神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
— 完 —
點這裏關注我，記得标星哦～
一鍵三連「分享」、「點贊」和「在看」
科技前沿進展日日相見 ~
>
