用Dynamic chunk去干掉tokenizer？
圖片
一般你們下AR模型的時(shí)候，都有這個(gè)，也就是tokenzier，tokenizer是干啥的，其實(shí)就是你的分詞字典
不光有specal的token對應(yīng)的還有實(shí)際的對應(yīng)的分詞對應(yīng)的代碼，比如：
圖片
也有tokenzier沒顯示的，比如，
為什么呢？
因?yàn)樗皇俏谋灸Ｐ?，人家輸入是聲音，因?yàn)樗茿SR扯遠(yuǎn)了，回歸主題tokenizer之所以總是個(gè)獨(dú)立的model，因?yàn)樗蛅ransformer不是一個(gè)網(wǎng)絡(luò)，它也不參與transformer訓(xùn)練時(shí)候的反向傳播（和embedding層兩回事，embedding參與BP和學(xué)習(xí)），也不共享參數(shù)（其實(shí)問你為什么沒關(guān)系，你記住這點(diǎn)就夠了）
一個(gè)正常的流程是這樣的
傳統(tǒng)自回歸文本模型（如GPT/Llama）
訓(xùn)練時(shí)流程：
原始文本 → tokenizer切分 → token id序列 → embedding → Transformer → 輸出概率/預(yù)測下一個(gè)token
推理時(shí)流程：
文本 → tokenizer → token id → embedding → 模型生成token id → detokenizer（還原文本）
這個(gè)沿用了多少年的架構(gòu)的有什么問題嗎？
其實(shí)是有的
靜態(tài)分詞：只能預(yù)定義/規(guī)則分割，不隨語境、下游任務(wù)改變；
詞表對非英文、代碼、特殊字符等不友好，多語言/新詞適應(yīng)性差；
字符錯(cuò)位/擾動(dòng)很容易破壞下游表現(xiàn)（比如 misspell、空格丟失等，魯棒性差）；
tokenizer/vocab詞表一旦定型，后期無法彌補(bǔ)缺失、替換麻煩。
造車上面那幾個(gè)問題的原因：
1. 詞表構(gòu)建機(jī)制決定的“偏見”和局限
大部分主流tokenizer（BPE、WordPiece等）是基于英文語料統(tǒng)計(jì)頻率自動(dòng)生成“片段” （tokens/subwords），詞表中每個(gè)條目是按常見性排序和合并出來的。
這會(huì)導(dǎo)致詞表里絕大多數(shù)都是英語常用詞、前綴、后綴，以及特殊分隔符，對別的語言（中文、阿拉伯文、俄語）、編程代碼、emoji、數(shù)學(xué)符號(hào)等覆蓋不全，兼容性低。
2. 非英文/多語言適應(yīng)困難
- 詞表是靜態(tài)的且容量有限，比如GPT-2的vocab僅5萬-6萬個(gè)而已。英文組成大都在其中，其他語種即便包含，也非常零散或拆分得特別碎。
- 比如中文，往往被拆成單字（明/天/去/看/書），或者出現(xiàn)大量 UNK（未登錄詞）或‘##’前綴的生僻合成，而不是自然分詞和表達(dá)。
- 罕見符號(hào)/擴(kuò)展字符/emoji/古文字等，因?yàn)樵~表沒收錄，只能用char級(jí)別或fallback（拆為u8字節(jié)）編碼成很多token，表達(dá)效率極低。
3. 新詞/熱詞/代碼/專業(yè)類token的弱勢
- 領(lǐng)域?qū)Ｓ忻~（如新科技名詞、代碼單詞、化學(xué)式等）未進(jìn)入初始詞表時(shí)，只能被拆為很多“字符”或“常出現(xiàn)的前綴/后綴”碎片，模型難以捕捉其整體語義；
- 代碼文本常見變量、內(nèi)置語法結(jié)構(gòu)、斜杠點(diǎn)等符號(hào)，傳統(tǒng)tokenizer未專門優(yōu)化，往往拆的四分五裂，遠(yuǎn)不如直接字符/字節(jié)級(jí)處理。
4. 多語言詞表擴(kuò)展的工程復(fù)雜性
- 為了多語言LLM，多數(shù)方案要顯式加大詞表，或多人手動(dòng)挑選token，但詞表容量越大，embedding參數(shù)爆炸，推理速度也會(huì)下降，說到擴(kuò)詞表，比如4o當(dāng)時(shí)上市的時(shí)候都干到15萬左右了，大家還覺得它整挺好，它其實(shí)非常無奈，完了為了維護(hù)多模態(tài)，又得壓縮，導(dǎo)致一個(gè)長詞對應(yīng)一個(gè)token id，才有了那時(shí)候的一些小bug，感興趣的各位自己去找當(dāng)年的新聞。
- 有些詞永遠(yuǎn)用不上，冗余空間浪費(fèi)；而新加入的熱詞又需要重新訓(xùn)練embedding才能學(xué)出屬性。
這時(shí)候如果有兄弟玩過LSTM可能會(huì)一起來，早起是沒有tokenizer，也沒BPE這玩意的，最早是char-level來建模（注意是最早，LSTM也有token level）
char-level (字符級(jí)) 建模，是指模型的輸入輸出都是“字符”，比如 ["m", "o", "d", "e", "l"]，或者直接處理字節(jié)（每個(gè)字節(jié)一個(gè)embedding），其實(shí)就是字符映射為 embedding index，適用于玩具任務(wù)、OOV高風(fēng)險(xiǎn)任務(wù)、小數(shù)據(jù)集、很早期的英文句子生成等
- 特點(diǎn)是詞表極?。ㄖ恍韪采w所有常見字符或字節(jié)），無須分詞器，OOV問題天然不存在，對語種/符號(hào)極友好，即使所有中文字、標(biāo)點(diǎn)都可編碼進(jìn)固定的小字表（7000常用漢字以內(nèi)都能輕松搞定）
- 舊的LSTM/char-RNN/ByT5等都是純char-level（或byte-level）。
那為啥都轉(zhuǎn)去token level去了呢？
語義表達(dá)效率低：
漢語一個(gè)字的信息含量比英文小，隨便一個(gè)新詞（如“碼農(nóng)”）只能靠“碼”、“農(nóng)”兩個(gè)單字序列表達(dá)，捕捉組合語義難，長依賴seqlen變長。
序列極長：
同長度內(nèi)容，char-level序列會(huì)遠(yuǎn)比token-level長，計(jì)算/內(nèi)存/推理慢（transformer類模型自注意力時(shí)間、顯存正比于N^2,當(dāng)然這個(gè)和LSTM沒啥關(guān)系，線性注意力一直是N）。
模型收斂慢，捕捉高階結(jié)構(gòu)難：
大段話、句子、專業(yè)詞都被拆為單字或字節(jié)，模型要學(xué)會(huì)組合成“自然語言片段”需要更多層、更多數(shù)據(jù)，效率和泛化難度高于“合理分塊”的token-level或動(dòng)態(tài)chunking方案。
但是最近有CMU的人給字符level編碼翻案
這論文針對的場景就是剛才我們說的tokenizer的問題
分詞器本身是手工預(yù)處理，對語義、語境缺乏自適應(yīng)，“一刀切”方式不適合所有語種/信息結(jié)構(gòu)（比如中文/代碼/DNA等）。
靜態(tài)Token也導(dǎo)致模型易受拼寫噪聲、字符級(jí)擾動(dòng)破壞；跨領(lǐng)域遷移也更難。支持多語言費(fèi)勁。
所以誕生了dynamic chunk機(jī)制（和我自己做的項(xiàng)目dc不是一回事，我那個(gè)不是分詞和char level的）和H-net
H-Net總體架構(gòu)
核心思想：創(chuàng)造支持“動(dòng)態(tài)分塊機(jī)制”（Dynamic Chunking, DC）的層次化神經(jīng)網(wǎng)絡(luò)（H-Net），讓模型自己端到端學(xué)會(huì)：哪里是有意義的邊界，該怎么自動(dòng)分段、壓縮和聚合輸入序列。
1. 架構(gòu)圖如上面的圖
流程：
- 原始字節(jié)輸入 （從下面網(wǎng)上面看）→ 編碼器（Encoder）做初步字節(jié)級(jí)embedding（這也可以用Mamba SSM層，線性注意力，當(dāng)然也可以transformer）；
- 動(dòng)態(tài)分塊模塊（DC）模型自適應(yīng)“切片”輸入序列，按上下文/內(nèi)容決定block（被分詞的）位置。
- 主干網(wǎng)絡(luò)（Main Network）：主要參數(shù)集中于此，對已被壓縮的chunk序列做深度建模（高語義、長距離依賴捕獲）。
- 解分塊（Dechunking）：用上采樣/smoothing等方法，將高層chunk輸出重新映射回細(xì)粒度token，供解碼器（Decoder）輸出。
2. “分塊”與常規(guī)分詞對比：
常規(guī) Tokenizer：全靠規(guī)則/人工預(yù)設(shè)，只能一分到底。
動(dòng)態(tài)分塊DC：模型自動(dòng)檢測上下文變化處（如語法/語義轉(zhuǎn)換），預(yù)測邊界概率→下采樣成chunk embedding序列，高效又自適應(yīng)。
我們用一個(gè)具體例子來說明H-Net的動(dòng)態(tài)分塊（Dynamic Chunking，DC）機(jī)制是怎么“自動(dòng)檢測上下文變化”并形成chunk的。
示例文本
假設(shè)輸入文本為："The end of tokens."
1. 傳統(tǒng)tokenizer分割
例如使用BPE等，會(huì)直接把它分為
["The", "end", "of", "tokens", "."]
2. H-Net動(dòng)態(tài)分塊的流程與輸出
第一步：編碼各字節(jié)/字符
輸入會(huì)轉(zhuǎn)成：["T", "h", "e", " ", "e", "n", "d", " ", "o", "f", " ", "t", "o", "k", "e", "n", "s", "."]
每個(gè)字符/空格/符號(hào)作為一個(gè)輸入位置，初步embedding。
第二步：模型自動(dòng)“判別”邊界概率
H-Net的routing module會(huì)對每兩個(gè)相鄰embedding進(jìn)行相似度測量（比如用余弦相似度），如果發(fā)現(xiàn)：
如 ??["d", " "]???（即“單詞結(jié)束后是空格”）、??["s", "."]??（單詞結(jié)束遇到句號(hào)）等位置，embedding變化大（語法/語義上有明顯切換），相似度低，邊界概率高！
而像??["e", "n"]??、“["o", "f"]”等（單詞內(nèi)部連續(xù)字母），相似度高，邊界概率低。
這樣，模型經(jīng)過訓(xùn)練后，會(huì)在如下位置分塊邊界概率最高（比如）：
T h e _ e n d _ o f _ t o k e n s .
↑ ↑ ↑ ↑ ↑ ↑
0 0 1 0 0 1
下劃線和句號(hào)后的邊界概率更高
第三步：根據(jù)概率做動(dòng)態(tài)分塊
H-Net的downsampler會(huì)篩選出邊界概率超過一定閾值的位置，比如：
- “The end”作為一個(gè)chunk
- “of”作為一個(gè)chunk
- “tokens.”作為一個(gè)chunk
最終分塊方式可能是：
["The end", "of", "tokens."]
或者更細(xì)粒度：
["The", "end", "of", "tokens", "."]（這么分和BPE就一樣了）
chunk的大小、邊界完全由數(shù)據(jù)和上下文（而不是手工規(guī)則）自動(dòng)學(xué)到，且不同上下文還能靈活變化。
第四步：聚合chunk embedding并繼續(xù)建模
被判定為一個(gè)chunk的所有原始字節(jié)embedding會(huì)聚合（池化/加權(quán)等方法），形成一個(gè)chunk級(jí)higher-level embedding，進(jìn)入主干網(wǎng)絡(luò)進(jìn)行高抽象推理，這快就不用講了，因?yàn)橐呀?jīng)進(jìn)transformer了
打個(gè)比方：
- 像是在讀句子的時(shí)候，你發(fā)現(xiàn)“這里信息切換了，和下文關(guān)聯(lián)對有區(qū)分了”就自動(dòng)切一刀，把前面的歸為一個(gè)高抽象信息塊。如果連續(xù)的內(nèi)容沒變化（比如單詞內(nèi)），就不分塊。
- 你給模型的任何輸入，不論語言、結(jié)構(gòu)、符號(hào)，只要數(shù)據(jù)里有“信息變化點(diǎn)”，就可能自動(dòng)形成chunk。
再舉極端對照例子
- "I love applepie"
普通tokenizer：["I", "love", "apple", "pie"]，這就分錯(cuò)了唄，分成了 apple and pie
H-Net：可能["I", "love", "applepie"] 或 ["I love", "applepie"]（因?yàn)?applepie"常一起出現(xiàn)），這兩個(gè)分都沒毛病 - 代碼場景："def run_fast(x):"
普通tokenizer：["def", "run", "_", "fast", "(", "x", ")", ":"]，這么分也比較扯了（當(dāng)然你們大多數(shù)看不見這么差的，是因?yàn)榇a量大，special token和輔助字符機(jī)制讓你們不止于碰到這么離譜的，我就是舉個(gè)例子）
H-Net：可能["def", "run_fast", "(", "x", "):"]，甚至整個(gè)函數(shù)名+參數(shù)合成chunk
所以，動(dòng)態(tài)分塊DC讓模型“自動(dòng)發(fā)現(xiàn)結(jié)構(gòu)”，而不是簡單、固定地分詞或分字，大大增強(qiáng)了理解、壓縮和表達(dá)的能力。
我們最后再做一下流程對比
總結(jié)一下就是其實(shí)就是encoder+dc做了tokenizer的事了，然后上采樣+decoder做了softmax到詞表的logit
這么一上圖就沒那么抽象了，至于主干那塊其實(shí)愿意用trasformer還是ssm，或者mamba甚至混著來（現(xiàn)在不都流行這樣嗎，隔一層一遍，確實(shí)能省掉一部分因?yàn)橹笖?shù)注意力造成的算力壓力），就看你想怎么折騰了
最后看一下效果：
A. 語言建模主任務(wù)（英文+多語言）
1. 驗(yàn)證困惑度/壓縮效率（BPB）
H-Net（動(dòng)態(tài)分塊）在相同訓(xùn)練數(shù)據(jù)和算力預(yù)算下
1-stage結(jié)構(gòu)已可匹配傳統(tǒng)BPE-Transformer的困惑度；
2-stage遞歸結(jié)構(gòu)大幅超越：
- H-Net (1-stage): BPB ≈ BPE Transformer
- H-Net (2-stage): BPB 顯著低于同算力BPE Transformer
- 訓(xùn)練曲線顯示，H-Net隨數(shù)據(jù)量增加，性能提升更快，最終收斂值更低（見下圖）。
2. 多語言與代碼/DNA建模
- H-Net對中文、代碼、DNA等特殊輸入類型展現(xiàn)強(qiáng)大優(yōu)勢，尤其是沒有自然token邊界的文本數(shù)據(jù)。
- 中文建模時(shí)，BPB顯著優(yōu)于Llama3/Transformer等多語支持模型。
- 代碼建模同理，chunk壓縮率更高，表現(xiàn)優(yōu)于詞表法。
- DNA建模 性能提升極大，數(shù)據(jù)效率比等參數(shù)Transformer高3.6倍（可用更少數(shù)據(jù)達(dá)到同樣困惑度）。
B. 下游通用任務(wù)表現(xiàn)
大規(guī)模zero-shot評(píng)測在LAMBADA、HellaSwag、PIQA、ARC-e、ARC-c、Winograd、OpenBook等七大benchmark任務(wù)上，H-Net（2-stage）平均分比傳統(tǒng)BPE Transformer高2%~3%
對比Mix-of-Experts（MoE） 、SpaceByte、LlamaByte等各種優(yōu)化方法，H-Net也依然表現(xiàn)勝出，這里吐槽作者為什么方MOE，不過頁能理解，雖然不是一個(gè)層面的，但是，也都是優(yōu)化手段，姑且理解為主干（FFN）稀疏vs壓縮冗余吧, 反正它敢比，我就敢把這個(gè)也粘過來了
C. 魯棒性和泛化能力
抗文本擾動(dòng)魯棒性：在HellaSwag的五種perturbation（如隨機(jī)大小寫、字符重復(fù)、丟drop、混亂語法）測試下，H-Net魯棒性-平均準(zhǔn)確度遠(yuǎn)超過BPE Transformer和所有對照組。
可解釋性更強(qiáng)：Chunk邊界分布可視化表明模型學(xué)出的邊界多能對應(yīng)詞/短語/語法塊，而不是簡單機(jī)械分詞。
圖片
D. 數(shù)據(jù)/計(jì)算效率
同樣訓(xùn)練數(shù)據(jù)和FLOPs下，H-Net能用更少數(shù)據(jù)、更少算力達(dá)到等同或更優(yōu)效果，尤其在"hardcase"領(lǐng)域（如代碼/DNA/多語種）差距巨大。
總之還成，我為什么講這個(gè)呢，因?yàn)楝F(xiàn)在大家都在反transformer架構(gòu)，但是也不能光喊口號(hào)，這個(gè)至少做出了一部分的關(guān)鍵工作（雖然tokenizer不屬于transformer，但是它也是現(xiàn)在網(wǎng)絡(luò)的基礎(chǔ)?。?，如果你把主干全換成ssm類的比如mamba，那就徹底告別現(xiàn)在的網(wǎng)絡(luò)了，不過我覺得從主流視角看，這類的工作至少還要5年，因?yàn)閠ransformer本身也都在外圍進(jìn)行線性化的優(yōu)化，而transformer非線性的部分的attention短期我沒看到能被取代的可能性。
本文轉(zhuǎn)載自?????熵減AI?????，作者：周博洋
