面向低資源語言的AI語音技術棧選擇：以亞塞拜然語為例

2026年7月6日

每個即時語音AI演示都是用英語執行的。延遲神奇，輪換感覺像人類，供應商的定價頁面有讓CFO滿意的計算器。但當你改變一個引數——使用者實際使用的語言——你上個月做的整個技術棧評估就毫無價值了。

我在為亞塞拜然的一家金融控股公司構建AI面試平臺時發現了這一點。亞塞拜然語約有2400萬使用者，採用拉丁字母，形態清晰。它並非小眾語言，但在唯一重要的意義上屬於低資源語言：所有主要STT和語音轉語音模型的訓練語料庫中轉錄語音資料的數量。

這一事實重塑了整個架構決策：

語音轉語音模型（OpenAI Realtime、Gemini Live）提供最佳延遲和最自然的對話，但你受制於模型的語言覆蓋範圍，當它不覆蓋時無法更換元件。

級聯流水線（LiveKit、Pipecat、Vapi配合自定義供應商）允許你插入任何能找到的STT/TTS，但你需要自己處理延遲預算、語音檢測邏輯以及整合存在的亞塞拜然語語音模型。

在高資源語言中，這只是偏好問題。在低資源語言中，這是一條岔路：一條路可能根本行不通，另一條路可能只在生產環境中才能發現其糟糕表現，而那時已有真實候選人在真實電話線上。

這篇文章是我希望在我開始之前就存在的評估：實際上什麼會崩潰，在哪個技術棧中，以及適用於任何演示未涵蓋的語言的決策框架。

語音轉語音路徑——很好，直到它失效

從每個人都希望可行的選項開始：一個單模型接收音訊並輸出音訊。OpenAI Realtime和Gemini Live。無需組裝流水線，亞秒級響應，自然中斷處理免費。

吸引力是真實的。在英語中，兩者都是該領域最接近解決方案的存在。所以第一個問題不是“哪個更好”，而是“它們真的會說亞塞拜然語，還是隻是聲稱會？”

存在不同的失敗級別，供應商文件只告訴你第一級：

未列出。語言不在支援頁面上。簡單——你結束了。

列出但降級。語言“支援”，在乾淨、慢速語音上理解良好，但在電話質量音訊、地區口音、俄語程式碼切換（每個真實亞塞拜然語使用者都會做的）、領域詞彙時崩潰。這是會在生產環境中殺死你的級別，因為你的演示會透過。

不對稱。模型理解語言，但以外國口音、錯誤重音模式或漂移音系輸出。對於面試平臺，聽起來像外國人的機器人對候選人來說是可信度問題。

我的發現：

OpenAI Realtime：在級別3失敗。理解尚可，但輸出的亞塞拜然語有扭曲口音——錯誤音系、錯誤重音。對於隨便使用，可以容忍。但對於在金融機構進行面試的系統來說，是致命的：候選人在第一句話就聽出口音，這為之後的一切定下基調。沒有語音調整或發音控制可以解決——失敗在於模型，而模型不是你的。

Gemini Live：驚喜。理解和輸出質量真的很好——它透過了所有三個級別。但殺死它的是我自己分類中遺漏的第四個失敗模式：延遲。響應延遲足夠長，打破了對話節奏。在聊天介面中只是一個旋轉圖示；在語音中，候選人會想知道是否掉線，然後打斷模型，輪換從此崩潰。即時語音有嚴格的感知預算——一旦超過，其他地方的品質就不再重要。

因此，2026年中的語音轉語音得分榜：一個模型說得不好，一個說得很好但太慢。兩種失敗都無法從API端修復。這是你對語音轉語音做出的結構性賭注——當它有效時，是最佳選項；當它在任何維度上錯過你的語言時，你只能等待別人的路線圖。

這迫使你走上另一條路：自己組裝流水線。

級聯路徑——你擁有每一毫秒

如果語音轉語音對你語言無效，後備方案是經典流水線：語音活動檢測→語音轉文本→LLM→文本轉語音，由編排層拼接。賣點是控制：每個元件都可更換，所以如果一個環節不支援亞塞拜然語，你替換那個環節而不是放棄整個技術棧。

