對話機器人：審核個人信息、智能信審

04-27

業務關鍵詞：客戶基本信息審核、智能信審、反欺詐
技術關鍵詞：對話系統、自然語言理解

背景

「客戶提交的個人信息是真是假？」--很多場景都需要驗證客戶所填信息的真偽，最典型的就是貸款場景（現金貸、消費貸、信用貸等）。目前業內基本都是通過人工打電話的方式進行審核，比如某客戶填寫的家庭地址是將府家園、單位地址是東方梅地亞、職業是教師，信審員拿到信息後要先做功課：用地圖軟體搜客戶家庭/單位地址附近的POI、搜集教師行業的專有問題，然後打電話問客戶「您公司附近有什麼銀行？您家附近有什麼商場？教師資格證要考哪些科目...」 -- 這種方式在信審專員人手不夠時、容易造成進件積壓、影響用戶體驗和效益。

對話機器人

於是，有了這個任務導向的對話機器人：客戶註冊/提交個人信息後，調用該機器人與用戶進行交互，在對話的過程中驗證客戶所填的家庭地址、公司地址、職業、出行方式等信息是否屬實，第一時間過濾部分欺詐/騙貸用戶，減少信審員壓力。

此項目是姨搜和致誠合作的，名曰「星探」、屬於」群星計劃「中的一員，由多名8年經驗的老信審員提供策略/業務支持、由多名PM和大佬提供建議、由我和王燦提供對話管理技術。目前處於內測階段，之後會對內支持宜信各業務線、對外提供服務。它的進化路線是這樣的：

初級形態：交流時機器人和客戶都使用文字。（目前形態）
中級形態：交流時機器人使用文字、客戶使用語音或文字均可。（正在實現）
終極形態：電話交流、機器人和客戶都使用語音、類似人工審核。（規劃中）

下文只對初級形態下的對話機器人在工程和演算法上進行一些簡介。

基本架構

直接上圖吧、一目了然：

我和王燦做的」對話管理「其實就是給致誠提供web service，基本流程是：

他們把客戶」基本信息「傳給我們 ->
我們據此生成並返回」問題「 ->
他們把用戶的」回答「傳給我們 ->
我們」判斷「用戶答得是否正確、並根據對話上下文/語境返回下一道」問題「

如此往複，其中並非所有問題都是有答案的、有的對話輪次只是為了收集信息。

工程方面

敏捷開發

1月12日 / 周五 / 小寒 / 宜賓士道塗...致誠趙總+大數據創新中心工程總監軍哥突然召集我們開會討論這個項目，當時致誠已經在和出門問問合作做這個事了、而且第一期已經上線、問我們要不要和他們PK？這個活接不接？...無可置疑：接了...為了能趕上出門問問，1月15日 / 周一 / 宜祭祀... 這天、我們祭了祭伺服器、認真擦了擦鍵盤、便開始了封閉開發，參與人員少+追求開發速度、於是選擇了敏捷開發。

技術棧選擇

快速迭代、小步快走 ~ 就選擇了python ~ 無論是寫web介面還是做NLP模型都很方便。這裡有個小細節：為了降低後續由python性能帶來的不可用風險、為了方便後續做橫向拓展，我們選擇了RESTful API、完全摒棄了框架提供的session機制等、自己寫原生代碼做用戶區分、連接控制、緩存等，寫起來並不複雜，而且後續做負載均衡時緩存的信息（如用戶基本信息、對應的問答圖譜、判題信息、上下文語境信息、狀態信息等等）可以方便的序列化到Redis/Memocache分散式緩存中，不用再折騰session一致性等亂七八糟的事，同時也避免了和框架耦合太深、畢竟這是python...

全棧節奏

調研的同時就在構思架構；寫代碼搭架子的同時就在考慮模型、就在讓爬蟲工程師爬語料；做模型的同時就在考慮下一步的迭代...並發、流水線、節奏快捷明朗，只用了兩周就出了0.1版本，就開始了評審... 精兵簡政、人多不一定力量大，其實這裡也體現出了全棧工程師的優點：避免了很多對接/溝通方面的開銷，極大提高了開發效率、極大提高了開發效率、極大提高了開發效率。如果按普通套路：做開發的只做web後台、做演算法的只做模型、然後溝通、設計介面、對接、調試等等一套下來估計兩個月也上不了線...

