如何開發一個特定領域的自動問答機器人(Chat Bot)？

01-05

想做個練手項目，順便跟現在的業務方向結合一下。
比如想做一個教學類的自動問答AI，可以代替老師做80%的日常答疑。在一定的基礎演算法基礎上，每位用戶可以設定自己的問題集。
會編程，AI零基礎，想問一下這個任務應該怎樣分解，需要哪些方面的知識才能做出來

謝邀。趁著快下班(鍾)隨便說幾句...

如果你不要求那種特別智能的問答機器人的話，其實這個項目不難做，而且嚴格意義上和人工智慧的關係不是特別大。從易操作的角度上說，我推薦你使用微軟平台(C#) + Python 來實現這個聊天機器人項目。

----------------------------------------------------------------------------

1. 需求分析架構

首先分析你的需求：

對AI零基礎
有編程經驗和能力
想做一個自動問答機器人(Chat Bot)來代替老師做日常答疑。
* 用戶可以自定義問題集

直白的說，項目就兩個核心需求：1. 提供和用戶的交互 2. 提供準確的答案。

我簡單畫了一個模塊圖，不知道上傳以後的解析度如何。

這個方案中有4個主要模塊，其中控制整個流程的是模塊3：

模塊1：知識庫，也就是一個預儲存問題和答案的資料庫。理所當然必不可少...不然從哪給用戶答案。
模塊2：一個部署在線上的預測模型。這個模型可以是簡單的自然語言+機器學習模型，唯一功能就是根據用戶輸入的問題預測知識庫中最接近的問題是哪一個，所以其實是一個簡單的相似度匹配模型(Similarity Measurement)。如果有可能，最好還能根據用戶反饋並記錄預測是否準確，方便後期的再訓練。
模塊3：一個用於和用戶交互的前端界面和流程式控制制中心。使用適當的平台可以將其部署在雲上並通過主流通訊軟體進行交互，比如微信或者Skype。
模塊4：一個線下的學習模型，可以不斷進行重新訓練並提高上面第2點中提到模型預測的準確度。

以Skype為例，成品聊天機器人使用起來就像和你的微信好友對話，雙擊就可以使用，如下圖。

圖片來源: Microsoft Bot Framework connector for Skype for Business! - Witivio - Blog

2. 流程介紹

當用戶在前端UI，比如Skype(模塊3)，輸入一個問題後。流程式控制制中心會將用戶提出的問題傳給我們部署在雲上的預測模型(模塊2)。預測模型會對用戶的問題進行處理並找到現有知識庫中最接近的問題(模塊1)，將該問題的答案通過Skype返回給用戶。

同時，如果一個問題在知識庫中沒有匹配，或者用戶認為我們的答案錯誤，應該記錄在額外資料庫中。利用這個「用戶反饋資料庫」，我們可以定期在線下(offline)進一步對我們部署在線上進行即時預測的模型進行更新和修正(模塊4)。

3. 需要的平台＆軟體

實現上面所說的這一切，依靠微軟的Azure和Bot Framework平台即可:

MS Azure Cloud：微軟雲服務用於提供資料庫，訓練模型和預測模型所需要的資源如虛擬機。

MS Bot Framework: 這個平台是微軟2016年推出的對話機器人平台。主要編程語言是C#或者Node.js，熟悉C#的話可以用Visual Studio非常方便。這個平台的主要用途就是降低對話機器人的開發成本，使用這個平台後，我們可以很輕鬆的把Skype作為交互界面，而不需要再去開發其他的交互。更多關於這個平台的介紹可以看:

Bot Framework
如何評價 Microsoft Bot Framework ？
CSDN上也有不少使用BotFramework的案例

給大家看一張開發過程中的模擬器長的樣子，找bug和測試都很方便:

圖片來源：Bot Framework 405 Method Not Allowed, 401 Unauthorized and 500, Internal Server Error getting started

MS Visual Studio: 用於開發這個對話機器人。

自然語言和機器學習模型: 根據你的描述不太涉及複雜的NLP或者ML，建議用Python開發即可。對於語言處理中文的話用「結巴分詞」，衡量詞語/句子之間的相似度可以用「word2vector」、「sentence2vec」。至於機器學習模型，更是挑一個簡單的調包即可，比如SVM。這項目本質難度不在機器學習上，而是整合這個系統上。如果到時候大家有了別的模塊，但缺這個模型的話，我可以幫你一起做:)

