Apple 全新 Speech 框架：SpeechAnalyzer 與 SFSpeechRecognizer 的取捨

iOS 26 在既有的 SFSpeechRecognizer 之外，推出了一套全新的語音辨識框架。新的 API 介面是 SpeechAnalyzer 加上圍繞它組合的模組（SpeechTranscriber、SpeechDetector）¹。Apple 自己的定位是：SpeechAnalyzer 是現代化的路徑——全新的裝置端模型、長音訊支援、自動語言管理、適用於即時場景的低延遲，以及一套可隨時間擴展更多分析類型的模組化架構。SFSpeechRecognizer 仍會持續推出並運作；對於依賴其自訂詞彙功能（新框架尚未提供）的應用程式而言，它仍是正確的工具。

本文將新框架與舊框架並列比較。切入角度是「何時該遷移」而非「如何使用新的 API」，因為每個已經整合 SFSpeechRecognizer 的團隊都面臨同樣的取捨：新框架的現代化模型與架構是否值得遷移成本？還是既有的自訂詞彙投資足以讓你留下？

TL;DR

• SpeechAnalyzer（iOS 26+）是 Apple 現代化的裝置端語音辨識框架。它協調在初始化時設定的分析模組；iOS 26 內建三個：SpeechTranscriber（長音訊）、DictationTranscriber（短語句，相當於 SFSpeechRecognizer）、SpeechDetector（語音活動偵測，必須與轉錄器搭配使用）²。
• 新框架圍繞長音訊打造：講座、會議、多人對話。它完全在裝置端執行，自動管理語言，並搭載 Apple 全新專有模型，在等效轉錄任務上據報導比 Whisper Large V3 Turbo 快 2 倍³。
• SFSpeechRecognizer 仍持續推出並運作。舊框架保留了自訂詞彙功能（註冊已知關鍵字以提高領域專有名詞的辨識精度），新框架尚未提供此功能。
• 遷移是按功能進行，而非全有或全無。需要長音訊轉錄、更低延遲或更佳遠距音訊品質的應用程式，會遷移到 SpeechAnalyzer。已投入自訂詞彙的應用程式，則為這些功能保留 SFSpeechRecognizer，並為新功能加入 SpeechAnalyzer。
• 本系列的Vision 框架文章涵蓋了 Apple 另一個裝置端感知原語；SpeechAnalyzer 將同樣的裝置端、無雲端模式延伸到音訊。

架構：分析器 + 模組

SpeechAnalyzer 本身並不是轉錄器。它是一個協調者，管理音訊分析的工作階段，並將音訊緩衝區分派給一個或多個模組²。模組透過 init(modules:) 初始化器在初始化時設定，分析則透過 start(inputSequence:) 餵入 AsyncSequence 的音訊緩衝區來啟動：

import Speech

let transcriber = SpeechTranscriber(
    locale: .current,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: []
)
let analyzer = SpeechAnalyzer(modules: [transcriber])

try await analyzer.start(inputSequence: audioInputSequence)

for try await result in transcriber.results {
    if result.isFinal {
        print(result.text)
    }
}

iOS 26 內建三個模組：

SpeechTranscriber。 為長音訊（講座、會議、多人對話）設計的語音轉文字模組。回傳串流結果，包含每個 token 的時間資訊、信心分數，以及應用程式透過 for try await 消費的 results AsyncSequence。每個結果都帶有 isFinal 旗標，用以區分易變的部分假設與最終文字。

DictationTranscriber。 舊版 SFSpeechRecognizer 用例的直接替代品：採用與 SFSpeechRecognizer 相同裝置端模型的短語句轉錄。從 SFSpeechRecognizer 遷移過來處理短查詢的應用程式會選用 DictationTranscriber；採用本框架進行長音訊錄製的應用程式則會選用 SpeechTranscriber。這個劃分很重要，因為 SpeechTranscriber 與 DictationTranscriber 使用不同的語言覆蓋範圍與不同的模型路徑。