但問題在於，這個賣點假設替換部件存在。所以，在比較編排器之前，先進行元件搜尋——因為如果沒有可用的亞塞拜然語STT或TTS，編排器比較就是裝飾。

對於亞塞拜然語，2026年中，搜尋比一年前更令人鼓舞：

TTS：Azure Neural TTS多年來一直提供普遍可用的亞塞拜然語語音——主力選項，企業友好，平淡但可靠。ElevenLabs也支援亞塞拜然語，包括地區口音適應，價格更高，自然度上限明顯更高。

STT：歷史上是薄弱環節——Whisper技術上包含亞塞拜然語但其低資源效能像彩票，俄語程式碼切換會迷惑一切。當ElevenLabs的Scribe將亞塞拜然語納入99語言ASR模型，且2026年初Scribe v2增加專門針對代理用例的即時變體時，情況發生了實質性變化——即時是語音代理的硬性要求。

因此，元件存在。你從級聯技術棧得到的是使用它們的權利，而你付出的是對延遲預算的所有權。每次交接增加延遲：端點檢測、STT最終化、LLM首詞生成時間、TTS首位元組時間、它們之間的網路跳數。語音轉語音模型將這個總和隱藏在一個模型內；在流水線中，你需要工程化它——流式傳輸每個階段並重疊一切可能重疊的部分——以回到Gemini無法達到的對話閾值。

編排器選擇主要取決於你需要掌握多少工程：

Vapi：託管，最快演示，對低資源語言迫使你調整的細粒度引數（自定義STT/TTS供應商、輪換調整）控制最少。

LiveKit Agents：基礎設施級WebRTC加代理框架；控制最多，操作面最大。

Pipecat：開源流水線框架；最大靈活性，社群維護的聯結器，你自己執行一切。

我最終選擇了LiveKit。兩個配置透過測試：Deepgram STT + Cartesia TTS配合Gemini 2.5，以及全ElevenLabs流水線配合Gemini 2.5 Flash——兩者對話表現都很好。決定因素是成本：依賴本地元件的設定大約每10分鐘對話0.02美元，而ElevenLabs技術棧大約每10分鐘0.90美元——約45倍差價，當你大規模面試時就不再是理論問題。

從練習中得出的通用規則：目標語言在訓練資料中越少，你被迫在技術棧中下沉越深。高資源語言可以購買抽象層。低資源語言必須在抽象層之下構建。

評估任何演示忽略的語言的技術棧清單

將以上內容壓縮成我第一天就會執行的協議，適用於任何語言：

首先測試語音轉語音，但要對抗性測試。不是愉快路徑——電話質量的8 kHz音訊、快速語音、地區口音、本地第二語言的程式碼切換、你的領域詞彙。在四個失敗級別上評分每個模型：未列出、列出但理解降級、不對稱輸出（理解但說得差）、延遲。在供應商語言支援頁面上透過是級別零，總共四級。

如果任何級別失敗，檢查是否可以從API端修復。對於語音轉語音，答案几乎總是否定的——一個不可修復的失敗，在任何級別，都意味著這條路關閉，無論其餘部分多好。

在選擇編排器之前進行元件搜尋。找到至少一個生產可用的STT和TTS用於你的語言，並確認STT有流式/即時模式——僅批處理轉錄質量對對話無關。每隔幾個月重複此搜尋；低資源領域變化很快，去年的結論很可能過時。

預算端到端延遲，而不是每個元件。設定語音到語音目標低於約一秒，將其分配到端點檢測、STT、LLM首詞、TTS首位元組，拒絕任何不能流式的元件。單獨良好的元件組成的流水線仍然可能對話死寂。

權衡切換成本，而不僅僅是當前質量。今天的正確答案可能在下個模型更新後變得錯誤。級聯技術棧的真正產品不是質量——而是無需重建即可更換任何環節的選項。在低資源語言中，這個選項值得你為之付出的延遲工程。

元教訓：語言支援不是定價頁面上的布林值。它是失敗模式的分佈，對於世界上大多數語言，只有透過真實使用者的真實音訊進行測試，你才能知道自己落在哪裡。演示從來不是為你做的。據此構建。

此處描述的模型行為和供應商語言支援反映了我截至2026年中期的測試；兩者變化很快——在依賴它們之前請重新驗證。