內容來源：宜信技術學院第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庫不斷完善、模型自動更新、問題反饋、統計報表等都是一個統一的整體。單純只重視任何一方面，例如只重視演算法模型，忽略特定業務場景的語料，忽略運營的支援，都會導致機器人不好用，體驗差。在實際運營中，演算法、平臺和運營都需要形成閉環，進行有效溝通。這樣才能把平臺和機器人建設得更好用。

來源：宜信技術學院