對話機器人在瓜子的實踐

本文根據車好多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——

推薦閱讀：