內容來源：宜信技術學院第3期技術沙龍-線上直播|AI中台——智能聊天機器人平台
主講人：宜信科技中心AI中台團隊負責人王東
導讀：隨着“中台”戰略的提出，目前宜信中台建設在思想理念及架構設計上都已經取得了很多成果。宜信是如何借助中台化的思想打造“AI中台”及相關的智能產品呢？本次直播，宜信科技中心AI中台團隊負責人王東老師分享了宜信AI中台的具體實施路徑，並重點介紹了AI中台的智能產品——智能聊天機器人平台，包括智能聊天機器人平台的背景理念、設計思想、技術架構和應用場景，該平台能提供什么樣的能力，以及它如何快速地支持業務方，提供一種以中台化的思想來建設智能產品的實踐思路。
視頻回放：https://v.qq.com/x/page/q0904bcjlkn.html
——————
前兩期技術沙龍分別分享了宜信AI中台和數據中台的建設實踐，本次分享將先回顧AI中台的總體設計和實施路徑，以及AI中台與數據中台的關系，再詳細介紹基於中台思想建設的智能聊天機器人平台，包括其技術架構、技術原理、核心功能點、應用場景以及應用效果。
一、AI中台總體設計和實施步驟
1.1 業務演進與廣泛的智能化需求
隨着業務的不斷發展，業務處於不同的發展階段，對數據的需求也從剛開始的可用-滿足BI分析，到后來的易用-敏捷化分析，到現在的好用-數據智能化。例如前台系統提出客戶細分、個性化推薦、智能問答、模型預測等需求，后台數據探索需要進行關聯分析、聚類分析、持續分析等，這些都向我們提出了數據智能化的需求。
- 數據平台化能夠解決數據可用性的問題，提供數據的平台化管理、數據存儲、數據計算、管理、運維等功能；
- 數據中台化可以解決易用的問題，提供自助化、敏捷化的支持，並為數據的資產化、融合化、運營化提供支持。
- 數據智能化解決了好用的問題：從數據洞察到學習預測，數據驅動創新。
1.2 從數據中台到AI中台
數據中台除了提供平台能力以外，還提供了一些更高級的能力，比如把數據變成一種基礎服務提供給業務方，業務方可以以自助的方式在數據中台上獲取數據、進行數據處理、數據探索、數據挖掘、分析鑽取、多維分析、自助化報表、數據分享等，以快速實現自己的商業價值。
隨着業務的發展，越來越多智能化的數據需求被提出，這些智能化需求涉及到模型訓練、數據標注、特征工程、模型部署、性能監控等，需要使用機器學習、深度學習等算法支持。數據中台的主要目標還是服務數據，對於智能化和模型並不能很好地支持，因此AI中台應運而生。
我們把智能服務的需求抽象出來，形成一個獨立的AI中台層。AI中台是一個用來構建智能服務的基礎設施平台，對公司所需的模型提供分布分層的構建能力和全生命周期管理的服務，鼓勵各個業務領域將基礎性、場景性、通用性的AI能力沉淀到平台中，加強模型復用、組合創新、規模化，最終實現降本增效和快速響應業務方的目的。
1.3 數據中台和AI中台的關系
既然提到了數據中台和AI中台，很多人會問：數據中台和AI中台是什么關系呢？
數據中台和AI中台兩者是相互依存、承前啟后的關系。
首先，數據中台和AI中台都對外提供服務，只是側重點不同。
- 數據中台提供各種數據服務和數據產品，例如：BI報表應用、數據探索等。
- AI中台提供各種智能服務和智能產品，並承擔復雜的學習預測類智能需求研發、模型訓練、特征工程、數據標注等能力。例如：模型預測、智能推薦等。
其次，數據中台和AI中台是相互依存，相互支持的。
- AI中台依托數據中台提供的數據能力和工具集，加速AI相關服務的開發和復用，來應對前台智能化的業務需求。有了數據中台清洗好的數據，搭建智能項目能夠事半功倍。
- 數據中台也需要使用AI中台的智能化能力，使得數據使用更加平民化和智能化。例如增強型BI分析：通用自然語言交互方式，降低BI使用門檻；通過AI分析給出參與建議，幫助普通用戶在沒有數據專家的情況下有效訪問數據；增強型數據管理：利用機器學習來管理數據，包括數據質量、元數據管理、主數據管理等。
1.4 AI中台需要解決的痛點
在過去，很多算法團隊更像是算法外包團隊，根據不同業務線的需求，各自構建陣地，逐個攻克目標。這樣的形式雖然也取得了很多成績，但存在重復建設、效率有限的問題。
我們將這些問題總結如下：
- “煙囪式”開發，項目成本高、不易集成，過程重復，缺乏能力沉淀。
- 模型訪問方式各異，調用關系錯綜復雜，缺乏編排優化、協同。
- 手工進行數據操作，缺少統一數據訪問渠道，數據獲取難、標准不統一。
- 模型研發缺乏標准指導、參與角色眾多，缺少協同、自動化輔助，難以有效管理溝通協作。
- 模型交付難，缺少統一的模型運行、監控平台、服務管理接口及更新、維護機制。
- 基礎資源分散隔離，無法動態進行資源的分配和管理，造成浪費。
這些都是AI中台需要解決的痛點，針對以上痛點，我們希望：
- 對於算法、模型的標准化平台化，對研發過程標准化指導，以提高可復用性。
- 統一的服務接口規范，支持服務的動態編排組合。
- 與數據中台對接，利用數據中台的能力對數據進行標准化處理和預處理。
- 流程優化，清晰角色定義，構建AI產品流水線，具備環節內部、環節之間的自動迭代、流轉功能。
- 提供統一的模型交付部署、運行環境和監控能力，以及模型更新機制。
- 統一資源管理，包括計算資源、存儲資源等，支持資源彈性調度。
總結起來就是：可復用化、服務統一化、對接數據中台、流程角色優化、運行監控化和資源管控化，最終讓AI中台成為一個強大的AI能力支持中心，根據業務需求快速提供火力支援，迅速完成商業價值。
1.5 AI中台平台架構
下面介紹AI中台的平台架構。
最下面是數據中台，提供數據處理、數據分析、數據管理、數據安全、數據服務等能力。最上面是業務前台，包括各條業務線。AI中台處於數據中台和業務前台的中間位置。
如圖所示，整個AI中台由幾個模塊組成：
- AIHub智能服務：以服務的方式將模型封裝起來，提供模型服務運行平台能力。包括模型發布測試、自動部署、模型更新、模型交付、產品封裝等。
- AIMon平台監控：對運行的模型進行監控和預警，提供平台的監控服務。包括性能測試、狀態反饋、預警通知等。
- AIKit智能工具箱：提供輕量級、低侵入的AI工具服務，AI應用團隊可以自由選用。例如：通過無縫嵌入python語言開發環境，Moonbox可以提供虛擬查詢數據、混算數據等能力。也提供數據標注能力，包括結構化數據，以及文字、圖像等非結構化數據的在線標注。
- AIMgt中台管理：AI中台的一些通用管理能力。包括：角色權限、租戶管理、流程控制、資源管理等。
- AILab智能試驗室：提供標准的模型訓練與優化過程支持。包括模型設計、模型訓練、特征工程、特征處理、模型追蹤、模型評估、算法庫、模型庫等。
- AIAsset智能資產：用於模型資產管理，實現AI能力沉淀、復用、盤點。
- CUI會話式UI：這是我們AI中台的一個產品，就是接下來我們要介紹的可用於問答、閑聊、任務、推薦等場景的聊天機器人平台，從機器人平台的角度也包含語音外呼機器人。
1.6 AI中台的能力架構
上圖展示AI中台的能力架構。我們以能力的角度來描述AI中台對外輸出。除了前文介紹的服務運行能力、監控預警能力、資源管理能力（就是圖中左邊的幾個模塊）以外，我們把AI中台的能力分為4層：
1）平台層
比如數據獲取能力、在線訓練能力、在線標注能力、特征工程能力、自助訓練能力等。這些能力是通過AI工具集和AIlab來實現的。
這層的用戶主要包括：
- 算法工程師（AI中台、AI團隊），他們可以使用AI中台提供的平台層能力來進行在線訓練、復用算法庫、復用平台計算資源、進行各種實驗等。
- 高級研發人員、數據分析人員，他們可以使用AI中台的自助訓練能力，進行自助訓練，例如：根據自己已經標注好的數據，自助訓練分類模型。
2）AI技術層
AI技術層主要提供：AI基礎能力，包括詞法分析、語音合成、文章分類、圖像識別等，這些本質上是AI技術NLP、語音、圖像、視頻等大分類里的能力。
3）AI業務層
AI業務層主要提供AI技術與業務相結合后能提供的能力，比如：評論觀點提取、文章標簽、卡證類識別、人臉識別、視頻審查等。
AI技術層和業務層的區別在於：AI技術層主要提供AI基礎能力，比如NLP、CV、語音、視頻等。而AI業務層主要是將AI技術與具體的業務場景結合起來，例如身份證識別、學歷識別、驗證碼識別等。
這兩層的用戶是：業務團隊的應用開發人員，可以直接調用智能服務，從而實現業務場景智能化，例如：短文本相似度、語言合成、票據識別等。
4）產品層
這一層以產品的形式對外提供服務，例如：智能機器人產品、知識圖譜產品等。
這層的用戶是：公司的業務人員或公司的直接客戶，他們通過直接使用產品就可以獲得結果， 例如：機器人。
上面3層都屬於AI資產。從影響力角度來看，產品層的影響力最大，依次下來是業務層、技術層，最后是平台層。我們在AI中台的實施路徑上，也會按照這個優先級去構建和實施。
1.7 AI中台的建設思路-開放性
數據中台的口號是平民化和敏捷化。AI中台的口號是開放化。
AI中台的建設思路是希望多方聯合，公開透明，廣泛參與，協商一致促進AI能力沉淀，加強AI服務復用，降本增效。
我們更加關注於通用性的AI需求，為各個領域的AI應用團隊提供通用化智能服務。強調平台性和可復用性，鼓勵基礎類、場景類AI服務的通用化、平台化。
廣泛支持大中小業務領域AI應用團隊面臨的大量智能業務需求，提供模型學習平台與模型運行監控托管服務以及通用的AI工具，方便前台業務快速上線智能應用。在實施過程中也會充分利用包括數據中台在內的現有技術資源，並根據業務需求強弱和重要性來確定實施路線。
我們希望AI不再是錦上添花，而是必備的能力，讓開發者重新回歸到業務的理解和創意的賽道上來，關注自己的業務邏輯。AI能力將會全部開放給開發者和使用者，這些能力包括語音、視頻、自然語言處理、知識圖譜等，我們會將這些能力封裝好，開發者直接調用就可以。
二、機器人平台的背景、設計理念和技術架構
2.1 智能聊天機器人
基於中台化思想，我們是如何建設機器人平台的？
智能聊天機器人，是一種通過自然語言模擬人類進行對話的程序。
目前，特定場景和領域的聊天機器人已經展現出了很高的自然語言理解與處理能力，例如：小度、Siri、小愛同學等。
智能聊天機器人可以代替企業中相對固化、重復的人力密集型任務或流程，包括：
- 問題咨詢：基於業務知識庫進行業務問題解答。
- 數據檢索：縱跨各業務系統或數據庫，檢索數據或文檔。
- 業務處理：對接相關業務系統轉達指令，完成相應業務操作。
典型的應用場景：智能聊天機器人除了可以閑聊以外，還可以用在問答作為問答機器人，回答專業領域的問題；作為任務機器人完成線上，甚至部分線下的任務；作為推薦機器人，推薦文章、音樂、產品；作為助理機器人，集成以上各種功能。
智能聊天機器人可以對外提供客戶服務、對內進行業務輔助，實現全方位的效能提升，降本增效。
2.2 智能聊天機器人的本質：會話式UI
智能聊天機器人的本質是會話式UI。會話式UI是通過會話形式將已有數據、功能、服務展示給用戶。
會話式UI與傳統UI相比，具有獨特的優勢。
- 提高用戶注意力。在信息碎片化的今天，用戶注意力持續集中的時間不多，人們很容易為各種事情分心。在會話式UI中，信息是根據用戶的指令需求逐步提供的，這樣用戶就不會被無關的信息干擾。
- 減少用戶的挫敗感。在會話式UI中，用戶能進行的操作相對有限，這也避免了因用戶行為帶來不可控的高錯誤問題。讓用戶做簡單的選擇題，能降低用戶思考的成本和系統錯誤率，最終能夠實現讓用戶快速聚焦他們想要的東西，減少因操作帶來的挫敗感。
- 更高的投入產出比。會話式UI的另一個優勢是性價比高。會話式UI用戶界面上線后立即就能投入工作，不需要刻意進行訓練學習，降低了使用成本，並且可以根據商業邏輯及應用情況隨時將對話設計進行調整修改。
正如三星實驗室高級設計師Golden Krishna所說：“最好的界面就是沒有界面”。很多人認為語音交互比聊天機器人的干擾更小，能提供更好的使用體驗。
這也是導致各種智能音箱在市場反響火爆的原因，語音交互已經走進千家萬戶、世界各地。
2.3 趨勢：會話式UI與業務集成
目前會話式UI與業務系統緊密集成，是發展的主要趨勢。通過集成各個業務系統，可以打造出專屬的業務助手。如上圖所示，我們可以將報表查看、指令集成、知識圖譜查詢、查詢郵件等諸多服務集成到業務系統中，並且提供權限審核的功能，從而打造一個專屬的業務助理。
一些行業預測認為：
- 未來，更成熟的技術使得聊天機器人能夠更准確地識別用戶的問題和意圖。
- 客戶服務是聊天機器人的主戰場，是產生最大效益的領域。
- 聊天機器人在電商、通訊、保險、金融、旅行等領域廣泛應用。
- 以大數據的增強型分析為例，使用自然語言NLP等交互方式，BI使用門檻進一步降低。
Gartner預測到2020年：50%的分析查詢會通過搜索、自然語言處理或語音生成，或自動生成。一線業務工作人員通過自然語言處理和會話分析，來進行分析和使用商業智能產品的使用率從35%提升到50%以上。
2.4 智能聊天機器人建設過程
接下來詳細介紹聊天機器人建設的過程。
智能聊天機器人建設是有難度的，比如機器人的智能化核心開發需要一定的AI研發能力；機器人需要全套的模型封裝，以及數據管理、任務調度、權限控制等工程能力的支持等；各業務線均有廣泛的需求，一個個實施起來將是很漫長的過程。
如果按照一條線一條線建設的方式，如圖所示，AI同事和平台同事支持第一個業務時，沒有其他業務線的需求進來，按照項目的支持能夠快速響應需求，這時的體驗是很好的；而對於第二個業務來說，此時由於AI同事和平台同事正在支持第一個業務，第二個業務線的功能就會有所缺失，可以看到圖中業務線B的機器人少了一條腿，這時就產生了等待；到第三條業務線，已經進入了需求排期階段，AI同事和平台同事對該業務線的支持就很有限了；同樣的，后續的業務線都將處於等待狀態，盡管業務方很生氣，可AI同事和平台同事已經疲於奔命。
由此可以看出這種煙囪式機器人研發的缺點：耗時長、成本高。
那么如何才能高效地支持這些需求呢？
2.5 機器人工廠
以中台化思維來建設智能聊天機器人平台。通過平台化的建設、復用化的思想，使得我們的聊天機器人成為聊天機器人制造工廠。
- AI模型復用化：AI工程師構建通用AI模型，僅需少量具體的業務數據即可構建一個個性化的機器人核心。
- 工程能力平台化：平台化建設，提供一套全面的、通用化的機器人管理功能，將各種能力沉淀下來，實現工程模塊和能力復用化。
我們在構建智能聊天機器人平台的過程中，將各個業務線的需求和能力都集成到平台中，提供給不同業務線使用，各業務線都復用這些能力，並且提供數據權限的高度隔離。
最后達到機器人流水式生產，管理功能高度復用，業務用戶高速接入，迅速賦能全部領域。
2.6 智能聊天機器人平台設計考量
智能聊天機器人平台的設計考量包括以下幾個方面。
1）平台化or項目制
既然我們用平台化方式去建設，就必然面臨一些問題：平台化的好處是可以復用，事半功倍；缺點是難以兼容個性化。所以我們在平台建設過程中，要同時考慮什么樣的功能屬於平台、什么樣的功能屬於租戶、什么樣的功能屬於公司，把公共的功能進行沉淀、把租戶的功能進行定制化，這樣才能既兼顧平台化的事半功倍，又能滿足個性化的需求。
2）中台能力
- 多租戶。我們以多租戶的方式建設智能聊天機器人平台，基於用戶角色來定義功能，平台管理員和租戶功能進行能力划分。
- 自助化。所有功能自助化，管理和運維工作下放給租戶，這樣一來，租戶就可以對自己的機器人進行相應的管理，平台的維護也會減少很多，而且不用再等排期。
- 隔離和安全。通過資源隔離（包括數據隔離和語科隔離）、算力隔離等將成本分攤計算出來，也可保證數據之間互相不影響。另外，基於功能角色和數據角色的雙重角色正交的方式保證數據安全。
4）統一閉環
- 智能機器人平台是一個工程、算法、運營統一的結果。機器人不是一個簡單的算法模型，需要模型運行、數據管理、權限控制、人工介入、客戶端支持等，還需要運營的支持和鼓勵，比如我們平台中引入的積分系統，根據積分情況來開展一些運營活動，鼓勵大家使用一些功能。
- 通過運行過程中不斷補充問題、在線標注、語料導出、自動訓練、自動上線形成平台、數據和模型的閉環。比如我們開發了會話管理來進行在線標注，幫助用戶快速補充問題。
2.7 智能機器人平台系統架構
上圖所示是智能機器人平台的系統架構。
- 最上面是機器人對外提供的服務，通過Web、APP、Restful API對外提供服務。
- 中間是一個微服務層，使用Spring Cloud微服務架構，服務都注冊在Eureka里。微服務包括了網關服務、調度服務、外部服務、商業邏輯服務、數據訪問層、統計服務、通訊服務等。其中涉及到算法預測的模塊是在Python的一個服務里，我們也將Python的服務注冊到Eureka里，這也是我們稱之為“模型即服務”的一種思想。
- 外接認證系統包括LDAP、SSO、PS等，外接系統包括各種PC端、APP端、報表等。
- 數據存儲在Mongo中，文檔存儲在HDFS里，檢索使用Eleastic-Search，統計使用Click-house，人工后台通訊用Rabbit mq，會話和上下文管理使用Redis。
整個平台是微服務架構，支持容器化，支持使用Conductor模型編排，用MQTT協議以解決APP端網絡不穩定的問題。
三、機器人平台的核心原理和主要功能點
3.1 機器人的核心技術
前文介紹了機器人平台的背景、設計理念和技術架構，接下來介紹機器人平台的核心原理和主要功能點。
智能聊天機器人最核心的部分是對話引擎，對話引擎包括：自動語音識別(ASR)、自然語言理解(NLU)、對話管理(DM)、自然語言生成(NLG) 和文本到語音合成(TTS)。
其中，自然語言理解（NLU）的目標是將文本轉換成語義表示，文本中的單詞語義並不重要，重要的是文本轉化成了語義信息。簡單來說，就是將人的語言轉化成機器可以理解的結構化的完整的語義，讓機器理解人的語言。
我們通常說的NLP自然語言處理其實是一個大的集合，包含了NLU自然語言理解和NLG自然語言生成，並且包含了它生成上面的處理部分和下面的應用階段，所以NLU和NLG都是NLP的一個子集，它們不是平級的關系。
DM是對話管理系統的大腦，負責更新對話狀態。對話引擎的難點在NLU和DM。
總的來說，這些技術都是屬於自然語言處理技術（NLP，Natural Language Processing），本質上我們需要使用NLP技術來解決聊天機器人的問題。
對於用戶的一個問題，需要將這個自然語言問題通過一個模型（這個模型是我們用機器學習基於大量數據訓練和歸納得出來的），轉換為機器能理解的數據形式(我們將這種數據形式稱之為向量)。
NLP技術除了用於智能聊天機器人以外，還用在很多領域，例如：句法語義分析、信息抽取、文本挖掘、機器翻譯、信息檢索、對話系統等領域。
3.2 機器人原理
智能聊天機器人是由多個機器人組成，包括問答機器人、閑聊機器人、任務機器人等，人工后台以及文檔庫之間協作完成任務，最終選擇最優答案返回給用戶。
如圖所示，用戶提一個問題過來：
- 首先ASR將語音轉成文本，這時候涉及到了調度。平台服務和任務調度認為這是一個機器人的問題，就進入預處理階段。
- 預處理包含分詞/去停、詞表映射、詞性分析、句法分析、實體識別、句子復述、關系提取等；
- 然后進入分析階段，包括領域分析、問題分類、意圖檢測以及bot識別等；
- 然后轉到不同的機器人，比如QA機器人-解答用戶對事實和非事實類的問題、閑聊機器人-解答用戶情感方面的表述和對客觀問題的討論、任務機器人-滿足特定場景的任務操作、場景機器人、知識圖譜機器人等；
- 之后將結果匯集到融合排序層，進行加權重排答案矯正；
- 最后經過用戶權限過濾，生成答案，將答案經過TTS合成語音反饋給用戶。
如果這個問題機器人不能解答，就會轉入人工后台，或轉到搜索引擎進入文檔的搜索檢索，最終將最優答案返回。
3.3 QA機器人
QA機器人的本質是：假設用戶提了一個問題Q，QA機器人需要從已有的QA數據庫中尋找最合適的QA對返回，QA機器人會進行QQ相似度計算和QA匹配度計算，通過綜合相似度與匹配度，找到最適合的一組QA對 (Qi, Ai)，即最佳答案返回。
解決方案1：NN模型
常見的網絡模型包括RNN和CNN模型。例如雙層編碼(Decoder)的長短期記憶模型（LSTM）。這種模型在很多場景下都比較好用，網絡模型的主要缺點是需要一定數量的樣本。
解決方案2：拆分成子問題。
在語料比較小的情況下，將問題進行拆分，分為兩個階段：
- 把問題變成一種短文本語義表征，通常有tfidf、w2v。
- 然后再進行語義距離計算，例如計算向量的余弦距離。
它的優點是在語料比較小的情況下效果不錯。
3.4 QA機器人原理(QQ匹配）
這里以QQ匹配來介紹QA機器人原理。
QQ匹配包括幾個部分：句向量化、相似度計算、相似度排序。
- 句向量化是使用BoW詞袋模型和同義詞擴展，將句子的詞轉換成向量；
- 然后再與問題庫里的詞進行相似度計算，計算出余弦相似度；
- 用余弦距離產生相應的結果，按照相似度大小排序返回答案列表。
句向量我們是通過詞袋模型和同義詞擴展來表示的。
什么是詞袋模型？詞袋模型就是忽略文本里的詞序、詞法、句法，只將它看做一個詞的集合，把它當成一個詞袋。
還引入了同義詞擴展。在實際的問題中，不同的詞可能存在不同的問法，但其語義相同，所以進行一些同義詞等價，這樣就形成了詞向量。向量的值是TF-IDF值，用於表示權重。
TF-IDF模型（term frequency–inverse document frequency，詞頻與逆向文件頻率）。TF-IDF是一種統計方法，用以評估某一字詞對於一個文件集或一個語料庫的重要程度。TF-IDF的主要思想是，如果某個詞或短語在一篇文章中出現的詞頻高，並且在其他文章中很少出現，則認為此詞或者短語具有很好的類別區分能力，適合用來分類。
TF-IDF有兩個值，一個是詞頻率，另一個是IDF（inverse document frequency，逆向文件頻率）。如圖中的計算方式。
舉個例子，庫中10000篇文檔，10000篇提到“母牛”，其中10篇提到“產奶量”，比如一篇關於“母牛的產奶量”的文字，這篇文章有100個詞，“母牛”出現5次，“產奶量”出現2次)。
通過計算發現，雖然“母牛”的詞頻率很高，但IDF值很低，最后“母牛”的TF-IDF很低，也就是說這個詞不具太大的標識度。而“產奶量”這個詞的詞頻率不高，但它的辨識度很高，最終它的TF-IDF也很高。
具體執行過程如圖所示，首先拿到一個語句，進行分詞、去停用詞、去重，得到一個詞序列。然后遍歷每一個詞進行TF-IDF計算，如果在同義詞表里，就計算詞TF-IDF並求平均值；如果在詞庫中，就計算TF-IDF值；如果不在詞庫中，就直接忽略，最后形成詞對應的TF-IDF值，並將Value向量單元化。
接下來我們要計算向量和向量之間的距離，這里我們采用余弦距離。計算方式如圖所示。
當兩個詞向量的余弦值接近1的時候，兩個詞向量相似，也就是兩個句子相關。否則就不相關。通過計算余弦值來最終達到判斷句子的相似度。
上文介紹的QQ匹配是屬於一種基於檢索的聊天機器人，另一種對應的分類是基於模型生成的表情機器人。
基於檢索的聊天機器人：
- 特點是回復數據是預先存儲且知道（或定義）的數據。
- 優點是問題與答案都經過人工總結，保證了數據庫中的答案正確性，表述自然、易於理解。
- 缺點是用戶提問的各種問題，機器人都試圖在庫上尋找答案；問題數有限，無法覆蓋用戶的所有問題；需要不斷總結、擴展，爭取覆蓋大多數問題。
生成模型的聊天機器人：
- 特點是創造出嶄新的、未知的回復內容（模型沒有見過），類似機器翻譯技術。
- 優點是不需要預先存儲且定義好的數據，比起檢索模型更加的靈活多變。
- 缺點是生成效果不佳，生成的答案可能有一些語法錯誤和語義無關的內容；生成式模型需要海量的訓練數據，且難以優化；結果無法控制。
目前的現狀是，在商業領域，工業級標准還是會使用基於檢索的機器人，適合特定領域內、問題集合有限，還有一些變體，比如知識圖譜、基於KG的機器人、基於搜索引擎的機器人。而生成模型的機器人，是學術界研究的重點，在商業領域，它會作為檢索式機器人的補充形式，兩者結合使用，
3.5 閑聊機器人原理
閑聊機器人主要是進行客觀話題討論，用戶對聊天機器人進行一些情感表達，回答問候、情感和娛樂等信息。閑聊處理由兩個組件組成：
- 基於預置規則匹配：公司合規用語要求。
- 基於聊天庫中海量閑聊語料：滿足大多數閑聊應答。
海量的閑聊語料，可以從在線論壇、微博對話、甚至別的通用機器人爬取，雖然從各個地方爬取，也需要審核，以滿足用戶需求。
閑聊機器人的要求是：簡單閑聊、結果可控、快速開發。所以實現上我們基於AIML構建閑聊機器人。
AIML是由Richard Wallace發明的一種語言。他設計了一個名為 A.L.I.C.E.（Artificial Linguistics Internet Computer Entity 人工語言網計算機實體）的機器人，並獲得了多項人工智能大獎。AIML是一種為了匹配模式和確定響應而進行規則定義的XML格式。
AIML的能力很靈活，如圖所示，可以基於模板匹配、任意字符匹配、元素提取、一個問題多個答案、划分主題等。
AIML來作為知識載體的好處是靈活、人性化強。缺點是在知識的編寫方面門檻高，比如閑聊庫的擴充方面的問題等。
好在有現成的AIML編輯軟件，如：SimpleAIMLEditor，GaitoBotAIMLEditor等。
AIML語言的規范也在不斷升級，最新版本AIML2.0。
3.6 任務機器人原理
任務機器人（Task-Bot） 的關鍵技術是基於意圖識別與語義槽提取。 舉個例子，A說“幫我訂一個今天下午3點到4點的會議室吧？要大一點的。”機器人識別出來這是一個任務，而這個任務要完成必須三個語義槽：時間、地點、大小。
經過分析發現A的任務請求中缺乏一個語義槽-地點，於是觸發機器人反問“請問您要預訂哪個職場的會議室？”，A補充了地點后，機器人聯動會議預定系統，進行會議室預定，完成任務並反饋結果給A。
這個過程涉及了：意圖識別、關鍵參數提取、多輪對話&對話管理、配置化、對接外部系統。
以上圖的一個實際例子來看，這個例子是根據身份證號查詢歸屬地。
- 首先配置可能的問法，這里可以看到，設置的可能問法越多，越能幫助機器人識別意圖。這里主要涉及到意圖識別和設置可能問法。
- 然后配置需要提取的槽值，槽值來自一個實體，這里的槽值是身份證。並且配置如果沒有提取到的話，需要追問的問題。可以在線進行測試槽值提取。
- 接下來配置觸發的外部系統，這里支持常見的post，get，將相應的槽值發送給系統，然后獲得返回值，再從返回值中提取必要信息，用於顯示正確情況和錯誤情況。
- 最后看到的效果如上圖所示，整個過程涉及到多輪對話和話題追蹤。
3.7 場景機器人原理
場景機器人可以說是任務機器人更高級的版本，它是基於預置規則驅動完成場景任務。
上圖示例中，銷售人員G想查客戶李國強的信息，機器人給出相應信息后，根據預設的場景，觸發后台配置的一個業務推薦流程，根據這個流程，銷售人員可以獲得適合李國強客戶的產品推薦、了解相關產品情況、進行話術演練等，本來只是一個聊天過程，跳轉到特定的場景以及業務相關的聯動，這就是場景機器人。場景機器人的場景和相關業務跳轉都是可以配置的，這樣可以達到動態化地支持不同的場景。
場景機器人與場景綁定、結合場景相關話術和跳轉規則，可以做：客戶畫像查詢、產品信息查看、場景演練、面見話術等，還可以進行交叉銷售、客戶關聯查詢。
3.8 KG機器人原理
KG機器人，即知識圖譜機器人，本質上是一種語義網絡，其結點代表實體或者概念，邊代表實體、概念之間的各種語義關系。KG機器人是基於知識圖譜推理給出結果，也是基於檢索型機器人的一種。
相較於純文本，知識圖譜在問答系統中具有以下優勢。
- 數據關聯度：語義理解程度是問答系統的核心指標。在知識圖譜中，所有知識點被具有語義信息的邊所關聯。從問句到知識圖譜的知識點的匹配關聯過程中,可以用到大量其關聯結點的關聯信息。這種關聯信息無疑更為智能化的語義理解提供了條件。
- 數據精度：回答准確率高，知識圖譜的知識來自專業人士標注，或者專業數據庫的格式化抓取，這保證了數據的高准確率。
- 數據結構化：檢索效率知識圖譜的結構化組織形式，為計算機的快速知識檢索提供了格式支持。
這些優勢都促使我們在構建智能聊天機器人平台時使用知識圖譜來作為問答系統的知識來源。
舉個例子，這是保險的知識圖譜，包含了：查詢實體屬性-平安境內旅行險一個月多少錢？查詢關系以及屬性-能保骨折，且承保時間在5年以上的保險有哪些？查詢簡單關系-平安境內旅行險能保意外骨折嗎？查詢復雜關系-想買一個能保骨折，並且能夠在海口市的三甲醫院報銷的保險。
這些本質上都是在進行圖查詢，查詢實體的屬性，查詢實體和實體之間的關系等。
知識圖譜機器人構建過程中：
- 首先第一步是定義知識圖譜的領域知識，上述例子中我們相當於在面向對象定義實體、屬性、關系等，三元組（實體、屬性、關系）的關系定義好了以后，才可以構建圖譜模型。
- 接下來是提取信息，這個過程涉及到大量的訓練、在線標注等，需要從現有的表單、文檔中將需要的信息提取出來，並將提取的信息導入第一步構建的模型中。
- 然后是知識問答。需要從問句中提取實體、屬性、關系。在這個例子中，重大疾病險的等價詞是重疾險，重疾險是一個實體，結腸癌也是一個實體。最后問句就被轉換為一個實體和實體之間關系的預測。
當用戶問問題時候，把問句轉化成圖計算，機器人通過知識圖譜進行查詢計算，並轉化為答案反饋給用戶。
3.9 模型編排
除了上述各種機器人之外，聊天機器人平台還涉及到模型編排和模型管理的部分。比如有的業務只需要QA機器人，這時通過預處理，調用QA機器人，經過角色權限過濾就可以提供服務了。有的場景可能需要多種機器人進行合作，這就涉及到路由/群發，群發機器人的結果還要進行融合合並。
模型編排，將不同的模型進行組合，以可視化的方式對調用的模型順序進行編排，支持拖拽式配置。
模型本身是需要服務化的。我們的實際模型本身是一些python服務，我們將這些python服務進行封裝，進行服務的統一管理，這樣的話就可以對模型定義統一的接口，還可以進行自動化的更新，比如通過定時模型訓練去更新此模型，其他模型不受影響，如上圖所示的模型手動更新和自動更新。同時我們可以進行單元測試和鏈路測試。
3.10 智能聊天機器人能力
目前平台已能夠支持：
- 多類型機器人集成功能，包括問答、任務、閑聊等；
- 復雜情景會話：包括多輪對話功能、話題追蹤功能等；
- 多渠道機器人交互終端；
- 統一的機器人管理框架；
- 完善的人工客服能力支持；
- 全面的數據記錄與統計。
3.11 機器人平台功能
聊天機器人平台主要功能包括以下幾個方面。
- 聊天機器人平台。聊天機器人平台的前台有機器人應答、QA、文檔檢索、關聯檢索、離線消息、會話歷史、常見問題、問候語等功能。后台包括搜索引擎是否介入、反饋設置、外觀設置、場景設置、模型配置等功能。
- 人工后台。人工后台包括客服工作台（在線會話、會話歷史、會話轉單、會話排隊、邀請會話、客戶信息顯示、快捷回復等功能）、客服管理、技能組管理等。
- 會話管理。瀏覽會話導出、查詢歷史會話、對歷史會話進行在線分類評分，添加QA問題。
- QA/文檔管理。瀏覽編輯、全文檢索、問題分類、等價問題、批量上傳語料、生成水印、查看文檔權限。
- 任務管理。對於任務機器人來說，功能包括任務配置、實體管理、任務更新、模型配置等。
- 閑聊管理。對於閑聊機器人，功能包括閑聊庫管理、全文檢索、語料導出、模型更新管理。
- 報表統計。包括會話統計、文檔/QA統計，人工后台服務分析、用戶提問句雲活躍度排名、用戶積分、用戶行為覆蓋等。
- 模型管理。包括模型編排、模型啟停更新、自動維護發布上線、模型預測等測試環境功能。
- 認證支持/外部系統對接。包括PS對接、LDAP對接、SSO對接/各種外部系統對接。
1）機器人前台
機器人預置了web交互頁面，支持機器人全部的功能。包括對話、留言反饋、轉人工、查看歷史消息；可直接嵌入PC端和APP端業務系統等。
在上圖的例子中可以看到，前面部分是我們的常見問題列表，用戶問了一個問題，然后找到一個匹配該問題的答案。如果用戶給出的問題比較簡單，如上圖，只給出“宜人貸”，就沒辦法命中一個獨立的問題，這時除了匹配答案以外，還會給出一些與該問題相關聯的問題，這種我們稱之為關聯問題。也可以轉到搜索引擎，通過搜素引擎的相關問題。
實際上，對於檢索模型的聊天機器人而言，當FAQ中沒有合適的答案，我們返回的是FAQ中與問句最相近問句-答案對中的問句，而不是答案，這樣可以從用戶提問中得到更多信息，以便返回更真實的答案。我們在實踐中發現，用戶通過這樣的關聯，只需要幾次點擊就能找到真正想要的答案，其滿意度會得到提升。
2）知識庫
這是機器人的知識庫，知識庫包含了一些分類信息，支持相應的數據角色、文檔的數據顏色格式，還包含瀏覽編輯、全文檢索、問題分類、批量上傳、語料生成、水印生成等功能。
3）人工后台
這是機器人的人工后台。人工后台上線后，用戶可以跟人工后台的客服人員聊天，在這個過程中也可以上傳圖片。與機器人問答不同的是，機器人模式中用戶只能發文字，而與客服人員聊天，可以上傳文檔、插入表情、請求評價等。在這里還可以做快捷回復、查看知識庫、文檔庫、客戶本身的信息，還有一些智能回答。
這是客服工作台的功能，可以從隊列里調出相應的客戶進行會話，解決不了的問題可以轉交給別的工作台的客服解答。
4）會話管理
接着來看會話管理。上圖左邊是這個人對應的歷史聊天信息，我們可以檢索並定位到他認為回答不好的問題，進行在線快速補充添加新問題。每一個問題的評分都會顯示，既能幫助算法同事，也能幫助運營同事進行在線信息維護。
5）統計分析
機器人平台還提供數據統計和分析功能，這一功能是基於Davinci數據可視化工具完成的，可以自定義數據指標，比如機器人服務時長、服務執行度等。還可以進行報表統計：會話統計、文檔QA統計，人工后台服務分析、用戶提問句雲、活躍度排名、用戶積分、用戶行為覆蓋、使用明細。
6）模型管理
機器人平台還提供通用化模型運行托管平台，它是一個高可用運行架構，可以進行模型封裝、發布、啟停、更新管理，還包括自動數據更新機制、統一服務訪問接口等。
7）多租戶和角色權限
機器人平台提供多租戶和角色權限管理的功能，並且在公司里提供用戶的自動導入，通過配置相應的角色和權限，自動導入成機器人的用戶角色權限。這樣一來，就不用維護用戶本身了，可以跟不同的業務系統直接對接。
機器人平台的其他功能，諸如任務配置、閑聊配置、積分管理、對接外部系統等功能此處不一一展開。
3.12 機器人發展階段
如圖所示為智能聊天機器人平台的發展階段，我們已經完全了前面階段的機器人功能建設，包括問答、人工后台等。目前我們處於第三階段向第四階段演進的過程，最終我們希望達到業務領域系統性CUI整合，即通過機器人會話，以場景式機器人的方式展示給客戶，成為機器人助理。
四、智能聊天機器人平台的應用場景
4.1 智能客服機器人
智能客服機器人的初衷是解決客服管理部的痛點。
宜信有很多線下門店，這些門店中的銷售人員有大量的問題，涉及到政策、法規、流程、管理等眾多方面，這些問題都會通過內部溝通工具蜜蜂或郵件集中到客服管理部來解答。
- 溝通的過程中，因為人數和問題量太大，重復工作多、問題難跟蹤，知識難沉淀、缺乏問題的統計、無法針對性的培訓。
- 對於門店客服和銷售人員而言，人工回答等待時間很長，影響工作效率，客服容易情緒急躁，人工解答也不標准。
- 對於客戶來說，等待時間較長，影響客戶體驗、解答不標准、影響品牌認知。
引入智能客服機器人以后，80%的問題被機器人攔截，剩下的20%轉到人工后台，減輕了客服管理人員的壓力。
智能客服機器人目前服務於所有一線的客服同事，成為客服管理重要的日常工具。客服人員只需要通過手機就可以操作，實現了運營管理智能化從0到1的過程，幫助運營人員減輕壓力，提升運營效率。
4.2 財富智能助手機器人
財富銷售過程中涉及到很多產品（基金、保險等），需要了解產品知識、政策法規、銷售話術等。同事希望能有一個知識型的助手，協助解答在銷售過程中遇到的諸多知識盲點，提高專業度。
我們計划使用聊天機器人小助手與現有手機app結合，實現產品、客戶、知識一站式服務。
如上圖所示，財富智能助手並不是直接調用機器人平台，而是通過API方式調用機器人平台，然后去詢問各種支持銷售的問題。
目前財富智能助手機器人覆蓋所有一線銷售和業務支持人員，解決投前、投中、投后、銷售政策等問題，提高了業務專業度、響應速度，提升業務拓展效率。
4.3 保險智能機器人
第三個場景是保險智能機器人。微信用戶存在大量相關問題咨詢，使用人員來回答的話疲於應付，回答也不專業，人力成本很高，希望通過機器人對售前類問題提供咨詢服務，代替人工，完成售前信息交互，大幅減少人員成本，提高回答准確的和精准度。
如圖所示，保險智能機器人基於第三方知識庫提供查詢：包括保險類術語查詢、疾病庫查詢、險種查詢、醫院庫等保險知識大全；基於知識圖譜和推理的1~3度內查詢等，例如：條款明細請問這款產品有猶豫期嗎？我孩子5歲可以買這款產品嗎？重疾險都包那些疾病？還可以做常見售前售后意圖判斷、保險費用預計算。
4.4 AIOps運維機器人
最后一個場景是AIOps智能運維機器人，AIOps是一個很大的話題，涉及到海量數據的存儲、分析和處理。數據包括：歷史數據、流數據、日志數據、時序數據、異常數據等。整個系統由許多小工具集成成為一個大系統。AIOps還包含自動模式發現和預測、異常檢查、根因分析等需要模型支持等方面。
這里我們主要關注入口：文本輸入。
在日常運維中，當出現異常時，運維同事收到手機、郵件或短信報警，希望通過手機APP，以自然語言方式查看獲得當前系統狀態、隨時隨地了解當前系統，甚至可以通過運維執行命令來解除故障。
比如可以通過手機APP調用任務機器人去查詢后台系統中網絡占用的一個時序圖，把這個圖以報表的方式返回到前端。使用機器人可以有效降低信息過載問題，調用相關接口，直接找到目前最重要的問題並返回。當發現系統出現故障時，可以通過機器人發送命令，重啟服務解除故障。
五、總結
- 基於AI中台的思想和實踐。智能聊天機器人采用平台化建設方式，使得機器人可以快速復制。第一個機器人從研發到上線用時6個月，接下來是5個月上線，4個月上線，2個月上線，6周上線，最新的項目是3周完成上線。
- 支持多業務線、系統無縫對接，同時響應個性化需求。產品從立項以來支持公司普惠金融、財富管理的諸多重要業務方，支持PC端、APP端、restful api接口對接。
- 覆蓋同事廣，服務時間長。支持一線同事數萬人，累積回答問題數十萬次以上，累積會話時長近千小時。
- 運營效果好，節省人力。據統計，有效回答（機器人回答占總回答比例）在80%以上，錯誤反饋率在5%以下(反饋無用的比例)。
- 產品種類全。包括問答機器人、閑聊機器人、任務機器人、知識圖譜機器人、以及基於場景的交互式機器人（如產品推薦、問卷調查、催收銷售等）。
- 提供工程、算法和運營統一的一站式智能聊天解決方案。比如在線查看標注會話和知識更新、自動化語料導出和模型更新、數據、算法和運營形成閉環。
六、Q & A
Q1：語音外呼機器人如何用數據驅動做話術質量評估？比如：要定位哪些話術節點高頻發生客戶無回應、打斷或投訴等，但機器人語音播報里是含多個變量參數的，而且文本會話存儲是按ASR識別音轉文的，和配置機器人時的固定話術格式不一樣，這樣一來導致句子量級非常龐大，這種如何統計呢？
A：語音外呼機器人其實是一個統稱，一般來說會具體到一個領域，並且和特定場景相結合。比如：電銷促銷機器人、售后快遞送貨機器人、語音催收機器人等。
以售后快遞送貨機器人為例，機器人通過語音電話通知客戶，將快遞送到家或者指定快遞櫃等。
在這種特定場景里，主要是要進行話術編排，費時間的也是在話術編排上，需要充分結合業務場景特點，由機器人向客戶發問，對客戶可能回答的方式進行歸類（與具體業務方一起根據現有人工話術可能的回答進行分類）和統計，這樣就方便對無回應、投訴等話術進行評估了。
最終用戶的回答都會被引導到有限的話術邏輯中，從而達到電話外呼的目的。句子量級龐大，但話術是有限的，不會特別巨大（我們目前場景中的話術都是和業務方一起合作總結的）。
另外，這種場景機器人的配置頁面與分享中提到的任務機器人還不完全一樣，有其單獨的話術編排配置。
Q2：老師提到使用similarity的chatbot，請問這樣的chatbot只是做intent識別嗎，對於slots的填充是怎樣處理的呢？
A：基於相似度的模型用於問答和閑聊機器人。任務機器人的處理基於專門的意圖識別模型和實體識別模型來做。
意圖識別模型，由於我們要做的是通用化、自助化、彈性化，所以設計了一個輕量級的自訓練意圖識別框架，基於用戶提出的少量語料，通過句子成分分析提取特征，並對特征進行分析而成，其中主要涉及到語言學知識，少量統計學習方法，優點是自訓練需求算力很少、解釋性強、准確率高、用戶完全可以隨意添加各類新的任務。
槽值提取基於NER和意圖識別中的句子成分分析開展。NER自帶通用的時間、地點、人名、組織等實體識別，通用實體由於語料充足，其識別利用了ML、DNN等模型。此外考慮到專業領域里的專有槽值實體（例如合同號、公司內部部門名稱、員工編號等等），我們允許用戶自行配置列表實體、正則實體等。
Q3：第二種使用模型對intent和slots識別，請問里面的slots識別是character-level的還是word-level的？如果是word-level的,怎樣處理cut-word不准帶來的問題?
A：槽值中通用實體的識別基於word-level，專有的實體識別比較復雜，常見的情景中如果是列表實體，那么我們在分詞階段已經將列表實體名稱加入分詞表；正則實體直接做正則匹配。
之所以采用這種NER方式，主要就是降低用戶每次新建任務、實體后模型框架自訓練的開銷，使其可以迅速動態加載新的意圖識別和槽值提取task。
Q4：第一個機器人從開發到上線用了六個月，機器人平台開發用了多久呢？
A：因為是按照平台化的思維去建設，實際上第一個機器人開發的時候，機器人的模型部分和機器人平台是同步進行的，團隊成員包括算法同事和平台研發同事，以兩周一個小版本的速度，在與第一個客戶一直保持密切交流的情況下，隨時改善用戶體驗，總共花了6個月的時間，第一版的機器人模型和平台同時完成。
第一版主要包含QA機器人、QA庫管理、文檔庫管理、會話管理、模型自動更新等主要功能。閑聊機器人、任務機器人等都是后面版本迭代增加的。
其實機器人模型、QA庫不斷完善、模型自動更新、問題反饋、統計報表等都是一個統一的整體。單純只重視任何一方面，例如只重視算法模型，忽略特定業務場景的語料，忽略運營的支持，都會導致機器人不好用，體驗差。在實際運營中，算法、平台和運營都需要形成閉環，進行有效溝通。這樣才能把平台和機器人建設得更好用。
來源：宜信技術學院