作者：李燁，現就職于微軟，曾在易安信（EMC）和太陽微系統（Sun Microsystems）任軟件工程師。先后參與聊天機器人、大數據分析平臺等項目的開發。

朋友：最近忙什么呢？

我：在開發聊天機器人。

朋友：像你這么不會聊天的人，也能開發聊天機器人啊？

我：……

不會聊天的人能開發聊天機器人嗎？如果開發者自己就不會聊天，開發出來的機器人是不是也不會聊天呢？

ELIZA：聊天機器人的鼻祖

我們先來看看世界上第一款聊天機器人吧：1966 年，在 MIT 任職的德裔美國計算機科學家 Joseph Weizenbaum，開發出了一款名為 ELIZA 的聊天機器人程序。

通過運行名為 DOCTOR 的腳本，此程序可以用類似心理學家的方式和人類交談。下面就是一段 ELIZA 和用戶的經典對話：

User: Men are all alike.

ELIZA: IN WHAT WAY

User: They’re always bugging us about something or other.

ELIZA: CAN YOU THINK OF A SPECIFIC EXAMPLE

User: Well, my boyfriend made me come here.

ELIZA: YOUR BOYFRIEND MADE YOU COME HERE

User: He says I’m depressed much of the time.

ELIZA: I AM SORRY TO HEAR YOU ARE DEPRESSED

好暖心的 ELIZA（不是 ELSA），和“她”說話，是不是感覺很治愈？

“她”的制造者引入了心理學家羅杰斯提出的個人中心療法（Person-Centered Therapy），更多強調對話態度、尊重與同理心。Eliza 并不主動提供內容，它只是引導用戶說話。

那么?ELIZA 背后的計算邏輯是什么樣的呢？

簡單得叫人想哭，其實就是一條條模式匹配和字符替換規則，下面是其中幾條：

you are (depressed|sad) * => I AM SORRY TO HEAR YOU ARE \1all * => IN WHAT WAYalways * => CAN YOU THINK OF A SPECIFIC EXAMPLE

用戶說失望/傷心，ELIZA 就回答“我好抱歉啊”；用戶用了“所有”這個詞，機器人就追問一句“以何種方式”；如果用戶說“總是”如何如何， 程序就引導“你能舉個例子嗎”……

ELIZA 項目取得了意外的成功，它的效果讓當時的用戶非常震驚。Joseph 教授原本希望 ELIZA 能夠偽裝成人，但沒有寄予太高期望，讓他沒想到的是，這個偽裝居然很多次都成功了，而且還不容易被拆穿。以致于后來產生一個詞匯，叫 ELIZA 效應，即人類高估機器人能力的一種心理感覺。

ELIZA 無疑是一款會聊天的機器人——很多程序員真應該和 ELIZA 好好學學：跟人說話的時候經常重復一下對方的話，以顯示同理心；經常跟進詢問“到底是怎么回事呢？”，“你能舉個例子嗎？”以顯示對對方的尊重和關注；經常說“好的”，“是的”，“你是對的”，自然就獲得對方的好感了……

但是，這樣一款機器人，真的能解決現實的問題嗎？如果，我需要的不是和人閑聊，而是需要確定，或者咨詢某件事，機器人能告訴我嗎？

對于這樣的需求，ELIZA 恐怕做不到，不過，別的機器人可以。

問題解決型機器人?

Task Completion Bot

問題解決型機器人，存在的目的是為了幫用戶解決具體問題，例如：售前咨詢、售后報修、訂機票、酒店、餐廳座位等等。

基礎三步

和 ELIZA 明顯不同，問題解決型機器人需要提供給用戶用戶自己都不知道的信息。

有鑒于此，問題解決型機器人（TC Bot）需要有自己的知識儲備——知識庫（Knowledge Base），其中存儲的信息用來提供給用戶。

光有了知識還不夠，還需要至少做到兩件事：

理解用戶問題，知道用戶在問什么。

將用戶的問題轉化為對知識庫的查詢。

有了這三者，就可以做到最基本的問題解決了：

多輪對話的上下文管理

如果用戶的每個問題都是完整的，包含了該問題所需要的所有信息，當然上面三步就可以得出答案。

