孟子小樣本和檢索式預訓練模型進展

架構師修行手冊發表於2023-04-21

來源:DataFunSummit

導讀 大家好,我是來自瀾舟科技的王宇龍,今天為大家分享的主題是孟子輕量化技術體系,以及我們在小樣本和檢索式預訓練方面的一些進展。

分享分為四部分:

1. 大規模預訓練模型

2. 為什麼要訓練輕量化模型?

3. 孟子模型輕量化技術體系

4. 孟子輕量化預訓練模型開源

分享嘉賓|王宇龍 瀾舟科技 大模型技術負責人

編輯整理|馬慧 匯豐達

出品社群|DataFun



01

大規模預訓練模型

孟子小樣本和檢索式預訓練模型進展

預訓練現在是大家公認的比較核心的 NLP 技術。從 2017 年推出 Transformer,到後來  BERT、 GPT、T5 的預訓練模型。這些模型都是基於自監督學習:利用大規模的無標註的文字學習出一個語言模型,在此基礎之上,針對每一個 NLP 任務,用有限的標註資料進行微調。
這種遷移學習技術推動了整個 NLP 領域的發展,在各種下游任務上都有比較明顯的提升。更為重要的是有了這種預訓練加微調技術,我們可以使用一套技術去解決不同語言的或者是不同的 NLP 任務,有效提升開發效率,標誌著 NLP 進入了一種工業化的實施階段。
當前在預訓練模型領域關注的重點問題包括:
(1)如何訓練超大規模模型;
(2)如何對已有的模型的架構進行創新性的研究;
(3)如何進行更有效的訓練或者訓練加速的方法;
(4)如何簡化微調步驟,比如像 GPT 這種基於 Prompt 的機制來統一所有下游任務微調方法;
(5)除此之外,多模態的預訓練和推理加速也是目前的關注熱點。
02
為什麼要訓練輕量化模型?

孟子小樣本和檢索式預訓練模型進展

像 GPT 這種模型訓練引數量越來越大,為什麼我們會去關注輕量化的預訓練方法?
大家普遍認為,在相同的網路架構或者訓練方法的條件下,隨著模型層數的增加以及引數量的增加,能力就一定增強,但增強幅度實際上是有衰減的,是會越來越小的。
由於訓練一個很大的模型,代價非常大,比如像 GPT3 就達到了百萬美金級別,再加上大模型的落地部署代價也很大。雖然根據摩爾定律,硬體算力在上漲,成本在下降,但是這種硬體能力顯然是追不上目前模型的增長的。
另外,在實際應用當中,尤其是在接觸客戶的使用場景當中,GPT3 系統的模型是很難直接去部署的,尤其是涉及到對延遲或對速度要求比較高的線上業務。
在摩爾定律逐漸走向終結的時代,模型的輕量化是必須要考慮的一條技術路線。
現在輕量化大多數會有兩種途徑:
① 一種是先有一個比較大的模型,透過蒸餾、壓縮等各種手段把它縮成小模型;
② 另外一個方法就是直接訓練一個小的模型。
當然這兩種方法是可以融合的,比如用蒸餾後的模型去給輕量化預訓練模型做初始化。
03
孟子模型輕量化技術體系

孟子小樣本和檢索式預訓練模型進展

上圖是整個瀾舟的輕量化技術體系的概覽,接下來會逐塊去介紹。
1. 知識增強
(1)語言學知識增強

孟子小樣本和檢索式預訓練模型進展

前面我們也提到現在這種大規模預訓練模型,一個非常重要的技術特徵就是使用自監督學習。可以使用大量網際網路上沒有標註的原始語料去學習語言中的知識。
但是無論是 Mask Language Model 或是 Causal Language Model,這些預訓練任務,能學習到的知識完全依賴於文字本身裡面的內容,是有一定侷限性的。
經過我們的一些對比實驗,發現一種比較有效的增加額外知識的方法,就是增加語言學知識。
我們有各種方法去增加語言學知識:
比如使用詞性標註的訊號或者命名實體識別的訊號,去告訴模型或者去指導模型。你不僅要能夠預測出這些句子中被遮蓋的詞或者後續的詞,同時也需要能夠理解每一個詞的詞性或者它是什麼實體類別。這樣相當於是提升了模型學習的任務的強度,模型能夠對文字的理解會更加深刻。
(2)序列關係增強

孟子小樣本和檢索式預訓練模型進展

