蘋果全新 Speech 框架：SpeechAnalyzer 與 SFSpeechRecognizer 之比較

iOS 26 在既有的 SFSpeechRecognizer 之外，導入了一套全新的語音辨識框架。新 API 的主體是 SpeechAnalyzer，再加上環繞其組合而成的模組（SpeechTranscriber、SpeechDetector）¹。蘋果自己的定位是：SpeechAnalyzer 才是面向未來的路徑。它帶來全新的裝置端模型、長音訊支援、自動語言管理、足以應付即時場景的低延遲，以及一套便於日後增添更多分析類型的模組化架構。SFSpeechRecognizer 仍隨系統提供，也依然可用；繼續留在舊框架的理由只剩兩點：對舊版系統的支援，以及一處更窄的缺口——新框架長音訊 SpeechTranscriber 模型上的自訂詞彙，因為短語音的 DictationTranscriber 路徑確實可以接受 contextual strings。

本文把新舊兩套框架擺在一起對照。切入點是「何時遷移」，而不是「如何使用新 API」，因為凡是已有一套可用 SFSpeechRecognizer 整合的團隊，面對的都是同一道取捨題：新框架的現代模型與架構，值不值得付出遷移成本？還是既有的自訂詞彙投入足以讓人按兵不動？

重點摘要

• SpeechAnalyzer（iOS 26 以上）是蘋果面向當下的裝置端語音辨識框架。它負責統籌在初始化時設定好的分析模組；iOS 26 隨附三個模組：SpeechTranscriber（長音訊）、DictationTranscriber（短語音，對應原先的 SFSpeechRecognizer 場景）與 SpeechDetector（語音活動偵測，必須與某個轉錄模組搭配使用）²。
• 新框架是圍繞長音訊打造的：講座、會議、多人對話。它完全在裝置端執行，自動處理各語言地區的模型資源，並搭載蘋果自研的新模型；據報導，在同等轉錄工作上，該模型比 Whisper Large V3 Turbo 快 2 倍³。
• SFSpeechRecognizer 仍持續提供且可用——而且自訂詞彙已不再是它的專利。新框架的 AnalysisContext.contextualStrings（透過 SpeechAnalyzer.setContext(_:) 設定）可為 DictationTranscriber 路徑註冊最多 100 條領域專用片語⁶。剩下的缺口是長音訊的 SpeechTranscriber 模型，它不接受 contextual strings。
• 遷移是按功能推進的，不是全有或全無。需要長音訊轉錄、更低延遲或更佳遠場音質的 App，應遷移到 SpeechAnalyzer。在自訂詞彙上已有投入的 App，也可以用 DictationTranscriber 搭配 contextual strings 遷移短語音聽寫；唯有「長音訊轉錄加自訂詞彙」這個組合，才仍然構成保留舊 API 的理由。
• 本系列的 Vision 框架一文介紹了蘋果另一項裝置端感知基元；SpeechAnalyzer 則把同樣的裝置端、不上雲模式延伸到音訊。

架構：分析器加模組

SpeechAnalyzer 本身並不負責轉錄。它是一個協調者，管理一次音訊分析工作階段，並把音訊緩衝區分派給一個或多個模組²。模組透過 init(modules:) 初始化方法在建立時設定完成，分析則從以 start(inputSequence:) 送入一連串 AnalyzerInput 值的 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。 針對長音訊（講座、會議、多人對話）設計的語音轉文字模組。它回傳串流結果，內含逐詞的時間資訊、信心分數，以及一個供 App 透過 for try await 取用的 results AsyncSequence。每筆結果都帶有 isFinal 旗標，用來區分尚未穩定的暫時假設與已定稿的文字。

DictationTranscriber。 針對舊有 SFSpeechRecognizer 使用情境的對應替代品：短語音轉錄，採用與 SFSpeechRecognizer 相同的裝置端模型。為了短查詢而從 SFSpeechRecognizer 遷移的 App 應選 DictationTranscriber；為了長音訊錄製而採用新框架的 App 則選 SpeechTranscriber。這項區分之所以重要，是因為 SpeechTranscriber 與 DictationTranscriber 的語言涵蓋範圍不同，走的模型路徑也不同。

SpeechDetector。 負責語音活動偵測。它會在音訊串流中語音開始與結束時回報事件。這個偵測器無法單獨執行，必須與同一個 SpeechAnalyzer 實例中的某個轉錄模組搭配。App 可藉此限縮轉錄的運算量（不去轉錄無聲片段），或用來驅動介面提示（例如「請開始說話」的指示）。

