一、背景介紹

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

信息數(shù)字化，簡單來說，就是把信息用數(shù)字化的方式進行讀寫、存儲和傳遞。從以前的紙質(zhì)文檔到現(xiàn)在的電子文檔以及在線協(xié)同文檔，信息數(shù)字化已經(jīng)變成了現(xiàn)在辦公的新常態(tài)。目前阿里使用釘釘文檔和語雀文檔進行業(yè)務(wù)協(xié)同，在線文檔數(shù)量已經(jīng)達到了 2000 萬以上。另外很多企業(yè)內(nèi)部會有自己的內(nèi)容社區(qū)，比如阿里的內(nèi)網(wǎng)阿里內(nèi)外，以及技術(shù)社區(qū) ATA，目前 ATA 社區(qū)里面有將近 30 多萬篇技術(shù)文章，都是非常寶貴的內(nèi)容資產(chǎn)。

流程的數(shù)字化，指的是運用數(shù)字技術(shù)改造辦事流程，提高辦事效率。像企業(yè)內(nèi)部行政、IT、人事等會有很多事務(wù)型工作。BPMS 流程管理系統(tǒng)可以把辦事流程標(biāo)準(zhǔn)化，根據(jù)業(yè)務(wù)規(guī)則制定一個工作流，按照工作流自動執(zhí)行，就可以大大降低人工成本。RPA 主要是用來解決流程中多系統(tǒng)切換的問題，因為它可以模擬人工在系統(tǒng)界面上進行點擊輸入的操作，所以它可以連接各個系統(tǒng)平臺。流程數(shù)字化的下一個發(fā)展方向是流程的智能化，通過對話機器人和 RPA 來實現(xiàn)。現(xiàn)在任務(wù)型的對話機器人可以在幾輪對話內(nèi)就幫助用戶完成一些簡單的任務(wù)，比如請假、訂票等等。

業(yè)務(wù)數(shù)字化的目標(biāo)是通過數(shù)字技術(shù)建立一個新的業(yè)務(wù)模式。在企業(yè)內(nèi)部，其實也會有一些業(yè)務(wù)的中臺，比如采購部門的業(yè)務(wù)數(shù)字化，指的是從商品的搜索、采購申請的發(fā)起、采購合同的撰寫、付款、訂單執(zhí)行等一系列流程的數(shù)字化。再比如法務(wù)中臺的業(yè)務(wù)數(shù)字化，以合同中心為例，實現(xiàn)從合同起草開始，到合同審核、合同簽署、合同履約在內(nèi)的合同全生命周期的數(shù)字化。

數(shù)字化產(chǎn)生海量的數(shù)據(jù)和文檔會散落在各個業(yè)務(wù)系統(tǒng)里面，所以需要一個智能的企業(yè)搜索引擎，幫助員工快速定位到他想找的信息。以阿里集團為例，企業(yè)搜索的場景主要有以下幾種：

（1）統(tǒng)一搜索，又稱綜合搜索，它聚合了多個內(nèi)容站點的信息，有釘釘文檔、語雀文檔、 ATA 等等。統(tǒng)一搜索的入口目前是放在阿里的內(nèi)網(wǎng)阿里內(nèi)外以及釘釘?shù)膯T工專屬版，這兩個入口的流量加起來有達到 140 QPS 左右，在 ToB 場景中屬于很高的流量了。

（2）企業(yè)員工助手指的是內(nèi)外小蜜，它是一個面向阿里內(nèi)部員工的智能服務(wù)機器人，匯集了 HR、行政、IT 等多個領(lǐng)域的企業(yè)知識問答服務(wù)，還有快速的辦事通道，包括釘釘?shù)倪@個入口，以及一些外掛入口在內(nèi)，一共開放人群有 25 萬人左右，也是集團的流量陣地之一。

（3）行業(yè)搜索對應(yīng)上一章講到的業(yè)務(wù)的數(shù)字化，比如采購有一個門戶網(wǎng)站叫做采購商城，采購員可以在采購商城里面搜索，選擇商品，提交采購的申請，類似于電商搜索網(wǎng)站，只不過用戶是企業(yè)的采購員；法務(wù)合規(guī)業(yè)務(wù)也有對應(yīng)的一個門戶網(wǎng)站，法務(wù)的同學(xué)可以在里面搜索合同，進行合同的起草、審批、簽署等一系列工作。

