![]()
500毫秒,這是人類對話中"自然感"的生死線。超過它,你會感覺對面是個機器人;低于它,用戶幾乎察覺不到延遲。谷歌Gemini 2.5 Flash Live API把語音交互壓進了這個區間,但一位開發者花了500多場真實對話才發現——真正的殺手不是推理速度,是回聲。
GoNoGo.team的創始人最初以為最難的是多智能體編排、40多個函數調用工具。結果上線后,AI面試代理頻繁打斷自己說話,像個人在空曠房間里聽到回音后愣住。問題的根源:瀏覽器自帶的回聲消除(Acoustic Echo Cancellation,AEC)在新型語音架構里完全失效。
為什么傳統方案會"失明"
傳統語音AI走"語音→文字→語音"的拼接路線,延遲通常在1-3秒。Gemini Flash Live API是原生語音到語音(speech-to-speech),音頻進、音頻出,沒有中間文本層。這意味著客戶端處理的是原始PCM數據:16kHz麥克風輸入,24kHz代理語音輸出,Base64編碼后走WebSocket傳輸。
瀏覽器端的AEC有個底層假設——"遠端音頻"必須通過``元素或Web Audio API播放,這樣瀏覽器才能追蹤參考信號。但GoNoGo的實現是手動解碼WebSocket傳來的24kHz PCM塊,用AudioContext緩沖區調度播放。瀏覽器看不到這個音頻流,自然無法消除它。
后果很荒誕:AI開口說話,筆記本揚聲器出聲,麥克風收進去,AI以為用戶在打斷自己。最優情況是它重復半句話;最差情況——作者說" constantly happened"——對話徹底崩掉。
500場對話磨出的野路子方案
開發者試過讓AI忽略自己的聲音,但語音活動檢測(Voice Activity Detection,VAD)閾值調再高也攔不住物理層面的聲波耦合。最終方案是在客戶端建立"自引用消除":把即將播放的音頻幀緩存為參考信號,與麥克風輸入做實時對齊抵消。
這相當于在瀏覽器里重寫半個AEC。對齊精度要控制在樣本級別——24kHz意味著每幀約21微秒的偏差都會漏出殘差。作者用512樣本塊(約32毫秒)處理,RMS能量檢測閾值設在0.05,低于此值直接丟棄。
更麻煩的是采樣率不匹配。輸入16kHz,輸出24kHz,重采樣本身引入延遲。GoNoGo的做法是統一在客戶端升到48kHz處理,再降回各自目標,把額外開銷壓到10毫秒以內。
被忽視的工程暗角
這個案例暴露了一個行業盲區:當語音AI從"文本中介"轉向"端到端音頻",大量瀏覽器層面的音頻基礎設施需要重建。AEC、噪聲抑制、自動增益控制(AGC)這些曾經開箱即用的功能,在WebSocket+手動解碼的架構里全部需要自研。
作者提到一個細節:測試時發現某些筆記本的揚聲器-麥克風物理隔離太差,即使軟件層面完美消除,機械振動仍會漏音。最終被迫在檢測到AI說話時,動態壓低麥克風增益——用信噪比換穩定性,這是硬件層面的妥協。
500毫秒延遲的目標達成了,但代價是團隊把一半精力花在"讓AI聽不到自己"這種基礎問題上。語音AI的競賽正在從模型能力轉向工程整合——誰能把端到端延遲、回聲消除、網絡抖動緩沖這些臟活累活打包好,誰才能讓用戶覺得"對面像個真人"。
GoNoGo現在每天處理數百場創始人面試,回聲問題基本解決。但作者留下一個未回答的疑問:當多模態模型開始同時處理語音、視覺、實時環境音,現有的音頻處理棧還有多少能復用?下一代開發者會不會在同樣的坑里再栽一次?
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.