模組化架構正是相較於 SFSpeechRecognizer 的結構性改進。舊 API 把設定、緩衝區處理與結果傳遞全塞進 recognizer 與 request 這一對物件裡，還得仰賴使用者在「設定」中啟用語言；新 API 則把工作階段的協調者與分析模組拆開，App 需要什麼就組合什麼。

新模型帶來了什麼

SpeechTranscriber 背後的轉錄模型，是蘋果專為這套框架開發的全新裝置端模型⁴。蘋果在 WWDC 2025 強調的改進包括：

長音訊品質。 這個模型針對數分鐘乃至數小時的持續轉錄訓練，而不只是短查詢。講座、Podcast、多人會議與聽寫情境的轉錄準確度，被蘋果拿來與 Whisper 等級的模型相提並論。MacStories 的獨立測試量得，在同等轉錄工作上它比 MacWhisper 的 Large V3 Turbo 版本快約 2.2 倍³。

遠場音訊處理。 擺在房間另一頭的麥克風、多人圍坐的會議桌音訊、夾雜環境噪音的音訊。新模型正是針對這些條件訓練的；SFSpeechRecognizer 的舊模型處理起來就吃力得多。

即時低延遲運作。 SpeechTranscriber 的串流結果，比舊框架 SFSpeechRecognitionRequest.shouldReportPartialResults 的回呼來得更快。凡是要在介面上呈現即時轉錄的 App（字幕、語音驅動的介面、聽寫），都能得到更流暢的更新。

自動語言管理。 蘋果在此處的說法（這是我的轉述，並非他們的用語）指的是模型與資源管理，而不是在串流中途切換語言。系統會透過 AssetInventory 下載並安裝該語言地區所需的模型資源，App 不必再自行打理各語言的模型可用性。單一轉錄器實例一次仍然只處理一個語言地區——這點與舊框架相同——但過去讓多語言支援變得麻煩的資源管線，如今歸系統負責。

不增加 App 體積。 模型隨系統提供，而非隨 App 打包。採用 SpeechAnalyzer 的 App 無須再夾帶額外的模型權重。與把 Whisper 等級模型塞進 App 套件相比，差別相當可觀：一套具競爭力的裝置端轉錄能力，佔用的套件容量是零位元組。

舊框架仍具備的優勢

SFSpeechRecognizer 在 iOS 26 中仍持續提供且可用。App 繼續使用它的理由有三：

長音訊上的自訂詞彙。 SFSpeechRecognitionRequest.contextualStrings 讓 App 得以註冊一份已知關鍵字清單（專有名詞、專業術語、產品名稱），使模型更有機會正確辨識。這項能力能大幅提升領域專用 App 的準確度（含藥品名稱的醫療聽寫、含判例引用的法律 App、含零件編號的工程 App）。新框架針對聽寫路徑也有自己的對應機制：AnalysisContext.contextualStrings 最多接受 100 條依標籤分組的片語，透過 SpeechAnalyzer.setContext(_:) 設定到分析器上；在那裡註冊的片語，即使不在系統詞彙表中也能被辨識出來⁶。此外，DictationTranscriber 還能透過 ContentHint.customizedLanguage(modelConfiguration:) 這個內容提示接受自訂語言模型設定⁷。目前尚無對應做法的，是長音訊 SpeechTranscriber 模型上的 contextual strings——因此若某個 App 需要在長音訊轉錄上使用自訂詞彙，遷移這條路徑反而會造成功能退步。

舊版系統支援。 SFSpeechRecognizer 自 iOS 10 起可用；SpeechAnalyzer 則需要 iOS 26 以上。以 iOS 18 及更早版本為目標的 App 仍然需要舊框架。

已經運作良好的整合。 若 App 中的 SFSpeechRecognizer 整合穩定、經過稽核、效能也達標，就沒有急著遷移的理由。新框架的改進主要在新情境上見效（長音訊轉錄、遠場音訊、多人對話）；那些透過舊 API 處理簡短語音查詢的 App，收穫未必抵得過遷移成本。

何時該遷移

有三個值得點名的遷移訊號。

App 要處理長音訊。 會議錄音工具、講座轉錄 App、把 Podcast 轉成文字的工具。新模型在持續音訊上的訓練正好對路；舊模型則會隨著工作階段拉長而退化。這類情境應優先遷移。

App 需要處理遠場或吵雜的音訊。 會議室轉錄、只用一支遠處麥克風的訪談錄音、在有環境噪音的場所收錄的音訊。在這些條件下，新模型的表現明顯更好。