一般來說，企業(yè)里面每個業(yè)務(wù)系統(tǒng)或者內(nèi)容站點會有自己的搜索業(yè)務(wù)系統(tǒng)，是需要相互隔離的，但是內(nèi)容站點的隔離會形成信息孤島的現(xiàn)象。比如一個技術(shù)同學(xué)遇到了一個技術(shù)問題，他可能會先去 ATA 搜索問題相關(guān)的技術(shù)文章，搜不到的話再去知否、釘釘文檔、語雀文檔里面搜索類似的內(nèi)容，一共要進行四五次搜索行為，這樣毫無疑問效率是很低的。所以，我們希望能把這些內(nèi)容集合起來，做成一個統(tǒng)一的企業(yè)搜索，只要一次搜索就可以獲得所有相關(guān)的信息。

另外帶有業(yè)務(wù)屬性的行業(yè)搜索一般來說是需要互相隔離的。像采購商城的用戶是集團的采購員，合同中心的用戶是集團的法務(wù)，這兩個搜索場景的用戶量很少，所以用戶行為就會比較稀疏，依賴用戶行為數(shù)據(jù)的推薦算法，效果就會大打折扣。采購、法務(wù)領(lǐng)域的標(biāo)注數(shù)據(jù)也很少，因為需要專業(yè)人員來標(biāo)注，成本很高，所以很難收集到高質(zhì)量的數(shù)據(jù)集。

最后是 Query 和文檔的匹配問題，搜索的 Query 長度基本在十幾個詞以內(nèi)，是短文本，缺少上下文，語義信息不夠豐富，針對于短文本的理解，學(xué)術(shù)界有很多相關(guān)的研究工作。搜索的 Item 基本上都是長文檔，字符數(shù)量在幾百到幾千之間，對長文檔的內(nèi)容理解和表征也是一個很有難度的任務(wù)。

上圖展示的是目前我們的企業(yè)搜索的基本架構(gòu)。這里主要介紹統(tǒng)一搜索的部分。

目前統(tǒng)一搜索接入了 ATA、釘釘文檔、語雀文檔等大大小小 40 多個內(nèi)容站點。使用阿里自研的 Ha3 引擎進行召回和粗排，在召回之前會調(diào)用算法的 QP 服務(wù)對用戶 Query 進行分析，提供 Query 的分詞、糾錯、term 權(quán)重、query 擴展、NER 意圖識別等。根據(jù) QP 的結(jié)果和業(yè)務(wù)邏輯，在引擎?zhèn)绕春貌樵兇M行召回?；?Ha3 的粗排插件可以支持一些輕量級的排序模型，比如 GBDT 等等。在精排階段可以使用更復(fù)雜的模型進行排序，主要用相關(guān)性模型來保證搜索的準(zhǔn)確性，以及點擊率預(yù)估模型直接優(yōu)化點擊率。

除了搜索排序之外，還沉淀了其他的一些搜索周邊功能，比如搜索下拉框的搜索直達區(qū)、聯(lián)想詞、相關(guān)搜索、熱門搜索等。目前上層支持的業(yè)務(wù)主要是阿里內(nèi)外和阿里釘釘?shù)慕y(tǒng)一搜索、采購和法務(wù)的垂直搜索，還有 ATA Teambition OKR 系統(tǒng)的 Query 理解。

上圖是企業(yè)搜索 QP 的大致架構(gòu)，QP 服務(wù)部署在一個叫做 DII 的算法在線服務(wù)平臺上。DII 平臺，可以支持 KV 表、index 表索引的構(gòu)建和查詢，其整體是一個鏈?zhǔn)椒?wù)框架，需要把復(fù)雜的業(yè)務(wù)邏輯拆分成相對獨立和內(nèi)聚的業(yè)務(wù)模塊。比如，阿里內(nèi)外的搜索 QP 服務(wù)，就拆分成分詞、糾錯、查詢擴展、term weight、意圖識別等多個功能模塊。鏈?zhǔn)娇蚣艿暮锰幨欠奖愣嗳藚f(xié)作開發(fā)，每個人負(fù)責(zé)各自模塊的開發(fā)，只要約定好上下游接口就可以，并且不同的 QP 服務(wù)可以復(fù)用同一個模塊，減少重復(fù)代碼。此外，在底層的算法服務(wù)上面包了一層，對外提供 TPP 接口。TPP 是阿里內(nèi)部的一個成熟的算法推薦平臺，可以很方便地做 AB 實驗和彈性擴容，日志打點和監(jiān)控報警的機制也非常成熟。

在 TPP 側(cè)進行 Query 的預(yù)處理，然后組裝 DII 請求，調(diào)用 DII 算法服務(wù)，獲得結(jié)果之后進行解析，最后返回給調(diào)用方。

二、工作分享

