編輯｜Panda

AI 很有用，但也有黑歷史，還不少，比如就是算不準 Strawberry 中有多少個 r、知道馬嘉祺卻說不出他的名字以及還在持續困擾用戶的 AI 幻覺問題。

今天，又有新的問題出現了，這一次是谷歌搜索。

有用戶發現，近日升級了 AI 能力的谷歌搜索在面對「google 里面有幾個 P」這樣的簡單問題時竟然失敗了！

這件事引發廣泛關注和測試熱潮。我們也簡單試了下，就算用漢語提問，谷歌搜索同樣錯誤，而且還自行加戲，導致錯上加錯 —— 說 Pixel 里面有兩個 P。

事實上，還不只是 google 這個詞，谷歌搜索在面對很多其它詞時也會出現類似的字母計數和拼寫問題：

甚至純漢語的提問也可能遭遇這樣的問題：

那么，為什么會出現這樣的問題呢？

谷歌把搜索引擎 AI 化了

要理解這次的問題，得先知道谷歌最近做了什么。

今年 5 月的 Google I/O 2026 大會上，谷歌宣布了一次被稱為「搜索框 25 年來最大升級」的搜索改版。新版谷歌搜索以重新設計的「智能搜索框」為核心，將 AI Overview 與 AI Mode 整合為統一的搜索流程：用戶提問后，AI 直接生成答案并支持追問，傳統鏈接依然保留，但不再是交互的主角。

谷歌搜索負責人 Liz Reid 將其定性為「過去 25 年來搜索框最大的一次升級」。這是谷歌在 OpenAI、Perplexity 等 AI 搜索競爭者的壓力下，做出的一次全面押注。

問題也隨之而來。數周前，就有用戶發現，在谷歌搜索框里輸入「disregard（無視）」這個詞，AI 不是給出詞典解釋，而是把這個詞當成了指令，回答說：「好的，我已忽略你之前的消息，有什么新問題請告訴我。」谷歌很快修復了這個 bug。

但拼寫錯誤的問題，目前依然存在。

TechCrunch 咨詢了谷歌相關人士，得到了一個相當坦誠的回應：「在詞內部數字母一直是大語言模型的已知難題，我們正在修復這個特定問題。」

真正的原因：AI 其實「看」不見字母

谷歌的回應點出了核心：這不是谷歌一家的問題，而是當前所有 LLM 共同面臨的結構性缺陷。

想理解為什么 AI 數不清字母，得先理解 AI 是怎么「讀字」的。

我們人類讀一個詞，是按字母一個一個掃過去的：G-O-O-G-L-E，六個字母。這個過程天然包含了對字符的感知。

但 LLM 不是這樣工作的。它處理文字的基本單位不是字母，而是token—— 可以理解為一種更粗粒度的「語言碎片」。一個 token 可能是一個完整的單詞，也可能是半個單詞，甚至可能是幾個詞的組合。

以 OpenAI 的分詞器為例，「Strawberry」這個詞會被切成三個 token：「Str」「aw」「berry」。對 AI 來說，它接收到的不是 11 個字母，而是 3 個抽象的語言單元。你讓它數里面有幾個「r」，它必須先「還原」這些 token 里隱藏的字母信息，這一步沒有被明確訓練過，所以它往往做不好。

「Google」這個詞同樣如此。在常見的分詞方案下，它極有可能被當成一個 token 整體處理，其中的字母組合信息已經被「壓縮」進了一個抽象編號。問 AI 里面有幾個 P，相當于問一個只背過單詞音節的人，那個詞里有沒有某個字母 —— 他未必知道。

馬里蘭大學 AI 研究員 Matthew Guzdial 解釋說：「當模型看到 the 這個詞時，它拿到的是 the 的整體編碼，它并不知道里面有 T、H、E。」

LLM 處理的是語言的「意思」，而非文字的「形狀」。拼寫恰恰屬于后者。

老問題了

「Strawberry 里有幾個 r」這道題，早在大模型興起之初就成了一個測試 AI 的經典梗。幾乎所有主流模型，在不加特別提示的情況下，都會答錯。

剛剛加入 Anthropic 的 Andrej Karpathy 曾專門寫過一個小程序，用 emoji 來可視化 token 的切分方式，讓普通人直觀感受到「AI 眼中的文字」是什么樣的。當你看到「How many letters 'r' in the word'strawberry'?」在模型視角里變成一串被隨機切開的色塊，就能明白為什么它數不清了。

有意思的是，這個問題并非無解。如果你在提問時加上「請逐步思考」或「請先把每個字母列出來」，模型通常能答對。這說明它具備推理所需的基礎信息，只是在沒有被要求「認真想」的情況下，會直接給出一個「快速直覺答案」，而這個答案往往是錯的。

這種現象和心理學里的「系統一 / 系統二」思維模式頗為相似：人類平時也依賴快速直覺（系統一），只有在被要求時才切換到深思熟慮（系統二）。大模型的默認模式，也是「能省則省」。

Karpathy 給這種 AI 能力分布不均的現象起了個名字：Jagged Intelligence（參差不齊的智能）。一個能在數學奧林匹克競賽中拿銀牌的模型，可能數不清一個單詞里有幾個字母；一個能寫出流暢代碼的 AI，可能判斷不了兩個圓是否重疊。這種反直覺的能力分布，是當前大模型的普遍特征，而非個別缺陷。

