使用者喜歡聊天機器人，因為它們非常簡單且要求極低 — 它們可以簡單到只是一種線索式文字對話。使用者喜歡停留在他們最喜歡的訊息應用程式內。他們希望直奔主題，而無需導航應用程式、Web URL、選單、按鈕、廣告、瀏覽器和其他元素。
但是，這種簡單性也存在巨大的設計挑戰。聊天機器人必須準確地理解使用者輸入的資訊，並採取恰當的行動。甚至對於如今最優秀的自然語言人工智慧 (AI)，這也是難度極高的要求。
考慮到 AI 的當前發展狀態，線索式文字對話或對話 UI (CUI) 幾乎總是沒有精心設計的圖形 UI (GUI) 受歡迎。與 GUI 相比，CUI 仍處於發展初期。在本教程中，我將解釋聊天機器人差強人意的原因，以及如何才能成功地實現它們。
備註：Robert Kosara 博士最近發表一篇題為 “擬人化使用者介面的陷阱” 的部落格文章。他描述了 Shneiderman 和 Maes 在 1997 年對於 UI 的 “直接操作” 與 “介面代理” 樣式的爭議。他的結論是，20 年前的教訓今天仍然適用：除非 “代理” 能完美地預測使用者的需求（完美的 AI），否則為使用者呈現一個 GUI 視窗會更好一些，因為資訊更容易被發現，而且互動不需要 “語法”。但是，使用者對其喜愛的訊息應用程式中的極簡 UI 表現出的強烈喜歡不容忽視。
聊天機器人失敗的原因
Facebook 在 2016 年 4 月啟動它的機器人平臺後，許多人試用了 “啟動夥伴” 特色功能，發現 存在很多缺陷。聊天機器人 甚至無法理解其應用領域中的基本問題（例如，檢查天氣或鮮花快遞）。尤其令人痛苦的是，當使用者嘗試 “自然地” 談話並偏離聊天機器人期望的機械式問題時，就會看到 機器人崩潰。
Facebook Messenger 產品經理 Mikhail Larionnov 檢查了 Facebook 平臺上的許多聊天機器人，確定了一些聊天機器人缺乏吸引力的 3 個原因：
- 受理工作做得不好，對聊天機器人的用途解釋得非常少
- 嘗試在一個聊天機器人中實現太多用途，價值不明確
- 過於依賴自然語言處理
建立成功的聊天機器人的方式
但是，Larionnov 也提供了一些解決這些問題的具體建議。
首先，聊天機器人應擁有非常有限的範圍。它應在一個很小的主題上提供價值，並將這件事做好。更重要的是，應該能用一兩句話解釋它的操作。
第二，在使用者受理過程中，你應該使用每個訊息平臺的內建功能表達聊天機器人的特性。Facebook Messenger 採用了精心設計的問候視窗和操作要求。對於 Slack，該功能就是機器人商店中的描述。
第三，你應該儘可能多地使用結構化按鈕。如果需要採用自由使用者輸入格式，則需要處理 AI 無法理解輸入的情況，並提供有關如何正確使用語法的幫助訊息。聊天機器人的語法是觸發操作的命令和關鍵詞。
我還想新增第 4 點，那就是不能刷屏。聊天機器人必須理解並響應停止、退訂和取消等命令。此外，它應該立即停止傳送訊息。如果你的機器人向使用者傳送了大量不想要的訊息，使用者除了遮蔽你的聊天機器人外，別無選擇。據知，如果 4% 的使用者遮蔽了你的聊天機器人，Facebook 就會將它下線。
設計一個命令控制 CUI
CUI 通常會提醒人們輸入 DOS 和 UNIX 時代古老的計算機命令。事實上，當聊天機器人最初流行時，他們被開發人員廣泛用於執行高技術任務。例如，GitHub 的 HUBOT 在內部使用命令來管理許多操作。在該使用案例中，“對話” 通常是開發人員直接將命令輸入聊天視窗，然後機器人執行這些命令。這是否意味著，構建一個機器人來響應使用者必須記住的預定義命令是可接受的？在許多情況下確實如此。
我們來檢視兩個使用案例：
- 用於工作和生產的聊天機器人可能更適合命令。這些聊天機器人使用者通常是精通計算機的專業人員，他們習慣於在工作中使用命令。事實上，許多超級使用者已掌握應用緩慢的 GUI 執行重複任務的命令列提示和鍵盤快捷鍵。所以，在此場景中，高效的 “命令列” 機器人或許比聊天式機器人更可取。
- 隨計算機一起成長的年輕使用者一生都在使用文字訊息。他們可能更注重命令的效率而不是緩慢的 GUI。
如果設計一個命令控制 CUI，以下是一些具體的設計考慮因素：
- 提供自動完成或其他形式的幫助，確保使用者能夠正確地拼寫命令。特別關注 iOS 和 Android 裝置的自動更正功能，因為如果使用者命令的拼寫不合常規，它們可以修改使用者的輸入。內建命令幫助的一個不錯示例是 Slack 的 Slash 命令。Slack 應用程式 UI 建議正確的拼寫，並對鍵入的命令提供解釋。
- 編寫你的聊天機器人來容忍常見的拼寫錯誤或同義詞。例如，“help” 也可以是 “How do I do this?”。此場景要求建立一個同義詞列表，其中許多同義詞可以是正規表示式，並在執行時將它們與使用者輸入進行匹配。
設計一種填空式的簡單對話
與命令列相反的是可與使用者進行自然對話的聊天機器人。但是，考慮到自然語言 AI 的當前發展狀態，與使用者進行任意範圍的對話幾乎不可能。而且你不需要這麼做。聊天機器人要想變得實用，通常只需使用高度指令碼化的對話。例如，要詢問聊天機器人天氣，你可能會說：
德克薩斯州奧斯汀明天是什麼天氣？
在這裡可以注意到，你擁有：
- 意圖：天氣報告
- 地點：德克薩斯州奧斯汀
- 時間：明天
聊天機器人現在可以查詢天氣。但是有時候，使用者沒有一次提供所有資訊。如果使用者最開始僅提供了意圖，聊天機器人應能要求使用者完成其他所需的引數，這些引數稱為空位。這是可能的對話情形：
Human: What is the weather?
Bot: I will look up weather for you. Do you want to check your local weather or somewhere else?
Human: Somewhere else
Bot: Okay, where is it?
Human: Austin Texas
Bot: Thanks. Do you want to know the weather right now or do you want a forecast?
Human: Forecast
Bot: Okay, when?
Human: Tomorrow
Bot: The weather tomorrow at Austin, Texas, is sunny with a high of 80 degrees and low of 75 degrees.
你已獲得想要的資訊。這種高度指令碼化的對話可能在許多場景中發生。一般而言，當你要求機器人執行某項任務時，機器人應該能夠進行一次簡短對話來填上所有需要的空位。
互動式對話的設計
命令和填空式對話是解決缺乏真正的對話 AI 的有效方式。但還有另外一種更直接的方法 - 在要求特定回覆的訊息後顯示按鈕。以便你能清晰地傳達希望使用者提供的回覆。這是一個 Facebook Messenger 聊天會話內的按鈕示例。
一個 GUI 上的按鈕的螢幕截圖如果沒有這些按鈕，聊天機器人通常會提供編號選項或關鍵詞選項（例如，“回覆 1 讀取更多資訊，回覆 2 檢視所有故事”）。這種互動型別通常給人一種機械化的感覺。無論如何，當聊天機器人要求使用者從一個編號列表中進行選擇時，它應該能夠處理使用者輸入，比如 1、一、第一、第一個選擇和其他同義詞。
請記住，使用者可能未使用你提供的按鈕或編號列表。使用者可能跳過按鈕並鍵入完全不同的資訊。一個常見的示例是，使用者看到一組按鈕時，不知道如何回覆，而鍵入 help 或 menu。你的聊天機器人應準備好應對這種場景，透過分析任何自由回覆來檢視使用者是做出了你請求的選擇，還是希望啟動一個全新的任務。
當然，如果你擁有按鈕，也可以擁有其他互動式元素。例如，Facebook Messenger 支援一個可水平滾動的滾輪。這是提供一組選項的好方法，無需讓一個非常長的列表塞滿整個視窗。
該螢幕截圖顯示了不同的選項點選檢視大圖
預測多模式使用者輸入
現代訊息應用程式的一個不錯功能是，能夠傳送影像、音訊、影片、表情、位置和其他輸入。Facebook Messenger 是這類豐富的聊天功能的一個好示例。
Facebook 訊息底部的訊息輸入欄位點選檢視大圖
自然，一些使用者更傾向於使用語音通訊，而其他使用者可能喜歡傳送圖片。最好透過一個位置來回答 “你在哪裡” 的問題。Facebook Messenger 為你的聊天機器人提供了所有這些使用者生成的資源。但你的聊天機器人需要弄清楚它們的含義（例如，語音到文字轉換、影像識別、OCR、經緯度與地址的對映，以及其他輸入）。
備註：不同的訊息應用程式支援不同型別的使用者生成的多模式輸入，而且它們提供了不同的方法將此資料傳送到聊天機器人。因此，很難建立一個在所有訊息應用程式中一致執行的通用跨平臺聊天機器人。
粗魯使用者與作家 UI 設計師
在編寫聊天機器人時，需要預測使用者可能提供的各種各樣的資訊。有時，使用者會故意粗魯地對待聊天機器人，只為了挑戰極限，看看聊天機器人會如何反應。你應準備許多機智的回覆來處理粗魯的評論。
一般而言，對於你的所有回覆，你首先應該檢測使用者的意圖，然後對該意圖嘗試不同的回覆。與一次又一次地看到聊天機器人的準確回覆相比，沒有什麼讓人感覺更機械化。對話管理工具（比如 谷歌的Dialogflow、IBM Watson Conversation 或 Dialog 服務、中文領域裡奇點機智的“對話流”）可幫助你在每個場景中從一個預備答案列表中隨機選擇答案。
對聊天機器人提供機智的回覆和個性的需求，催生了 “作家即 UI 設計師” 運動。據報導，矽谷公司正在招聘英語專業生和詩人 來改善其初生的機器人。
案例分析：來自微信的教訓
微信是中國最大的訊息平臺，每月擁有 7 億多活躍使用者。2013 年，微信開闢了 “公眾號” 這個非常成功的機器人程式。從聊天機器人互動方面講，微信上有哪些成功或失敗之處？
微信目前支援兩種公眾號機器人：訂閱號和服務號。二者最開始都是聊天機器人，但也逐漸演變為不太關注 “人工智慧聊天”。兩種公眾號都支援 CUI。
訂閱號由內容釋出者用來向其訂閱者提供新內容。通常，釋出者每天一次向其所有訂閱者傳送當天的新內容文章列表。
使用者也可以回覆文字來獲得具體的文章或執行具體操作，例如：
- 一篇文章可能說 “輸入 42 下載文中提到的 PowerPoint 幻燈片”。
- 使用者可以輸入 “歷史文章” 獲取最近發表的文章的列表。
- 使用者可以輸入 “聯絡方式” 獲取一個 Web 連結來聯絡訂閱號管理員。
請注意，這些都是非常簡單的命令或觸發關鍵詞。它們旨在快速將你引導至網頁或下載地址。很少有訂閱號嘗試與使用者進行漫長的自然語言對話。
客戶服務部門使用服務號在微信上與其客戶互動。示例包括航空公司、酒店或電子商務商店。微信很早就認識到，AI 自動聊天機器人無法處理人類客戶支援問題。因此，與 Facebook 頁面非常相似，每個服務號可以將一個或多個人類使用者帳戶指定為 “支援人員”。
以下這些螢幕截圖顯示了來自一個航空公司和一個信用卡公司的實際的客戶服務聊天會話。儘管文字為中文，但你可以想象這裡經歷的過程。這同樣是簡單的觸發文字和命令。
客戶服務聊天視窗的螢幕截圖點選檢視大圖
對於一些客戶服務號，服務號所有者會嘗試與使用者進行更長的對話。同樣地，對話僅在開頭是自動化的，在機器人發現使用者的意圖後，聊天很快轉移到一個相關的網頁（例如重新預定機票）或與該服務號相關的人類代理。
微信高度發展的機器人生態系統帶來的關鍵結論是：
- 不同的機器人應用程式需要不同風格的對話 UI。對於許多機器人，引導至一個 Web 檢視的簡單命令或觸發文字就足夠了。
- 更長的機器人對話適合高度指令碼化的使用案例，比如特定產品的客戶支援。即使在那時，根據需要將使用者轉移到 Web 應用程式或人類代理仍是明智之舉。
- 訊息機器人的價值通常體現在與平臺整合，以便機器人可無縫地訪問使用者的身份、支付資訊和其他資訊。
結束語
在本教程中，我討論了聊天機器人的對話設計面臨的關鍵問題，列出了建立成功的機器人的方式，而且透過分析微信訊息平臺演示了這些方式。我建議了 3 種互動型別：命令控制、填空和互動式對話。我還提及了多模式使用者輸入和如何富有創意地提供回覆。
原文作者：Michael Yuan
來源：https://www.ibm.com/developerworks/cn/cognitive/library/cc-cognitive-chatbot-conversational-design/index.html