接下來介紹兩個企業(yè)場景下的 Query 意圖識別工作。

1、內(nèi)外小蜜

內(nèi)外小蜜底層是基于達摩院推出的云小蜜問答引擎，它可以支持 FAQ 問答、多輪任務(wù)型問答、知識圖譜問答。上圖右邊展示的是 FAQ 問答引擎的大致框架。

用戶輸入一個 Query 之后，開始會有一個規(guī)則干預(yù)模塊，主要是讓業(yè)務(wù)和運營來設(shè)置一些規(guī)則，如果命中規(guī)則的話，就直接返回設(shè)定的答案，如果沒有命中規(guī)則就走算法。意圖識別的模塊，把用戶 Query 預(yù)測到對應(yīng)的業(yè)務(wù)線，每個業(yè)務(wù)線的 FAQ 知識庫里面有很多的 QA 對，每個問題會配置一些相似問法。用 Query 去知識庫檢索得到 QA 對候選集，然后再通過文本匹配模塊來對 QA 對進行精排，根據(jù)模型打分來判斷是答案直出，還是推薦關(guān)聯(lián)問題，還是無答案。除了 FAQ 問答引擎之外，還會有任務(wù)型問答和知識圖譜問答等其他的問答引擎，所以，最后設(shè)計多模塊的 ranker 來選擇透出哪個引擎的答案給用戶。

下面重點介紹一下意圖識別這個模塊。

通過統(tǒng)計過去一年內(nèi)外小蜜的用戶 Query，發(fā)現(xiàn)大部分的用戶 Query 字?jǐn)?shù)集中在 0- 20 之間，80% 以上的 Query 字?jǐn)?shù)在 10 以內(nèi)，所以，內(nèi)外小蜜的意圖識別是一個短文本分類的問題，短文本次數(shù)很少，所以如果用傳統(tǒng)的向量空間模型表示，會造成向量空間的稀疏。并且一般來說短文本表述會不太規(guī)范，簡稱和不規(guī)范用語很多，所以 OOV 的現(xiàn)象也比較多。

小蜜的短文本 Query 還有一個特點，就是會有很多專有名詞，一般是內(nèi)部的平臺和工具名，比如歡行、愛豆等等。這些專有名詞本身文本也不具備類別相關(guān)的語義信息，所以很難學(xué)到有效的語義表示，所以我們想到用知識增強來解決這個問題。

一般的知識增強會用開源知識圖譜，但是企業(yè)內(nèi)部的專有名詞沒辦法在開源的知識圖譜里面找到對應(yīng)的實體，所以我們就從內(nèi)部找知識。剛好阿里內(nèi)外有一個知識卡片搜索的功能，每個知識卡片對應(yīng)的是一個內(nèi)網(wǎng)的產(chǎn)品，它和內(nèi)外小蜜的領(lǐng)域是高度相關(guān)的，像這里面的歡行、愛豆都能找到相關(guān)的知識卡片，所以就把企業(yè)知識卡片作為知識來源。

方法分成兩步：

首先是知識增強，一共有 6000 多個企業(yè)知識卡片，每個知識卡片會有一個實體名和一段文本介紹，根據(jù)用戶的 query 去召回與它相關(guān)的知識卡片，把歷史 query 也都利用起來，因為有很多 query 是相似的，比如內(nèi)網(wǎng) Wifi 連接，Wifi 內(nèi)網(wǎng)連接等，相似 query 互相之間可以補充語義信息，進一步緩解短文本的稀疏性。召回除了知識卡片實體還有相似 query，連同原始 query 一起送到文本分類模型里面進行分類。

用向量召回的方式，召回知識卡片的實體和相似 query。用 Bert 分別計算 query 和知識卡片文本描述的具象量。一般來說不會直接使用 Bert 的 CLS 向量作為句子表征，很多論文中也有提到，直接使用 CLS 向量作為句子表征效果會很差，因為 Bert 輸出的向量會出現(xiàn)表達退化的問題，不適合直接用它做無監(jiān)督的相似度計算，所以使用對比學(xué)習(xí)的思想，把相似樣本拉近，讓不相似的樣本盡量均勻分布。

具體來講，就是在數(shù)據(jù)集上 finetune 了一個 Sentence-Bert，其模型結(jié)構(gòu)和訓(xùn)練方式可以產(chǎn)出比較好的句向量表征。它是一個雙塔的結(jié)構(gòu)，兩邊的 Bert 模型共享模型參數(shù)，兩個句子分別輸入到 Bert 里面， Bert 輸出的 hidden states 做 pooling 之后會得到兩個句子的句向量。這里優(yōu)化的目標(biāo)是對比學(xué)習(xí)的 Loss，infoNCE。

