Google 發表 Gemini 3.5 Transcribe，將它定位為新一代語音轉文字模型，而且不只是把錄音內容原封不動打出來。這套模型的目標，是把帶有停頓、口頭禪、說到一半重新修正的自然語音，整理成較完整、易讀的文字，適合用於口述輸入、筆記、訊息及語音編輯。Google 更稱它是目前最精準的語音轉文字模型，並把它視為 Chirp 3 的重要升級。1 12

這項改變很實用，但也值得先搞清楚：一個會刪走「嗯」、「呃」、理解修正內容並推測語意的系統，確實能產生更像成稿的文字，卻可能不再完整保留說話者的原句。

Gemini 3.5 Transcribe 改變了什麼？

Gemini 3.5 Transcribe 採用 Google 所稱的「智能轉錄」方式。它不會把每一次停頓、重複或未完成的句子都視為必須保留的內容，而是可以清理語氣不流暢之處、採用說話者後來的修正、補上標點及套用格式。模型也能接受語音編輯指令，把零散、不成句的口述內容整理成更易讀的文章。1 8 12

換句話說，用戶可以像口述草稿一樣說話，不必刻意放慢或每句講得完整，最後取得較接近訊息、文件或表格回覆的文字。

模型亦針對背景噪音、技術術語及專門詞彙進行設計。Google 表示，開發者可以加入自訂詞彙，讓人名、產品名稱及特定領域用語更有機會以正確拼法呈現；系統則可自動辨識 85 種以上語言。1 7

處理預錄音訊時，Google 列出時間戳記及最多三位講者的說話者分離功能，開發者因此可以把不同片段對應到個別講者。1

比 Chirp 3 更準、更快？數字要看測試條件

Google 將 Gemini 3.5 Transcribe 描述為相較前代 Chirp 3 的大幅進步。引用 Artificial Analysis 測量結果的報道指出，模型在非串流音訊的詞語錯誤率為 2.6%，串流音訊為 4.0%，而取得最終轉錄文字所需的時間減少 70%。3 4 9

不過，這些數字不能直接當成所有情況下的保證。詞語錯誤率會受語言、口音、錄音品質、背景噪音及測試資料集影響。Google 自己的資料則列出 FLEURS 基準測試結果，在串流模式下的詞語錯誤率為 5.50%；由於測試條件不同，這項數字不能與所有第三方測量直接比較。1

較實際的解讀是：Google 同時希望降低即時語音互動的延遲，也改善錄音或口述內容最後整理出來的品質，而不是單靠一個基準數字證明模型在任何場景都同樣出色。

開發者可選即時或預錄音訊流程

Google 按照應用場景，提供兩條主要使用路徑。

即時語音轉錄

即時方案適合需要持續接收音訊並快速回應的應用。Gemini Live API 支援低延遲、即時的語音互動，也能提供用戶輸入及模型輸出的文字轉錄。12 20

這類整合可用於語音助理、即時字幕、對話式介面，以及需要在說話者尚未講完時便開始產生文字的服務。API 參考文件亦區分單次請求、串流及即時互動等 Gemini 應用程式介面模式。24

預錄音訊轉錄

處理已經錄好的音訊時，開發者可以上傳或引用音訊檔案，再透過 Gemini API 的互動流程提交處理。這種方式較適合重視時間戳記、格式、自訂詞彙及講者標記的工作，而不是追求即時回應。1 12 18

Google 的 Gemini API 文件建議新應用採用 Interactions API 作為標準介面；至於需要持續、低延遲語音及視覺互動的體驗，則使用 Live API。19 20

已經用在哪些 Google 產品？

Gemini 3.5 Transcribe 並非只停留在開發者預覽階段。相關報道指，它已經支援 Android 版 Gboard 的 Rambler 語音口述功能，以及 macOS 版 Gemini 應用程式。2 13 26

