像「Google」這個字,可能會被編碼成一個Token ["Google"],或者兩個Token ["Go", "ogle"]["G", "o", "o", "g", "l", "e"]
這會衍生出兩個雪上加霜的問題:
第一,模型的嵌入層沒有完整編碼字母層級的資訊。 研究表明,大型語言模型的嵌入層,僅對每個Token的第一個字符儲存了較強的字元資訊;超出第一個字符後,字母層級的細節就會急遽衰減 。當模型需要去數一個Token裡有幾個字母時,它必須從一個原先就沒打算保留字母順序的向量表徵中,重新建構出字母序列。雖然後續的Transformer層能部分補救——研究人員觀察到模型在拼出一個Token時,會出現明顯的「突破點」——但這過程本身就極不可靠且脆弱
。
第二,子詞級別的分詞器「基本上對Token的內部結構視若無睹」。 一份2024年發布於Arxiv的研究,將這種脆弱性命名為**「分詞化的魔咒(The Curse of Tokenization)」**:分詞器天生就對錯字、長度變化很敏感,卻對Token本身的內部組成渾然不覺 。像「journalism」這樣一個完整的字,很可能就是一個Token——模型從未學過如何在字母層級將其拆解成「j-o-u-r-n-a-l-i-s-m」,因此當被要求拼出來時,它只能憑印象瞎猜。
如果問題出在分詞化,那最直覺的解法,就是改用「字母層級」或「位元組層級」的模型,讓模型能看見每一個字母。這個做法確實存在,像ByT5這類模型就是直接在原始位元組上運算,但它之所以不被廣泛採用,是因為這麼做會讓模型的執行成本巨幅提升 。
改採純字母層級的處理方式,會讓運算中的文字序列長度暴增約三到五倍,這不光代表運算成本會等比例飆升,也讓模型更難以學習到長距離的上下文與語義關係 。可以說,子詞級別的分詞化,正是讓現代大型語言模型得以實用化的「效率妥協方案」:它能將文字壓縮進一個可管理的詞彙量大小,同時保留足夠的意思來生成流暢的語言。
研究人員普遍認為,「完美」的分詞器很可能並不存在 。分詞器「經常會產生非唯一的編碼」,造成的「表徵不匹配」是深度嵌入架構本身的問題,並非簡單修補就能解決的臭蟲
。對Transformer架構來說,在字母級精準度與語義流暢度之間的取捨,似乎是一件魚與熊掌難以兼得的事。
這些看似愚蠢的拼字錯誤,其實曝露了AI Overview乃至整個大型語言模型技術,好幾項結構性的限制。
LLM是圖形辨識與機率預測機,而非符號操作機。 對於任何跑傳統程式碼的電腦來說,計算字母數量只是個微不足道的演算法任務,但大型語言模型並不執行演算法——它們是根據訓練資料中的統計規律,去預測下一個最有可能出現的Token 。當被問到有幾個字母時,模型只是從學到的關聯性中,生成一個聽起來很合理的答案,而非真的在進行計算。
自信程度與正確性完全脫鉤。 AI可以語法完美、語氣篤定地回答出「兩個」,但客觀上就是錯的。這正是LLM「幻覺」的經典特徵:生成一個聽似合理、充滿自信,卻毫無查證機制的產出。Google自己在2024年也承認,儘管AI Overview「被設計為只會顯示有頂尖網頁結果支撐的資訊」,但它們仍可能誤解查詢問句或語言的細微差異 。
這個盲點是架構性的,而非偶然。 所有使用子詞分詞化的主流大型語言模型,包含OpenAI、Anthropic和Meta的模型,在處理像是倒著拼出單字、數算特定字母數量或解構字謎時,都展現出類似的弱點 。將模型規模擴大能稍微緩解,但這個偏誤始終存在
。
一個連自己公司名字都不會拼的AI,看起來似乎很丟臉,但業界並不把它視為危機,因為大型語言模型的巨大價值,展現在完全不同的地方。
流暢的文字生成、摘要、推理、翻譯、程式碼撰寫——所有這些強項,都來自模型在語義層次的運作能力,在這個層次上,Token級別的抽象化是「功能」而非「缺陷」。字母級的精確性,壓根就不是這些架構設計時要最佳化的目標。
實務上的修補之道,是將拼字和計數類的查詢,引導至外部傳統的「規則導向軟體」來處理,而不是要求LLM自己做。多個AI Overview的實作版本,已經嘗試在偵測到此類問題時進行轉發,但從2026年5月鬧出的這起事件來看,就連偵測機制本身也還不夠完備 。一份獨立研究更發現,Google的AI Overview在要求它倒著拼出單字時,有52%的機率會答錯,而當單字音節達三個以上時,拼對的機率更只剩下10%
。
Google正在為這次公開的計數問題開發修復方案 。但對任何理解這項分詞化取捨的人來說,真正的教訓並非「Google推出了一個有缺陷的產品」,而是驅動這波人工智慧革命的核心架構,天生就存在一個根本的盲點——而且到目前為止,沒有人能找到在不犧牲LLM最核心價值的前提下,根治這個問題的方法。
Comments
0 comments