對話機器人在瓜子的實踐

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