作者：James Giangola 「Google 創新主管-會話設計與人物角色」

發布于：Google Design

全文共 2494 字；閱讀約10 分鐘

這篇文章是“Words go here”的一部分，“Words go here”是介紹關于語言設計在產品設計中作用的系列文章。

初到健身房，我的大腦最近一直在重復——諸如“一分耕耘一分收獲”之類的話語。作為一名對話設計師和語言學家，我會更加頻繁地思考語言中的重復。

下面是一個迷你對話中關于重復的示例：

【例子1 音頻】

A: Joe’s a waiter, but he paints on the side.

B: Oh, what kind of pictures does he paint?

A: Pictures?! He paints houses.

動詞“paint”重復了兩次，單詞“pictures”重復了一次。重復明確地/顯式地將一個句子連接到另一個句子，并以有意義的方式幫助對話聯系在一起。語言學家會將此視為一個所謂“銜接”的好例子。

銜接是指在一段語言中對一個內容的解釋引用了同一段語言中的某個其他內容。銜接手段——例如重復、代詞和話語標記——是將口語或書面語各部分連接起來的單詞和短語，以便使想法和細節更加清晰地結合在一起。 因為這些手段以一種有效的方式將文本的各個部分連接起來，它們有助于確保我們交流的可靠性，并使理解更加容易。

正如重復（repetition）在自然的日常對話中發揮的作用一樣，它在對話設計中也是一個有價值的但經常被忽視的技巧。為了弄清為什么重復在對話設計中如此重要，我們首先必須理解語音識別技術中的“錯誤接受（false accepts）”問題。

首先，“正確接受（correct accept）”是指用戶說出某些內容并且識別器正確識別。反之，“錯誤接受（false accepts）”則是指用戶說出的內容被識別器錯誤識別。例如，用戶說的是“去奧斯?。?/span>Austin）的往返機票”，但是識別器錯誤地將這個詞解析為“去波士頓（Boston）的往返機票”。其他錯誤接受的例子包括“6月13日（June thirteenth）”被誤認為“6月30日（June thirtieth）”，或者“40美元（forty dollars）”被誤認為“14美元（fourteen dollars）”等。

隨著語音識別系統變得越來越精確，錯誤接受（false accepts）的情況變得越來越少（即便如此，為它們進行設計也是至關重要的，原因見下文）。也許有一天它們會成為過去式，但對于當下，我們還沒有“完美的（和人類一樣好的）”語音識別技術。那么我們怎樣才能盡量減小這個問題呢？引入重復（repetition）！

在下面這個迷你對話示例中，識別器并未重復它“認為”自己所聽到的內容：

用戶: What’s 11 times 3?

助手: The answer is 21.

這個答案令人費解，因為我們大家都知道答案并不是21。這樣的設計讓這個語音助手看起來并不會做基本的算術。并且，如果這是一個更加復雜的數學問題，我們或許會把它直接當作正確答案接受并使用。

以下示例展示了如果識別器向用戶重復它所聽到的內容，對話將如何進行：

【例子2 音頻】

用戶: What’s 11 times 3?

助手: 7 times 3 is 21.

用戶: No, what’s 11 times 3?

助手: 11 times 3 is 33.

通過重復所聽到的內容，很明顯實際上存在一個語音識別錯誤——一個錯誤接受（false accept）。通過讓系統的“識別假設”對用戶透明化，助手不再顯得算術不好（有時可能只是有點聽力障礙）。然后，用戶就知道要再問一次。

當系統重復用戶請求中的某個關鍵信息時，這被稱為“隱性確認（implicit confirmation）”。這種類型的重復在對話設計中很有用，這樣用戶就可以知道系統是否正確理解了他們。一方面，當識別器正確識別時，隱性確認可以提供保證。這種保證可以增強用戶對識別技術的信心，特別是在過去經歷過其他不太準確的系統的糟糕體驗的情況下。另一方面，當識別器出錯時，隱性確認讓用戶知道他們需要再次嘗試或改進他們的請求。這使得設計具有容錯性。也就是說，當錯誤發生時，設計可以將錯誤的后果最小化。

以下是隱性確認（implicit confirmation）的更多示例：

【例子3 音頻】

用戶: What’s the state motto of Georgia?

助手: Georgia’s motto is “Wisdom, Justice, Moderation.”

【例子4 音頻】

用戶: Who is the Prime Minister of India?

助手: The Prime Minister of India is Narendra Modi.

【例子5 音頻】

用戶: Call Amber Gómez.

助手: Calling Amber Gómez.

