網劇、網綜早已成爲人們的“休閒佳品”，除了精彩內容，還有各種貼片廣告推送。細心的你也許會發現，這些廣告彷彿知你所想，懂你所思，常常能擊中你的喜好。這是爲什麼呢？因爲這些廣告背後，涉及了機器學習與多維時序預測等技術和場景。要講清楚這背後的故事，首先，我們要了解什麼是廣告庫存。
什麼是廣告庫存？
在計算廣告中，庫存指的是廣告投放機會的存量，廣告投放機會由兩個要素構成：媒體與流量。媒體是內容與廣告的載體，以視頻、音頻、文字等不同形式提供內容與廣告位；流量則關乎廣告投放機會的存量與價值。廣告機會的價值取決於流量本身，由高消費潛力用戶構成的流量價值自然更高些；廣告機會的存量則很大程度由用戶的觀看習慣、瀏覽習慣所決定。舉例來說，一集50分鐘的《後翼棄兵》，媒體平臺以前貼片、中貼片和後貼片的方式總共設置4個廣告位，如下圖所示。
廣告機會示意
對於任何一個觀看這集《後翼棄兵》的用戶，視頻中的廣告位都是如此設置，但是，至於這 50 分鐘的視頻到底能提供多少個廣告投放機會，那就因人而異了。比如有兩個用戶，李雷和韓梅梅，李雷將視頻從頭看到尾，甚至把正片結束後 30 秒的後貼片廣告也看完了，那麼李雷提供的廣告投放機會就是 4；韓梅梅則沒那麼有耐心，視頻看了 1/3，看到第二個廣告之後便把視頻關掉，那麼韓梅梅提供的廣告投放機會是 2，即便後面 2/3 的視頻內容中還有兩個廣告位，但是已經沒有機會展示出來了。
在計算廣告業務中，庫存預測扮演着重要角色。對於品牌廣告，買賣雙方交易撮合的前提是不同定向條件下廣告庫存的準確預測；效果廣告中，對於交易價格隨時間波動的媒體流量，如果能夠有效預測其在未來一段時間的概率分佈，那麼作爲買方的市場參與者在預算固定的情況下對於流量的競買會更加遊刃有餘。
預測廣告庫存：多維時序預測
基於上面的示例，應該更容易理解：本質上，廣告庫存是不同用戶畫像下廣告投放機會的存量。那麼，廣告庫存該如何預測呢？既然廣告庫存取決於流量且按照定向條件（用戶畫像）劃分，那我們自然想到將這個業務問題轉化爲多維時序預測，一旦有了技術方向，剩下的就是技術選型問題了。無論是從用戶視角出發的用戶畫像，還是從廣告主視角出發設置的定向條件，本質上都是不同維度的交叉組合。例如，給定性別、年齡、所在省份三個刻畫維度，至少有 2x100x52 種組合來刻畫不同的人羣，如果以小時爲單位統計不同人羣貢獻的廣告庫存，那麼每一個人羣都有與之對應的庫存序列。顯然，有多少人羣，就有多少廣告庫存序列——這也正是多維時間序列名字的由來。對於多維時序預測場景，計算廣告公司 FreeWheel至少有 3 種技術方案，如下圖所示。
不同技術方案優缺點
在 FreeWheel 的業務場景中，我們需要基於種類衆多的定向條件（內容來源、地理位置、播放設備、用戶畫像等）以小時爲粒度預測未來 3 個月的廣告庫存。這樣的業務需求至少面臨 4 個方面的挑戰：
衆多定向條件的交叉組合造成維度爆炸，維度爆炸又帶來數據分佈的長尾效應；
維度爆炸帶來的工程複雜度。如果爲每個序列構建時序模型，那麼工程與運維成本無法想象；
超長時間序列。在傳統的金融時序預測中，預測週期往往不超過 120 個時間單元，但在 FreeWheel 的場景中，需要向前預測 2160（24x90）個時間單元；
海量數據挑戰。FreeWheel 日投放廣告量達到10億級規模，爲了向前預測2160個時間單元，至少需要回溯同樣長的時間週期，也就是說至少要回溯3個月的數據，數據規模可想而知。
機器學習團隊的主要職能在於利用機器學習算法賦能業務，團隊的核心競爭力在於算法，專注於機器學習在計算廣告業務中的應用與落地。與專職算法研究不同，算法的應用與落地要求團隊同時具備算法鑽研與實現、模型調優、工程交付等多方面的能力。受限於團隊規模與有限的人力資源，FreeWheel 無法承受龐大的工程與運維成本，因此上表的方案1被迅速排除。
方案2雖然在一定程度上降低了工程成本，但是訓練階段先聚類再時序預測、推理階段先預測再反歸一化的非端到端流程依然比較繁瑣，非端到端解決方案的主要痛點在於工程耦合組件較多，耦合組件過多帶來的副作用就是端到端的穩定性較差。爲了將後期運維成本降至最低，我們最終還是選擇了上表中的方案3。儘管方案3涉及的深度模型複雜度較高、調優挑戰較大，但這正是團隊的核心價值所在。
技術方案敲定後，接下來需要考慮的是採用哪些技術棧。衆所周知，端到端機器學習流水線至少囊括以下環節：
FreeWheel 通常使用 Presto 分佈式數據庫來拉取數據源，然後利用高效的分佈式計算引擎 Apache Spark（Databricks商業版本）來進行數據預處理、特徵工程和樣本工程。就機器學習算法來說，Spark 的 ML 算法庫提供了豐富的經典算法實現並且支持大規模樣本量下的分佈式模型訓練。不過，對於參數量動輒百萬甚至上億的深度模型來說，模型並行是剛需，Spark 基於數據並行的實現方式便有些力不從心，超大規模的深度學習模型在單點中的存儲與更新已然超出硬件資源上限，從而導致模型訓練無法順利完成。鑑於此，FreeWheel 採用支持模型並行機制的 TensorFlow 來實現自定義的深度學習模型。得益於 Keras Functional API，FreeWheel 很快便實現了定製化的深度網絡結構並在單機環境中跑通了訓練流程，接下來便是基於3個月體量的大規模樣本在分佈式環境下不停地迭代、調優模型。對於算法人員來說，網絡結構調整、超參調優是“家常便飯”，週而復始的迭代對分佈式訓練環境的穩定性與運行效率提出了較高要求。就目前來說，TensorFlow 的分佈式部署主要有如下幾種方式：
三種部署方案各有千秋，基於 Spark 或 YARN 的部署方式適合已經部署 Hadoop 生態的數據和算法團隊；而基於 Kubernetes 的部署方式則非常有利於離線模型訓練與在線模型服務的融合與統一。不過，對於這三種部署方案，我們不難發現這其中的每一種都需要 TensorFlow 與底層框架的集成與耦合，對於FreeWheel 機器學習團隊來說，沒有額外的時間和精力來搭建這樣的分佈式訓練集羣。對於一個規模小、專注於算法研究與落地的團隊來說，FreeWheel 最需要的是“召之即來、揮之即去”的分佈式訓練環境，按需而用，用完即棄。於是，FreeWheel 調研了多種雲原生的分佈式機器學習平臺，並最終選擇了Amazon SageMaker 來實現分佈式模型訓練、調優、部署，從而打通整條端到端大規模機器學習流水線。
爲什麼選擇AmazonSageMaker？
Amazon SageMaker 從開發到部署，以開箱即用和深度定製化兩種方式提供了完備的分佈式功能集合。在開發方面，AmazonSageMaker 提供的 Jupyter notebook 與腳本模式允許開發者根據業務需要充分定製深度模型，開發者僅需幾行框架代碼（Skeleton code）即可將現有的 TensorFlow 代碼遷移至Amazon SageMaker，僅需幾個有限的參數即可按指定機型、數量自由啓停分佈式訓練集羣。對於分佈式模型訓練，Amazon SageMaker 在模型並行方面支持兩種實現方式：參數服務器與 Horovod，在硬件資源方面支持 CPU 與 GPU，這種開放性允許開發者結合業務場景（圖像識別、分類迴歸、時序預測等）靈活地構建運行時環境。
在模型訓練過程中，Amazon SageMaker console 提供的可視化面板讓開發者可以及時監測模型訓練過程、收斂情況、擬合能力、泛化能力，從而使開發者在下一輪迭代中做到有的放矢。對於模型調優，算法人員最頭疼的無疑是超參調優、網絡結構變更、激活函數、學習率、優化函數等等，不一而足。對於深度模型，網格搜索和隨機搜索逐漸淡出視野，超參調優的趨勢是利用機器學習來調優機器學習，即用機器學習的方法來選擇超參數；值得一提的是，在Auto ML如火如荼發展的當下，作爲其中一個門類，超參調優被應用得最爲廣泛。AmazonSageMaker的Auto Pilot爲自動超參調優賦能，允許開發者以開箱即用的方式充分享受Auto ML發展的紅利。
部署方面，Amazon SageMaker 提供的 API 允許開發者以按需方式啓停分佈式訓練集羣，按需而用、按需付費、用完即停。不僅如此，Amazon SageMaker 自 2017 年底開始支持 Spot 機型，這一機型的支持使 FreeWheel 的雲上成本在現有的基礎上又降低了至少 50%。Amazon SageMaker 爲開發者提供的功能集合完備而全面，鑑於篇幅有限，難以一一陳述。
那麼，Amazon SageMaker 如何助力 FreeWheel 實現大規模多維時序預測？效果與收益如何？2021年1月13日，亞馬遜 re:Invent2020 計算廣告與營銷主題專場會議《Distributedmachine learning for digital video and TV ad serving》（Session ID: ADM302）中，AWS 資深開發者佈道師王宇博聯袂FreeWheel 機器學習團隊負責人吳磊，爲您傾情講述箇中細節，敬請期待！
1.做備忘|GD32 Arm MCU物聯網開發者線上課程不容錯過！
