Gemini 3.5 Transcribe 深度解析：Google 為何讓媒體 AI 專門化？（2026）

2026 年 8 月 26 日，Google 在官方部落格發布 Gemini 3.5 Transcribe；隔天又推出可延伸場景、指定首尾影格並輸出 4K 放大版本的 Gemini Omni 1.1 Flash。表面上，一個把聲音變成文字，一個把指令變成影片，像是兩則各自獨立的產品新聞。真正值得注意的卻是同一個方向：Google 正在產品與 API 層，把媒體能力包成任務專用的模型入口與更明確的控制介面；公開資料沒有證明底層架構也因此「變窄」。

這不代表專用模型一定比較強。Google 的發布文混在一起使用「最精準」、public preview、function calling 與公司自測數字；現行模型文件與獨立評測補上後，有些說法成立，有些必須縮小範圍。下面先忠實還原原文，再回答三個更實際的問題：Gemini 3.5 Transcribe 到底交付了什麼？它在公開評測上站在哪裡？Omni 與 Transcribe 同週出現，透露了哪一種產品策略？

點擊下方截圖可在新分頁開啟 Google 公告，直接閱讀原文。

---

Gemini 3.5 Transcribe 原文到底宣布了什麼？

Today, we’re introducing Gemini 3.5 Transcribe, our most precise speech-to-text model yet, designed for intelligent voice interactions.

中文：「今天，我們推出 Gemini 3.5 Transcribe，這是目前最精準、為智慧語音互動設計的 Google 語音轉文字模型。」

Google，〈Intelligent transcription with Gemini 3.5 Transcribe〉

這句話有兩個不能省略的限定。第一，原文是「our most precise」，意思是 Google 自家目前最精準的語音轉文字模型，不是全市場第一。第二，Transcribe 不是一般 Gemini 模型多了一個上傳音檔按鈕，而是兩條獨立 API：

工作模式	模型 ID	主要輸出	現行文件邊界
預錄音訊	gemini-3.5-transcribe	逐字稿、說話者、字詞時間碼	單檔最長 1 小時；開啟說話者或時間碼時為 30 分鐘
即時串流	gemini-3.5-transcribe-live	連續 partial／final 文字	單次連線最長 10 分鐘；不提供說話者辨識與字詞時間碼

Google 把能力包成兩種文字模式。Verbatim 盡量保留停頓、口頭禪與自我修正，適合逐字紀錄；Smart transcription 會移除「嗯、啊」、整理標點，還可能把「週二——不，週三」直接收斂成週三。後者更像可讀筆記，卻不是忠實逐字稿，而且不能與 word timestamps 或 speaker diarization 同時啟用；需要這兩項功能時只能用 verbatim。官方文件另警告，開啟字詞時間碼可能降低整體轉錄準確度；模型卡也承認 Transcribe 可能出現幻覺、偶發緩慢或 timeout。若文字要作為訪談引用、客服稽核或其他可追溯紀錄，較穩健的做法是保存原始音訊與 verbatim，再把 smart 結果當成衍生版本，而不是只留下模型清理過的文字。

現行模型頁列出超過 85 種語言、自訂詞彙最多 1,000 個詞（Google 建議控制在 100 個以內），以及預錄音訊最多辨識 8 位說話者；3 位以上仍標成 experimental。發布文只把「最多 3 位」放在主文，現行文件則補出 8 位上限；兩者都警告 3 位以上屬實驗功能，不應被寫成互相推翻。真正要整合時，模型頁比發布文提供更完整的操作邊界。

GA 還是 Preview？Google 同一通道的文件也沒有統一答案

發布文最後把開發者的 Gemini API／AI Studio 與企業入口都寫成 public preview；同一天的 Gemini API changelog 卻把 gemini-3.5-transcribe 與 gemini-3.5-transcribe-live 標成 GA。也就是說，衝突不只來自不同平台：Google 對同一組無後綴 Gemini API 模型，也在發布文與 changelog 使用不同階段標籤。Google Cloud 的 Gemini Enterprise Agent Platform 則另有帶 -preview 後綴的端點，並明確標示 Preview。

• Gemini API／AI Studio：changelog 把無後綴模型列為 GA，發布文卻把同一開發者入口寫成 public preview。
• Gemini Enterprise Agent Platform：使用 -preview 模型 ID，產品頁列 Preview。
• 消費者產品：發布時僅列出英文 Gemini macOS app、特定國家與語言的 Android Rambler，Chrome 則是 coming soon，不能外推成所有使用者都已拿到。

因此，目前不能只靠「通道不同」把所有標籤調和掉。能確定的是端點已可呼叫、Cloud 版本仍帶 preview 後綴；無後綴 Gemini API 究竟應按 GA 還是 Preview 管理，Google 的公開文件本身未統一。要進 production，應鎖定實際模型 ID、帳戶控制台、配額與支援條款，而不是只引用其中一頁的階段名稱。