特別是在用戶難以接觸屏幕的情況下——比如正在開車——這樣聽到“Amber Gómez”可以讓他們確定即將與正確的人聯系。畢竟，想想當我們意識到自己打錯電話時，常常會面臨舌頭打結、臉紅懊惱的尷尬處境。這讓我想起了一位店主，他不小心給我發了一條感情真摯的短信，為“昨晚的吵架”（我們從未吵過架）道歉，并希望我能冷靜下來。哎呀，您發錯了！ (是的，我回復了)

當然，隱性確認（implicit confirmations）不一定要依賴于逐字重復。也可以用同義詞或者改述的方法來替代：

【例子6音頻】

用戶: Set an alarm for tomorrow morning at 5:30.

助手: Okay, 5:30 AM. Your alarm’s set.

在這里“AM”和“in the morning”是同義的。

在某些情況下，隱性確認（implicit confirmation）并不是必要的。例如，如果你讓數字助手打開手電筒，那么手電筒應該會亮起——就不再需要額外的確認?？吹綗袅林旧砭褪且环N確認，所以聽到“你的手電筒已打開”（一種隱性的確認）并沒有任何價值（當然，也許助手可以簡單地用一個確認詞來回復請求，比如“好的”）。另一方面，如果用戶坐在客廳里，請求助手關掉臥室的燈，那么確實需要一個隱性確認，以便用戶知道什么地點發生了什么事（“好的，關掉臥室的燈”）。

另一個需要考慮的問題是用戶是否需要看屏幕。例如，如果用戶要查看舊金山的地圖，那么隱性確認（implicit confirmation）并不十分重要，因為用戶無論如何都會看著屏幕，然后就能明白系統是否理解了。另一方面，如果用戶詢問舊金山的天氣情況，我們不能保證他們一定會看屏幕，所以隱含地確認他們的請求是一個好的選擇。

重復用戶所說的內容對另一種確認方式至關重要——顯性確認（explicit confirmation）。與隱性確認不同，顯性確認會向用戶發出聲明，要求他們用”是"或"否"進行確認。

下面是一個例子：

【例子7音頻】

用戶: I need a flight from L.A. to Miami on June 7th.

助手: Okay, that’s from Los Angeles to Miami on June 7th. Did I get that right?

用戶: Yes, you did.

這里重復了“Miami”和“June 7th”并用“L.A.”取代用戶的“Los Angeles”。

顯性確認（explicit confirmation）適用于以下情景：

出錯后的代價會很高，例如出售100股谷歌股票

應用程序將要執行的是一些難以或無法撤銷的操作，例如取消訂單

用戶已經投入時間為系統提供了大量的信息，例如預訂機票

商業或法律要求必須得到用戶明確的口頭協議，例如在最終確定匯款之前

對特定識別結果的準確性的沒有足夠的信心

顯性確認（explicit confirmation）的好處是用戶可以清楚地知道如何回應。因為用戶會被詢問一個是或否的問題來確認，所以他們知道如何在錯誤接受（false accept）的情況下使對話回到正軌。

相比之下，隱性確認（implicit confirmation）適用的情景是：

錯誤識別不太可能導致出現不良結果

對識別率信心很高

隱性確認（implicit confirmation）的優點是速度。當系統正確運行時，這種體驗感覺相對較快。當系統出錯時，用戶只損失了幾秒鐘的時間，可以簡單地重復或重述他們的請求來克服。

隱性確認（implicit confirmation）的一個潛在缺點是，當用戶需要修復錯誤接受（false accept）時，他們可能不知道該說什么。在這種情況下，應該構造識別語法以適應用戶從錯誤中恢復的嘗試。這需要關于用戶的言語行為的數據，以及識別語法的迭代改進。

在考慮使用哪種類型的確認時，重要的是要同時考慮到識別的準確性和識別錯誤造成的損失。

總而言之，重復用戶剛剛所說的話是對話設計中確認策略的核心。這些策略，反過來，是設計容錯性的基礎。也就是說，確認（confirmation）可以最小化錯誤接受（false-accept）帶來的后果。 

確認策略（confirmation strategies）還可以建立用戶信任。如果用戶知道助手不會在未經確認的識別結果基礎上做出決定，那么他們更有可能相信技術，并對正在發生的事情有掌控感。

特別感謝Eunice Liu對本文的幫助。

翻譯：PMCAFF 創新設計團隊

創新設計是外包大師聯合全球最大的產品經理社區，共同推出的針對企業互聯網產品的服務。從客戶實際問題出發，以解決客戶問題為最終目標，提供整套產品解決方案。

咨詢數字化轉型、O2O渠道融合相關業務：掃描下方的二維碼，讓我們一起聊聊你的需求！