跳到主要內容
工程的博客

改進供應鏈需求預測的新方法

帶因果因素的細粒度需求預測

2020年3月26日 工程的博客

分享這篇文章

快速鏈接到這篇文章中引用的筆記本。

組織正在迅速接受細粒度需求預測

零售商和消費品製造商越來越多地尋求改善其供應鏈管理,以降低成本,釋放流動資金,並為全渠道創新奠定基礎。消費者購買行為的變化給供應鏈帶來了新的壓力。通過需求預測更好地了解消費者需求被認為是大多數這些工作的良好起點,因為對產品和服務的需求推動了有關勞動力、庫存管理、供應和生產計劃、貨運和物流以及許多其他領域的決策。

來自AI Frontier的注釋麥肯錫公司強調,零售供應鏈預測精度提高10 - 20%,可能會使庫存成本降低5%,收入增加2% - 3%。傳統的供應鏈預測工具未能提供預期的結果。索賠行業平均不準確性為32%在零售商供應鏈需求預測中,即使是適度的預測改進,對大多數零售商的潛在影響也是巨大的。因此,許多組織正在遠離預包裝的預測解決方案,探索將需求預測技能引入內部的方法,並重新審視過去的實踐,這些實踐影響了預測準確性和計算效率。

這些工作的一個重點是在更細的時間和(位置/產品)層次粒度上生成預測。精細需求預測有可能捕捉到影響需求的模式,使其更接近必須滿足的需求水平。在過去,零售商可能會在市場層麵或分銷層麵預測一類產品的短期需求,為期一個月或一周,然後使用預測值來分配在給定的商店和一天中應該放置的一類特定產品的單位,細粒度需求預測允許預測者建立更多的本地化模型,反映特定產品在特定位置的動態。

精細穀物需求預測麵臨挑戰

盡管精細需求預測聽起來令人興奮,但它也麵臨許多挑戰。首先,通過遠離總體預測,必須生成的預測模型和預測的數量會激增。所需的處理水平要麼是現有預測工具無法達到的,要麼是它大大超出了這些信息有用的服務範圍。這種限製導致公司在處理的類別數量或分析中的穀物水平上做出權衡。

正如先前檢查過的博客可以使用Apache Spark來克服這一挑戰,允許建模人員並行化工作,以實現及時、高效的執行。當部署在Databricks等原生雲平台上時,可以快速分配和Beplay体育安卓版本釋放計算資源,將這項工作的成本控製在預算之內。
要克服的第二個更困難的挑戰是理解在更細的粒度級別上檢查數據時,總體上存在的需求模式可能不存在。用亞裏士多德的話來說,整體往往大於各部分之和。當我們在分析中轉向更低的細節級別時,在更高粒度級別上更容易建模的模式可能不再可靠地呈現,使得使用適用於更高級別的技術生成預測更具挑戰性。在預測的背景下,這個問題被許多從業者注意到,一直追溯到亨利·賽爾在20世紀50年代。

當我們接近事務粒度級別時,我們還需要考慮影響個別客戶需求和購買決策的外部因果因素。總的來說,這些可能反映在組成時間序列的平均值、趨勢和季節性中,但在更細的粒度級別上,我們可能需要將這些直接納入我們的預測模型中。

最後,移動到更細的粒度級別增加了數據結構不允許使用傳統預測技術的可能性。我們越接近事務粒度,就越有可能需要處理數據中的不活動時期。在這種粒度級別上,我們的因變量,特別是在處理銷售單位等計數數據時,可能會出現不適合簡單轉換的傾斜分布,這可能需要使用許多數據科學家所不熟悉的預測技術。

訪問曆史數據

詳見數據準備筆記本

為了研究這些挑戰,我們將利用紐約市自行車共享計劃的公共旅行曆史數據Citi Bike NYC.Citi Bike NYC是一家承諾幫助人們“解鎖自行車”的公司。解鎖紐約。”他們的服務可以讓人們去紐約市850多個不同的租賃地點中的任何一個地方租自行車。該公司有超過1.3萬輛自行車庫存,並計劃將數量增加到4萬輛。Citi Bike擁有超過10萬名訂戶,每天騎行近1.4萬次。

