咁樣就衍生咗兩個交織嘅問題:
首先,嵌入層並冇完全編碼字符級別嘅資訊。 研究顯示,LLM 嘅嵌入層只會為每個 Token 嘅 第一個字符 儲存強烈嘅字符資訊;喺第一個字符之後,字符級別嘅細節就會急速衰減 。當模型需要數 Token 入面嘅字母嗰陣,佢必須由一個本身就冇設計嚟保存呢啲資訊嘅表徵度,重新建構返個字符序列出嚟。之後嘅 Transformer 層會局部咁彌補呢個缺陷——研究人員觀察到一個明顯嘅「突破點」,模型會喺嗰個位成功將一個 Token 串返出嚟——但成個過程並唔可靠而且好脆弱
。
第二,子詞分詞器「對 Token 嘅內部結構幾乎係視而不見。」 一篇 2024 年嚟自 Arxiv 嘅研究,用咗 「分詞嘅詛咒」 呢個詞嚟形容呢個漏洞:分詞器天生就對打字錯誤、長度變化好敏感,而且睇唔到 Token 本身嘅內部構成 。一個詞語例如「journalism」好可能係一個單一 Token——模型從來冇學過要將佢分解成
j-o-u-r-n-a-l-i-s-m 呢啲字符級別嘅嘢,所以當你要佢串出嚟嗰陣,佢就只係靠估。
如果問題出喺分詞上,咁最直覺嘅解決方法就係用字符級別(character-level)或者字節級別(byte-level)嘅模型,等個模型可以睇到每一個字母。呢種方法係存在嘅——好似 ByT5 呢類模型就直接喺原始字節上運行——但佢冇俾人廣泛採用,因為咁樣會令模型嘅運行成本貴得好誇張 。
轉用純字符級別處理,會令到序列長度估計增加 3 到 5 倍,按比例咁增加運算成本,同時令模型更難學到長距離嘅依賴關係同語義關聯 。子詞分詞器係令現代 LLM 變得可行嘅效率妥協方案:佢哋將文字壓縮成可管理嘅詞彙量,同時保留足夠嘅語義令到語言生成可以流暢進行。
研究人員普遍同意,一個「完美」嘅分詞器好可能根本唔存在 。分詞器「經常產生非唯一嘅編碼」,並創造出「表徵不匹配」嘅問題,呢個係一個深層嘅結構性問題——而唔係一個簡單可以修補嘅 bug
。喺字符級精確度同語義流暢度之間做取捨,似乎係 Transformer 架構嘅一個根本性難題。
呢啲拼字失敗暴露出幾個結構性嘅限制,而呢啲限制遠遠唔止影響 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 咁有價值嘅核心能力。
Comments
0 comments