Google 亦表示，Chrome 即將加入由這套模型支援的語音轉文字功能。屆時用戶可直接在網頁文字欄位口述內容，包括訊息、貼文、表格及提示詞，而不必局限於專門的語音輸入應用程式。1 8 13

這次模型發布也與 Gemini 3.5 Live 及 Gemini 3.5 Live Experimental 一同納入 Google 所稱的「Gemini Audio」系列。當中，Transcribe 專注於把語音轉成文字；Live 系列則主要面向互動式音訊體驗。12 26

最大取捨：工整文字，還是忠於原話？

Gemini 3.5 Transcribe 最吸引人的功能，也正是它最需要留意的限制。刪除填充詞、整合自我修正及潤飾句子，能讓口述內容更容易直接使用，但同時改變了錄音與文字稿之間的關係。

一份整理後的文字可能省略有意義的遲疑，只保留說話者修正後的版本，亦可能淡化個人的說話節奏與風格。對於口述訊息、整理筆記或填寫表格，這往往是優點；但如果重點是保留原話，就未必如此。

因此，在訪問、法律或醫療紀錄、研究逐字稿、無障礙文件或需要引用原句的場合，用戶應保留原始錄音，並核對重要段落。除非具體實作提供清楚的「逐字模式」，否則 Gemini 3.5 Transcribe 更適合被理解為具備編輯能力的智能轉錄系統，而不是中立、完全不改動的錄音文字化工具。

這次發布代表什麼？

Google 正把語音辨識推向「語音協助寫作」。Gemini 3.5 Transcribe 把轉錄、清理、格式化、語言辨識、自訂詞彙及講者資訊整合在一起，並為即時及預錄音訊提供不同工作流程。1 12

對開發者而言，這可能減少語音辨識後所需的文字後處理；對一般用戶而言，口述輸入也許不再像是在對機器逐字報讀，而更像是把一份粗略草稿交給編輯整理。

真正需要問的問題，已經不只是模型能否產生更乾淨的文字，而是每個應用需要「乾淨的文字」，還是需要一份「確切記錄原話」的文字稿。

Google 發表 Gemini 3.5 Transcribe，將它定位為新一代語音轉文字模型，而且不只是把錄音內容原封不動打出來。這套模型的目標，是把帶有停頓、口頭禪、說到一半重新修正的自然語音，整理成較完整、易讀的文字，適合用於口述輸入、筆記、訊息及語音編輯。Google 更稱它是目前最精準的語音轉文字模型，並把它視為 Chirp 3 的重要升級。1 12

這項改變很實用，但也值得先搞清楚：一個會刪走「嗯」、「呃」、理解修正內容並推測語意的系統，確實能產生更像成稿的文字，卻可能不再完整保留說話者的原句。

Gemini 3.5 Transcribe 改變了什麼？

Gemini 3.5 Transcribe 採用 Google 所稱的「智能轉錄」方式。它不會把每一次停頓、重複或未完成的句子都視為必須保留的內容，而是可以清理語氣不流暢之處、採用說話者後來的修正、補上標點及套用格式。模型也能接受語音編輯指令，把零散、不成句的口述內容整理成更易讀的文章。1 8 12

換句話說，用戶可以像口述草稿一樣說話，不必刻意放慢或每句講得完整，最後取得較接近訊息、文件或表格回覆的文字。

模型亦針對背景噪音、技術術語及專門詞彙進行設計。Google 表示，開發者可以加入自訂詞彙，讓人名、產品名稱及特定領域用語更有機會以正確拼法呈現；系統則可自動辨識 85 種以上語言。1 7

處理預錄音訊時，Google 列出時間戳記及最多三位講者的說話者分離功能，開發者因此可以把不同片段對應到個別講者。1

比 Chirp 3 更準、更快？數字要看測試條件

Google 將 Gemini 3.5 Transcribe 描述為相較前代 Chirp 3 的大幅進步。引用 Artificial Analysis 測量結果的報道指出，模型在非串流音訊的詞語錯誤率為 2.6%，串流音訊為 4.0%，而取得最終轉錄文字所需的時間減少 70%。3 4 9

