返回快訊

谷歌發佈Gemini 3.5 Transcribe模型,用於實時聽寫及預錄音頻轉寫

谷歌推出Gemini 3.5 Transcribe語音轉文本模型,將語音識別與語義級文本編輯結合,用於實時聽寫及預錄音頻轉寫。

模型可刪除“um”“uh”等口頭填充詞,識別說話者自我修正並輸出整理後的文本;用戶可提供自定義詞彙表,使其更準確處理專業術語、訂單號、郵編等字母數字實體。該能力意味着輸出並非天然逐字記錄,而是經過語義處理的成稿文本。blog+1

在FLEURS多語種基準的主要語言與地區測試中,Gemini 3.5 Transcribe流式轉寫詞錯誤率爲5.50%,非流式爲5.04%;谷歌稱,相較上一代Chirp 3,最終轉寫生成時間縮短70%。另一組由Artificial Analysis測量的平均成績爲流式4.0%、非流式2.6%,兩組指標採用的評測方法和數據集不同。blog+1

模型可自動識別並轉寫85種以上語言,處理不同地區口音和方言;預錄音頻支持最多三名說話者的時間戳歸屬,三人以上說話人識別仍處於實驗階段。谷歌同時提供面向實時交互的Transcribe Live及面向預錄音處理的Transcribe接口。deepmind+1

該模型已通過Android版Gboard的Rambler功能落地,並向Gemini API的Google AI Studio和Antigravity開放公開預覽;Gemini Enterprise Agent Platform也處於公開預覽,Chrome支持被列爲後續計劃。公開報道顯示,Rambler目前僅在部分國家和語言推出,並非所有Pixel或所有Android用戶均已獲得。theverge+1

市場機制上,谷歌把轉寫能力嵌入Gboard、Gemini及企業API,獲益方包括需處理跨語言客服錄音、會議紀要和語音輸入的開發者與企業客戶;低延遲與更低錯誤率會把部分需求從獨立轉寫軟件導向谷歌的模型和雲端接口。以逐字法律取證、醫療原始記錄或新聞引語爲核心業務的用戶則面臨風險:去口頭禪和自動修正可提高可讀性,卻可能改變原始表述,需選擇保留原話的工作流。theverge+1

來源:公開信息

ABAB AI 解讀

谷歌語音識別並非從Gemini時代纔開始佈局:Google Cloud曾將Chirp作爲Universal Speech Model推進,藉由大規模多語種語音數據提供語音轉寫能力;Chirp 3是其上一代轉寫引擎。Gemini 3.5 Transcribe的變化不只是把詞錯誤率繼續壓低,而是把“識別”推進到“重寫”——模型判斷哪些停頓、口誤和自我修正應被剔除。這與Google Docs的Smart Compose、Gmail的寫作輔助形成相同產品路線:先捕捉輸入,再將輸入改寫成可直接使用的文本。

資本與資源路徑集中在終端入口和雲服務兩端。Gboard擁有移動端輸入入口,Gemini API與Enterprise Agent Platform面向開發者和企業工作流,Chrome則擁有瀏覽器入口;同一套模型可同時服務消費者聽寫、客服中心錄音、會議歸檔和語音代理。谷歌選擇讓Rambler率先承接該能力,實質是在鍵盤層把語音變爲格式化文本,而不是僅在雲端出售每分鐘轉寫服務;這會提高用戶對Google輸入層與Gemini服務的黏性。

可對比微軟將Azure Speech、Teams Copilot和Microsoft 365 Copilot連接,或OpenAI把語音輸入、實時API與ChatGPT產品結合:三者都在將語音從單獨的識別工具轉爲AI工作流的原始數據層。傳統轉寫公司如Rev、Otter.ai和AssemblyAI仍可提供專業功能,但行業位置已從“提供基礎轉寫能力”轉向“在合規、垂直工作流、審計軌跡或高保真逐字記錄上建立差異”。Gemini 3.5 Transcribe處於語音AI從工具擴張至操作界面的階段。

本質屬於技術替代:原先的語音轉寫按“音頻—文字”交付,現在模型直接交付“可發送、可歸檔、可執行的文本”。發生機制是,多模態模型同時擁有聲學識別、上下文推斷和語言生成能力,因此可把原始語音中的噪音、猶豫與修正壓縮掉;效率提升會降低語音作爲輸入方式的摩擦,卻也將逐字真實性從默認輸出改爲需要主動選擇的產品屬性。

ABAB News · 認知定律

  1. 輸入越智能,原始信息越稀缺

  2. 自動修正提升效率,也重寫證據

  3. 工具替代工具,入口決定利潤