KDD Cup 2019 AutoML Track冠军深兰科技DeepBlueAI团队技术分享 | 开源代码
作者丨羅志鵬
單位丨深蘭北京AI研發中心
近日，KDD Cup 2019 AutoML Track 比賽結果出爐，本次賽題是第五次 AutoML 挑戰賽，由第四范式、ChaLearn 和微軟聯合舉辦，專注于時序相關數據的自動機器學習。
這次競賽注冊隊伍達到近 800 支，是近幾次 AutoML 競賽中參賽隊伍最多的一次。由來自深蘭科技北京 AI 研發中心的 DeepBlueAI 團隊斬獲冠軍，團隊成員均畢業或就讀于北大。新加坡國立大學的 NUS-Xtra-Lab 團隊獲得第二名，阿里巴巴集團和佐治亞理工學院組成的 admin 團隊則獲得第三名。排名前十的隊伍中還包括清華大學、南京大學、微軟亞洲研究院、海康威視、美團點評等高校或機構。
本文帶來該團隊在競賽中技術細節分享，文末附開源代碼 Github 鏈接。
背景介紹
ACM SIGKDD 由美國計算機協會數據挖掘與知識專業委員會發起，是數據挖掘領域公認的具有最高學術地位的國際性學術會議。KDD Cup 是由 ACM 的數據挖掘及知識發現專委會（SIGKDD）主辦的數據挖掘研究領域的國際頂級賽事，從 1997 年至今已有 22 年的歷史。
作為目前數據挖掘領域最有影響力、最高水平的國際頂級賽事，KDD Cup 每年都會吸引來自世界各地數據挖掘領域的頂尖專家、學者和工程師參賽，因此也有“大數據奧運會”之名。今年， 第 25 屆 ACM SIGKDD 會議于 2019 年 8 月 4 日至 8 日在美國阿拉斯加舉行。
團隊成績
在 KDD Cup 2019 AutoML Track 當中，DeepBlueAI 團隊在 Feed-back 階段以 4 項第一，1 項第二平均成績排名第一；AutoML 階段以 3 項第一，平均指標領先第二名 0.3 的成績以絕對優勢獲得冠軍，具體排名如下：
▲?圖1.?KDD Cup 2019 AutoML Track終榜及開源地址
?
▲?圖3.?KDD Cup 2019 AutoML Track Feed-back Phase排行榜
?
團隊成員獲獎記錄
賽題介紹
參賽者將利用時序關系數據，設計一個能夠自主（無人為干預）實現監督學習的AutoML計算機程序。該比賽聚焦在二分類問題，且時序關系數據均來自實際業務場景。根據大多數實際應用的時間屬性，數據集按時間順序劃分為訓練集和測試集。訓練集和測試集都由一個主表、一組相關表和一個關系圖組成：?
參賽者需要提交通過主表、相關表和關系圖自動構建機器學習模型的 AutoML 方案。一旦經過訓練，模型將以測試主表（不包括樣本標記）、相關表和關系圖作為輸入，并預測測試集的樣本標記。參賽者提交的方案將在受限制的計算資源和時間內進行測試。?
為了讓參賽者能夠更好的開發并評估方案，主辦方提供了 10 個時序關系數據集，其中 5 個公共數據集，5 個私有數據集。
比賽階段
Feedback 階段?
即反饋階段。在此階段，參賽者可以在五個公共數據集上進行訓練，開發 AutoML 方案。參賽者可以進行有限數量的提交，并獲得作為反饋的所有五個公共數據集的測試數據的性能。參賽者可以下載有標記的訓練數據集和未標記的測試數據集。因此，參賽者可以在線下準備他們的代碼并提交。該階段最后的代碼提交將最終作為下一階段進行盲測的代碼。?
Check 階段?
即校驗階段。該階段將在五個私有數據集上對第一階段的最后一次提交的代碼進行盲測，確保提交的方案順利運行，不會出現例如超時或者內存溢出等問題，但參賽者無法看到具體的結果，所有參賽隊伍具備一次更新代碼的機會，以保證在最終階段正確的運行自己的代碼。?
AutoML 階段?
即盲試階段。該階段將測試方案在私有數據集上的性能。參賽者的代碼將在無需人為干預情況下完成訓練和預測。AUC 作為評價指標，最終將根據五個私有數據集的平均排名進行評分。若最終比分相同，則優先考慮可解釋性更好的方案，可解釋性將由專家團隊評審。
以上三個階段的計算及內存資源均有所限制，因此方案應兼顧效果及效率。
競賽時間
2019 年 4 月 1 日：比賽開始，發布公共數據集。參與者可以開始提交代碼并在排行榜上獲得即時反饋信息。?
2019 年 6 月 27 日：Feedback 階段結束，Feedback 階段的代碼自動遷移到 Test 階段。?
2019 年 7 月 7 日：Check 階段結束，主辦方開始代碼驗證。?
2019 年 7 月 11 日：提交報告的截止日期。?
2019 年 7 月 16 日：AutoML 階段結束，開始評審流程。?
2019 年 7 月 20 日：宣布 KDD Cup 冠軍。?
2019 年 8 月 4 日：在 KDD 上舉辦頒獎儀式。
評測指標
本次比賽采用 AUC 作為評分指標，排名規則以官方給出的 baseline 得分 auc_base 為 0 分基準，以所有選手最高成績 auc_max 為滿分 1 分基準，按照公式得出相對分數，最后算出 5 個數據集的平均分為最終得分，得分越高代表模型性能越好。得分計算公式如下：
題目特點
在這次比賽中，主要有以下難點：
1. 挖掘有效的特征
與傳統數據挖掘競賽不同的是，AutoML 競賽中，參賽選手只知道數據的類型（數值變量、分類變量、時間變量、多值分類變量等），而不知道數據的含義，這毫無疑問會增加特征工程的難度，如何挖掘到有效的通用特征成為一個難點。
2. 賽題數據和時序相關
時序相關數據的數據挖掘難度較大，在傳統的機器學習應用中，需要經驗豐富的專家才能從時序關系型數據中挖掘出有效的時序信息，并加以利用提升機器學習模型的效果。即使具備較深的知識儲備，專家也需要通過不斷的嘗試和試錯，才能構建出有價值的時序特征，并且利用好多個相關聯表來提升機器學習模型的性能。
3. 賽題數據按照多表給出
賽題的數據是按照多表給出的，這就要求參賽選手能夠構建一個處理多表之間多樣的連接關系的自動化機器學習系統。多表數據無疑提升了對系統的穩定性的要求，稍有不慎，有可能合并出來的數據過于龐大就直接超時或者超內存而導致沒有最終成績。
4. 時間內存限制嚴格
比賽代碼運行環境是一個 4 核 CPU，16G 內存的 docker 環境，對于未知大小的數據集，在代碼執行過程中的某些操作很容易使得內存峰值超過 16G，導致程序崩潰。因此選手要嚴格優化某些操作，或使用采樣等方式完成任務。此外，比賽方對于每個數據集嚴格限制了代碼的執行時間，稍有不慎就會使得運行時間超時而崩潰。
解決方案
我們團隊基于所給數據實現了一套支持多表的 AutoML 框架，包括自動多表合并、自動特征工程、自動特征選擇、自動模型調參、自動模型融合等步驟，在時間和內存的控制上我們也做了很多優化工作。
數據預處理
我們通過對表結構及其屬性的分析，針對不同類型的數據制定不同的數據預處理方案。首先，在多表間的多個連接 key 中，我們在主表中種類最多的一個 key 識別為 user。基于識別出的 user，可以嘗試在主表的 category 中識別出 session。
另外，我們嘗試在 category 數據中識別出只有兩類有效值的 binary 數據。我們對 category、user、session、key 進行重新編碼，對 numerical 數據嘗試將其轉換為占用內存更少的類型，將 time 數據轉換為容易操作的 datetime 類型。
def?recognize_user_col(self,data,key_cols):
????user_col?=?None
????nunique?=?-1
????for?col?in?key_cols:
????????nnum?=?data[col].nunique()
????????if?nnum?>?nunique:
????????????user_col?=?col
????????????nunique?=?nnum
????return?user_col
def?recognize_session_col(self,data,cat_cols,user_col):
????if?user_col?is?None:
????????return?[]
????user_nunique?=?data[user_col].nunique()
????session_cols?=?[]
????def?func(df,user_nunique):
????????cat_col?=?df.columns[0]
????????user_col?=?df.columns[1]
????????cat_nunique?=?df[cat_col].nunique()
????????if?(cat_nunique?<=?user_nunique)?or?(cat_nunique?>=?df.shape[0]-10):
????????????return?False
????????if?(df.groupby(cat_col)[user_col].nunique()>1).sum()>10:
????????????return?False
????????return?True
????res?=?Parallel(n_jobs=CONSTANT.JOBS,require='sharedmem')(delayed(func)(data[[col,user_col]],user_nunique)?for?col?in?cat_cols)
????for?col,is_session?in?zip(cat_cols,res):
????????if?is_session:
????????????session_cols.append(col)
????return?session_cols
多表連接
比賽給的數據結構如上圖所示，表和表之間的連接關系可以分為四種，分別是 1-1、1-M、M-1、M-M。因為時間和內存的限制，所以我們需要在盡可能保留信息的同時，讓最后生成的表的數據規模不至于過大。而處理多表連接的方式，直接影響到后面的結果。我們針對不同的連接方式采用了不同的方法。
首先將四種連接方式分成了兩種類型：類型 1 包含了 1-1、M-1，類型 2 包含了 1-M、M-M。對于類型 1，我們可以直接將副表的數據通過 key 合并到主表上。對于類型 2，我們首先對副表做一些聚集操作，生成聚集的結果，而這些聚集的結果可以理解為和主表是類型1的關系。
接下來，我們只要對生成聚集的結果做類型 1 的操作，直接將其合并到主表上即可。并且，對于主表和副表都有時間戳的情況下，我們為了盡可能保留信息，將副表上離主表當前數據早且最近并且為相同 key 值的數據合并到主表上。
其具體操作可以見圖示，key 為 147714011 的數據項的 n_1 列的數據為 3.6，連接到 Main Table 對應的 147714011 的所有數據項之上。
該圖表示了類型 2 的連接方式，這個例子為對 n_1 列做了均值聚集操作，key 為 147714011 的數據項在 n_1 列上的均值為 2.3，之后就是將該數據對應合并到主表上。
采樣
因為 AutoML 比賽方給定的數據集大小未知，在對其進行操作處理之前首先要判斷當前環境是否能夠支持整個數據集共同參與特征工程及模型訓練過程。我們在讀入數據進入預處理之前做了一次判斷，即要求訓練集與測試集的總樣本數不超過某一個可以接受的閾值。如訓練集與測試集的總樣本數過多，我們就考慮對其進行采樣，在當前給定的 16G 內存的條件下，我們經過估算，得到 400 萬條數據是一個比較好的閾值。
此外，在特征工程的組合特征模塊中，同樣用到了采樣的思想。組合特征的特點是產生的特征數量多，特征工程的時間長，內存峰值高，起作用的特征數量少。因此，為了避免內存溢出，我們在做組合特征之前，在小數據集上進行特征工程，經過篩選后得到真正有效的特征，再在整個數據集上僅做出這些有效的特征這樣不僅可以減少系統運行時間也能避免爆內存的風險。
自動特征工程
def?main_init(self):????self.order1s?=?[????????????????PreMcToNumpy,McCatRank,????????????????OriginSession,????????????????ApartCatRecognize,\????????????????KeysCountDIY,UserKeyCntDIY,SessionKeyCntDIY,\????????????????KeysTimeDiffAndFuture,????????????????KeysNuniqueDIY,?KeysCntDivNuniqueDIY,????????????????KeysCumCntRateAndReverse,UserKeyCumCntRateAndReverse,????????????????KeyTimeDate,KeyTimeBin,KeysBinCntDIY,????????????????CatCountDIY,????????????????LGBFeatureSelection,????????????]????self.keys_order2s?=?[????????????????KeysNumMeanOrder2MinusSelfNew,????????????????KeysNumMaxMinOrder2MinusSelfNew,????????????????KeysNumStd,????????????????KeysCatCntOrder2New,????????????????LGBFeatureSelectionWait,????????????]????????self.all_order2s?=?[????????????????BinsCatCntOrder2DIYNew,????????????????BinsNumMeanOrder2DIYNew,????????????????CatNumMeanOrder2DIYNew,????????????????CatCntOrder2DIYNew,????????????????LGBFeatureSelectionWait????????????]????????self.post_order1s?=?[????????????????TimeNum,????????????]????????self.merge_order1s?=?[????????????????CatSegCtrOrigin,????????????????CatMeanEncoding,????????????????LGBFeatureSelectionLast,????????????]
????self.order1s?=?[
????????????????PreMcToNumpy,McCatRank,
????????????????OriginSession,
????????????????ApartCatRecognize,\
????????????????KeysCountDIY,UserKeyCntDIY,SessionKeyCntDIY,\
????????????????KeysTimeDiffAndFuture,
????????????????KeysNuniqueDIY,?KeysCntDivNuniqueDIY,
????????????????KeysCumCntRateAndReverse,UserKeyCumCntRateAndReverse,
????????????????KeyTimeDate,KeyTimeBin,KeysBinCntDIY,
????????????????CatCountDIY,
????????????????LGBFeatureSelection,
????????????]
????self.keys_order2s?=?[
????????????????KeysNumMeanOrder2MinusSelfNew,
????????????????KeysNumMaxMinOrder2MinusSelfNew,
????????????????KeysNumStd,
????????????????KeysCatCntOrder2New,
????????????????LGBFeatureSelectionWait,
????????????]
????????self.all_order2s?=?[
????????????????BinsCatCntOrder2DIYNew,
????????????????BinsNumMeanOrder2DIYNew,
????????????????CatNumMeanOrder2DIYNew,
????????????????CatCntOrder2DIYNew,
????????????????LGBFeatureSelectionWait
????????????]
????????self.post_order1s?=?[
????????????????TimeNum,
????????????]
????????self.merge_order1s?=?[
????????????????CatSegCtrOrigin,
????????????????CatMeanEncoding,
????????????????LGBFeatureSelectionLast,
????????????]
特征工程部分往往是數據挖掘競賽的關鍵核心內容，也是我們團隊在競賽中取得顯著優勢的重要因素。我們通過 LightGBM 模型來驗證特征效果。我們將特征工程分成幾個模塊。
第一個模塊是基礎特征部分，這一部分主要是針對 user、key、session 的統計特征，產生新特征的數目較少卻有很好的效果，因此放在最先。
第二模塊是一階組合特征部分，我們嘗試將主表中較為重要的 user、key、session 與其余的 numerical 或 categorical 挑選出的數據進行組合，對某些數據集有非常好的效果。
第三個是大量組合特征部分，我們對時間分桶，嘗試使用時間桶對 categorical 和 numerical 數據進行組合，此外我們還根據不同數據集的數據量大小，篩選出適量的 categorical 或 numerical 數據兩兩組合形成新的特征，在希望挖掘到有用的特征的同時，盡量減小內存溢出的風險。
最后的部分是有監督學習的 CTR 和均值編碼特征，將其放在最后的原因是一方面在這一階段會產生很多特征，容易造成生成過多的特征而導致爆內存；另一方面是我們認為這些特征和其他特征組合沒有什么實際意義，因此將其放在最后不參與組合。
同時，因為本次競賽的時間和內存的控制比較嚴格，在面對百萬級的數據量上，每個特征生成幾乎都要控制在幾秒內生成，為了滿足這一要求，我們的代碼加入了許多優化。比如對于類別數據在多類別數據中的位置這一特征，如果用傳統的 Pandas 實現，時間會達到幾個小時，而加入多線程之后，情況會有所改善，但是仍舊要消耗大量的時間。
我們退而求其次，使用 numpy 來實現該特征，特征的生成時間直接到達了幾十秒的級別，但是這仍舊不能滿足我們的要求。最后我們對這塊代碼使用 cython 去優化，并且對 cython 代碼進行精雕細琢，最后該特征的生成只需要幾秒。
▲?圖4.?經過篩選后較為重要的特征
?自動特征選擇
?在自動特征工程階段，我們將特征工程分為多個階段。在每一個模塊結束后，我們都會做一次特征選擇來篩掉那些在這一階段做出的無效的特征，來避免內存溢出并且加速最終的模型訓練。
我們通過結合特征重要性及序列后向選擇算法，設置一個閾值，將在參與模型訓練中，篩出重要性較低的特征而盡可能小地損失模型精度。我們還嘗試了基于特征的信息增益來對特征進行篩選，亦或是對兩種篩選方法進行結合，但因為沒能找到更好的切分點，最終還是使用了基于特征重要性的方法。
▲?圖5.?特征選擇機制
類別不平衡問題處理
我們對類別不平衡的數據在訓練時做了處理。正負樣本比例超過 1:3 時，我們采用欠采樣的方式，緩和正負樣本不平衡。此外，我們還嘗試通過增加正樣本的權重等方式來優化類別不平衡帶來的問題。在模型融合的部分，我們在保留原始較少的正樣本的同時，換一批負樣本來進行訓練，這樣能夠盡可能保留更多的原始數據的信息，同時緩解類別不平衡的問題。
模型融合
由于比賽環境對時間和內存做了嚴格的限制，我們在模型融合方面考慮了 bagging、blending、stacking 等方案，最終選用了使用 bagging 的方法。我們通過計算一個 demo 模擬真實數據集訓練和預測來預估真實數據集所需要的時間，如時間不足則選擇在訓練時 early-stop，允許精度上的損失來保證代碼能夠在規定時間內運行完畢。
如時間充裕，則通過當前剩余時間計算允許多少個模型進行融合。為了保證代碼通過，我們采用了保守估計的方式，即在計算出模型融合數量的基礎上，選擇少融合一個模型。
temp?=?temp.astype(np.float32)
gc.collect()
temp?=?temp.values
gc.collect()
model.predict(temp)
end_time?=?time.time()
model_test_use_time?=?(end_time-start_time)
#?估算預測10萬條數據所需的時間
model_test_use_time?=?len_test/temp.shape[0]?*?model_test_use_time
#?得到預測測試集數據所需的時間
model_use_time?=?model_use_time?+?model_test_use_time
#?總時間?=?訓練時間?+?測試時間
del?temp,model
rest_time?=?config.budget/10*9-(end_time-config.start_time)
#?使用給定時間的90%做保守估計，計算剩余可用時間
if?rest_time?<=?0:
????rest_model_num?=?0
else:
????rest_model_num?=?int(rest_time?/?model_use_time)
if?rest_model_num?>=?50:
????rest_model_num?=?50?
if?rest_model_num?>=?1:
????rest_model_num?-=?1
#?根據剩余時間計算出可融合模型的數量，在此基礎上少融合一個模型
運行時間優化
我們的時間控制在各個過程中都有體現。?
在自動化數據處理和自動化特征工程的過程中，我們使用 Cython 對編碼以及一些生成效率較慢的特征進行加速。這里舉一個特征為例，對于兩列數據，一列為 category 類型的數據，一列為 multi-category 類型的數據，我們提前判斷了兩列數據的數據項集具有交集，我們要計算這一 category 列中的數據項在 multi-category 列對應的數據項集中的位置信息。
比如說有有一條數據。data : [ 2137 , (134,2137,576,816) ] ，前者 2137 在后者的第 2 個位置上。所以這條數據該特征為 2。如果沒有出現的話，規定為 0。對于這一特征，如果我們使用 pandas 提供的 apply 接口來實現，在本次競賽的環境下，該類特征的生成需要大約幾個小時的時間。
考慮到 DataFrame 不適合做遍歷，以及接口泛化性帶來的性能上的損失。我們使用 Numpy，做遍歷來實現該特征，能夠讓特征的生成達到分鐘級。而本次競賽的時間和內存有嚴格的控制，像那些需要超過 10 秒才能生成的一類特征就算非常耗時的了。
之后我們采用 Cython，應用 Cython 提前編譯，靜態類型等機制我們將該特征的生成時間控制在了 10 秒內。其中生成該特征的過程中有一些細節。比如如果在 Cython 中繼續使用 Python 原生類型，那么遍歷的效率還是比較緩慢。但是 multi-category 類型的數據存儲又不好離開 Python 原生類型的支持。
考慮我們在生成特征的過程中，主要是對 multi-category 類型做遍歷操作，所以可以使用一個數組去存儲 multi-category 的每個數據項。并且用額外一個數組去保存每個 multi-category 的數據項集的長度。這樣根據其長度數組和數據數組，我們就能做一個高效的遍歷。
在測試這段優化的過程中，純粹的 Python 代碼經過 Cython 優化，效率大概能到 60 秒。而經過這段優化，很輕松就能到達 10 秒內（測試環境就是以我們的本次計算機為主，線上環境會多一些時間）。?
在模型集成部分，我們會做提前計算，記錄到當前用時，通過訓練模型幾個輪次來計算出模型啟動的時間以及模型訓練每一輪數據所消耗的時間，通過這兩個時間，我們能夠預估出后續的參數調優，模型訓練的時間。從而決定最后模型融合的數量。
▲?時間優化前后對比
運行內存優化
在內存控制方面，我們首先實現了一個內存的監聽器。我們首先完整運行一輪我們的系統，記錄下內存情況，對不同數據集的內存峰值進行分析。可以發現的是，內存峰值往往就出現在幾個典型的地方。比如：數據合成時、在模型開始訓練時、某些特征生成時。
經過分析，可以概括為幾個點，其中比較典型的是數據合成時，如果使用 pandas 的接口 pandas.concat 進行數據合并，其合并過程中，會生成大約兩倍當前數據內存的量。這個是顯然的，因為其合并返回的結果不是就地的，而是創建出第三塊內存。因此，我們將合成的過程改為按列賦值，這樣合并時就幾乎不存在內存峰值了。但是這么做，同時會帶來較差的時間效率。所以在系統的早期，內存比較寬松的情況下，我們仍舊采用 pandas 的接口來進行對數據的合并。
另外，我們同樣對訓練預測時內存的情況進行了提前計算，在最后的特征篩選的過程中，我們會計算模擬出在生成多大的數據量下，能夠完整進行系統后續的過程。從而來控制最后篩選出來的數據量。并且在最后一次特征篩選前，生成特征時，我們也會先時候小數據集進行一個模擬過程，來計算出整個過程中的內存情況，來對生成期生成的特征數量進行一個控制。
最后，我們會做一些比較精細的內存管理，在變量生命周期結束的時候，我們都會對其進行內存回收。以下是我們內存優化前后的一個對比。里面包含了比賽中給的 5 個數據集的運行過程中的內存情況。
▲?圖6.?內存優化前后對比
?系統測試
對于系統的測試，我們分為了兩個方面進行。第一個方面是測試系統的擴展性，第二個方面是測試系統的性能。?
對于系統的擴展性，我們測試過如下：?
以及其他一系列的極限狀態。
而對于系統的性能方面，我們測試過如下：?
總結
本次 KDD Cup AutoML 競賽在賽制上得到進一步完善。相對于 NeurIPS 2018 AutoML 競賽增加了一次 AutoML 階段的提交次數，這樣能夠盡量保障參賽選手順利跑通 B 榜數據。相對于 PAKDD 2019 AutoML 競賽改進評分機制，最終得分只受各任務最高分的影響。完善后的競賽機制讓參賽選手得到更好的競賽體驗和技術發揮，感謝主辦方的辛勤付出。?
在這次競賽中我們的工作圍繞著競賽的挑戰而進行，主要有幾個比較重要的過程：自動化多表數據處理、自動多表連接、自動化特征工程、自動化模型構建、選擇和融合。同時為了滿足競賽的時間和內存的需求，我們在代碼上做了相當多的優化，比如使用了多線程、Cython、預處理、提前估算等方法。最后我們的成績相當不錯，A，B 榜單上均在多個任務集上有比較大的優勢。?
時序關系型數據在在線廣告、推薦系統、金融市場分析等應用場景中十分常見。本次 AutoML 聚焦時序關系型數據，為參賽者提出了挑戰，同時也為 AutoML 的發展提供了新的思路。近年來 AutoML 因為其高適應性、高效性、可擴展性、高可用性，在工業應用中可以大大降低應用門檻，在不同的場景中均可以發揮出用武之地，大大縮短項目開發周期。最后祝賀所有的 Top 隊伍，愿大家在未來都能取得自己滿意的成績！
作者介紹
羅志鵬，深蘭北京 AI 研發中心負責人，深蘭科技機器學習科學家。
碩士畢業于北大，獲得過 PAKDD，KDD，NeurIPS，CIKM，CVPR，SIGIR 等頂級會議競賽冠軍，以一作發表 KDD Oral 一篇，共同一作 WWW 一篇，多年機器學習實戰經驗。
開源鏈接
https://github.com/DeepBlueAI/AutoSmart
點擊以下標題查看更多往期內容：?
圖神經網絡綜述：模型與應用
ACL 2019 | 基于知識增強的語言表示模型
ACL 2019 | 基于上下文感知的向量優化
基于小樣本學習的意圖識別冷啟動
復旦大學邱錫鵬：詞法、句法分析研究進展綜述
ACL 2019?| 句對匹配的樣本選擇偏差與去偏方法
深度長文：NLP的巨人肩膀（上）
NLP 的巨人肩膀（下）：從 CoVe 到 BERT
#投 稿 通 道#
?讓你的論文被更多人看到?
如何才能讓更多的優質內容以更短路徑到達讀者群體，縮短讀者尋找優質內容的成本呢？答案就是：你不認識的人。
總有一些你不認識的人，知道你想知道的東西。PaperWeekly 或許可以成為一座橋梁，促使不同背景、不同方向的學者和學術靈感相互碰撞，迸發出更多的可能性。
PaperWeekly 鼓勵高校實驗室或個人，在我們的平臺上分享各類優質內容，可以是最新論文解讀，也可以是學習心得或技術干貨。我們的目的只有一個，讓知識真正流動起來。
??來稿標準：
? 稿件確系個人原創作品，來稿需注明作者個人信息（姓名+學校/工作單位+學歷/職位+研究方向）?
? 如果文章并非首發，請在投稿時提醒并附上所有已發布鏈接?
? PaperWeekly 默認每篇文章都是首發，均會添加“原創”標志
? 投稿郵箱：
? 投稿郵箱：hr@paperweekly.site?
? 所有文章配圖，請單獨在附件中發送?
? 請留下即時聯系方式（微信或手機），以便我們在編輯發布時和作者溝通
?
現在，在「知乎」也能找到我們了
進入知乎首頁搜索「PaperWeekly」
點擊「關注」訂閱我們的專欄吧
關于PaperWeekly
PaperWeekly 是一個推薦、解讀、討論、報道人工智能前沿論文成果的學術平臺。如果你研究或從事 AI 領域，歡迎在公眾號后臺點擊「交流群」，小助手將把你帶入 PaperWeekly 的交流群里。
▽ 點擊 |?閱讀原文?| 獲取最新論文推薦
總結
以上是生活随笔為你收集整理的KDD Cup 2019 AutoML Track冠军深兰科技DeepBlueAI团队技术分享 | 开源代码的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 文末福利 | 国际前沿算法峰会报名进行中
- 下一篇： 解读小米MoGA：超过MobileNet