人機之間的對話交互會如何發展——可控性與智能性的權衡

　　交互，就是不同物體進行信息交換的過程。信息交換效率是衡量交互最重要的指標。人與機器的交互，將追隨人與人交互的演化路徑。

　　人與人的交互

　　在語言發明前，人類的祖先智人主要是通過什么方式進行交流的？一種方式是用肢體做動作，模仿各種活動，比如動物；另一種方式則是喊叫，通過不同的喊叫聲來傳達一些簡單信息，比如危險靠近、找到食物。大部分其他動物的交流方式到現在也是如此。

　　第一種交流方式對應的就是圖形交互，用到的器官主要是眼睛，其主要約束來自于空間：距離不能太遠，不能移動太快，不能被東西遮擋等。第二種交流方式對應的則是對話交互，用到的器官主要是耳朵，其對空間的依賴性更低：距離可以很遠，移動和遮擋影響也不大。

　　在發明語言后，人類進一步提高了第二種交流方式（對話交互）的效率和信道容量。對話交互碾壓圖形交互成為人與人最重要的交流方式。使用對話交互，人類可以同時與多人進行較遠距離的實時交流。相比于圖形（眼睛），現在人類對語音（耳朵）的并行處理能力要強得多。這可能就是進化的結果。

　　人類也一直在努力改進對話交互方式。通過電話我們已經可以和地球任一個角落的其他人進行交流，前提是對方得在電話旁邊。對方老不在怎么辦？讓他一直把電話帶身旁（手機）。什么，你想交互更便捷、便宜，對話交互時還能融合圖形交互？微信吧。

　　最后總結下人類交流方式的發展路徑，基本就是在不斷改善對話交互的效率，降低空間和時間對它的約束：

　　語言發明前：主要使用圖形交互方式，受空間和時間約束巨大；

　　語言發明后：主要使用對話交互方式，受空間和時間約束變小，但仍然很大；

　　電話和手機發明后：極大改善了對話交互方式，不再受空間約束，但時間約束仍較大；

　　（移動）互聯網發明后：人類幾乎一直在線，對話交互方式基本不再受時間的約束。

　　人與機器的交互

　　在計算機剛被發明時，計算機可以被認為是一種很低等的物種。人類作為高級物種在跟低級物種計算機進行交流時，必須遷就計算機，使用它喜歡的語言（匯編、命令行）。這就像主流文明社會如果要跟深山里的原始部落進行交流，開始階段只能是文明社會去學習原始部落的交流方式然后與他們交流。

　　隨著計算機逐漸被動進化出外表（圖形），人類逐漸學會了與它通過圖形交互進行交流，并在發展過程中逐漸提升交流效率（PC、APP早期時代）。

　　文明社會學會了原始部落的語言后，會反過來再教導原始部落學習文明社會的語言，因為文明社會所使用的語言表達能力更強，效率更高。人類與計算機的交互進化路徑也會如此，因為最終目的都是人類獲得交互效率的提升。

　　為什么要計算機遷就人類？因為人類進化太慢。人類在經過長達百萬年的進化后，對話交互已成為人類目前可接受的最高效溝通方式。顯然我們沒法為了提升與計算機的交互效率短時間讓自己再進化進化，所以只能讓計算機進化出人類最喜歡的對話溝通能力。這就是為什么人類一直不遺余力地發展計算機的（語音）對話交互能力。

　　人機交互接下來的發展路徑會和人人交互的發展路徑相同——人類會讓機器一直保持在線。這不就是IoT時代的目標么。隨著IoT萬物互聯時代的臨近，人類需要與各種機器進行交互。相比于圖形交互，對話交互具有更好的遷移性。使用圖形交互，與不同的機器溝通就要開發不同的圖形交互界面（想想PC和手機的圖形交互差別有多大），但我們卻可以跟所有東西使用相同的對話溝通方式。

　　讓所有機器都具有對話交互能力，人類就可以并行地與多臺機器同時進行交互。（想想鋼鐵俠里男主角在工作室工作的情景吧。）沒有對話交互，那你讓你家吸塵器工作時還得深情地看著它……

　　當然，以后人類可能會發展出更高效的人機、人人交互方式，比如直接用腦電波進行交互（想想三體人）。但這個目前看還是需要段時間的。在此之前，

　　對話交互是最高效的人人交互方式，也將成為最高效的人機交互方式。

