復(fù)雜度（Complexity）

在接觸了工業(yè)界的應(yīng)用場景和工作后，我最大的感觸就是：復(fù)雜度（Complex）。我之所以用復(fù)雜度（Complex）而不是困難度（Complication, Difficulty），是因?yàn)槿绻颜麄€(gè)工作拆分為每個(gè)小塊，你會(huì)發(fā)現(xiàn)每部分其實(shí)都不算難（或者說大部分都不算難），但是因?yàn)檎麄€(gè)搜索全鏈路涉及到的模塊太多了，整個(gè)全鏈路需要參與的流程也太多了，組成如此復(fù)雜的系統(tǒng)勢必帶來巨大的復(fù)雜度，而合理地控制復(fù)雜度并不是容易的事情。土豆認(rèn)為任何一個(gè)系統(tǒng)都可以拆分為復(fù)雜度和困難度兩個(gè)維度進(jìn)行分析。

我們知道信息檢索的基本過程可以分為：信息爬取，召回，粗排，精排，重排等四個(gè)步驟，而我們作為搜索策略更為關(guān)心的是后面四個(gè)步驟。這每個(gè)步驟中都蘊(yùn)含著數(shù)不盡的策略在里面，其中不少策略還是上下游耦合在一起的，因此所謂牽一發(fā)而動(dòng)全身，上游某個(gè)策略小小的改動(dòng)可能導(dǎo)致下游排序結(jié)果的巨大區(qū)別。這意味著在策略迭代過程中，如果在線上出現(xiàn)bad case，要對其進(jìn)行調(diào)試并不是一件容易的事情。導(dǎo)致這個(gè)bad case的根本原因可能并不是迭代的策略帶來的，比如說可能是某些doc由于在線上的某些特征因某些原因（比如在線特征 or 在線字典請求超時(shí)，特征覆蓋率問題等等）而沒有取到，而該doc又被迭代的策略排到精排了，那么就可能導(dǎo)致bad case，然而這個(gè)bad case的本質(zhì)原因并不是你迭代的策略。這種例子還有不少，總得來說上游策略大的影響更容易傳遞到下游策略中，如果下游策略無法兜住上游策略帶來的影響，就可能爆出很多bad case了。

從我目前的認(rèn)知來看，我會(huì)把復(fù)雜度拆分到以下幾個(gè)較為獨(dú)立的部分中：離線調(diào)研，在線調(diào)研，模型上線。其中離線調(diào)研和在線調(diào)研可能又能分為：數(shù)據(jù)，模型，人工規(guī)則策略，效果評估流程及其輔助工具。在線調(diào)研又包含有：模型在線化工具及其流程，在線效果評估等。

離線調(diào)研

當(dāng)分析某個(gè)策略的bad case發(fā)現(xiàn)了可改進(jìn)點(diǎn)時(shí)，會(huì)先考慮對模型或者策略進(jìn)行離線調(diào)研，也就是在離線數(shù)據(jù)集上進(jìn)行回歸，直到在離線數(shù)據(jù)集上比基線有較大幅度的提升為止。這個(gè)過程通常會(huì)包括：數(shù)據(jù)的升級，模型的改進(jìn)，人工規(guī)則策略的改進(jìn)和效果評估等。

數(shù)據(jù)

