第2章
聊天機器人與自然語言了解
在編寫機器人和建立自然語言模型之前，我們先回顧一下自然語言了解（NLU）和機器學習（ML）的基礎知識。微軟的語言了解智能服務（LUIS）實作了自然語言了解中的一些概念，另一些概念則可以使用Python/R等機器學習工具包，或利用其他服務（比如微軟認知服務）實作。本章旨在為讀者快速而簡單地介紹與自然語言了解相關的基本概念，如果讀者已經對相關知識十分熟悉，則可以跳過本章内容直接閱讀第3章。我們希望通過本章的學習使讀者對NLU的根源及其如何将NLU應用于機器人領域有基礎的了解。最後，網際網路上有很多對NLU更深入的學習材料，如果讀者感興趣可以閱讀我們提供的參考資料。
如果我們決定開發一個內建了NLU的機器人，則在機器人的工程開發中必須保證了解使用者語言的系統能做到與人進行持續的互動。以我們在第1章中介紹的用自然語言進行恒溫控制的機器人為例，它有4個意圖：開關打開、開關關閉、設定模式、設定溫度。就設定溫度這一意圖而言，開發者如何編寫能了解使用者設定溫度意圖并且能識别使用者語言輸入中哪一部分代表溫度的系統呢？
一種方法是進行暴力編碼（brute-force coding），直接在程式裡寫死。典型地，我們可以使用正規表達式來對使用者語句進行比對，比如“set temperature to {temperature}”“set to {temperature}”以及“set {temperature}”。我們寫完程式并用符合上面正規表達式的語句測試完之後，似乎萬事大吉，但此時來了一個新使用者，如果他對機器人說的語句是“I want it to be 80 degrees”，那麼機器人會無法了解，也就無法與使用者進行互動了。于是，我們又增加一條正規表達式“I want it to be {temperature}”。然而，如果又有新的使用者對機器人說“lower temperature by 2 degrees”，這時候我們還可以再加兩條正規表達式“lower temperature by {diff}”和“increase temperature by {diff}”。但是，使用者的輸入是多種多樣的：lower和increase有很多同義詞，溫度機關也有攝氏度、華氏度，使用者的輸入語句可能是多條指令……那麼我們怎麼處理這麼多的變化？
回顧剛才機器人中所支援的互動可以發現，簡單粗暴的暴力編碼開發方式非常容易産生極其複雜冗長的代碼，并且考慮到使用者使用自然語言表達的多樣性，這個機器人在互動上也一定很差，一點兒都不優雅。如果開發者需要适度地引入這種簡單粗暴的方法，那麼使用正規表達式無疑是最适合的方式，我們将在第5章介紹Bot架構對正規表達式的支援；如果不采用正規表達式，則開發者應該確定設計的互動模型簡單且易于維護。
自然語言了解（NLU）是自然語言處理（NLP）中機器閱讀了解任務裡的子任務。自然語言了解和自然語言處理密不可分，主要是因為我們會将機器人的智能程度與機器人的互動溝通能力聯系起來：如果不管我們說的話多麼複雜，機器人都能了解我們的說話内容，那我們自然會覺得機器人很智能。
我們在第1章提到的“指令行”的互動方式自然不屬于智能的範疇，因為這種互動方式需要使用固定的輸入格式。那麼，通過了解使用者的語音輸入來運作某個Node.js腳本屬于智能的範疇嗎？通過NLU技術，我們可以建構對某一特定任務有了解能力的模型。這樣從表面上看，機器人是具備一些智能的。事實上，我們的計算能力和技術都沒有達到可以建立一個比對人類智能的NLU系統。如果一個問題隻有在計算機能像人類一樣聰明的情況下才能被解決，那麼這個問題就是“AI Hard”問題。我們目前還無法做到使NLU系統達到像人類一樣了解自然語言，但我們可以做到建立一個簡潔的NLU系統，它能很好地了解某一類事情，并創造出流暢的對話體驗。
鑒于近來對機器學習和人工智能的過熱追捧，在機器人開發的開始階段設定正确的期望對我們而言尤為重要。在和客戶讨論對話智能時，我也一直向他們強調現實和期望的智能化程度是有差距的。我們每個人隻需要想出一種人類可以了解但機器人卻無法了解的表達方式來描述某件事情，就可以輕易地擊敗機器人。開發機器人會存在這樣的技術局限性，而且也受限于開發預算和開發周期。隻要我們建立的機器人專注于某一類任務，友善了使用者的生活，那麼我們的開發思路就是正确的。
2.1 自然語言處理的基本概念
NLP領域的開端可以追溯到艾倫·圖靈（Alan Turing）時期，特别是圖靈測試—一種确定機器是否能被認為具有人類智能的測試。在圖靈測試中，測試者向兩個被測試者提出一系列問題，被測試者對問題進行回複，其中一個被測試者是人，另一個是計算機。對于兩個被測試者的回答，如果測試者無法判斷哪個是人哪個是計算機，那麼該計算機就通過了圖靈測試。盡管目前有一些系統聲稱能夠通過圖靈測試，但最終都被認為并不成熟。另外，還有些批評者認為，讓機器人做到使人類相信它是人類和了解人類的語言輸入是截然不同的兩件事。我們要通過圖靈測試可能還需要好幾年。
自然語言處理領域最著名的成功案例之一是Eliza，Eliza在20世紀60年代中期由心理學家Joseph Weizenbaum開發，它是一個能模拟和人進行對話的聊天機器人，雖然簡單但讓人感覺很智能。Eliza由一個腳本驅動，該腳本根據輸入的關鍵字為輸入計算出一個得分，依據得分的輸入比對一個輸出，Eliza的機制與後文Bot架構中的識别器不同。在網上我們能找到用JavaScript實作的Eliza，如圖2-1所示。除了Eliza，技術人員還開發過很多相似的系統，也都取得了不同水準的成功。
NLU引擎通常是基于規則的，它們使用結構化的知識表示來進行編碼，以便系統在處理使用者輸入時使用。大約在20世紀80年代，機器學習領域開始取得進展，機器學習比基于規則的方法更接近智能。比如，我們已經在前文探索過用簡單粗暴的方式編寫NLU引擎和根據多種多樣的規則進行冗長煩瑣的編碼工作。使用機器學習的方法，NLU不需要提前了解所有意圖的分類，而隻需要在編寫NLU引擎時為它提供一些标記了意圖名字的樣例輸入。其中，這些樣例稱為訓練資料集。基于樣例輸入和标記的意圖可以訓練出一個能從輸入中識别所有意圖的模型。訓練結束之後，模型就能接收新的輸入并為輸出的每個意圖打分。通常情況下，我們所使用的訓練資料越多，模型的性能就越好。這就是機器學習的用武之地：先用高品質的資料來訓練模型，然後通過使用該統計模型，系統可以開始對之前尚未遇到的輸入進行标簽預測。
由于訓練資料是打了标簽的，是以上述訓練方法稱為監督學習（supervised learning）。監督學習的表現可以很好地定量分析，因為我們知道真實的标簽，并能夠将它們與預測的标簽進行比較，以獲得定量值，這也稱為交叉驗證。分類和回歸問題是兩類最适合監督學習的任務，分類就是判斷輸入i是否屬于類别C，典型的分類算法包括支援向量機和決策樹。
圖2-2展示了一些監督學習的場景。
回歸和分類有些相似，但回歸關注連續值的預測。比如，某一資料集中包含了紐約肯尼迪國際機場、舊金山國際機場、芝加哥奧黑爾國際機場的溫度、濕度、雲層覆寫、風速、雨量及當日取消的航班數量，那麼可以用該資料集訓練一個回歸模型，并根據給定的紐約、舊金山、芝加哥的天氣資料使用回歸模型預測當日航班的取消數量。
除了監督學習，機器學習中還有其他的訓練方式，比如無監督學習（unsupervised learning）。無監督學習沒有對訓練資料打标簽，聚類任務是典型的無監督學習，如圖2-3所示。
半監督學習（semisupervised learning）顧名思義就是用一部分打了标簽的資料和一部分沒有标簽的資料來訓練模型。強化學習（reinforcement learning）是典型的半監督學習，強化學習通過觀察以及（基于觀察）做出最大化獎勵函數的決策來進行學習，如果所做的決策産生了獎勵回報則模型被強化，否則模型被懲罰。關于機器學習的學習方法和内容，可以參考其他學習資料。
斯坦福大學計算機系網站上有一個關于深度強化學習的示範頁面，如圖2-4所示。在該示範中，智能體（agent）需要學習在空間中進行導航，學習過程中智能體從灰色蘋果中得到獎勵，從黑色蘋果中得到懲罰。
需要強調的一點是，能內建自然語言處理和自然語言了解技術的一些廣為所知的機器人應用程式在智能方面其實也很淺顯。對于IBM Watson在益智問答電視節目《Jeopardy》上做了什麼一直存在批評，比如Ray Kurzweil在《華爾街日報》評論稱Watson其實并不知道它自己在《Jeopardy》上取得了勝利，了解和分類/抽取資訊是兩個不同的任務。Ray的評論的确客觀，但精心建構的意圖和實體模型在特定的狹窄場景中了解人類語言時被證明是非常有效的，機器人所做的正是這種特定場景下對自然語言的了解。
除了意圖分類問題，自然語言處理領域關注的任務還包括語音标記、語義分析、機器翻譯、命名實體識别、自動摘要、自然語言生成、情感分析等。我們将在第10章介紹多語言機器人及機器翻譯。
20世紀80年代，人們對人工神經網絡（ANN）的研究興趣逐漸上升，在後續幾十年裡，對神經網絡的進一步研究産生了很多重要的成果。對于人工神經網絡中的神經元，最簡單的了解方式是将其視為具有N個權重/輸入和一個輸出的簡單函數。人工神經網絡由許多互相連接配接的神經元組成，它接受一系列輸入并産生一個輸出，并且可以通過訓練神經網絡得到最終的權重，人工神經網絡的結構如圖2-5所示。另外，神經網絡的類型有很多，學術界對它們進行了深入研究，比如深度學習的過程就是訓練在輸入層和輸出層之間有許多隐藏層的深度神經網絡。
谷歌翻譯、AlphaGo以及微軟語音識别都通過深度神經網絡獲得了很好的成果。深度學習的成功是對深度神經網絡結構進行研究的結果，目前十分流行的深度神經網絡包括卷積神經網絡（Convolutional Neural Network，CNN）和循環神經網絡（Recurrent Neural Network， RNN）。機器人應用程式中常常包括機器翻譯、文本摘要和語言生成等自然語言任務，如果讀者想深入了解人工神經網絡如何應用于這些自然語言任務，連結中還有許多其他的資源供你學習和探索。
目前，當資料在不同層的神經元之間前向、反向傳遞時，各層神經網絡做了什麼？這個問題的答案現在尚不完全清晰，可以看到的例子是谷歌翻譯會建立自然語言的中間表達；Facebook建立的AI可以與其他機器人或人類協商，導緻AI能“撒謊”。這些事例已被吹捧成人工智能正在接管世界，實際上它們隻是訓練過程的副作用而已。将來，随着神經網絡複雜性的提升，可能産生更多意想不到的行為，這些副作用可能會更詭異、更解釋不清。
Microsoft Cognitive Toolkit和Google Tensor Flow等工具包的出現，使開發深度學習模型變得更加容易，同時使人工神經網絡模型更加流行。
深度學習技術在自然語言處理領域取得了非常好的效果，尤其是語音識别和機器翻譯。比如，微軟研究院釋出的語音識别系統“在識别對話上可以達到和專業速記員媲美的水
平”；谷歌通過進階深度學習算法将其翻譯算法的譯錯率（在給定的兩門語言之間）降低到55%～85%。然而，在意圖分類等自然語言了解任務上，深度學習的表現卻沒有像其現在被炒作的那麼好，這是因為深度學習隻是機器學習工具包中的一個工具，并不是萬能的“靈丹妙藥”。
2.2 常見的自然語言處理任務
一般來說，NLP所處理的大部分問題都是NLU任務的一部分，與語言的句法、語義和語篇分析相關。不是NLP領域中的每個任務都與聊天機器人開發相關，其中一些任務是意圖分類和實體抽取等高階任務的基礎。
2.2.1 句法分析
句法通常用于擷取文本輸入并對輸入進行分解，與句法分析相關的任務一般比較基礎，句法分析的結果不會被機器人直接使用。将語言輸入分割成詞素（morphemes）以及用某種文法建立表達語言的結構是兩種典型的句法分析。另外，詞性标注可以用于優化使用者的查詢。
2.2.2 語義分析
語義分析的任務是在自然語言輸入中發現語言的含義。語義分析任務在聊天機器人中有很多具體的應用，包括：
- 命名實體抽取（named entity extraction）：給定一段自然語言文本，從中找出相關實體，并标注出其類型（如位置、人），也就是将文本中的詞語映射到實體命名和類型上。命名實體抽取是我們開發機器人時計劃實作的功能之一。
- 情感分析（sentiment analysis）：識别一段自然語言文本的内容整體是積極的、消極的還是中性的。情感分析可以用來識别使用者對機器人回複内容的情感感受，重定向到人工回複，或者用于分析使用者目前所處狀态無法和機器人進行很好的互動。
- 主題分割（topic segmentation）：給定一段自然語言文本，将其分解為與主題内容相關的片段，并提取片段的主題。
- 關系抽取（relationship extraction）：抽取文本中對象之間的關系。
2.2.3 語篇分析
語篇分析是觀察更大的自然語言結構并将它們了解為一個單元的過程。在語篇分析中，我們從文本主體的上下文内得出文本的具體含義。比如，對大量内容進行自動摘要，如公司财務報表。語篇分析在機器人中主要用于指代消解（也叫共指解析，co-conference），指代消解的目的在于自動識别表示同一個實體的名詞短語或代詞，并将它們歸類。比如，在下面一段文本中，“I”指的是Szymon：
2.3 機器人中常見的自然語言了解功能
如果我們打算在機器人開發中運用自然語言了解，則在評估解決方案時需要考慮幾個功能。NLU中最簡單的基本功能是識别自定義意圖和實體的能力，此外以下功能在選擇NLU時是必須考慮的：
- 多語言支援（multilanguage support）：開發者所內建的NLU系統能夠支援多種語言。優化不同語言的經驗很好地展現了開發團隊對NLU的整體把握能力。
- 包含預模組化型：許多系統中包含了與特定域相關的預建意圖和實體，供開發者們在開發時使用。
- 預建實體（prebuilt entity）：我們希望現有的NLU系統能夠輕松地為我們提取許多類型的實體，如數字和日期/時間對象。
- 實體類型（entity type）：NLU系統應該能區分不同類型的實體。
- 同義詞（synonym）：NLU系統應該能将同義詞映射到相同的實體上。
- 通過主動學習持續訓練模型：NLU系統應該能利用使用者的輸入作為訓練資料，進而不斷更新訓練模型。
- 應用程式接口（API）：雖然NLU系統中實作了一些使用者界面供開發者訓練模型使用，但同時也應該提供API來執行這些操作。
- 提供導出/導入功能：開發者的模型應該允許以（如JSON等的）開放文本格式被導入/導出。
使用現有NLU服務的替代方案是開發者自己進行開發，如果讀者正在閱讀本書，那麼你可能沒有足夠的經驗和知識來使自己開發的NLU有效工作，這是另外的話題了。一些易于使用的機器學習軟體包（如scikit-learn）可能會給開發者留下一種印象—在機器人中加入NLU很容易，其實這需要經過大量的優化、調整和測試才能從通用NLU系統中獲得可用的性能名額，這個過程需要花費大量的時間、精力和專業知識。如果開發者對這些技術原理感興趣的話，網上有大量的材料可以自學。
2.4 雲端自然語言了解系統
目前，科技巨頭公司将機器學習部署在雲上作為服務提供給使用者，機器人所需的基本功能都可以通過部署在雲端的機器學習服務獲得。從實際角度來看，這樣做有很多好處：開發人員不必關心為某一問題（比如分類）選擇最佳算法，不需要擴充實作，同時雲還為開發者提供了有效的使用者界面和功能更新，并且優化也是無縫的。如果開發者要建立機器人并需要提供分類和實體抽取功能，則使用基于雲的服務是最佳選擇。在撰寫本書時，以下是一些部署在雲端的自然語言了解系統：
- 微軟語言了解智能服務（LUIS）：LUIS是一個純語言了解系統，完全獨立于對話引擎，它允許開發者自己添加意圖和實體，自己選擇适合的LUIS版本，在應用程式釋出之前進行測試，最後釋出到測試端點或生産端點。此外，LUIS還提供了主動學習的功能，保證模型可以不斷被訓練和更新。
- 谷歌Dialogflow（Api.ai）：Dialogflow的前身是Api.ai，它允許開發人員在滿足特定條件時建立NLU模型并定義轉換流和調用Webhook或雲功能。通路對話則是通過API或通過與許多消息通道內建來實作的。
- 亞馬遜Lex：亞馬遜的Alexa長期以來一直允許開發人員建立意圖分類和實體抽取模型。随着Lex的推出，亞馬遜為機器人開發中的NLU帶來了更好的使用者界面。在作者撰寫本書時，Lex隻有少數幾個消息通道，并且同樣可以通過API進行調用。和Dialogflow一樣，Lex允許開發者使用API通路對話。
- IBM Watson Conversation：Watson Conversation允許開發人員定義意圖、實體和雲端的對話，對話同樣可以通過API通路。在作者撰寫本書時，Watson沒有預定義的通道連接配接器，必須由機器人開發人員自己編寫代理。
- Facebook Wit.ai：Wit.ai已經推出了很長一段時間，包含定義意圖和實體的接口。自2017年7月以來，Wit.ai開始聚焦NLU并移除了機器人引擎部件。此外，Wit.ai與Facebook Messenger生态系統的內建非常緊密。
下一章我們會對NLU做深入探索，屆時我們将使用LUIS進行介紹。作為一個純粹的NLU系統，LUIS具有顯著的優勢，特别是在Bot架構內建方面。雖然目前NLU領域的基準測試不多，但LUIS是市場上表現最好的NLU系統之一。
2.5 自然語言了解系統的商業産品
一些較大的公司也推出了自己的自然語言了解産品，比如IPsoft的Amelia和Nuance的Nina。商業産品通常經過多年開發，非常先進，一些公司專注于IT或過程自動化，一些公司專注于企業内部使用案例，一些公司專注于特定的垂直行業，一些公司則完全專注于圍繞特定用例的預建NLU模型。此外，在某些産品中，我們可能需要通過專有語言編寫和實作機器人。
最後，企業所要做的決策是購買NLU服務還是自己建構NLU服務的兩難選擇。一些提供特定業務解決方案的公司在市場上已經存活了很久，但随着IBM、亞馬遜、微軟、谷歌和Facebook投入這一領域開發，财務支援較少的公司的發展可能會受阻。我認為會有更多提供特定業務解決方案的公司利用科技巨頭提供的産品在專門的NLU和機器人解決方案方面進行創造和創新。
2.6 結束語
我們真正看到了人工智能在NLU領域的普及。多年前，機器人開發人員必須選擇一個已經存在的NLU和一個機器學習庫來建立一個像現在這樣可以直接從雲端獲得服務并進行使用的系統。現在，建立一個內建了NLU、情感分析和指代消解的機器人非常容易。科技巨頭正在挖掘這個空間，為他們的開發者提供工具，為他們自己的平台建立對話體驗。
這對于開發者而言是利好消息，因為這意味着競争将繼續推動該領域的創新。随着該領域研究的進展，分類、實體抽取和主動學習的改進将提高NLU系統的性能，機器人開發人員亦可從中獲益。