Google 推出 Gemini 3.5 Transcribe，將語音轉文字由「逐句照抄」推向「先理解、再整理」。呢個新模型主打將零碎、口語化、講到一半停頓或者改口嘅說話，直接變成較完整、易讀、甚至可以即時使用嘅文字。Google 更形容佢係目前最精準嘅語音轉文字模型，並視之為 Chirp 3 之後嘅重大升級。1 12

但要留意，文字變得更順，唔代表一定更忠於原聲。Gemini 3.5 Transcribe 會主動刪走語氣詞、整合修正內容，甚至按推斷到嘅意思重新組織句子。對於口述訊息、寫筆記或者填表格，呢種做法可能更加方便；但如果你要嘅係一份不加修飾嘅逐字稿，結果就未必一樣。

新模型有咩唔同？

Gemini 3.5 Transcribe 採用 Google 所稱嘅「智能轉錄」方式。傳統語音辨識通常會將每個停頓、重複字眼或者講到一半放棄嘅句子都保留落去；新模型就可以清理呢啲語氣不流暢位，將講者後來嘅修正整合入句子，再加上標點及基本格式。1 8 12

例如使用者可以一邊諗一邊講，先講出一個版本，之後再話「唔係，應該係另一個日期」。模型嘗試輸出嘅，唔係完整保留兩個版本，而係較接近最後意思嘅整潔文字。它亦支援以語音指令修改內容，將一段比較散亂嘅口述整理成文章、訊息或者表格回覆。1 8

Google 表示，模型可以處理背景噪音、專業術語及特殊詞彙。開發者亦可以加入自訂詞彙表，令姓名、產品名或者行業用語更大機會以指定拼法顯示。模型自動偵測超過 85 種語言。1 7

處理預錄音訊時，系統可以提供時間戳，並分辨最多三位講者，方便將逐段內容對應返不同參與者。1

比 Chirp 3 快幾多、準幾多？

Google 將 Gemini 3.5 Transcribe 定位為 Chirp 3 嘅大幅改進版。引用 Artificial Analysis 測量結果嘅報道指出，Gemini 3.5 Transcribe 在非串流音訊嘅字詞錯誤率為 2.6%，串流音訊則為 4.0%；由收到語音到產生最終稿件所需時間，就減少約 70%。3 4 9

不過，呢啲數字唔應該當成所有情況都適用嘅保證。字詞錯誤率會受語言、口音、錄音質素、背景聲，以及測試資料集影響。Google 自己引用 FLEURS 基準測試時，提到串流模式字詞錯誤率為 5.50%；由於測試條件唔同，呢個結果唔可以直接同所有第三方測量互相比較。1

實際上比較重要嘅訊息係：Google 同時針對兩個方向改善——即時對話要有較低延遲，而錄音或口述內容完成後，就要有較乾淨嘅最終文字。

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

Google 為不同應用場景提供兩條主要路線。

即時轉錄

即時版本適合需要持續接收音訊、快速回應嘅應用。Gemini Live API 可以處理低延遲、即時嘅連續語音互動，亦可以提供使用者輸入及模型輸出嘅文字轉錄。12 20

呢種整合方式適合語音助手、即時字幕、對話介面，以及要喺講者未講完之前已經開始處理文字嘅產品。Gemini API 文件亦區分咗單次回應、串流及即時互動等使用模式。24

預錄音訊轉錄

如果係已經錄好嘅音檔，開發者可以上載或者引用音訊檔案，再經 Gemini API 嘅互動流程提交處理。呢條路線較適合訪問錄音、會議檔案或者其他現成音訊，因為時間戳、格式、自訂詞彙及講者分辨，通常比即時回應速度更加重要。1 12 18

Google 開發者文件目前建議新 Gemini 應用採用 Interactions API 作為標準介面；至於要處理連續、低延遲語音及視覺互動，就應該使用 Live API。19 20

已經用喺邊啲產品？

Gemini 3.5 Transcribe 並唔只係實驗室展示。報道指，佢已經支援 Android Gboard 嘅 Rambler 語音輸入功能，以及 macOS 版 Gemini 應用程式。2 13 26

