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終榜及開源地址
▲圖2。 KDD Cup 2019 AutoML Track Blind Test Phase排行榜
▲ 圖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 型別。
# 識別user 與 session
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
，
］
特徵工程部分往往是資料探勘競賽的關鍵核心內容，也是我們團隊在競賽中取得顯著優勢的重要因素。我們透過 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，允許精度上的損失來保證程式碼能夠在規定時間內執行完畢。
如時間充裕，則通過當前剩餘時間計算允許多少個模型進行融合。為了保證程式碼透過，我們採用了保守估計的方式，即在計算出模型融合數量的基礎上，選擇少融合一個模型。
start_time
=
time
。
time
（）
temp
=
X
。
iloc
［：
100000
］
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。 記憶體最佳化前後對比
系統測試
對於系統的測試，我們分為了兩個方面進行。第一個方面是測試系統的擴充套件性，第二個方面是測試系統的效能。
對於系統的擴充套件性，我們測試過如下：
對於不同的資料型別缺失的情況；
對於不同資料型別數值全為空的情況；
對於表的結構為單表、複雜多表的情況。
以及其他一系列的極限狀態。
而對於系統的效能方面，我們測試過如下：
擴大資料的條目，就本次競賽的 5 個數據集而言，我們擴充套件每個資料集資料條目 2 倍，3 倍，6 倍都能夠在規定的時間和記憶體下順利執行。
擴大資料的欄位數量，同樣，我們擴充套件 5 個數據集的欄位數量 2 倍也能夠順利執行。
構造特定的資料集，觀察是否會因為某些組合特徵而系統崩潰。最後測試了大約數十個構造的極端資料集都能夠執行成功。
限制資料集允許執行時間，我們透過調整資料集允許執行時間，觀察我們的系統是否能夠自適應調整自身的執行時間。我們調整本次競賽中原本時間就比較緊張的 A 資料集以及資料量較大的 B 資料集，將其允許的執行時間變為原來的 1/2，1/3，甚至是 1/4。我們的系統都能夠順利執行。
總結
本次 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 一篇，多年機器學習實戰經驗。
開源連結
#投 稿 通 道#
如何才能讓更多的優質內容以更短路徑到達讀者群體，縮短讀者尋找優質內容的成本呢？
答案就是：你不認識的人。
總有一些你不認識的人，知道你想知道的東西。PaperWeekly 或許可以成為一座橋樑，促使不同背景、不同方向的學者和學術靈感相互碰撞，迸發出更多的可能性。
PaperWeekly 鼓勵高校實驗室或個人，在我們的平臺上分享各類優質內容，可以是
最新論文解讀
，也可以是
學習心得
或
技術乾貨
。我們的目的只有一個，讓知識真正流動起來。
來稿標準：
• 稿件確係個人
原創作品
，來稿需註明作者個人資訊（姓名+學校/工作單位+學歷/職位+研究方向）
• 如果文章並非首發，請在投稿時提醒並附上所有已釋出連結
• PaperWeekly 預設每篇文章都是首發，均會新增“原創”標誌
投稿方式：
• 方法一：在PaperWeekly知乎專欄頁面點選“投稿”，即可遞交文章
• 方法二：傳送郵件至：
hr@paperweekly。site
，所有文章配圖，請單獨在附件中傳送
• 請留下即時聯絡方式（微信或手機），以便我們在編輯釋出時和作者溝通
關於PaperWeekly
PaperWeekly 是一個推薦、解讀、討論、報道人工智慧前沿論文成果的學術平臺。如果你研究或從事 AI 領域，歡迎在公眾號後臺點選
「交流群」
，小助手將把你帶入 PaperWeekly 的交流群裡。
加入社群：
http：//paperweek。ly
微信公眾號：PaperWeekly
新浪微博：@PaperWeekly