除了學習這種詞級別的知識,還需要學習句子級別的知識,尤其是一些任務當中會有多句或者篇幅稍微長一些的文件。這裡我們結合 ALBERT 裡面提出的 SOP 訓練任務,能夠帶來比較明顯的提升。 
我們在中文任務上進行了一些測試,發現 NSP 訓練任務其實效果並不是很明顯。
(3)訓練最佳化

孟子小樣本和檢索式預訓練模型進展

像 Mask Language Model 這種基於掩碼的方式,我們可以拆成兩個階段:
① 先透過 Ennoising 的方式去增加 Mask 來構建訓練的樣本;
② 再用模型去還原被破壞的句子。
通常我們會採用隨機的方式去進行 Mask,但是因為不同的詞、不同的樣本的預測難度是不同的:
① 模型在 Denoising 階段,梯度更新的強度和樣本難度之間其實是沒有統一的,可能會造成訓練的不穩定。
② 另外也可能會有些假的負例,比如模型還原出一個詞和原始詞不一致,但實際上也是合理合法的,比如一些近義詞,因為我們通常會採用交叉熵進行模型訓練化,這樣的樣本會判為錯誤的預測,導致訓練時不是特別穩定。

孟子小樣本和檢索式預訓練模型進展

針對上面這個問題,我們增加了一些訓練校正策略。
① 一種是評估 Mask 本身對句子的破壞程度。我們會有假設,當破壞程度越大時候,Loss 應該是越大的,這樣模型需要花更大代價去更新梯度。
② 第二個就是如果預測結果和原始句子之間的語義距離是很小的,那麼 Loss 應該會更小。這是對 Token 級別交叉熵的 Loss 的一個補充。

孟子小樣本和檢索式預訓練模型進展

我們在 BERT 和 ELECTRA 這些模型上進行了一些驗證,發現都能夠提升模型效能,並且有利於模型應對同義詞替換的對抗性的攻擊,提升魯棒性。
2. 模型壓縮
這一部分介紹我們在模型壓縮方面的工作。

孟子小樣本和檢索式預訓練模型進展

上圖是我們整個壓縮,蒸餾、量化一體的 Pipeline。
在預訓練模型越做越大的時代,透過壓縮以及蒸餾的方式去實現輕量化就變得至關重要了。
整個 Pipeline,我們可以有效降低模型的冗餘度,整個模型的引數規模會有顯著地降低。這樣我們就可以將模型部署在線上或者是對推理速度比較敏感場景裡面。
(1)模型壓縮(蒸餾)

孟子小樣本和檢索式預訓練模型進展

我們走訪不同場景的客戶發現大家對模型規模的要求其實是各種各樣的。比如 Large 級別的模型,可能會處理一些對指標敏感的離線任務。Base 級模型可能作為我們實驗的 Baseline。實際上的部署情況,我們可能會要求 66 Million 或者 10 Million 這種級別不同的引數量。
針對這種不同規模模型的蒸餾,我們參考了 MiniLM 基於 Attention 的蒸餾方法。它是基於 KL 散度去蒸餾 Attention 的 QKV 的矩陣。

孟子小樣本和檢索式預訓練模型進展

我們基於這套技術蒸餾了內部的 Mengzi-BERT-Large 的版本,相比於其他蒸餾方法或 Tiny-BERT 這種同尺寸的模型來說,實驗結果效果會有一些優勢。根據用這套技術滿足客戶的需求。比如,如果需要做 Base 級的這種場景,或者想做一些線上場景,我們可以透過一套技術去蒸餾出不同的尺寸來滿足不同延遲需求的業務場景。
(2)模型壓縮(剪枝和量化)

孟子小樣本和檢索式預訓練模型進展

在模型的剪枝和量化方面,我們也做了一些技術探索。
① 受到 Early-Bird 這種篇文章的啟發,我們在模型的 Pre-train 階段進行的 Head 裁剪,使得預訓練的成本有所下降,最終使得模型的推理速度變得更快。
② 另外參考有 ROSITA 在 Fine-tuning 階段其實也可以進行選擇性的結構化的剪枝。首先在層數上進行剪枝,然後在寬度上對 Head、Head Size 和 Depth Size 進行裁剪,最終實現模型引數量下降、推理加速。
可以看這張表中我們實驗資料,考慮到深度和寬度的結構化剪枝方案,對 BERT-Base 級別模型進行剪枝,可以在壓縮比到 61% 的情況下,加速比達到 1.75X 。我們在 Sst-2 任務上做效能測試 ACC 能到 92.1,相比於同等 66 Million 其他模型而言效果會更好。
③ 在結構化剪枝的同時,還可以再同時去結合量化技術去進一步的實現推理速度最佳化。我們在 4 核的 CPU 裝置上進行了這種量化剪枝的結合。最終可以看到相比直接用 PyTorch 可以達到 6 倍左右的加速。
這套 Pipeline 就為我們提供一套更具有適應性的落地方案,根據使用者不同場景可以拿到不同尺寸的模型。
3. 檢索增強
(1)各種架構的檢索增強模型

