常見問題與解決方案

最常見的原因是複合索引鍵碰撞 – 如果兩個記錄共用相同的唯一識別符，其中一個會覆寫另一個。

如果資料映射中的篩選條件排除您預期看到的記錄，也會發生這種情況。

報告執行之間履行或移除的順序會從下一次重新整理中消失，但仍可能出現在前一天資料產生的例外狀況中。

在下一次資料重新整理之前，不會顯示新建立的訂單。

系統會自動篩選至產品主伺服器。只有存在於您產品主檔案中的產品才會包含在預測中。不過，如果大量百分比的輸入檔案超出範圍 （例如 50% 以上的資料列），這表示來源匯出需要收緊。

定期檢查您的產品涵蓋率。每次資料載入後，請確認您的銷售和預測輸入檔案中的產品百分比符合產品主控端。如果涵蓋範圍低於 80%，請調查來源匯出範圍是否已變更或產品主伺服器是否需要更新。

計劃輸入中的Out-of-scope產品可能會導致總計膨脹。如果您的 EDI 或 SIOP 檔案包含來自其他植物的產品，則彙總預測訊號會高於預期值。在載入之前，請確保將計劃輸入檔案篩選至與產品主控端相同的產品範圍。

檢查例外狀況的時間戳記 - 如果超過一天，建議可能會過時。

如果建議明顯錯誤 （例如，忽略圖表中可見的大型訂單），請使用拇指向下提供意見回饋，並向支援團隊報告特定例外狀況。

影響日期會顯示庫存問題何時開始 （例如，當缺貨開始或超額超過閾值）。

「執行者」日期應考量前置時間，以便您在問題具體化之前有時間採取行動。如果 Act By 等於影響日期，則可能無法納入前置時間 - 請向您的支援團隊回報此問題。

範圍內太多低容量/非作用中產品。具有稀疏、間歇性需求的產品對任何模型來說都難以超越簡單平均值。使用預先處理規則，將預測範圍限定為具有有意義的需求歷史記錄 （例如至少 6 個月非零需求） 的產品。

有關過時或受污染歷史記錄的訓練。如果您的訂單歷史記錄回溯多年，舊的需求模式可能無法反映目前的實際情況。請考慮預先處理規則，將訓練歷史記錄限制為最近 3-5 年，或使用標準化值取代異常期間 （例如 COVID)。

一次性訂單的需求尖峰。單一大型大量訂單可能會在訓練資料中建立錯誤的向上趨勢。使用預先處理規則，將異常每月需求值限制在追蹤平均值的倍數 （例如 5 倍）。

套用方向錯誤的共識規則。LLM 代理程式可能會錯誤解譯規則語言。「減少 27%」可套用為增加。一律透過比較特定產品和月份，根據基準驗證共識輸出。使用明確的乘法語言 (「乘以 0.725」)，而不是方向性語言 (「減少 27.5%」)。

模型會在成長期間進行訓練。如果近幾年顯示成長未繼續，則模型會推斷不再存在的趨勢。

共識規則正在向上堆疊調整。多個規則，每個規則都可以增加預測 （缺貨偏差、趨勢提升、季節性提升）。檢閱哪些規則處於作用中狀態，並檢查它們是否全部套用到相同的產品。

已刪除/停用的產品仍在範圍內。具有延遲需求且仍在預測中的產品會顯示系統性超額預測。

未整合外部預測訊號。如果您載入了計劃輸入 （例如 EDI 客戶預測、SIOP 生產計劃），但您的共識規則未套用它們，則預測預設為統計基準，這可能不會擷取規劃者看到的需求訊號。透過比較 ConsensusForecast 匯出與預測 （基準） 匯出，驗證共識規則是否實際修改輸出。如果它們相同，則不會觸發規則。

稀疏的 product×site 組合將彙總下移。如果您以 product×site 精細程度進行預測，但許多組合具有零或接近零的需求，則模型會產生非作用中組合的小型非零預測。這些不會增加太多個別值，而是將總預測整體拖曳到實際值以下。使用預先處理規則排除需求歷史記錄不足的組合，或在計畫輸入中使用條件式零填充，以明確表示非作用中組合「不預期需求」。

模型尚未擷取最近的成長趨勢。統計模型加權歷史資料。如果您的業務在最近幾個月大幅成長，但模型具有多年的較低數量歷史記錄，則將落後趨勢。隨著模型累積更多最近的資料，這通常會隨著時間而改善。在此期間，請考慮一項共識規則，該規則使用最近實際的結尾平均值作為外部預測週的下限。

Year-over-year季節性不相符。如果今年的需求模式與前幾年不同 （例如，較舊的季節性漸進測試、新產品推出），則模型可能會在差異期間預測不足。檢查低偏差是否集中在與前一年模式不同的特定週或月內。

外部訊號只會在短期內提供協助。如果您的共識規則在前幾週納入了客戶預測 (EDI)，則近期準確性將明顯更好，並在規則停止套用時下降。這是預期的 - 考慮使用混合方法擴展規則以涵蓋更多週 （例如，中期週的 50/50 外部訊號和基準混合）。

