背 景

在公司運行過程中，尤其是對于偏重數據的互聯網公司，業務異常檢測是一個非常重要但又很容易被輕視的工作。一旦因為業務發生異常并且沒有被及時發現，一定會對公司和客戶產生某種程度的損失，從而影響業務正常發展。很多公司都構建了基于規則的報警平臺，并將其應用于業務的異常檢測。但由于數據模式的快速變化，并且數據中存在著大量噪音，基于規則的異常檢測誤報率較高。基于機器學習和人工智能的業務異常檢測可以獲得比傳統規則系統更高的準確率和擴展性，但由于面臨諸如異常的定義較為模糊、缺少數據標簽等諸多挑戰，構建一個實用的業務異常檢測系統需要算法工程師和數據開發工程師的精雕細琢才能完成。

FreeWheel 是一家數字廣告管理技術和服務提供商，創建于 2007 年，是一家專門提供電視及互聯網視頻廣告投放、監測、預測、增值等關鍵解決方案的技術公司，主營業務為高端視頻媒體的廣告服務。為客戶提供穩定可靠的廣告投放服務是 FreeWheel 的宗旨，為了提高服務質量，對業務的異常檢測和預警非常關鍵。我們從 2020 年開始從零打造了基于機器學習的業務異常檢測系統，覆蓋了 FreeWheel 核心業務指標，為客戶的廣告投放保駕護航。

本文介紹了 FreeWheel 基于機器學習的業務異常檢測實踐，提煉了從零開始構建業務異常檢測系統面臨的問題和解決方案，文章介紹了常用的異常檢測算法，比較了不同算法模型的優劣，介紹了可擴展的異常檢測系統是如何搭建的，希望對于從事相關工作的朋友能夠帶來幫助。

異常檢測概述

從應用場景分，異常檢測包括指標異常檢測、日志異常檢測、網絡異常檢測、用戶行為異常檢測（風控、反作弊）等。從數據角度又可以分為新奇點檢測 (Novelty Detection) 和離群點檢測 (Outlier Detection)。

廣告業務異常檢測是以業務指標為基礎，多維度、多角度的異常檢測。一方面，業務指標是連續采集的時間序列，通常認為歷史序列是正常的，從中學習特定的模式，未來的指標如果違反了這個模式，可以認為出現了異常，從這個角度看，屬于新奇點檢測的范疇。另一方面，業務指標在某幾個維度下的值一般會滿足某種分布，和多數正常值相比差別比較大的可能就是異常點，這屬于離群點檢測的范疇。受篇幅所限，本文主要關注新奇點檢測問題，離群點檢測的相關實踐將在后續分享。

異常檢測面臨諸多挑戰，第一，正常和異常的邊界是非常模糊的，很多時候是“公說公有理，婆說婆有理”；第二，歷史數據里經常包括很多噪音，甚至歷史數據中就存在著異常。第三，幾乎沒有標注的異常標簽；第四，正常數據的模式也不是一成不變的，會隨著時間的推移和業務的演進發生很大的變化。指標異常檢測算法，包括無監督、半監督、監督機器學習算法。其中以無監督應用最為廣泛。無監督主要有基于統計模型的異常檢測（如 EVT），基于時間序列預測的異常檢測，基于隱變量重構誤差的異常檢測（如 VAE），以及其他深度學習的衍生模型（如 AnomalyTransformer) 等。監督的算法更偏向于傳統的機器學習和深度學習的分類模型，半監督方法致力于解決標簽數據不足的問題，提高監督方法的學習效果。本文主要介紹我們從零到一的實踐經驗和在生產環境中應用較為成熟的算法模型，除此之外，基于監督和半監督方法的模型也很快投入生產環境，期待后面分享給大家。

業務指標監控

FreeWheel 監控平臺目前有兩大指標數據來源，Prometheus 和數據平臺。Prometheus 是目前主流的開源監控解決方案，具有數據模型靈活、延遲低等特點，目前存儲 FreeWheel 絕大多數系統和應用指標和核心業務指標。Prometheus 的核心業務指標是從 Ad Server 直接采集而來，如請求量、廣告曝光量等，聚合粒度較粗。另一部分來源于 FreeWheel 數據平臺，通過對 AdServer 產生的廣告日志的實時處理，將更細粒度的指標存入 Druid，其數據延遲為分鐘級。有了細粒度的數據后，我們可以基于我們關心的維度進行實時聚合，如廣告曝光量這個指標，根據客戶 ID 進行聚合，可以對每個客戶 ID 的廣告曝光量時間序列進行異常檢測和報警。