Citi Bike NYC將自行車從停放的地方重新分配到他們預計未來需求的地方。紐約市Citi Bike麵臨的挑戰與零售商和消費品公司每天麵臨的挑戰類似。我們如何最好地預測需求,將資源分配到正確的領域?如果我們低估了需求,就會錯失盈利機會,並可能損害客戶的信心。如果我們高估了需求,我們就有多餘的自行車庫存沒有使用。

這個公開的數據集提供了從上月末到2013年年中該項目開始時的每一次自行車租賃信息。行程曆史數據確定了從特定出租站租用自行車的確切時間,以及將自行車歸還到另一個出租站的時間。如果我們將Citi Bike NYC項目中的站點視為門店位置,並將租賃的開始視為交易,那麼我們就有了一個非常接近於長期而詳細的交易曆史的東西,我們可以根據它進行預測。

作為這個練習的一部分,我們將需要識別外部因素,並將其納入我們的建模工作中。我們將利用假日事件以及曆史(和預測的)天氣數據作為外部影響因素。對於假日數據集,我們將簡單地使用假期圖書館在Python中。對於天氣數據,我們將使用每小時提取的視覺交叉是一個流行的天氣數據聚合器。

Citi Bike NYC和Visual Crossing數據集有條款和條件,禁止我們直接共享他們的數據。那些希望重現我們結果的人應該訪問數據提供商的網站,查看他們的條款和條件,並以適當的方式將他們的數據集下載到他們的環境中。我們將提供將這些原始數據資產轉換為我們分析中使用的數據對象所需的數據準備邏輯。

檢查事務數據

詳見探索性分析筆記本

截至2020年1月,Citi Bike NYC自行車共享計劃包括864個活躍的站點,在紐約市大都市區運營,主要在曼哈頓。僅在2019年,客戶發起的獨立租賃次數就略高於400萬次,高峰日的租賃次數多達近1.4萬次。beplay体育app下载地址

Citi Bike NYC的銷售數據可視化示例,說明了各個可用租賃站的需求。

自該計劃啟動以來,我們可以看到出租的數量逐年增加。這種增長部分可能是由於自行車利用率的增加,但大部分似乎與整個車站網絡的擴張有關。

數據可視化顯示了2013年至2020年紐約市Citibike租賃需求和利用率的增長。
數據可視化顯示了2013年至2020年紐約市Citibike租賃需求和利用率的增長。

通過網絡中活躍站點的數量來標準化租金,可以看出在過去幾年裏,每個站點的客流量一直在緩慢增長,我們可以認為這是一個輕微的線性上升趨勢。

數據可視化顯示,2013年至2020年間,紐約市Citibike每個站點的客流量不斷增加

使用這個租金的標準化值,客流量似乎遵循一個明顯的季節性模式,在春季、夏季和秋季上升,然後在冬季下降,因為室外的天氣變得不太適合騎自行車

數據可視化描繪了2013年至2020年紐約市Citibike租賃需求的季節性

他的模式似乎與該城市最高溫度(華氏度)的模式密切相關。

數據可視化顯示了高溫和Citibike NYC自行車租賃需求增加之間的相關性。

雖然很難將每月的客流量與氣溫模式區分開來,但降雨量(以月平均英寸為單位)並不能很容易地反映這些模式

月平均降雨量的數據可視化顯示了將天氣與Citibike NYC租賃需求相關聯的難度。

根據周日為1,周六為7的每周騎行模式,紐約人似乎把自行車作為通勤工具,這種模式在許多其他自行車共享項目中都能看到。

Citibike NYC每周自行車騎行量的數據可視化顯示,通勤者的使用模式與許多其他自行車共享項目相似。