搜索過程中每一步都是對上一步返回結(jié)果更優(yōu)的排序/召回，精確度越來越高，doc數(shù)量也越來越少。顯然每一步驟的數(shù)據(jù)分布也就有著非常大的區(qū)別，如果策略生效在某個(gè)步驟，如何挑選更符合該步驟的訓(xùn)練和測試數(shù)據(jù)，如何進(jìn)行合適的標(biāo)注，是一個(gè)非常關(guān)鍵的問題。如果構(gòu)建的測試數(shù)據(jù)并不能很好地表征線上的數(shù)據(jù)分布，那么即便在離線階段取得了不錯(cuò)的收益，一旦進(jìn)入在線調(diào)研就可能出現(xiàn)負(fù)向的結(jié)論。在『數(shù)據(jù)』這塊兒，又可以分為無標(biāo)注數(shù)據(jù)和有標(biāo)注的數(shù)據(jù)，無標(biāo)注數(shù)據(jù)典型的就是用戶行為數(shù)據(jù)，比如展現(xiàn)無點(diǎn)擊的query-doc對，點(diǎn)擊次數(shù)小于某個(gè)閾值的doc，停留時(shí)間小于某個(gè)閾值的doc等等，用戶行為在一定意義上可以表示query-doc的需求滿足程度。通過篩選出海量的無標(biāo)注數(shù)據(jù)，可以對模型進(jìn)行預(yù)訓(xùn)練從而大大增強(qiáng)模型的表征能力。相關(guān)預(yù)訓(xùn)練在信息檢索中的應(yīng)用見[7,8]。有標(biāo)注的數(shù)據(jù)通常數(shù)量量級遠(yuǎn)比無標(biāo)注數(shù)據(jù)少，通常是萬級別到十萬級別，有標(biāo)注的數(shù)據(jù)一般可以用于Finetune預(yù)訓(xùn)練模型，或者可以用于訓(xùn)練Learning To Rank（LTR）模型，比如GBDT/GBRank模型。通常對于標(biāo)注數(shù)據(jù)而言，根據(jù)產(chǎn)品的定為，會(huì)有若干檔位，比如描述相關(guān)性的0-4檔，描述質(zhì)量性的0-3檔，搜索過程中的不同階段中的數(shù)據(jù)檔位分布也是不同，而用于Finetune預(yù)訓(xùn)練模型和訓(xùn)練LTR模型的訓(xùn)練數(shù)據(jù)的檔位分布是很重要的，如果數(shù)據(jù)檔位構(gòu)建有偏置，很容易出現(xiàn)離在線效果不一致的現(xiàn)象。

注意到即便是某一步驟的數(shù)據(jù)分布和數(shù)據(jù)檔位分布也不會(huì)是一成不變的，而是隨著時(shí)間而變化的，這意味著需要定期對離線數(shù)據(jù)集進(jìn)行更新，同時(shí)需要定期對模型進(jìn)行迭代。在這個(gè)過程中會(huì)產(chǎn)生若干版本的數(shù)據(jù)集，當(dāng)?shù)螖?shù)多了后，對數(shù)據(jù)集的版本管理問題也是一件不可忽視的復(fù)雜度問題。人都會(huì)犯錯(cuò)，特別是在一堆命名規(guī)則不一致，版本管理混亂，數(shù)據(jù)預(yù)處理過程模糊，產(chǎn)出時(shí)間不明的數(shù)據(jù)集面前，一旦用期望外的數(shù)據(jù)集進(jìn)行了模型的訓(xùn)練和測試，將會(huì)產(chǎn)生難以debug的問題，模型評估的結(jié)論也會(huì)不置信，甚至影響后續(xù)的在線調(diào)研階段，產(chǎn)生很大的離在線不一致問題。解決問題的最好時(shí)機(jī)便是在問題發(fā)生之前，土豆在吃了好一些實(shí)踐中的教訓(xùn)之后，發(fā)現(xiàn)數(shù)據(jù)集的版本管理和有效的文件命名規(guī)則是相當(dāng)必要的，對于我來說，通常會(huì)考慮這樣對數(shù)據(jù)文件管理：

對于普通的小規(guī)模數(shù)據(jù)集而言（通常數(shù)據(jù)量在幾十萬以下，用單個(gè)或少量文件可以組織，通常是文本形式的數(shù)據(jù)），進(jìn)行規(guī)則的數(shù)據(jù)文件命名管理，命名規(guī)則如下：

文件名規(guī)則為： comment_phase_num.date.producer.process.type

