我們對 GPT-Live-1 語音智能體 API 的初步印象
OpenAI 兩日前將全新全雙工語音模型 GPT-Live-1 推出至 API。我們在正式環境建立及營運 AI 電話智能體，因此將它接駁至真實電話號碼，並致電測試了很多次。
我們以其中一位保險客戶約 13,000 個 token 的溫熱潛在客戶資格審核腳本進行測試，當中包括必須逐字讀出的句子、嚴格的覆述規則，以及分支式後續提問。在漫長的一日內，我們進行了十多通真實電話、約 25 次模擬訪談，以及一批非結構化測試。
以下是我們的初步印象，附有逐字稿及音訊。更深入的分析將於短期內推出。
逐字稿來自我們的測試通話，並由 GPT-Live 轉錄。我們已更改姓名及可識別身分的措辭、刪減部分對話，並合併拆分的片段。時間戳記以通話開始後的秒數計算，均取自原始記錄。
自然度極為出色
GPT-Live-1 是我們接駁至電話線路後，聽過最自然的對話者。這是一次真正的重大躍進。
它在同一條持續的音訊串流中聆聽及說話，毋須分開進行轉錄與語音合成。大部分對話機制都運作良好。來電者停止說話後，約 1.3 秒便會聽到它的首段語音（中位數）；若不計電話線路傳輸，則約為 0.7 秒。我們沒有加入任何語音活動偵測或輪流發言邏輯。它能從容處理打斷情況、產生自然的附和語（「嗯哼」），並以明快而近似真人的節奏說話。
當只提供目標而非指定讀稿時，它能按對話內容調整提問，亦能自然接受修正：
無論是修正、打斷，還是來電者在通話中途改變答案，它從未失去從容。如果自然度就是全部工作，本文至此便可結束。可惜，事情並不止於此。
它未能穩定遵從指示
GPT-Live-1 對於腳本電話中至關重要的行為，未能穩定遵從指示。
不止一次，它將明確的「是」當成「否」處理，重新提出問題，或像來電者已拒絕般繼續下一步。
最持續出現的問題，是它過度按字面理解指示。我們的提示詞寫明：如來電者表示系統記錄的住房狀況不正確，便詢問對方是自置物業、租住，還是與父母同住。一名來電者說「不，我現在已擁有物業」，其實已回答了問題。模型仍然讀出選項：
部分早期異常情況源於我們的提示詞，但這種過度按字面理解的問題，在我們嘗試過的每個提示詞版本中都持續出現。任何未有明確列出的答案，都會被機械式處理，而非作出合理判斷。
它有時亦會在受壓情況下將思考過程說出口：
數字及英數字元存在風險
拼寫、地址、出生日期及身分證明號碼必須準確無誤。這正是 GPT-Live-1 語音表現問題最嚴重的範疇。
我們聽到它在英數字串中遺漏及替換字元。以下是它讀出一個虛構索償編號的情況；除了剪走靜音部分外，音訊片段未經處理。英文轉錄文字正確，但音訊多讀了一個「Y」：
俄語表現更差：「Q」在音訊及其轉錄文字中均變成了「X」。
日期亦出現同類問題。來電者以數字提供出生日期，但模型其後將它讀成一個數字：
它亦偶爾會說出本應屬於來電者的句子：
其他語言的口音
我們會在產品支援的 47 種語言中測試新語音模型。GPT-Live-1 的俄語流暢，但帶有濃厚的美式口音（相比之下，我們在正式環境運行的 TTS 語音通常聽起來如母語人士）：
我們亦測試了盧干達語。第一次通話時，它改以斯瓦希里語回答。第二次則以盧干達語說話，其自然程度超出我們對通用模型的預期，但同樣帶有濃厚的美式口音。我們尚未測試所有語言，但預計這種口音模式很可能普遍存在。對只使用英語的智能體而言，這並不重要；但對其他語言的使用情境而言，卻是一項相當重要的限制。
幾項值得留意的 API 限制
根據我們本週的發現，以下幾項 API 限制對真正投入使用的智能體尤其重要：
- 工作階段開始後，指示內容不可更改，而且上限為 16,384 個 token。
- 輸出音訊永不會停止串流——靜音亦會串流——因此，對需要分割輪次的使用情境而言，不能以「音訊已停止」作為輪次結束訊號。
- 它只能透過新的
v1/live/sessions端點使用，而我們檢查時 Azure 尚未提供支援。
目前的印象
正式環境的電話智能體必須聽起來自然，並能持續一致地遵循指令稿。GPT-Live-1 在前者表現出色，但後者仍存在一些嚴重問題。隨着時間推進，我們會進行更多測試，並繼續分享我們的發現。