更多詳情，可參閱機器之心報道《為什么 AI 數不清 Strawberry 里有幾個 r？Karpathy：我用表情包給你解釋一下》。

為什么這次在谷歌身上特別扎眼？

同樣的底層問題，為什么偏偏在谷歌搜索這里引發了更大的討論？

原因很簡單：場景變了，預期就變了。

在 ChatGPT 或其他 AI 聊天工具里，用戶多少有心理預期：這是個 AI，它可能犯錯，偶爾答錯數字母也情有可原。但谷歌搜索不同。幾十年來，它是很多人獲取準確信息的默認入口，是「有問必答」的代名詞。

當谷歌把 AI 直接嵌入搜索結果頁面，并以權威口吻給出「答案」（而非鏈接），用戶的容錯預期就大幅降低了。一旦答錯，觀感會比同樣的錯誤發生在獨立 AI 產品上嚴重得多。

更何況，這次翻車的詞不是什么生僻名詞，而是「Google」本身。這在傳播上的效果，可以說是被完美拿捏了。

事實上，這已經不是 Google AI Overviews 第一次出現離譜錯誤。2024 年功能剛上線時，它曾將 Reddit 玩笑帖和諷刺內容誤當成可靠信息來源，甚至建議用戶在披薩里加入膠水、或「每天吃一塊小石頭」。盡管谷歌隨后進行了多輪修復，但近期再次出現把普通詞匯誤識別為系統指令的問題，也說明大模型在信息檢索、上下文理解與指令邊界識別上，仍存在較深層的系統性缺陷。

能治嗎？

從技術角度看，答案是：難，但有方向，也有代價。

Northeastern 大學研究 LLM 可解釋性的博士生 Sheridan Feucht 認為，「token 的邊界本身就是模糊的，不可能存在一個完美的分詞方案」。這句話點出了問題的核心：如果要從根本上解決字母感知的缺陷，方向之一是拋棄現有的分詞機制，改用更細粒度的方式處理文字。

舉個例子，Meta AI 研究團隊在 2024 年底發布了一種名為Byte Latent Transformer（BLT）的新架構，直接繞過分詞器，讓模型從最底層的「字節」開始處理文字 —— 相當于讓 AI 真正逐字符「讀」一段話，而非靠抽象的語言碎片拼湊語義。在字符級任務的測試中，BLT 的表現遠超基于分詞的傳統模型，在拼寫類任務上接近滿分，而 LLaMA 3 在同類測試里幾乎全軍覆沒。

BLT 由三個模塊組成：一個輕量級 Local Encoder，用于將輸入字節編碼為分塊表示；一個計算開銷較大的 Latent Transformer，用于處理分塊表示；以及一個輕量級 Local Decoder，用于解碼下一個字節分塊。BLT 融合了字節 n-gram 嵌入和交叉注意力機制，以最大化潛在變換器與字節級模塊之間的信息流動。與固定詞表的分詞方法不同，BLT 將字節動態分組為分塊，從而保留對字節級信息的訪問。arXiv: 2412.09871

但這個方案的代價是顯而易見的。拋棄分詞，意味著序列長度急劇增加。一句話原本被壓縮成幾十個 token，換成逐字節處理后，序列長度會膨脹數倍乃至十倍。Transformer 的注意力機制計算量隨序列長度呈二次方增長 —— 也就是說，序列翻倍，計算量可能翻四倍。這在訓練規模上的代價，是任何大型商業模型都需要認真權衡的。

Meta 的 BLT 通過一種「動態分組」策略緩解了這個問題：對于內容可預測、信息密度低的文字片段，模型會自動合并處理，減少無謂的計算；只在遇到復雜、高熵的語言片段時才精細處理。在同等推理成本下，BLT 的擴展效率甚至優于傳統 token 模型。但這套架構目前最大的實驗規模是 80 億參數，距離谷歌、OpenAI 等公司動輒數千億參數的生產級模型，還有相當距離。從零開始用新架構重新訓練一個能支撐搜索引擎的大模型，成本可能是數億乃至數十億美元量級的事情。

另一個代價更低的方向，是讓模型「知道自己不擅長什么」。Karpathy 將其稱為「認知自我知識（cognitive self-knowledge）」—— 如果模型能識別出「數字母」是自己的薄弱項，就可以在遇到此類問題時自動調用外部工具（如代碼解釋器、計算器、搜索）來輔助，而不是直接憑直覺給出錯誤答案。

舉個例子，針對經典的「strawberry 中有多少個 r」的問題，谷歌搜索會檢索網絡后給出答案，而非讓 AI 自己計數（結果中的鏈接符號）。

Meta 在 Llama 3 的訓練中，就專門針對「讓模型只回答它知道的問題」做了系統性工程：通過知識探測技術，篩選出模型在多次采樣中都能正確作答的問題生成訓練數據；對那些模型反復答錯的問題，則訓練其學會拒絕回答，而非自信地給出錯誤結論。

相比重建架構，這類訓練層面的修補成本要低得多，但它治的是癥狀不是病根。

當然，補丁式的修復也在同步進行。從谷歌的表態來看，他們正在專門針對「詞內字母計數」做優化。只是這類根植于架構的問題，修復周期往往比用戶期待的要長得多，還涉及到成本問題。

https://techcrunch.com/2026/05/27/why-googles-ai-cant-spell-google-or-anything-else/

https://www.bbc.com/news/articles/cd11gzejgz4o