AI中臺——智能聊天機器人平臺的架構與應用（分享實錄）

內容來源：宜信技術學院第3期技術沙龍-線上直播|AI中臺——智能聊天機器人平臺

主講人：宜信科技中心AI中臺團隊負責人王東

導讀：隨着「中臺」戰略的提出，目前宜信中臺建設在思想理念及架構設計上都已經取得了不少成果。宜信是如何藉助中臺化的思想打造「AI中臺」及相關的智能產品呢？本次直播，宜信科技中心AI中臺團隊負責人王東老師分享了宜信AI中臺的具體實施路徑，並重點介紹了AI中臺的智能產品——智能聊天機器人平臺，包括智能聊天機器人平臺的背景理念、設計思想、技術架構和應用場景，該平臺能提供什麼樣的能力，以及它如何快速地支持業務方，提供一種以中臺化的思想來建設智能產品的實踐思路。

——————

前兩期技術沙龍分別分享了宜信AI中臺和數據中臺的建設實踐，本次分享將先回顧AI中臺的整體設計和實施路徑，以及AI中臺與數據中臺的關係，再詳細介紹基於中臺思想建設的智能聊天機器人平臺，包括其技術架構、技術原理、核心功能點、應用場景以及應用效果。

1、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、機器人平臺的背景、設計理念和技術架構

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、機器人平臺的核心原理和主要功能點

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、智能聊天機器人平臺的應用場景

4.1 智能客服機器人

智能客服機器人的初衷是解決客服管理部的痛點。

宜信有不少線下門店，這些門店中的銷售人員有大量的問題，涉及到政策、法規、流程、管理等衆多方面，這些問題都會經過內部溝通工具蜜蜂或郵件集中到客服管理部來解答。

• 溝通的過程當中，由於人數和問題量太大，重複工做多、問題難跟蹤，知識難沉澱、缺少問題的統計、沒法針對性的培訓。
• 對於門店客服和銷售人員而言，人工回答等待時間很長，影響工做效率，客服容易情緒急躁，人工解答也不標準。
• 對於客戶來講，等待時間較長，影響客戶體驗、解答不標準、影響品牌認知。

引入智能客服機器人之後，80%的問題被機器人攔截，剩下的20%轉到人工後臺，減輕了客服管理人員的壓力。

智能客服機器人目前服務於全部一線的客服同事，成爲客服管理重要的平常工具。客服人員只須要經過手機就能夠操做，實現了運營管理智能化從0到1的過程，幫助運營人員減輕壓力，提高運營效率。

4.2 財富智能助手機器人

財富銷售過程當中涉及到不少產品（基金、保險等），須要瞭解產品知識、政策法規、銷售話術等。同事但願能有一個知識型的助手，協助解答在銷售過程當中遇到的諸多知識盲點，提升專業度。

咱們計劃使用聊天機器人小助手與現有手機app結合，實現產品、客戶、知識一站式服務。

如上圖所示，財富智能助手並非直接調用機器人平臺，而是經過API方式調用機器人平臺，而後去詢問各類支持銷售的問題。

目前財富智能助手機器人覆蓋全部一線銷售和業務支持人員，解決投前、投中、投後、銷售政策等問題，提升了業務專業度、響應速度，提高業務拓展效率。

4.3 保險智能機器人

第三個場景是保險智能機器人。微信用戶存在大量相關問題諮詢，使用人員來回答的話疲於應付，回答也不專業，人力成本很高，但願經過機器人對售前類問題提供諮詢服務，代替人工，完成售前信息交互，大幅減小人員成本，提升回答準確的和精準度。

如圖所示，保險智能機器人基於第三方知識庫提供查詢：包括保險類術語查詢、疾病庫查詢、險種查詢、醫院庫等保險知識大全；基於知識圖譜和推理的1~3度內查詢等，例如：條款明細請問這款產品有猶豫期嗎？我孩子5歲能夠買這款產品嗎？重疾險都包那些疾病？還能夠作常見售前售後意圖判斷、保險費用預計算。

4.4 AIOps運維機器人

最後一個場景是AIOps智能運維機器人，AIOps是一個很大的話題，涉及到海量數據的存儲、分析和處理。數據包括：歷史數據、流數據、日誌數據、時序數據、異常數據等。整個系統由許多小工具集成成爲一個大系統。AIOps還包含自動模式發現和預測、異常檢查、根因分析等須要模型支持等方面。

這裏咱們主要關注入口：文本輸入。

在平常運維中，當出現異常時，運維同事收到手機、郵件或短信報警，但願經過手機APP，以天然語言方式查看得到當前系統狀態、隨時隨地瞭解當前系統，甚至能夠經過運維執行命令來解除故障。

好比能夠經過手機APP調用任務機器人去查詢後臺系統中網絡佔用的一個時序圖，把這個圖以報表的方式返回到前端。使用機器人能夠有效下降信息過載問題，調用相關接口，直接找到目前最重要的問題並返回。當發現系統出現故障時，能夠經過機器人發送命令，重啓服務解除故障。

5、總結

• 基於AI中臺的思想和實踐。智能聊天機器人採用平臺化建設方式，使得機器人能夠快速複製。第一個機器人從研發到上線用時6個月，接下來是5個月上線，4個月上線，2個月上線，6週上線，最新的項目是3周完成上線。
• 支持多業務線、系統無縫對接，同時響應個性化需求。產品從立項以來支持公司普惠金融、財富管理的諸多重要業務方，支持PC端、APP端、restful api接口對接。
• 覆蓋同事廣，服務時間長。支持一線同事數萬人，累積回答問題數十萬次以上，累積會話時長近千小時。
• 運營效果好，節省人力。據統計，有效回答（機器人回答佔總回答比例）在80%以上，錯誤反饋率在5%如下(反饋無用的比例)。
• 產品種類全。包括問答機器人、閒聊機器人、任務機器人、知識圖譜機器人、以及基於場景的交互式機器人（如產品推薦、問卷調查、催收銷售等）。
• 提供工程、算法和運營統一的一站式智能聊天解決方案。好比在線查看標註會話和知識更新、自動化語料導出和模型更新、數據、算法和運營造成閉環。

6、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庫不斷完善、模型自動更新、問題反饋、統計報表等都是一個統一的總體。單純只重視任何一方面，例如只重視算法模型，忽略特定業務場景的語料，忽略運營的支持，都會致使機器人很差用，體驗差。在實際運營中，算法、平臺和運營都須要造成閉環，進行有效溝通。這樣才能把平臺和機器人建設得更好用。

來源：宜信技術學院