呢啲並唔係隨機嘅 bug。呢個係每一個主流大型語言模型處理文字時，一個可以預見嘅後果——亦揭示咗一個短期內冇咁快可以修補到嘅盲點。

Tokenization 嘅問題：點解 LLM 唔係逐個字母閱讀

人類會將詞語理解為一連串獨立嘅字母。但 LLM 做嘅嘢完全唔同：佢將文字拆成 Token——呢啲 Token 可能係完整嘅詞語、子詞詞塊，或者偶爾係單個字符，具體取決於一個由類似「字節對編碼」（BPE）呢類演算法建立嘅預定義詞彙表 。

詞語「Google」可能會被編碼成單一 Token ["Google"]，或者兩個 Token 例如 ["Go", "ogle"]，視乎個分詞器嘅詞彙表而定。但佢永遠唔會俾編碼成 ["G", "o", "o", "g", "l", "e"]——模型根本冇一個原生嘅方式去理解 Token 入面嘅個別字母。

咁樣就衍生咗兩個交織嘅問題：

首先，嵌入層並冇完全編碼字符級別嘅資訊。 研究顯示，LLM 嘅嵌入層只會為每個 Token 嘅 第一個字符 儲存強烈嘅字符資訊；喺第一個字符之後，字符級別嘅細節就會急速衰減 。當模型需要數 Token 入面嘅字母嗰陣，佢必須由一個本身就冇設計嚟保存呢啲資訊嘅表徵度，重新建構返個字符序列出嚟。之後嘅 Transformer 層會局部咁彌補呢個缺陷——研究人員觀察到一個明顯嘅「突破點」，模型會喺嗰個位成功將一個 Token 串返出嚟——但成個過程並唔可靠而且好脆弱 。

第二，子詞分詞器「對 Token 嘅內部結構幾乎係視而不見。」 一篇 2024 年嚟自 Arxiv 嘅研究，用咗 「分詞嘅詛咒」 呢個詞嚟形容呢個漏洞：分詞器天生就對打字錯誤、長度變化好敏感，而且睇唔到 Token 本身嘅內部構成 。一個詞語例如「journalism」好可能係一個單一 Token——模型從來冇學過要將佢分解成 j-o-u-r-n-a-l-i-s-m 呢啲字符級別嘅嘢，所以當你要佢串出嚟嗰陣，佢就只係靠估。

結果就係大家喺 Google AI Overview 見到咁樣：一個連哲學都可以辯論、識寫 Code 嘅 AI，竟然好有信心咁話「Google」有兩個「p」，而「poop」入面啱啱好有一個「r」。

點解解決呢個問題難過想像中咁多

如果問題出喺分詞上，咁最直覺嘅解決方法就係用字符級別（character-level）或者字節級別（byte-level）嘅模型，等個模型可以睇到每一個字母。呢種方法係存在嘅——好似 ByT5 呢類模型就直接喺原始字節上運行——但佢冇俾人廣泛採用，因為咁樣會令模型嘅運行成本貴得好誇張 。

轉用純字符級別處理，會令到序列長度估計增加 3 到 5 倍，按比例咁增加運算成本，同時令模型更難學到長距離嘅依賴關係同語義關聯 。子詞分詞器係令現代 LLM 變得可行嘅效率妥協方案：佢哋將文字壓縮成可管理嘅詞彙量，同時保留足夠嘅語義令到語言生成可以流暢進行。

研究人員普遍同意，一個「完美」嘅分詞器好可能根本唔存在 。分詞器「經常產生非唯一嘅編碼」，並創造出「表徵不匹配」嘅問題，呢個係一個深層嘅結構性問題——而唔係一個簡單可以修補嘅 bug 。喺字符級精確度同語義流暢度之間做取捨，似乎係 Transformer 架構嘅一個根本性難題。

呢啲錯誤揭示咗 LLM 嘅咩本質

呢啲拼字失敗暴露出幾個結構性嘅限制，而呢啲限制遠遠唔止影響 Google 嘅 AI Overview。

LLM 係模式配對器，而唔係符號操作器。 對於任何行緊傳統代碼嘅電腦嚟講，數字母係一個好簡單嘅演算法任務，但 LLM 唔係執行演算法——佢係根據訓練數據入面嘅統計模式，去預測下一個最有可能出現嘅 Token 。當你問佢字母數量嗰陣，個模型係從學到嘅關聯度，生成一個聽落好有可能嘅答案，而唔係執行一個計數操作。