演算法方面

問答圖譜

每個客戶的基本信息（家庭地址、公司地址、出行、職業等）都是不同的，所以我們會為每個客戶定製、生成一份針對性的問答圖譜，比如：有的客戶家附近有銀行、此時可以問他家附近有什麼銀行，而有的客戶家附近沒有銀行、就不能這麼問了。同時，也需要考慮上下文的語境，比如客戶說他的出行方式是開車，接下來就不能再問他關於地鐵公交等方面的問題，而是和客戶聊：開什麼車/價位/排量等~這些是可以做校驗的。還有，不同題目的權重是不同的：一些簡單的問題如果用戶答錯了會給較大的懲罰。等等吧、細節挺多的。

我們使用圖結構來存q(問題)，類似知識圖譜，並用邊來存儲推理信息/規則信息、用來控制問題的推進：滿足什麼條件（當前的上下文語境、state、slots）時會進入哪個分支。--也就是「當前的context state」+「客戶的回答」+「邊中存儲的規則」構成一個推理步，一步一步推進。

這裡使用了一些NLU(自然語言理解)技術，還有判題模塊（即判斷用戶的回答是否正確）也大量使用了NLU技術、都差不多、核心都是「相似度演算法」、見下文。

判題

不同類型題目題目在判題時會有很大的區別，比如：

地址類題目：主要是計算POI(信息點、也就是地點名)的相似度，使用的是文本相似度、字面上的相似度：BOW+cosin距離/Jaro–Winkler距離/萊文斯坦比，但是在算文本相似度之前還需要對POI進行各種清洗、格式化、提取主幹，因為用戶在回答時一般都不會用標準名，比如「耀萊成龍尊榮影城」~用戶可能會說「成龍影院」、「中國光大銀行(北方中惠國際中心B座西北)」~用戶可能會說"光大"，這些口語化的POI與標準POI文本相似度還是很低的，容易遭成誤判，所以我們加了很多細粒度的清洗規則來輔助提取主幹，比如把國/省/市/區名加到stop words、這樣就可以從「北京市石景山區婦幼保健院」提取出「婦幼保健院」、但這並不是一籃子解決方案、它會引入很多bad case、如「廈門國際銀行」-如果去了「廈門」、就會變成「國際銀行」、但很明顯它的主幹是「廈門銀行」、還有「北京銀行」/「中國銀行」等、又需要做特殊處理；還可以對分詞的詞典進行修訂；等等吧、處理起來還是蠻複雜的、總之就是：大量看數據->總結規則->驗證規則、評估規則帶來的收益（是解決的問題多還是帶來的問題多）...
職業類題目：這裡就不止用文本相似度了、還會涉及語義計算、比如職業名稱歸一化~我們有標準職業名稱庫，需要把客戶說的職業映射成標準的（比如客戶說他是「做包子的」則需要把ta歸一化到「廚師」），最簡單、最容易想到的方案就是word2vec+word movers distance+rank 召回最相似的標準職業名，於是爬了幾個招聘網站的崗位信息配合相關語料train了個模型、試了一把、效果不理想：模型表現不穩定、方差特別大、一部分很准、一部分很差、不能達到企業級可用，目前使用的方案：對用戶說的職業和各個標準職業算文本相似度、如果相似度超過閾值則返回、否則、對用戶說的職業和各個標準職業做語義增強、然後再計算相似度、如果相似度超過閾值則返回、否則、用word2vec+word movers distance做兜底、算距離、按距離排序返回...
...其實內容挺多的、主要是細節很多、挺繁瑣的，比如：有時還需要考慮用戶輸入錯別字的情況、用拼音算文本相似度；有時需要對數字大小寫（「14號線」與「十四號線」）做處理；有時需要對字母大小寫做處理；等等吧、篇幅有限、不細說了。