AssemblyAI提出同步HTTP轉錄方案，供自建VAD團隊使用

AssemblyAI提出一種同步HTTP轉錄方式，供使用自建語音活動偵測（VAD）判斷發話結束的語音代理開發團隊採用。使用者說完後，系統將音訊片段送出，並在同一個HTTP回應中取得轉錄文字。

AssemblyAI於10月26日發布的技術文章指出，Sync適合自行管理VAD與對話流程的團隊。該公司表示，多個大型語音代理開發團隊曾要求提供這類API，但未公布團隊名稱或導入成果。

這種方式由開發團隊的VAD偵測發話開始與結束，並收集音訊。團隊將完整音訊片段送至Sync API後，無須另外查詢結果，就能在單次回應中取得轉錄文字，再交由大型語言模型（LLM）生成回答，最後透過語音合成（TTS）轉成語音。

由於採用請求與回應的架構，通話期間不必持續維持語音辨識（STT）的WebSocket連線。不過，系統必須等發話結束後才能傳送音訊，因此處理流程與說話途中就能取得轉錄結果的方式不同。

Sync不會在發話期間提供部分轉錄文字。如果團隊希望依據部分轉錄內容提早啟動LLM處理，Sync的流程便與即時串流有所不同。

若發話結束偵測不準確，音訊片段可能會截掉句尾，或包含多餘的靜音。開發團隊也需要自行管理發話邊界與對話中的插話處理。

即時串流會透過WebSocket連續傳送音訊，並在發話結束前提供部分轉錄結果。AssemblyAI在即時STT指南中建議，需要部分轉錄，或希望交由STT判斷發話何時結束的語音代理採用Universal-3.6 Pro Realtime。

Sync文件列出的預設模型則是Universal-3.5 Pro，與即時串流建議使用的Universal-3.6 Pro Realtime版本不同。

因此，比較兩種方式時，除了通訊架構，也要一併考量模型差異。Sync被定位為適合已有自建VAD與對話流程管理機制，並希望以單次發話為單位提出請求的團隊。

Sync STT文件將一次轉錄完整音訊檔案的方式，與即時接收發話中詞句的串流方式區分開來。處理簡短語音指令或已錄製的發話時，團隊可在發話結束後透過Sync取得轉錄文字。

處理時間數據需依測量範圍解讀。AssemblyAI表示，Sync在美國與歐洲的中位數（P50）處理時間約為134毫秒，這項數據只計算伺服器處理時間。

AssemblyAI另一篇技術說明提到，一段在新加坡錄製、約15秒長的示範音訊，完整回應時間約為1,900毫秒。這項數據包含音訊傳送與接收回應，測量範圍與前述伺服器處理時間不同，也不包含LLM生成回答及TTS播放所需時間，因此不等於語音代理的完整回應時間。

LiveKit的AssemblyAI整合文件說明如何將Universal-3.6 Pro串流模型接入語音代理。這份文件呈現的是串流整合方式，並未反映Sync的採用情況。

本刊先前曾報導AssemblyAI提出串接語音辨識、回答生成與語音輸出的架構。這次技術文章則進一步說明，在語音辨識階段，如何區分逐次發話的HTTP請求與即時串流。