SpeechDetector。 語音活動偵測。在音訊串流中偵測到語音開始與結束時回報事件。偵測器無法單獨運作；它必須在同一個 SpeechAnalyzer 實例中與其中一個轉錄器模組搭配使用。應用程式用它來控制轉錄運算（不對靜音進行轉錄），或驅動 UI 提示（「請說話」指示器）。

模組化架構是相對於 SFSpeechRecognizer 在結構上的改善。舊的 API 將音訊工作階段管理、語言偵測與轉錄合併成單一物件；新的 API 則分離各項職責，讓應用程式組合自己需要的模組。

新模型帶來什麼

SpeechTranscriber 背後的轉錄模型是 Apple 專為此框架開發的全新裝置端模型⁴。Apple 在 WWDC 2025 強調的改進：

長音訊品質。 此模型針對持續數分鐘或數小時的轉錄訓練，而不只是短查詢。講座、Podcast、多人會議與聽寫工作階段的轉錄精度，Apple 將其定位為對標 Whisper 等級的模型。MacStories 的獨立測試顯示，在等效轉錄任務上比 MacWhisper 的 Large V3 Turbo 版本快約 2.2 倍³。

遠距音訊處理。 麥克風放在房間另一端、會議桌上有多位講者的音訊、帶有環境噪音的音訊。新模型針對這些情境訓練；SFSpeechRecognizer 較舊的模型處理起來則沒那麼從容。

即時低延遲運作。 SpeechTranscriber 的串流結果比舊框架的 SFSpeechRecognitionTask.shouldReportPartialResults 回呼到達得更快。提供即時轉錄（字幕、語音驅動 UI、聽寫）的應用程式能獲得更流暢的更新。

自動語言管理。 SpeechTranscriber(locale:) 接受一個起始 locale,但模型可在串流途中適應語言切換。舊框架要求開發者實例化每種語言的辨識器並在它們之間切換。

不增加應用程式體積。 模型隨作業系統一起提供,而非隨應用程式。採用 SpeechAnalyzer 的應用程式不需要額外打包模型權重。與在應用程式 bundle 中內建 Whisper 等級模型的對比相當顯著:具競爭力的裝置端轉錄堆疊,bundle 體積成本為零。

舊框架仍有什麼價值

SFSpeechRecognizer 在 iOS 26 中仍持續推出並運作。應用程式可能繼續使用它的三個理由:

自訂詞彙。 SFSpeechRecognitionRequest.contextualStrings 讓應用程式可以註冊一份已知關鍵字清單(專有名詞、技術術語、產品名稱),模型對這些詞彙更容易精確辨識。此功能對領域專屬應用程式的精度有顯著改善(內含藥名的醫療聽寫、含案件引用的法律應用、含零件編號的工程應用)。SpeechAnalyzer 尚未提供自訂詞彙;對於依賴此功能的應用程式而言,遷移將造成精度倒退。

較舊的 OS 支援。 SFSpeechRecognizer 適用於 iOS 10+;SpeechAnalyzer 需要 iOS 26+。目標平台為 iOS 18 及更早版本的應用程式必須使用舊框架。

既有整合運作良好。 已有穩定、經過稽核、效能良好的 SFSpeechRecognizer 整合的應用程式,沒有迫切的遷移理由。新框架的改進對新用例(長音訊轉錄、遠距音訊、多人對話)最為重要;透過舊 API 處理短語音查詢的應用程式,可能無法獲得足以證明遷移代價的收益。

何時遷移

值得指出的三個遷移觸發點:

應用程式處理長音訊。 會議錄音器、講座轉錄應用、Podcast 轉文字工具。新模型在持續音訊上的訓練是正確選擇;舊模型在長時間工作階段下會逐漸劣化。優先遷移。

應用程式需要遠距或嘈雜的音訊。 會議室轉錄、用單支遠距麥克風錄製的訪談、在帶有環境噪音的環境中擷取的音訊。新模型在這些條件下的處理明顯更好。

