Gamma Lab：讓機器回答一個自然語言問題需要幾步？

機器之心原創

作者：邱陸陸

人類從一百二十萬年前就開始製造機器了。阿基米德的槓桿給了我們力量，伽利略與達芬奇的動力學給了我們速度與空間，而計算機科學將取之不盡的信息從廣闊的世界裡吸收過來呈現在我們眼前：它試圖讓人類更「淵博」，用可以無限擴充的存儲幫助大腦去記憶；也試圖讓人類更「聰明」，能夠用可疊加的算力幫助人跨越自身處理大量數據和高維數據的極限。

然而僅僅有存儲能力和算力是不夠的，當一位保險業務員被客戶問到「這個保險可以用來辦貸款嗎？」的時候，即使保險說明書就存在電腦里，業務員也仍然需要花大量時間才能從數百頁長的說明書里找到相應條款，至於實時回應客戶的業務諮詢，簡直是天方夜譚。而當一位銀行銷售經理想知道「北京客戶的年齡分布情況如何？」的時候，即使每一位客戶的年齡數據都記錄在資料庫中，他作為一名沒有資料庫知識的一線業務人員，仍然需要等待專業分析師以周為單位給出一份未必能夠滿足要求的報告。

信息存在不等於信息可得，信息可得不等於知識可得，想要讓機器真正聽懂我們的問題、幫助我們回答問題，機器需要「學習」的還有很多。在平安集團旗下，有一家專攻金融科技的獨角獸公司，金融壹賬通。在金融壹賬通的人工智慧實驗室 Gamma Lab 里，有兩支專攻「讓機器聽懂人的語言，再把信息變成知識交給人」的隊伍，他們選擇了兩個金融領域裡常見的業務情景，研發了可以幫保險業務員做說明書閱讀理解的 Gamma eExpert 和可以幫助銀行業務員把問題變成資料庫查詢命令再變成報表的 Gamma Telescope。

最近，機器之心走進 Gamma Lab，與工程師們仔細地聊了聊這兩款產品，確切地說是聊了聊，讓機器回答一個自然語言問題，到底需要幾步。

Gamma eExpert：對保險文檔「倒背如流」的業務助手

幫助業務員回答一個客戶對一份長度可達數百頁的保險文檔的問題，需要幾步？eExpert 團隊給出的答案是：三步。

eExpert 是一個旨在幫助保險業務員讀保險文檔同時回答客戶問題的系統，它把一個來自客戶的問題和一篇對應的保險文檔視作輸入，然後輸出一句可以直接回答給客戶的話，以及這句話引用的保險條款原文出處。

eExpert 智能閱讀理解系統界面截圖，下方為保險文檔段落，紅字部分為閱讀理解選出的精準答案

第一步：拆解保險文檔，進行段落匹配

以 pdf、word 等形式存儲的帶有複雜格式的保險文檔經過目錄結構梳理、表格抽取和文本分段，被拆解成了眾多的文本段落。而用戶的問題進入系統後，段落匹配模塊首先要找出，在整篇保險文檔中，與這個問題最相關 N 個段落。

段落匹配主要利用了相似度匹配演算法的思路：首先將深度學習表示和符號表示結合起來，得到十幾個可以代表這個段落的「特徵」，然後再用排序演算法對這些特徵與用戶問題的相關度進行打分，打分最高的 N 個相應的段落就會進入到下一步，段落理解中。

值得注意的是，打分的機制也並不是工程師憑藉經驗「拍腦袋」想出來的，而是通過「讓演算法做選擇、比較演算法的選擇與真正的答案之間的差異、據此對參數進行優化」的三段式學習方式找到的，據負責人介紹，最後段落匹配 top3 的準確度能達到 96% 以上。

第二步：進行段落理解

把用戶問題和段落匹配階段選出來的 N 段文本分別輸入閱讀理解模塊，通過由輸入嵌入層、嵌入編碼層、文本注意力層、模型編碼層和輸出層組成的深度學習模型之後，得到一個表徵「起始點位置」與「終止點位置」的向量，相當於用記號筆高亮了段落中的一個短語或者一句話。

段落理解是 eExpert 系統的核心，為了訓練出準確度高、覆蓋面廣、可遷移性強的模型，團隊在模型結構、數據、優化流程上都進行了許多探索。

