覆蓋率數字背後的舊問題
Google 在 2026 年 9 月 15 日發布〈AI for everyone in every language〉，開頭給的數字是：旗下技術與產品支援超過 300 種語言、涵蓋 70 億以上人口，約占全球 86%。同一篇文章也承認另一半事實——數十年來科技只對少數強勢語言友善，數千種仍在使用的語言與方言在數位世界裡幾乎不存在。
對產品團隊來說，這不是道德呼籲，而是規格問題。當你的服務只在一種語言裡「表現正常」，你在其他語言市場賣的其實是半成品。
從轉錄文字到直接處理音訊
Google 描述了一個管線轉向：過去語音辨識是「音訊轉文字、處理文字、再合成回音訊」，這條路會把語氣、節奏、情緒與情境濾掉。他們現在訓練 Gemini 直接處理音訊，同時理解聲音與意圖。
文章列出的具體能力包括：Gemini 3.5 Live Translate 支援 70 種語言的即時口語翻譯、2,000 多個語言配對，並能處理語碼轉換與情緒線索；Gemini 3.5 Transcribe 則被描述為目前最精確的語音轉文字模型，能在吵雜環境或專業術語情境下輸出整理過的文字，也用於 Android Gboard 的 Rambler 功能。
這裡的產品含義很直接：如果你的語音功能仍以「先轉成文字再處理」為預設架構，你會在口音、混語與情緒判斷上持續吃虧。這類取捨和工具呼叫迴圈的停損設計一樣，屬於架構層的決定，而不是事後調參——可參考本部落格先前談 工具呼叫迴圈的四個停損點 的討論方式。
資料從哪裡來，決定模型在哪裡能用
文章把資料來源寫得很清楚：因為網路內容過度偏向少數語言，Google 改用在地草根合作。三個例子是 WAXAL（27 種撒哈拉以南非洲語言、超過 1 億人使用）、與印度科學理工學院及 Bhashini 合作的 Project Vaani（已蒐集超過 30,000 小時語音、109 種語言、15.5 萬名以上說話者），以及 Amplify Initiative（1,600 多名在地專家、20 所大學、15,000 筆多模態資料）。
另外，Universal Speech Model 以 1,200 萬小時音訊訓練，透過跨語言遷移學習，把資料豐富語言學到的模式套用到資源稀缺語言。
對要選模型的團隊，這代表「支援某語言」不是勾選項，而是要問：這個語言的訓練資料是誰收的、覆蓋哪種腔調、有沒有涵蓋混語情境。
離線與低階裝置不是附註
文章提到超過 30 億人仍缺乏穩定網路，因此推出 TranslateGemma：以 Gemini 為基礎、涵蓋 55 種語言的輕量開源翻譯模型，可在裝置端執行，不需要連雲端。另一端則是 feature phone 使用者——Google 支持 Viamo 的「Ask Viamo Anything」，用語音 AI 助理把 Gemini 帶到一般功能手機上，並稱該服務已在盧安達試行、用 Gemini 回答超過 200 萬個問題。
這兩件事放在一起看，等於承認多語市場的硬體與連線條件差異極大。若你的產品假設使用者一定有穩定網路與中高階手機，你在這些市場的可用性會被基礎設施直接封頂。
無障礙與地名發音：容易被忽略的驗收項
文章也談到非標準語音與手語。Sign Language-to-Text 以 50 多種手語訓練，在 Pixel 11 的 Gboard 與 Live Transcribe 上提供手語轉文字聽寫，先從美國手語（ASL）對英文開始，目標族群是全球約 7,000 萬名以手語溝通的人。
另一個例子是地名發音：Google 與紐西蘭的毛利語專家合作，改善 Google Maps 的地名讀音，並把文化上正確的發音納入文字轉語音模型。
這些細節通常不會出現在產品規格書第一頁，卻是最容易被使用者察覺的品質落差。
對產品團隊的實際下一步
文章最後說，語言技術已嵌入 Search、Android、Chrome、YouTube、Google Play 等九個平台、連結超過 50 億人，但規模只是部分故事，重點是深度與文化脈絡。
務實的做法是：在語言支援清單上，除了「有沒有」，再加上三欄——是否原生處理音訊、是否能在離線或低階裝置運作、資料來源是否涵蓋在地腔調與混語。這三欄會直接影響你的評測設計與上線範圍。至於 Google 各項功能的實際品質與地區可用性，仍要看各地區的產品公告與實測，這篇文章提供的是方向與資料來源，不是逐項驗收結果。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。