應用程式呈現即時轉錄 UI。 字幕浮層、聽寫介面、語音驅動的輔助 UI。SpeechTranscriber 較低的串流結果延遲讓 UI 感覺更靈敏。

不一定值得遷移的情境:

• 帶有自訂詞彙的短語音查詢(處方聽寫、法律術語)。為了詞彙功能保留 SFSpeechRecognizer;若 Apple 在未來版本加入詞彙支援,再考慮 SpeechAnalyzer。
• 需支援 iOS 18 及更早版本的應用程式。SpeechAnalyzer 僅限 iOS 26;無論如何,程式碼都需要舊框架來支援較舊的目標平台。

並行模式

對於既要支援較舊 OS 版本、又想在 iOS 26+ 上獲得新框架品質的應用程式,並行模式是正確做法:

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current)
    let analyzer = SpeechAnalyzer(modules: [transcriber])
    try await analyzer.start(inputSequence: audioInputSequence)
    for try await result in transcriber.results {
        if result.isFinal {
            handleTranscription(result.text)
        }
    }
} else {
    let recognizer = SFSpeechRecognizer(locale: .current)!
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.shouldReportPartialResults = true
    request.requiresOnDeviceRecognition = true
    let task = recognizer.recognitionTask(with: request) { result, error in
        guard let result else { return }
        handleTranscription(result.bestTranscription.formattedString)
    }
}

DictationTranscriber 是 iOS 26+ 分支的正確選擇,因為遷移目標是 SFSpeechRecognizer 用例(短查詢搭配相同的聽寫模型)。針對長音訊的應用程式,則在 iOS 26 分支中將 DictationTranscriber 換成 SpeechTranscriber。

兩個框架共存;執行時的版本檢查會根據可用性挑選正確者。彼此互不阻礙;應用程式的轉錄管線會自行調適。

隱私與語音授權介面

兩個框架共用相同的 Speech 框架權限(Info.plist 中的 NSSpeechRecognitionUsageDescription)以及相同的使用者授權流程⁵。隱私故事相同:兩個框架的語音轉錄都在裝置端進行。SpeechAnalyzer 在設計上僅在裝置端執行;SFSpeechRecognizer 在 SFSpeechRecognitionRequest 上將 requiresOnDeviceRecognition 旗標設為 true 時預設為裝置端,否則可能退回伺服器端路徑。

意涵在於:使用 SpeechAnalyzer 的應用程式仍應正確處理 Speech 授權。使用者提示、設定條目、App Store 隱私營養標籤,全部使用相同的授權機制。

對於將麥克風音訊串流給分析器的應用程式,標準的 AVAudioSession 設定仍然適用。本系列的Privacy Manifest 文章涵蓋了使用 Speech 的應用程式之 manifest 條目;兩個框架同屬相同的隱私聲明範疇。

與代理工作流的連結

SpeechAnalyzer 的裝置端模型與結構化輸出,可乾淨地與本系列的兩個模式搭配:

Foundation Models 用於應用程式內推理。 一個用 SpeechTranscriber 轉錄音訊、再用裝置端 LLM 摘要逐字稿的管線(見Foundation Models 裝置端 LLM),完全在裝置端執行。網路呼叫總數:零。第三方資料外洩:零。

App Intents 用於語音驅動動作。 接受逐字稿作為輸入的 AppIntent,可透過語音捷徑(見Accessibility as platform)或 Apple Intelligence 的動作介面叫用。Intent 的 perform 方法執行 SpeechAnalyzer 來轉錄輸入,接著分派給應用程式的邏輯。整個流程是私密且本地的。

模式很清楚:新的 Speech 框架補完了裝置端感知三角(Vision 處理影像、Foundation Models 處理語言推理、Speech 處理音訊),讓 iOS 應用程式上完全本地的 AI 功能變得可行。

此模式對 iOS 26+ 應用程式的意義

三點重點。

1. 新程式碼預設使用 SpeechAnalyzer。 現代化的模型、模組化的架構,以及在長音訊、遠距、即時表現上的改進,使其成為正確的起點。當需要支援較舊 OS 或自訂詞彙時,舊框架是備援。