　　各種對話交互（Bot）平臺

　　首先需要承認，現在機器的智能還非常有限，它們沒法和人類做到什么都能聊（開放域對話交互），但是在某些小的垂直領域它們已經能和人聊的很好（任務導向對話交互）。這種現狀應該還會持續一段時間。現在大部分Bot領域的公司做的事都是與任務導向對話交互相關。

　　那怎么開發任務導向的對話機器人系統呢？如果你只是想讓機器人用在一個固定領域或固定企業業務，那么你針對此領域或此企業業務進行技術優化即可。這時候使用的技術可以具有領域特性，不需要能夠推廣到其他領域或者其他業務。這里最有代表性的是Google的Gmail和Allo中的Smart Reply功能。

　　如果你的系統是幫助其他開發者更便捷地開發對話機器人，即Bot創建平臺，那么使用的技術就最好不要與某個領域或業務有關。國外比較典型的是Facebook的Wit.ai和Google的Api.ai，國內也有不少創業公司在做這方面的事，比如一個AI、知麻、如意等，基本處于起步階段。

　　篇幅有限，接下來我們只討論第二類對話系統，即Bot創建平臺，對Gmail和Allo的Smart Reply感興趣的同學可以看看我之前寫的《Google的智能問答技術》。

　　不同的Bot平臺：可控性與智能性的權衡

　　企業通常會更關注自己bot的可控性，也即掌控力度，在出現問題時必須快速定位并解決。企業寧愿bot答不上來，也不能允許它瞎答。而用戶當然希望bot能解答自己的各種問題，所以bot一定是越智能越好。但可控性和智能性本身就是一對互相矛盾的性質，智能本就包含了不可控。我一直記得K.K.在《失控》中的一個觀點：智能來自于失控。

　　基于可控性和智能性的矛盾性，再考慮到現階段技術的可行性，各種bot平臺能做的就只能是在可控性和智能性之間找平衡點了。技術的發展只是會不斷拓展可控性和智能性的帕累托邊界而已。

　　下面介紹幾類典型的bot平臺：微信與旺旺、Viv、Api.ai與一個AI、Wit.ai，它們似乎大不相同，其實也只是在可控性和智能性之間的權衡不同罷了，見下圖。

　　一個bot平臺想要獲得更好的智能性，那它就要付出可控性的代價。（一個AI放在api.ai上面倒不是說現在它的智能性比api.ai強，而是表明我們對一個AI的定位，希望它能在中文方面做得比api.ai好。）把Gmail的Smart Reply功能放在圖中的原因是把它作為其他bot平臺的參照對象。作為特定領域的bot，它能夠更好地兼顧可控性和智能性。

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　下面分別介紹這幾類bot平臺

　　一、極度可控的微信和旺旺

　　其實我們早就在用各種bot服務了，這些bot太不智能以至于我們都沒把它們往bot這個方向上想。比如各種電話服務里的操作步驟，旺旺里商家維護的常見問題列表，微信公眾號里的菜單和功能編碼：

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　這些bot雖然不智能，但是卻很有用，因為它們很可靠，不會犯錯誤。我們點擊微信里的菜單，獲得的響應一定是公眾號管理者設定好的那個反饋，不會因為系統理解錯而出現管理者不希望出現的東西。

　　二、較可控和較智能的Api.ai和一個AI

　　Api.ai目前應該是美國最流行的bot創建平臺。9月19日，Api.ai宣布自己被Google收購。相比于Viv，api.ai的優勢是簡單和可控，它里面的每個意圖通常只包含一輪對話，開發者只需要維護其中的用戶提問、機器回復、動作，以及涉及到的實體。這樣系統可以依據用戶設定的這些數據訓練模型以便在服務時預測用戶輸入對應的意圖和識別包含的實體。

　　在接收到用戶輸入后，系統會分析用戶的輸入，預估用戶的意圖，以及識別輸入中包含的實體，這些實體是在達成意圖時需要的。下圖給出了完成一次請求時的大致流程和一個示例。

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　Api.ai好的可控性降低了開發者的使用和維護門檻，它的靈活性較Viv低但也能滿足大部分應用的需求。但是，api.ai對中文的支持很差，在國內訪問延時也很大。前幾天它宣布被Google收購了，估計被墻也只是時間問題。基于這些原因我們開發了一個AI，希望通過一個AI把api.ai范式的強大和便捷帶給國內開發者。下面詳細介紹下一個AI。