快速搭建 V1.0 系統

最早的時候，我們通過規則的方式對幾個關鍵的指標配置了預警，比如，某個重要客戶的曝光量或者轉化率小于某個閾值就會觸發報警；比如針對所有的站點，若流量同環比小于 80%，就認為可能有問題。這些規則確實起到了一定的作用，也檢測到了很多異常，但缺點也很明顯：第一是規則太多，不同客戶的業務和流量模式千差萬別，同一套閾值比較難以滿足需求；第二點是業務變化很快，閾值需要隨著業務變化不斷地調整，維護成本高；第三點，也是最大的痛點是誤報率大，需要耗費大量的人工處理報警。

為了從零開始快速搭建起基于機器學習的 V1.0 的異常檢測系統，我們采用了簡單直接的做法，基于歷史數據訓練回歸模型，預測未來的指標和對應的上下界，如果真實值超過了上下界，則檢測到異常并觸發報警，也就是基于時間序列預測的異常檢測。

（注：綠色實線時指標的真實值，藍色虛線是指標的預測值，橙色和紅色分別是上下屆，紅框標注的是檢測到的異常）

第一版模型 ARIMA

首先，為了能快速上線第一個版本，我們嘗試了時間序列預測里最常用的 ARIMA 模型，ARIMA 是 Autoregressive Integrated Moving Average model 的縮寫。ARIMA 模型有三個超參數 p,d,q，一般寫作 ARIMA(p,d,q) 中，AR 是“自回歸”，p 為自回歸項數；MA 為“滑動平均”，q 為滑動平均項數，d 為使之成為平穩序列所做的差分階數。對于每一個時間序列，都需要確定最適合的超參數 p,d,q，通常有一套成熟的策略進行人工選擇，如通過觀察差分之后的平穩性確定 d，通過觀察 ACF 曲線和 PACF 曲線確定 q 和 p 等等。但是，對于數以萬計的時間序列來說，人工調整顯然不可行，這套經驗策略也較難量化，因此我們采用類似網格搜索的方法確定超參數，這一過程也被稱為自動定階。

周期性檢測

ARIMA 模型沒有考慮時間序列的季節性（也稱作周期性，下文統稱周期性）變化，但周期性是大多數跟流量相關的指標必須要考慮的一個因素，并且不同的業務模式的流量周期是不一樣的，看下面的兩個例子。

如上圖所示，按小時粒度聚合的 2 個指標，其周期分別為 24 和 168，分別代表每天重復的模式和每周重復的模式。

我們需要給出最匹配這個時間序列的周期值，即周期性檢測。周期性檢測的方法有很多，第一種就是相似度檢測，假設周期為 T，將時間序列按照長度為 T 進行切分得到若干個分段，計算相鄰分段的相似度。第二種方法是分析 ACF 曲線，ACF 全稱是 Autocorrelation function，其表達了時間序列和自身偏移一定量之后的相關性。通過觀察 ACF 曲線的特點可以推斷出時間序列周期。除了這兩種方法外，周期性檢測還有快速傅里葉變換（FFT）、小波變換等方法。我們根據不同指標的時間粒度、數據量和不同方法的計算復雜度、準確性等，根據經驗和實驗結果構建了一個的選擇周期性檢測方法的決策樹，由最適合的一種或幾種方法，綜合計算出時間序列的周期。

Seasonal ARIMA

由于普通的 ARIMA 模型不能夠處理周期性，Seasonal ARIMA 模型引入了季節分量，可以更好地處理周期性，通常寫作 SARIMA(p,d,q)(P,D,Q,s) 。s 是時間序列的周期，P,D,Q 分別對應季節分量的滑動平均項數、差分階數和滑動平均項數。

在訓練數據的選取上，雖然歷史數據越多，模型擬合地會更好，但并不是越多越好，一方面，數據量增加會使得 ARIMA 模型擬合時間變長，另一方面，業務指標的模式可能隨著時間而發生變化。以小時粒度指標，對于無周期的 ARIMA 模型，200~300 多個點即可取得比較好的效果，也就是 7~14 天左右的歷史數據；對于周期性的 SARIMA 模型，5~10 個周期即可取得比較好的效果，對于呈現每周重復的模式，6 周左右的數據可以取得比較好的效果。

如何計算上下界

