使用這些基本 REST API 最佳實踐構建出色的 API
AI Value by Data Types
下圖是 Google 內部的各種時序預測的場景，看起來是不是應用范圍一點也不亞于搜廣推呢 ??
Forecasting at Google
在很多研究中，會把時間序列進一步區分成單變量時間序列和多變量時間序列。例如單支股票的價格走勢是一個單變量時序問題，但某支股票的價格波動除了自身因素，也會受到其它股票價格波動的影響，甚至是股票市場外的一些其它信息影響，所以我們需要通盤考慮來做預測，就形成了所謂的多變量時間序列問題。
簡單來設想，我們只要把輸入和輸出的維度從一維變到高維就能處理多變量的時序問題了。但實際問題中，情況往往更為復雜。例如股票市場中可能會有新股上市，也可能會有退市，這個多維本身可能也會有數量的波動。如果考慮所有曾經出現過的股票信息，那么維度可能就會很高，但序列本身長度卻相對受到局限，不像 NLP 場景中有海量的序列數據可以做各種數據增強，自監督學習，遷移學習的玩法，一般很難達到比較好的預測效果。
因此，業界在實際做時序問題時，通常采用的手段還是對每一個序列來做訓練學習（但不一定是單獨模型），把相關的動態，靜態信息通過特征的方式輸入到模型中。比如股票代碼就不再是維度上的區別，而是做成一個類別變量，輸入到模型中進行訓練。這也是目前較為主流的問題形式和對應的實踐方式，后面我們會再展開詳述。
在介紹具體預測方法之前，我們先來看下如何檢驗時序預測的效果。
在指標方面，作為一個回歸問題，我們可以使用 MAE，MSE 等方式來計算。但這類 metric 受到具體預測數值區間范圍不同，展現出來的具體誤差值區間也會波動很大。比如預測銷量可能是幾萬到百萬，而預測車流量可能是幾十到幾百的范圍，那么這兩者預測問題的 MAE 可能就差距很大，我們很難做多個任務間的橫向比較。
所以實際問題中，我們經常會使用對數值量綱不敏感的一些 metric，尤其是 SMAPE 和 WMAPE 這兩種：
這類誤差計算方法在各類不同的問題上都會落在 0~1 的區間范圍內，方便我們來進行跨序列的橫向比較，十分方便。
在實際項目中我們還會經常發現，很多真實世界的時序預測目標，如銷量，客流等，都會形成一個類似 tweedie 或 poisson 分布的情況。如果我們用 WMAPE 作為指標，模型優化目標基本可以等價為 MAE（優化目標為中位數），則整體的預測就會比平均值小（偏保守）。在很多業務問題中，預測偏少跟預測偏多造成的影響是不同的，所以實際在做優化時，我們可能還會考察整體的預測偏差（總量偏大或偏小），進而使用一些非對稱 loss 來進行具體的優化。
我們在一開始接觸機器學習的交叉驗證概念時，教科書上一般都是對數據做隨機的 split。不過在時序問題上，需要特別注意不能做隨機 split，而需要在時間維度上做前后的 split，以保證與實際預測應用時的情況一致。比如用 1-6 月的數據做訓練，在 7 月數據上做驗證，用 2-7 月的數據做訓練，在 8 月數據上做驗證，以此類推。
后面在介紹機器學習方法時，我們也會再次提到類似的思想，即使用一段時間窗口的歷史數據作為模型輸入，對未來的一個時間窗口做預測輸出和效果驗證。這是時序問題中極為重要的一點。
時序問題整體來說是個難度很大的問題，縱觀 Kaggle 相關比賽，能夠穩定在時序問題上拿金的大佬幾乎沒有，但其它像 CV，分類等問題上排名靠前的 GM，熟悉的名字比例明顯就會高很多。這其中很大一部分原因來自于真實世界中的時序問題基本都是不符合 i.i.d 假設的，世界變幻莫測，如果我們能準確預知未來，那還做什么算法工程師 ??
正因如此，除了驗證準確率的 metric，我們還需要考察模型的穩定性。例如在不同的序列之間的精度波動，不同預測 step 之間的精度波動，以及不同時間點的精度波動等。綜合表現穩定的模型往往才是業務上的更優選擇。
穩定性也很重要
從這一節開始，我們介紹具體的預測方法。
時間序列問題有著悠久的研究歷史，如果去看這方面的相關資料，會找到很多經典的時間序列檢測，預處理，和預測方法。例如很多時序模型都要求序列本身是平穩的，如果沒有達到檢測要求的話就需要通過差分操作來轉換為平穩序列。這方面的資料比較多，理論也略顯復雜，我們在這里不做太多展開，只列舉幾種比較常用的方法。
在業界做過幾個時序預測場景的同學，經常會發出這樣的感慨：“MA 好強啊”。移動平均雖然是一個很簡單的方法，但往往在很多實際問題中有著非常良好的表現，是一個不容易打敗的 baseline。
最簡單的移動平均，就是使用過去 n 個時間點的觀測值的平均，作為下一個點的預測。
Simple Moving Average
Moving Average
可以看到移動平均給出的預測非常的“靠譜”，如果把 MA 的參考范圍縮小，比如只考慮前一個時間點，我們很容易就能得出一個看起來非常準確，但只是“滯后”了一點的預測效果。但是這個滯后并不是那么好修復的，這也是很多初學者經常有的一個疑問。
在最基礎的移動平均基礎上，我們還可以有加權移動平均，指數移動平均等方法。當年 M4 比賽的冠軍方法是由 Uber 提出的 ES-RNN，其中 ES 就是指數平滑的縮寫 ??
移動平均在具體實現時也比較方便，例如在 pandas 里就有 rolling[1], ewm[2] 等方法，可以直接進行計算。在 sql 中也可以用 window function[3] 的方法來快速實現。相對其它方法來說，移動平均的計算速度很快，在海量序列場景下也能夠適用。
不過如果要做多步預測，移動平均方法就會顯得有些困難了。
時序預測領域最知名的算法，應該沒有之一。其中 AR 部分可以類比為高級的加權移動平均，而 MA 雖然是移動平均的縮寫，但其實是對 AR 部分的殘差的移動平均。
ARIMA 相關的理論基礎非常多，這里就略過了（我也不懂）。實際在使用時還需要做平穩性檢驗，確定 p, d, q 參數的值，使用起來有點麻煩。好在我們有 Auto ARIMA[4]（原版為 R 中的 forecast 包，Python 中也有類似的庫如 pmdarima[5]），可以通過 AutoML 的手段來自動搜尋最佳的參數組合。
與 ARIMA 類似的還有很多，例如改進版的 SARIMA，ARIMAX，還有雖然聽過，但從來沒用過的 ARCH，GARCH 模型等……這類模型相比簡單的移動平均，擬合能力明顯會更強一些，但缺點是運行時間也明顯變長了。通常來說，這類傳統模型我們都需要對每一條時間序列都單獨擬合和預測。如果我們要對淘寶所有的商品做銷量預測，可以預見到序列的數量會非常之大，這類方法在執行時就需要花費很長的時間，而且需要用戶自己來開發相應的并發執行機制。
由 Facebook 開源的 Prophet[6] 是另一個非常知名的時序預測模型。因為 API 設計比較友好，還附帶一系列可視化和模型解釋，在廣大人民群眾之中迅速的流行了起來。
Prophet 背后使用的是加性模型模式，將時間序列分解為趨勢，季節，節假日等外部變量這三類模型之和，且利用了概率建模方式，在預測時可以輸出預測值的概率分布情況。具體可以參考我們組鼎彥同學的這篇優秀的 介紹 Prophet 原理的文章[7]。
Prophet
Prophet 相比原版 ARIMA，在非線性趨勢，季節性，外部變量方面都具有優勢，做多步預測也會更加自然一些。但同樣，Prophet 的訓練預測也需要在每一條序列維度來進行，大規模序列的性能會是一個挑戰。
最近 Uber 也推出了一個有些類似的時序預測庫 Orbit[8]，據稱效果比 Prophet 更好。另外我們還嘗試過基于 PyTorch 的 NeuralProphet[9]，API 跟 Prophet 非常接近，不過實測下來預測的穩定性沒有 Prophet 好，可能神經網絡比較容易跑飛……
這里我們來總結一下傳統時序預測方法的一些問題：
正因為這些問題，實際項目中一般只會用傳統方法來做一些 baseline，主流的應用還是屬于下面要介紹的機器學習方法。
如果我們去翻閱一下 Kaggle 或其它數據科學競賽平臺上的相關時序預測比賽，會發現絕大多數的獲勝方案使用的是傳統機器學習的方式，更具體地來說，一般就是 xgboost 和 lightgbm 這類梯度提升樹模型。其中有個有意思的例外是當年的 Web Traffic Forecasting[10]，我當時看了這個比賽也很激動，嘗試了 N 多深度學習的方法來做時序問題，可惜大都沒有很好的結果。砍手豪大佬的這篇文章[11] 也對相關原因做了一些分析。下面我們對這類方法做個簡單介紹。
機器學習方法處理時序問題的基本思路跟前面提到的時序驗證劃分一致，就是把時序切分成一段歷史訓練窗口和未來的預測窗口，對于預測窗口中的每一條樣本，基于訓練窗口的信息來構建特征，轉化為一個表格類預測問題來求解。
滑動窗口
如上圖中，淺藍色的部分即為我們構建特征的窗口，我們利用這部分的信息輸入構建特征后，再去預測深藍色預測窗口中的值，計算誤差，再不斷迭代改進。這個窗口可以不斷往前滑動，就形成了多個預測窗口的樣本，一定程度上可以提高我們的數據利用率。
實際場景中，一般我們需要確定幾個參數：
另外值得一提的是，上圖中畫的是一條時間序列，實際上如果我們有成百上千個序列，是可以把這些數據放在一起做訓練的。這也是機器學習方法對于傳統時序方法的一個較為明顯的優勢。
在看一些文章的時候，我們也會看到一些額外加入時序預處理步驟的方法，比如先做 STL 分解再做建模預測。我們嘗試下來這類方法總體來說效果并不明顯，但對于整個 pipeline 的復雜度有較大的增加，對于 AutoML，模型解釋等工作都造成了一定的困擾，所以實際項目中應用的也比較少。
構建特征與預測
這張圖更明確的指出了我們構建特征和建模的方式。為了便于理解，我們可以假設預測的 horizon 長度僅為 1 天，而歷史的特征 window 長度為 7 天，那么我們可以構建的最基礎的特征即為過去 7 天的每天的歷史值，來預測第 8 天的值。這個歷史 7 天的值，跟之前提到的移動平均，AR（自回歸）模型里所使用的值是一樣的，在機器學習類方法中，一般被稱為 lag 特征。
對于時間本身，我們也可以做各類日期衍生特征，例如我們以天為粒度做預測，我們可以添加這天是星期幾，是一個月的第幾天，是哪個月份，是否是工作日等等特征輸入。
另外一類最常見的基礎特征，就是區分不同序列的類別特征，例如不同的門店，商品，或者不同的股票代碼等。通過加入這個類別特征，我們就可以把不同的時間序列數據放在一張大表中統一訓練了。模型理論上來說可以自動學習到這些類別之間的相似性，提升泛化能力。
類別屬性實際上可以歸類為靜態特征，即隨著時間的變化，不會發生變化的信息。除了最細粒度的唯一鍵，還可以加入其它形式的靜態特征。例如商品屬于的大類，中類，小類，門店的地理位置特性，股票所屬的行業等等。除了類別型，靜態特征也可能是數值型，例如商品的重量，規格，一般是保持不變的。
Lag 特征，日期特征這類，則屬于動態特征，隨著時間變化會發生改變。這其中又可以分成兩類，一類是在預測時無法提前獲取到的信息，例如預測值本身，跟預測值相關的不可知信息，如未來的客流量，點擊量等。對于這類信息，我們只能嚴格在歷史窗口范圍內做各種特征構建的處理，一般以 lag 為主。另一類則是可以提前獲取到的信息，例如我們有明確的定價計劃，可以預知在 T+1 時計劃售賣的商品價格是多少。對于這類特征，我們則可以直接像靜態特征那樣直接加入對應時間點的信息進去。
以上提到的基本屬于直接輸入的信息，基于這些信息，我們還可以進一步做各種復雜的衍生特征。例如在 lag 的基礎上，我們可以做各種窗口內的統計特征，比如過去 n 個時間點的平均值，最大值，最小值，標準差等。進一步，我們還可以跟之前的各種維度信息結合起來來計算，比如某類商品的歷史均值，某類門店的歷史均值等。也可以根據自己的理解，做更復雜計算的衍生，例如過去 7 天中，銷量連續上漲的天數，過去 7 天中最大銷量與最低銷量之差等等。很多數據科學比賽的獲勝方案中都會有大量篇幅來講解這方面的衍生特征如何來構建。
最后值得一提的是還有很多將各類特征工程手段自動化的工具，在時間序列領域最有名的莫過于 tsfresh[12] 了。除了前面提到的一些基礎操作，tsfresh 還能夠支持 wavelet 等高深操作，但缺點就是運行時間相對有點長，且需要結合特征選擇來達到更好的效果。
tsfresh
模型這塊，基本上沒有什么花樣，大家的主流選擇基本都是 GBDT 和 NN。個人最常使用的選擇是 LightGBM[13] 和 fastai[14]，然后選擇好時序驗證方式，做自動參數優化就可以了（比如使用 Optuna 或 FLAML）。Lgb 的訓練速度快，而且在某些業務特征比較重要的情況下，往往能達到比神經網絡更好更穩定的效果。而 NN 的主要優勢在類別變量的表達學習上，理論上可以達到更好的 embedding 表示。此外 NN 的 loss 設計上也會比較靈活，相對來說 lgb 的 loss 或者多目標學習限制條件就比較多了。更多的討論也可以參考我的這篇 表格數據模型對比[15] 的文章。總體來說，目前最常見的選擇仍然是樹模型一族。
有一個值得注意的考量點在于 local 模型與 global 模型的取舍。前面提到的經典時序方法中都屬于 local 模型，即每一個序列都要構建一個單獨的模型來訓練預測；而我們提到的把所有數據都放在一起訓練則是 global 模型的方式。實際場景中，可能需要預測的時序天然就會有很不一樣的規律表現，比如科技類股票，跟石油能源類股票的走勢，波動都非常不一樣，直接放在一起訓練反而可能導致整體效果下降。所以很多時候我們要綜合權衡這兩種方式，在適當的層級做模型的拆分訓練。深度學習領域有一些工作如 DeepFactor[16] 和 FastPoint[17] 也在自動適配方面做了些嘗試。
前面有提到過在 Kaggle 2018 年的 Web Traffic Forecasting 比賽中，冠軍選手采用了深度學習的方案，當時年幼的我看到這個分享大受震撼，感覺深度學習統治時間序列領域的時代就要到來了！后面也花了不少時間調研和嘗試各類針對時序問題設計的 NN 模型（有不少是從 NLP 領域借鑒過來的）。不過幾年嘗試下來，發現絕大多數論文中實驗數字看起來很漂亮的模型，在真實世界場景中應用的效果都不太理想，包括后來的很多比賽也仍然是樹模型占據獲勝方案的主流地位。這里有一個原因可能跟前面介紹傳統時序方法中的問題類似，很多學術研究的數據集（參考 papers with code）都是比較單一的時間序列（比如氣象信息，醫學記錄），沒有包含什么其它輸入信息和業務目標。而現實應用中的時序場景很多時候都是海量序列，包含了很多層級維度，促銷，氣候，外部事件等異常豐富的業務輸入信息，其預測場景也更加豐富多樣。
總體來說，深度學習的思路是盡量只使用原始的序列和其它相關輸入信息，基本不做特征工程，希望通過各類模型結構自動學習到時序的隱含表達，進而做端到端的預測輸出。所以我把特征工程 + NN 的方案歸類到了上面機器學習方法中。這一節里簡要介紹一下這幾年我們做過的深度學習相關嘗試，可以供同學們參考。
直接借鑒 NLP 領域中經典的 RNN, GRU, LSTM 模型來做時間序列的預測應該是最直觀的一種思路了。使用這個方法，甚至可以直接做任意步的預測窗口輸出。但實際場景中，一般時序問題的輸入輸出窗口大小帶有比較重要的業務含義，也需要針對性進行訓練，評估，優化，所以往往不會直接使用這類原始 RNN 的方式來做訓練預測。
Seq2Seq
這就是前面提到的 Web Traffic Forecasting 比賽冠軍方案中主要采用的模型。基本是借鑒了 NLP 里的經典架構，使用 RNN/GRU/LSTM 作為基本單元，encoder 中做訓練窗口中的信息提取，然后在 decoder 中做預測 horizon 的多步輸出。作者在方案里還嘗試了在 decoder 時同時引入注意力機制，但發現效果并不穩定，最后直接改成了 lag 特征來捕捉固定周期的歷史信息。
在訓練預測方面，作者也花了不少功夫，例如使用 SMAC3 進行自動調參，使用 COCOB 作為優化器，通過一系列 SGD averaging，多模型，多 checkpoint 輸出的均值來提升模型的穩定性等，具體可以參考作者的這篇 總結文檔[18]。
我們當時也把這套架構遷移到了很多我們內部的項目中，但整體用下來發現調參的計算開銷要比跑樹模型大的多得多，訓練穩定性卻遠不如樹模型，很難調整到一個穩定預測輸出的狀態。再加上整體的誤差分析和模型解釋也比較難做，所以后來也并沒有推廣使用。砍手豪大佬之后也分析過這次比賽之所以是神經網絡模型獲勝，跟使用的 SMAPE 指標也有很大關系。
這也是當年非常火的一個模型，主要是 RNN 系列模型不好并行，所以突然發現谷歌提出的這個空洞因果卷積感覺很高級，性能理論上也比 RNN 之類的好很多，它的結構大致長這樣：
WaveNet
除了使用一維 CNN 來做序列預測外，WaveNet 里還加入了 residual connection 和 skip connection，以及一系列復雜的“門機制”：
WaveNet 細節
不過我們實際使用下來，感覺 CNN 整體對于序列問題的預測效果還是不如 RNN 系列。事后來看可能跟缺乏位置編碼這類信息有關。
順帶一提 WaveNet 這類 CNN 結構也可以用在 Seq2Seq 框架中的 encoder 部分。
當年應該是在 Papers With Code 上看到 LSTNET 占據了幾個 benchmark 的榜首位置，也去簡單嘗試了一下，模型結構也是愈發花里胡哨：
LSTNet
不過效果嘛，還是不理想，不如特征工程加 fastai 效果來的好。
亞馬遜提出的一個網絡架構，也是基于 Seq2Seq，不過 DeepAR 的輸出跟 Prophet 一樣，是一個概率分布，這也是它與傳統 RNN 系列最大的一個區別。
DeepAR
雖然來頭很大，但嘗試下來仍然是很難穩定收斂，多次訓練的精度波動也很大，最終效果也無法與 GBDT 匹敵。不過在嘗試 DeepAR 的過程中發現亞馬遜開源的一個挺不錯的時序預測庫 gluon-ts[19]，里面包含了非常多的深度學習時序模型實現，也很方便自己實現相關模型，大大加速了我們的實驗嘗試，非常值得推薦！
概率分布輸出本身是個挺有用的特性，例如用于下游的 Service Level 的滿足率計算等。理論上我們也可以用 quantile regression 方法，或者 ngboost[20] ， LightGBMLSS[21] 等庫在 GBDT 模型上實現概率預測輸出。
這也是一個來頭很大的模型，出自 Element AI[22]，Bengio 是其中的 Co-Founder。第一次見到它是來自 M5 比賽亞軍的分享，不過他也只是在 top-level 的預測中使用了一下 N-Beats 模型。
N-Beats
從介紹來看，N-Beats 專注于做單變量的時序預測，且可以具有一定的 seasonality，trend 的可解釋性，跟 Prophet 很相似。從論文的實驗來看，作者使用了非常重的 ensemble，每個序列搞了 180 個模型的 bagging。這感覺有點過于“殺雞用牛刀”了……我們實測下來也沒有取得很好的效果，而且看起來還不好加額外的特征變量，使用場景很受限。
終于來到了一個嘗試下來表現可以與樹模型匹敵的深度學習模型了！這就是 Google AI 提出的 Temporal Fusion Transformers。也是本文提到的第一個帶 transformer 結構的模型 ??
TFT
個人感覺 TFT 的設計里最有意思的是對于特征變量選擇網絡的考慮，從實現效果上來說跟樹模型做特征選擇很相似。順帶一提我們在表格類問題上測試下來表現比較好的模型，例如 TabNet，NODE 等，也都有這種模擬決策樹行為的設計。具體實驗下來在一些場景中 TFT 甚至可以超越特征+GBDT 的建模方案，非常驚人！不過訓練計算開銷仍然是比較大，這點還是跟樹模型有差距。
TFT 還有一點比較有意思的是對于特征輸入的設計挺系統化，分成了靜態類別/連續變量，動態已知類別/連續變量，和動態未知類別/連續變量。以我們使用的 pytorch-forecasting[23] 庫為例，其 dataset 接口大致長這樣：
training = TimeSeriesDataSet(
data[lambda x: x.date <= training_cutoff],
time_idx= ..., # column name of time of observation
target= ..., # column name of target to predict
group_ids=[ ... ], # column name(s) for timeseries IDs
max_encoder_length=max_encoder_length, # how much history to use
max_prediction_length=max_prediction_length, # how far to predict into future
# covariates static for a timeseries ID
static_categoricals=[ ... ],
static_reals=[ ... ],
# covariates known and unknown in the future to inform prediction
time_varying_known_categoricals=[ ... ],
time_varying_known_reals=[ ... ],
time_varying_unknown_categoricals=[ ... ],
time_varying_unknown_reals=[ ... ],
)這種歸類方式非常具有通用性，值得推廣。
總體看來，目前（22 年初）能夠大規模推廣應用的深度時序模型感覺還基本沒有（最新的 Informer, Autoformer 還沒嘗試）。前陣子有一篇很有意思的論文也討論了這點，標題就叫 Do We Really Need Deep Learning Models for Time Series Forecasting?[24]，從結果來看基本還是 GBDT 完勝。
這塊也有很多綜述文章可以參考，例如：
除了模型預測本身，深度學習中的各種強項，例如預訓練和遷移學習，表達學習，生成式模型等方面，目前也還很難應用于時序領域。未來想要有所突破，如何能更好的做 數據增強[27]，做 時序問題的預訓練[28]，也是很值得深入研究的方向。
最后在整體架構方面，跟機器學習模型 pipeline 來對比看，前者一般模型部分處理會相對簡單，但涉及到的預處理，特征工程及后處理方面會比較復雜；而深度學習手段正好相反，在整體 pipeline 層面會相對簡單，更提倡 end-to-end 的訓練，但模型部分則相對復雜和難以優化。
最后我們來看下時序領域的 AutoML，近幾年 Github 上也出現了一些針對時序問題的 AutoML 庫，例如：
不過總體來說他們面向的還是模型的自動選擇和調優，針對時序問題做了一些特定的配置項，如時間粒度，前面有提到過的預測的長度，自動的 validation 等。但從前文的對比來看，目前效果比較好的主流方法還是特征工程+GBDT 模型，尤其是特征工程這塊的自動化顯得尤為關鍵，而目前 tsfresh 也并沒有在衍生特征的自動化上做多少工作。個人在前面 TFT 的結構化時序數據集接口設計基礎上，設計相應的自動化特征工程與模型優化，會是一個能夠達到比較好效果的路徑。
此外，前文中比較少有提到時序數據的各種檢測判斷，預處理等環節。在之前的 AutoML 比賽中，就有 life-long learning 的設定，即模型的學習預測會隨著時間的推移不斷有新數據的輸入，這也與真實項目的情況非常符合。因此完善的 AutoML 方案中，也需要包含例如 prior shift, covariate shift, concept drift 等方面的檢測與處理，以適應復雜的真實預測場景。
可以預見未來會有更多的面向時序問題的 AutoML 框架和產品出現，不斷降低使用門檻，擴展相關的應用場景。對這些方向感興趣的同學也可以多跟我們討論交流，一起打造行業領先的 AI 產品。
[1]rolling:https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.rolling.html
[2]ewm: https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.ewm.html
[3]window function: https://learnsql.com/blog/moving-average-in-sql/
[4]AutoARIMA:https://www.rdocumentation.org/packages/forecast/versions/8.16/topics/auto.arima
[5]pmdarima: http://alkaline-ml.com/pmdarima/index.html
[6]Prophet: https://facebook.github.io/prophet/
[7]介紹 Prophet 原理的文章: https://zhuanlan.zhihu.com/p/463183142
[8]Orbit: https://github.com/uber/orbit
[9]NeuralProphet: https://github.com/ourownstory/neural_prophet
[10]Web Traffic Forecasting: https://www.kaggle.com/c/web-traffic-time-series-forecasting/
[11]砍手豪大佬的這篇文章: https://zhuanlan.zhihu.com/p/352461742
[12]tsfresh: https://github.com/blue-yonder/tsfresh
[13]LightGBM: https://github.com/microsoft/LightGBM
[14]fastai: https://github.com/fastai/fastai
[15]表格數據模型對比: https://zhuanlan.zhihu.com/p/381323980
[16]DeepFactor: https://arxiv.org/abs/1905.12417
[17]FastPoint: https://dl.acm.org/doi/abs/10.1007/978-3-030-46147-8_28
[18]總結文檔: https://github.com/Arturus/kaggle-web-traffic/blob/master/how_it_works.md
[19]gluon-ts: https://github.com/awslabs/gluon-ts
[20]ngboost: https://github.com/stanfordmlgroup/ngboost
[21]LightGBMLSS: https://github.com/StatMixedML/LightGBMLSS
[22]Element AI: https://www.elementai.com/
[23]pytorch-forecasting: https://github.com/jdb78/pytorch-forecasting
[24]Do We Really Need Deep Learning Models for Time Series Forecasting?: https://arxiv.org/pdf/2101.02118.pdf
[25]Learnings from Kaggle’s Forecasting Competitions: https://arxiv.org/abs/2009.07701
[26]Neural forecasting: Introduction and literature overview: https://arxiv.org/abs/2004.10240
[27]數據增強: https://arxiv.org/abs/2002.12478
[28]時序問題的預訓練: https://arxiv.org/abs/2005.06978
[29]Auto_TS: https://github.com/AutoViML/Auto_TS
[30]AutoTS: https://github.com/winedarksea/AutoTS
文章轉自微信公眾號@算法進階