對于大規(guī)模的數(shù)據(jù)（通常是用于預(yù)訓(xùn)練的數(shù)據(jù)），規(guī)模在千萬到億級別，由于數(shù)據(jù)量過大會(huì)采用分part的方式儲(chǔ)存在集群中，這個(gè)時(shí)候無法對每個(gè)文件名進(jìn)行統(tǒng)一管理（每個(gè)part的文件名通常是part-xxxxx，同個(gè)數(shù)據(jù)集的所有part都在同一個(gè)文件夾內(nèi)儲(chǔ)存），通常對文件夾名進(jìn)行管理即可，并且最好在wiki中對數(shù)據(jù)細(xì)節(jié)進(jìn)行記錄。

數(shù)據(jù)命名方式無法表明數(shù)據(jù)的分布情況，還需要同步有wiki記錄每個(gè)數(shù)據(jù)集的數(shù)據(jù)分布情況，比如數(shù)據(jù)檔位分布情況等。

工作中遇到的很多數(shù)據(jù)都是以文本的形式組織的，即便遇到多模態(tài)數(shù)據(jù)集，也會(huì)將圖片轉(zhuǎn)成base64編碼的字符串后進(jìn)行儲(chǔ)存。通常文本形式的數(shù)據(jù)會(huì)存在有多個(gè)字段，不同字段之間通過特殊不可視字符隔開（比如\t \1 \2 ）等，為了方便日常工作中對數(shù)據(jù)進(jìn)行查看，處理和分析，有以下若干工具是值得深入學(xué)習(xí)和掌握的，比如：

• awk: 一個(gè)強(qiáng)大的文本處理工具，以數(shù)據(jù)行為處理單位，提供有很多基本的字符串處理函數(shù)，并且提供有類C語言的編程接口，可以對數(shù)據(jù)字段進(jìn)行靈活的處理，支持正則表達(dá)式
• sed: Stream EDitor, 對數(shù)據(jù)流的流式處理，可以自動(dòng)編輯和處理文本，比如字符串替換，查找刪除，指定行輸出等等，支持正則表達(dá)式
• tr: TRansform, 用于對字符串的轉(zhuǎn)換或者刪除
• grep: 專為字符串查找而生，用于查找字符串中符合條件的字符串，支持正則表達(dá)式

之前土豆整理了一些在工作中比較常用的一些命令 [9]，歡迎一起交流~ 數(shù)據(jù)是模型的糧食，可以說萬物源于數(shù)據(jù)，再怎么小心都不為過。

模型

就土豆的感知而言，對于搜索系統(tǒng)而言，在大部分場景中，數(shù)據(jù)的關(guān)鍵程度要比模型高。眾所周知，對模型結(jié)構(gòu)的改造和設(shè)計(jì)，很多時(shí)候可以看成是對建模問題引入先驗(yàn)知識，比如卷積網(wǎng)絡(luò)的設(shè)計(jì)初衷就是引入了視覺統(tǒng)計(jì)特征具有局部性的先驗(yàn)知識，而引入先驗(yàn)知識的主要原因很大程度上在于可利用的數(shù)據(jù)稀少，通過引入模型先驗(yàn)知識從而減少數(shù)據(jù)的需求。然而，搜索系統(tǒng)中有著大量可用于預(yù)訓(xùn)練的用戶行為數(shù)據(jù)，這些數(shù)據(jù)雖然嘈雜（可視為弱標(biāo)注數(shù)據(jù)），經(jīng)過一番篩選和濾波后仍可提供非常寶貴的信息量。當(dāng)一個(gè)模型有足夠的表征能力時(shí)，通過充足的預(yù)訓(xùn)練足以提供良好的模型先驗(yàn)，而類Transformer模型（如BERT，ERNIE，GPT等）正是這一類模型。以百度的ERNIE [10,11]為例，在大部分場景中對模型結(jié)構(gòu)的改動(dòng)是很微小的，大多集中在：

在精排階段需要更為精確的模型打分，通常是Transformer模型大展身手的地方，一些涉及到Query-Doc聯(lián)合建模的單塔Transformer模型（比如Query-Title相關(guān)性，Query-Title-Content相關(guān)性）需要在線計(jì)算。層數(shù)較多的Transformer模型計(jì)算復(fù)雜度較高（當(dāng)然效果也更好），通常需要大量資源才能支撐得起，為了減少資源的消耗需要進(jìn)行模型的小型化，比如模型量化，剪枝，蒸餾等，以微小的模型性能損失換來大量的資源節(jié)省。