有了預測值之后，接下來我們需要得到判斷異常的上下界閾值，ARIMA 模型在輸出預測結果的同時，也輸出了置信區間。置信區間概率論里的一個概念，是基于區間估計的結果，在預測的場景下，代表預測結果會一定的概率出現在這個區間，這個概率就被稱為置信度。當隨機變量符合正態分布時，95% 置信度的置信區間近似等于均值加減 2 倍標準差，而均值加減 3 倍標準差的置信度為 99.7%，這也就是常說的 2 倍標準差法和 3 倍標準差法。將置信區間作為判斷異常的上下界閾值時最適合不過的了，當置信度越大時，置信區間越寬，超出上下界閾值的異常就越顯著，換句話說，業務指標的異常就越嚴重。通過設置不同的置信度，我們可以探測到不同嚴重程度的異常。

在實際應用時，由于我們的業務指標通常時非負的，并不能滿足正態分布（或者高斯分布），因此 ARIMA 模型直接輸出的置信區間就不合適了。通過分析發現，絕大多數業務指標近似滿足從零處截斷的截斷正態分布（高斯分布），因此我們只需要取出 ARIMA 模型輸出的預測值和標準誤差，就可以利用截斷正態分布的累計分布函數和分位函數計算出置信區間。

V1.0 系統架構

有了第一版的模型的結果，我們上線了異常檢測系統 V1.0，架構如下圖所示：

V1.0 系統的核心就是指標預測服務，指標預測服務將需要預測的指標的預測結果和報警上下界輸出到監控平臺，通過在監控平臺上對需要進行異常檢測到指標配置報警規則，由監控平臺實時檢查是否滿足報警要求，也就是超過上下界，從而觸發報警。指標預測服務是基于 PySpark 實現的，由兩類定時任務構成。第一類是周期性檢測和模型訓練，頻率較低，大約每天執行一次，負責將所有需要檢測的指標和維度下的時間序列都進行周期性檢測、ARIMA 超參數選取和 ARIMA 模型訓練，并將周期數、ARIMA 超參數和 ARIMA 模型參數進行保存。

第二類是預測任務，基于 Spark 的并行計算能力，可以實現在較短時間能完成大量時間序列的預測工作。以小時級任務為例，每次預測任務都會預測時間序列未來 N 個小時（例如 N=24）的指標值和上下界，并寫入數據庫；小時級任務可以配置每隔 M 個小時（例如 M=6）執行一次，同時覆蓋之前的預測結果。這樣做的好處是既保證了預測數據的冗余，使得在預測任務失敗或者延誤的時候還有之前的預測結果可以使用，同時執行預測任務的 executor 可以允許在按需申請的 spot instance ec2 上，節約了計算成本，由于 spot instance 的不可靠性，預測任務可能隨時失敗，只要重試即可。另一方面，配置 M

當前的問題和優化

對第一版的結果進行分析，我們發現有下面幾個問題會導致精確率（Precision）不足，誤報較多：

1) 區間太緊

首先是置信區間的問題，當我們選好一個合適的置信度，如 99%，會發現對于多數時間序列都是合適的，但對于那些規律性比較強的時間序列來說，其模型的擬合度非常好，MAPE 能小于 5%，預測的標準誤差很低，因此置信區間會比較窄，如圖：

這就會導致如果指標出現輕微的抖動，比如 +/-10%，就會被識別為異常，這顯然是我們不希望看到的。我們的改進有兩點，第一是對標準誤差進行放大，當標準誤差 / 均值的比例小于一定的程度時，將標準誤差乘以一定的放大系數，再計算置信區間；第二是利用預期的抖動比例進行干預，將計算出來的置信區間和基于經驗配置的容忍抖動比例（如 +/-20%）進行融合，這樣得出的上下界既能符合模型的擬合結果，也能在業務上看來不至于特別離譜。

2) 數據包含噪音

第二點，歷史數據中包含異常點，會對模型的擬合和預測產生一定的影響。例如如果前一天流量因為某些原因（如壓力測試）有一個很明顯的尖峰，那大概率 ARIMA 模型預測的今天同周期也會相應地變高，從而導致對正常流量的誤判。我們從兩個方面解決這個問題，第一是模型啟動的時候，我們用一個規則去識別那些比較明顯的異常點；然后，當我們的模型開始運行，異常點被檢測出來后，我們通過建立反饋機制修正模型的輸入數據，將異常點的值修正為此前的預測值，后面模型的預測將不會收異常點的影響。當然如果異常點識別錯了，反饋機制會帶來負面效應，處理這個異常報警的運營人員會對其進行標記，從而避免這個問題。