孟子小樣本和檢索式預訓練模型進展

檢索增強領域,不同公司或者不同團隊在這個方面做了各種各樣工作。
這裡列的是 4 個比較典型的模型:REALM、RAG、RETRO、KNN-LM
這些模型在具體細節上可能各有不同,但是大家去看整體架構,會發現其實有一些相同之處:
這些模型都是透過引入一些外部知識,這樣子模型在一些知識密集型的任務當中就可以獲得更好的能力。就好比進行開卷考試,在考試同時去參考一些外部資料,就可以獲得一個更好的回答。這裡外部資料可能是一些參考數,也可以是一些資料庫,也可以是一個搜尋引擎,形式其實是不限的。但是目前的實現其實有比較大的差異。
為了推進這方面的研究,我們對整個檢索預訓練進行了抽象,同時參考 RATIO 一些實現,對整個架構進行了一些簡化。
(2)檢索預訓練統一抽象實現

孟子小樣本和檢索式預訓練模型進展

這是一個簡化圖,上面所有這些檢索預訓練模型大概都會抽象成這種模式。
① 右側就是我們常講的 T5、 BERT 這種模型;
② 左側是一個檢索服務;
③ 中間這條線是透過一個 API 和模型的 Data Loader 進行通訊,模型在推理或訓練過程中可以拿到相應的參考資料輔助相關的任務。

孟子小樣本和檢索式預訓練模型進展

透過這種方法可以把它的知識去從模型中解耦。也就是我們想學會一門語言的時候,並不需要把整個維基百科給背下來。實際上我們可以把維基百科變成一本參考書,在需要的時候可以找到相應的知識。
這項技術不僅能夠把知識解耦,同時在引數規模上也會有一些減小,這使得我們不再需要那麼大的模型也能達到相似效果。
右上角表格,我們的 Baseline 就是 GPT-neo 125M 模型引數,一般 Perplexity 指標越低越好。透過在 GPT-neo 上增加 200G 的檢索庫,它的 PPL 就從 35 降到 22。如果我們加到 400G,效果就會比 GPT-neo 1.3B 模型效果還要更好,這樣我們會對 GPU 的需求會變得更小,即使考慮到 Inference 上需要一個檢索庫,它的 Inference 時間也會有比較好的提升。當然這裡面還有很多工程最佳化可以去做,使得它的效果變得更好。
使用檢索除了降低模型引數量,外部的知識庫完全變得工程化了,使得我們可以對它進行實時性的調整。比如我們可以把一些檢索策略或者是檢索的內容都進行一些實時性調整,來滿足不同的需求。
4. 多工

孟子小樣本和檢索式預訓練模型進展

多工是最近一年來的重點主題之一,我們可以看到 GPT-2 本身雖然是一個單任務的模型,它學的時候根據前序的文字預測後序文字,但實際上就像它的標題說的一樣,它本質上是一個多工模型,因為在我們的語料中其實蘊涵了各種各樣的任務。比如:在語料當中用 Reddit 這種論壇對話,實際上它的學習任務當中就蘊含了對話場景;可能還會有一些新聞,前面是新聞標題或者 Summary,後面是整個新聞的細節,實際上就是包含文字擴寫,或者在文字最後有一些 Tag ,模型也要去學習從文字預測 Tag 的能力。
這樣在整個 GPT 模型當中,它實際上透過多工方式獲得一個比較好的 Few-shot 或者 Zero-shot 這種能力。我認為這也是大家在 GPT-3 當中看到比較令人驚豔的表現的一個核心原因。但是 GPT-3 實際上對模型的引數規模要求非常高,到 175B 類我們會看到比較好效果。但是如果我們把模擬引數壓到 1B 或者更小,效果就會大打折扣。
但是多工的方式,不僅僅是可以透過 GPT 方式去做,也可以透過 Prompt 的方式去做。如果我們在訓練階段去增加 Prompt,就可以把不同的監督的資料來源引入進來,比如像 GPT 這種文字預測的任務,統一地轉化進來,去設計不同的 Prompt。表中左邊是原始的任務,可能是一些情感分類、新聞分類或者摘要任務,我們透過 Prompt 模板的形式把它統一轉化成一樣的任務。對模型來說,它的預訓練任務其實並沒有太大改變,但是它卻學會了多種多樣的能力。
在這樣的技術支援下,模型的引數量會有所減小。我們在 BigScience 的 T0 那篇文章中可以看到,同時也會讓模型具備各種能力。