2. 詞彙相依的應用程式保留 SFSpeechRecognizer。 在 Apple 為新框架加入自訂詞彙之前,依賴 contextualStrings 來提升領域專有名詞精度的應用程式應保留舊 API。兩個框架共存;按功能混用是正確模式。

3. 裝置端隱私故事從 Vision 延伸到 Speech。 圍繞 Vision 裝置端 CV 打造的應用程式,如今對音訊也擁有等效能力。再結合 Foundation Models 的推理,完整的「感知到語言」管線都可以在本地執行,不必對外洩露資料。

完整 Apple 生態系列文章:具型別的 App Intents;MCP 伺服器;路由問題;Foundation Models;執行期 vs 工具鏈 LLM 區別;三個介面;單一真相來源模式;Two MCP Servers;為 Apple 開發設計的 hooks;Live Activities;watchOS 執行期合約;SwiftUI 內部;RealityKit 的空間心智模型;SwiftData schema 紀律;Liquid Glass 模式;多平台出貨;平台矩陣;Vision 框架;Symbol Effects;Core ML 推論;Writing Tools API;Swift Testing;Privacy Manifest;Accessibility as platform;SF Pro 排版;visionOS 空間模式;我拒絕寫的內容。中樞在 Apple 生態系列。如需更廣泛的「iOS 搭配 AI 代理」脈絡,請見 iOS 代理開發指南。

常見問題

SFSpeechRecognizer 已被棄用了嗎?

Apple 並未正式棄用 SFSpeechRecognizer。它在 iOS 26 中仍持續推出並獲得支援。WWDC 2025 的定位是:SpeechAnalyzer 是新程式碼建議採用的現代化路徑;舊框架在特定情境(自訂詞彙、較舊 OS 支援)下仍是正確工具。

我可以對預先錄製的音訊檔使用 SpeechAnalyzer 嗎?

可以。SpeechAnalyzer.start(inputSequence:) 接受 AsyncSequence 的音訊緩衝區。應用程式將任何音訊來源(透過 AVAudioEngine 的麥克風、預錄檔案 URL、AVAsset 實例)包裝成 AsyncSequence 配接器後餵給分析器即可。轉錄串流不論輸入來源為何,都產生相同的 for try await result in transcriber.results 消費方式。

如果遷移,自訂詞彙會怎樣?

SpeechAnalyzer / SpeechTranscriber 目前不支援自訂詞彙。依賴此功能取得領域專屬精度的應用程式,在 Apple 加入該功能之前不應遷移那條路徑。混合做法(一般轉錄使用 SpeechAnalyzer,而對詞彙敏感的轉錄使用搭配 contextualStrings 的 SFSpeechRecognizer)在 iOS 26 上可行。

我可以在伺服器端執行 SpeechAnalyzer 嗎?

不行。SpeechAnalyzer 是僅限裝置端的框架,沒有伺服器端路徑。若需伺服器端轉錄,正確的工具是雲端 API(OpenAI Whisper API、Google Cloud Speech-to-Text、AWS Transcribe)或自架模型。Apple 框架的價值正在於裝置端隱私與每次呼叫零成本。

語言偵測如何運作?

SpeechTranscriber(locale:) 接受初始 locale。模型可自動適應串流中途的語言切換。對於語言事先已知的應用程式(本地化應用的聽寫功能),請明確指定。對於多語言情境(講者可能切換語言的會議轉錄器),自動管理是正確行為。

它在本系列其他裝置端 ML 文章中的位置為何?

SpeechAnalyzer 是裝置端感知堆疊的第三根支柱:Vision(見 Vision 框架)處理影像、Speech 處理音訊、Core ML(見 Core ML 裝置端推論)是兩者底下的引擎。Foundation Models(見 Foundation Models 裝置端 LLM)處理語言推理。三者合力構成不需網路呼叫的完整裝置端 AI 管線。

參考資料