按小時劃分這些客流量模式,我們可以看到明顯的工作日模式,在標準通勤時間客流量峰值。在周末,模式表明更悠閑地使用程序,支持我們之前的假設。

Citibike NYC自行車騎行量的數據可視化顯示了在白天和晚上的所有時間發生的租賃活動。

一個有趣的現象是,無論假日是星期幾,它所顯示的消費模式都大致與周末的使用模式相似。假日的不頻繁出現可能是這些趨勢不穩定的原因。不過,這張圖表似乎表明,節假日的確定對於做出可靠的預測是很重要的。

Citibike NYC自行車假日騎行量的數據可視化顯示,利用模式大致模擬了周末的使用情況。

總的來說,每小時的數據似乎表明紐約市確實是一個不夜城。在現實中,有許多車站有很大一部分時間沒有自行車出租。

Citibike NYC自行車騎行人數的數據可視化顯示了在一天中記錄1小時不活動的單個站點的數量,說明了使用傳統方法預測需求的困難。

在試圖進行預測時,這些活動的差距可能會產生問題。通過將間隔時間從1小時改為4小時,各個站點沒有租賃活動的時段數量大幅下降,盡管在這段時間內仍有許多站點處於不活躍狀態。

Citibike NYC自行車騎行人數的數據可視化顯示,記錄了一天中4小時不活動的單個站點的數量,說明了使用傳統方法預測需求的難度。

我們將嚐試以小時為單位進行預測,探索替代預測技術如何幫助我們處理這個數據集,而不是通過轉向更高級別的粒度來回避不活躍期的問題。由於預測大部分不活躍的站點並不是特別有趣,我們將把分析限製在最活躍的200個站點上。

使用Facebook Prophet預測共享單車租賃

在最初嚐試預測每個站點的自行車租賃情況時,我們使用了Facebook的先知,一個流行的用於時間序列預測的Python庫。該模型被配置為探索具有每日、每周和每年季節性模式的線性增長模式。數據集中與節假日相關的時段也被識別出來,這樣這些日期的異常行為就不會影響算法檢測到的平均值、趨勢和季節模式。

使用之前引用的博客文章中記錄的橫向擴展模式,對200個最活躍的站點的模型進行了訓練,並為每個站點生成了36小時的預報。總的來說,這些模型的均方根誤差(RMSE)為5.44,平均比例誤差(MAPE)為0.73。(MAPE計算將零值實際調整為1。)

這些指標表明,這些模型在預測租金方麵做得相當不錯,但當每小時租金上漲時,這些模型就不存在了。將單個站點的銷售數據可視化,您可以通過圖形化方式看到這一點,例如E 39 St & 2 Ave 518站點的圖表,其RMSE為4.58,MAPE為0.69:

詳見時間序列筆記本。

數據可視化顯示了使用Facebook Prophet預測模型的局限性,該模型被配置為探索線性增長模式來預測本地化需求。該模型在預測單個Citibike NYC租賃站的租金方麵做得相當不錯,但當每小時租金上漲時,就開始出錯。

然後對模型進行了調整,將溫度和降水作為回歸因子。總的來說,所得預測的RMSE為5.35,MAPE為0.72。雖然有很小的改善,但模型仍然難以在車站層麵發現客流量的大幅波動,正如518站再次證明的那樣,其RMSE為4.51,MAPE為0.68:

詳見時間序列與回歸筆記本。
Facebook Prophet預測模型的數據可視化,該模型被配置為探索線性增長模式,並將天氣作為回歸量進行調整。雖然這是一個非常微小的改進,但這些模型仍然難以捕捉到紐約市Citibike站點客流量的大幅波動。

這種模式的難度建模較高的值在兩個時間序列模型是典型的處理數據的泊鬆分布.在這樣的分布中,我們將在平均值周圍有大量的值,在平均值之上有長尾值。在平均值的另一邊,零底部會使數據產生偏差。今天,Facebook Prophet希望數據具有正態分布(高斯分布)計劃對泊鬆回歸的引入進行了討論。