孟子小樣本和檢索式預訓練模型進展

這是剛才展開的一個例子,比如我們輸入一段常規的文字,因為在預訓練的階段已經見過各種各樣的 Prompt,我們就可以直接問,比如“找出上述句子中的實體和它們對應的類別”。下面就是一個字串形式的輸出,是一種 K-Value 的形式,比如地址、政府,或者是其中提到的姓名。
(1)孟子模型的零樣本金融資訊抽取平臺

孟子小樣本和檢索式預訓練模型進展

基於這套技術,以及我們前面講到 T5,我們在內部構建了一套基於零樣本技術的金融資訊抽取平臺,使用者可以去構建不同的任務,自定義任務的輸入輸出。比如你只想抽取公司,或者你只想抽取人名,或你只想抽取時間,我們就可以去設計這樣不同的 Prompt。同時我們還會提供一套除錯 UI,你可以根據你的 Prompt,看一下這些 Prompt 在不同任務上會獲得什麼樣的效果。最後你可以把你的 Prompt 等等打包成一個 API 進行除錯。
(2)孟子多工模型的 Zero-Shot 能力

孟子小樣本和檢索式預訓練模型進展

因為我們在預訓練階段見過大量任務,在使用的時候可以去直接調取這些能力。之前包含了常見的實體抽取、相似度,還有一些場景類的,比如金融關係的抽取、廣告文案生成、醫學領域意圖分類等等。這些任務裡面有一些是理解類任務,有一些是生成的任務,但由於 T5 這種架構本身都是基於 Sequence to Sequence 形式,而我們又透過 Prompt 的方式將不同的任務統一成文字生成類的任務,這樣我們就可以只基於一個模型去做各種各樣不同的任務。
(3)Mengzi-T5-base-MT 模型開源

孟子小樣本和檢索式預訓練模型進展

我們基於這套技術訓練的模型,叫做 Mengzi-T5-base-MT。
T5 是我們這次採用的架構,Base 是採用引數量的級別,MT 是 Multi-Task 的意思,在我們去年開源的 T5-base 上去做多工訓練。包含了 27 個資料集,對應大概有 300 多個 Prompt。
我們將模型提交到 ZeroCLUE 庫榜單上,當時是在激烈的競爭中拿到了第一。最近看到有許多公司也有提交,但相比於其他模型,要注意我們的引數量只有 0.2B,而其它一些模型可能有 1.3B。
我們也把模型進行了開源,大家可以到 HuggingFace、ModelScope 網頁上去看,也可以試用、下載模型。或者在 GitHub 上對模型進行一些封裝,可以拿到端到端的 SDK,這個 SDK 包含了 8 項任務,比如情感分類、新聞分類、語義相似度、實體抽取、金融關係抽取、評論物件抽取、廣告文案生成,還有醫療領域意圖識別,具體的細節去可以去看 GitHub 文件。
目前我們看到 HuggingFace 下載量上個月已經達到 10 萬級別,大家有興趣可以去下載試用,評測一下模型效果,也可以給我們提供一些反饋。後續也會根據大家的反饋增加更多能力上的支援,這樣大家就可以用很低成本去完成零樣本場景的任務。
5. 多模態

孟子小樣本和檢索式預訓練模型進展