在模型階段很重要的一點(diǎn)是模型的訓(xùn)練超參數(shù)配置和訓(xùn)練方式，比如模型的初始化方式，訓(xùn)練的學(xué)習(xí)率，優(yōu)化器，權(quán)重衰減方式，學(xué)習(xí)率采用的一些動(dòng)態(tài)更新策略（余弦衰減，退火，warmup等），對于多任務(wù)學(xué)習(xí)，還需要考慮不同任務(wù)的訓(xùn)練方式（交替進(jìn)行？用加權(quán)l(xiāng)oss的方式同時(shí)訓(xùn)練？可持續(xù)訓(xùn)練？），對于GAN這類訓(xùn)練需要精細(xì)控制Generator和Discriminator訓(xùn)練過程的模型來說可能就更需要注意了。

個(gè)人認(rèn)為，模型層面的復(fù)雜度主要體現(xiàn)在：

1. 通常調(diào)優(yōu)一個(gè)模型需要嘗試很多超參數(shù)，這意味著需要進(jìn)行很多對照實(shí)驗(yàn)，當(dāng)實(shí)驗(yàn)數(shù)量多起來后如何對實(shí)驗(yàn)進(jìn)行良好管理是一種復(fù)雜度問題，一個(gè)實(shí)驗(yàn)的什么指標(biāo)是需要記錄的？訓(xùn)練曲線，測試指標(biāo)，測試樣本的原始打分輸出，超參數(shù)網(wǎng)格，數(shù)據(jù)集，數(shù)據(jù)處理方式… 如何對實(shí)驗(yàn)進(jìn)行管理也是一個(gè)值得注意的內(nèi)容。
2. 通常在對模型調(diào)優(yōu)過程中會(huì)對代碼進(jìn)行多次修改和調(diào)整，如果修改過于頻繁，而且沒做好代碼版本管理，那么就會(huì)是一場噩夢。想象下你昨天在某個(gè)旮旯角輕微修改了模型的結(jié)構(gòu)，睡了一覺第二天可能就忘記了，然后跑了一版調(diào)參實(shí)驗(yàn)… 這個(gè)輕微的修改將會(huì)對后續(xù)所有實(shí)驗(yàn)造成影響，并且是在你不知曉的前提下，導(dǎo)致所有實(shí)驗(yàn)結(jié)論可能都不置信。對此，有以下建議：