4. 模塊整合

年初花了幾個月做了一個類似的項目，側重點在機器學習上因此用了複雜的預測模型。而對話機器人只是交互手段，方便我們在客戶的平台上部署。

而題主的這個項目難點不在於單獨每個模塊，而是將這些模塊整合起來成為一個產品。Skype和Bot Framework可以用微軟提供的API進行整合，和資料庫之間的互動可以用C#裡面之間連接抓取。

整個項目中最麻煩的是如何將模塊2(預測模型)與其他部分整合。我的建議是在雲上部署一個虛擬機，在虛擬機上寫一個最簡單Flask Web App，並使用 Flask-Restful提供Restful API給其他模塊使用。如果有條件的話，也可以直接在雲上部署一個含有預測模型的Flask App，這下就不需要在勞什子的使用虛擬機了。

好了不多說了，我要去接客了(手動滑稽) ?????

@阿薩姆講的這個，就是我們組在做的東西哎。

項目傳送門：Enterprise Deep Intelligence (EDI) - Microsoft Research

這個 Prototype 現在還是在 Beijing Office 小範圍試用中。可以訂會議，設 reminder 等等這些基礎功能；現在正在迭代的功能就包括 FAQ 問答系統。跟題主描述的應該是十分類似的。

題主還可以看一下前段時間微軟辦的比賽 Microsoft 編程之美 2017。這個比賽就是讓學生們用微軟的 LUIS.ai(Language Understanding Intelligent Service) 和 Bot Framework 來開發一個可以回答關於你們學校的各種問題的 Bot。比賽說明頁面給到了很多開發資源和入門教程，題主可以多參考一下。

------

下面說點個人的理解。

問答系統可以實現的非常簡單，也可以難度非常大。全看你對機器人的要求有多高。

問答系統有兩個比較重要的性質，一個是 domain，一個是輪次。Domain 分 close-domain 和 open-domain，輪次分單輪和多輪。

目前學界對 close-domain 的單輪問答系統研究已經非常成熟了，拿「Single turn QA System」去 Google Scholar 上搜大把的 paper。Open-domain 的單輪問答系統也已經有了許多不錯的研究成果，例如 Facebook 這份工作 [1704.00051] Reading Wikipedia to Answer Open-Domain Questions，就是利用 Wikipedia 的知識來回答 Open-domain 的問題。

而多輪問答系統目前在學界都還是一個成果寥寥的領域，也是我們組很多人目前在努力的方向。結合題主描述的情況，我覺得題主嘗試一下單輪的就足夠了。

實際上我們組有同學現在就在做 Single-turn FAQ Matching 的任務，我在做 Multi-turn 的，但是方法都是相通的。 @阿薩姆描述的流程也較為詳細，我做些補充。

首先你需要維護一個知識庫，就像你問題中描述的那樣

每位用戶可以設定自己的問題集

就是簡單的 QA pair 即可。

用戶每輸入一句話時，要識別用戶意圖並匹配到對應 QA，或者匹配失敗告知用戶 Bot 不知道這個問題。這一步我們通常稱為 Intention Classifier，我最近剛好寫了一篇文章講我的處理：MSRA 搬磚小記 | 類 One-Hot 方法的 Sentence Level 文本相似度匹配。由於場景不完全一樣，具體 Sentence Embedding 方法可能不一定適用，但是預處理和 Word Embedding 都是通用的。

@阿薩姆提到這是「相似度匹配模型(Similarity Measurement)」，更加準確的說，best practice 是 Ranking 模型，即針對用戶輸入，給全部待選 QA 打分，並取出最好的（或前 N 好的）。有時人們會把這一步處理成 Classify 模型，但其實這樣後續是有不少問題的，比如 Not-Found 如何匹配。這裡面再繼續還可以深入，題主說對 AI 零基礎，就不多展開了。

關於 Sentence Embedding，不建議用某些庫自帶的 sentence2vec function，效果很差。Sentence 及以上級別的 Embedding 在學界仍然是有待研究的問題，現在並沒有特別好用的工程輪子。這部分如果考慮簡單實用的話，建議用 TF-IDF Word Embedding Sum 來做，或者我專欄里寫的 One-Hot。如果題主有需要可以評論我，待會可以給你找一個 Text Similarity 的綜述過來。

百度理解與交互技術平台UNIT|幫助開發者大幅降低對話系統研發門檻