3) 數據太稀疏

此外，我們發現，有一大部分時間序列的數據非常稀疏，也就是其歷史上的取值經常缺失，導致時序預測準確度較差。針對這種情況，從業務的角度考慮，我們通過設置閾值跳過數據太稀疏或者歷史流量過少的的場景，減少誤報。

第二代系統 (V2.0) V1.0 的不足

V1.0 異常檢測系統有幾個問題，首先在系統層面，隨著需要配置異常檢測報警的指標越來越多，通過 Hard Code 的方式部署的指標預測服務的擴展性問題就凸顯出來；另外，業務上希望對于指標短時間抖動或者業務影響比較小的異常進行過濾，現有的架構難以實現。在模型層面，ARIMA（SARIMA）模型在很多場景下預測誤差較大，基于這樣的預測結果計算的上下界會導致較多誤報警。

針對 V1.0 系統和模型的不足，我們設計了第二代異常檢測系統 V2.0。

異常檢測系統 V2.0 架構

在第二版的異常檢測系統中，我們將異常檢測的工作從監控平臺完全剝離出來，專注于優化異常檢測算法和策略，進而提升異常檢測的效果。異常檢測系統將結果以異常得分的形式輸出給監控平臺，由監控平臺負責報警和運營操作。下面是系統整體的架構圖。

異常檢測系統包括元數據管理、模型訓練、異常評估等幾個模塊。元數據理負責和監控平臺同步異常檢測需求和配置信息，如要檢測的指標、數據源、維度、過濾條件等，并生成對應的時間序列元數據。模型訓練和之前相似，不同的是從批任務變成了實時任務，通過內置的調度模塊，一方面要服務監控平臺實時配置的需求，對于新增的時間序列要優先進行訓練，另一方面也要定期地對舊模型進行更新。

異常評估模塊

異常評估模塊也是一個長期運行的 Spark 應用，內置的調度模塊會調度每個任務的運行，同時考慮實時數據源依賴、數據完整性檢查、指標歷史數據緩存、任務優先級等，將適合的任務提交 Spark Job Group。每個 Spark Job Group 都包括指標數據查詢、數據處理、并行的時間序列異常檢測和結果匯總與輸出等多個 Spark Job/Stage，其中最核心的是并行的時間序列異常檢測的 Stage，多個 Task 由 Spark 調度并行執行。

異常評估模塊的另外一個關鍵點是對異常進行評估和打分 (0 到 1 之間的分數)，異常比較明顯或者對業務影響比較大的異常的得分更接近 1，不明顯的異常、噪音、對業務影響小的異常的得分更接近 0。相比 V1.0 異常檢測系統，引入異常評估模塊后極大地提升了異常檢測的能力，一方面可以引入基于規則和策略的評估，另一方面可以直接基于無監督或者監督的機器學習模型給出異常打分。由于基于規則和策略的評估方法可解釋性更強，占線上多數場景都采用此方法；在一些特殊業務場景中，通過模型直接打分也取得了不錯的效果。

下面簡單介紹下我們的打分策略，首先，選取評估窗口，即同時評估最近的幾個時刻指標值的異常情況，評估窗口數據的異常相比只評估點數據的異常可以減少噪音的影響，當然，越新的數據權重越大。以流量指標為例，我們綜合了以下幾個因素進行評估：是否超出上下界、相比預測值流量異常下降（或者上漲）的幅度，即重構誤差、歷史流量大小，當前所處時刻流量的相對大小、異常持續的時間、歷史上發生過類似異常的頻率等。

除了基于影響的評估之外，我們還構建了根因分析系統對異常進行歸因分析，提供一站式業務運營解決方案，極大地提高了運營效率，同時消除由于業務上預期的“指標異常”導致的誤報警。對于可以簡單找到根因的異常，我們選擇直接在異常檢測階段進行消除，而不是導入根因分析系統，來減少計算壓力。例如，程序化交易的流量異常下降，很可能是交易暫停，或者已經達到預算等原因導致的。

新的算法模型 預測模型

