本文根據車好多NLP方向負責人王文斌老師在DataFun“AI+”Talk—— “Application of AI In Second Hand Market”中分享的《對話機器人在瓜子的實踐》編輯整理而成。
今天主要分享以下幾個方面，首先介紹下什麼是對話機器人，然後講一下技術選型的過程，設計了怎樣的演算法架構和系統架構，最後分享下線上的效果以及在瓜子中面臨的一些挑戰。
目前對話機器人很火，是有多方面原因的：第一，圖靈在定義智慧時就將對話機器人作為人工智慧的一個標誌；第二，深度學習技術越來越成熟，對話機器人在工業界已經達到一定水平；第三，對話機器人由於有智慧客服的積累，有很多公司在做這方面的東西。上面是一個智慧客服設計圖，左邊是接入渠道，登入進來，會提供一些客服產品，如機器人客服、人工線上客服、雲呼叫中心，以及使用者依據產品做一些自助服務。聊天過程中使用者會將其資料留下來（反饋資料、對話資料、人工客服資料），利用這些資料就可以做分析，如客服資料可以做質檢，使用者資料可以做營銷工作，與CRM接入打通。
接下來講一下會什麼要有對話機器人，開始瓜子目標就是提高效率，用機器替代人，達到縮減人力和培訓成本、7*24小時線上服務、質量可控的目標。在發展的過程中概念慢慢昇華到一個線上化的概念，就是數字化、資料化和智慧化。數字化就是將使用者和企業互動的資料都記錄下來，將資料結構化，做成演算法可用的資料叫資料化，有了資料化就可以用建模等一系列智慧化手段做一些智慧化提升。線上化做後可以做到整個溝通可追蹤、提供可優化、差異化的服務以及精細化運營，最終推動企業線上化。
線上機器人是線上聊天的一部分，既是整個服務閉環的入口也是出口。使用者可以在聊天中表達和解決相應的訴求，而搜尋、推薦更像是一個被動的過程，IM是一個主動表達訴求的門戶。
對話機器人的分類：開放式的有微軟小冰、度祕；任務導向的有訂機票、詢問天氣。從角色定位角度，如提供IM通道其實就是架構，只有有了骨架才能做相應的應用，演算法在裡面是一個關鍵的作用，後期其實更多的是偏產品化的東西。對話機器人技術是透明的，區別在於誰做的細節更完善。開發的角度就是完善三個檢視，客戶檢視： 對話內容、對話方塊、對話方塊外推薦資訊；客服檢視：對話上下文、客戶畫像、背景資訊、訂單畫像，管理者檢視：控制檯、知識庫。
對話機器人經典流程：語音喚醒，告訴你要幹嘛，喚醒之後經過語音識別轉化為文字，這時候可以做語義理解（其中可能需要知識庫互動），將語義理解的結果通過對話管理引擎拿到使用者對應的話術，將對應的話術轉化為文字，最後轉化為語音輸出。
說明下對話機器人的核心概念，如“幫我定一張明天上午10點從北京到上海的機票”，這句話的意圖就是“訂機票”。槽位就是如果要完全理解一句話並且能夠夠返回結果資訊還需要什麼屬性，這句話槽位資訊有：起飛時間 = 明天早上10點，起始地 = 北京，目的地 = 上海。
接下來講一下技術選型，這是對話機器人選用技術調研的過程。對話機器人開始是基於關鍵詞，然後就是模板技術，目前很多公司還在使用，優點是質量可控、準確率高，其缺點就是泛化能力比較弱。隨著功能不斷迭代，模板很大程度依賴於人工，不能自主提升自己的泛化能力。然後有了基於搜尋的對話機器人，有很強的業務適應能力，其缺點就是準確率低。最近幾年深度學習火起來後，利用深度學習替換原來的模型進行意圖識別，意圖識別相對傳統方法準確率提升很大，但是缺點就是對資料質量要求較高。
模板可以部分自動生成，如果上線也需要應用方自己稽核與補充，話術也需要應用方自己去配置。搜尋技術更多的是先用意圖識別做一個路由器的功能，然後路由到一些小的robot，每個robot做一類事情。深度學習與傳統分類方法做的事情類似，也是在做多意圖的意圖分類，確定意圖後會通過一對一或其他配置方式將其關聯回答。
下面是一個模板演算法，“泉州過戶到廈門會不會很麻煩”，這個模板在前面沒有出現過，就無法匹配，需要將模板提取出來，固化到知識庫、模板庫中。
對話機器人發展到後面越來越注重運營，有一個管理平臺，就是知識庫。固化知識，給運營提供管理入口。前面例子就是維護問題到模板以及模板到回答的對映關係，人工需要做很多稽核以及一些校對的工作。而搜尋方案，將query經過預處理打散成terms，進入搜尋系統，如果按照原始結果會得到一個排序“泉州到廈門過戶問題，泉州到廈門遠嗎，泉州到廈門怎麼坐車，泉州到福州過戶問題，泉州到廈門過戶問題”，最後得出結果與查詢一致，將最相近的query回答返回。而解決排序不正確的方法就是需要海量資料。
接下來講一下深度學習的演算法架構，深度學習應用很多，以對話機器人而言，基礎技術如分詞、詞性、實體識別都可以用深度學習，資料好的話會比傳統方法好。還有搜尋架構中的相似度計算、用來排序的一些特徵也可以用到深度學習的方法。我們是從整個結構來看就是一個深度學習的架構，這也是學術界研究的熱點。
深度學習知識庫我們解決就是意圖與答案一對一的關係，回答對話術本身要求很嚴格，幾乎是一個純人工的過程，有很多人蔘與業務運營。如果是單輪就是一個多分類問題，更重要的是如何建立一種機制將問題積累過程與上線後模型的演進過程變得更加自動化、質量更可控。除了剛才它談到的技術還有其他方法如生成模式，學術界較火，主要是應用於閒聊。我們最後選用深度學習模式，考慮的原因有以下幾個方面，就是不再需要人去抽取大量的特徵。
語義理解的流程，包括快速識別、模型識別、搜尋識別、相似問題，在這個流程中應用了很多技術。我們採取的是一個漏斗方式，開始是快速識別（需要實時解決），在快速識別弄一個白名單用關鍵詞或模版匹配立刻糾正，原則是必須準確率要高。90%的問題是依據模型框架，準確率也在90%以上，有了前面兩步，後面是在補充召回的過程，通過搜尋系統藉助文字相似度的匹配將一部分資料召回，儘量讓使用者更多的問題被識別。
接下來介紹下多輪，我理解多輪是一個更偏工程的過程。裡面更多的演算法是在做槽位解析，需要做好三件事，第一個就是填槽，如果對話過程中槽位未補全，在下輪對話過程中引導使用者補全槽位資訊。再者就是場景管理，需要維護海量使用者的聊天資訊。第三點就是可配置，多輪最後面都是一個業務問題，開發一個可配置的介面，讓運營自行配置其需要的對話。多輪的邏輯是在知識庫裡配置的，DM是和業務無關的，只需要按配置的解析結果執行即可。
按照上面設計還是會出現風險，常見的五個風險有：任何演算法的選擇都只是滿足當前的需求，資料是歷史資料，演算法是當前反饋，業務演化過程不可知； 模型互搏，各種模型都要去做A/BTest確定哪種好那種壞，之前更多的判斷是從原理上判斷；意圖爆炸，目前知識庫是基於意圖回答一對一關係，業務相對收斂，但是未來發展速度可能導致意圖不可收斂； 主觀標準的反覆，很多過程都由人工參與，每個人評判標準不一；模型更新滯後於業務發展，技術發展較快。解決方案就是永遠保持主動，提前應對。
系統架構：前端有一個對話方塊和訊息伺服器，類似於IM基本架構，訊息伺服器會將訊息路由到對話管理模組（中控）。使用者聊天文字會在中控識別意圖和槽位，通過意圖在知識庫中獲取對應的話術。知識庫有一個控制檯，與外部互動的介面，對話管理也會訪問後端雲服務，比如通過ip地址獲取其屬於哪個城市，除此外還有語義理解、CRM服務等。
線上效果，左邊是一個單輪對話能力，無論問如何貸款都能準確識別，右邊是一個動態API，類似於知識圖譜想要完成的工作。
在瓜子遇到的挑戰：首先是資料，不管做什麼都需要資料。運營，這方面主要是對話機器人自學習的能力，如何設定一些機制使運營能夠滿足當前業務效果，跟上業務發展速度。最後是產品化，如何將產品細節做得足夠好。
舉例：第一個就是資料來源，以一定規則構造資料，或利用非結構化資料通過遷移學習訓練embedding向量，將向量作為意圖識別的原始輸入，或模型產生資料反哺模型，不斷迭代。第二個就是話術的確認流程，編輯發起修改，業務反饋，編輯確認，稽核，法務，上線，這是一個理想的模式。人與人之間的平衡： 回答的標準，新增意圖的標準，產品和演算法的平衡： 意圖預判、suggest、相似問題、下一個問題，業務和技術的平衡：卡片訊息，就是線上化，後臺服務如何讓使用者利用起來。
使用者從不同的業務入口進來看到的問題列表是不同的，從不同業務階段進來看到的問題列表也是不一樣的。後續希望做到不僅根據業務狀態還要基於歷史資料做一些推薦。對話機器人可以做很多事情，如目前我們正在做的精準營銷，通過多輪對話完善使用者訴求，給出更加精準的推薦。
下面更多是一種理念，打通CRM等內部系統，可以利用資料做商業智慧，覆蓋售前、售中、售後所有場景，使用者溝通可追蹤可優化，精準營銷，從客服轉化為專家顧問，實現使用者服務線上化和企業線上化，最終實現整個企業的智慧化。
作者介紹：
王文斌，車好多NLP方向負責人。碩士畢業於北京大學，曾就職於美團、百度等公司，在編譯器、瀏覽器、IM、大資料等複雜系統研發上有實踐經驗，並在搜尋推薦、知識問答、資料探勘、機器學習、NLP等演算法方向有豐富的積累。加入車好多後發起了智慧IM專案，實現了對話機器人的成功落地。
團隊介紹：
瓜子NLP團隊，以chatbot等產品，增加人效，提高服務質量，讓瓜子逐步加大服務線上化的比例。團隊承載瓜子服務線上化的重任，是未來瓜子發展的重要基礎能力之一。
——END——
本文由DataFun社群首發，社群公眾號ID：datafuntalk