不懂編程，想找一個平台來實現物流領域的問答集。題主現在什麼進度了？

客服系統機器人產品設計詳解|智能回答

原創 2017-10-20 KEVIN Kevin改變世界的點滴

關於客服系統中的機器人

客服系統的興起是基於滿足降低公司人力成本、維護精力的需求，一套客服系統的產品設計，上次有分享過史上最詳細的客服系統產品落地|後台產品經理的工作實例，有那麼苦嗎？，但除了工單管理、客戶管理、以及客服系統的BI，其實最為困難的就是如何提升客服系統的使用效率。

就客服系統的使用效率，其根本就是是否能夠為企業降低人工服務的次數、仍共服務的時間佔比，甚至是提升公司的營業業績。在這裡面，我落地的客服系統其佔比最終的還是機器人回答。

【機器人問答的產品設計】

但機器人回答的發展期間，機器人的回答方式也在如今也是基於關鍵詞匹配與大數據結合的情況下發展的。

【APP端機器人客服】

【WEB端客服】

產品落地中，調研到目前國內的方法在中文分詞中，現在有三大分詞演算法

第一類叫做基於字元串匹配的分詞方法

第二類基於理解的分詞方法

第三類基於統計的分詞方法

相對於早起的純關鍵字匹配，現在國內的機器人也是基於NLP（自然語言處理技術也逐漸在興起），作為PM的我們，到底要如何去落地機器人問答系統？我談談我的案例分享

01知識庫的建立

如果說從0-1做客服系統，那麼機器人的模塊從一開始規劃中最為重要的就是建立知識庫，這個知識庫的重要性在於以後的模型建立。

那麼問題來了，什麼是模型？

【對話模型】

日常生活中，我們所知道的模型就相當於是一個模具，一個模具的可以作為一點，其製作更多產品，把模型做的越好、越精確，在量產中就會得到更準確的結果。

更加精準、更加快速

那麼對話模型，就是我們這裡提的一個模型。在不同行業中，我們可以知道起用戶發文的內容範圍、回答的範圍是不同的。

那麼如何訓練模型，簡單來說就是通過對話找到問題的答案，答案的問題

【問題與答案的訓練】

【答案與問題的訓練】

這裡提一個關鍵詞：語料

預料你可以理解問一些詞庫，不過這個詞庫不同的是他會包含更多測試詞語、句子、符號等數據，而詞庫則是我們知識庫中最為關鍵的一個匹配詞庫。

既然要考慮模型和語料，我們首先要考慮公司的業務是什麼？這就是所謂的特定領域，再到全局領域

目前這些語料都有網上的一些公開的包，PM可以去下載了解下是否符合公司的業務。通過這些語料包，可以去知道語氣詞、標點符號、違規敏感等

這裡從特地領域的語料，簡單舉個列子在金融證券行業，最為關鍵的語料就是：公司產品名稱、股票名稱、公司名稱、常用服務名稱

這些都算語料裡面的詞庫，在一個公司建立知識庫中，我是按下圖進行分類組合

既然上面的邏輯關係清楚了，我們可以清楚知識庫是起著機器人回答的一個重要部分

【網易7魚】

從上面的圖可以看到，其知識庫時候為了分類管理，提供了一個分類管理的模塊，並且將問題與知識庫進行關聯。

【知識點與FAQ】

將問題匹配進入相應的知識點，機器人也需要知道諧音、或包含問題以外的其他內容，如何去掉無效內容，匹配問題答案。

【相似詞庫】

建立相似詞庫的意義就是為了方便機器人把相似處看作同義詞進行理解，把問題進行匹配。

在知識庫中添加問題與答案，我們這裡落地首先要考慮問題與答案的對應關係。

也就是在對話模型中，一個問題是否會對應2個答案，一個答案是否會對應2個以上的問題？

【知識庫添加】

最好的方式是利用EXCEL文檔的方式整理，將文檔導入上傳。這裡我借鑒了一些客服系統的機器人中心文檔，將他們的文檔進行歸類，整理了如下模版

這樣的話，公司即使沒有客服系統，但通過日常的文檔歸類，也可以快速的建立詞庫。

01基於字元串的匹配演算法

在產品設計中，這套系統還是基於字元串匹配的演算法。利用正相最大匹配、逆向最大匹配分、以及最小切分