ARIMA（SARIMA）模型能夠較好地擬合大多數的時間序列，但在實際使用中有兩個比較突出的問題：一、對于不帶周期項的 ARIMA，其預測結果會有較為明顯的滯后現象，容易導致誤判；二、如果周期數過大，模型擬合的速度很慢，如對于小時粒度的數據，當周期為 168 時，其單線程擬合時間超過 5 分鐘。為了彌補 ARIMA 模型的不足，我們引入了 XGBoost、STL、SMA 和 EVT 等模型，不同的模型有各自的優缺點和適合的應用場景，下面我們先簡單介紹下這些模型。

XGBoost

XGBoost 是一個梯度提升決策樹（GBDT）的高效實現，以極強的模型學習效果和性能著稱，可以解決 SARIMA 長周期預測性能無法滿足要求的問題。應用到時間序列預測時，需要人工進行特征工程，我們選取了這么幾類特征：

第一類是時間序列的 lag（滯后算子），也就是要預測的時刻 T 的前面時刻的值，如 T-1，T-2…. lag 并不是越多越好，對于小時粒度的數據，如果輸入是 5 周（840），那么約靠前的 lag 可能的價值就越低，我們根據周期的不同，選取的 lag 數也不一樣。如前序判斷為 24 周期，則選取 1~40 lag，和每 24 個周期選取同周期的 lag，如 t-48，t-96，等等。

第二類是時間特征，如星期幾、是否為周末、當前小時等。

第三類是時間窗口統計特征，如最近 24 小時的平均值，工作日的平均值，周末的平均值，過去 7 天當前小時的平均值，等等。

XGBoost 的擬合能力是非常強的，因此擺在我們面前很大的問題是如何避免過擬合，也就是雖然在訓練數據上模型擬合地非常好，但在驗證數據上預測誤差較大。首先是從參數入手，包括使用 L2 正則，限制樹的深度、對訓練數據進行采樣，預剪枝等參數都會起到一定的效果。此外，如果訓練數據不足，過擬合是很難避免的，因此 XGBoost 只適用于時間序列歷史數據非常多的情況。

此外，另一種解決單一的時間序列訓練數據量較少的方法，是通過對相同指標不同維度的時間序列進行聚類，將相似的維度值對應的時間序列放到一起訓練模型，這樣可以增加訓練數據量，緩解過擬合的問題。但這種方法擴展性較差，需要根據具體的指標和維度對應的時間序列的情況單獨調整。

STL

對于某些長周期的指標，我們面臨 SARIMA 擬合時間非常長，又沒有足夠的數據訓練 XGboost 的情況，這時候時間序列分解派上用場了。時間序列分解是將時間序列分解為均值 (Mean) 、趨勢 (Trend) 、季節 (Seasonality) 、循環 (Cycle)、隨機誤差 (Random) 這幾個部分，分解方式通常包括乘法和加法。趨勢表示這個時間序列的長期趨勢，通常加上了均值，季節性（也叫周期性）指時間序列隨著時間的季節波動，通常是年、周、日等，循環指的是指標在較長時間呈現出上下波動，通常會被合并到趨勢項中，稱作趨勢 - 循環項（trend-cycle）。

將時間序列的周期和趨勢分解開之后，我們可以通過更加簡單的模型，如 ARMA，去擬合趨勢，對于周期項，只需要簡單的重復即可，最后將趨勢的預測結果和周期相加即刻得到最終的預測結果。

圖片來源于https://otexts.com/fpp2/stl.html

經典的乘法和加法分解只能支持固定周期，且受歷史數據的異常點影響較大，STL(Seasonal and Trend decomposition using Loess) 分解則較好地解決了這兩種問題，我們選用 STL 分解結合 ARIMA 擬合趨勢的方法，較好地解決了長周期時間序列的預測問題。除了 STL 之外，還有 X11 和 SEATS 等分解方法。

SMA

在線上實際運行時，我們發現無論是 ARIMA、XGboost，還是 STL 分解，其模型訓練時間都在分鐘級，預測時間都在秒級，對于那些時間序列數量巨大的業務指標來說，顯然是非常不經濟的。

同時我們發現，這些業務指標都有一個特點，對于多數時間序列，他們的模式是非常穩定的，因此設計一種快速地算法解決這類問題可以極大地降低異常檢測的成本。

我們從常用的同環比出發，設計一種結合周期的帶權移動平均方法（Seasonality Moving Average，簡稱 SMA），可以在毫秒級完成預測任務。預測值為同比（最近幾個周期同時刻）和環比（最近的數據）的加權平均，以小時粒度指標，周期為 24 時為例：

r(recent): 考慮最近的數據點數

α(alpha): 最近數據的權重

