今天我演講的內容主要從三部分展開，首先從一個回顧的視角去看問答系統的技術演變過程；其次，探討構建智能問答產品，特別是智能客服，在實踐中遇到的問題和解決方案；最后跟大家分享一些到云上構建智能機器人的思考。
問答系統的前世今生
問答系統早在 1960 年代便初見雛形，大致經歷了基于結構化數據、基于自由文本、基于問題答案對等階段。
關于問答系統，有一些比較關鍵的時間點，其中有幾個時間點跟 AI 技術的發展關系非常密切。從圖靈測試往后看，上世紀 60-80 年代的問答系統，主要是基于邏輯規則、結構化數據來做的。這個時代正值連接主義，也是神經網絡的寒冬（AI ），當時主流的一些技術都是基于邏輯的、符號的。因此，在問答系統的展現上它更多偏向于符號與邏輯計算的結構。而另一方面，神經網絡也開始有了分布式表示的早期概念，例如 提出的“分布式的概念表示”。現在來看，分布式的語義表示幾乎已成為絕大多數 NLP 任務的基礎，從思想上來看是一脈相承的。
在 1990 年，美國標準委員會 NIST 開始做大規模檢索語料集的收集與評測，后來通過 TREC 這個會議開放給信息檢索的研究社區。1999 年，TREC 新增了一個項目子項，叫做 ，當時， 更多的思路還是在延續信息檢索、IR 領域的一些經典方法在問答上面做一些嘗試。后面會再展開講一點。
之后隨著互聯網技術的發展，一些問答社區產品涌現出來，比如雅虎問答。最近幾年，因為知識圖譜概念的流行，讓基于知識圖譜的問答也開始獲得了更多的關注。同樣的，因為機器閱讀理解技術的發展，也促進了非結構化文檔問答的發展。從這些例子可以看出，技術的發展和成熟，會幫助拓展產品的場景和邊界。
接下來講一下問答和智能的聯系，很多人主張從圖靈測試開始看，但早在 17 世紀時，就有笛卡爾語言測試，當時笛卡爾認為，語言和智能的關系是一個很明確的三段論 — “大前提，小前提和結論” ，大前提是什么？它是指如果一個機器能夠產生一些回答、詞語，就存在對某些現象產生反映，但它不能對任何現象都產生所有可能的反映（無法編碼窮盡），一旦存在某種現象，機器無法正確地產生反映，這個大前提即說明機器沒有語言能力。小前提是，語言能力代表著思維、智能的呈現，通過“大前提、小前提”推斷出來“機器沒有智能”。
1950 年的圖靈測試避免了對智能定義的討論，而從行為、功能的角度看，如果一個機器能夠跟我對話，且我又不能分辨它是機器還是人，我就認為它有智能，這是從功能的角度去判斷的。
80 年代 John R. 的“中文屋”實驗對圖靈測試做了反駁，中文屋實驗是指，在一個房間里有一個完全不懂中文的人和一本中文工具書，外面的人用中文紙條和房間里的人對話，里面的人通過查詢工具書找到對應的中文輸出，對于外面的人來說，里面的人是可以通過中文對話的，但其實他并不懂中文。
我覺得“中文屋”實驗更重要的點不在于反駁圖靈，而是在于它提出了一些更有外延的一些想法，它思考了句法和語義的關系。我們都知道，人的思維活動其實是計算，或者說人類的思維很多是在大腦中的計算，并通過神經元、突出進行化學信號、電信號等的傳遞，那是不是意味著人的思維等價于計算呢？
“中文屋”就是在反駁這個（說法），它認為思維不僅是符號的操作過程，不純粹是物理的操作過程，它認為物理介質本身也很重要，也就是說我們的思維不僅僅是因為我們的突觸、神經元在傳遞電信號、化學信號，是因為神經元本身這個載體也構成了我們思維的一部分。因此該實驗認為，必須要有一個特定的實現，這個特定的實現必須要有物理化學基礎。當然后來中文屋實驗也引起了很多的討論，有興趣的同學可以看看 John 后來寫的中文屋回顧總結。
剛才講的兩個都是思維實驗，它其實是一個想法，并不適合用來做真正的問答測試。如果真正做一個嚴肅的問答系統的測試，要如何做呢？也有一些人提出了新的測試方式，比如 WSC，這是一個相對來說更加規范的測試文本倒排文檔舉例，它會給一句話、一個描述，然后給一個問題，讓人去選答案。這樣的問題非常簡單，只要你能看得懂這句話就能選出正確的答案。目前 WSC 測試最好的效果能達到 61，人類可以做到 95，所以，在這個方面機器和人類的距離還差得很遠。
剛在提到，在上個世紀 60 年代— 80 年代的問答系統中，主要是基于句法、邏輯規則、結構化數據來做的，當時這些問答系統都有一個名字，叫做 NLIDB。當時智能問答系統研究主要針對數據庫自然語言接口任務，即如何使用自然語言檢索結構化數據庫，代表系統包括 和 LUNAR。LUNAR 允許用戶使用自然語言提問的形式查詢 NASA 月球巖石及土壤數據庫。
1999 年，TREC 舉辦了第一屆開放領域智能問答測評任務 TREC-8，它從信息檢索的角度打開了智能問答的一個新方向，2000 年，當時 TREC 的做法跟 IR 的體系是一脈相承的，很多想法都是繼承了 IR 的思路，當時做 TREC 系統的比較經典的架構，跟 IR 系統是密不可分的。
一些文檔集通過 IR 的子系統，再通過一些語義（名詞動詞、語法結構、主語謂語）相關性的篩選，去找到侯選的答案。這其實都沒有 Model，基本上都是基于這樣的一些符號的操作，并得到了很多侯選答案。這些方法，已經有了現在的問答系統的雛形了，但當時這個方法的效果并沒有那么好，當時的 TREC 也好幾個數據集，最好的也沒有超過 60%，普遍的在 30%。
到 2010 年的時候， 已有一定發展。在美國，有一個電視問答比賽節目—“", 這個問答節目的規則是，有一些侯選人站在臺上，主持人提一個問題，大家先是選擇要不要去搶答這個問題，搶答后就可以回答問題。這里涉及到回答的準確率和覆蓋率（有多少問題搶答了）。在這個節目里，人類冠軍的準確率大概在 85% —95%，覆蓋率在 40% — 60%。
從 2007 年開始，IBM 一直想去挑戰這個比賽，4 年之后，IBM 構建的 系統參加了這個節目，并在比賽中擊敗了人類冠軍選手。 系統結合了檢索和結構化數據兩個方法，結構化的一個好處是，它不會隨著數據量擴大而掉的很厲害，當范圍擴大的時候，它仍然能維持在一定的表現，它做了很多優化的技巧，在 0.7 版本時已經能夠比一半的人類冠軍的表現要好。
在拿到冠軍之前， 系統曾遇到過的一個最大問題是它的線上耗時問題，因為它當時維持了一個非常大數量級的結構化知識庫，去做查找時需要兩個小時。當時節目中有一個 5 秒鐘倒計時，為了加速到線上去，5 秒鐘能做到，IBM 花了 300 萬美元組建了一個 90 臺的集群，每臺集群的配置很高，78 核、16PB 的內存，在當時世界超級計算中心的集群里排名前五百。
到現在，問答系統已經有一定技術成熟度，在面向垂類的問答比如智能客服、智能咨詢、智能導購類方面做的比較好，在面向開放域的任務問答、KEG 問答、閑聊等方面已有很多廠商做的很不錯，比如騰訊云，騰訊云會開放自己的對話平臺，大家可以在上面構建自己的任務機器人。目前，具備常識推理的，具有情感感知能力的擬人對話系統，離我們還比較遙遠。
從構建一個智能客服產品說起
剛才簡單講了一下問答系統的發展歷程，接下來講一講構建智能問答產品的實踐，我們就以智能客服為例。
現在，大家可能經常遇到這樣一個場景，很多廠商都會有自己的智能客服，可能老板就會說，智能客服很常見，技術好像也都比較成熟，是不是可以很快地去構建一套自己的智能問答的一個產品？
在之前也提到，其實現在信息檢索方法對 QA 的影響是深遠的，所以我們可以直接去用 IR 的方式先去構造一個初始的版本。構造完初始的版本后，我們會發現一些問題，比如在做問答的時候，用戶的 query 是比較口語的，多樣性會比較豐富，因此如果我們基于全文檢索，基于關鍵字匹配、關鍵詞的倒排索引來做，可能在泛化這一塊兒會有一些問題。所以我們需要去加入一些更多技能進來，比如需要去做意圖的判斷、理解，比如說需要去做一些排序和匹配的工作等。
再來說關于深度學習的問題，對于這個問題，針對大部分的場景也需要去考慮一下它的投入比，當實際上數據量很小的情況下是不是一定要去上深度學習? 我們的架構能不能支持很好地把模型加載進來？耗時能不能在線上承接的??？這些都是我們需要在深度學習上去考慮的。
假設到此我們已經搭了一個檢索的基本框架、加了一些 NLU 和匹配的算法，加了深度學習來進一步增強準確率，現在我們的 FAQ 的機器人終于上線了。
上線之后，我們發現還是會遇到一個問題：如果場景實體特別多，每個實體都要配置 FAQ 嗎？這樣工作量其實是非常大的，這樣類似的場景，可以歸納成一個多（物品）實體，少（問法）模式的場景，在電商、文旅里尤為常見。對于這樣的場景，KG 圖譜的問答會更加適合，圖譜的問答可以允許較多實體的數量，可以支持實體以比較低成本的大量增加，但它的模式會相對固定，使用 KG 問答，可以免去我們配制很多關于實體的問答對。
另外一個非常常見的場景是，在 FAQ 機器人中會發現很多問題其實是沒有的，或者說這些問題都存在于文檔里，可能會有很多的規章制度、解答都會寫在文章里，那這樣的情況是不是需要大家從文檔里面去抽這樣的一些問答對？當文檔數量很多的時候，這個問題就會比較繁瑣，耗人力。因此我們會有文檔問答的一些場景，就是為了去解決這樣的一些長尾問答、長尾問題。說到 FAQ，大家往往只關注它的 AQ，就是它的 QA 對，往往沒有怎么去關注這個 F，F 的意思是 ，是常見問題集，對于一些不常見、長尾的問題，我們完全可以通過文檔問答的方式，在文檔里面去找到答案。
我們還可能會碰到另外的場景，當機器人上線以后，用戶的問法往往會認為它可能會有上下文的理解，有些話用戶在上一次說了，不希望在下一次再重復，那么對于這一些多輪場景，我們也需要去構建一個多輪的引擎，我們需要有一個會話引擎去做會話管理，去管理它的上下文，去把用戶的邏輯和算法邏輯去配置在一起。
以上具體介紹了我們在構建一個智能客服產品的時候，遇到的一些問題和場景?？偨Y一下，當遇到這些場景后，我們首先是基于檢索的一個框架，做了一個初版，然后我們加了意圖識別 NLU 的模塊，讓它的問答支持更泛化的問法，進一步加了匹配和深度學習的模塊，讓準確率效果更好。最后，因為要面對它有很多實體但模式比較固定的場景，因此加入了 KG 的部分。為了去解決長尾問題，又加入了文檔的部分，最后為了關聯住上下文的問題，讓這個對話有對話記憶的功能，加了多輪交互的問題。
看似做了很多的工作，但問題解決了嗎？我們可能會發現這個系統上線后，它的效果還不如人工客服 + 以前的規則引擎，那該如何解決這個問題？
這就是我們接下來要講的 AI 中間件的部分。
AI 中間件： 智能客服
我們再進一步深入去看一下數據的原因，當線上數據出問題的時候，應該要從三方面去看，第一部分要看數據本身，第二部分看數據的模型，第三部分是看數據運營。
我分別來講一下這三個部分，首先要看數據本身的問題，不管是 FAQ 的數據也好，還是 KG 的數據也好，還是文檔的數據也好，這些都是基于數據的，我們首先要去對數據做一個健康度的指標和評價。我們都知道，模型有一個原則，" in， out"，如果你給它一些"垃圾"，它出來肯定是"垃圾"，我們必須要對數據做一個比較清晰的認識，這里會設一些指標，比如 (線上問答和知識庫的重合度到底有多少)。如果用戶問的問題都不在我的庫里，那再好的模型也無法回答。
第二個是這些模型本身是否有足夠的分離特點，如果這些知識點都耦合在一起，對模型來說，它也很難去學習。第三是看知識點是不是均衡的，有些知識點的問題和答案會比較均衡。有些問題，它有很多相似問題，有些問題則沒有，我不太希望我的知識庫里面出現這樣懸殊的樣本，這些是一些宏觀指標。
此外還有微觀指標，我們理想中的“相似問”是希望它和“標準問”的距離不要太遠，也不要太近，因為如果它太遠，可能機器無法去學習，太近的話，我們認為它是一個冗余，它沒有提供任何新的信息。我們希望每一個知識點的相似問的距離，它的分布是一個鐘型的，我希望他們大量的分布都是集中在一個窄的范圍里，希望所有的這個距離既不要太近也不要太遠。另外我希望這個鐘型足夠的窄、足夠的瘦、足夠的苗條，讓它們的分布會比較均衡，這就是剛才提到的“均衡度”。
剛才講了一些知識度的指標，那如何運用呢？可以構建一個數據閉環，我們有了知識庫以后，通過自動化的評測，評測后能拿到一個健康度的指標，可以去可視化，并給它一些梳理的建議，那梳理建議完了以后文本倒排文檔舉例，可以通過智能運營工具 去生成或產生優化知識點，然后給到人工去審核、編輯，最后回饋到知識庫里面去，這就是一個很好的數據閉環。同時，這樣一個健康可視化和知識處理也會給后面過程的選型、技術的選型帶來參考。
我剛才主要講的是 FAQ，這里也順帶去提一下 KG 的數據要求，KG 對數據的要求會更多，因為它是結構化的數據，那還有一部分是 Doc，為了能夠回答長尾問題，它人工介入的數據量會比較低，它是一個更加非結構化的數據。
接下來看一下數據模型，在看模型的時候，因為框架是自己檢索的，我覺得第一步應該先去看一下召回。召回很重要，因為召回是給我們畫了一個“圈”，告訴我們答案就在這個“圈”里，如果這個“圈”都畫不對，那后面的工作很難做的更好。如果召回沒有問題，這個圈里面答案的覆蓋率是百分之百，那就沒問題。
做到這些以后，就去看模型，先看排序模型，排序模型里要分別去看它的場景，另外再去看匹配的模型，這里有兩種主流模型的代表，很多人會覺得，現在普遍都用 based 的方法，為什么你還會說這個 based 的方法呢，為什么還講這種 Arc-I 的結構呢？其實 Arc-I 的結構大家不要去忽視它，因為在線上的時候， based 的方法耗時會大，每一次交互都是需要實時去做的。但如果是基于 based 的方法，可以離線算好存好，知識庫里的問答對都可以預計算，在實時的過程，只需要做很少的計算。所以在實際中要考慮 Trade off。
此外，大家可能在做模型的時候，比較少去關注的點是負例的構造，loss 的構造，這對實際效果的影響會比較大，有可能比模型本身的架構影響會更大，還有關于打分的問題，怎樣讓打分是有用的、可比較的。
接下來是 KG 的模型，其實 KG 的模型現在來講都比較經典，主要有幾類方法，一類類似于“ to ”這種方式，通過很多規則，通過設法標注句法的方式把它轉成圖數據庫的查詢語句。第二三種方法會綜合考慮問答的表示，就是問法的向量化及圖譜里的一些向量化，最后把它變成一個機器學習的問題。還有 Doc 模型，這里沒有展開去講閱讀理解這個模型，更多是在講，在實際工程里去考慮怎么去做這個事情，我們可能會先做文檔檢索，然后找到段落，做段落定位，再去段落里找答案。
做了這么多模型和數據的工作后，我們發現，AI 用上去效果是不錯，但隨著時間的流失，它就慢慢“掉”下來了，它又比原來的人工差了。這就是需要第三部分—運營的思想。
我們在傳統軟件里都會提到 CICD，AI 軟件跟傳統軟件有些不同，傳統軟件不需要長期的去培育。我們去交付一個傳統軟件更多情況下是一次性的。但對于 AI 軟件來講，我們交付的是一個“嬰兒”，我們得不停地去”培育“他，用線上的數據去“哺育”他，讓他盡快地成長起來，要更加的魯棒，因此我們要非常需要去關注運營效果。在 AI 軟件里，我們需要有 CICL 的思想，需要持續學習、持續進化的思想。
在運營里，我們可以重點看兩部分，第一個是事前，第二個是事中。事前運營，它有以下幾類，第一類是從文檔里去生成 QA 對；第二部分是從對話里去生成 QA；第三部分是生成相似問；這些是為了去啟動一個系統、一個 Model 可以做的一些事前部分。
事中部分是指，如果已經上線了，該怎么樣讓它做得更好？可以通過流水日志去看未解決的問題、去做一些聚類和發現。剛才也提到了一個智能運營工具— ，這個工具它是從文檔里去生成一個 QA pair，它跟文檔的結構是很相關的。另外一個工具是去生成一個相似問，我們可能會做一些模板庫，基于這個模板庫，抽出答案后把它做不同的套用。相對來說，做了聚類分析的模塊，比較適合在業務的線上去用到，尤其適合線上業務有線上客服的情況。
剛才講了很多關于數據運營的部分，除了數據以外，模型也需要運營。模型在不停地有新數據進來以后，需要做很多迭代，需要去做模型的訓練、模型的自適應的調參、模型的版本管理等等。因此，我們會有一個 Auto NLP 的平臺，這個平臺可以理解為 在 NLP 領域的一個實現。現在在這上面，我們已經實現了一些閉環，第一個閉環是數據的閉環，第二個閉環是模型的閉環，第三個閉環是流水日志的閉環。一個理想的運營系統，應該要實現這三個閉環。
總結
最后總結一下，在智能客服這塊，我們發現它的工作沒有想象中那么簡單，并不是老板說一周上線，我們就可以去解決所有問題。但我們發現其實智能客服的提效和降本的能力還是很強的，以一個實際客戶的數據舉例，它的智能客服系統上線 8 個月以后，在成本方面，上千人的人工客服團隊縮減到了 60%，而同時接單量反而有增無減，用戶排隊等待時間也大幅縮短，在只保留 40% 的人工客服的情況下，整體客服系統效率反而提高了 30% 以上，這還是一個相對來說比較保守的估計。因為最開始我們會有投入，比如購買成本，它是負的，但隨著它的客服系統上線運營的效果，會發現它的收益是越來越明顯增加。
如果大家想要去做智能客服，但又發現它沒有那么容易的時候，我們騰訊云可以幫大家做這個“Dirty Work”。對于一些不同類型、不同場景的 Bot，及數據運營和模型運營的模塊，我們都會開放一些能力給到大家，主要有 4 層能力，從下往上分別是：底層的平臺、原子化的能力；AI 中間件能力，比如不同類型的 Bot 中間件、運營的中間件、數據運營和模型運營的中間件；PaaS 平臺，騰訊云可以提供一些平臺的功能；最上層，企業可以針對各自所處的行業里面去做自己的行業應用，此外，還可以針對自己的場景去做自己的業務應用。
希望大家都能搭建自己的智能問答產品和系統，為自身業務降本增效。我們云也非常愿意為大家的智能化建設出一份力。分享就到這里，謝謝！
嘉賓介紹
鐘黎，騰訊云 AI 語義研發總監，主要負責云上智能搜索、問答、對話方向的產品業務研發工作。之前為騰訊社交網絡事業群語義分析負責人，主要負責社交網絡中的文本挖掘與語義分析工作。
你也「在看」嗎？