信心同正確性係冇關係嘅。 AI 可以語法完全流暢咁回答「兩個」，但客觀上係錯嘅。呢個係 LLM 「幻覺」嘅標誌性特徵：佢會輸出有信心、聽落好合理嘅內容，但冇內置嘅驗證機制。Google 自己喺 2024 年都承認，雖然 AI Overview 「為咗淨係顯示有頂級網絡結果支持嘅資訊而設」，但佢哋仍然可以誤解查詢或者語言上嘅細微差別 。

呢個盲點係結構性嘅，而唔係偶然嘅。 每一個用子詞分詞嘅主流 LLM——包括 OpenAI、Anthropic 同 Meta 嘅模型——喺字符級別嘅任務上都表現出類似嘅弱點，例如倒轉串字、數字母，或者處理回文構詞 。將模型規模擴大會有啲幫助，但呢種偏見仍然持續存在 。

點解業界唔當呢個問題係緊急事態

一個連自己公司名都串唔到嘅 AI，呢啲失敗睇落可能好尷尬——但業界並冇將佢哋視為危機，因為 LLM 嘅巨大價值喺另一度。

流暢嘅文字生成、摘要、推理、翻譯、代碼生成——呢啲所有能力都嚟自模型喺 語義 層面工作嘅能力，喺嗰個層面，Token 級別嘅抽象係一個功能，而唔係一個錯誤 。字符級別嘅精確度，根本唔係呢啲架構設計嗰陣要去最佳化嘅目標。

務實嘅解決方法係將拼字同計數查詢，路由返去畀傳統嘅基於規則嘅軟件處理，而唔係叫 LLM 去處理。幾個 AI Overview 嘅實作已經嘗試檢測並延遲處理呢類查詢，不過 2026 年 5 月呢啲咁高曝光率嘅錯誤，證明咗檢測本身仍然唔完善 。一項獨立研究發現，Google 嘅 AI Overview 對於倒轉串字嘅查詢，有成 52% 嘅時間係答錯嘅——而對於有三個或以上音節嘅詞語，得 10% 係成功倒轉串返啱 。

Google 正努力為呢啲俾人公開咗嘅特定計數問題做修正 。但對任何明白分詞取捨嘅人嚟講，真正嘅教訓並唔係 Google 推出咗一個有 bug 嘅產品。而係，驅動呢場 AI 革命嘅架構，本身就有一個根本嘅盲點——而且到目前為止，冇人搵到一個方法可以修補呢個盲點，同時又唔犧牲令 LLM 咁有價值嘅核心能力。

呢啲並唔係隨機嘅 bug。呢個係每一個主流大型語言模型處理文字時，一個可以預見嘅後果——亦揭示咗一個短期內冇咁快可以修補到嘅盲點。

Tokenization 嘅問題：點解 LLM 唔係逐個字母閱讀

人類會將詞語理解為一連串獨立嘅字母。但 LLM 做嘅嘢完全唔同：佢將文字拆成 Token——呢啲 Token 可能係完整嘅詞語、子詞詞塊，或者偶爾係單個字符，具體取決於一個由類似「字節對編碼」（BPE）呢類演算法建立嘅預定義詞彙表 。

詞語「Google」可能會被編碼成單一 Token ["Google"]，或者兩個 Token 例如 ["Go", "ogle"]，視乎個分詞器嘅詞彙表而定。但佢永遠唔會俾編碼成 ["G", "o", "o", "g", "l", "e"]——模型根本冇一個原生嘅方式去理解 Token 入面嘅個別字母。

咁樣就衍生咗兩個交織嘅問題：

首先，嵌入層並冇完全編碼字符級別嘅資訊。 研究顯示，LLM 嘅嵌入層只會為每個 Token 嘅 第一個字符 儲存強烈嘅字符資訊；喺第一個字符之後，字符級別嘅細節就會急速衰減 。當模型需要數 Token 入面嘅字母嗰陣，佢必須由一個本身就冇設計嚟保存呢啲資訊嘅表徵度，重新建構返個字符序列出嚟。之後嘅 Transformer 層會局部咁彌補呢個缺陷——研究人員觀察到一個明顯嘅「突破點」，模型會喺嗰個位成功將一個 Token 串返出嚟——但成個過程並唔可靠而且好脆弱 。

第二，子詞分詞器「對 Token 嘅內部結構幾乎係視而不見。」 一篇 2024 年嚟自 Arxiv 嘅研究，用咗 「分詞嘅詛咒」 呢個詞嚟形容呢個漏洞：分詞器天生就對打字錯誤、長度變化好敏感，而且睇唔到 Token 本身嘅內部構成 。一個詞語例如「journalism」好可能係一個單一 Token——模型從來冇學過要將佢分解成 j-o-u-r-n-a-l-i-s-m 呢啲字符級別嘅嘢，所以當你要佢串出嚟嗰陣，佢就只係靠估。