不過，這些數字不能直接當成所有情況下的保證。詞語錯誤率會受語言、口音、錄音品質、背景噪音及測試資料集影響。Google 自己的資料則列出 FLEURS 基準測試結果，在串流模式下的詞語錯誤率為 5.50%；由於測試條件不同，這項數字不能與所有第三方測量直接比較。1

較實際的解讀是：Google 同時希望降低即時語音互動的延遲，也改善錄音或口述內容最後整理出來的品質，而不是單靠一個基準數字證明模型在任何場景都同樣出色。

開發者可選即時或預錄音訊流程

Google 按照應用場景，提供兩條主要使用路徑。

即時語音轉錄

即時方案適合需要持續接收音訊並快速回應的應用。Gemini Live API 支援低延遲、即時的語音互動，也能提供用戶輸入及模型輸出的文字轉錄。12 20

這類整合可用於語音助理、即時字幕、對話式介面，以及需要在說話者尚未講完時便開始產生文字的服務。API 參考文件亦區分單次請求、串流及即時互動等 Gemini 應用程式介面模式。24

預錄音訊轉錄

處理已經錄好的音訊時，開發者可以上傳或引用音訊檔案，再透過 Gemini API 的互動流程提交處理。這種方式較適合重視時間戳記、格式、自訂詞彙及講者標記的工作，而不是追求即時回應。1 12 18

Google 的 Gemini API 文件建議新應用採用 Interactions API 作為標準介面；至於需要持續、低延遲語音及視覺互動的體驗，則使用 Live API。19 20

已經用在哪些 Google 產品？

Gemini 3.5 Transcribe 並非只停留在開發者預覽階段。相關報道指，它已經支援 Android 版 Gboard 的 Rambler 語音口述功能，以及 macOS 版 Gemini 應用程式。2 13 26

Google 亦表示，Chrome 即將加入由這套模型支援的語音轉文字功能。屆時用戶可直接在網頁文字欄位口述內容，包括訊息、貼文、表格及提示詞，而不必局限於專門的語音輸入應用程式。1 8 13

這次模型發布也與 Gemini 3.5 Live 及 Gemini 3.5 Live Experimental 一同納入 Google 所稱的「Gemini Audio」系列。當中，Transcribe 專注於把語音轉成文字；Live 系列則主要面向互動式音訊體驗。12 26

最大取捨：工整文字，還是忠於原話？

Gemini 3.5 Transcribe 最吸引人的功能，也正是它最需要留意的限制。刪除填充詞、整合自我修正及潤飾句子，能讓口述內容更容易直接使用，但同時改變了錄音與文字稿之間的關係。

一份整理後的文字可能省略有意義的遲疑，只保留說話者修正後的版本，亦可能淡化個人的說話節奏與風格。對於口述訊息、整理筆記或填寫表格，這往往是優點；但如果重點是保留原話，就未必如此。

因此，在訪問、法律或醫療紀錄、研究逐字稿、無障礙文件或需要引用原句的場合，用戶應保留原始錄音，並核對重要段落。除非具體實作提供清楚的「逐字模式」，否則 Gemini 3.5 Transcribe 更適合被理解為具備編輯能力的智能轉錄系統，而不是中立、完全不改動的錄音文字化工具。

這次發布代表什麼？

Google 正把語音辨識推向「語音協助寫作」。Gemini 3.5 Transcribe 把轉錄、清理、格式化、語言辨識、自訂詞彙及講者資訊整合在一起，並為即時及預錄音訊提供不同工作流程。1 12

對開發者而言，這可能減少語音辨識後所需的文字後處理；對一般用戶而言，口述輸入也許不再像是在對機器逐字報讀，而更像是把一份粗略草稿交給編輯整理。

真正需要問的問題，已經不只是模型能否產生更乾淨的文字，而是每個應用需要「乾淨的文字」，還是需要一份「確切記錄原話」的文字稿。