預測供應鏈需求的替代方法

那麼我們如何繼續對這些數據進行預測呢?Facebook Prophet的管理者正在考慮的一種解決方案是,在傳統時間序列模型的背景下利用泊鬆回歸功能。雖然這可能是一種很好的方法,但它並沒有被廣泛記錄,因此在考慮其他技術之前自行解決這個問題可能不是滿足我們需求的最佳方法。

另一個潛在的解決方案是對非零值的規模和零值周期出現的頻率進行建模。然後可以將每個模型的輸出組合成一個預測。這種方法被稱為Croston方法,最近發布的Python庫而另一位數據科學家已經實現了他自己的功能為它。然而,這並不是一種被廣泛采用的方法(盡管該技術可以追溯到20世紀70年代),我們的偏好是探索更多的東西開箱即用的

考慮到這種偏好,隨機森林回歸器似乎有相當大的意義。一般來說,決策樹不會像許多統計方法那樣對數據分布施加相同的約束。預測變量的值範圍是這樣的,在訓練模型之前使用像平方根變換這樣的東西來轉換租金可能是有意義的,但即使這樣,我們可能會看到算法在沒有它的情況下表現如何。

為了利用這個模型,我們需要設計一些特性。從探索性分析中可以明顯看出,無論是在年度、每周還是每天的水平上,數據都存在強烈的季節性模式。這導致我們提取年、月、星期的一天和一天中的小時作為特征。我們還可以加入一麵假日旗幟。

使用隨機森林回歸器和時間衍生特征,我們得到了總體RMSE為3.4,MAPE為0.39。518站的RMSE和MAPE值分別為3.09和0.38:

詳情請參見Temporal Notebook。

通過利用降水和溫度數據,結合這些相同的時間特征,我們能夠更好地(盡管不是完美地)解決一些較高的租金值。518站的RMSE下降到2.14,MAPE下降到0.26。總體而言,RMSE降至2.37,MAPE降至0.26,表明天氣數據在預測自行車需求方麵是有價值的。

詳見隨機森林與時間和天氣特征筆記本。

Facebook Prophet預測模型的數據可視化(用於Citibike NYC),配置為探索線性增長模式,使用隨機森林回歸器進行調整,除了時間衍生特征外沒有其他特征。

研究結果的意義

更細粒度級別的需求預測可能需要我們以不同的方式思考建模方法。外部影響因素可能被安全地認為是總結在高水平的時間序列模式中,可能需要更明確地納入我們的模型。隱藏在聚合級別的數據分布模式可能變得更容易暴露,並需要對建模方法進行更改。在這個數據集中,這些挑戰最好的解決辦法是包括每小時的天氣數據,並從傳統的時間序列技術轉向對輸入數據進行較少假設的算法。

可能還有許多其他的外部影響因素和算法值得探索,當我們沿著這條路走下去時,我們可能會發現其中一些對我們的某些數據子集比其他數據更好。我們可能還會發現,隨著新數據的到來,以前工作良好的技術可能需要被放棄,而需要考慮新的技術。

我們在客戶探索細粒度需求預測時看到的一個常見模式是在每個訓練和預測周期中beplay体育app下载地址評估多種技術,我們可以將其描述為自動模型烘烤。在決勝輪中,為給定數據子集產生最佳結果的模型贏得這輪比賽,每個子集都能夠決定自己的獲勝模型類型。最後,我們希望確保我們正在執行良好的數據科學,其中我們的數據與我們所使用的算法正確對齊,但正如一篇又一篇文章所指出的那樣,問題的解決方案並不總是隻有一種,有些解決方案可能在同一時間比其他解決方案更好。我們今天所擁有的Apache Spark和Databricks等平台的強大之處在於,我們可以利Beplay体育安卓版本用計算能力來探索所有這些路徑,並為我們的業務提供最佳解決方案。

額外的零售/CPG和需求預測資源

免費試用Databricks

相關的帖子

看到所有工程的博客的帖子
Baidu
map