App 要呈現即時轉錄介面。 字幕浮層、聽寫介面、以語音操作的輔助使用介面。SpeechTranscriber 串流結果的低延遲，會讓介面顯得更靈敏。

也有一些情況未必值得遷移：

• 仰賴自訂詞彙的長音訊轉錄（例如必須準確捕捉藥品名稱或判例引用的會議錄音工具）。長音訊 SpeechTranscriber 模型不接受 contextual strings，因此在蘋果補上這處缺口之前，這個組合應繼續留在 SFSpeechRecognizer 上。帶自訂詞彙的簡短語音查詢則可以乾淨俐落地遷移——DictationTranscriber 加上 AnalysisContext.contextualStrings 就足以涵蓋⁶。
• 需要支援 iOS 18 及更早版本的 App。SpeechAnalyzer 僅限 iOS 26；無論如何，程式碼庫都得為舊目標保留舊框架。

並行共存的模式

如果一個 App 既要兼顧舊版系統，又想在 iOS 26 以上享有新框架的品質，那麼讓兩者並行共存就是正確的做法：

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current, preset: .shortDictation)
    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)
    }
}

在 iOS 26 以上這個分支裡選 DictationTranscriber 是對的，因為遷移的目標正是 SFSpeechRecognizer 的使用情境（以同一套聽寫模型處理短查詢）。鎖定長音訊的 App，只需在 iOS 26 分支中把 DictationTranscriber 換成 SpeechTranscriber。

兩套框架可以並存；執行期的判斷會依可用性挑選合適的一方。彼此互不阻擋，App 的轉錄流程自會隨之調整。

隱私與語音授權面

兩套框架在授權層面有所不同。SFSpeechRecognizer 保留了它專屬的語音辨識授權：Info.plist 中的 NSSpeechRecognitionUsageDescription，加上 SFSpeechRecognizer.requestAuthorization(_:) 跳出的授權提示⁵。SpeechAnalyzer 不走這條路——用它轉錄即時音訊的 App 需要麥克風權限（NSMicrophoneUsageDescription），而要轉錄 App 手上已有的音訊則不需要別的權限。隱私方面兩者都在裝置端：SpeechAnalyzer 在設計上就僅限裝置端；SFSpeechRecognizer 則要在 SFSpeechRecognitionRequest 本身把 requiresOnDeviceRecognition 旗標設為 true 時才會在裝置端執行——這是必須明確指定的，而非預設值，否則它可能走伺服器端路徑。

這對並行共存模式的意涵是：同時執行兩套框架的 App 會背上兩套權限面——SpeechAnalyzer 分支的麥克風提示，以及舊分支的語音辨識授權——App Store 的隱私「營養標示」也應把兩者都反映出來。

對於把麥克風音訊串流送進分析器的 App，標準的 AVAudioSession 設定照常適用。本系列的 Privacy Manifest 一文介紹了使用 Speech 的 App 需要填寫的資訊清單項目；就隱私聲明而言，兩套框架適用同一套規範。

與代理工作流程的連結

SpeechAnalyzer 的裝置端模型與結構化輸出，能與本系列的兩種模式緊密銜接：

用 Foundation Models 做 App 內推理。 先以 SpeechTranscriber 轉錄音訊，再用裝置端大型語言模型（見 Foundation Models 裝置端 LLM）摘要逐字稿，整條流程完全跑在裝置上。網路呼叫總數：零。第三方資料曝露總量：零。

用 App Intents 驅動語音操作。 一個以逐字稿為輸入的 AppIntent，可以透過語音捷徑（見作為平台能力的輔助使用）或 Apple Intelligence 的操作入口呼叫。該 intent 的 perform 方法會執行 SpeechAnalyzer 轉錄輸入，再交給 App 自身的邏輯處理。整個流程既私密又在地。

歸結起來就是：新的 Speech 框架補齊了裝置端感知的三角（Vision 管影像、Foundation Models 管語言推理、Speech 管音訊），讓完全在地的 AI 功能在 iOS App 上真正可行。

這個模式對 iOS 26 以上的 App 意味著什麼

三點結論。

1. 新程式碼預設採用 SpeechAnalyzer。 現代模型、模組化架構，以及在長音訊、遠場與即時情境下更好的表現，讓它成為合適的起點。舊框架則是備案，用於必須支援舊版系統、或必須在長音訊轉錄上使用自訂詞彙的場合。