基準會在較長的時間範圍恢復為長期平均值。統計模型在較長的地平線中變得較不自信，並傾向於歷史平均值。如果最近的需求高於歷史平均值，則外部週會顯示偏差不足。這是模型行為，而不是組態問題。

需求波動會使更長的地平線本質上更困難。如果您的需求具有高week-to-week間變異性 （變異係數 > 0.5)，即使是完美的模型也會在較長的期間顯示高錯誤。專注於前 3-4 週的準確度評估，這是大多數操作的可行規劃時段。

外部訊號可能無法涵蓋足夠的產品。EDI 或客戶預測通常僅涵蓋產品目錄的一部分 （通常為 30–50%)。沒有外部訊號的產品仍會使用基準。檢查您的涵蓋率 — 如果低於 50%，對彙總準確性的影響將會受到限制。

外部訊號可能不夠準確，無法提供協助。在規則中使用外部預測之前，請獨立測量其準確性。如果其 WAPE 比基準更差，則將其納入會造成傷害，而不是提供協助。考慮將規則限制在特定網站或產品，其中外部訊號明顯較佳 （例如，容積加權 WAPE 低於 50%)。

外部訊號不會報告零。許多 EDI 系統只會為具有作用中訂單的產品傳送記錄，它們會省略需求為零的產品，而不是明確報告為零。如果您的共識規則顯示「當 EDI = 0 時，將預測設定為 0，」它永遠不會觸發，因為沒有零記錄。您需要為沒有外部訊號且沒有最近銷售歷史記錄的產品×網站組合，在預先處理中產生合成零記錄。

外部訊號準確度因地平線而異。客戶預測通常會在下週立即最準確 （基本上已確認的訂單） 並快速降級。直接在一週內使用外部訊號的規則可能會損害較長期限的準確性。考慮分層方法：第 1-3 週直接取代，第 4-6 週混合，僅基準為第 7 週以上。

較高優先順序的規則可能已覆寫規則。規則會依優先順序套用。稍後的規則可以復原較早的規則。檢查規則排序。

規則條件可能不符合任何產品。如果規則參考不在項目中繼資料中的產品屬性 （例如 product_group_id)，它會無提示地比對任何內容。

規則語言被錯誤解譯。LLM 代理程式會從自然語言產生程式碼。不明確的措辭可能會產生非預期的結果。請盡可能具體且合乎常值。使用確切的欄位名稱、明確乘數和明確條件。

聯結中的維度不相符。共識引擎會將計畫輸入加入維度資料欄 （產品 ID、網站 ID、日期） 的基準。如果資料欄名稱在基準和計劃輸入之間不同 （例如，基準使用 item_id，而 EDI 使用 product_id)，則聯結不會產生相符項目，且所有規則都屬於基準預設值。確認資料流程組態中的維度映射在兩個結構描述之間正確映射。

日期格式不相符。基準可以將日期儲存為 2026-03-02，而計劃輸入將其儲存為 2026-03-02T00：00：00.000Z。如果聯結需要完全相符，則時區感知和時區起始日期不相符。在加入之前，請檢查日期資料欄是否轉換為相同的格式。

計劃輸入未載入。確認您的計劃輸入檔案 (EDI、SIOP 等） 已成功擷取。檢查系統中的記錄計數 — 如果它們顯示計劃輸入的零資料列，則檔案可能無法載入。

共識 forecast_id 符合基準 forecast_id。如果兩個匯出共用相同的 forecast_id，則共識引擎會產生基準的直接複本，而無需處理。這表示系統層級問題 — 請聯絡您的支援團隊，並提供 forecast_id 和 demand_plan_run_id。

網站/產品篩選條件可能會參考錯誤的資料欄。如果您的規則顯示「套用至 【清單】 中的網站」，但產生的程式碼會檢查不存在或值不同的資料欄，則篩選條件可能會無提示地傳遞所有資料列。透過抽查一些不應受規則影響的特定產品來驗證。

規則優先順序可能會反轉。規則會套用為鏈結，稍後的規則會覆寫先前的規則。如果在特定規則後套用廣泛規則 （例如，「使用基準進行一切」) （例如，「針對這 50 個網站使用 EDI」)，則廣泛規則會復原特定規則。確保您的規則描述清楚說明優先順序。

新增四捨五入規則做為最終共識步驟。在所有其他共識規則之後套用的簡單「四捨五入至最接近的整數」規則將清除分數。低於 0.5 的值將四捨五入為零，這適用於極低需求的組合。

考慮四捨五入至操作數量。如果您的產品以標準套件大小 （例如 12 個案例、48 個貨盤） 運送，四捨五入到最接近的有效套件大小可能會改善預測的可用性和準確性。這需要您產品主伺服器的套件大小資料。與您的支援團隊共用 MOQ 或套件大小資料，以探索此選項。

檢查精細程度。產品在產品層級可能有 52 週的需求，但在任何個別產品×網站組合中只有 3 週。在 product×site 層級套用的最小歷史記錄閾值會排除大多數組合。請考慮改為在產品層級套用閾值，或大幅降低閾值。

部署前測試 。啟用預先處理規則之前，請計算有多少個 product×site 組合通過篩選條件與您目前的總數。如果排除超過 20%，則規則可能過於積極。從寬鬆閾值開始並逐漸收緊。