零售商和消費者品牌專注於確保他們擁有消費者在市集中尋求購買的正確產品和服務。 在查看最大化銷售時，產品（或產品群組）是購物體驗的主要部分。 供應專案的可用性— 庫存 — 是消費者品牌持續關注的問題。
產品庫存也稱為 SKU 種類，是橫跨供應和物流產業鏈的複雜問題。 在本文中，我們特別著重於優化 SKU 種類的問題，以將消費品收入最大化
透過開發演算法來回答下列問題，即可解決 SKU 分類優化難題：
- 哪些 SKU 在指定的市場或商店中表現最佳？
- 應該根據其效能，將哪些 SKU 配置給指定的市場或商店？
- 哪一個 SKU 執行效能低，且應該由高效能的 SKU 取代？
- 我們可以衍生哪些其他見解來瞭解我們的消費者和市場區隔？
自動化決策制定
傳統上，消費者品牌通過增加SKU組合中的SKU數目來接近消費者需求的問題。 隨著 SKU 數量激增和競爭增加，據估計，90% 的收入只歸因於組合內的 10% 產品 SKU。 一般而言，80% 的收入來自 20% 的 SKU。 這個比例是提高盈利能力的候選專案。
靜態報告的傳統方法會使用歷程記錄數據，以限制深入解析。 至少，決策仍會以手動方式進行並實作。 這表示人為介入和處理時間。 隨著 AI 和雲端運算的進步，您可以使用進階分析來提供一系列選擇和預測。 這種自動化可改善結果和客戶速度。
SKU 分類優化
SKU 分類解決方案必須將銷售數據分割成有意義的詳細比較，以處理數百萬個 SKU。 解決方案的目標是使用進階分析，藉由調整產品種類，將每個網點或商店的銷售最大化。 第二個目標是消除庫存不足，並改善各種種類。 財政目標是銷售額增加5%至10%。 為此，深入解析可讓您：
- 瞭解SKU組合效能及管理低效能。
- 將 SKU 分佈優化，以減少庫存不足。
- 瞭解新的 SKU 如何支援短期和長期策略。
- 從現有數據建立可重複、可調整且可採取動作的深入解析。
描述性分析
描述性模型會匯總數據點，並探索可能影響產品銷售的因素之間的關聯性。 此資訊可以透過一些外部數據點來增強，例如位置、天氣和人口普查數據。 視覺效果可藉由解譯數據來協助人們衍生深入解析。 不過，在這樣做時，瞭解僅限於在上一個銷售週期中發生的事情，或可能發生在目前銷售週期中的情況（取決於數據重新整理的頻率而定）。
在此案例中，傳統的數據倉儲和報告方法就足以瞭解 SKU 在一段時間內表現最好的和最差的 SKU。
下圖顯示歷史銷售數據的一般報告。 它會使用複選框來選取準則來篩選結果的數個區塊。 中心會顯示兩個條形圖，顯示一段時間的銷售額。 第一張圖表顯示依周的平均銷售額。 第二個顯示依星期的數量。
預測性分析
歷史報告有助於瞭解所發生的事情。 歸根結底，我們希望預測可能發生的情況。 過去的信息對於該用途很有用。 例如，我們可以識別季節性趨勢。 但是，它無法協助假設案例，例如，建立新產品的模型。 若要這樣做，我們必須將焦點轉移到模型化客戶行為，因為這是決定銷售的最終因素。
深入探討問題：選擇模型
讓我們先定義我們要尋找的內容，以及我們有哪些數據：
各種優化表示尋找可最大化預期收益的產品子集。 這是我們正在尋找的。
事務數據 會定期收集以用於財務目的。
各種資料 可以包含任何與 SKU 相關的專案：以下是我們想要的範例：
- SKU 數目
- SKU 描述
- 配置的數量
- 購買的 SKU 和數量
- 事件的時間戳（例如購買）
- SKU 價格
- 以 POS 計算的 SKU 價格
- 每個 SKU 在任何時間點的庫存層級
不幸的是，這類數據不會像事務數據一樣可靠地收集。
在本文中，為了簡單起見，我們只考慮事務數據和 SKU 數據，而不是外部因素。
即便如此，請注意，假設有一組 n 個產品，有 2n 個 可能的種類。 這會使優化問題成為需要大量計算的程式。 評估所有可能的組合與大量的產品是不切實際的。 因此，一般而言，各種類別會依類別區隔（例如穀物）、位置和其他準則來減少變數數目。 優化模型會嘗試剪除可運作子集的排列數目。
問題的癥結在於 有效地將取用者 的行為模型化。 在完美的世界中，提供給他們的產品將符合他們想購買的產品。
幾十年來，用來預測消費者選擇的數學模型已經發展起來。 模型的選擇最終將決定最適合的實作技術。 因此，我們將摘要說明它們，並提供一些考慮。
參數模型
參數模型會使用具有一組有限參數的函式來近似客戶行為。 我們估計參數集最適合我們處置的數據。 其中一個最老且最出名 的是多項羅吉斯回歸 （也稱為 MNL、多類別對數或 softmax 回歸）。 它用來計算分類問題中數個可能結果的機率。 在此情況下，您可以使用 MNL 來計算：
取用者 （c） 在特定時間 （t） 選擇專案 （i） 的機率，在分類中指定了一組類別的專案，且客戶有已知的公用程式 （v）。
我們也假設專案的公用程式可以是其功能的函式。 外部資訊也可以包含在公用程序的測量中（例如，雨傘在下雨時更有用）。
我們通常會使用 MNL 作為其他模型的基準，因為它在估計參數時和評估結果時的可取性。 換句話說，如果您比 MNL 更糟，您的演算法就不會使用。
數個模型已衍生自 MNL，但已超出本文討論這些模型的範圍。
R 和 Python 程式設計語言有連結庫。 針對 R，您可以使用 glm （和衍生專案）。 針對 Python，有 scikit-learn、 biogeme 和 larch。 這些連結庫提供工具來指定 MNL 問題，以及平行解決器，以在各種平台上尋找解決方案。
最近，建議在 GPU 上實作 MNL 模型，以計算具有許多參數的複雜模型，否則會使其難以運作。
具有softmax輸出層的神經網路已有效地用於大型多類別問題。 這些網路會產生一個輸出向量，代表一些不同結果的機率分佈。 相較於其他實作，它們訓練速度很慢，但可以處理大量的類別和參數。
非參數模型
儘管其受歡迎程度，MNL 還是對人類行為提出了一些重大假設，可以限制其實用性。 特別是，它假設某人在兩個選項之間選擇的相對機率與稍後在集合中導入的其他替代方案無關。 在大多數情況下，這是不切實際的。
例如，如果您同樣喜歡產品 A 和產品 B，您將選擇一個超過其他 50% 的時間。 讓我們將產品 C 引入混合。 您仍然可以選擇產品 A 50% 的時間，但現在您將喜好設定 25% 分割為產品 B，並將 25% 分割為產品 C。相對機率已變更。
此外，MNL 和衍生產品沒有簡單的方法來考慮由於庫存或各種品種的替代專案（也就是說，當你沒有清楚的想法，並在貨架上挑選隨機專案）。
非參數模型的設計目的是要考慮替代專案，並對客戶行為施加較少的限制。
他們介紹了排名的概念，消費者對各種產品表示嚴格的偏好。 因此，其購買行為可以藉由依喜好的遞減順序排序產品來建立模型。
各種優化問題可以表示為營收的最大化：
- ri 代表產品 i 的收入。
- yik 是 1，如果產品 i 在排名 k 中選擇。 否則為 0。
- π k 是客戶根據排名 k 做出選擇的機率。
- xi 是 1，如果產品包含在各種產品中。 否則為 0。
- K 是排名數目。
- n 是產品數目。
注意
受限於條件約束：
- 每個排名只能有1個選擇。
- 在排名 k 下，只有在屬於各種產品時，才能選擇 i 的產品。
- 如果產品 i 包含在各種產品中，則無法選擇排名 k 中較不偏好的選項。
- 不購買是一個選項，因此可以選擇排名中較不偏好的選項。
在這類公式中，問題可視為 混合整數優化。
假設有 n 個產品，可能的排名數目上限，包括無選擇選項，是因數： （n+1）！
公式中的條件約束允許比較有效率地剪除可能的選項。 例如，只選擇最偏好的選項，並將 設定為 1。 其餘部分會設定為 0。 假設可能的替代項目數目，您可以想像實作的延展性很重要。
數據的重要性
我們之前提到，銷售數據已可供使用。 我們想要使用它來通知分類優化模型。 特別是，我們想要尋找機率分佈 π。
銷售點系統的銷售數據包含具有時間戳的交易，以及該時間與位置向客戶顯示的一組產品。 從這些，我們可以建構實際銷售的向量，其元素vi，m代表向客戶銷售專案 i 給客戶的機率，指定各種 Sm
我們也可以建構矩陣：
找出我們的機率分佈 π，因為我們的銷售數據會成為另一個優化問題。 我們想要尋找向量 π，以將銷售估計錯誤降到最低：
minπ |Ππ - v|
請注意，計算也可以表示為回歸，因此可以使用多變數判定樹等模型。
實作詳細資料
由於我們可以從先前的公式推斷，優化模型既是數據驅動，又需要大量計算。
Microsoft 合作夥伴，例如 Neal Analytics，已開發健全的架構來滿足這些條件。 請參閱 SKU 最大值。 我們將使用這些架構作為範例，並提供一些考慮。
- 首先，他們依賴強固且可調整的數據管線來提供模型，以及健全且可調整的執行基礎結構來執行模型。
- 其次，透過儀錶板，規劃人員可以輕鬆地取用結果。
圖 2 顯示範例架構。 其中包含四個主要區塊：擷取、進程、模型和運作。 每個區塊都包含主要進程。 擷取包含數據前置處理;進程包括存放區數據函式;模型包含定型機器學習模型函式;和 Operationalize 包括儲存數據和報告選項（例如儀錶板）。
圖 2：SKU 優化架構，由 Neal Analytics 提供
數據管線
此架構強調為模型定型和作業建立數據管線的重要性。 我們會使用 Azure Data Factory 來協調管線中的活動，這是受控擷取、轉換和載入 （ETL） 服務，可讓您設計和執行整合工作流程。
Azure Data Factory 是受控服務，其元件稱為 取用和/或產生數據集的活動 。
活動可以分割成：
- 資料移動（例如，從來源複製到目的地）
- 資料轉換（例如，使用 SQL 查詢匯總或執行預存程式）
您可以將一組活動連結在一起的工作流程，由數據處理站服務排程、監視及管理。 完整的工作流程稱為 管線。
在擷取階段中，我們可以使用Data Factory複製活動，將資料從各種來源（內部部署和雲端中）傳輸到 Azure SQL 數據倉儲。 如何在檔中提供的範例：
下圖顯示管線的定義。 它是由數據列中三個相同大小的區塊所組成。 前兩個是一個數據集和一個透過箭號連接的活動，以指出數據流。 第三個標籤為 Pipeline ，並指向前兩個表示封裝。
圖 3：Azure Data Factory 的基本概念
您可以在 Microsoft 商業市集頁面上找到 Neal Analytics 解決方案所使用的數據格式範例。 解決方案包含下列資料集：
- 每個商店與 SKU 組合的銷售歷程記錄數據
- 儲存和取用者記錄
- SKU 代碼和描述
- 擷取產品功能的SKU屬性（例如大小和材質）。 這些通常用於參數模型中，以區分產品變體。
如果數據源不是以特定格式表示，Data Factory 會提供一系列轉換活動。
在程序階段中，SQL 數據倉儲是主要的儲存引擎。 您可以將這類轉換活動表示為 SQL 預存程式，而此預存程式可以在管線中自動叫用。 檔案提供詳細的指示：
請注意，Data Factory 不會限制您 SQL 數據倉儲和 SQL 預存程式。 事實上，它與各種平臺整合。 例如，您可以使用 Databricks 並改為執行 Python 腳本進行轉換。 這是一個優點，因為您可以在下列模型階段使用一個平臺來儲存、轉換和定型機器學習演算法。
定型 ML 演算法
有數個工具可協助您實作參數和非參數模型。 您的選擇取決於您的延展性和效能需求。
Azure ML Studio 是一項絕佳的原型設計工具。 它可讓您輕鬆地使用程式代碼模組（在 R 或 Python 中），或在圖形化環境中使用預先定義的 ML 元件（例如多類別分類器和提升判定樹回歸）來建置和執行定型工作流程。 它也可讓您輕鬆地將定型的模型發佈為 Web 服務，以便進一步取用，為您產生 REST 介面。
不過，它可以處理的數據大小目前限制為 10 GB，且每個元件可用的核心數目限制為 2。
如果您需要進一步調整，但仍想要使用一些快速、平行、常見的機器學習演算法 Microsoft 實作（例如多項羅吉斯回歸），您可以考慮在 Azure 資料科學虛擬機器 上執行的 Microsoft ML Server。
對於非常大的數據大小（TBs），選擇記憶體和計算元素可以：
- 獨立調整，以在未定型模型時限制成本。
- 將計算分散到多個核心。
- 執行接近記憶體的計算，以限制數據移動。
Azure HDInsight 和 Databricks 都滿足這些需求。 此外，它們是 Azure Data Factory 編輯器中支援的兩個執行平臺。 將任整合至工作流程相當簡單。
ML Server 及其連結庫可以部署在 HDInsight 之上，但若要充分利用平臺功能，您可以使用 SparkML、Python 中的 Microsoft ML Spark 連結庫，或其他專業的線性程式設計解算器，例如 TFoCS、Spark-LP 或 SolveDF，來實作您選擇的 ML 演算法。
啟動定型程序之後，會成為從 Data Factory 工作流程叫用適當 pySpark 腳本或筆記本的問題。 圖形化編輯器完全支援此功能。 如需詳細資訊，請參閱 在 Azure Data Factory 中使用 Databricks Notebook 活動執行 Databricks Notebook。
下圖顯示透過 Azure 入口網站 存取的 Data Factory 使用者介面。 其中包含工作流程中各種進程的區塊。
圖 4：具有 Databricks 筆記本活動的 Data Factory 管線範例
另請注意，在我們的清查優化解決方案中，我們建議透過 Azure Batch 調整的解決器容器式實作。 Pyomo 等專家優化連結庫可讓您使用 Python 程式設計語言來表達優化問題，然後叫用 bonmin （開放原始碼） 或 gurobi （商業） 等獨立解決器來尋找解決方案。
庫存優化文件處理與各種優化不同的問題（訂單數量），但 Azure 中的解算器實作同樣適用。
雖然比到目前為止建議的複雜程度更高，但這項技術允許最大的延展性，大部分受限於您可以負擔的核心數目。
執行模型 （operationalize）
定型模型之後，執行模型通常需要不同於用於部署的基礎結構。 為了方便取用，您可以使用 REST 介面將其部署為 Web 服務。 Azure ML Studio 和 ML Server 都會自動化建立這類服務的程式。 在 ML Server 的情況下，Microsoft 會提供範本來部署支援的基礎結構。 請參閱相關 文件。
下圖顯示部署的架構。 它包含執行 R 語言和 Python 的伺服器表示法。 這兩部伺服器都會與執行計算的 Web 節點子區段通訊。 大型數據存放區會連線到計算區塊。
圖 5：ML 伺服器部署的範例
在 HDInsight 或 Databricks 上建立的模型取決於 Spark 環境（連結庫、平行功能等等）。 您可以考慮在叢集上執行它們。 這裡提供指引。 這樣做的優點是，作業模型本身可以透過Data Factory管線活動叫用以進行評分。
若要使用容器，您可以封裝模型，並將其部署在 Azure Kubernetes Service 上。 原型需要使用 Azure 資料科學 VM。 您也必須在 VM 上安裝 Azure ML 命令行 工具。
數據輸出和報告
部署之後，模型可以處理財務交易工作流程和股票讀數，以產生最佳的各種預測。 因此產生的數據可以儲存回 Azure SQL 數據倉儲，以進行進一步分析。 特別是，可以研究各種 SKU 的歷史效能，找出最佳的收益產生器和虧損者。 然後，您可以比較這些與模型建議的種類，並評估效能，以及重新定型的需求。
Power BI 提供一種方式來分析和顯示程式中所產生的數據。
下圖顯示典型的Power BI儀錶板。 其中包含兩個顯示 SKU 庫存資訊的圖表。
安全性考量
處理敏感數據的解決方案包含財務記錄、股票水平和價格資訊。 這類敏感數據必須受到保護。 您可以透過下列方式來減輕對資料安全性和隱私權的擔憂：
- 您可以使用 Azure Integration Runtime 在內部部署執行部分 Azure Data Factory 管線。 運行時間會執行內部部署來源的數據移動活動。 它也會分派活動以供內部部署執行。
- 您可以開發自定義活動，以匿名傳送至 Azure 的數據，並在內部部署執行。
- 提及的所有服務都支援傳輸和待用加密。 如果您選擇使用 Azure Data Lake 儲存數據，預設會啟用加密。 如果您使用 Azure SQL 資料倉儲，您可以啟用透明數據加密 （TDE）。
- 除了 ML Studio 之外，所有提及的服務都支援與 Microsoft Entra ID 整合以進行驗證和授權。 如果您撰寫自己的程式碼，則必須將該整合建置至應用程式。
如需有關歐盟一般數據保護規定（GDPR）的詳細資訊，請參閱我們的 合規性 頁面。
元件
本文提供下列技術：
- Azure Batch
- Microsoft Entra ID
- Azure Data Factory
- HDInsight
- Databricks
- 資料科學虛擬機器
- Azure Kubernetes Service
- Microsoft Power BI
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- Scott Seely |軟體架構師
若要查看非公用LinkedIn配置檔，請登入LinkedIn。
下一步
- 什麼是 Azure Data Factory？
- Azure Data Factory 中的整合執行階段
- 什麼是 Azure Synapse Analytics 中的專用 SQL 集區（先前稱為 SQL DW？
- Microsoft 機器學習 Studio （傳統版）
- 什麼是 機器學習 伺服器
- Pyomo 優化模型語言
- Bonmin 規劃求解
- 適用於 Spark 的 TFoCS 規劃求解
相關資源
相關零售指引：
- 零售產業的解決方案
- 將電子商務解決方案遷移至 Azure
- 使用 Azure Cosmos DB 進行零售的視覺搜尋
- 使用 Azure 和 Azure Stack Hub 部署以 AI 為基礎的客流量偵測解決方案
相關架構：