那麼什麼是正向匹配演算法？

正向最大匹配演算法：從左到右將待分詞文本中的幾個連續字元與詞表匹配，如果匹配上，則切分出一個詞。

但這裡有一個問題：要做到最大匹配，並不是第一次匹配到就可以切分的。我們來舉個例子：

待分詞文本如下：

content[]={"產"，"品"，"經"，"理"，"從"，"此"，"站"，"起"，"來"，"了"，"。"}

詞表： dict[]={"產品"， "產品經理" ， "從此"，"站起來"}

這裡CONTENT[1]開始進行從左到右正向掃描，那麼掃描到第一個content[1]，這個時候掃描的為「產」字，掃描到第二個content[2]，這個時候掃描到[產品]；和dict[1]匹配上了，但是因為字數才2個字，需要為3個字，就繼續這樣向下掃描。

循環處理，最終將詞語掃描出來。但這樣掃描出來的結果可能為：產品/產品經理/從/此/站起/來，或產品/產品經理/從/此站起/來......

等結果，利用最小切詞，切詞的換算方式，但當然既然採用的是基於字元串匹配的分詞方法，其劣勢就在這裡，切分為導致歧義問題。

因此我們會把逆向最大匹配、正向最大匹配、最少分詞結果進行綜合匹配。最少分詞就是將針對正向、逆向的問題，將雙向切分的結果進行比較，選擇切分詞語數量較少的結果。

機器人知識庫初始化

機器人在設置中，建議一開始沒有詞庫的時候，產品經理需要考慮一些基本詞庫，這些詞庫是公司名稱、公司產品、微信公眾號、網站地址等

【機器人初始化】

這樣設計的理由很簡單，這是公司的基本問題或回答。在這套客服系統機器人是對外或甚至以後運營盈利情況下，方便客戶首先設置好自己的基本機器人資料。

除了以上的機器人基本詞庫以外，還有機器人寒暄詞庫，並且產品設計中要對每一個類型的詞庫回答進行限制。

比如當問了3個問題，都無法匹配到機器人的答案，機器人應該以轉換人工的提醒方式或回答方式，讓用戶去尋找人工解決辦法。

【切換人工】

在當前的機器人系統中，在這個產品設計我一直定位該產品是輔助於人工客服去減少工作量，增加工作效率。機器人並不能完全替代人工，所以時刻保持機器人與人工的切換，讓用戶能夠獲得好的解決體驗。

總結

在當下科技不斷發展的時代，都說是AI的時代，從以前的大數據到如今的AI時代，智能機器客服系統就是典型的一個產品。

雖然對於PM來說，客服系統的難點在於如何去跑通公司客服業務流程，建立起一套好的服務流程。

1.分擔客服工作量

2.積累客服經驗，不斷完善問題庫

3.自定義機器人樣式，模擬人工聊天。

但難點也在於如何通過人工客服去積累學習更多的知識，以及通過數據渠道獲得客服以及所在客戶行業的專業基礎知識。

和你有同樣的想法，想做校園生活智能問答機器人。我覺得最難的是領域知識構建，重點是收集這些訓練集，演算法和開源工具選擇的話，都不是難事。

其實我覺得這個還是得對基礎的機器學習等有一定的了解的，不然都使用別人的東西，做出來的結果也肯定是抄襲出來的。

如果是用C#，推薦使用開源的項目 Kwoth/NadekoBot

地址是：

Kwoth/NadekoBot

如果是用java，推薦開源的項目 DV8FromTheWorld/JDA

地址是：

DV8FromTheWorld/JDA

其實我個人感覺搞這個東西最好的語言還是python，夠簡單，而且很容易上手。

推薦的是 gunthercox/ChatterBot

地址：

gunthercox/ChatterBot

@阿薩姆 @駱梁宸已經回答得很好了，我補充幾個我自己遇到的問題。

訓練數據, 在實際場景中某一領域的訓練數據通常很少( &< 500 條)，這時候可能需要考慮遷移學習；
Not-Found問題，對於有些情況，需要識別為這個query不回答，針對這個也是個難點；
DL模型和NLP模型, 在QQ的Similarity Measure上, 我們實驗下來確實BoW出來的更可靠些，靠DL會出現難以解釋的回答錯的情況。
數據迴流，單單構建完這個模型可能還不夠，還需要考慮數據閉環。

===========================

ALIME | 專註服務的會話機器人平台