ChatOps智能問答技術(shù)在運維服務(wù)領(lǐng)域的應(yīng)用探索與實踐

在智能交互領(lǐng)域，ChatOps基于DevOps協(xié)作模式，是人工智能技術(shù)和新型工作理念相結(jié)合的產(chǎn)物，其以溝通平臺為中心，通過與機器人產(chǎn)生對話和交互，使開發(fā)人員只需在聊天窗口即可完成DevOps所承載的工作。以運維工作為例，ChatOps圍繞一線和二線員工運維數(shù)據(jù)獲取難、使用難、信息不通暢、信息支撐手段匱乏等痛點，可助力打造數(shù)據(jù)賦能的智能運維問答機器人，構(gòu)建低成本、高效率的共享服務(wù)模式，實現(xiàn)公開透明、上下文共享、移動友好以及DevOps文化打造等一系列目標(biāo)。對此，筆者團隊基于農(nóng)業(yè)銀行一體化生產(chǎn)運維平臺，創(chuàng)新構(gòu)建了新一代智能運維問答機器人，旨在為AIOps和DevOps能夠更好融合添加助力、搭建橋梁，以及為有相似建設(shè)需求的金融同業(yè)提供可借鑒、可拓展的實踐案例。一、基于ChatOps的多輪對話方案設(shè)計一般而言，多輪對話常用于任務(wù)型智能問答場景，使用者帶著明確的目的而來，希望得到滿足特定限制條件的信息或服務(wù)(如查詢信息、訂票、找電影、購買商品等)。實際上，用戶需求可能很簡單也可能很復(fù)雜，甚至需要通過多輪陳述，在對話過程中不斷修改、完善自身需求。簡言之，多輪對話更像是一個決策過程，需要智能運維機器人在對話過程中不斷根據(jù)當(dāng)前狀態(tài)決策下一步應(yīng)該采取的最優(yōu)動作，從而有效輔助使用者完成信息或服務(wù)獲取。在此過程中，意圖識別是智能問答自然語言理解(NLU)中的一個必要步驟，它通過分類方法支持將query分配到相應(yīng)的意圖種類，最大優(yōu)點是可以有效縮小檢索范圍，大幅提升問題匹配的準(zhǔn)確度，因此對于特定領(lǐng)域的問答系統(tǒng)有著非常重要的作用。聚焦智能運維領(lǐng)域，由于專業(yè)領(lǐng)域的特殊性和用戶習(xí)慣的差異性，運維人員通常并不會遵循純自然語言的輸入規(guī)律來提出問題，而智能運維機器人也很難理解一個具體的服務(wù)目錄、項目名稱或某個運維工具代表了什么含義。針對上述難點，為構(gòu)建一個具備良好可擴展性和專業(yè)領(lǐng)域理解能力的智能運維機器人，筆者團隊自研實現(xiàn)了兩種不同的多輪對話場景，并著重解決了兩者間存在的語序沖突等問題。在此基礎(chǔ)上，根據(jù)用戶對特定領(lǐng)域機器人提問的特性，筆者團隊還基于NLU的對話能力進一步實現(xiàn)了基于檢索的智能問答意圖識別，同時解決了跨平臺的語義沖突等問題。二、基于狀態(tài)機的多輪對話應(yīng)用實踐為實現(xiàn)“輕量級”的多輪交互，筆者團隊創(chuàng)新設(shè)計了引導(dǎo)式的對話模式，即通過語音客服，輔助使用者輸入指定關(guān)鍵字來進一步獲取回答或查詢更多信息。1.基于Redis的存儲結(jié)構(gòu)鑒于智能問答具有“短、平、快”等特征，筆者團隊最終選定了Redis作為存放多輪對話臨時答案的緩存機制，該方法既能確保對話維持在高響應(yīng)速率，也能自由控制臨時答案的存在期限。在該存儲結(jié)構(gòu)中，本輪答案和下輪答案均以json方式存儲，可輸入的關(guān)鍵詞是“鍵(Key)”，其余元素構(gòu)成“值(Value)”。多輪對話答案存儲模型如圖1所示。圖1多輪對話答案存儲模型在上述存儲結(jié)構(gòu)中，為避免出現(xiàn)刷新Redis時更新域無法控制的情況，筆者團隊選擇將輸入值存放在同一個鍵值對下，以確保更新緩存時答案的一致性和完整性。舉例來說，本輪次設(shè)置用戶的快捷輸入為“1、2、3”，輸入“1”進入的下一輪次快捷輸入為“1”和“2”，那么在輸入“1”刷新緩存時，快捷輸入值“1”和“2”的緩存鍵值會被同步更新，但輸入“3”的緩存鍵值依然保留著，這意味著用戶即使進入到下一輪次，仍可以輸入上一輪次中的部分快捷鍵獲取上一輪次答案。2.對話狀態(tài)機模型設(shè)計實現(xiàn)多輪對話的核心在于智能運維機器人需要時刻了解用戶的當(dāng)前狀態(tài)，知道用戶何時進入了多輪對話，又在何時選擇退出。對此，筆者團隊選擇基于狀態(tài)機原理來實現(xiàn)多輪對話場景。本地多輪對話狀態(tài)模型如圖2所示。圖2本地多輪對話狀態(tài)模型總體來說，基于對話狀態(tài)機原理的設(shè)計思想如下：智能運維機器人前端設(shè)置全局變量，默認(rèn)用戶狀態(tài)為單輪對話狀態(tài)，表示用戶當(dāng)前未進入多輪對話。當(dāng)用戶的提問命中了多輪會話后，根據(jù)場景特點，如后續(xù)輪次大于1，則用戶狀態(tài)進入多輪初始狀態(tài)，表示用戶正處于多輪對話，且還可有下一輪對話；如后續(xù)只有一輪次，則用戶狀態(tài)進入多輪結(jié)尾狀態(tài)，表示用戶正處于本多輪對話場景的最后一輪?；谠撃Ｊ?，可以使答案模板與緩存機制的交互次數(shù)趨于最小化，從而盡可能減少性能上的開銷。在上述流程中，當(dāng)用戶提問進入多輪狀態(tài)后，智能運維機器人首先需要區(qū)分該場景是否還存在下一輪對話，如果當(dāng)前已為最后一個輪次，那么僅需要向用戶返回本輪答案即可；如果當(dāng)前對話仍存在更多輪次，那在獲取到本輪答案之后，還要把下輪答案也放到緩存中。本地多輪對話程序流程如圖3所示。圖3本地多輪對話程序流程3.多輪對話異步加載在前述方法中，對于下一輪次需要調(diào)起外部聯(lián)機接口的場景，預(yù)先加載答案不僅會使性能壓力都集中在前一輪次，且不能保證用戶一定會選擇進入下一輪次，這使得提前緩存略顯冗余。此外，部分聯(lián)機接口對時效性要求較高，實時檢索結(jié)果也始終在動態(tài)變化?；谝陨峡紤]，筆者團隊對存儲結(jié)構(gòu)進行了優(yōu)化，允許通過異步加載的方式返回結(jié)果，即本輪次下用戶輸入某個快捷鍵后，智能運維機器人才會調(diào)起對應(yīng)的接口返回本輪次答案。支持異步加載的多輪對話答案存儲模型如圖4所示。圖4支持異步加載的多輪對話答案存儲模型4.多機制并行的沖突解決策略在試點推廣智能運維機器人的過程中，為避免出現(xiàn)會話被“覆蓋”的情況，筆者團隊進一步優(yōu)化了本地多輪對話的存儲結(jié)構(gòu)，即在鍵值對中“值”的最外層增加了字段“答案類型”。對于觸發(fā)了間接回答的情況，將提前在Redis中緩存更新鍵值對，將答案類型預(yù)置為“外部”，而對于答案類型等同于“外部”的緩存，則會跳過對本地答案的解析，從而可有效避免兩種多輪對話并存的情況下相同快捷鍵被其中一種機制攔截的沖突問題。三、基于檢索的智能問答意圖識別通過分析試點推廣階段的用戶行為發(fā)現(xiàn)，由于智能機器人大多服務(wù)于特定領(lǐng)域，因此用戶在提問中往往會帶有一些專業(yè)領(lǐng)域術(shù)語，且提問方式也大多為文字輸入而非語音交流，用戶提問很少是完整的主謂賓句式，動賓結(jié)構(gòu)或者純名詞更為常見。針對這一問題，筆者團隊最初選擇在聊天界面的前端設(shè)置引導(dǎo)問題來提升命中功能型會話的概率，但隨著機器人服務(wù)渠道的不斷擴展，當(dāng)業(yè)務(wù)拓展到CS架構(gòu)(類似微信、暢聊)中的某個服務(wù)號時，由于整體框架能力的限制，已無法再通過設(shè)置引導(dǎo)的方式來提升直接回答的命中率，需要進一步挖掘用戶習(xí)慣，讓機器人的理解能力更加貼合本專業(yè)領(lǐng)域。1.基于詞典和規(guī)則的意圖識別面向?qū)I(yè)領(lǐng)域的會話內(nèi)容，筆者團隊首先明確了希望被直接檢索的短語場景，包括服務(wù)目錄編號、變更單號、應(yīng)用名稱、用戶名、IP地址、專業(yè)術(shù)語等，之后即是根據(jù)每個場景的短語特性來決定檢索方式。最終，筆者團隊重點選擇了三種本地檢索方法，其優(yōu)劣勢對比見表1。表1本地檢索方法對比2.模塊間檢索順序基于本文實踐的模塊間檢索順序如圖5所示。當(dāng)對話用戶發(fā)出請求時，智能運維機器人首先會判斷用戶當(dāng)前狀態(tài)，并在多輪情況下優(yōu)先進入緩存查找答案；在非多輪情況下，優(yōu)先匹配正則表達式及字符串解析，匹配成功后進入對應(yīng)模塊并返回內(nèi)容；否則繼續(xù)檢索詞表，進入緩存查找相關(guān)字典項，匹配成功后進入對應(yīng)模塊并返回內(nèi)容；如果以上均未匹配成功，則會調(diào)起普通智能問答接口，觸發(fā)智能運維機器人的識別邏輯進行兜底回復(fù)。圖5模塊間檢索順序3.語義沖突解決方案在集成了傳統(tǒng)FAQ對話、任務(wù)型對話和本地基于檢索的意圖識別后，由于不同場景下命中的關(guān)鍵字有重合，筆者團隊曾遇到過兩種語義沖突問題：一是本地檢索與任務(wù)型對話詞槽沖突，即在任務(wù)型對話的詞槽澄清環(huán)節(jié)，用戶輸入的應(yīng)用名稱將會被本地檢索直接攔截，導(dǎo)致智能運維機器人在返回配置信息后，依然處于等待任務(wù)型對話的詞槽澄清狀態(tài)，此時用戶輸入的其他問題將無法被正常識別。二是FAQ與任務(wù)型對話詞槽沖突，即由于部分系統(tǒng)別名與詞槽中配置的系統(tǒng)別名完全一致，導(dǎo)致原本用戶希望通過別名進行單輪對話，但最終卻被智能運維機器人認(rèn)為應(yīng)該進入任務(wù)型多輪對話。針對上述難題，筆者團隊通過優(yōu)化模塊間的檢索順序，有效解決了語義沖突問題。具體而言，在根據(jù)用戶輸入頻率調(diào)整本地檢索模塊順序的基礎(chǔ)上，將會攔截任務(wù)型詞槽的本地檢索(應(yīng)用編號、全名)下沉到FAQ型返回邏輯中，截斷知識庫答案再調(diào)起本地檢索API，解決了本地檢索與任務(wù)型對話的詞槽沖突，并通過將系統(tǒng)別名的檢索放在最外層之前，解決了FAQ與任務(wù)型對話的詞槽沖突。四、應(yīng)用效果與經(jīng)驗總結(jié)面向任務(wù)型對話場景，筆者團隊以查詢工具接入狀態(tài)為例，通過自然語言輸入觸發(fā)了案例場景。當(dāng)用戶輸入應(yīng)用名稱時，首先模糊匹配應(yīng)用系統(tǒng)全稱，從而有效提高了詞槽匹配準(zhǔn)確性，其次是在詞槽填充完畢后，利用自定義的模擬報文來實現(xiàn)智能運維機器人對執(zhí)行本地API的精準(zhǔn)控制，并根據(jù)本地模板統(tǒng)一封裝答案。針對本地多輪對話，筆者團隊以檢索應(yīng)用配置信息為試點場景，并在該場景同樣運用了基于詞表的檢索能力。此外，筆者團隊還針對各服務(wù)渠道(包括無狀態(tài)位的無條件Redis檢索和優(yōu)化后基于狀態(tài)機的Redis檢索)的對話能力表現(xiàn)開展了性能測試。各渠道本地多輪對話優(yōu)化前后性能對比見表2。表2各渠道本地多輪對話優(yōu)化前后性能對比基于智能運維問答機器人的應(yīng)用探索與實踐，筆者團隊總結(jié)梳理了如下經(jīng)驗：一是技術(shù)發(fā)展始終緊密貼合用戶需求變化，即堅持以極簡的交互方式和強大的后端邏輯，來打造緊密貼合運維自動化領(lǐng)域的服務(wù)模式。截至目前，智能運維問答機器人已服務(wù)用戶近2000人，問答輪次超過15000輪，服務(wù)渠道從最早的WEB端擴展到如今的WEB端、移動端、暢聊端，并支持持續(xù)觀察、分析用戶需求。二是根據(jù)不同渠道的特征選取不同的對話方式。例如，對于可提供引導(dǎo)的服務(wù)渠道，推薦使用任務(wù)型多輪問答實現(xiàn)特定任務(wù)；對于受到限制或無法給出聯(lián)想的服務(wù)渠道，推薦引入意圖識別來提升問答效率；對于現(xiàn)有平臺無法滿足客戶需求的服務(wù)渠道，推薦參照本地多輪對話機制，基于狀態(tài)機原理和緩存機制實現(xiàn)任務(wù)型對話的“平替”。三是盡可能保持生產(chǎn)和測試語料庫一致。針對場景間因語義沖突而引發(fā)的問題，筆者團隊采用了以一個后端對應(yīng)多個前端的技術(shù)架構(gòu)，即始終把所有能力集成在一個通用后端接口，開展控制準(zhǔn)入，以便快速應(yīng)對不斷拓展的前端服務(wù)渠道，并始終保持體驗一致的對話表現(xiàn)能力。多渠道智能問答能力集成架構(gòu)如圖6所示。圖6多渠道智能問答能力集成架構(gòu)五、未來展望在智能問答領(lǐng)域，當(dāng)前用戶對于純機器人的交互方式仍處于嘗試和觀望階段。后續(xù)，筆者團隊將繼續(xù)踐行