輸入嵌入層對問題和文本分布做詞級別的嵌入，同時添加了很多人工特徵。嵌入編碼層利用多尺度的一維卷積，把不同長度的問題和文本編碼為等長的多維向量。文本注意力層對問題和文本做雙向的注意力計算：根據問題去文本中找相關內容，同時根據文本去問題中找相關內容。模型編碼層以矩陣的形式找到起始點和終止點位置的聯合分布。最後，輸出層給出多個泛化答案。相比於單個答案，多個泛化答案能夠明顯提高獲得正確答案的召回率。

而為了解決專業領域有標註數據匱乏而準確率要求高的問題，團隊採用了從通用模型到垂直領域專用模型遷移的方式。在使用近 10 個中、英文通用數據集進行了預訓練，確保模型有好的泛化能力後，這樣的通用模型在混合通用數據集上大概能取得 36% ~ 48% 的準確率。

隨後，Gamma 組織保險領域的專家，耗時半年建立了一個 10 萬量級的保險閱讀理解垂直數據集，然後利用這個垂直數據集對模型做精調和迭代式改進。第一輪精調後，模型的準確率直接提升都超過了 65%。然而這仍然不是一個「可推廣」的模型，因此團隊針對錯誤的回答進行了數據負樣本增強。比如「猶豫期內退保是否有損失」和「猶豫期外退保是否有損失」，從語義相似度的角度不過一字之差，答案卻截然不同。模型在只有極少針對性訓練樣本的情況下不能很好區分二者，因此就會擴充帶有「猶豫期內」、「猶豫期外」關鍵詞的樣本。經過兩輪、1 萬條左右的數據擴充以及多種模型改進技巧，模型的準確率攀升到 90% 左右。

第三步：篩選答案，智能話術生成

「篩選答案」同樣是一個由小組件組成的模塊。

首先，對於那些多步推理的問題或者有「較長標準正確答案」的定義類問題，eExpert 將問題和答案以知識圖譜三元組的形式組織起來。（比如，「什麼是重症疾病？」、「什麼是除外責任？」）在篩選答案環節里，系統首先會判斷，用戶的問題是否是一個有「標準答案」的常見問題，如果是，那麼知識圖譜提供的答案會有較大概率被選擇。一個最典型的適合知識圖譜而不是閱讀理解回答的問題是「哪些疾病不在該保險的承保範圍中？」這個問題的答案通常分散在保險文檔的不同段落中，這就為閱讀理解模型解決這一問題帶來了天然的障礙，而反之，基於知識圖譜的問答模型（KBQA）則非常擅長根據條件從文本中進行內容抽取以及整合。

來自知識圖譜的答案，對多個段落的總結

然後，對於那些 FAQ 解決不了或者解決得不好的問題，「答案拒絕」組件會對選出來的 N 個段落以及答案做二次審核，如果閱讀理解模型優中選優的 N 個答案和問題不存在蘊含關係，拒絕模塊會阻止答案進入話術生成，而是告訴「閱讀理解」模塊，本次回答失敗，下次再接再厲。

最後，有的時候，直接讀文檔給客戶會顯得非常生硬，業務員在與客戶交談的時候除了需要熟練掌握保險條款，也會運用一定的表達技巧。這一部分 eExpert 也考慮到了，平台總結了一系列業務員常用的話術模版，把找到的標準答案和話術模版融合在一起，讓機器生成一個更有「人味」的答案。

紅字部分是閱讀理解模塊選出的答案，藍字部分是智能話術的答案

Gamma Telescope：隨手拯救「表哥」「表姐」

幫助管理人員用一張報表回答一個和資料庫相關的自然語言問題需要幾步？很巧，Telescope 的團隊給出的答案也是，三步。

Telescope 和 eExpert 的服務對象都是金融行業的業務人員，都需要處理自然語言問題，區別在於 eExpert 是從另一份自然語言文本中尋找答案，而 Telescope 則是從結構化資料庫中尋找答案。eExpert 把保險文檔段落和問題一起輸入模型，而跟隨問題一起進入 Telescope 模型的是數據表。eExpert 在文檔段落中高亮出能夠回答問題的部分，而 Telescope 輸出一句查詢命令，然後把從資料庫中返回的查詢結果以可視化的形式展現出來。換言之，這是一位業務員專屬的數據分析師。

Telescope 界面實例

第一步：語言建模

在第一部分里，數據表的表頭（列名，column names）和自然語言問句被視為兩個序列，分別用 Bi-LSTM 編碼層編碼為兩個向量，然後利用注意力機制加強問句中與表格更相關的詞的重要性，最後得到既包含問題信息，也包含表格信息的一個向量，完成語言建模。Bi-LSTM 編碼將表格的位置信息、語言的語序信息也都編碼進去了，換言之，調換一下一張數據表中的列的順序，在模型看來就又是一個完全新鮮的訓練數據了。

