Google 推出 Gemini 3.5 Transcribe 預覽版,語音轉文字支援 85 種以上語言
2026年8月29日
Google 在 2026 年 8 月釋出專門的語音轉文字模型 Gemini 3.5 Transcribe,公開預覽中,分成檔案處理與即時串流兩個端點,支援語者分離、字詞級時間戳與自訂詞彙。對做會議記錄、字幕與語音應用的開發者,這是值得評估的新選項。
禮拜三下午三點,內湖一間新創的工程師剛開完跨國會議,回到座位第一件事是把錄音檔丟進轉錄服務。中英夾雜的兩小時會議,出來的逐字稿把「這個 sprint 的 blocker」變成一串莫名其妙的中文詞,講者也全部混在一起分不出誰是誰。他嘆了口氣,開始手動修。
這個場景大概是所有台灣科技團隊的共同記憶。而 Google 在八月釋出的新模型,剛好衝著這幾個痛點來。
事件背景
Google 在 2026 年 8 月於 Gemini API 推出專門的語音轉文字模型 Gemini 3.5 Transcribe,目前為公開預覽(public preview)狀態。
值得注意的是它的產品設計:這不是把通用的 Gemini 模型加個語音輸入,而是拆成兩個專門的端點。gemini-3.5-transcribe 負責處理預錄好的音檔,走 Interactions API;gemini-3.5-transcribe-live 負責雙向即時串流,走 Live API。前者適合會議錄音、Podcast、影片字幕這類批次工作,後者適合即時字幕、語音助理、客服系統。
依官方文件,模型支援 85 種以上語言,並附有 BCP-47 語言代碼對照。
本次重點
- 語者分離(speaker diarization):最多支援 8 位講者,但官方註明 3 位以上的歸屬判定仍屬實驗性質。
- 字詞級時間戳:僅檔案處理端點支援,且官方明說開啟後會使準確度下降。做字幕對時的人要注意這個取捨。
- 語言自動偵測與語碼轉換:以語句為單位偵測語言,支援同一段音訊中的多語言切換——這對中英夾雜的台灣會議情境很關鍵。
- 自訂詞彙偏誤(custom vocabulary biasing):最多可提供 1,000 個詞,但官方建議約 100 個效果最好。這是餵公司內部術語、產品名、人名的地方。
- 智慧轉錄:可移除口頭禪與填充詞(呃、然後、那個之類)。
- 音訊長度限制:檔案處理單次最長 1 小時;若同時開啟語者分離或時間戳,上限降為 30 分鐘;即時串流每個工作階段 10 分鐘。
至於準確度與價格,官方文件頁面本身並未列出詞錯誤率(WER)數字與定價細節。第三方報導(MarkTechPost)引述 Artificial Analysis 的量測,指出非串流平均詞錯誤率約 2.6%、串流約 4.0%;多家整理文章給出的價格估算約為批次每分鐘 0.005 美元、即時每分鐘 0.009 美元。這些數字皆非 Google 官方公布,實際費率請以 Gemini API 定價頁為準。
市場影響分析
對台灣使用者: 語碼轉換的支援是這次最該關注的功能。台灣職場的會議語言現實就是中英夾雜——「這個 feature 的 timeline 要 push 一下」這種句子,過去的轉錄模型幾乎必錯。如果以語句為單位的語言偵測真的能穩定處理這種混用,那對會議記錄、訪談逐字稿的實用度會有明顯提升。但要提醒:官方沒有針對繁體中文與台灣口音公布個別的準確度數字,這件事只能自己實測。
對企業應用: 自訂詞彙偏誤是企業導入時最實用的功能。公司內部的產品代號、專案名稱、同事的名字,這些通用模型一定會轉錯,但可以透過詞彙清單餵進去。官方建議約 100 個詞效果最好,這個數字很務實——不要一次塞 1,000 個進去,先挑最常出現又最常錯的。
不過 30 分鐘與 1 小時的音訊上限,對法說會、教育訓練這類長時間錄音來說需要額外的切檔處理。導入前要把這段工程成本算進去。
對開發者: 兩個端點分開的設計,代表你要依場景選 API,而不是一套打天下。做即時字幕的走 Live API,但每個工作階段 10 分鐘的限制意味著長時間直播需要處理續接。做批次轉錄的走 Interactions API,要注意開啟時間戳會犧牲準確度這件事——如果你的應用不需要精確對時,就別開。
市場上的競爭也要納入考量。ElevenLabs 在語音領域有既有的生態、Otter.ai 在會議場景有成熟的產品體驗、Descript 則把轉錄整合進剪輯流程。純 API 層的選擇變多,對開發者是好事。
未來發展趨勢
語音轉文字這個品類正在分化成兩層:一層是模型 API(拚準確度、語言數、單價),另一層是應用產品(拚工作流整合與體驗)。Google 這次很明確站在第一層,把模型能力賣給開發者,不做終端應用。
我認為接下來一年的競爭焦點會從「準確度」轉向「結構化輸出」。單純把聲音變成文字已經接近商品化,真正有價值的是誰講的、什麼時候講的、哪一句是決議、哪一句是待辦——語者分離與時間戳都是往這個方向走的基礎建設。
另一個值得追蹤的是預覽版何時轉正式版。公開預覽期間的模型行為、定價與服務等級都可能調整,把它放進生產環境前要評估這個風險。
TheAI學院 總結與評語
老實說,語音轉文字這幾年的進步已經到了「一般用途夠好了」的階段,再往上拚幾個百分點的準確度,感受不會太強烈。真正還沒解決的是那些邊緣情況:多語混用、多人搶話、專業術語、口音。這次 Gemini 3.5 Transcribe 主打的功能,剛好都在這幾個點上。
給台灣團隊的具體建議:找一段你們最頭痛的真實會議錄音——最好是中英夾雜、三個人以上、講得很快的那種——同時丟給現在在用的服務與這個新模型,比對結果。不要看官方 demo,不要看第三方評測的平均數字,用你自己的資料測。另外記得把 100 個公司常用術語整理成詞彙清單一起餵進去,那才是真實的使用條件。
評語:語音轉文字已經不缺「堪用」的選項,缺的是能處理台灣中英夾雜這種混亂現場的模型。Gemini 3.5 Transcribe 的規格看起來對症下藥,但它在繁體中文與台灣口音上到底行不行,官方沒給數字,只能自己測。花半天做這個實測,比讀十篇評測有用。
資料來源
- Google AI for Developers:Gemini 3.5 Transcribe 官方文件
- MarkTechPost:Google AI Releases Gemini 3.5 Transcribe(2026 年 8 月 27 日)
本文依公開資訊整理,功能規格與定價以官方為準。文中提及的詞錯誤率與價格估算引自第三方來源,非 Google 官方公布數字。
常見問題
Gemini 3.5 Transcribe 支援繁體中文嗎?
官方文件說明支援 85 種以上語言並附有 BCP-47 代碼對照,中文在範圍內。但官方未公布繁體中文與台灣口音的個別準確度數字,建議用自家的實際錄音做實測,特別是中英夾雜的會議情境。
兩個端點該用哪一個?
處理已錄好的音檔(會議錄音、Podcast、影片)用 gemini-3.5-transcribe,走 Interactions API;需要即時雙向串流(現場字幕、語音助理、客服)用 gemini-3.5-transcribe-live,走 Live API。兩者的限制不同,即時串流每個工作階段上限 10 分鐘。
為什麼開啟時間戳會影響準確度?
這是官方文件明確註明的取捨:字詞級時間戳僅檔案處理端點支援,且開啟後會使轉錄準確度下降。如果你的應用不需要精確對時(例如只是要逐字稿而非字幕),建議不要開啟。
自訂詞彙要放幾個詞?
官方上限是 1,000 個詞,但建議約 100 個時效果最好。實務上應該挑出最常出現又最常被轉錯的術語、產品名與人名,而不是把整本術語表倒進去。
資料來源:theai-editorial