結果就係大家喺 Google AI Overview 見到咁樣：一個連哲學都可以辯論、識寫 Code 嘅 AI，竟然好有信心咁話「Google」有兩個「p」，而「poop」入面啱啱好有一個「r」。

點解解決呢個問題難過想像中咁多

如果問題出喺分詞上，咁最直覺嘅解決方法就係用字符級別（character-level）或者字節級別（byte-level）嘅模型，等個模型可以睇到每一個字母。呢種方法係存在嘅——好似 ByT5 呢類模型就直接喺原始字節上運行——但佢冇俾人廣泛採用，因為咁樣會令模型嘅運行成本貴得好誇張 。

轉用純字符級別處理，會令到序列長度估計增加 3 到 5 倍，按比例咁增加運算成本，同時令模型更難學到長距離嘅依賴關係同語義關聯 。子詞分詞器係令現代 LLM 變得可行嘅效率妥協方案：佢哋將文字壓縮成可管理嘅詞彙量，同時保留足夠嘅語義令到語言生成可以流暢進行。

研究人員普遍同意，一個「完美」嘅分詞器好可能根本唔存在 。分詞器「經常產生非唯一嘅編碼」，並創造出「表徵不匹配」嘅問題，呢個係一個深層嘅結構性問題——而唔係一個簡單可以修補嘅 bug 。喺字符級精確度同語義流暢度之間做取捨，似乎係 Transformer 架構嘅一個根本性難題。

呢啲錯誤揭示咗 LLM 嘅咩本質

呢啲拼字失敗暴露出幾個結構性嘅限制，而呢啲限制遠遠唔止影響 Google 嘅 AI Overview。

LLM 係模式配對器，而唔係符號操作器。 對於任何行緊傳統代碼嘅電腦嚟講，數字母係一個好簡單嘅演算法任務，但 LLM 唔係執行演算法——佢係根據訓練數據入面嘅統計模式，去預測下一個最有可能出現嘅 Token 。當你問佢字母數量嗰陣，個模型係從學到嘅關聯度，生成一個聽落好有可能嘅答案，而唔係執行一個計數操作。

信心同正確性係冇關係嘅。 AI 可以語法完全流暢咁回答「兩個」，但客觀上係錯嘅。呢個係 LLM 「幻覺」嘅標誌性特徵：佢會輸出有信心、聽落好合理嘅內容，但冇內置嘅驗證機制。Google 自己喺 2024 年都承認，雖然 AI Overview 「為咗淨係顯示有頂級網絡結果支持嘅資訊而設」，但佢哋仍然可以誤解查詢或者語言上嘅細微差別 。

呢個盲點係結構性嘅，而唔係偶然嘅。 每一個用子詞分詞嘅主流 LLM——包括 OpenAI、Anthropic 同 Meta 嘅模型——喺字符級別嘅任務上都表現出類似嘅弱點，例如倒轉串字、數字母，或者處理回文構詞 。將模型規模擴大會有啲幫助，但呢種偏見仍然持續存在 。

點解業界唔當呢個問題係緊急事態

一個連自己公司名都串唔到嘅 AI，呢啲失敗睇落可能好尷尬——但業界並冇將佢哋視為危機，因為 LLM 嘅巨大價值喺另一度。

流暢嘅文字生成、摘要、推理、翻譯、代碼生成——呢啲所有能力都嚟自模型喺 語義 層面工作嘅能力，喺嗰個層面，Token 級別嘅抽象係一個功能，而唔係一個錯誤 。字符級別嘅精確度，根本唔係呢啲架構設計嗰陣要去最佳化嘅目標。

務實嘅解決方法係將拼字同計數查詢，路由返去畀傳統嘅基於規則嘅軟件處理，而唔係叫 LLM 去處理。幾個 AI Overview 嘅實作已經嘗試檢測並延遲處理呢類查詢，不過 2026 年 5 月呢啲咁高曝光率嘅錯誤，證明咗檢測本身仍然唔完善 。一項獨立研究發現，Google 嘅 AI Overview 對於倒轉串字嘅查詢，有成 52% 嘅時間係答錯嘅——而對於有三個或以上音節嘅詞語，得 10% 係成功倒轉串返啱 。

Google 正努力為呢啲俾人公開咗嘅特定計數問題做修正 。但對任何明白分詞取捨嘅人嚟講，真正嘅教訓並唔係 Google 推出咗一個有 bug 嘅產品。而係，驅動呢場 AI 革命嘅架構，本身就有一個根本嘅盲點——而且到目前為止，冇人搵到一個方法可以修補呢個盲點，同時又唔犧牲令 LLM 咁有價值嘅核心能力。