如何對錶頭和自然語言問題進行編碼

第二步：用預測的方法把問句轉換為 SQL 語句

在 Telescope 的視角里，一個 SQL 語句由語句類型、操作維度、以及條件過濾器三部分組成。系統的第二部分任務就是把「SQL 語句生成」這個大問題拆分成多個小問題，通過一系列的預測，確定 SQL 語句的不同組成部分，從而完成語句的生成。

首先進行預測的是語句的形式。Telescope 把自身會用到的語句類型分成多個類別，並確定自然語言問句對應哪一種 SQL 語句類別。例如「學歷分布」、「年齡分布」、「銷售額分布」就都屬於「分布」類問題。

其次進行預測的是操作維度，系統會預測在數據的眾多列中，問句最有可能是針對哪一列數據進行提問，並把可能性最大的列名加入查詢範圍中。

最後進行預測的是條件過濾器相關的一系列內容，包括過濾器的數量、類別、條件列名以及條件值。其中前三者的預測方式和語句類型以及操作維度的預測方式相似，而條件值部分則採用了指針網路（Pointer Network），用於將原文中的專有名詞複製到問句中。例如在「上海地區 30 歲及以上男性借款人的學歷分布是什麼樣的？」一個問句中，過濾器就會把「地區是上海」，「年齡大於 30 歲」兩個條件識別出來。

針對金融企業里每一個職能部門可能出現的數據表以及業務人員可能對這份數據提出的問題，團隊為數千個自然語言問題按照上述範式給出了標註，根據這份標註，可以自動生成一句能夠提取相應數據的 SQL 語句。

第三步：查詢可視化與返回

獲得數據之後，如何針對數據特性找到最有助於輔助決策的可視化方式，是一類機器尚不如人類表現的問題。因此在這裡，產品團隊從現實的需求場景出發，針對每一種「語句類型」提供了推薦的可視化方式。例如，針對「分布」這一語句類型，系統給出了「柱狀圖」和「詞雲」兩個可視化選項。

值得一提的是，「語句類型」里除了「分布」這樣的明確意圖之外，還包含了「是什麼樣的」這樣未指明意圖的情況。自然語言查詢對於提問者的約束遠小於傳統分析工具，因此，經常會出現「北京的客戶是什麼樣的？」這樣未指明意圖的模糊問句。針對這樣的問題，Telescope 也會嘗試猜測和「北京」、「客戶」相關的查詢，把「北京客戶的逾期情況」、「北京客戶的借貸機構數情況」、「北京客戶的多頭借貸情況」以圖表報告的形式呈現給查詢者，讓查詢者選擇他們關心的方向。

而從語句類型的設定到從可視化選項的選擇，都來自平安內部一線業務人員的標註與反饋意見。這也確保了多樣化的真實場景下的真實需求都得到滿足。

自然語言問題中的「大象」與「冰箱」

回到最初的問題：通過段落匹配、閱讀理解和智能話術生成三步，eExpert 就能回答一個保險諮詢問題，而通過語言建模、SQL 語句預測和查詢可視化三步，Telescope 就能生成一張業務分析圖表，然而和「把大象裝進冰箱里需要幾步」一樣，「回答一個自然語言問題需要幾步」是一個看似可以用一句話概括，但實際近乎不可能的任務。完成這樣一個任務時，需要進行大量基於實務經驗的產品設計的問題。

「有人說，想要獲得足夠高的問答準確度，有百萬量級的專業語料就好了。但是當客戶說希望有一個能通過自然語言問答查詢數據的工具時，我們不能對客戶說，你先把百萬標註語料拿出來。我們要做的是不是讓場景適應技術，而思考如何把問題拆分、把技術組裝，去達到一個真實的目的。」Telescope 的負責人說。

因此在了解 eExpert 與 Telescope 系統的結構、每一個部分的原理、必不可少的數據標註工作之外，我們也透過這些描述，看到了 Gamma Lab 在這條讓機器「理解人的問題，再把信息變成知識交給人」的路上，遇到的障礙與跨越障礙的種種努力。

這些經過了反覆探討的流程設計，反覆試驗、失敗、再試驗最終得以保留的方法與技巧，才是客戶能夠毫不費力地用最自然地方式得到想要的答案的原因。

他們改變了「大象」，也改變了「冰箱」，然後給了用戶一個簡單至極的答案。

本文為機器之心原創，轉載請聯繫本公眾號獲得授權。

------------------------------------------------

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！