Function calling 的漂亮示範，不是 Transcribe API 的能力

原文最容易讓開發者誤讀的一段，是「模型可以透過 function calls，把影像生成、檔案分析等複雜任務交給其他 Gemini 模型」，接著才補一句目前只在 Gemini macOS app 提供。若直接查看模型規格，Gemini 3.5 Transcribe 的功能表反而把 function calling 列為不支援。

較合理的解讀是：macOS app 在應用層接收 Transcribe 的文字，再把工作路由給另一個能叫工具的 Gemini 模型；開發者直接呼叫 Transcribe endpoint，拿不到同一套工具能力。這個分界很重要。語音 Agent 的完整路徑至少還有端點偵測、輪替管理、LLM、工具、回應合成與打斷控制，STT 只是其中的「耳朵」。想看一個把 ASR、TTS 與 server 邊界拆開的本機案例，可延伸閱讀 NeMo-Speech.cpp 本機語音 API 教學。

2.6% WER 很強，但沒有證明它是市場第一

Google 引用 Artificial Analysis，宣稱非串流平均 WER 為 2.6%、串流為 4.0%，time to final transcription 比 Chirp 3 改善 70%。前兩個數字來自第三方排行榜；70% 則是 Google 對前代的產品比較。WER 可以粗略理解成每 100 個參考字詞需要多少次替換、遺漏或插入，越低越好，但它不是所有語言、口音與場景的單一準確率。

截至 2026 年 8 月 29 日，Artificial Analysis 的非串流榜把 Gemini 3.5 Transcribe 的 2.6% 排在第 5，不是第 1。AA 方法頁顯示，總樣本約 8 小時，權重是 50% AA-AgentTalk、25% VoxPopuli、25% Earnings22；測試 prompt 要求 verbatim，並套用以英文為主的 normalizer。AA-AgentTalk 是為語音 Agent 設計的私有 held-out 集，不能把名稱直接理解成完整自然對話，更不能用這個排名驗證 Smart 模式或 85+ 語言。它比一段乾淨 demo 更有參考價值，仍無法代表台灣中文、產品代碼、人名或你的麥克風環境。

這張圖也不能替 85+ 語言背書。Google 的 評測方法只選 FLEURS 的 26 個 top locales；原始資料集雖涵蓋 102 種語言，主要仍是朗讀句子，資料卡明說 read-speech 與嘈雜 production 環境可能存在落差。因此圖上的 5.50% 支持「Google 選定語言、指定設定下優於圖中對手」，不是跨所有語言與真實場景的通行證。

另一份更接近即時 API 的公開證據來自 Pipecat STT Benchmark。在它的 1,000 段測試集中，gemini-3.5-transcribe-live 有 99.9% 樣本產出文字、78.0% 完全匹配、semantic WER 2.24%，time to final segment 中位數為 458ms。成績很強，但同一張表仍有供應商取得更低 WER 或更短延遲，沒有單一模型同時壟斷所有欄位。

反方證據其實就在同一張表：AssemblyAI universal-3-5-pro 同樣有 99.9% 樣本產出文字，卻同時取得較高 perfect rate（84.7%）、較低 WER（1.44%）與較短 TTFS 中位數／P95／P99；在這組欄位上，Gemini 並不領先。Pipecat 也不是把每家服務在同一時間、同一機房重跑的正式聯賽，各列可由不同貢獻者加入。測試集偏向語音 Agent 的 turn-taking 片段；參考逐字稿先由 Gemini 生成再由人工覆核，semantic WER 由 Claude 判讀並忽略 filler words，因此不能驗證逐字忠實度。它能證明 Transcribe 值得進候選名單，不能證明你的 workload 一定重現 2.24%。

隔天的 Omni，把同一條策略帶到影片

8 月 27 日，Google 又發布 Gemini Omni 1.1 Flash。單次輸出仍是 3–10 秒；所謂 40 秒，是每次延伸 10 秒後的累積長度，而且延伸只承諾使用最後 10 秒影片作為脈絡，沒有證明模型會記住前 40 秒的完整敘事與角色狀態。它也能指定首尾影格、先以 360p 打樣，再把入選片段輸出為 1080p 或 4K；API guide明確說後兩者經過 upscaling，不是原生細節保證。完整規格與計價已在 Gemini Omni 1.1 Flash 深度解析逐項拆過，這裡只保留與本文論點直接相關的反方證據。

首尾影格只是端點約束，不保證中間動作、物理或角色一致；Google 的 Omni model card也承認，跨編輯的完整一致性、複雜動作與精準文字仍是難題。發布文與模型卡沒有公開 capability benchmark、失敗率或盲測基線，所以目前只能確認控制參數存在，不能由 4K 標籤或成功 demo 推導長片可靠度。

