在快速發展的AI語音助手領域，開發者們正在突破界限，創造更加自然的對話體驗。最近一個名為 RealtimeVoiceChat 的開源專案引發了關於使AI語音互動真正接近人類對話的根本性挑戰的討論。雖然在減少延遲方面已經取得了令人印象深刻的技術成就，但社群已經確定了更深層次的對話動態問題仍需解決。
延遲挑戰
延遲——人類說話與AI響應之間的時間差——仍然是語音互動中的關鍵因素。傳統語音助手通常有至少300毫秒的最小延遲，主要是因為它們依賴於靜音檢測來確定何時響應。RealtimeVoiceChat 專案旨在即使在執行較大的本地模型時也能實現約500毫秒的響應延遲，社群指出這已接近商業應用的黃金標準。然而，這仍然無法匹配人類對話動態，在人類對話中，說話者之間的中位數延遲實際上是零毫秒——這意味著在自然交談中，人類經常會相互重疊或打斷。
「人類之間對話中，說話者之間的中位數延遲是零毫秒。換句話說，約有一半的時間，一個說話者會打斷另一個，使延遲變成負值。」
打斷悖論
RealtimeVoiceChat 系統最受討論的功能之一是其處理打斷的能力，允許使用者在AI說話時插話。該實現使用即時轉錄作為觸發器，而不是簡單的語音活動檢測，這提供了更好的準確性，但代價是略微增加了延遲。然而，社群成員指出了一個具有挑戰性的悖論：雖然我們希望AI系統能夠被打斷，但我們也不希望它們在我們說話的自然停頓期間打斷我們。這創造了一個複雜的問題，即系統必須區分使用者的思考停頓和實際的輪流結束。
自然停頓問題
討論中確定的最重要的未解決挑戰可能是處理人類語音中的自然停頓。當前的AI語音系統傾向於將任何短暫的沉默解釋為輪流發言的提示，在使用者完全表達他們的想法之前就跳入回應。這迫使使用者採用不自然的說話模式，例如使用填充詞（呃呃呃）來保持他們的發言輪次，或按按鈕來表示他們何時說完。社群提出了幾個潛在的解決方案，從特殊的等待命令到可以檢測填充詞與真正完成輪次的雙輸入流，但尚未出現完美的解決方案。
RealtimeVoiceChat 技術棧：
- 後端： Python 3.x, FastAPI
- 前端： HTML, CSS, JavaScript (原生 JS, Web Audio API, AudioWorklets)
- 通訊： WebSockets
- 容器化： Docker, Docker Compose
- 核心 AI/ML 元件：
- 語音活動檢測： Webrtcvad + SileroVAD
- 轉錄： Whisper base.en (CTranslate2)
- 輪次檢測： 自定義 BERT 模型 (KoljaB/SentenceFinishedClassification)
- LLM： 透過 Ollama 使用本地模型（預設）或 OpenAI（可選）
- TTS： Coqui XTTSv2, Kokoro, 或 Orpheus
硬體要求：
- 支援 CUDA 的 NVIDIA GPU（在 RTX 4090 上測試透過）
- 大約響應延遲：~500ms
本地處理和技術要求
RealtimeVoiceChat 系統完全在本地硬體上執行，使用開源模型處理語音互動管道的每個元件：語音活動檢測、語音轉錄、輪次檢測、語言模型處理和文字到語音合成。這種方法提供了隱私優勢並消除了對雲服務的依賴，但需要大量硬體資源。開發者目前只在 NVIDIA RTX 4090 GPU 上進行了測試，這突顯了即使這些即時AI語音互動變得更容易被開發者使用，它們仍然非常資源密集。
追求自然感覺的AI語音對話繼續成為技術和人類挑戰的迷人交叉點。雖然減少延遲和啟用打斷代表了重要進步，但輪流發言、停頓和主動傾聽的微妙動態仍然是即使最先進的系統也無法達到類人互動的領域。正如一位社群成員恰當地指出，這提供了一個機會，可能使AI通訊甚至比人類對話更好，而人類對話本身往往充滿了尷尬的打斷和誤讀的社交暗示。