除了偏文字類,我們在多模態方面也做了一些嘗試。
多模態最近開始發生了比較大的變化。去年我們可能還是在考慮基於 VQ-VAE 去把圖片變成 Token 放進 Transformer 這種結構裡面去做,但是 Diffusion Model 的出現直接帶來了巨大的變化:
① 首先在引數量上讓大家可以在消費級顯示卡上去用,這也是為什麼它能出圈的原因。
② 另外由於它和之前架構不同,導致很多技術都要重新去做了。
可以看到這個是我們在 Stable Diffusion 的基礎之上進行的國畫風格遷移,叫 Guohua Diffusion,也在 HuggingFace 上開源了,大家有興趣可以下載下來玩一玩。
左上角這個是我們去嘗試生成一些電影海報,大家可以猜一下這是用的什麼 Prompt 生成的哪個電影海報。
左下角是一些景觀。後來我們把這個模型放到 Reddit 的 Stable Diffusion 板塊上,社群也有些人拿這個模型去做了各種各樣的嘗試。
右邊六個圖就是一些 Reddit 上有人拿這個模型生成了一些名人的頭像畫。
在我們的官網上,也放了一個基於 Stable Diffusion 的demo,做得比較簡單,更多是讓大家去玩一玩,目前還沒有比較複雜的功能。
改進點主要是:
① 對中文的支援。
② 另外就是一般大家在玩 Stable Diffusion 的時候,都需要寫比較長的 Prompt,各種 Magic 的 Tag 加到後面模型效果就會提升。在我們看來,這種東西學習成本是比較高的,我自己上手也花了很多時間。我們額外做了一個模型,會在後臺幫助大家把 Prompt 進行擴充,這樣你只寫你想要東西,剩下的質量問題就會由後面模型來幫你搞定。

孟子小樣本和檢索式預訓練模型進展

04
孟子輕量化預訓練模型開源

孟子小樣本和檢索式預訓練模型進展

前面講到了我們的各種技術,中間用到的一些模型也會開源。上圖中列出了我們在 Hugging Face 上開源的模型列表,可以看到不同規模以及不同任務型別,幾乎都有支援。
大家有興趣可以去我們的 GitHub 主頁上去看一看。如果發現哪些模型,比如效果或者使用方法不明確,也可以到我們的 GitHub 去提 Issue。

孟子小樣本和檢索式預訓練模型進展

這是我們去年在 CLUE 打榜的成績,當時大家都在用百億模型的時候,我們是用了十億級別模型去做這些任務。目前看當時其實不太需要那麼大規模的模型完成這些任務。
當然今年可以看到有很多公司也在做這方面的嘗試,把模型壓到 1B 或者更小級別,同時能達到大模型的效果。在這方面瀾舟還是走在比較靠前的位置。
小模型會帶來一些很好的技術特性:
① 研發迭代成本的降低。軟體是需要迭代的,而不是一次性搞定的,軟體釋出之後不可能再也不改,模型同樣也是,在我們看來它也是軟體體系的一部分,我們也要繼續對它進行迭代。百萬級別美金的成本去迭代是不現實的,所以我們往往會選擇百 Million 級別去做迭代。
② 另外就是我們還可以做領域遷移。因為不同場景,比如金融或者法律場景,我們很難把 GPT-3 整個去做 Fine-tuning,成本是難以回收的。透過這種小規模模型可以在很低成本上快速地去遷移到某一個領域。
孟子知識服務引擎

孟子小樣本和檢索式預訓練模型進展

基於整個預訓練體系,我們衍生出了不同的應用場景,比如在機器翻譯、文字生成、以及搜尋引擎這些場景中都用到預訓練的模型。去年我們在北京 HICOOL 創意大賽上拿到 AI 和金融賽道的冠軍。

孟子小樣本和檢索式預訓練模型進展

這是雲大所今年的一個大模型應用案例。我們的模型引擎在這裡面做了應用展示,這是我們的榮譽證書。
瀾舟是比較注重和落地場景的,所以我們從輕量化技術出發,和很多合作伙伴完成了各種實際落地的專案。
這是我們一些合作伙伴的列表。大家可以看到無論在翻譯、營銷文案或者金融領域,我們都會有不同的落地案例。

孟子小樣本和檢索式預訓練模型進展

孟子小樣本和檢索式預訓練模型進展

孟子小樣本和檢索式預訓練模型進展
05
問答環節

Q1:加入詞性引導預訓練在大規模資料上怎麼用? 詞性預測本身依賴模型。