正例：直接把樣本輸入到模型里面兩次，但是這兩次的 dropout 是不一樣的，所以表征的向量也會有些微的差別。

負(fù)例：同一個 batch 里面所有其他的句子。

優(yōu)化這個 Loss，就得到了 Sentence-Bert 的模型，來預(yù)測句向量。

我們使用 StructBERT 模型參數(shù)來初始化這里面的 Bert 的部分。StructBERT 是達摩院提出的一個預(yù)訓(xùn)練模型，它的模型結(jié)構(gòu)和原生的 Bert 是一樣的，其核心思想是在預(yù)訓(xùn)練任務(wù)里面融入語言結(jié)構(gòu)信息，去獲得 query 的句向量和知識卡片，通過計算向量的 cosine 相似度，召回最相似的 top k 個知識卡片和相似 query。

上圖是文本分類的模型結(jié)構(gòu)，在 Encoding 層使用 Bert 提取原始 query 和相似 query 的詞向量的表征，每個知識卡片的實體會維護一個實體的 ID embedding，ID embedding 是隨機初始化的。

模型結(jié)構(gòu)圖右側(cè)，用來處理 query 召回的實體，得到實體的統(tǒng)一向量表征。因為短文本本身比較模糊，所以召回的知識卡片實體也會有一定的噪聲，通過使用了兩個 attention 的機制，讓模型更加注意正確的實體。一個是 Query-to-Entity 的Attention，目的是讓模型更注意和 query 相關(guān)的實體。另一個是實體本身的 self Attention，可以把互相之間相似的實體權(quán)重提高，降低噪聲實體的權(quán)重。綜合兩組Attention 權(quán)重，就得到最終實體的一個向量表示。

模型結(jié)構(gòu)圖左側(cè)就是處理原始 query 和相似 query，因為觀察得到，相似 query 和原始 query 的重合詞語一定程度上可以表征 query 的中心詞，所以這邊計算了每個詞語兩兩之間的點擊，得到相似度矩陣做 sum pooling，得到原始 query 中每個詞語相對相似 query 的權(quán)重，目的是讓模型更加注意中心詞，然后將相似 query 和原始 query 的詞向量一起拼接起來，計算融合的語義信息。

最后上面三個向量再拼接起來，經(jīng)過 dense 層預(yù)測，得到每個類別的概率。

以上是實驗結(jié)果，超過了 BERT finetune 的結(jié)果，編碼層不用 Bert 的話，也是超過了所有非 Bert 的模型。

2、行業(yè)搜索

以采購商城為例，采購商城有自己的商品類目體系，每個商品在上架之前會掛載到一個商品類目下。為了提高商城搜索的準(zhǔn)確率，需要把 query 也預(yù)測到具體的類目，再根據(jù)這個類目調(diào)整搜索排序結(jié)果，也可以根據(jù)類目結(jié)果，在界面上展示子類目導(dǎo)航和相關(guān)搜索。

類目預(yù)測需要人工標(biāo)注的數(shù)據(jù)集，但是采購領(lǐng)域，標(biāo)注的成本比較高，所以從小樣本分類的角度來解決這個問題。

預(yù)訓(xùn)練模型在 NLP 任務(wù)上展示了強大的語言理解能力，典型的使用范式是先在大規(guī)模的無標(biāo)注數(shù)據(jù)集上預(yù)訓(xùn)練，然后再在有監(jiān)督的下游任務(wù)上進行 finetune。比如 Bert 的預(yù)訓(xùn)練任務(wù)，它主要是一個 mask 的語言模型，也就是把一個句子里面的詞語隨機 mask 掉一部分，輸入到原模型中，然后預(yù)測 mask 部分的詞語，最大化詞語的似然。

做 query 類目預(yù)測本質(zhì)上就是文本分類的任務(wù)，文本分類任務(wù)就是把輸入預(yù)測到某一個 label ID，而這沒有使用 label 本身的語義信息，微調(diào)的分類任務(wù)和預(yù)訓(xùn)練任務(wù)是不一致的，不能最大化地利用預(yù)訓(xùn)練任務(wù)學(xué)到語言模型，所以出現(xiàn)了一個新的預(yù)訓(xùn)練語言模型。

