一、背景介紹

企業數字化是近年來很熱的一個話題，它是指運用人工智能、大數據、云計算等新一代數字技術，改變企業的業務模式，從而推動企業業務產生新的增長。企業數字化一般來說包括業務經營的數字化和企業管理的數字化。本次分享主要介紹企業管理層面的數字化。

信息數字化，簡單來說，就是把信息用數字化的方式進行讀寫、存儲和傳遞。從以前的紙質文檔到現在的電子文檔以及在線協同文檔，信息數字化已經變成了現在辦公的新常態。目前阿里使用釘釘文檔和語雀文檔進行業務協同，在線文檔數量已經達到了 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 意圖識別工作。

1、內外小蜜

內外小蜜底層是基于達摩院推出的云小蜜問答引擎，它可以支持 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 的模型。

2、行業搜索

以采購商城為例，采購商城有自己的商品類目體系，每個商品在上架之前會掛載到一個商品類目下。為了提高商城搜索的準確率，需要把 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、搜索這些事實性任務，如何在生成式語言模型的結果上保證答案的正確性，也是一個需要思考的問題。

四、問答環節

Q1：阿里提供的整個意圖識別的模型，有相關的論文或者代碼嗎？

A1：模型是自研的，目前還沒有論文和代碼。

Q2：目前 query 和相似 query 當中是以 token 級的輸入，檢索出的知識卡片信息在分類模型為什么沒有使用它的具象量，而是僅考慮了 ID 的 embedding？

A2：query 和相似 query 是用了 token 維度級別的輸入，知識卡片只用了 ID embedding，因為考慮到知識卡片的名字本身，存在一些內部的產品名，在文本語義上并沒有特別的有意義。這些知識卡片如果用文本描述的話，只是一段比較長的文本，可能會引入過多的噪聲，所以就沒有使用它的文本描述，只用了這個知識卡片的 ID embedding。

Q3：關于 promote 的相關問題，目前在小樣本的情況下，現在精度只有 16%，ten short 也只有 50，那這樣子的話企業應用上面怎么考慮呢？或者這塊是有什么思路嗎？

A3：ten short 確實就只有 50% 左右，是因為預訓練的模型并沒有覆蓋到采購領域的一些比較罕見的語料，并且使用的是參數量相對較少的模型 BERT-base，所以 ten shot 的效果也不是很好，但是使用全量數據的話，可以把準確率做到 80% 以上。

Q4：剛剛最后提到的企業預訓練大模型回答準確性的保證，方便展開說一說相關內容嗎？

A4：這塊目前也是正在探索。主要想法是在語言模型生成之前，運用一些類似于強化學習的思路，加入一些人工的反饋，來調整輸出。

在輸入的后面，就是大模型輸出的后面增加一些預處理，預處理的時候可以加入知識圖譜或者是其他的一些知識，來保證回答的準確性。