• 代碼的版本管理：代碼管理永遠(yuǎn)是管理復(fù)雜度的一個(gè)神器，最常用的莫過于git和svn，永遠(yuǎn)保持stable分支穩(wěn)定可用，dev分支進(jìn)行架構(gòu)開發(fā)迭代，expt分支用于日常實(shí)驗(yàn)（通常expt分支只需要修改超參數(shù)配置，而不需要改動(dòng)代碼），對commit進(jìn)行規(guī)范的命名，比如參考文章優(yōu)雅的提交你的 Git Commit Message [12]， 采用[head, body, footer]的形式進(jìn)行命名。永遠(yuǎn)不要為難未來將會(huì)閱讀自己代碼的自己。
• 代碼架構(gòu)功能分離： 對整個(gè)代碼架構(gòu)進(jìn)行合理的功能分離，比如將整個(gè)項(xiàng)目分為模型層（model），模塊層（module，模型層將會(huì)從模塊層調(diào)用小模塊構(gòu)成模型，比如RNN模塊，Conv模塊，Transformer Encoder模塊等）, 配置層（config，以yaml或者其他格式儲(chǔ)存超參數(shù)），數(shù)據(jù)讀取層（data_reader），數(shù)據(jù)廣場（data_playground，可用于數(shù)據(jù)分析，后處理等，放置jupyter notebook腳本等），主程序?qū)樱╩ain_process，用于組織訓(xùn)練和測試過程，是整個(gè)訓(xùn)練/測試任務(wù)的入口）,啟動(dòng)層(launch，用于放置任務(wù)啟動(dòng)腳本，用于調(diào)用主程序進(jìn)行訓(xùn)練/測試，通常還需要負(fù)責(zé)數(shù)據(jù)掛載，日志文件目錄有效性檢查，隨機(jī)種子設(shè)置等等輔助過程)，優(yōu)化器層(optim，用于放置需要的優(yōu)化器)，參數(shù)解析器(parser，定義參數(shù)解析器，通常可以從yaml文件里讀取配置)，工具類（utils，一些常用工具文件），第三方層（thrid_party，如果項(xiàng)目需要調(diào)用第三方模組，可以考慮定義第三方層）, 一個(gè)簡單但不完全的例子可以見土豆兩年前的小項(xiàng)目 [13]。通過代碼架構(gòu)的功能分離，可以將模型調(diào)優(yōu)的過程局限在超參數(shù)層中，盡量減少不同功能代碼的耦合。
• 合理類繼承： 對于一個(gè)可能會(huì)經(jīng)常迭代的復(fù)雜模塊而言（比如數(shù)據(jù)讀取器DataReader），將其進(jìn)行功能拆解，拆解成基類和子類，比如BaseDataReader將迭代過程中不會(huì)經(jīng)常變動(dòng)的共有功能（比如讀取文件，解析，令牌化，拼接等）進(jìn)行實(shí)現(xiàn)，通過子類繼承BaseDataReader實(shí)現(xiàn)更為定制化的數(shù)據(jù)讀取過程。這樣即可以在基類里面定義接口，又可以在子類里面定制特定實(shí)驗(yàn)需要的功能。相似的，在Model里面也可以分為BaseModel和子類model。

『過早的優(yōu)化是萬惡的根源』，在項(xiàng)目一開始不需要設(shè)計(jì)的非常細(xì)致，但是需要時(shí)刻關(guān)注整個(gè)項(xiàng)目的復(fù)雜度，一旦復(fù)雜度過高導(dǎo)致迭代困難，應(yīng)該及時(shí)考慮優(yōu)化。

在線調(diào)研

當(dāng)離線調(diào)研得到顯著正向結(jié)論后，就需要進(jìn)行在線調(diào)研了。在線調(diào)研指的是通過真實(shí)的用戶搜索行為，從最終返回的doc排序中對比策略和基線的優(yōu)劣。顯然在線調(diào)研是一個(gè)端到端的過程，包括你迭代的策略在內(nèi)，整個(gè)搜索系統(tǒng)的絕大部分現(xiàn)有策略都會(huì)參與，因此最終結(jié)果將會(huì)受到多方影響，這是典型的一個(gè)復(fù)雜系統(tǒng)。即便策略在離線調(diào)研中有著非常大的收益，進(jìn)入在線調(diào)研后結(jié)果持平甚至出現(xiàn)負(fù)向結(jié)論都是可能的，原因有多方面：

