。數位化是近年來很熱的一個話題，它是指運用人工智慧、大數據、雲端運算等新一代數位技術，改變企業的業務模式，進而推動企業業務產生新的成長。企業數位化一般來說包括業務經營的數位化和企業管理的數位化。本次分享主要介紹企業管理層面的數位化。
訊息數位化，簡單來說，就是把訊息用數位化的方式進行讀寫、儲存和傳遞。從以前的紙本文檔到現在的電子文檔以及線上協同文檔，資訊數位化已經變成了現在辦公室的新常態。目前阿里使用釘釘文件和語雀文件進行業務協同，線上文件數量已經達到了 2000 萬以上。另外很多企業內部會有自己的內容社區，例如阿里的內網阿里內外，以及技術社區 ATA，目前 ATA 社區裡面有將近 30 多萬篇技術文章，都是非常寶貴的內容資產。
流程的數位化，指的是運用數位科技改造辦事流程，提升辦事效率。像企業內部行政、IT、人事等會有很多事務型工作。 BPMS 流程管理系統可以把辦事流程標準化，依照業務規則制定工作流程，依照工作流程自動執行，就可以大幅降低人力成本。 RPA 主要是用來解決流程中多系統切換的問題，因為它可以模擬人工在系統介面上進行點擊輸入的操作，所以它可以連接各個系統平台。流程數位化的下一個發展方向是流程的智慧化，透過對話機器人和 RPA 來實現。現在任務型的對話機器人可以在幾輪對話內就幫助用戶完成一些簡單的任務，例如請假、訂票等等。
業務數位化的目標是透過數位技術建立一個新的業務模式。在企業內部，其實也會有一些業務的中台，例如採購部門的業務數位化，指的是從商品的搜尋、採購申請的發起、採購合約的撰寫、付款、訂單執行等一系列流程的數位化。再例如法務中台的業務數位化，以合約中心為例，實現從合約起草開始，到合約審核、合約簽署、合約履約在內的合約全生命週期的數位化。
#數位化產生大量的資料和文件會散落在各個業務系統裡面，所以需要一個聰明的企業搜尋引擎，幫助員工快速定位他想找的資訊。以阿里集團為例，企業搜尋的場景主要有以下幾種：
（1）統一搜索，又稱綜合搜索，它聚合了多個內容網站的訊息，有釘釘文件、語雀文件、 ATA 等等。統一搜尋的入口目前是放在阿里的內網阿里內外以及釘釘的員工專屬版，這兩個入口的流量加起來有達到 140 QPS 左右，在 ToB 場景中屬於很高的流量了。
（2）企業員工助理指的是內外小蜜，它是一個面向阿里內部員工的智慧服務機器人，匯集了HR、行政、IT等多個領域的企業知識問答服務，還有快速的辦事通道，包括釘釘的這個入口，以及一些外掛入口在內，總共開放人群有25 萬人左右，也是集團的流量陣地之一。
#（3）產業搜尋對應上一章講到的業務的數位化，例如採購有一個門戶網站叫做採購商城，採購員可以在採購商城裡面搜索，選擇商品，提交採購的申請，類似於電商搜尋網站，只不過用戶是企業的採購員；法務合規業務也有對應的一個門戶網站，法務的同學可以在裡面搜索合同，進行合同的起草、審批、簽署等一系列工作。
#一般來說，企業裡面每個業務系統或內容網站會有自己的搜尋業務系統，是需要相互隔離的，但是內容站點的隔離會形成資訊孤島的現象。例如一個技術同學遇到了一個技術問題，他可能會先去ATA 搜尋問題相關的技術文章，搜不到的話再去知否、釘釘文檔、語雀文檔裡面搜尋類似的內容，一共要進行四五次搜尋行為，這樣毫無疑問效率是很低的。所以，我們希望能把這些內容集合起來，做成一個統一的企業搜索，只要一次搜索就可以獲得所有相關的資訊。
另外帶有業務屬性的產業搜尋一般來說是需要互相隔離的。像採購商城的用戶是集團的採購員，合約中心的用戶是集團的法務，這兩個搜尋場景的用戶量很少，所以用戶行為就會比較稀疏，依賴用戶行為數據的推薦演算法，效果就會大打折扣。採購、法務領域的標註資料也很少，因為需要專業人員來標註，成本很高，所以很難收集高品質的資料集。
最後是Query 和文件的匹配問題，搜尋的Query 長度基本上在十幾個字以內，是短文本，缺少上下文，語義資訊不夠豐富，針對於短文本的理解，學術界有許多相關的研究工作。搜尋的 Item 基本上都是長文檔，字元數量在幾百到幾千之間，對長文檔的內容理解和表徵也是一個很困難的任務。
上圖展示的是目前我們的企業搜尋的基本架構。這裡主要介紹統一搜尋的部分。
目前統一搜尋接入了 ATA、釘子文件、語雀文件等大大小小 40 多個內容網站。使用阿里自研的 Ha3 引擎進行召回和粗排，在召回之前會調用演算法的 QP 服務對用戶 Query 進行分析，提供 Query 的分詞、糾錯、term 權重、query 擴展、NER 意圖識別等。根據 QP 的結果和業務邏輯，在引擎側拼好查詢串進行召回。基於 Ha3 的粗排插件可以支援一些輕量級的排序模型，例如 GBDT 等等。在精排階段可以使用更複雜的模型進行排序，主要用相關性模型來確保搜尋的準確性，以及點擊率預估模型直接優化點擊率。
除了搜尋排序之外，還沉澱了其他的一些搜尋週邊功能，例如搜尋下拉框的搜尋直達區、聯想詞、相關搜尋、熱門搜尋等。目前上層支援的業務主要是阿里內外和阿里釘釘的統一搜索、採購和法務的垂直搜索，還有 ATA Teambition OKR 系統的 Query 理解。
上圖是企業搜尋 QP 的大致架構，QP 服務部署在一個稱為 DII 的演算法線上服務平台。 DII 平台，可以支援 KV 表、index 表索引的建置和查詢，其整體是一個鍊式服務框架，需要把複雜的業務邏輯拆分成相對獨立且內聚的業務模組。例如，阿里內外的搜尋 QP 服務，就拆分成分詞、糾錯、查詢擴充、term weight、意圖辨識等多個功能模組。鍊式框架的好處是方便多人協作開發，每個人負責各自模組的開發，只要約定好上下游介面就可以，並且不同的 QP 服務可以重複使用同一個模組，減少重複程式碼。此外，在底層的演算法服務上麵包了一層，對外提供 TPP 介面。 TPP 是阿里內部的一個成熟的演算法推薦平台，可以很方便地做 AB 實驗和彈性擴容，日誌打點和監控警報的機制也非常成熟。
在 TPP 側進行 Query 的預處理，然後組裝 DII 請求，呼叫 DII 演算法服務，獲得結果之後進行解析，最後回傳給呼叫方。
#接下來介紹兩個企業場景下的 Query 意圖辨識工作。
#內外小蜜底層是基於達摩院推出的雲端小蜜問答引擎，它可以支援FAQ 問答、多輪任務型問答、知識圖譜問答。上圖右邊展示的是 FAQ 問答引擎的大致架構。
使用者輸入一個Query 之後，開始會有一個規則幹預模組，主要是讓業務和營運來設定一些規則，如果命中規則的話，就直接返回設定的答案，如果沒有命中規則就走算法。意圖辨識的模組，把使用者 Query 預測到對應的業務線，每個業務線的 FAQ 知識庫裡面有很多的 QA 對，每個問題都會配置一些相似問法。用 Query 去知識庫檢索得到 QA 對候選集，然後再透過文字匹配模組來對 QA 對進行精排，根據模型打分來判斷是答案直出，還是推薦關聯問題，還是無答案。除了 FAQ 問答引擎之外，還會有任務型問答和知識圖譜問答等其他的問答引擎，所以，最後設計多模組的 ranker 來選擇透出哪個引擎的答案給使用者。
以下重點介紹意圖辨識這個模組。
#透過統計過去一年內外小蜜的用戶Query，發現大部分的用戶Query 字數集中在0- 20 之間，80% 以上的Query 字數在10 以內，所以，內外小蜜的意圖識別是一個短文本分類的問題，短文本次數很少，所以如果用傳統的向量空間模型表示，會造成向量空間的稀疏。而且一般來說短文本表述會不太規範，簡稱和不規範用語很多，所以 OOV 的現像也比較多。
小蜜的短文Query 還有一個特點，就是會有很多專有名詞，一般是內部的平台和工具名，像是歡行、愛豆等等。這些專有名詞本身文字也不具備類別相關的語意訊息，所以很難學到有效的語意表示，所以我們想到用知識增強來解決這個問題。
一般的知識增強會用開源知識圖譜，但是企業內部的專有名詞沒辦法在開源的知識圖譜裡面找到對應的實體，所以我們就從內部找知識。剛好阿里內外有一個知識卡搜尋的功能，每個知識卡對應的是一個內網的產品，它和內外小蜜的領域是高度相關的，像這裡面的歡行、愛豆都能找到相關的知識卡片，所以就把企業知識卡當作知識來源。
#
#首先是知識增強，總共有6000 多張企業知識卡片，每張知識卡會有一個實體名稱和一段文字介紹，根據使用者的query 去召回與它相關的知識卡片，把歷史query 也都利用起來，因為有很多query 是相似的，例如內網Wifi 連接，Wifi 內網連接等，相似query 互相之間可以補充語意訊息，進一步緩和短文本的稀疏性。召回除了知識卡實體還有相似 query，連同原始 query 一起送到文字分類模型裡面進行分類。
#用向量召回的方式，召回知識卡的實體和相似 query。用 Bert 分別計算 query 和知識卡文字所描述的具象量。一般來說不會直接使用Bert 的CLS 向量作為句子表徵，很多論文中也有提到，直接使用CLS 向量作為句子表徵效果會很差，因為Bert 輸出的向量會出現表達退化的問題，不適合直接用它做無監督的相似度計算，所以使用對比學習的思想，把相似樣本拉近，讓不相似的樣本盡量均勻分佈。
具體來講，就是在資料集上 finetune 了一個 Sentence-Bert，其模型結構和訓練方式可以產出比較好的句向量表徵。它是一個雙塔的結構，兩邊的 Bert 模型共享模型參數，兩個句子分別輸入到 Bert 裡面， Bert 輸出的 hidden states 做 pooling 之後會得到兩個句子的句向量。這裡優化的目標是對比學習的 Loss，infoNCE。
正例：#直接把樣本輸入到模型裡面兩次，但這兩次的dropout 是不一樣的，所以表徵的向量也會有些微的差異。
負例：#同一個 batch 裡面所有其他的句子。
優化這個 Loss，就得到了 Sentence-Bert 的模型，來預測句向量。
我們使用 StructBERT 模型參數來初始化這裡面的 Bert 的部分。 StructBERT 是達摩院提出的一個預訓練模型，它的模型結構和原生的Bert 是一樣的，其核心思想是在預訓練任務裡面融入語言結構訊息，去獲得query 的句向量和知識卡片，透過計算向量的cosine 相似度，召回最相似的top k 個知識卡和相似query。
#上圖是文字分類的模型結構，在Encoding 層使用Bert提取原始query 和相似query 的詞向量的表徵，每個知識卡的實體會維護一個實體的ID embedding，ID embedding 是隨機初始化的。
模型結構圖右側，用來處理 query 召回的實體，得到實體的統一向量表徵。因為短文本本身比較模糊，所以召回的知識卡實體也會有一定的噪聲，透過使用了兩個 attention 的機制，讓模型更加註意正確的實體。一個是 Query-to-Entity 的Attention，目的是讓模型更注意和 query 相關的實體。另一個是實體本身的 self Attention，可以把彼此之間相似的實體權重提高，降低噪音實體的權重。綜合兩組Attention 權重，就得到最終實體的一個向量表示。
#模型結構圖左側就是處理原始query 和相似query，因為觀察得到，相似query 和原始query 的重合詞語一定程度上可以表徵query 的中心詞，所以這邊計算了每字詞兩兩之間的點擊，得到相似度矩陣做sum pooling，得到原始query 中每個詞語相對相似query 的權重，目的是讓模型更加註意中心詞，然後將相似query 和原始query 的詞向量一起拼接起來，計算融合的語意資訊。
最後上面三個向量再拼接起來，經過 dense 層預測，得到每個類別的機率。
#以上是實驗結果，超過了BERT finetune 的結果，編碼層不用Bert 的話，也是超過了所有非Bert 的模型。
#以採購商城為例，採購商城有自己的商品類目體系，每個商品在上架前會掛載到一個商品類目下。為了提高商城搜尋的準確率，需要把 query 也預測到具體的類目，再根據這個類目調整搜尋排序結果，也可以根據類目結果，在介面上展示子類目導航和相關搜尋。
類別目預測需要手動標註的資料集，但是採購領域，標註的成本比較高，所以從小樣本分類的角度來解決這個問題。
#預訓練模型在NLP 任務上展現了強大的語言理解能力，典型的使用範式是先在大規模的無標註資料集上預先訓練，然後再在有監督的下游任務上進行finetune。例如 Bert 的預訓練任務，它主要是一個 mask 的語言模型，也就是把一個句子裡面的詞語隨機 mask 掉一部分，輸入到原模型中，然後預測 mask 部分的詞語，最大化詞語的似然。
做query 類別目預測本質上就是文字分類的任務，文字分類任務就是把輸入預測到某一個label ID，而這沒有使用label 本身的語意訊息，微調的分類任務和預訓練任務是不一致的，不能最大化地利用預訓練任務學到語言模型，所以出現了一個新的預訓練語言模型。
預訓練語言模型的範式叫做提示學習，Prompt 可以理解為給預訓練語言模型的一個提示線索，幫助它更好地理解人類的問題。具體來說，在輸入文字的基礎上額外添加一段話，這段話裡面會mask 掉和label 相關的詞語，然後讓模型來預測mask 這個位置的詞語，這樣就把分類任務轉化成了mask 語言模型任務，預測了這個mask 位置的詞語之後，往往會需要再把這個詞語映射到標籤集，採購的類目預測就是典型的小樣本分類問題，透過針對類目預測任務構建幾個模板，然後mask 掉的部分就是需要預測的詞語。
對於模板，建立了預測詞到標籤詞的對應。
首先，預測詞不一定就是標籤。因為為了方便訓練，每個樣本的 mask 字元數是一致的，原本的標籤字有 3 個字、4 個字等，這裡把預測字和標籤字都做了映射統一變成兩個字。
#另外，在提示學習的基礎上，使用自學習的框架，先用有標籤數據到每個模板訓練一個模型，然後幾個模型集成起來進行預測無標籤數據，訓練一輪，從中選出置信度高的樣本作為偽標籤數據，加入到訓練集中，這樣就獲得了更多的有標籤數據，再接著訓練一輪模型。
#上圖是一些實驗結果，可以看到在zero shot 場景下分類的效果，預訓練模型用的是Bert base，總共是30 個類，zero shot 已經能達到16% 的準確率了。在 ten shot 資料集上進行訓練，幾種模板最高能達到 56% 的準確率，提升還是比較明顯的，可以看出模板的選擇也會對結果產生一定的影響。
同樣的ten shot 資料集，使用TextCNN 和BERT-finetune 也做了實驗，效果都是遠低於提示學習微調的效果，所以提示學習在小樣本場景是非常有效的。
最後，使用全量數據，約 4000 個訓練樣本，加上自我學習，效果達到了 82% 左右。線上再加入卡閾值等一些後處理，可以確保分類的準確率在 90% 以上。
#企業場景Query 理解有兩大困難：
（1）領域知識的不足，一般短文理解會藉由知識圖譜來做知識增強，但由於企業場景的特殊性，開源的知識圖譜很難滿足需求，所以使用企業內部的半結構化資料來做知識增強。
（2）企業內部的一些專業領域標註資料很少，0 樣本和小樣本的場景特別多，這種情況下很自然地可以想到用預訓練模型加提示學習，但是0 樣本的實驗結果也不是特別好，因為現有的預訓練模型裡面用的語料，其實並沒有覆蓋到我們企業場景的領域知識。
所以是不是可以訓練一個企業級的預訓練大模型，在通用語料的基礎上用企業內部垂直領域的數據，例如阿里的ATA的文章資料、合約資料和程式碼資料等進行訓練，得到一個預訓練大模型，再用提示學習或者是Context learning，把文本分類、NER、文本匹配等各種任務統一成一個語言模型任務。
另外，像是問答QA、搜尋這些事實性任務，如何在生成式語言模型的結果上保證答案的正確性，也是一個需要思考的問題。
A1：模型是自研的，目前還沒有論文和程式碼。
#A2：query 和相似query 是用了token 維度層級的輸入，知識卡只用了ID embedding，因為考慮到知識卡的名字本身，存在一些內部的產品名，在文本語意上並沒有特別的有意義。這些知識卡如果用文本描述的話，只是一段比較長的文本，可能會引入過多的噪聲，所以就沒有使用它的文本描述，只用了這個知識卡的 ID embedding。
A3：ten short 確實只有50% 左右，是因為預訓練的模型並沒有覆蓋到採購領域的一些比較罕見的語料，並且使用的是參數量相對較少的模型BERT-base，所以ten shot 的效果也不是很好，但是使用全量資料的話，可以把準確率做到80% 以上。
A4：這塊目前也是正在探索。主要想法是在語言模型生成之前，運用一些類似強化學習的思路，加入一些人工的回饋，來調整輸出。
在輸入的後面，就是大模型輸出的後面增加一些預處理，預處理的時候可以加入知識圖譜或是其他的一些知識，來保證回答的準確性。
#以上是基於知識增強和預訓練大模型的 Query 意圖識別的詳細內容。更多資訊請關注PHP中文網其他相關文章！
