微軟 MAI 串流逐字稿登場：開口後約百毫秒出字，即時語音 AI 更接近對話
語音 AI 對話是否自然，往往先卡在「聽完多久才出字」。Microsoft AI 在 2026 年 10 月 1 日推出 MAI-Transcribe-2-Streaming，讓聲音持續進來的同時，文字也逐步出現。這項更新最有用的地方，是把即時字幕、聽寫與語音代理的等待時間往前移。
語音 AI 對話是否自然，往往先卡在「聽完多久才出字」。Microsoft AI 在 2026 年 10 月 1 日推出 MAI-Transcribe-2-Streaming，讓聲音持續進來的同時，文字也逐步出現。這項更新最有用的地方，是把即時字幕、聽寫與語音代理的等待時間往前移。
本文會進一步說明即時出字與最後定稿，並分析實際使用條件與評估方法。
不過，早一點看到文字和早一點得到正確答案仍有差別。新模型會先給暫時辨識結果，再隨後續語音修正，因此應用程式必須知道哪些文字可以先參考、哪些必須等它穩定。
百毫秒出現的是第一版辨識
依 Microsoft AI 官方公告，模型支援 60 種語言與持續的自動語言偵測，接收到音訊後略多於 100 毫秒即可產生初步文字。串流辨識就是邊接收聲音、邊輸出結果，不必每次等到一句話結束。
官方稱其在 Artificial Analysis 的最終與部分逐字稿準確率評測中排名第一。這是該評測條件的成績，不代表所有口音、環境噪音與專業名詞都能正確。中文使用者尤其應以自己的說話速度與詞彙測試。
先顯示與先執行，要用不同標準
字幕可以先顯示暫時結果，讓觀眾跟得上談話，再更新較穩定的文字。但如果代理一聽到金額就立即修改訂單，辨識後來修正時，就可能已經做錯操作。
比較合理的設計，是讓初步文字協助準備動作，等關鍵資訊穩定後才執行。例如先查出可能的訂單，等使用者說完編號與需求再確認修改。模型省下的等待時間，應該用來改善流程，不必全部拿去提前執行。
每小時音訊費用只是成本起點
Microsoft 公佈每小時音訊 0.54 美元的入門價格，期限到 2026 年底。這是語音轉文字的計費口徑，若還要讓模型理解需求、查資料或生成語音，其他服務費用要另外計算。
我會把評估放在整段對話：從開口、辨識、查詢到回答，一次完成需要多久，人工還要修多少字。對大量會議字幕或客服語音，減少修正與等待都有價值，但不能只用第一個字出現的速度當成總效能。
即時出字與最後定稿，是語音流程的兩個階段
串流轉錄的特色，是聲音還在進來時，系統就逐步提供文字。這些先出現的文字通常屬於暫定結果，後面聽到更多上下文，模型可能調整前面的辨識。例如使用者說到一半才補充否定或更正，最早顯示的片段就不能當成完整意圖。對字幕介面而言，文字修正可以自然呈現。對會執行工作指令的語音代理，則需要更明確的定稿條件。
Microsoft AI 提到首次部分文字的延遲略高於一百毫秒，這描述的是開始取得中間結果的速度，並不表示一百毫秒就完成整句辨識。最終結果還要等待更多聲音與語句結束的判斷。讀者若要比較服務，應分開看第一段文字、最後定稿與整段對話完成的時間，而不是把不同時間口徑放在同一張排行榜上。
這個區分會影響產品設計。聽寫工具可以先讓使用者看到文字，再標示已確認的句子。客服助理可以先準備可能的回答，但涉及帳務變更等行動時，應等完整需求被確認。這些是導入時的設計選擇，並非模型本身會自動處理所有業務後果。模型更快出字，代表產品有更多時間安排下一步，也代表團隊要決定哪些事可以先做。
語音代理的等待，還包含辨識之外的步驟
一段語音對話通常包含收音、聲音傳輸、轉錄、理解需求、查詢資料、產生回答與播放聲音。每個步驟都會增加等待時間。即使轉錄很快，後端訂單查詢花了兩秒，使用者仍會感到停頓。因此，評估 MAI-Transcribe-2-Streaming 時，應先知道原本流程最慢的環節，再估計這次更新可以改善多少。
可以用假設性的客服流程理解這件事：使用者詢問訂單何時送達，轉錄先抓出訂單問題，系統準備查詢。等使用者提供完整識別資訊後，再確認可查詢的資料。這種安排可能減少後續等待，但不能在資料未確認前就讀取錯誤的訂單。對話速度與資料正確性需要同時設計，單純縮短辨識時間並不足以完成可靠服務。
網路環境也會影響實際體驗。官方模型延遲是在指定測試條件下取得，使用者裝置、連線距離與聲音分段方式，都可能讓端到端等待變長。導入團隊應測量從使用者開口到文字顯示的時間，以及從說完到回答開始的時間。這些產品層級的資料，才能回答使用者是否覺得對話更順，而不只是證明模型端比較快。
六十種語言，不等於每種口音都已同樣成熟
官方宣佈支援六十種語言與自動語言辨識，這讓跨語言產品有更多選擇。自動辨識可以減少使用者手動選擇語言的步驟，但語言名稱本身不能代表所有地區口音、專有名詞和混合語句都有一致品質。臺灣使用者常在中文裡加入英文品牌、數字與縮寫，這些組合最好單獨測試。
對教育或會議紀錄產品，可以準備含有學校名稱、人名、課程術語與中英切換的音檔，先建立人工確認逐字稿，再比較模型輸出。對客服，則應加入地址、商品型號與訂單編號等真正影響後續處理的內容。一般文字辨識正確率很高，仍可能把最重要的一個數字聽錯，因此需要檢查關鍵資訊，而不是隻看整段文字的平均表現。
自動語言辨識也需要測試很短的開場、背景有人說話或使用者突然換語言的情況。聲音資訊不足時，產品可以要求確認，或在畫面上保留語言選擇。支援範圍值得關注，但正式導入的信心應來自目標使用者的樣本。官方公開評測是比較模型的起點，無法代替本地資料的驗證。
評測除了錯字，還要看能否保留工作意圖
語音辨識常用詞錯誤率衡量，把替換、遺漏與多出的詞和原稿比較。這能幫助評估整體轉錄品質，但每個錯誤造成的影響不一樣。把語助詞辨識錯，可能只是讀起來不自然。把「不要取消」漏掉否定詞，就可能改變整句意思。產品評估應同時檢查一般文字與高影響資訊。
團隊可以把樣本分成安靜環境、背景噪音、快語速與較長停頓，再記錄每類結果。若只用錄音室音檔測試，可能看不到通勤或實際電話中的問題。字幕產品還應觀察文字來回修正是否過多，因為過度跳動的字幕即使最後正確，也可能降低閱讀體驗。對話助理則要檢查是否錯把停頓當成句子結束。
評測也需要保存使用條件，包括模型版本、聲音格式與介面設定。相同音檔若用不同的分段方式送入，結果可能不同。把測試過程固定下來，才方便在模型更新後比較，也能查出問題出在收音、傳輸還是辨識。這些安排是讓公開評測數字轉成可用產品資訊的必要步驟。
公開預覽的定位，會影響正式服務安排
微軟官方文件將 MAI-Transcribe-2-Streaming 標示為公開預覽，並說明預覽功能沒有服務等級協議，也不建議用於正式生產工作。服務等級協議是供應商對可用性等服務條件的約定。這個限制對開發者很重要：模型能力可以先測試，正式服務則不能只靠展示結果就直接全面替換。
預覽階段適合用來驗證音檔品質、整合方式與使用者介面，也可以做不影響既有服務的平行測試。假設原本的字幕系統仍在運作，新模型只在內部產生比較結果，就能收集差異而不讓使用者承擔變動。等服務狀態、品質與運作條件符合需求，再決定是否安排正式遷移。
團隊需要明確區分試驗成功與正式交付。完成一次語音展示，證明的是特定環境可以運作。長時間穩定、失敗時可恢復、資料處理符合組織要求，才屬於持續服務的能力。公開預覽並不否定產品潛力，而是提醒導入者把模型驗證與服務承諾分成兩個決策。
兩種整合方式，主要差在連線管理與既有工具
官方文件提供 Realtime API 與 Azure Speech SDK 兩種方向。前者使用持續連線傳送聲音與接收結果，後者透過軟體開發工具組協助處理連線與呼叫。應用程式介面是讓程式使用服務的入口，開發工具組則是把常見整合工作包成可以使用的程式元件。選擇哪一種，需要看團隊既有架構與管理需求。
已有即時聲音流程的團隊，可能希望沿用相容的連線形式。使用 Azure Speech 其他功能的團隊，則可能更重視工具組對重連和事件處理的支援。兩者都需要測試連線中斷時的行為、重複結果是否會被插入，以及聲音送出後如何追蹤對應文字。這些問題會影響字幕是否重複，也會影響工作指令是否被執行兩次。
導入文件中的範例適合幫助開始操作，仍應依產品需求補上錯誤處理與觀察紀錄。若團隊只在本機跑通一段範例，卻沒有測試長時間連線，正式使用時就可能遇到未預期的斷線。從介面選擇開始建立可追蹤的流程，可以讓新模型的低延遲優勢真正被產品利用。
每小時零點五四美元，先算聲音量再算完整服務
官方公佈的每小時零點五四美元是音訊轉錄的介紹價格，適用安排延續到二〇二六年底。假設每月處理一千小時聲音，只看這項費率，轉錄部分約為五百四十美元。這個計算沒有加入語言模型回答、語音生成、儲存與其他服務，因此不能當成一千小時完整語音客服的總成本。
企業還要確認實際計費單位、是否包含沉默段落，以及所選資源與地區的適用條件。對會議紀錄產品，聲音長度大致接近會議時間。對客服，則可能要處理通話等待與背景聲音，實際送入服務的時間需要另外統計。從音訊量建立成本估算，比依聊天次數猜測更接近官方費率的口徑。
比較方案時，應把校對與錯誤修復的時間一起記錄。較低的轉錄費用，如果伴隨大量關鍵資訊錯誤，總服務成本可能更高。MAI 串流轉錄最值得先測的，是等待時間是否減少，同時維持必要的辨識品質。對準備正式導入的團隊，公開預覽的服務限制則是另一個必須獨立確認的條件。
整合方式與公開預覽限制可查閱 Microsoft Learn 官方文件。
常見問題
串流逐字稿會修改已經顯示的字嗎？
會，初步結果可能隨更多語音資訊修正。產品介面應區分暫時文字與已穩定文字，避免把兩者當成相同可信度。
排名第一等於中文最好用嗎？
排行榜反映指定資料集與方法。若要處理臺灣口音、多人重疊發言或中英混用，需要用實際錄音評估。
語音體驗要看完整鏈條
這次更新讓即時辨識更有機會跟上對話。開發者下一步應檢查字幕修正方式、執行時機與整體回應速度，讓更快的辨識轉成更穩定的服務。