1. 離線調(diào)研采用的測試集無法描述在線數(shù)據(jù)分布，因此離線調(diào)研拿到的收益不置信，導(dǎo)致線上結(jié)果不盡人意。
2. 策略的收益被其他策略『吃掉』了，有可能你迭代的策略和現(xiàn)有的某個(gè)策略有重復(fù)的功能，一旦上線你的模型相當(dāng)于就被其他策略取代掉了。理論上，這種情況應(yīng)該在離線調(diào)研中能夠被發(fā)現(xiàn)，因?yàn)樵陔x線調(diào)研中通常還需要重新訓(xùn)練LTR模型，通過觀察LTR模型的特征權(quán)重變化可以判斷迭代策略的特征是否和其他特征功能上有所重合。
3. 特征覆蓋率問題，離線調(diào)研數(shù)據(jù)和線上數(shù)據(jù)的特征覆蓋率由于資源的原因，可能并不能完全對齊，特征覆蓋率的差別有可能導(dǎo)致離在線區(qū)別。
4. 策略可能在某些query下效果就是較差，比如一些長尾query，其召回的doc通常也會(huì)比較長尾，可能相關(guān)性模型對其的判斷能力就較弱。如果離線數(shù)據(jù)在采集過程中沒有對特定query進(jìn)行采集，有可能會(huì)導(dǎo)致這種區(qū)別。
5. 代碼bug，這一點(diǎn)也是經(jīng)常出現(xiàn)的，比如土豆就曾經(jīng)出現(xiàn)過不小心在線上代碼中將輸入提前截?cái)?，?dǎo)致某些case下離在線打分diff的情況… ???? 這一點(diǎn)可以認(rèn)為是需要對齊線上線下的數(shù)據(jù)處理，數(shù)據(jù)如果都沒對齊那么結(jié)論也是不置信的。
6. 離在線輸入數(shù)據(jù)的差別，這一點(diǎn)和5其實(shí)不太一樣，有可能線上建庫時(shí)候有特別的邏輯，導(dǎo)致線上源數(shù)據(jù)輸入和線下數(shù)據(jù)就是不一致的，比如線下可能是全角標(biāo)點(diǎn)符號，而建庫時(shí)候都被處理成了半角標(biāo)點(diǎn)符號 :- (

導(dǎo)致離在線結(jié)論差別的原因太多了，五花八門，其中很大程度上是因?yàn)檎麄€(gè)搜索系統(tǒng)太過于復(fù)雜，沒有人能了解其中所有策略的細(xì)節(jié)，可能在某個(gè)旮旯角就出現(xiàn)了預(yù)期外的情況。對其怎么解決，土豆暫時(shí)也沒有思路，只能平時(shí)盡量小心，盡量不要把低級bug引到在線調(diào)研中吧，希望在以后的工作中能總結(jié)出有用的結(jié)論出來。

困難度 （Complication）

然而系統(tǒng)并不是只有復(fù)雜度，而沒有困難度的，控制復(fù)雜度能保證系統(tǒng)的高效迭代，解決困難度能保證系統(tǒng)的領(lǐng)先性。對于數(shù)據(jù)這塊而言，個(gè)人感覺困難度集中在如何挑選合適的數(shù)據(jù)，這又可以分為幾個(gè)維度考慮：

• 如何挑選合適的訓(xùn)練數(shù)據(jù)。模型是否需要預(yù)訓(xùn)練？預(yù)訓(xùn)練數(shù)據(jù)應(yīng)該從哪里構(gòu)造，用戶行為數(shù)據(jù)中是否會(huì)存在預(yù)期外的偏置？采用有展現(xiàn)無點(diǎn)擊的數(shù)據(jù)作為負(fù)樣本是否合適 [15]，是否所有有點(diǎn)擊數(shù)據(jù)都能作為正樣本？ 是否需要從粗排數(shù)據(jù)中進(jìn)行隨機(jī)采樣？還是需要從精排數(shù)據(jù)中進(jìn)行采樣？用戶和用戶之間是否可能存在隱式關(guān)系，可以用于數(shù)據(jù)挖掘？ 是否需要數(shù)據(jù)標(biāo)注，如何標(biāo)注，標(biāo)準(zhǔn)是什么，如何篩選數(shù)據(jù)去送標(biāo)？這些都是問題。
• 如何挑選合適的測試集。離線調(diào)研中測試集用于評估策略對比基線的有效性，如果測試集無法正確描述在線數(shù)據(jù)情況，那么將會(huì)導(dǎo)致在線調(diào)研結(jié)論不符合預(yù)期。測試集的挑選同樣面臨著訓(xùn)練集相似的問題，在某些垂類細(xì)分問題上，如何正確的構(gòu)建測試集的正樣本和負(fù)樣本并不是一件容易的事情，有時(shí)候甚至問題都不容易定義，很容易導(dǎo)致離在線的diff。
• 數(shù)據(jù)需要提供什么信息量。數(shù)據(jù)需要提供什么信息直接影響模型應(yīng)該如何構(gòu)建和訓(xùn)練，對于相關(guān)性而言，可能構(gòu)建Query-Title相關(guān)，Query-Title-Content相關(guān)，Query-Content相關(guān)；對于質(zhì)量而言可能構(gòu)建Title-Content質(zhì)量性。如何結(jié)合資源挑選合適的數(shù)據(jù)輸入，如何把每個(gè)輸入信息單元精準(zhǔn)做好，也是一件困難的事情。