2. 仰賴詞彙的 App 依音訊長度分流。 帶自訂詞彙的短語音聽寫可以遷移：DictationTranscriber 加上 AnalysisContext.contextualStrings 就能承載這些領域用語⁶。帶自訂詞彙的長音訊轉錄，則繼續留在 SFSpeechRecognizer 上，直到 SpeechTranscriber 模型開始接受 contextual strings 為止。兩套框架可以並存；依功能混用才是正確的模式。

3. 裝置端隱私的故事從 Vision 延伸到 Speech。 那些圍繞 Vision 裝置端電腦視覺打造的 App，如今在音訊上也有了對等能力。再配合負責推理的 Foundation Models，從感知到語言的完整流程都能在本機執行，無須向第三方曝露資料。

完整的 Apple Ecosystem 系列：具型別的 App Intents；MCP 伺服器；路由的取捨；Foundation Models；執行期 LLM 與工具鏈 LLM 的區別；三個介面；單一真實來源模式；兩台 MCP 伺服器；給蘋果開發用的 hooks；Live Activities；watchOS 執行期；SwiftUI 的內部構造；RealityKit 的空間心智模型；SwiftData 的 schema 紀律；Liquid Glass 模式；多平台交付；平台矩陣；Vision 框架；Symbol Effects；Core ML 推理；採用 Writing Tools API；Swift Testing；Privacy Manifest；作為平台能力的輔助使用；SF Pro 字體系統；visionOS 空間模式；我拒絕書寫的那些題目。總覽在 Apple Ecosystem 系列。想了解 iOS 與 AI 代理結合的更廣脈絡，可參閱 iOS 代理開發指南。

常見問題

SFSpeechRecognizer 已經被淘汰了嗎？

蘋果並未正式將 SFSpeechRecognizer 標示為 deprecated。它在 iOS 26 中仍隨系統提供，也仍受支援。WWDC 2025 的說法是：對新程式碼而言，SpeechAnalyzer 是現代且建議的路徑；舊框架則適用於特定情境（長音訊轉錄上的自訂詞彙、舊版系統支援）。

我可以用 SpeechAnalyzer 處理預先錄好的音訊檔案嗎？

可以。SpeechAnalyzer.start(inputSequence:) 接受一連串 AnalyzerInput 值的 AsyncSequence，每個值包裹一段音訊緩衝區。App 可以把任何音訊來源（透過 AVAudioEngine 取得的麥克風、錄音檔案 URL、AVAsset 實例）包裝成 AsyncSequence 轉接器再送給分析器。無論輸入從何而來，轉錄串流的取用方式都是同一句 for try await result in transcriber.results。

如果遷移，自訂詞彙會怎麼樣？

這取決於遷移落在哪個轉錄模組上。聽寫路徑是支援的：透過 AnalysisContext.contextualStrings 註冊最多 100 條片語，用 SpeechAnalyzer.setContext(_:) 設定上下文，DictationTranscriber 便會使用它們⁶。長音訊的 SpeechTranscriber 模型不接受 contextual strings，因此對詞彙敏感的長音訊轉錄，應繼續留在搭配 contextualStrings 的 SFSpeechRecognizer 上，直到蘋果補上那處缺口。混合做法（一般轉錄用新框架、對詞彙敏感的長音訊路徑用舊 API）在 iOS 26 上同樣行得通。

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

不行。SpeechAnalyzer 是僅限裝置端的框架，沒有伺服器端路徑。若要在伺服器端做轉錄，合適的工具是雲端 API（OpenAI Whisper API、Google Cloud Speech-to-Text、AWS Transcribe）或自行架設的模型。蘋果這套框架的價值，恰恰在於裝置端隱私與單次呼叫零成本。

語言偵測是怎麼運作的？

SpeechTranscriber(locale:) 為每個轉錄器實例接受一個語言地區，而且不支援在串流中途切換語言。iOS 26 自動化的是資源那一側：AssetInventory 會下載並管理各語言地區的模型資源，因此支援多種語言不再意味著要自行打理模型可用性。對於事先已知語言的 App（例如已在地化 App 的聽寫功能），直接明確指定即可。至於多語言情境（例如說話者可能中途換語言的會議轉錄），先偵測語言或讓使用者自行選擇，再為該語言地區建立轉錄器。

這篇文章與本系列其他裝置端機器學習的文章如何銜接？

SpeechAnalyzer 是裝置端感知堆疊的第三根支柱：Vision（見 Vision Framework）處理影像，Speech 處理音訊，而 Core ML（見 Core ML 裝置端推理）則是兩者底下的引擎。語言推理由 Foundation Models（見 Foundation Models 裝置端 LLM）承擔。三者合起來，構成一條無須網路呼叫的完整裝置端 AI 流程。

參考資料