![]()
你有沒有想過,為什么和朋友打電話如此自然,但讓AI理解你的語音卻如此困難?我們每天都在用語音交流,從早上叫醒Siri到晚上和家人通話,語音似乎是人類最直觀的交流方式。但當我們試圖讓機器也用這種方式與我們互動時,卻發現背后隱藏著巨大的技術挑戰。
最近讀到 Greylock 合伙人 Sophia Luo 的一篇深度技術分析(https://greylock.com/greymatter/voice-agents-easy-to-use-hard-to-build/),她詳細剖析了語音 AI agent 的技術架構和挑戰。作為一個在AI領域深耕多年的投資人,Sophia的觀察讓我重新思考了語音AI的復雜性。她指出了一個看似矛盾的現象:語音交互對用戶來說極其自然,但對開發者來說卻是技術棧中最難攻克的部分之一。這種反差不僅揭示了技術的復雜性,也解釋了為什么即使在AI大爆發的今天,真正高質量的語音AI產品仍然稀少。
我在過去幾年里接觸了無數AI產品,從文本生成到圖像創作,但語音AI始終給我一種"幾乎到了,但還沒有"的感覺。每次體驗那些號稱革命性的語音助手時,總會在某個關鍵時刻被延遲、誤解或者不自然的聲音打斷沉浸感。Sophia的分析讓我明白,這不是某個公司工程能力的問題,而是整個技術棧固有的復雜性造成的。從她的研究中,我看到了語音AI面臨的根本挑戰,也看到了這個領域未來的機會和方向。
語音AI技術棧的三層架構
Sophia在分析中將語音AI的技術棧分為三個層次,每一層都代表著不同的技術投入和產品策略。我覺得這個分層框架非常有啟發性,因為它揭示了不同公司選擇不同路徑的根本原因。
最底層是核心基礎設施層(Core Infrastructure)。在這一層工作的團隊需要從頭構建整個語音架構,管理從跨平臺音頻SDK到實時監控,再到邊緣環境部署的所有組件。他們還要支持檢索增強生成(RAG)、外部系統集成和特定應用邏輯。這種方法需要深厚的基礎設施和語音專業知識,但提供了最高級別的靈活性和控制能力。我理解為什么大公司愿意投入這么多資源在這一層——當你需要處理數百萬用戶的語音請求時,任何小的優化都能帶來巨大的成本節約。
中間層是框架和開發者平臺(Frameworks & Developer Platforms)。像Vapi和Retell這樣的平臺提供了減少構建自定義agent所需工作量的框架,開箱即用地提供函數調用、提示鏈和webhook支持。這些平臺深受那些不想投入工程資源從零開始構建所有必需技術基礎設施,但仍希望快速實現靈活、可配置基礎設施的團隊青睞。我觀察到越來越多的中型公司選擇這條路徑,因為它在開發速度和技術控制之間找到了很好的平衡點。
最上層是端到端應用(End-to-End Applications)。這一層的公司通常構建自己的核心基礎設施,為客戶支持、醫療保健和家庭服務等細分領域提供全方位語音agent服務,向最終客戶屏蔽技術復雜性。像Netic、Cresta、Bland和Simple這樣的團隊與最終用戶密切合作進行實施,經常接入知識庫、API和業務邏輯。在這一層,工作流集成和強大的市場推廣策略最為重要。
![]()
我認為這種分層反映了語音AI市場的成熟度。與其他AI領域不同,語音AI的技術門檻高到足以支撐多層的生態系統。每一層都有其存在的合理性,也都面臨著不同的挑戰和機會。這種多層架構也解釋了為什么語音AI領域的競爭格局如此復雜——不同層次的公司并不直接競爭,而是在各自的層次上尋找最優解。
語音AI的技術內核:看似簡單的復雜性
Sophia詳細分析了當前生產級語音系統的技術架構,大多數遵循三部分架構:語音轉文本(STT)模型、大語言模型(LLM)和文本轉語音(TTS)模型。大多數STT-LLM-TTS架構還集成了語音活動檢測(Voice Activity Detection, VAD)層來檢測用戶何時開始和結束說話。
這種看似直觀的架構背后隱藏著巨大的復雜性。我特別認同Sophia提到的一個觀點:盡管端到端語音對語音(S2S)模型是一個有前景的替代方案,能夠跳過從音頻到文本再回到音頻的中間轉換,但目前還沒有為大多數生產用例做好準備,主要是因為幻覺增加、函數調用限制、推理時間較慢和推理能力較弱。
![]()
我在實際體驗中也感受到了這種技術選擇的影響。使用STT-LLM-TTS架構的語音助手往往在理解復雜指令方面表現更好,但聲音聽起來不夠自然。而那些聲音更自然的系統,往往在處理復雜任務時表現不佳。這種權衡反映了當前技術的局限性,也指出了未來發展的方向。
![]()
Sophia指出的一個關鍵洞察是,無論使用哪種架構,提供高質量實時語音交互的根本挑戰都是復雜的,需要解決整個技術棧的問題。這讓我想起軟件工程中的一個經典難題:分布式系統的復雜性往往不在于單個組件,而在于組件之間的交互。語音AI也是如此,真正的挑戰在于讓STT、LLM和TTS這三個組件無縫協作,同時保持低延遲和高質量。
延遲:語音AI的生死線
在Sophia分析的所有技術挑戰中,延遲可能是最關鍵的一個。她提到,即使在理想條件下,WebRTC(低延遲音頻傳輸的標準)在每個方向通常會引入大約250毫秒的延遲,這就創造了大約500毫秒的基線延遲。而在后端,STT、LLM和TTS模型通常按順序調用,還可能涉及額外網絡請求的函數調用,每個步驟都會增加延遲。
我深刻理解為什么延遲對語音交互如此致命。在文本交互中,用戶可以接受幾秒鐘的等待時間,甚至會利用這個時間思考下一步操作。但在語音交互中,任何超過700毫秒的延遲都會讓對話感覺不自然,破壞交互的流暢性。這種對延遲的極度敏感性,使得語音AI的工程挑戰遠超其他AI應用。
Sophia提到的投機性技術特別有趣:一些系統會在結束檢測器完全確定用戶已完成說話之前就發送LLM請求。雖然這可能導致冗余的推理調用,但能顯著改善平均延遲。這種設計選擇體現了生產級語音agent在速度、成本和交互質量之間的持續權衡。我認為這種權衡思維是語音AI工程師必須具備的核心能力——不是追求完美,而是在各種約束條件下找到最優解。
從商業角度看,延遲問題也解釋了為什么很多語音AI公司選擇專注于特定場景。在客服場景中,用戶可能更容忍一些延遲,因為他們期望得到準確的答案。但在娛樂或社交場景中,任何明顯的延遲都會破壞體驗。這種場景差異為不同的技術選擇和商業策略提供了合理性。
![]()
函數調用編排:讓AI真正做事的關鍵
Sophia對函數調用編排(Function Calling Orchestration)的分析讓我看到了語音AI與傳統聊天機器人的根本區別。函數調用允許模型獲取數據和執行操作,但在語音環境中,這變得異常復雜。語音agent必須不僅決定調用哪個函數,還要確定調用順序、參數設置以及何時暫停等待用戶輸入——所有這些都要在嚴格的延遲約束和非確定性環境中完成。
我特別關注Sophia提到的函數調用類型:呼叫轉接決策、升級到人工agent、數據查找、多步任務和復雜分支工作流。這些功能看似簡單,但實際實現起來極其困難。想象一下,一個語音助手需要決定是否將客戶轉接給人工客服。它不僅要理解客戶的問題復雜性,還要評估自己解決問題的能力,同時考慮當前的業務規則和客戶等待時間。這種決策需要的不僅是技術能力,還有對業務邏輯的深度理解。
我在觀察不同語音AI產品時發現,函數調用編排能力往往是區分產品質量的關鍵因素。那些只能進行簡單對話的語音助手很快就會讓用戶失去興趣,而能夠實際完成任務的語音agent才有持久的價值。但后者的技術復雜性要高出幾個數量級。這也解釋了為什么大多數成功的語音AI公司都選擇專注于特定的垂直領域——只有深入理解特定場景的業務流程,才能設計出有效的函數調用編排策略。
從產品設計角度,函數調用編排也對用戶體驗提出了新要求。用戶需要理解語音助手的能力邊界,知道什么任務可以通過語音完成,什么任務需要其他方式。這種用戶教育比傳統軟件更加復雜,因為語音交互的自然性會讓用戶高估系統的能力。如何在保持交互自然性的同時,清晰傳達系統邊界,是語音AI產品設計的核心挑戰之一。
![]()
幻覺和護欄:語音AI的安全邊界
Sophia強調,在高風險或受監管領域避免幻覺至關重要,特別是當語音agent處理醫療保健、金融和其他高度監管行業的敏感工作流時。這讓我想到語音AI面臨的一個獨特挑戰:錯誤的代價更高。
在文本交互中,用戶可以仔細閱讀和驗證AI的回復。但在語音交互中,信息傳遞的速度和方式都不利于用戶進行實時驗證。用戶更容易被語音的權威性所影響,特別是當AI的聲音聽起來專業和自信時。這種心理效應使得語音AI的幻覺問題比文本AI更加危險。
Sophia指出的語音特定錯誤特別值得關注:發音錯誤、不當語調或語音改變。我注意到這些問題往往比內容錯誤更容易被用戶察覺和記住。一個發音錯誤可能會立即破壞用戶對系統專業性的信任,即使系統在其他方面表現完美。這種對語音質量的高敏感性,要求語音AI系統在護欄設計上比文本系統更加嚴格。
我認為護欄設計將成為語音AI公司的核心競爭力之一。不同行業和應用場景需要不同類型的護欄,這為專業化公司創造了機會。一個專注于醫療領域的語音AI公司,需要對醫療術語、診斷流程和法規要求有深入理解,才能設計出有效的護欄系統。這種專業化要求也解釋了為什么通用語音AI很難快速占領所有市場。
從技術實現角度,語音護欄的實時性要求也帶來了獨特挑戰。與文本系統不同,語音系統無法在生成完整回復后再進行檢查,而必須在生成過程中實時監控和調整。這要求護欄系統具備與語音生成同樣的低延遲特性,技術復雜度進一步提升。
![]()
中斷和暫停:模擬人類對話的復雜性
Sophia對中斷和暫停處理的分析讓我深刻理解了為什么自然對話如此難以模擬。處理"嗯"、"是的"、"等等"、"不"和重疊語音等中斷,以及區分用戶是在與agent說話還是與房間里其他人說話,需要的不僅僅是基本的語音活動檢測。
我特別認同她提到的狀態管理復雜性:AI必須檢測到中斷發生了,理解中斷期間說了什么,確定是否暫停、修訂或丟棄之前的回復。它還需要保留上下文,比如知道自己剛才在說什么,并決定是恢復原來的思路、轉向用戶引入的新話題,還是并行管理兩者。這需要精確的實時校準和復雜的狀態管理來跟蹤和優先處理對話線程。
我在日常對話中意識到,人類處理這些情況是如此自然,以至于我們很少意識到其復雜性。但當我試圖從技術角度分析時,發現這需要多層次的認知處理:語音識別、語義理解、意圖判斷、上下文管理和響應策略選擇。每一層都可能出錯,而錯誤會快速累積,導致對話體驗的崩潰。
Sophia區分了半雙工系統(一次只能有一方說話)和全雙工系統(雙方可以同時說話)的差異,后者需要更高級的重疊語音和輪流處理。我認為這種技術選擇反映了產品策略的差異。半雙工系統更容易實現,但用戶體驗不夠自然。全雙工系統提供更自然的體驗,但技術復雜度和成本都大幅提升。
從商業應用角度,中斷處理能力往往決定了語音AI在特定場景下的可用性。在客服場景中,用戶經常需要打斷AI提供額外信息或糾正理解錯誤。如果系統無法優雅地處理這些中斷,用戶會快速轉向人工客服,語音AI的價值就大打折扣。這也解釋了為什么很多語音AI公司在某些場景下選擇保留人工備選方案。
![]()
語音細節:魔鬼就在細節中
Sophia提到的語音細節處理讓我意識到,語音AI面臨的挑戰遠超我之前的認知。處理口音、不常見的名字、電話號碼、地址和品牌術語在嘈雜環境中仍然容易出錯。她舉的例子特別生動:汽車經銷商的語音agent應該正確發音汽車品牌,但這不是TTS模型自動編碼的功能。其他例子包括說"9-1-1"而不是"九百一十一",或者"MIT"而不是"mitt"。
這些看似微小的細節卻可能決定用戶體驗的成敗。我想象一個客戶致電汽車經銷商咨詢"BMW"信息,但語音AI卻發音成"B-M-W"或其他錯誤讀音,客戶會立即質疑這個系統的專業性。這種細節錯誤的影響遠超其比例,因為它們直接影響用戶對系統可信度的判斷。
我特別關注Sophia提到的上下文相關性。同樣是"911",在緊急情況下應該讀作"nine-one-one",在歷史討論中可能讀作"nine eleven",在地址中可能讀作"nine hundred eleven"。這種上下文理解需要的不僅是語音技術,還有對應用場景的深度理解。這也解釋了為什么通用語音AI很難在所有場景下都表現完美。
從技術實現角度,這些細節處理需要大量的特殊化工作。每個行業、每個應用場景都有自己的術語、縮寫和發音習慣。這種特殊化需求為專業語音AI公司創造了護城河,也解釋了為什么語音AI市場會出現大量垂直化的產品。一個在醫療領域深耕的語音AI公司,會對醫療術語的正確發音投入大量精力,這種投入很難被通用系統快速復制。
我也注意到,這些細節問題往往在演示環境中不明顯,但在真實使用中會被放大。這給語音AI的銷售和推廣帶來了挑戰——如何在有限的演示時間內展示系統在這些細節方面的能力?這也要求買方在評估語音AI系統時,必須進行足夠真實和全面的測試。
![]()
背景噪音和多說話者檢測:現實世界的復雜性
Sophia強調,區分用戶的聲音和其他說話者或環境噪音對于準確的轉錄和理解至關重要。現實世界環境很少提供干凈的音頻,而強健的說話者分離(diarization)在許多生產設置中仍然是一個未解決的問題。
我深刻理解這個挑戰的現實意義。在辦公室環境中,語音AI需要區分用戶的指令和背景的同事對話。在家庭環境中,它需要知道用戶是在和它說話,還是在和家人交流。在客服場景中,它可能需要處理用戶在嘈雜環境中的來電。每種環境都有其獨特的聲學特征和挑戰。
Sophia提到的交互式語音應答(IVR)系統、等待音樂和其他非語音音頻的處理,讓我意識到語音AI面臨的挑戰遠不止理解人類語音。在實際應用中,語音AI經常需要與現有的電話系統集成,處理各種音頻信號。這種集成能力往往決定了語音AI在傳統業務環境中的可用性。
我特別關注多說話者場景的復雜性。在電話會議或多人對話中,語音AI需要識別誰在說話,理解對話的結構,甚至可能需要分別回應不同的說話者。這種能力對于會議助手、電話客服等應用至關重要,但技術實現極其困難。當前大多數語音AI系統都避免或簡化了這些場景,這也限制了它們的應用范圍。
從產品設計角度,背景噪音處理能力直接影響了產品的可用場景。一個只能在安靜環境中工作的語音助手,其應用場景會大大受限。而一個能在嘈雜環境中穩定工作的系統,則可以應用于更廣泛的場景。這種能力差異也解釋了為什么一些語音AI公司選擇專注于特定的使用環境,比如車載場景或家庭場景。
![]()
持久的基礎設施需求:語音AI的技術底座
Sophia的分析中最有價值的部分之一是對持久基礎設施需求的識別。她指出,無論團隊是從頭構建語音agent、利用開發者平臺和框架,還是部署完全托管的應用程序,某些基礎設施能力都是基礎性的。
她特別強調的可靠性和質量需求讓我看到了語音AI的技術門檻。在實踐中,可靠性和質量體現在三個方面:實際語音本身的質量、對話內容和上下文記憶、以及對話流程和流可靠性。每個方面都需要專門的技術解決方案和持續的優化。
我特別認同她對語音特定幻覺的關注:意外笑聲、品牌名稱或實體的發音錯誤、電話和賬號錯誤念讀,或縮寫發音錯誤。這些問題看似微小,但在專業環境中可能造成嚴重后果。想象一個銀行的語音助手錯誤地念出客戶的賬號,或者醫療助手錯誤發音藥物名稱,這種錯誤的影響遠超技術層面。
Sophia提到的對話流程和流可靠性也特別重要。語音agent需要避免尷尬的暫停、中斷或輪流出錯。同樣重要的是底層流可靠性,包括處理丟包、重連和抖動等問題。我觀察到,這些較低級別的問題雖然經常被忽視,但能實質性地降低感知的語音agent質量和響應性。
從商業角度看,這些基礎設施需求創造了顯著的技術壁壘。不是每個公司都有能力和資源來解決這些底層技術問題,這為專業的基礎設施提供商創造了機會。同時,這些需求也解釋了為什么語音AI領域的整合程度相對較低——技術復雜性使得垂直整合變得困難和昂貴。
我也注意到,這些基礎設施需求在高度監管的行業中變得更加嚴格。在金融服務和醫療保健等領域,安全和合規標準是不可妥協的。這種監管要求進一步提高了技術門檻,也為那些能夠滿足這些要求的公司創造了護城河。
安全和合規:語音AI的信任基礎
Sophia特別強調了在高度監管環境中的安全和合規要求,這讓我深刻理解了語音AI商業化面臨的挑戰。與文本AI不同,語音AI的錯誤更難發現和糾正,這使得安全性變得更加關鍵。
我特別關注語音數據的隱私保護問題。語音包含了大量個人信息,不僅包括說話內容,還包括口音、情緒狀態、健康狀況等敏感信息。如何在提供有效服務的同時保護這些隱私信息,是語音AI公司必須解決的核心問題。這種隱私保護需求也推動了邊緣計算和本地處理技術的發展。
合規要求在不同行業有顯著差異。醫療行業需要符合HIPAA等健康信息保護法規,金融行業需要滿足反洗錢和客戶識別要求,政府部門有自己的安全標準。每種要求都需要特定的技術解決方案和流程設計。這種復雜性解釋了為什么很多語音AI公司選擇專注于單一行業。
我也觀察到,合規要求往往與用戶體驗形成張力。更嚴格的安全措施通常意味著更復雜的驗證流程和更保守的AI行為,這可能影響交互的自然性和效率。如何在安全和體驗之間找到平衡,是語音AI產品設計的關鍵挑戰。
從技術架構角度,安全和合規要求推動了語音AI系統設計的演進。傳統的云端處理模式在某些場景下可能無法滿足數據本地化要求,這推動了混合部署和邊緣計算的采用。這種技術演進也為基礎設施提供商創造了新的商業機會。
我對語音AI未來的思考
基于Sophia的深度分析和我自己的觀察,我認為語音AI正處在一個關鍵轉折點。技術的復雜性確實很高,但正是這種復雜性創造了持久的競爭優勢和商業機會。
我預測語音AI領域會出現明顯的分層和專業化趨勢。底層基礎設施將由少數幾家技術實力雄厚的公司主導,中間層框架會出現多家專業化提供商,應用層則會高度分散和垂直化。這種結構類似于云計算的發展模式,但語音AI的技術門檻更高,分層會更加明顯。
我特別看好在特定垂直領域深耕的語音AI公司。醫療、法律、金融等專業領域有著獨特的術語、流程和合規要求,這些領域的語音AI需要深度的行業知識和長期的積累。通用系統很難快速進入這些領域,這為專業化公司創造了護城河。
從技術發展趨勢看,我認為端到端語音模型(S2S)最終會成為主流,但這個過程可能比預期更長。當前的STT-LLM-TTS架構雖然復雜,但在可控性和可靠性方面有優勢。在商業應用中,可靠性往往比自然性更重要,這延緩了S2S模型的采用速度。
我也看到了邊緣計算在語音AI中的巨大潛力。隨著專用AI芯片的發展和模型壓縮技術的進步,在設備端運行高質量語音AI變得越來越可行。這不僅能解決延遲和隱私問題,還能降低運營成本。我預期未來幾年會看到更多混合架構的出現,將部分處理遷移到邊緣設備。
最后,我認為語音AI的發展會推動整個AI產業的技術進步。語音交互對實時性、可靠性和自然性的極高要求,迫使技術提供商在算法優化、硬件加速、系統架構等方面不斷創新。這些創新最終會惠及整個AI生態系統。
語音AI可能是最難做的AI應用之一,但也可能是最有價值的。當我們最終突破技術障礙,實現真正自然、可靠、實用的語音交互時,它將徹底改變人們與技術的關系。那時,Sophia分析的這些技術挑戰將成為行業發展的重要里程碑。
結尾
也歡迎大家留言討論,分享你的觀點!
覺得內容不錯的朋友能夠幫忙右下角點個贊,分享一下。您的每次分享,都是在激勵我不斷產出更好的內容。
歡迎關注深思圈,一起探索更大的世界。
![]()
![]()
![]()
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
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.