c(cycles): 考慮的周期數

o(offsets): 同周期前后偏離的點數

預測模型的評估

對于以上的時間序列預測模型，需要評估其預測的準確程度，我們選用 SMAPE 作為預測模型準確性的評估指標：

SMAPE 反映了模型擬合歷史數據的誤差，在模型擬合能力一定時，也反應了該時間序列的可預測性，或者叫模式（pattern）的強弱。上面四種模型基本上可以滿足多數時間序列的異常檢測，但是對于周期性和模式都比較弱的時間序列來說，上述模型預測誤差都比較大，通常 SMAPE>70，會導致有較多的異常誤報。最初的做法是忽略這類時間序列的異常檢測，在一定程度上解決了異常檢測精準率不足的問題，但也降低了召回率。

EVT

為了提升周期性和模式都比較弱的時間序列異常檢測的召回率，我們引入了極值理論（Extreme Value Theory，簡稱 EVT）。極值理論可以在數據分布位置的條件下，估計極值（極大值和極小值）的分布，從而估計正常數據合理的上下界。由于篇幅原因，本文不詳細描述具體算法實現，大家感興趣可以閱讀論文（https://www.researchgate.net/publication/318919520）。論文作者考慮了概念漂移的問題，但沒有考慮數據的周期性。對于存在一定周期性的時間序列，我們在應用極值理論模型的時候會先根據周期性進行數據采樣，對于同周期的數據，采樣的概率更大，這樣更符合實際情況，對異常檢測的準確率也更高。

模型對比

目前我們引入的模型有 ARIMA、XGBoost、STL-ARIMA、SMA、EVT 等，我們先來總結一下這些模型的特點：

模型選擇

隨著模型引入越來越多，我們需要一套方法為特定的時間序列選擇合適的模型。根據這些模型的特點，我們建立了一個決策樹，根據指標的類型、周期性、歷史數據量、實時性、成本等因素，選擇合適的候選模型方案。

一個候選模型方案包括首選模型、若干個備選模型和保底模型。舉一個典型的例子，因為極低的成本，SMA 將被作為首選模型，首先用 SMA 擬合時間序列的歷史數據，并給予設定好的驗證數據窗口，如最近 3 天，計算預測的 SMAPE 誤差，若 SMAPE 小于預設的閾值（如 50），則認為 SMA 的擬合是有效的并將其作為模型選擇的結果，否則，將嘗試備選模型。假設 ARIMA、XGBoost、STL-ARIMA 都可以做為備選模型，則分別嘗試對這三種模型進行擬合，在 SMAPE 小于閾值的模型中選擇最優的作為模型選擇的結果。如果備選模型都不能滿足需求，則判斷有沒有保底模型，如果有保底模型（比如 EVT），則將其作為模型選擇的結果，否則這個時間序列被認為是無效的。

總結 & 未來展望

FreeWheel 業務異常檢測系統從上線至今已有兩年的時間，共接入了十幾種業務場景和幾十種指標，如針對不同客戶集成方式的流量監控、程序化交易全生命周期的異常檢測及根因分析等，幫助 FreeWheel 和客戶主動發現廣告投放中的若干個 P1、P2 級別的嚴重問題，減少了客戶的損失，在維護客戶關系方面發揮了重大作用。下一步，我們會支持更多的業務，尤其是針對 FreeWheel Marketplace 的業務，發現和解決廣告需求側和供給側之間的匹配問題，以及客戶流量的廣告填充率不足的根因分析，幫助客戶提高廣告投放效果和利潤。

從算法和模型的角度，目前線上大多數模型都是基于時間序列預測、針對特定指標和維度（時間序列）自動訓練的小模型，其優點是靈活性和擴展性好，成本低；缺點也比較明顯，不方便針對具體的業務優化特征工程，包括多指標協同、不同維度和標簽之間的數據依賴等。因此，我們針對幾種特殊的業務場景，如程序化交易，開發了基于神經網絡的大模型；除此之外，我們也對其他的無監督、監督和半監督方法進行了研究和開發，希望后面能分享給大家。

作者簡介

鐘雨，本科和研究生就讀于清華大學，現任 FreeWheel 異常檢測團隊主任算法工程師，FreeWheel 業務異常檢測算法團隊負責人。曾供職于京東廣告數據團隊，Spark Contributor，具備豐富的大數據開發與調優、數據挖掘和機器學習經驗，在廣告大數據行業深耕多年。

審核編輯：郭婷