把兩則發布並排，Transcribe 的核心不是讓 Gemini「聽得懂」——一般 Gemini 本來就能理解音訊；Omni 的核心也不只是讓 Google「會生影片」——Veo 是另一條影片生成產品。兩個專用模型共同增加的是可被工作流驗收的控制面：

• Transcribe：把即時／預錄音訊、verbatim／smart、說話者、時間碼、自訂詞彙拆成明確參數與介面。
• Omni：把時間延伸、首尾邊界、參考片段、草稿解析度與輸出解析度拆成明確參數與介面。
• 共同效果：團隊可以固定輸入、選模式、比較版本並設定失敗條件，減少部分只靠 prompt 的不確定性；生成結果仍須抽樣驗收。

AlphaLab 的判讀：任務專用 API 不是倒退，而是把責任說清楚

判讀一：模型競爭正從「會不會」轉向「能不能控制」

通用模型已能聽音檔、看影片、寫文字，繼續列出 modalities 很難回答 production 問題。客服中心關心誰說了哪句、逐字稿能否追溯；影片團隊關心角色跨鏡是否一致、草稿能否低成本重跑。任務專用 endpoint 的價值，是為模式、時間碼、影格與解析度提供可設定欄位，並讓角色一致、轉錄忠實度等結果能被分項測試；它沒有把後兩者直接變成保證。

判讀二：任務專用端點讓 benchmark 更有用，也更容易被誤用

STT 有 WER、speaker attribution、final latency，至少能把「感覺很準」拆成數字；影片也能分開評 continuity、prompt adherence 與時間邊界。問題是數字越乾淨，越容易被當成通用排名。Artificial Analysis 的 2.6% 與 Pipecat 的 2.24% 來自不同資料集、評分方法與產品模式，兩者都是真的，也都不是台灣中文會議逐字稿的保證。

判讀三：Google 的真正優勢可能是路由，而不只是單一模型

發布時，Transcribe 已進入 Gboard、Gemini app 等入口，並預告 Chrome coming soon；macOS app 還展示把文字交給其他模型叫工具。由這些產品入口推論，Google 可能不只想賣一條孤立 STT API，而是讓任務專用入口先把媒體轉成結構，再交給通用模型推理或行動。這是產品路由的策略推論，不是 Google 已公布的統一架構；Transcribe 的 模型卡反而寫明它基於 Gemini 3 Pro，因此不能把產品介面專用化誤寫成底層架構變窄或性能提升的原因。

判讀四：Smart output 很方便，卻不能取代原始紀錄

Transcribe 把自我修正、贅字與格式清理直接納入模型輸出，這可減少會議筆記的後處理；同一件事也會把「辨識」與「編輯」混在一起。只要用途涉及精準引用或事後追查，就應保存原始音訊與 verbatim 版本，讓 smart 文字服務閱讀，而不是改寫唯一的 source of truth。

我同意什麼，我存疑什麼

我同意：Gemini 3.5 Transcribe 已有可呼叫的即時／預錄音訊 API、明確模式與強勁公開成績，Omni 1.1 也把影片生成推向迭代式導演。兩者都比「通用模型也支援音訊／影片」更接近可以驗收的產品。

我存疑：Google 把「自家最精準」放在最醒目的位置，卻讓 GA／Preview 直接出現官方衝突，說話者上限與 function calling 邊界又散落在不同文件。這些不會推翻產品價值，但會提高整合成本；剛發布就要進 production 的團隊，不能把一篇 launch post 當成完整規格。

---

現在怎麼測 Gemini 3.5 Transcribe，才不會被榜單帶著走？

1. 先選產品模式。字幕與語音 Agent 測即時端點；會議、客服錄音與影音後製測預錄音訊端點。後者走 Interactions API，不是 Gemini Batch API；兩組 WER 與延遲也不能混在一起。
2. 建立 50–200 段自己的 eval set。按台灣中文／英文／中英夾雜、口音、房間、麥克風、背景噪音與重疊說話分桶，另放入人名、產品碼、地址與數字。
3. 同時保存 verbatim 與 smart。前者算 WER／CER 與追溯錯誤，後者另評可讀性、錯誤刪詞與自我修正是否被正確處理。
4. 把品質與延遲拆開。記錄 first partial、final segment、整段完成時間、空結果率、speaker attribution 與 timestamp 偏移，別只留一個平均值。
5. 用固定門檻決定路由。若專有名詞或關鍵數字未達標，先試 custom vocabulary；仍失敗就保留人工複核或第二模型，而不是因公開榜單第幾名直接全量切換。

若還沒有自己的驗收集，可先用 10 題小型 Eval 與模型路由方法建立最小版本，再把題目改成真實音檔。任務專用介面真正帶來的進步，不是讓你少做評測，而是終於能把「哪裡準、哪裡快、哪裡會改寫」拆開量測。