對于模型而言，需要探索一些在特定場景下有效的模型結(jié)構(gòu)和訓(xùn)練方式。比如在多模態(tài)檢索中，近年來大規(guī)?？缒B(tài)對比學(xué)習(xí)的興起，已經(jīng)證實(shí)了其在搜索應(yīng)用中的有效性[15,16,17]，一些新的基于memory bank和momentum更新的方法使得對比學(xué)習(xí)的規(guī)模愈來愈大[15,18,19]。這些對模型的改進(jìn)，或者模型訓(xùn)練方式的改進(jìn)，一旦在應(yīng)用中落地，就有可能拿到巨大的收益。

總結(jié)

雖然感覺已經(jīng)寫了蠻多了，也不知道對諸位讀者有沒有幫助，其實(shí)在工作中還遇到很多『復(fù)雜度』的內(nèi)容，比如流程性的東西，代碼的準(zhǔn)入，測試，上線規(guī)范，資源申請，諸多內(nèi)部工具的使用（百度的基建很完善，有很多內(nèi)部工具給策略同學(xué)提供了便利）等等，然而這些東西更多的是『繁瑣』，有時(shí)候也會(huì)在這些流程中踩坑，但是寫出來一是可能違規(guī)，二是可能對大家也沒幫助，因此也就不提了。希望后續(xù)還能對這個(gè)系列進(jìn)行更新，分享一些工作中學(xué)習(xí)到的知識。

Reference

[1]. https://blog.csdn.net/LoseInVain/article/details/105545703

[2]. https://blog.csdn.net/LoseInVain/article/details/108212429

[3]. https://blog.csdn.net/LoseInVain/article/details/107265821

[4]. https://blog.csdn.net/LoseInVain/article/details/107720442

[5]. https://blog.csdn.net/LoseInVain/article/details/108322781

[6]. https://blog.csdn.net/LoseInVain/article/details/108710063

[7]. Liu, Yiding, Weixue Lu, Suqi Cheng, Daiting Shi, Shuaiqiang Wang, Zhicong Cheng, and Dawei Yin. “Pre-trained language model for web-scale retrieval in baidu search.” In Proceedings of the 27th ACM SIGKDD Conference on Knowledge Discovery & Data Mining, pp. 3365-3375. 2021.

[8]. Fan, Yixing, Xiaohui Xie, Yinqiong Cai, Jia Chen, Xinyu Ma, Xiangsheng Li, Ruqing Zhang, Jiafeng Guo, and Yiqun Liu. “Pre-training Methods in Information Retrieval.” arXiv preprint arXiv:2111.13853 (2021).

[9]. https://blog.csdn.net/LoseInVain/article/details/120272575

[10]. Sun, Yu, Shuohuan Wang, Yukun Li, Shikun Feng, Xuyi Chen, Han Zhang, Xin Tian, Danxiang Zhu, Hao Tian, and Hua Wu. “Ernie: Enhanced representation through knowledge integration.” arXiv preprint arXiv:1904.09223 (2019).

[11]. https://blog.csdn.net/LoseInVain/article/details/113859683

[12]. https://juejin.cn/post/6844903606815064077

[13]. https://github.com/FesianXu/LipNet_ChineseWordsClassification

[14]. https://blog.csdn.net/LoseInVain/article/details/113706168

[15]. https://blog.csdn.net/LoseInVain/article/details/120364242

[16]. https://blog.csdn.net/LoseInVain/article/details/122735603

[17]. https://blog.csdn.net/LoseInVain/article/details/121699533

[18]. https://fesian.blog.csdn.net/article/details/119515146

[19]. https://fesian.blog.csdn.net/article/details/119516894