　　一個AI（www.yige.ai）是一個創建聊天機器人（bot）的免費在線平臺。利用一個AI，開發者甚至產品和運營人員都可以輕松地開發聊天機器人應用，而不需要具備機器學習與自然語言處理等相關知識。一個AI的使命是：

　　讓每個人都能輕松開發一個AI應用。

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　一個AI中包含幾個重要概念：詞庫、場景、動作、狀態。詞庫是一個規范的自然語言短語集合，通常定義為應用所在領域的關鍵詞、術語。詞庫在學術領域通常被稱為實體（entity），是自然語言處理中的重要概念。

　　詞庫在一個AI中用于從用戶輸入中提取動作和狀態所需的參數值。一個AI不僅內置了常用的系統類型，如數字、日期、時間等，也為開發者定義自己詞庫提供了靈活便捷的支持。開發者可以定義包含同義詞的同義詞詞庫，也可以定義不包含同義詞的枚舉詞庫，甚至可以定義由其他詞庫組合而成的組合詞庫。

　　一個AI中的場景通常對應著從用戶提問到AI產生答復的一輪交互過程。一個場景主要由用戶提問、AI回復、動作和輸入輸出狀態所組成。

　　動作是用戶提問匹配到的場景執行后觸發的一個特定操作，它可以使用從用戶輸入中提取出的詞庫作為輸入參數。動作相當于代碼中的函數，其具體實現在開發者端，一個AI系統端只是一個標識，相當于函數聲明。

　　狀態記錄了對話交互的背景信息，主要用于上下文信息（如參數值）的傳遞。此外，它也被用于管理會話流，串聯起原本孤立的不同場景。多個場景通過場景里的輸入輸出狀態連接成圖網絡以完成更加復雜的功能。

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　一個AI遵循的流程和Api.ai類似（見之前的流程圖）。在接收到用戶的輸入后，流程如下：

　　一個AI首先識別用戶輸入中的詞庫和用戶場景。詞庫和場景的識別并不是獨立的，相同的詞在不同的場景下可能屬于不同的詞庫類型。在場景識別時也會考慮到場景設定的狀態是否存在。如果某場景設定的輸入狀態不是都存在，則不會把用戶輸入識別為此場景。

　　查看動作中需要的必須參數是否都已獲得取值。如果存在必須參數還沒有獲得取值，就觸發設定好的提示語作為機器人回復，要求用戶輸入對應的參數取值。參數的取值不僅可以來自于此次用戶輸入中的詞庫，也可以來自于輸入狀態中的變量。對于非必須參數，可以為他們設定默認值。

　　只有所有必須參數都已收集到取值，此場景才能完成，場景設定的AI回復才會作為回復返回給用戶。到這里此場景就完成了，用戶之后的輸入就會觸發新的循環。

　　一個AI定位于服務國內開發者，所以也引入了一些中文相關的特性，例如查詢接口支持未分詞的整句話輸入，以及分詞后的語句輸入。

　　關于一個AI的由來，可見我之前的文章《創建Bot的中文平臺——一個AI（yige.ai）》。更多信息可見一個AI官方文檔，也歡迎大家去一個AI官網（www.yige.ai）逛逛，嘗試創建年輕人的第一個AI應用吧^_^。

　　三、更智能的Viv

　　Siri的開發團隊從蘋果離職后開發了Viv，一個bot平臺。Viv還沒正式發布，只是在今年5月9日的TechCrunch Disrupt（演講視頻）大會上展示了一下。

　　Viv中主要包含了兩種對象：概念對象（Concept Object）和動作對象（Action Object），其中概念對象指的就是實體，而動作對象就是執行的動作。以概念和動作對象為結點，Viv構建了規模龐大的有向網絡圖。概念結點到動作結點的邊表示此動作以此概念為輸入參數，而動作結點到概念結點的邊表示此動作的輸出中包含了此概念。

　　如果兩個概念結點存在擴展（“is a”）或者屬性（“has a”）關系，那么它們之間也會存在有向邊。隨著開發者不斷把新的概念和動作對象加入到Viv系統，這個網絡圖會逐漸延伸，越來越大。借助于Viv的動態演化認知架構系統（Dynamically Evolving Cognitive Architecture System，簡稱DECAS），Viv能做的事會隨著網絡圖的增大而指數增長。