A1:這個問題很好,如果按照 Google 方式去做純粹 BERT 預訓練,它所學的所有的訊號都是來自於語料本身,我們蓋住哪個詞,它預測哪個詞,雖然我們加了隨機性,增加資料的廣度,但其實很多知識是不在裡面的。
加入詞性本質上是把監督性引進來。大家做無監督,並不是因為有監督沒有用,而是之前我們沒有那麼多有監督資料。引入無監督大規模訓練之後,我們其實也不應該放棄有監督訊號。無論是做知識的增強,還是後面 T5 的多工學習,本質上都是把有監督的訊號引進來,相當於更多地引入人類的知識,而不是純粹靠沒有額外標註的文字。
Q2:偽標籤就行了?
A2:可能有的表現不好,但大多數標籤詞都是正確的。我們在 SpaCy 做 NER 的時候,在中文和英文上的表現差距挺大的,主要是因為 SpaCy 官方在做英文的 NER 上用的資料質量比較好,可以去官網看一下,他們的預測準確率 ACC 都是比較高的,但是在中文上表現比較差。
所以如果想做中文詞實體識別的增強,是需要做自己的資料去增強模型的。原始模型效果可能並沒有那麼好,所以這本質上還是在增加監督訊號的質量,是一種弱監督學習。
Q3:大模型去學小模型的偽標籤?
A3:可以這麼理解,或者你可以從蒸餾的方式去想也是對的。
Q4:有沒有和 UIE 的對比?
A4:我們其實內部也在對比了,後面會放到 GitHub 上,大家可以去關注。關於UIE,我們之前在瀾舟分享會上做了分享,在我們看來這是比較好的工作,但是思路可能會稍微有些差異。由於我們內部有不同規模的版本,比如 Base、Large,所以我們在進行一些系統性的跟 UIE 的比較。
孟子主要做資訊抽取, 預訓練模型其實並不跟任務繫結。預訓練模型本身是一個底座,上面去做文字理解還是文字生成都可以。這對模型架構會有一些要求。比如你理解類用 BERT 可能是工業化落地最實際的,但是如果你用生成式地去做聲音抽取,可能會在小樣本或者泛化性上獲得比較好的表現,當然這個東西也不是絕對的,具體 Case 具體分析,也可能會有一些融合式的方案.
Q5:百度的是基於抽取式的還是生成式的?
A5:這個細節我不太清楚,對於百度,我理解它更多是構造自己的特殊 Schema,跟我們用 T5 這種純生成方式還不太一樣。我們其實更希望把整個 Pipeline 進行簡化,儘可能去迴歸到更傳統的 Sequence to Sequence 的方式上。這樣使用者如果想要做一種更新的任務的時候不用構造非常複雜的 Pipeline 或者是定義特別精確的 Schema, 只需要把它轉化成一種大多數工程師甚至大多數產品經理能夠理解的任務形式上就可以去增加模型的新的能力。
Q6:利用知識圖譜做預訓練
A6:知識圖譜其實跟語言知識增強一樣,大多數知識圖譜,其實是引入了監督訊號的。比如你拿到常識圖譜,或者是這些示意圖譜裡面的三元組,很多都是經過人工授修正的,取決於你從哪裡拿,這些修正過的結果實際上就是一個非常強硬的監督訊號。
我們可以用各種方式把知識圖譜變成我們的預訓練的任務,或者是預訓練的語料。比如可以基於圖譜三元組去構造句子,對圖譜三元組的關係或者實體進行遮蓋,這樣模型就會去做這件事情。
Q7:檢索增強是在 Neo 上繼續微調了麼?
A7:對,我們現在做的是比較通用的檢索增強的框架。目前考慮到訓練成本,我們先在 GPT-Neo-125M 這個模型上做,其實不叫繼續微調了,因為我們會 Freeze 掉整個 GPT-neo 原始的權重,額外增加檢索模組。也就是說當你把檢索的模組關掉的時候,它的行為會 Fall back 回預設的這種 GPT-neo 的行為上。當然如果你把檢索開啟以後,它就會引入檢索資訊。
相關的配置、整理的資料庫,還有這些檢索, 我們都放在 HuggingFace 以及 GitHub 上,目前已經看到一些國外的團隊進行了完整的復現。有興趣可以去 GitHub 上看一下我們的文件,只要你的磁碟空間夠大,可能會需要幾百 G 的檢索庫,就可以復現這個結果。後續我們可能還會適配到不同的結構上,因為本質上是相通的,比如我們可以適配到 T5、BART、BERT 上都可以,更多是提供一個通用的框架去方便大家做研究。
Q8:有做過對話的下游任務嗎?
A8:在多工裡面是可以很方便去融入的,只不過我們目前的重心會更多地放在金融領域,所以會把抽取類的任務嘗試加強一些。當然,如果你覺得對話比較重要,也歡迎您去我們的 GitHub 參考一下文件,也可以為 Mengzi-SDK 可以增加對話的功能。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70027824/viewspace-2947446/,如需轉載,請註明出處,否則將追究法律責任。

相關文章