預(yù)訓(xùn)練語言模型的范式叫做提示學(xué)習(xí)，Prompt 可以理解為給預(yù)訓(xùn)練語言模型的一個提示線索，幫助它更好地理解人類的問題。具體來說，在輸入文本的基礎(chǔ)上額外添加一段話，這段話里面會 mask 掉和 label 相關(guān)的詞語，然后讓模型來預(yù)測 mask 這個位置的詞語，這樣就把分類任務(wù)轉(zhuǎn)化成了 mask 語言模型任務(wù)，預(yù)測了這個 mask 位置的詞語之后，往往會需要再把這個詞語映射到標(biāo)簽集，采購的類目預(yù)測就是典型的小樣本分類問題，通過針對類目預(yù)測任務(wù)構(gòu)建幾個模板，然后 mask 掉的部分就是需要預(yù)測的詞語。

對于模板，建立了預(yù)測詞到標(biāo)簽詞的映射。

首先，預(yù)測詞不一定就是標(biāo)簽。因為為了方便訓(xùn)練，每個樣本的 mask 字符數(shù)是一致的，原本的標(biāo)簽詞有 3 個字、4 個字等，這里把預(yù)測詞和標(biāo)簽詞都做了映射統(tǒng)一變成兩個字。

另外，在提示學(xué)習(xí)的基礎(chǔ)上，使用自學(xué)習(xí)的框架，先用有標(biāo)簽數(shù)據(jù)到每個模板訓(xùn)練一個模型，然后幾個模型集成起來進行預(yù)測無標(biāo)簽數(shù)據(jù)，訓(xùn)練一輪，從中選出置信度高的樣本作為偽標(biāo)簽數(shù)據(jù)，加入到訓(xùn)練集中，這樣就獲得了更多的有標(biāo)簽數(shù)據(jù)，再接著訓(xùn)練一輪模型。

上圖是一些實驗結(jié)果，可以看到在 zero shot 場景下分類的效果，預(yù)訓(xùn)練模型用的是 Bert base，一共是 30 個類，zero shot 已經(jīng)能達到 16% 的準(zhǔn)確率了。在 ten shot 數(shù)據(jù)集上進行訓(xùn)練，幾種模板最高能達到 56% 的準(zhǔn)確率，提升還是比較明顯的，可以看出模板的選擇也會對結(jié)果產(chǎn)生一定的影響。

同樣的 ten shot 數(shù)據(jù)集，使用 TextCNN 和 BERT-finetune 也做了實驗，效果都是遠(yuǎn)低于提示學(xué)習(xí)微調(diào)的效果，所以提示學(xué)習(xí)在小樣本場景是非常有效的。

最后，使用全量數(shù)據(jù)，約 4000 條訓(xùn)練樣本，加上自學(xué)習(xí)，效果達到了 82% 左右。線上再加入卡閾值等一些后處理，可以保證分類的準(zhǔn)確率在 90% 以上。

三、總結(jié)思考

企業(yè)場景 Query 理解有兩大難點：

（1）領(lǐng)域知識的不足，一般短文本理解會借助知識圖譜來做知識增強，但由于企業(yè)場景的特殊性，開源的知識圖譜很難滿足需求，所以使用企業(yè)內(nèi)部的半結(jié)構(gòu)化數(shù)據(jù)來做知識增強。

（2）企業(yè)內(nèi)部的一些專業(yè)領(lǐng)域標(biāo)注數(shù)據(jù)很少，0 樣本和小樣本的場景特別多，這種情況下很自然地可以想到用預(yù)訓(xùn)練模型加提示學(xué)習(xí)，但是 0 樣本的實驗結(jié)果也不是特別好，因為現(xiàn)有的預(yù)訓(xùn)練模型里面用的語料，其實并沒有覆蓋到我們企業(yè)場景的領(lǐng)域知識。

所以是不是可以訓(xùn)練一個企業(yè)級的預(yù)訓(xùn)練大模型，在通用語料的基礎(chǔ)上用企業(yè)內(nèi)部垂直領(lǐng)域的數(shù)據(jù)，比如阿里的 ATA 的文章數(shù)據(jù)、合同數(shù)據(jù)和代碼數(shù)據(jù)等進行訓(xùn)練，得到一個預(yù)訓(xùn)練大模型，再用提示學(xué)習(xí)或者是 Context learning，把文本分類、NER、文本匹配等各種任務(wù)統(tǒng)一成一個語言模型任務(wù)。

另外，像問答 QA、搜索這些事實性任務(wù)，如何在生成式語言模型的結(jié)果上保證答案的正確性，也是一個需要思考的問題。

四、問答環(huán)節(jié)

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

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

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

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

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

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

Q4：剛剛最后提到的企業(yè)預(yù)訓(xùn)練大模型回答準(zhǔn)確性的保證，方便展開說一說相關(guān)內(nèi)容嗎？

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

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