Chatbots 中對話式交互系統的分析與應用
洪強寧 / 愛因互動 CTO
前豆瓣首席架構師，TGO 北京分會成員。編程 30 余年，11 年互聯網從業經驗。
16年的時候，我離開宜信出來創業，與原來豆瓣的首席科學家王守崑一起創立了愛因互動這家公司。愛因互動是做對話服務的，是一家 To B 的公司。我們服務的內容是用對話的形態來交付企業的價值。為了提高對話的效率、質量，我們採用了人工智慧技術。在這個過程當中，我們會涉及到更加偏售前的方式，會做更多的個性化推薦，促進交易轉化，所以是一個多輪對話的過程。這種對話機器人的主題會與微軟小冰那樣的閑聊機器人的主題有很大區別，這兩個在對話機器人行業里屬於兩種技術路線。
人工智慧時代正在來臨
人工智慧時代正在來臨，現在每天都可以聽到AI這個詞。我在創業決定走入這個行業之前，和守崑一起回顧了從互聯網出現到現在差不多30年的時間中，都有哪些標誌性的事件使得我們的技術得到突飛猛進的發展。最早的時候是在互聯網商用的時候，即互聯網誕生，這件事情我覺得意義非常重大，不亞於早期的工業革命，其實它也被稱為「第三次工業革命」。互聯網出現這件事情，使得整個人類的信息開始流通，互聯互通，從這個時候開始人類的知識聯繫在一起了。從這個時代開始科學技術得到了非常快速的發展，這是因為聯通在一起之後，整個人類成為一個共同體，它的進化、發展速度都比之前快很多。
第二個標誌性的事件是Mosaic Web瀏覽器發布，開始進入Web時代，只要打開瀏覽器全世界的事情隨時可以收集到。這個事情是第二次提速，使得我們的發展速度變得更快。
第三個是在06、07年左右的時候，連著發生三件大事：第一件事情是谷歌發表了被稱為「三駕馬車」的分散式系統論文，這個使得我們處理大數據的能力具備了。原來的時候一個數據太大，超過了單機處理能力的時候，就會非常地難處理，需要切片，考慮各種各樣的故障，怎麼恢復等。但谷歌的這三篇論文其實在很大程度解決了這個問題，通過這三篇論文，產生了整個Hadoop的生態，基本上各家公司都會採用這個方式解決大數據的問題。
第二件事是亞馬遜發布了AWS，這是「雲」的開端，我們獲取計算資源直接從雲上摘就可以了，隨時隨地可以有非常大量的計算資源可以使用，而且很廉價。
第三件事是蘋果發布了iPhone，這件事開啟了移動互聯網時代。所以我把那段時間稱為移動互聯網時代和雲計算時代，這個時代一共有10年時間，現在大家已經非常習以為常了，每天都揣著手機使用互聯網。做雲計算的也是，大家都已經非常習慣了，做一個項目在雲上直接開機器，大數據處理也不是問題。在這裡還產生了大量的數據，我們每時每刻，24小時都是連上網的，這些數據可以被存儲在雲端，然後可以使用大數據的計算框架進行處理，這使我們進入了一個新的時代。
另外一個是AlphaGo戰勝李世乭這件事。我覺得這是一個標誌性的事件，標誌著人工智慧的通用技術開始體現出它的價值，具備了之前的人工智慧不能具備的能力。我覺得這一波人工智慧的興起是真的來了，進入到了一個人工智慧的時代。
人工智慧時代為什麼到現在才可以成為現實的事情呢？這跟前面那十年的發展是分不開的，我們有產生和處理大數據的能力，有雲計算的能力，在這兩個基礎之上才存在現在的人工智慧演算法的可能性。因為現在的人工智慧演算法是以深度學習演算法為代表的，而這個演算法是非常消耗計算能力的。也正是出於這個角度考慮，我認為人工智慧是下一個10年甚至更長時間內的一個大事情。
UI的進化
另外一個角度來說，我們和計算機系統，或者說和互聯網系統，是通過一個UI界面來交互的，人工智慧的發展使得UI交互也發生了非常深刻的變化。可以回顧下非常早期的時候，那個時候用的是DOS，還沒有Windows，包括現在程序員在伺服器上也是要使用命令行。命令行就是一個非常典型的人機交互界面，這個界面是命令式的，人去命令機器做一個事情，而且是要人去適配機器。因為機器只懂特定的命令，所以需要去學習機器能理解的命令，這是最早期的時候人機交互的方式。
後來Windows出現，開始進入到圖形化界面(GUI)的方式。與命令行(CLI)交互方式的主要區別在於增加了一個能力——「發現」。使用者不再需要事先去學習機器能懂什麼了，現在東西都展現在屏幕上面，能夠直觀地去看它能做些什麼，所以是一個發現式的界面。
現在我們可以看到各種各樣的技術在往上發展，比如AR技術，VR技術，語音技術等，其實都是在導向自然UI的方式。就是說我們在和機器交互的時候，和我們與真實的物理世界去交互是一樣的。我們人和人之間說話是用自然語言去溝通，當我們看見一個東西的時候是可以去撥弄它的。典型的場景比如說觸摸屏，以前的時候都是拿滑鼠點，現在我們可以真的去摸那個東西了。GUI的一部分也屬於自然UI的組成部分。
這邊的CUI指的是Conversation UI，它屬於NUI中的一類。指的是使用者可以用對話的方式與機器進行交互，不需要事先學習機器能聽懂什麼話，只需要使用原來與人溝通的方式就能與機器交互，這是一種機器適配人的形態。這是UI下一步的發展方向。
兩種形態的差別
大家對GUI已經非常熟悉了，GUI大概統治了我們有20年了，大家都很習慣使用GUI了。CUI並不是GUI的替代品，但是它能夠在一定程度上補充GUI的不足。GUI更加重視信息展示的廣度，能夠在一個屏幕上面，把你可能感興趣的東西全部展現出來，人要做的事情是從中發現自己真正感興趣的那部分。而CUI是一維的，它更加重視的是深度，就這一個主題，用戶接下來感興趣的內容是什麼，針對這個主題反覆地進行挖掘。
第二個是指給人的直接觀感。GUI更加重視空間感，布局中什麼東西放上面，什麼東西放下面，哪個地方需要加粗，哪個地方是醒目的顏色等，這些東西是一個空間的感覺。而對話UI更加強調的是時間感，我剛剛說了什麼，我很久以前說了什麼，這個對人的感覺是不一樣的，大家的注意力都會放在最近發生的事情上。這個對話是線性流動的，是一個時間的感覺。
第三個，在GUI的情況下更強調共性。我們在使用各種APP的時候，其實每個人心裡會有個預期，我看到的和其他人看到的差不多，我今天看到的和之前看到的也差不多。但在CUI的情況下是不一樣的，沒有人想每天在一個對話的交互界面里反覆地重複相同的對話。它一定是非常個性化的，針對我此時此刻的需要來發生變化的。
另外就是GUI是很穩定的，基本上我們期望的是熟悉了一個界面之後，這個界面最好不要再發生大的變化，這樣使用的時候效率最高。而在CUI的情況下面，我們是希望它能不斷進化的。我之前跟你說過的話，以後就不要再提了，因為我已經告訴過你了。這是GUI和CUI在交互上典型的不同。所以CUI其實是非常重視溝通的，希望你能夠不斷地跟我說話，就某個話題去深入，然後你能夠知道我關心的是什麼，曾經是個什麼樣的需求，現在能不能解決我的需求，會更加關心這個。
CUI它本身不是獨立的技術，並不獨立產生價值，它只是一個界面而已。它真正產生價值是使用對話這種方式，把真正有價值的東西表達出來，傳達給用戶。包括像個性化推薦，剛才提到了在對話的情況下，它是適合個性的，適合進化的場景，所以個性化推薦是非常適合使用對話技術來完成的。此外還有定向廣告，數據挖掘等，我能夠了解你的細節，去展現跟你相關的東西。以及在我業務場景下的一些細節的知識，可以通過對話的方式展示給用戶。
對話機器人的應用場景
對話機器人目前能夠落地的場景，大概有這麼三類。一類是個人信息助理，類似Siri這種。一類就是客服和導購的機器人，在商業上面可以通過機器人的方式服務一個用戶，向他介紹產品，銷售，然後做售後服務。還有一類是泛娛樂的，就是做陪聊性質的，滿足的是情感需求。三類場景都有人在做，我們做的是第二類的客服導購機器人。
對話的不同形態
在導購這個情況下，它是一個非常複雜的形態，並不是說你問我一句話機器人回答一句話就完了。仔細地分一下，可以把對話的形態分為三類。一類是人主導的對話，人發出需求，我想要一個什麼，問一個什麼，然後機器人來回答，回答完了以後再問新的，然後機器人再回答，這是一個響應式的。第二類是機器人主導的對話，機器人問你要什麼，你說我要這個，然後機器人再問，你再回答。還有一類是交叉的，人去問一個，機器人反問，人回答了，機器人再回答前一個問題的答案。大致上可以分成這三類。
人主導的對話 - 單輪問答
主導的對話中最簡單的形態，也是現在最成熟的形態，是單輪問答。所謂的單輪就是說，用戶說一句話，機器人回一句，這事就結束了，下一句話和這句話沒什麼關係。比如說問機器人什麼是外匯儲備，然後機器人會告訴你外匯儲備是什麼意思，這個問題就答完了。一問一答，這是最簡單的形態。
要做這件事情，基本上整體架構是和搜索引擎差不多的。搜索引擎其實就是個一問一答的結構，你搜一個問題，然後它告訴你答案，下一個搜索跟上一個搜索沒什麼關係。中間是一個檢索模塊，從一個知識庫裡面去檢索。檢索的時候因為是對話形態，相較於搜索引擎它會多做些事情，它會更加關注你想要問的東西是什麼，或者你問的這個問題在文檔裡面有沒有出現。所以會做一些同義詞的替換，可以使用複述句的方式擴展你可能的問題，更好地去命中知識庫。可以使用深度學習的方式來產生詞向量或者句向量，使得更好地完成同位詞的替換，這樣可以減少知識庫構建的壓力。檢索到之後會去做匹配，過濾掉一些不合適的，然後排序。這基本上和傳統的搜索引擎是一致的，只不過在深度學習出現之後，可以有一些更好的演算法，在大量語料的情況下獲得更好的結果。
人主導的對話 - 多輪問答
但之前提到過，CUI的特點是有時間維度的。人和人之間對話的時候，不會是每一句話都和上一句沒關係的，這和搜索不一樣。這裡有一個典型的場景，比如問什麼是基金，然後機器人告訴我什麼是基金。接下來我問有風險嗎，這句話其實是有隱含條件的，因為我剛剛問你的是什麼是基金，所以這裡不是問股票有沒有風險，是問基金有沒有風險。所以這個時候要匹配到的是一段話來解釋基金有沒有風險。這是人主導的對話中多輪問答的典型場景。
這種場景現在主要的解決方法是通過NLP的技術，對句子進行句法分析，這個其實是已經發展了很多年的技術，就是通過指代消解的方式。第一個問題來的時候，我們做句法分析，分析出主謂賓的句子成分，把句子成分存儲到一個上下文空間里。下一個問題來的時候，「那有風險嗎」，這句話是沒有主語的，所以就到上一個句子的Context里去查，把基金拿出來做為一個主語，變成「那基金有風險嗎」，然後拿這句話去知識庫里查。這就是一個非常經典的指代消解的方法。同樣地，有時候我們有主語，但是主語是代詞，「它」、「這個」、「那個」，也可以用相同的方法去做替換。
人主導的對話 - 閑聊
人主導的對話還有一種形態，閑聊。閑聊在最近深度學習起來之後其實是研究非常多的地方，當然在商業場景下閑聊的作用不是特別大，因為在商業場景下我們往往是希望儘可能快地把事情做完，追求的是短的對話輪次來完成任務。而在閑聊的場景下，比如陪伴機器人或娛樂機器人，追求的是能夠和人多聊，能聊很多輪次，這個指標是完全不一樣的。我們的場景中也會涉及到一些閑聊的情況，會拿閑聊去做兜底，當機器人完不成任務不知道你在說啥時，就會用閑聊的技術來完成。
這樣的對話最典型的做法是用sequence-to-squence這樣的深度學習演算法來構建一個模型，利用大量的語料去訓練它，可以從海量的語料知道你問的這句話以前的人是怎麼答的，然後把以前的人答的那句話抽出來。當然sequence-to-squence是把句子拆成了詞，在詞的層面上來做這件事，生成一句話來回答你。在這個基礎之上，還可以做很多的增強，比如可以把一些個人信息注入進來，在談論什麼東西的背景信息也注入進來。這也是一種流派，通過這種方式去學習海量的數據，最後有一天就什麼都能答了。但是從目前對話技術的發展來看，這條路還處於很早的階段，真的要讓它做到什麼都能答，答得有意義答得對，還是有很長的路要走的。
這裡有個解決的問題域的因素要考慮，對話機器人要解決開放域的問題還是解決封閉域的問題。所謂開放域，就是指不管問的是什麼樣的問題，都應該能找到一個正確的答案。如果這個事情能做到，那它就是開放域的。封閉域是指，機器人只能解決固定的有限集合的問題，超出這個問題範圍之內的，它就答不了。從一個已知的答案列表中去獲取回復，來回答一個開放域的問題，這是不可能的，因為你無法窮舉世界上的所有問題。用Retrieving responses這種方法只能解決封閉域的問題，而這個是非常簡單的，比如說前面的問答系統就能完成這件事。如果想要去解決開放域的問題，那就必須使用生成式的回復，通過理解你的問題，動態地去生成一句話，而生成技術現在還非常地不成熟。現在能做到的就是說一些模稜兩可的話，不論你說什麼反正都能糊弄過去。所以現在在商用場景下面，主要還是用封閉域的技術解決問題。
機器人主導的對話 - 採集信息
第二種形態是機器人主導的對話，這在商用的場景下是更常見的。因為人主導的對話，你不能控制人只在一個封閉域裡面去問問題，經常性地人可能跳出這個封閉域問問題。所以在更加實際的場景下，我們往往把這個話題轉成由機器人主導，我問你答，這樣人回答的內容一般不會太出格。比如說問人投資目標是什麼，給你5個選項，養老、子女教育、購置房產、享受生活、賺更多的錢。所以我可以猜測你的回答應該就是在這五個選項裡面，不太可能突然在這種情況下蹦出來一句「你昨天吃了啥」這樣的回復。這樣的話這個對話就比較容易進行下去，一句一句地把這個事情做下去，類似於填表。
這種有固定的流程採集信息的情況，可以使用Form-Bot來完成。預先定義好一個個問題，可能的答案有哪些。用戶每次回答來的時候，就通過一個中控模塊，去判斷用戶的回答是不是在答剛才的問題。如果是在答剛才的問題，那麼就把下一個問題拋給用戶。然後中間有一個狀態保存，知道現在問到了哪個問題，Travesal本身是無狀態的形式。
機器人主導的對話 - 推薦產品
機器人主導的對話還有一個典型場景是推薦產品。比如這邊課程推薦的例子，我已經給用戶準備好了一些課程，詢問用戶想聽關於什麼的課程。用戶說想聽大數據的課程，那麼我這邊有相關的課程就會推薦給用戶，看用戶喜不喜歡，這時候用戶就可以進一步地進行交互。這種形態其實我們在Web頁面或者App頁面經常能看到，有推薦位這種東西。在對話的形態裡面做推薦這件事，它有額外的好處是，可以針對性地推薦，再進一步地提需求。比如用戶說這個老師的課以前聽過，能不能換一個老師，這時候機器人就可以換一個仍是大數據方面的，但不是當前這個老師的課程給到用戶。
在這個場景下推薦機器人的大致流程是這樣的：首先，根據用戶的畫像及當前用戶的需求，可以產生一個推薦產品列表，推給用戶，然後用戶就可以進行答覆。這個時候可以通過分析用戶的意圖，判斷用戶的答覆是不是對這個產品提出了更細緻的要求。如果是的話，就把這個要求返回給推薦引擎，讓推薦引擎產生更新過的列表，然後再給用戶。直到用戶覺得滿意了，或者表達出不需要推薦了，才退出這個流程。用這種方法就可以實現一個機器人主導的產品推薦。
人和機器人交叉主導的對話 - 分支問答
分支問答是在問答場景下由人和機器人交叉主導的對話。人先問一句話，機器人並不直接回答，而是做一句反問。在不能立刻給出答覆的情況下，或者雖然能夠給答覆，但是我的答覆有太多的可能性，所以我想要了解更多的細節然後再做答覆，這時候就可以做機器人反問。比如說用戶註冊的時候實名認證失敗了，這個時候人可能會問機器人為什麼實名認證失敗了。機器人從知識庫庫里了解到，實名認證失敗有很多種可能性，如果直接給一大段的文檔，那麼體驗是非常糟糕的。所有這個時候機器人就可以採取分支問答的方式，首先問你名字當中有繁體字嗎？沒有，那就再看下一個最有可能的問題，你是否改過名字？改過，那之後就可以給用戶提供相應的解決方法，這樣子就可以實現一個體驗更加良好的交互方式。
這個要實現的話用前面提到的FAQ-Bot和Form-Bot做組合就可以了。FAQ-Bot做問題的匹配，匹配到的答案交給Form-Bot，由Form-Bot去做後續的提問，等到了某個階段確定了用戶的情況，就給出反饋。
人和機器人交叉主導的對話 - 多輪任務
這是另外一種人和機器人交叉主導的對話形態，是完成一個多輪的任務。用戶發出一個指令，想要幹什麼什麼樣的事情，想讓機器人去做。但是機器人發現想要干這件事情掌握的參數不夠，所以機器人要反過來主導對話，把那些不夠的參數問出來。這裡是一個訂餐的場景，用戶問「我想預定今晚7點，大董，9個人，有沒有包廂？」。這時候機器人要先做意圖理解，知道你要定飯店了，但是發現缺個參數，大董在北京有好多家店，到底是訂哪一家。所以機器人會再反問一下，確定具體是哪家店。
再細緻地分析下，首先「請幫忙預定今晚7點的大董」這句話，可以通過深度學習或者機器學習的方法，得到一個意圖分類器，判斷出這種句式是在表達預定的意圖。然後根據知識工程我們可以知道當預定餐廳這件事情發生的時候，我們有一些槽位需要填充，包括時間槽位、餐廳槽位、姓名、手機號、分店、人數、包間。知道了這麼多信息，就可以去執行這個任務了。經過分析，發現分店信息不確定，這時候機器人就可以進行相應的問詢，可以根據定單的歷史，如果用戶以前老預定某家分店，那麼這次很有可能還是那家分店。至於是直接幫他就訂了這家分店，還是再問一句進行二次確認，這個可以根據咱們業務的需求來做。
圖中是Task-Bot典型的架構流程。在前面還可以加ASR語音識別，在最後可以加TTS語音輸出，這樣子就可以實現純語音的對話。首先做問題的分析，然後開始做問題的理解，理解完以後記錄一個當前的狀態，有哪些槽位還沒有填充。針對每一種狀態，去做一個對話策略的優化，可以知道這時候該生成什麼樣的話能最有效地獲得槽位。得到了之後去執行任務，然後用自然語言生成或者模板填充的方式返回一個回復，比如「請提供下手機號及姓名」，這樣一下子可以獲得兩個槽位。這就是Task-Bot典型的實現方式。
融合對話的不同形態
前面已經提到三個機器人的對話方式，一個是人主導的，一個是機器主導的，還有一個是交叉主導的，每個都有其特定的應用場景。但如果我們希望機器人能夠在現實世界當中發揮價值，往往會發現人和機器之間的對話不是一種形態的，總是要在各種形態間跳來跳去。所以我們需要能夠解決這個問題，要在不同的對話模式中切換。
比如說之前遇到過的一個做風險測評場景，機器人主導的時候，問客戶「請問你能不能夠承受波動率超過15%的風險？」，期望的是客戶說能或者不能。結果用戶回答的是「什麼是波動率？」，這個時候就要跳到問答的場景，變成人主導的方式，解決客戶不懂波動率的問題。去知識庫里找什麼是波動率的答案，然後把答案返回給客戶。波動率答完以後，還是要再回來，接著剛才的情況問客戶能否接受15%的波動率。有時候用戶說的話會弄錯，要有容錯的機制，AI行業最苦逼的就是沒法做到百分之百的確定，所以一定會有錯的情況。這時候可以做確認，「你指的是不是這個？」，這樣也會把整個的對話模式給變了。還有就是兜底，我聽不懂但是我也沒辦法去猜你是做什麼，所以給你回些模稜兩可的話，這也涉及到不同對話模式的切換。
要解決這個問題，就需要在各種模式的技術之外再加一層，做一個路由的Bot。我需要去知道在當前的狀態下，應該使用哪一種對話模式的哪一種對話技術去完成。如果前面的路由Bot還並不能夠完整地分析出來的時候，可能事後還要做個融合，根據另外一個反饋模型去判斷，這幾個Bot給出的回復哪個更有可能是用戶想要的回復。這就是一個可以把不同的對話模型整合在一起的方式。
這是Route-Bot的一個示例，我們內部在Route-Bot和其它Bot之間定義了一個協議，叫做Botlet Protocol，他們按照這個協議互相通信。可以做Pre-route，判斷他是不是在問話，如果是問話就交給FAQ-Bot。也可以做Post-route，在FAQ-Bot結束的時候追加一句回應，繼續剛才填表的問題。Route-Bot自己會維護一個當前的對話列表，因為有的時候有來一句話並不能確定到底該交給誰。為了完成這一點我們需要增加短期記憶和長期記憶，短期記憶就是前面提到的對話列表，需要能夠記住剛剛在聊什麼。長期記憶比如說之前告訴過你我叫什麼，那以後就不要再問了。
Chatbot and Cloud
SaaS
首先對於做對話機器人來說，SaaS是非常適合的，後面是服務，前面是各種各樣應用場景的接入。最後是通過一個中心化的chat service把它統一成同樣的協議，在後面進行統一處理。獲得的語料也可以獲得統一的訓練，這樣可以使機器人準確率的提高速度變得非常快，不斷地獲取新鮮的數據反覆地進行訓練。
PaaS
在前面的介紹里可以看到，有不同的對話模式，每種對話模式又有不同的具體場景需要使用不同的演算法來實現。做AI最苦逼的地方也在這裡，有什麼樣的數據就用什麼樣的演算法，沒有放之四海而皆準的演算法。在整個過程當中需要不斷地嘗試，根據數據去調整演算法，迭代的速度非常重要。所以我們希望使用一個PaaS平台來加速這個過程，也使得整個的穩定性能得到提升。
內部我們大概是分這麼幾層，最下面是IaaS層，我們現在是跑在AWS的雲上。因為上面的支撐，其實下面跑在虛擬機或者物理機上都可以。這些是依賴於容器的，只要能夠跑容器的地方就可以跑各種的機器人，Docker Swarm及Kubernetes這兩個形態都是支持的。這兩個形態之上封裝了一層應用PaaS，使用了Lain這個組件，是個開源的容器雲平台，在應用這個級別去通知它我想要的是什麼結果。包括也整合了整個一套開發、部署、測試的體系在裡面。在這個之上，因為它是一個通用的PaaS平台，我們主要是做機器人這個項目，所以在機器人之上封裝了一個叫subot的PaaS。可以快速地用一個yaml去定義想要的機器人，期望由哪些機器人組件組成，包括一些測試用例也可以放在裡面。
微服務
因為每一個技術環節都是需要去不斷地迭代調整，變化非常快，所以我們採用了微服務的架構來獲取最大的靈活性。控制台是獲得語料的地方，用戶上傳的語料或者我們自己抓取的語料可以到達控制台，控制台把語料存儲下來以後會通知subot平台。subot平台這時候會去通知Overlord。Overlord是我們的訓練調度平台，它會啟一堆的Trainer，根據不同的場景，會啟動相應演算法的訓練器，獲取語料去訓練出模型然後保存下來。同時subot也會去通知機器人服務載入新的模型，Brain會讓完成這個業務的各個小的Botlet去載入模型，這樣模型就上線了。
對話機器人的大航海時代
最後要說一下，剛才我也提到了AI行業很苦逼，對話機器人其實也很苦逼。上次我去聽李飛飛的演講，對她的一個說法非常認可，就是說人工智慧科學現在還沒有達到科學狀態，還算是伽利略時代。伽利略時代我們已經可以觀測到一些科學現象了，但是科學體系還沒有建立起來，真正的物理學科學體系到牛頓那個時代才確立。現在大家是說有些方法有效果，但是為啥，不知道。對話機器人我覺得還要更苦逼一點，我們現在連有些東西是否有效果都還不知道。我們知道有很多技術可以用，在某些場景下能得到不錯的效果，但是是否在其它場景都有用，這個不知道，得試。所以更加像一個大航海時代，我們把船開出去，一邊開一邊看，只要有一天我們能找到個新大陸，這個東西就能解決我們絕大部分的問題。
Q&A
提問：我們正常的自然語言進來，SR的方案用哪個？技術角度哪種方案的選擇？怎麼達到語義的識別？
洪強寧：其實SR語音識別這個技術已經可以達到了，不知道大家有沒有關注，其實還是可以的，在國內效果比較好的，比如說科大訊飛，比如說百度的雲識別，在我們的使用下還是不錯的，我們客戶自己也開始使用了，效果也還可以。但是現在的語音技術都有一個特點，它對語音質量的要求比較高，背景音樂不能太大，麥克風不能太遠，口音不能太重，會有些受限，但是如果是手機錄音的方式，說的是普通話，基本上屬於可用狀態，如果你說的話裡面有一些專業的辭彙，還是需要專門的訓練，日常用語可以用了，好的產品在95%以上吧。
語義的部分，和應用場景去結合，狹義的理解部分，要知道你說的是什麼意思。語義量特別少的時候可以用這種。這是一個非常標準的做法，就是手寫規則，只有當積累比較多的時候可以建立模型。對知識庫查詢的狀態，比如說什麼是基金，問一個基金的意圖，因為人工比較大，單獨划出來。
提問：對話機器人這一塊真正落地的時候是以SaaS的形式還是什麼？
洪強寧：我們最喜歡的是SaaS，有一些金融客戶要求必須使用，對於我們來說技術層面一樣的，容器雲的那一套，不管底下跑的公有雲還是物理機也好，還是私有雲，都是一樣的跑法，維護成本會升高，我們訓練模型，不像在雲端。
提問：假如說對一些金融行業，對數據比較敏感的，真正落地的時候，其實這個數據相當於專門基於它自己的數據，自己在項目裡面把知識庫的工作全部做了？
洪強寧：一定程度上是的，知識可以分三層，最底下一層是我們說中國話，說漢語都可以用得到這個知識。中間一層次是行業領域。再往上是專用知識，主要是建模在專用知識，需要和客戶一起完成，投入比較大。
提問：有一個通用模型，用它的語料，然後產生一個知識庫？怎麼對模型進行評判？
洪強寧：對。現在學界還在研究這個問題，沒有明晰的判斷標準，我們自己在做還是準確度的判斷，機器自己可以給自己判斷，準確的判斷這些答的，還是得好人外部的判斷，我們把這個對話挑出來，然後機器的回答是否符合預期。
提問：假設達不到客戶業務的需求，我這個要通過人工標註反饋給模型再去練？
洪強寧：反饋有幾種，我們現在用的都是監督性學習的方法，要輸入才可以，是不是得通過標註的形態，不一定的，因為在運行的時候有人值守，進行交互的時候已經產生了反饋數據。
提問：剛才提到的Route-Bot可以理解為移動識別的功能？
洪強寧：是它的一個組成部分，還有下一個識別，分發出去，這個Route-Bot回復以後看是否用你這句話。
TAG:Go中國 |