Google 亦表示，Chrome 即將加入由呢個模型支援嘅語音轉文字功能。到時使用者可以直接喺網頁文字輸入框口述，包括回覆訊息、撰寫帖文、填寫表格，或者向 Gemini 輸入指令，而唔一定要先開另一個專用應用程式。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

例如使用者可以一邊諗一邊講，先講出一個版本，之後再話「唔係，應該係另一個日期」。模型嘗試輸出嘅，唔係完整保留兩個版本，而係較接近最後意思嘅整潔文字。它亦支援以語音指令修改內容，將一段比較散亂嘅口述整理成文章、訊息或者表格回覆。1 8

Google 表示，模型可以處理背景噪音、專業術語及特殊詞彙。開發者亦可以加入自訂詞彙表，令姓名、產品名或者行業用語更大機會以指定拼法顯示。模型自動偵測超過 85 種語言。1 7

處理預錄音訊時，系統可以提供時間戳，並分辨最多三位講者，方便將逐段內容對應返不同參與者。1

比 Chirp 3 快幾多、準幾多？

Google 將 Gemini 3.5 Transcribe 定位為 Chirp 3 嘅大幅改進版。引用 Artificial Analysis 測量結果嘅報道指出，Gemini 3.5 Transcribe 在非串流音訊嘅字詞錯誤率為 2.6%，串流音訊則為 4.0%；由收到語音到產生最終稿件所需時間，就減少約 70%。3 4 9

不過，呢啲數字唔應該當成所有情況都適用嘅保證。字詞錯誤率會受語言、口音、錄音質素、背景聲，以及測試資料集影響。Google 自己引用 FLEURS 基準測試時，提到串流模式字詞錯誤率為 5.50%；由於測試條件唔同，呢個結果唔可以直接同所有第三方測量互相比較。1

實際上比較重要嘅訊息係：Google 同時針對兩個方向改善——即時對話要有較低延遲，而錄音或口述內容完成後，就要有較乾淨嘅最終文字。

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

Google 為不同應用場景提供兩條主要路線。

即時轉錄

即時版本適合需要持續接收音訊、快速回應嘅應用。Gemini Live API 可以處理低延遲、即時嘅連續語音互動，亦可以提供使用者輸入及模型輸出嘅文字轉錄。12 20

呢種整合方式適合語音助手、即時字幕、對話介面，以及要喺講者未講完之前已經開始處理文字嘅產品。Gemini API 文件亦區分咗單次回應、串流及即時互動等使用模式。24

預錄音訊轉錄

如果係已經錄好嘅音檔，開發者可以上載或者引用音訊檔案，再經 Gemini API 嘅互動流程提交處理。呢條路線較適合訪問錄音、會議檔案或者其他現成音訊，因為時間戳、格式、自訂詞彙及講者分辨，通常比即時回應速度更加重要。1 12 18

Google 開發者文件目前建議新 Gemini 應用採用 Interactions API 作為標準介面；至於要處理連續、低延遲語音及視覺互動，就應該使用 Live API。19 20

已經用喺邊啲產品？

Gemini 3.5 Transcribe 並唔只係實驗室展示。報道指，佢已經支援 Android Gboard 嘅 Rambler 語音輸入功能，以及 macOS 版 Gemini 應用程式。2 13 26

Google 亦表示，Chrome 即將加入由呢個模型支援嘅語音轉文字功能。到時使用者可以直接喺網頁文字輸入框口述，包括回覆訊息、撰寫帖文、填寫表格，或者向 Gemini 輸入指令，而唔一定要先開另一個專用應用程式。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

對開發者嚟講，呢種能力可能減少語音辨識完成後所需嘅後期處理；對一般使用者嚟講，口述就唔使再刻意講得一字一句，可以更加似係將一份粗略草稿交畀編輯幫手整理。

真正值得問嘅問題，唔係模型能唔能夠產生更乾淨嘅文字，而係你嘅應用場景，需要一段「寫得好睇」嘅內容，定係一份「原話係點就點」嘅記錄。