　　DECAS的核心，是如何串聯起不同的動作來達成目標。放在之前提到的概念和動作組成的網絡圖里面說，其實就是找意圖中概念結點到意圖中目標結點的各種連通路徑。（雖然Viv沒有具體說，但目標結點應該也是一種概念結點。）Viv把一條路徑稱為一個計劃（Plan）。計劃中使用到的動作可以跨應用，可以來自于不同開發者設定的動作。

　　下圖中給出了達成跑鞋推薦目標的兩個計劃，其中計劃1串聯了

　　transform_occupation_to_price和rec_shoes_based_on_price這兩個動作，而計劃2則是串聯了transform_occupation_to_type和 rec_shoes_based_on_type這兩個動作。開發者可以為每個計劃設定一個價值函數，DECAS則只需要選擇價值最高的topN計劃具體執行即可。當然，DECAS可能做得更復雜，比如依據用戶反饋實時調整計劃。

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　如果一個計劃包含的動作所需的必須輸入概念對象缺失，那么就需要與用戶進行多次交互以收集缺失概念對象的值。

　　總結下，Viv是以動作為核心的網絡系統。 它首先讓開發者定義對應領域的概念對象和動作對象，然后自動生成計劃（網絡圖中找兩個結點間的路徑），利用用戶輸入中的概念對象完成用戶的目標。相對于Api.ai和一個AI只能使用開發者設定的意圖來完成已知的需求，Viv在聯合不同開發者定義的概念和動作對象后可以執行一些不在開發者設定范圍內的意圖。隨著越來越多開發者接入Viv，它能做的事會指數增長。Viv在智能性/靈活性方面做得很好，但可控性會稍差，因為完成目標的計劃都是由系統自動生成的，開發者難以介入。好的靈活性也會對開發者有更高的要求，開發者初期付出的管理成本可能不低。Viv開發了很多輔助工具幫助開發者管理自己的應用，但這些工具能把開發者的管理成本降到什么程度目前尚不清楚。

　　關于Viv的更多細節，可見我之前的文章《原Siri團隊秘密研發的Viv能攪動bot市場嗎？》。

　　四、在路上的Wit.ai

　　Wit.ai在2014年就被Facebook收購了，今年上半年做了很大的改版。之前它的模式和一個AI類似，開發者可以手動設置狀態以銜接不同的場景。

　　改版后，它取消了之前一個場景控制一輪對話的邏輯，變為以故事（Story）為對話單元。一個故事相當于完成用戶某個需求的一條路徑。所以一個故事通常包括多輪對話，或者說一個故事包括完成同一需求的多個（隱式）場景。故事是比場景更大的對話單元。下圖給出了一個求約會故事的示例。

　　人機之間的對話交互會如何發展——可控性與智能性的權衡

　　開發者可以為同一需求設定多個故事，代表完成此需求的多條路徑，但也不需要為所有路徑都創建一個故事。Wit.ai可以使用已創建的故事來自動生成新的路徑以完成某個需求。如果把故事中的一輪對話看成一個AI里的一個場景，那wit.ai就能自動銜接不同故事中的各種場景，以便創建完成需求的新故事或者新路徑。類似的能力在api.ai和一個AI里更多是依靠開發者通過狀態進行維護。

　　以故事為對話單元的好處是，開發者不再需要手動設置場景和狀態了，系統可以通過學習來拆解已有故事并重新拼裝成新的故事。在相同場景數的情況下wit.ai能回答的用戶提問會比api.ai和一個AI多。但這種靈活性帶來的壞處就是可控性下降。開發者很難控制某些路徑不被自動創建，出現問題時開發者如何調整故事也變得很朦朧。而這些問題在api.ai和一個AI里是不存在的。

　　Wit.ai正從api.ai和一個AI這端走向Viv那端。路是不是對的，只能走著瞧了。

　　關于wit.ai的更多細節，可見我之前的文章《低價制造chatbots的利器 Wit.ai》。

　　說了這么多，該說的終于說完了，簡化一下就兩條內容：

　　對話交互會在IoT萬物互聯時代爆發，這是追逐交互效率的必然結果。

　　不同的bot和bot平臺的差別其實只是在可控性和智能性之間的權衡不同。技術的發展只是在不斷拓展可控性和智能性的帕累托邊界而已。我個人認為目前api.ai和一個AI的范式最適合國內小微企業。