Onepage/ AI 文字盲區
蝦說 AI（小金老師）· YouTube
AI 會算微積分，為什麼卻會數錯 strawberry 有幾個 r？
這支影片用一個很小的題目切進大型語言模型的真問題：模型看起來懂文字，也能做高階推理，但它處理的往往不是我們眼中的單一字母，而是被切過、壓縮過、用機率延續的 token pattern。
Video ID: 8dlbozHN2GASource: 蝦說 AI（小金老師）
01 / 表面問題
答案其實很簡單
strawberry 裡有三個 r。人類只要逐字看過去就能得到答案，但模型可能先依賴語意、常見問答模式或 token 片段。
02 / 真正問題
模型不是天然逐字元運作
LLM 通常把文字轉成 token，再根據上下文預測下一段文字。字母計數要求精確位置與逐字元遍歷，這剛好不是它最自然的能力。
03 / 實務啟發
高階能力不保證低階可靠
會解釋概念、寫程式或做數學推理，不代表每個字元級、格式級、邊界條件任務都可靠。系統設計要把這些弱點顯式補上。
The test
先把題目攤開：strawberry 的 r 在哪裡？
strawberry
strawberry
3
正確答案是 3 個 r。重點不是這題難，而是它會逼模型做一件很不語意化的事：逐字元定位、計數，並避免被常見回答模式帶走。
Why it fails
這不是「AI 笨」，而是表徵方式不同
原因 1
Token 不是字母
模型看到的輸入通常先被 tokenizer 切成片段。這些片段可能是一整段、詞根、子詞或符號，不一定對齊人類眼中的每一個字母。
原因 2
語意推理和字元掃描是兩種任務
問「strawberry 是什麼」時，模型可以靠語意與世界知識回答；問「第幾個字母是 r」時，它需要像程式一樣處理索引與計數。
原因 3
自信語氣會遮住不確定性
LLM 會產生看起來流暢的回答。當任務需要精確驗證時，流暢度不是可靠度；答案像對，不等於真的經過可檢查的計算。
原因 4
提示語可以改善，但不能當成保證
要求模型「一步一步列出每個字母」通常會提升成功率，因為它把隱藏的逐字操作外顯化；但生產系統仍需要檢查器或工具來保證結果。
Signals
從這個小測試延伸出的四個工程訊號
Task type
字元級
凡是逐字、逐格、逐欄位、精準格式，都要視為高風險任務。
Failure mode
看似簡單
人類簡單不代表模型簡單；模型容易被訓練分布與 token 邊界影響。
Mitigation
外部工具
用程式計數、regex、parser 或 schema validator，比單靠 prompt 更穩。
Product risk
自信錯
最危險的不是不知道，而是用很自然的語氣給出錯誤細節。
Apply it
把 strawberry 測試放進產品設計，要改哪裡？
格式輸出要驗證JSON、CSV、發票欄位、地址、身份證字號、日期區間這類任務，應該由 parser 或 validator 接手最後檢查。
計數和比對交給工具字元數、關鍵字出現次數、列表項目數、差異比對，適合用 deterministic code 做，不要只要求模型更小心。
提示語要迫使中間步驟可見在沒有工具的情境，讓模型先列出字元、位置或表格，再給答案，通常比直接問最後答案穩定。
評測集要包含低階陷阱不要只測問答、摘要、推理。把字元級、邊界條件、格式遵循與例外資料納入 eval，才能抓到產品中的真失敗。
Checklist
遇到「AI 明明很聰明卻錯很基本」時，先檢查這五件事
這個任務是不是其實需要精確索引？只要牽涉字元位置、欄位順序、逐項比對，就不要把它當成一般語意理解。
模型的中間步驟是否可檢查？如果沒有列出每個字母、每一步計算或每個資料來源，錯誤很難被發現。
可否用一段程式直接解？能用程式確定的，就不要用機率模型猜。LLM 適合理解意圖，工具適合保證精度。
答案是否需要第二路徑驗證？高風險答案應該由另一個檢查器、規則或測試集驗證，而不是靠模型自我保證。
UI 是否讓使用者看見不確定性？如果系統可能在低階細節犯錯，介面要保留可追溯資料與修正入口，避免把錯誤包成權威結論。
Source video