不過人類在聊天的時候有個習慣，經常會把部分信息隱含在上下文中，比如下面這段對話：

提問：今天北京多少度啊？

回答：35度。

提問：有霧霾嗎？（北京有霧霾嗎？）

回答：空氣質量優。

提問：那上海呢？（上海有霧霾嗎？）

回答：空氣質量也是優。

人類理解起來很容易，但是如果要讓機器人理解，我們就需要給它添加上一個專門的上下文管理模塊，用來記錄上下文。

如此一來，支持多輪對話的問題解決型聊天機器人，就需要經歷下列四步來完成。

分層結構

從程序開發的角度，TC Bot 分為三層：

• 輸入輸出：

• • 接受、理解用戶問題

  • 生成、返回答案給用戶

• 中間控制：構建雙向關系

• • 用戶問題=>知識庫知識

  • 知識庫知識=>機器人答案

• 知識存儲：存儲用于回答用戶問題的知識。

聊天機器人的實現技術

從學術研究的角度講，聊天機器人所需技術涉及到自然語言處理、文本挖掘、知識圖譜等眾多領域。

當前的研究和實踐中，大量機器學習、深度學習技術被引入。各種炫酷的算法模型跑在 Google、微軟等IT寡頭的高質量數據上，得到了頗多激動人心的研究成果。

但具體到實踐當中，在沒有那么巨量的人工標注數據和大規模計算資源的情況下，于有限范圍（scope）內，開發一款真正有用的機器人，更多需要關注的往往不是高深的算法和強健的模型，而是工程細節和用戶體驗。

此處，我們只是簡單介紹幾種當前實踐中最常用，且相對簡單的方法：

Solution 1：用戶問題->標準問題->答案

知識庫中存儲的是一對對的“問題-答案”對（QA Pair）。這些Pair可以是人工構建的，源于專家系統或者舊有知識庫的，也可以是從互聯網上爬取下來的。

現在互聯網資源這么豐富，各種網頁上到處都是 FAQ，Q&A，直接爬下來就可以導入知識庫。以很小的代價就能讓機器人上知天文下曉地理。

當用戶輸入問題后，將其和知識庫現有的標準問題進行一一比對，尋找與用戶問題最相近的標準問題，然后將該問題組對的答案返回給用戶。

其中，用戶問題->標準問題的匹配方法可以是關鍵詞匹配（包括正則表達式匹配）；也可以是先將用戶問題和標準問題都轉化為向量，再計算兩者之間的距離（余弦距離、歐氏距離、交叉熵、Jaccard 距離等），找到距離最近且距離值低于預設閾值的那個標準問題，作為查找結果。

但關鍵字匹配覆蓋面太小。距離計算的話，在實踐中比對出來的最近距離的兩句話，可能在語義上毫無關聯，甚至滿擰（比如一個比另一個多了一個否定詞）。另外，確認相似度的閾值也很難有一個通用的有效方法，很多時候都是開發者自己拍腦袋定的。

因此，這種方案，很難達到高質高效。

Solution 2：用戶問題->答案

知識庫中存儲的不是問題-答案對，而僅存儲答案（文檔）。

當接收到用戶問題后，直接拿問題去和知識庫中的一篇篇文檔比對，找到在內容上關聯最緊密的那篇，作為答案返回給用戶。

這種方法維護知識庫的成本更小，但相對于 Solution 1，準確度更低。

Solution 3：用戶問題->語義理解->知識庫查詢->查詢結果生成答案

從用戶的問題當中識別出用戶的意圖，并抽取這個意圖針對的實體。

相應的，知識庫內存儲的知識，除了包含知識內容本身之外，還應該在結構上能夠表示知識之間的關聯關系。

Chatbot 在提取了意圖和實體后，構造出對知識庫的查詢（Query），實施查詢，得出結果后生成回答，回復給用戶。

篇幅所限，后文我們所講的“小白版問題解決型聊天機器人技術方案“，就是基于本 Solution的，感興趣的同學可掃碼繼續閱讀~

總結

以上是生活随笔為你收集整理的不会聊天的程序员，如何开发聊天机器人的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。