1. 從一場(chǎng)展會(huì)聊起對(duì)話式 AI 為什么突然“卷”進(jìn)了所有硬件今年逛完 AWE 的展館我最大的感受不是某款電視有多薄、某臺(tái)冰箱有多智能而是一個(gè)幾乎被所有廠商掛在嘴邊的詞——對(duì)話式 AI。從掃地機(jī)器人到智能眼鏡從車載中控到廚房電器甚至一把電動(dòng)牙刷的展臺(tái)都在講“你可以直接跟它說(shuō)話”。這個(gè)信號(hào)非常明確對(duì)話式 AI 正在從手機(jī)和音箱這兩個(gè)“老陣地”快速滲透到每一個(gè)你能想到的終端硬件里。這件事的本質(zhì)是什么說(shuō)白了過(guò)去十年我們和硬件的交互方式基本沒變過(guò)——按鈕、觸屏、遙控器。而對(duì)話式 AI 要做的事情是把“人適應(yīng)機(jī)器”變成“機(jī)器適應(yīng)人”。你不需要學(xué)任何操作邏輯張嘴說(shuō)就行。這個(gè)變化聽起來(lái)簡(jiǎn)單但背后牽扯的技術(shù)鏈條非常長(zhǎng)語(yǔ)音喚醒、降噪拾音、語(yǔ)音識(shí)別、語(yǔ)義理解、對(duì)話管理、技能調(diào)度、語(yǔ)音合成每一個(gè)環(huán)節(jié)都要在資源受限的硬件上跑通。我寫這篇東西不是要復(fù)述展會(huì)上那些漂亮的宣傳語(yǔ)而是想從一個(gè)實(shí)際做過(guò)多款語(yǔ)音交互產(chǎn)品的人的角度把“對(duì)話式 AI 進(jìn)硬件”這件事拆開講清楚。如果你正在做智能硬件的產(chǎn)品定義、技術(shù)選型或者只是好奇為什么今年所有廠商都在押注這個(gè)方向那這篇內(nèi)容應(yīng)該能給你一些實(shí)在的參考。我會(huì)聊技術(shù)架構(gòu)怎么搭、端側(cè)和云側(cè)怎么分工、不同品類的硬件各自面臨什么坑以及我在實(shí)際項(xiàng)目中踩過(guò)的那些教訓(xùn)。2. 對(duì)話式 AI 進(jìn)硬件的整體架構(gòu)設(shè)計(jì)思路2.1 為什么不能直接把手機(jī)上的方案搬到硬件上很多人第一反應(yīng)是手機(jī)上語(yǔ)音助手已經(jīng)跑得很成熟了直接移植到其他硬件不就行了我一開始也這么想過(guò)實(shí)際做下來(lái)發(fā)現(xiàn)完全不是一回事。手機(jī)有強(qiáng)大的 SoC、充足的內(nèi)存、穩(wěn)定的網(wǎng)絡(luò)連接還有用戶已經(jīng)養(yǎng)成的“對(duì)著手機(jī)說(shuō)話”的習(xí)慣。但換成一個(gè)智能門鎖、一個(gè)車載后視鏡、甚至一個(gè)咖啡機(jī)情況就完全不同了。最核心的矛盾在于資源約束。一顆用于智能家居設(shè)備的 MCU可能只有幾百 KB 的 RAM 和幾 MB 的 Flash你不可能把一個(gè)大模型或者完整的語(yǔ)音識(shí)別引擎塞進(jìn)去。另一個(gè)矛盾是場(chǎng)景差異。手機(jī)語(yǔ)音助手的典型場(chǎng)景是用戶主動(dòng)喚醒、安靜環(huán)境、近距離說(shuō)話但一個(gè)廚房電器的場(chǎng)景可能是油煙機(jī)轟鳴、用戶手上沾著面粉、站在兩米外喊話。這兩個(gè)場(chǎng)景對(duì)拾音和識(shí)別的技術(shù)要求天差地別。所以對(duì)話式 AI 進(jìn)硬件的架構(gòu)設(shè)計(jì)第一步不是選模型而是明確場(chǎng)景約束。我通常會(huì)從四個(gè)維度來(lái)評(píng)估算力預(yù)算、功耗預(yù)算、網(wǎng)絡(luò)條件、交互距離。這四個(gè)維度決定了你的技術(shù)方案能走多遠(yuǎn)。2.2 端云協(xié)同哪些活必須在本地干哪些可以丟到云上目前行業(yè)里比較務(wù)實(shí)的做法是端云協(xié)同但具體怎么切分不同團(tuán)隊(duì)的做法差異很大。我的經(jīng)驗(yàn)是遵循一個(gè)原則跟實(shí)時(shí)性和隱私相關(guān)的放端側(cè)跟復(fù)雜語(yǔ)義和內(nèi)容生成相關(guān)的放云側(cè)。具體來(lái)說(shuō)端側(cè)必須搞定的是這幾件事喚醒詞檢測(cè)這個(gè)必須本地跑因?yàn)樾枰?7×24 小時(shí)監(jiān)聽如果一直往云端傳音頻流帶寬和功耗都受不了。常用的方案是輕量級(jí)的關(guān)鍵詞識(shí)別模型參數(shù)量控制在幾十 KB 到幾百 KB 之間。前端信號(hào)處理包括降噪、回聲消除、波束成形、自動(dòng)增益控制。這些算法必須在本地實(shí)時(shí)完成否則上傳的音頻質(zhì)量太差云端識(shí)別率會(huì)慘不忍睹。語(yǔ)音活動(dòng)檢測(cè)VAD判斷用戶什么時(shí)候開始說(shuō)話、什么時(shí)候說(shuō)完這個(gè)也必須在本地做不然會(huì)傳大量無(wú)效音頻上去。云側(cè)負(fù)責(zé)的是大詞匯量連續(xù)語(yǔ)音識(shí)別把音頻轉(zhuǎn)成文字這個(gè)需要大模型端側(cè)跑不動(dòng)。自然語(yǔ)言理解與對(duì)話管理理解用戶意圖、維護(hù)多輪對(duì)話狀態(tài)、決定下一步動(dòng)作。內(nèi)容生成與技能調(diào)度調(diào)用各種服務(wù)接口生成回復(fù)內(nèi)容。語(yǔ)音合成把回復(fù)文字轉(zhuǎn)成自然語(yǔ)音雖然現(xiàn)在端側(cè) TTS 也有輕量方案但音質(zhì)和自然度還是云端更好。注意端云切分不是一成不變的。如果你的硬件有 4G/5G 常連能力且用戶不介意延遲可以多往云側(cè)放如果是離線場(chǎng)景或者對(duì)隱私極度敏感端側(cè)就要承擔(dān)更多。我見過(guò)一個(gè)做智能門鎖的團(tuán)隊(duì)因?yàn)閾?dān)心音頻上云的隱私問題硬是把小詞匯量的命令詞識(shí)別全部放在了端側(cè)云端只做兜底的復(fù)雜語(yǔ)義解析。2.3 不同品類的架構(gòu)選型差異不是所有硬件都適合同一套架構(gòu)。我按算力和場(chǎng)景把常見終端分成三檔每檔的選型邏輯完全不同檔位典型硬件算力水平推薦架構(gòu)關(guān)鍵約束輕量級(jí)智能燈控、傳感器、小家電MCU無(wú) OS 或 RTOS端側(cè)喚醒命令詞云端兜底功耗和成本極度敏感中量級(jí)智能音箱、掃地機(jī)、車載中控應(yīng)用處理器Linux/Android端側(cè)前端處理云端 ASR/NLU網(wǎng)絡(luò)穩(wěn)定性、拾音距離重量級(jí)智能座艙、機(jī)器人、AR 眼鏡高算力 SoC可跑小模型端側(cè)跑小模型云端大模型協(xié)同散熱、功耗、多模態(tài)融合這個(gè)表格是我自己在做產(chǎn)品定義時(shí)常用的一個(gè)快速判斷工具。你先把自己的硬件往里面套基本就能確定技術(shù)路線的大方向。輕量級(jí)硬件不要想著跑大模型重量級(jí)硬件也不要什么都往云端丟找到平衡點(diǎn)才是關(guān)鍵。3. 核心技術(shù)點(diǎn)拆解從拾音到出聲每一步都有坑3.1 前端拾音與降噪對(duì)話式 AI 的第一道生死關(guān)我經(jīng)常跟團(tuán)隊(duì)里新來(lái)的工程師說(shuō)一句話語(yǔ)音交互的效果七分靠拾音三分靠識(shí)別。如果前端拾音沒做好后面用再大的模型也救不回來(lái)。展會(huì)上那些演示效果很好的產(chǎn)品背后在麥克風(fēng)陣列和降噪算法上下的功夫遠(yuǎn)比宣傳材料里寫的多。麥克風(fēng)陣列的選型是第一個(gè)決策點(diǎn)。常見的有 2 麥、4 麥、6 麥甚至 8 麥方案。麥克風(fēng)越多波束成形和聲源定位的能力越強(qiáng)但成本和結(jié)構(gòu)設(shè)計(jì)難度也越高。我的經(jīng)驗(yàn)是近距離交互0.5 米以內(nèi)如手機(jī)、遙控器單麥或雙麥足夠重點(diǎn)做回聲消除。中距離交互1-3 米如音箱、廚電4 麥環(huán)形陣列是甜點(diǎn)方案能實(shí)現(xiàn) 360 度拾音。遠(yuǎn)距離交互3-8 米如車載、會(huì)議室6 麥以上線性或環(huán)形陣列配合波束成形鎖定說(shuō)話人方向。降噪這塊傳統(tǒng)方案用譜減法、維納濾波現(xiàn)在越來(lái)越多團(tuán)隊(duì)用深度學(xué)習(xí)降噪。但我要提醒一點(diǎn)深度學(xué)習(xí)降噪在穩(wěn)態(tài)噪聲如空調(diào)聲、發(fā)動(dòng)機(jī)聲下效果很好但在非穩(wěn)態(tài)噪聲如突然的敲擊聲、多人說(shuō)話下可能引入失真。實(shí)際項(xiàng)目中我通常采用傳統(tǒng)算法和深度學(xué)習(xí)混合的方案穩(wěn)態(tài)噪聲交給深度學(xué)習(xí)瞬態(tài)干擾交給傳統(tǒng) VAD 和波束成形來(lái)抑制。還有一個(gè)容易被忽視的點(diǎn)是回聲消除AEC。如果硬件本身會(huì)播放聲音比如音箱、電視那麥克風(fēng)一定會(huì)拾到自己的聲音。AEC 沒做好的話會(huì)出現(xiàn)“自己?jiǎn)拘炎约骸被蛘摺罢f(shuō)著說(shuō)著被打斷”的情況。AEC 的關(guān)鍵在于參考信號(hào)的同步精度這個(gè)在硬件設(shè)計(jì)階段就要考慮好軟件層面很難完全彌補(bǔ)。3.2 喚醒詞檢測(cè)低功耗與高召回率的平衡術(shù)喚醒詞是用戶和硬件對(duì)話的“敲門磚”。這個(gè)環(huán)節(jié)的核心指標(biāo)有兩個(gè)喚醒率和誤喚醒率。喚醒率低了用戶喊半天沒反應(yīng)體驗(yàn)極差誤喚醒率高了設(shè)備動(dòng)不動(dòng)自己激活用戶會(huì)覺得這產(chǎn)品“有病”。在資源受限的硬件上做喚醒詞檢測(cè)通常用輕量級(jí)的神經(jīng)網(wǎng)絡(luò)比如 DSCNN深度可分離卷積網(wǎng)絡(luò)或者 TC-ResNet。模型大小控制在 100KB 以內(nèi)推理一次的計(jì)算量在幾 MFLOPs 級(jí)別這樣可以在低功耗 MCU 上以 10-20ms 的幀移持續(xù)運(yùn)行。實(shí)際調(diào)參時(shí)我一般會(huì)把喚醒閾值設(shè)得稍微保守一點(diǎn)寧可讓用戶喊兩次也不要頻繁誤喚醒。因?yàn)檎`喚醒帶來(lái)的困擾遠(yuǎn)大于多喊一次的不便。另外喚醒詞的選擇也有講究音節(jié)要豐富、聲學(xué)上要容易區(qū)分、最好 3-4 個(gè)音節(jié)。兩個(gè)音節(jié)的詞太容易和日常對(duì)話混淆五個(gè)音節(jié)以上用戶又記不住。實(shí)操心得喚醒詞檢測(cè)模型一定要用目標(biāo)硬件采集的數(shù)據(jù)做微調(diào)。我見過(guò)一個(gè)團(tuán)隊(duì)用公開數(shù)據(jù)集訓(xùn)練模型在實(shí)驗(yàn)室里效果很好但裝到實(shí)際產(chǎn)品上喚醒率直接掉了一半原因就是實(shí)際產(chǎn)品的麥克風(fēng)頻響特性和數(shù)據(jù)集不匹配。后來(lái)他們補(bǔ)采了 2000 條真實(shí)場(chǎng)景數(shù)據(jù)做微調(diào)喚醒率才回到可用水平。3.3 語(yǔ)音識(shí)別與語(yǔ)義理解端側(cè)小模型和云側(cè)大模型的配合語(yǔ)音識(shí)別ASR這塊端側(cè)和云側(cè)的方案差異很大。端側(cè)通常用流式小模型詞匯量有限但延遲低、隱私好云側(cè)用大模型準(zhǔn)確率高、支持熱詞和上下文但有網(wǎng)絡(luò)延遲。我的建議是做分級(jí)策略簡(jiǎn)單命令詞如“打開”“關(guān)閉”“調(diào)高溫度”走端側(cè)復(fù)雜語(yǔ)句如“幫我找一下上周買的那本書的物流信息”走云端。端側(cè)識(shí)別置信度低的時(shí)候自動(dòng)轉(zhuǎn)云端重試。這樣既保證了常用操作的響應(yīng)速度又覆蓋了長(zhǎng)尾需求。語(yǔ)義理解NLU是對(duì)話式 AI 的“大腦”。傳統(tǒng)方案用規(guī)則模板和意圖分類模型現(xiàn)在越來(lái)越多團(tuán)隊(duì)用大語(yǔ)言模型來(lái)做。大模型的好處是泛化能力強(qiáng)用戶換個(gè)說(shuō)法也能理解壞處是推理成本高、響應(yīng)慢、有時(shí)候會(huì)“胡說(shuō)八道”。我在實(shí)際項(xiàng)目中采用的是一個(gè)混合 NLU 架構(gòu)高頻意圖用輕量級(jí)分類模型處理保證速度和穩(wěn)定性低頻、復(fù)雜意圖路由到大模型利用其泛化能力。同時(shí)在輸出層加一個(gè)約束校驗(yàn)?zāi)K確保大模型生成的回復(fù)不會(huì)超出設(shè)備的能力范圍。比如用戶說(shuō)“幫我把空調(diào)調(diào)到 30 度”如果設(shè)備最高只能到 28 度校驗(yàn)?zāi)K要能攔截并給出合理回復(fù)。3.4 語(yǔ)音合成讓硬件“說(shuō)話”自然的關(guān)鍵語(yǔ)音合成TTS經(jīng)常被忽視但它直接影響用戶對(duì)產(chǎn)品的感知。一個(gè)機(jī)械、生硬的合成音會(huì)讓用戶覺得產(chǎn)品“低端”一個(gè)自然、有情感的合成音會(huì)讓用戶覺得產(chǎn)品“聰明”。端側(cè) TTS 方案主要有兩類拼接合成和參數(shù)合成。拼接合成音質(zhì)好但占用存儲(chǔ)大參數(shù)合成靈活但音質(zhì)稍差?，F(xiàn)在也有一些輕量級(jí)的神經(jīng)網(wǎng)絡(luò) TTS 方案可以在端側(cè)跑比如基于 FastSpeech 的蒸餾版本音質(zhì)接近云端水平模型大小控制在幾 MB 以內(nèi)。云端 TTS 的優(yōu)勢(shì)在于音色豐富、情感表達(dá)強(qiáng)、支持 SSML 標(biāo)記。如果硬件網(wǎng)絡(luò)條件好我通常建議 TTS 走云端端側(cè)只做緩存和降級(jí)方案。但要注意首字延遲——用戶說(shuō)完話到聽到回復(fù)的第一個(gè)字如果超過(guò) 1.5 秒體驗(yàn)就會(huì)明顯變差。優(yōu)化方法包括流式 TTS、預(yù)取常用回復(fù)的音頻、端側(cè)緩存高頻語(yǔ)句。4. 實(shí)操落地一個(gè)中量級(jí)硬件的對(duì)話式 AI 接入全流程4.1 硬件選型與系統(tǒng)框架搭建假設(shè)我們要給一款智能廚電比如帶屏幕的烤箱接入對(duì)話式 AI。這個(gè)場(chǎng)景的特點(diǎn)是廚房環(huán)境噪聲大油煙機(jī)、攪拌機(jī)、用戶可能離設(shè)備 1-3 米、手上有油污不方便觸屏、網(wǎng)絡(luò)通常穩(wěn)定。硬件選型上我推薦這樣的配置主控四核 ARM Cortex-A53 或以上主頻 1.5GHzRAM 2GBFlash 8GB。這個(gè)配置可以跑 Linux 系統(tǒng)支持端側(cè)前端處理和輕量級(jí)喚醒詞檢測(cè)。麥克風(fēng)4 麥環(huán)形陣列間距 40-60mm信噪比 65dB 以上。環(huán)形陣列適合廚房這種用戶可能從任意方向說(shuō)話的場(chǎng)景。音頻編解碼支持 16kHz 采樣、16bit 精度最好帶硬件 AEC 加速。網(wǎng)絡(luò)Wi-Fi 2.4G/5G 雙頻保證音頻上傳的帶寬和穩(wěn)定性。揚(yáng)聲器5W 以上支持回聲消除參考信號(hào)輸出。系統(tǒng)框架上我通常分成四層硬件抽象層麥克風(fēng)陣列驅(qū)動(dòng)、音頻編解碼驅(qū)動(dòng)、網(wǎng)絡(luò)驅(qū)動(dòng)。音頻前端層AEC、降噪、波束成形、VAD、喚醒詞檢測(cè)。對(duì)話引擎層端側(cè) ASR命令詞、云端 ASR 客戶端、NLU 路由、對(duì)話管理。應(yīng)用層技能實(shí)現(xiàn)、設(shè)備控制、UI 反饋。這個(gè)分層的好處是每一層可以獨(dú)立迭代。比如前端降噪算法升級(jí)了不需要?jiǎng)訉?duì)話引擎新增一個(gè)技能只需要在應(yīng)用層加代碼。4.2 關(guān)鍵參數(shù)計(jì)算與配置示例在實(shí)際配置中有幾個(gè)參數(shù)需要根據(jù)場(chǎng)景仔細(xì)計(jì)算。我拿拾音距離和麥克風(fēng)間距的關(guān)系舉個(gè)例子。假設(shè)用戶最遠(yuǎn)在 3 米外說(shuō)話聲速 343m/s4 麥環(huán)形陣列的直徑為 60mm。要保證波束成形的有效增益麥克風(fēng)之間的最大延遲差不能超過(guò)半個(gè)采樣周期。在 16kHz 采樣下半個(gè)采樣周期是 31.25μs對(duì)應(yīng)聲程差約 10.7mm。60mm 直徑的陣列相鄰麥克風(fēng)間距約 42mm聲程差最大約 42mm遠(yuǎn)大于 10.7mm。這意味著在 16kHz 采樣下高頻部分的波束成形會(huì)有空間混疊。解決方案有兩個(gè)一是提高采樣率到 48kHz這樣半采樣周期對(duì)應(yīng)聲程差約 3.6mm空間混疊問題大大緩解二是接受一定的高頻混疊因?yàn)檎Z(yǔ)音的主要能量集中在 300-3400Hz這個(gè)頻段的波長(zhǎng)較長(zhǎng)混疊影響相對(duì)可控。我通常建議中量級(jí)硬件用 48kHz 采樣做前端處理然后在送入 ASR 之前降采樣到 16kHz。喚醒詞檢測(cè)的配置示例wake_word: engine: dscnn model_path: /opt/models/wakeword_v3.tflite threshold: 0.72 frame_length_ms: 25 frame_shift_ms: 10 min_activation_duration_ms: 200 refractory_period_ms: 1500這里的threshold是喚醒置信度閾值refractory_period_ms是喚醒后的不應(yīng)期防止連續(xù)觸發(fā)。這些參數(shù)需要根據(jù)實(shí)際測(cè)試調(diào)整沒有萬(wàn)能值。4.3 聯(lián)調(diào)過(guò)程中的典型問題與解決聯(lián)調(diào)階段是最容易出問題的。我記錄了幾個(gè)高頻問題問題一喚醒后識(shí)別不到說(shuō)話內(nèi)容。排查下來(lái)發(fā)現(xiàn)是喚醒詞檢測(cè)和 ASR 之間的音頻緩沖區(qū)沒有對(duì)齊喚醒后前 200ms 的音頻被丟棄了。解決方法是在喚醒檢測(cè)模塊和 ASR 模塊之間加一個(gè)環(huán)形緩沖區(qū)喚醒觸發(fā)時(shí)把緩沖區(qū)里的音頻一起送過(guò)去。問題二廚房噪聲下誤喚醒率飆升。油煙機(jī)的聲音頻譜和某些喚醒詞有重疊。解決方法是采集廚房噪聲數(shù)據(jù)加入訓(xùn)練集的負(fù)樣本中重新訓(xùn)練喚醒模型同時(shí)在喚醒前加一個(gè)噪聲分類器判斷當(dāng)前環(huán)境是否適合喚醒。問題三云端 ASR 返回結(jié)果延遲波動(dòng)大。有時(shí)候 300ms 就返回了有時(shí)候要 2 秒。排查發(fā)現(xiàn)是網(wǎng)絡(luò)抖動(dòng)加上云端排隊(duì)。解決方法是在端側(cè)做流式上傳不要等用戶說(shuō)完再傳而是邊說(shuō)邊傳同時(shí)在端側(cè)緩存最近幾條識(shí)別結(jié)果網(wǎng)絡(luò)不好時(shí)用端側(cè)小模型兜底。問題四TTS 播放時(shí)被自己的聲音喚醒。這是 AEC 沒做好的典型表現(xiàn)。檢查發(fā)現(xiàn)揚(yáng)聲器參考信號(hào)和麥克風(fēng)采集信號(hào)之間存在非線性失真線性 AEC 無(wú)法完全消除。解決方法是加入非線性回聲抑制模塊或者在 TTS 播放期間暫時(shí)降低喚醒靈敏度。避坑技巧聯(lián)調(diào)時(shí)一定要在真實(shí)場(chǎng)景下測(cè)試不要只在實(shí)驗(yàn)室里測(cè)。我見過(guò)太多團(tuán)隊(duì)在安靜的會(huì)議室里調(diào)好了一到用戶家里就各種問題。廚房、客廳、車內(nèi)這些場(chǎng)景的噪聲特性完全不同必須分別采集數(shù)據(jù)、分別調(diào)參。5. 不同終端品類的落地差異與選型建議5.1 智能家居成本敏感下的取舍智能家居品類最大的特點(diǎn)是成本極度敏感。一個(gè)智能燈泡的 BOM 成本可能只有十幾塊錢你不可能給它配 4 麥陣列和四核處理器。所以這個(gè)品類的對(duì)話式 AI 方案必須做極致裁剪。我的建議是只做命令詞識(shí)別不做自由對(duì)話。用戶說(shuō)“開燈”“關(guān)燈”“調(diào)亮一點(diǎn)”這些固定命令詞用幾十 KB 的模型就能搞定。云端只做兜底而且可以做成可選的——用戶不聯(lián)網(wǎng)也能用基本功能。拾音方案上單麥加軟件降噪就夠了。但要注意遠(yuǎn)場(chǎng)拾音的問題如果設(shè)備裝在墻上用戶站在 3 米外說(shuō)話單麥的信噪比會(huì)很低。這時(shí)候可以考慮在房間里放一個(gè)帶麥克風(fēng)的網(wǎng)關(guān)設(shè)備通過(guò)藍(lán)牙或 Zigbee 把語(yǔ)音指令轉(zhuǎn)發(fā)給各個(gè)設(shè)備。這樣成本分?jǐn)傁聛?lái)每個(gè)設(shè)備只增加幾塊錢。5.2 車載場(chǎng)景噪聲、多說(shuō)話人和安全約束車載是對(duì)話式 AI 落地最復(fù)雜的場(chǎng)景之一。噪聲大發(fā)動(dòng)機(jī)、風(fēng)噪、胎噪、可能有多人同時(shí)說(shuō)話、還要考慮駕駛安全不能分散駕駛員注意力。麥克風(fēng)陣列通常用 4-6 麥分布在車頂或 A 柱。波束成形要能區(qū)分主駕和副駕的聲源方向。降噪方面發(fā)動(dòng)機(jī)噪聲是穩(wěn)態(tài)的可以用自適應(yīng)濾波風(fēng)噪和胎噪是非穩(wěn)態(tài)的需要深度學(xué)習(xí)降噪。車載場(chǎng)景還有一個(gè)特殊要求響應(yīng)必須快。駕駛員說(shuō)“導(dǎo)航到某某地方”如果等 3 秒才有反應(yīng)駕駛員可能已經(jīng)錯(cuò)過(guò)了路口。所以車載方案通常把更多處理放在端側(cè)云端只做 POI 搜索和路徑規(guī)劃。端側(cè) ASR 用限定領(lǐng)域的模型覆蓋導(dǎo)航、音樂、電話、空調(diào)這些高頻場(chǎng)景。安全約束也很重要。行駛中要限制某些語(yǔ)音操作比如“打開視頻”這種會(huì)分散注意力的指令應(yīng)該被攔截。這需要在對(duì)話管理層面加一個(gè)駕駛狀態(tài)感知模塊根據(jù)車速、檔位等信息動(dòng)態(tài)調(diào)整可用技能。5.3 可穿戴與 AR 眼鏡功耗和形態(tài)的極限挑戰(zhàn)可穿戴設(shè)備耳機(jī)、手表、AR 眼鏡對(duì)對(duì)話式 AI 的要求最苛刻功耗要低、體積要小、還要保證可用性。以 TWS 耳機(jī)為例電池只有幾十 mAh你不可能讓它一直跑喚醒詞檢測(cè)。常見的做法是手機(jī)協(xié)同耳機(jī)只做最基本的 VAD 和音頻采集喚醒和識(shí)別都交給手機(jī)。但這樣又依賴手機(jī)連接脫離手機(jī)就廢了。AR 眼鏡的情況更復(fù)雜。它需要多模態(tài)融合——語(yǔ)音、手勢(shì)、眼動(dòng)、頭部姿態(tài)一起用。用戶說(shuō)“把這個(gè)窗口移到左邊”同時(shí)眼睛看向某個(gè)窗口系統(tǒng)要能理解“這個(gè)”指的是哪個(gè)。這需要語(yǔ)音和視覺的聯(lián)合理解目前還處于比較早期的階段。我的判斷是可穿戴設(shè)備的對(duì)話式 AI 在未來(lái)兩年內(nèi)還是會(huì)以手機(jī)協(xié)同為主、端側(cè)為輔。真正獨(dú)立的端側(cè)對(duì)話能力要等低功耗 NPU 和輕量級(jí)大模型進(jìn)一步成熟。6. 常見問題與排查技巧實(shí)錄6.1 喚醒率低、誤喚醒高的排查思路這是最高頻的問題。我整理了一個(gè)排查清單現(xiàn)象可能原因排查方法解決方向喚醒率低麥克風(fēng)靈敏度不足用標(biāo)準(zhǔn)聲源測(cè)頻響曲線更換麥克風(fēng)或調(diào)整增益喚醒率低喚醒詞與用戶口音不匹配采集目標(biāo)用戶口音數(shù)據(jù)測(cè)試補(bǔ)充口音數(shù)據(jù)微調(diào)模型喚醒率低環(huán)境噪聲掩蓋了喚醒詞在不同噪聲級(jí)別下測(cè)試加強(qiáng)降噪或提高喚醒閾值誤喚醒高訓(xùn)練負(fù)樣本不足分析誤喚醒時(shí)的音頻內(nèi)容補(bǔ)充負(fù)樣本重新訓(xùn)練誤喚醒高閾值設(shè)置過(guò)低統(tǒng)計(jì)不同閾值下的 ROC 曲線提高閾值犧牲部分喚醒率誤喚醒高電視/音樂中的相似詞觸發(fā)采集電視音頻做負(fù)樣本加入相似詞對(duì)抗訓(xùn)練這個(gè)表格是我在實(shí)際項(xiàng)目中反復(fù)使用的基本上 80% 的喚醒問題都能通過(guò)這個(gè)清單定位到原因。6.2 識(shí)別延遲大、響應(yīng)慢的優(yōu)化手段延遲是對(duì)話式 AI 體驗(yàn)的殺手。用戶能接受的端到端延遲從說(shuō)完到聽到回復(fù)通常在 1.5 秒以內(nèi)。超過(guò)這個(gè)值用戶就會(huì)覺得“卡”。優(yōu)化延遲要從全鏈路入手拾音階段減少音頻緩沖區(qū)大小從 200ms 降到 100ms代價(jià)是抗抖動(dòng)能力下降。VAD 階段用更激進(jìn)的端點(diǎn)檢測(cè)策略用戶停頓 500ms 就認(rèn)為說(shuō)完了而不是等 1 秒。上傳階段流式上傳邊說(shuō)邊傳不要等 VAD 觸發(fā)再開始傳。云端處理選擇離用戶近的服務(wù)節(jié)點(diǎn)減少網(wǎng)絡(luò) RTT。TTS 階段流式合成生成第一個(gè)字就返回不要等整句合成完。我實(shí)測(cè)下來(lái)這套組合拳可以把端到端延遲從 2.5 秒壓到 1.2 秒左右。但要注意每個(gè)優(yōu)化都有代價(jià)比如激進(jìn)的 VAD 會(huì)導(dǎo)致用戶說(shuō)話中途停頓被誤判為說(shuō)完。需要根據(jù)具體場(chǎng)景調(diào)平衡。6.3 多輪對(duì)話中的上下文丟失問題多輪對(duì)話是對(duì)話式 AI 的高級(jí)能力但也是最容易出問題的。用戶說(shuō)“幫我找一下附近的餐廳”系統(tǒng)推薦了幾家用戶接著說(shuō)“第二家”系統(tǒng)要能理解“第二家”指的是上一輪推薦列表中的第二個(gè)。上下文丟失通常有幾個(gè)原因?qū)υ挔顟B(tài)沒有正確保存每輪對(duì)話結(jié)束后狀態(tài)被清空了。超時(shí)設(shè)置太短用戶思考了 10 秒才回復(fù)系統(tǒng)已經(jīng)認(rèn)為對(duì)話結(jié)束了。多設(shè)備干擾用戶在家里多個(gè)設(shè)備之間切換上下文沒有同步。解決方法是在對(duì)話管理層面維護(hù)一個(gè)會(huì)話狀態(tài)機(jī)記錄最近 N 輪的意圖、槽位和實(shí)體。超時(shí)時(shí)間根據(jù)場(chǎng)景設(shè)置簡(jiǎn)單命令 5 秒復(fù)雜查詢 30 秒。多設(shè)備場(chǎng)景下會(huì)話狀態(tài)可以存在云端用用戶 ID 關(guān)聯(lián)。實(shí)操心得多輪對(duì)話的上下文不要存太多輪3-5 輪就夠了。存太多不僅占用資源還會(huì)引入噪聲。我見過(guò)一個(gè)團(tuán)隊(duì)存了 20 輪上下文結(jié)果用戶說(shuō)“好的”的時(shí)候系統(tǒng)把 20 輪前的意圖又翻出來(lái)了鬧了笑話。7. 我對(duì)這個(gè)方向的一些個(gè)人判斷做語(yǔ)音交互產(chǎn)品這些年我最大的體會(huì)是技術(shù)不是瓶頸場(chǎng)景理解才是。展會(huì)上那些演示效果驚艷的產(chǎn)品背后往往不是用了多先進(jìn)的模型而是把場(chǎng)景吃透了——知道用戶會(huì)在什么環(huán)境下說(shuō)話、會(huì)說(shuō)什么、不會(huì)說(shuō)什么、說(shuō)錯(cuò)了怎么辦。對(duì)話式 AI 進(jìn)硬件這個(gè)趨勢(shì)短期內(nèi)還會(huì)繼續(xù)“卷”。但我建議做產(chǎn)品的同行不要被“卷”帶偏了節(jié)奏。先想清楚你的硬件到底解決了用戶的什么問題對(duì)話式 AI 在這個(gè)問題里扮演什么角色然后再去選技術(shù)方案。不要為了加語(yǔ)音而加語(yǔ)音用戶不傻不好用的功能只會(huì)讓產(chǎn)品顯得更蠢。另外端側(cè)小模型的能力在快速提升。我預(yù)計(jì)未來(lái)一兩年內(nèi)中量級(jí)硬件上跑一個(gè) 1-3B 參數(shù)的對(duì)話模型會(huì)成為常態(tài)。到那時(shí)候端云協(xié)同的切分點(diǎn)會(huì)進(jìn)一步向端側(cè)偏移隱私和延遲問題都會(huì)得到改善。但現(xiàn)在這個(gè)時(shí)間點(diǎn)務(wù)實(shí)的分級(jí)策略還是最穩(wěn)妥的選擇。