
圖說:墨寒仔細聆聽,讓不確定的聲音停在猜測之前
昨天談 Realtime 時,我說真正觸發回答的應該是「確認完成的使用者句子」。今天要追問:那句文字本身就一定可信嗎?
麥克風聽見的是聲音,AI 回答需要的是文字,中間要經過語音辨識。環境有風扇聲、我的口音與專有名詞,網路也會影響處理。如果辨識把一句話聽錯,墨寒仍可能很認真地回答錯的問題。更麻煩的是,系統為了幫助辨識而提供的提示文字,有時竟可能被當成使用者說的內容送回來。
那一刻我才明白:介面顯示出一行字,不代表墨寒真的聽懂;至少還要確認這是完整結果、不是重複結果,也不像系統自己提供的提示。
為了提高人名、角色名或語言的辨識率,程式可以提供簡短提示,告訴轉錄服務可能出現哪些詞。問題是提示如果寫得太像完整命令,例如「請使用自然清晰的繁體中文,不要改寫」,某些失敗情況可能把這段話原樣當成轉錄結果。
如果程式毫無防備,墨寒就會收到一個我根本沒說過的問題,接著開始回答系統自己的說明。從使用者角度看,就像她突然自言自語。
目前的做法,是在送出前先把提示縮短,保留必要的詞彙,不讓它像一整段指令;結果回來後也會比較,如果文字高度像原始提示,就略過這一輪。這不是宣稱能識破所有誤辨識,而是先阻止一個已知而可重現的錯誤路徑。
Realtime 重視速度,但完整一句話結束後,還可以用較完整的音訊再做一次高精度整句轉錄。墨寒目前保留這條混合路徑:即時連線負責對話節奏,句子結束後的轉錄負責提供較可靠的最終文字。
我把它想成現場速記與會後校稿。速記讓人跟得上,校稿則降低關鍵字聽錯的機會。不是兩份結果都拿去問 AI,而是等待確認哪一份才是本輪最後要使用的文字。
這裡又碰到昨天的去重問題。即時事件、完成事件與外部整句結果可能先後抵達;程式必須保證同一輪只送出一次,不因為準確度提升而換來兩個回答。
混合轉錄也不是免費午餐。要保留這一輪必要的短暫音訊,再送去做整句處理,可能增加一點等待與雲端請求。程式應只保留完成本輪辨識需要的資料,不把錄音無限制累積成私人聲音資料庫;停止或失敗後也要清理狀態。使用者若更重視速度,未來仍可能需要不同選擇,但預設策略至少要把準確、等待與隱私的取捨說清楚。
語音產品很容易害怕「沒有反應」,於是遇到空白或失敗也想找點東西回答。但對一位助理而言,憑空猜測比請主人再說一次更糟。
墨寒若沒有取得有效轉錄,這一輪就不應自動觸發回答。介面可以說明沒有聽清楚或轉錄失敗,讓我重新說;不能把噪音當命令,也不能沿用上一輪文字。
這項原則對未來工具操作更重要。一般聊天答非所問只是尷尬,如果語音被誤認成「刪除檔案」或「傳送郵件」,後果完全不同。即使後面還有權限確認,輸入端仍應盡量拒絕不可靠的內容。
同時,轉錄文字應該讓使用者看得見。若墨寒答非所問,我可以先確認畫面上記錄的是不是我原本的句子;若文字就錯了,問題在耳朵,若文字正確卻回答錯了,才往理解與模型方向追。這個小小的可見性,讓非工程師也能參與除錯,不必只對著「她怪怪的」猜測。
昨天以前,我常把語言設定想成畫面文字;實際上,轉錄也需要知道主要語言。繁中與簡中同樣屬於中文,輸出的字形與後續語言規則卻不完全相同;英文則更明顯。
程式要依目前語言準備合適的辨識設定,同時避免把簡中結果再送進台灣繁中修正路徑。這不代表只要指定語言就永遠不會聽錯,而是至少不要由自己的設定主動製造錯誤。
人名、作品名與中英混說仍是最需要真實語音測試的地方。自動測試可以餵入既定文字,檢查提示不會回灌、完成事件能去重、失敗不回答;它無法替代我在不同麥克風、噪音與口音下實際開口。
我也會留意被辨識出的文字是否意外包含祕密資訊。對話與轉錄可能進入本機歷史,截圖、支援包與文章素材就不能隨便把真實內容公開。測試最好使用虛構句子;需要分享錯誤時先去識別化,而不是為了證明功能把自己的對話紀錄整包上傳。
這一篇如果只錄一段乾淨語音,看到正確文字就結束,會漏掉真正麻煩的部分。我會故意製造短音、空白、重複完成訊號、轉錄失敗與疑似提示回傳,確認系統不會亂答;再用實機說包含「墨寒」、作品名稱與日常句子的內容,觀察錯誤是否能被看懂並重新嘗試。
我也不會把混合轉錄寫成百分之百準確。它是提高最終文字可靠度的設計,仍受模型、音質與環境限制。能誠實承認「這輪沒有聽清楚」,本身就是自然互動的一部分。
對我而言,這比讓介面永遠表現得很有自信更像真人。人也會聽錯,也會請對方再說一次;差別在於錯了以後是否坦白,是否保留讓主人看見與修正的機會。
語音到這裡,終於有了比較可靠的文字。接下來墨寒要開口,而她的嘴不能只是隨著音量隨便張合。Day 11 我會談 A、I、U、E、O 嘴型,以及我為什麼會為了一個像素的嘴唇邊界反覆檢查。
語音辨識永遠可能出錯;涉及外部操作時,轉錄結果仍須經過意圖、權限與使用者確認,不能因為「AI 聽起來很確定」就直接執行。