訓練與管理設備模型
設備模型採用受控制的生命週期。訓練只會建立待審查的候選版本，不會自動取代目前保護設備的生產判定。
先分清兩種模型產物
| 模型軌道 | 用途 | 目前訓練入口 | 生產控制方式 |
|---|---|---|---|
設備基線分布 (PDM_BASELINE_DISTRIBUTION) | 描述設備已觀察到的運轉分布，供基線比較使用。 | 預測性維護 > 模型控制台 | 模型控制台的基線晉升門檻 |
可執行異常模型 (PDM_ANOMALY_MODEL) | 對指定設備與 target 執行異常評分 artifact。 | 模型控制台 > 最佳化偵測、設備詳情或管理員 API | 指向已驗證不可變 artifact 的 ACTIVE assignment |
設備基線分布不是可執行異常模型。基線計算成功，不代表異常模型已實際執行；異常分數也不是故障機率。
入口與權限
| 任務 | 入口 | 權限 |
|---|---|---|
| 查看模型控制台 | /pdm/model-console | mlops.model.read 或 system.config |
| 查看模型使用詳情 | /ai-models/registry/:registryId | mlops.model.read 或 system.config |
| 訓練或晉升設備基線 | 模型控制台 | pdm:write |
| 啟動或取消異常偵測最佳化 | 模型控制台、設備詳情或 Platform AutoML API | mlops.model.write、pdm:write 或 system.config |
| 查看最佳化進度和結果 | 最佳化抽屜或 Platform AutoML API | mlops.model.read、pdm:read 或 system.config |
| 直接訓練單一可執行異常候選模型 | 管理員 API | pdm:write |
| 晉升或回復可執行 assignment | 管理員 API | pdm:write |
| 查看設備 Finding | /pdm/anomalies 與 Finding 詳情 | pdm:read |
標準「模型使用詳情」頁面是唯讀頁面。目前不提供 assignment 晉升或回復按鈕。
生命週期
SHADOW 只執行旁路比較，不會改變 alert、健康分數、advisory 或 Finding。ACTIVE 表示 assignment 具有生產選擇權，但仍要等到新鮮且成功的 runtime evidence，才能確認生產環境真的使用了該模型。
訓練統計設備基線
- 開啟 預測性維護 > 模型控制台。
- 找到目標設備並確認租戶、設備、target 與單位。
- 查看 readiness 結果與所有未滿足條件。
- 確認運轉狀態歷史和訓練時間窗正確。
- 在條件符合且具備
pdm:write時啟動訓練。 - 等待頁面更新，確認新版本和訓練時間。
| Readiness 結果 | 含義 | 下一步 |
|---|---|---|
| Eligible | 必要資料條件目前已滿足。 | 訓練後審查 SHADOW 候選版本。 |
| Missing criteria | 一項或多項可量測條件未滿足。 | 補齊有效運轉歷史或修復必要信號。 |
| Cannot determine | 服務無法作出判斷。 | 依頁面原因修復身份、資料或服務問題；不要誤報為歷史不足。 |
| Caveat | 可以訓練，但時間窗有已知限制。 | 記錄限制並納入發布審查。 |
訓練基線只會建立比較用候選版本，既有生產判定仍然有效。
最佳化異常偵測
最佳化流程會把受控、可解釋的候選方法，與任務啟動時正在生效的判定路徑進行比較。可從以下兩個入口開啟：
- 預測性維護 > 模型控制台 > 最佳化偵測；
- 設備詳情 > 最佳化偵測。
抽屜會先凍結正確的設備、測點和單位、建議訓練時間窗、資料截至時間以及目前判定依據。啟動前必須逐項確認；這些欄位屬於任務證據，不只是畫面資訊。
先處理資料準備問題
每個準備條件都會顯示實際值與要求值。任務遭到阻擋不等於模型訓練失敗，也不應被當成模型結果回報。
| 阻擋原因 | 處理方式 |
|---|---|
| 沒有有效振動來源，或有多個符合的綁定 | 在資料整合中修正設備與資料來源綁定。 |
| 測點缺少單位 | 在資料來源綁定中補上單位，不要在最佳化抽屜中猜測或換算。 |
| 無法判定 ISO 比較區帶 | 選取 補齊設備檔案，補上額定功率和軸承/支承方式後再返回。 |
| 運轉樣本、週數、跨度或連續性不足 | 繼續收集有效運轉狀態歷史或修復資料來源，不要以停機時段代替。 |
| 時序證據無法使用 | 恢復受治理的資料服務，再重新整理準備狀態。 |
| 沒有可用 Runner 或租戶佇列已滿 | 等候容量，或請管理員檢查私有化/staging Runner 池。重複點擊不會產生有效證據。 |
選擇受控搜尋預算
| 預算 | 適用情境 |
|---|---|
快速 (QUICK) | 日常設備審查的受控初步搜尋。 |
標準 (STANDARD) | 工程審查所需的較廣候選比較。 |
深入 (DEEP) | 已核准的專項調查，可使用更多時間和運算容量。 |
畫面只顯示租戶政策和 Runner 容量允許的預算。某個預算未顯示不代表瀏覽器異常。選擇較大預算也不保證一定產生勝出者或更準確的結果。
確認目標與準備證據後，選取 開始最佳化。任務會持久保存，關閉抽屜不會遺失；重新開啟同一設備即可還原最近任務。需要停止時使用 取消任務，已完成的證據仍會保留。
了解任務實際產出
任務會依序準備受治理訓練快照、比較候選方法、驗證時間窗、校驗 artifact，並在候選合格時註冊 SHADOW 模型。目前受控搜尋可比較 Isolation Forest 與統計基線候選，不會執行任意使用者程式碼。
| 結果 | 含義 | 下一步 |
|---|---|---|
NO_WINNER / 保留目前判定路徑 | 沒有候選同時通過可行性和實質改善門檻，因此未建立 SHADOW 模型。 | 保持目前路徑；如有資料限制先修復，只在證據或核准預算改變後重新執行。 |
| SHADOW 候選已就緒 | 某個候選通過門檻，並註冊為不可變 SHADOW assignment。 | 開啟模型證據進行審查。它仍不能改變客戶告警、健康分數、維護建議或 Finding。 |
| 失敗或逾時 | 畫面顯示安全原因，例如 Runner 無法使用、相依服務失敗、逾時或 artifact 無效。 | 先處理原因，不要把部分 trial 當成模型結果。 |
依四層閱讀訓練結果
完成後依下列順序閱讀抽屜：
- 結論：目前生產判據保持不變，或已產生 SHADOW 候選。
- 影響：現在允許發生哪些變化。SHADOW 結果不能改變客戶告警、健康分數、維護建議或 Finding。
- 證據：查看已凍結的目前生產判據、參與評估的方法、逐門檻結果、證據時窗、樣本數和資料截止時間。
- 行動：保持目前路徑、修復資料缺口、在有依據時更換預算重跑，或進入已登記 SHADOW 模型的證據頁。
候選比較表可以包含一列 目前生產判據。它與被比較候選使用相同的評估時窗、指標語意、單位和觀察數。每個候選會顯示門檻實際值和要求值，例如 涵蓋率：實際 68%；要求不低於 70%。缺失值顯示為 未評估，不會顯示為零。
| 證據 | 維運含義 |
|---|---|
| 涵蓋率 | 歷史運轉時窗中具備可用證據的比例；越高表示資料空洞越少。 |
| 穩定性 | 不同歷史折疊時窗中的告警負擔是否一致，不代表模型準確率。 |
| 告警負擔 | 該方法會標記為待複核的運轉樣本比例，不是每日告警數。 |
| 工況漂移 | 訓練時窗與驗證時窗的資料分布變化。 |
| SHADOW 差異 | 候選與目前判據給出不同判斷的樣本比例，不是錯誤率。 |
| 運算成本 | 每個受限樣本量的處理時間，只說明資源需求。 |
需要區分三種選擇結果：
- 沒有可行候選：沒有候選通過全部門檻。介面顯示每個候選未通過的項目，不會把其中一個標成「最佳候選」。
- 可行但沒有實質改善：介面標明實際與已凍結生產判據比較的候選，生產路徑保持不變。
- 已選擇候選：候選只登記為 SHADOW 供後續審查，不會自動晉升。
導入逐門檻證據之前建立的歷史任務仍可讀取。介面會顯示彙總解釋和明確的舊證據提示，不會在瀏覽器中重算門檻或猜測比較候選。
沒有經確認的故障標籤時，只能比較涵蓋率、穩定性、告警負擔、漂移、SHADOW 差異與運算成本。這些值說明行為和維運負擔，不能證明 accuracy、precision、recall 或故障機率。NO_WINNER 本身是有效且有價值的結果。
API 邊界
介面使用持久化 Platform AutoML 任務合約：
| Method | Endpoint | 用途 |
|---|---|---|
POST | /api/v1/platform/automl/jobs | 建立受治理的候選搜尋任務。 |
GET | /api/v1/platform/automl/jobs/{jobId} | 讀取持久化進度。 |
GET | /api/v1/platform/automl/jobs/{jobId}/outcome | 讀取 trial、選擇證據和下一步。 |
POST | /api/v1/platform/automl/jobs/{jobId}:cancel | 要求取消，但不刪除既有證據。 |
POST /api/v1/pdm/model-console/{equipmentId}/train-anomaly-model 仍保留為管理員直接建立單一可執行候選的整合介面；它不是多候選最佳化流程。
建立 SHADOW 候選後，開啟正確的 registry 記錄，確認設備與 target 綁定、不可變 artifact 驗證狀態及執行比較證據，再進行發布決策。所有介面和 API 操作都必須在目標租戶內執行；不可複用從其他租戶或環境複製的 assignment、job 或 registry 識別碼。
審查 SHADOW 行為
在模型使用詳情確認綁定、artifact 類型與驗證狀態、訓練時間窗、執行結果數量，以及 SHADOW disagreement。
Disagreement 只表示候選路徑與現行路徑在某個比較窗內結果不同，不代表任一方較準確。告警較少也可能表示漏掉重要狀況。發布決策必須搭配現場 Finding、維護結果、運轉情境和資料品質。
有意識地晉升
在 UI 晉升設備基線
符合條件的 SHADOW 基線可在模型控制台向具備 pdm:write 的使用者顯示晉升動作。後端會檢查候選版本是否可與目前判定比較，但不宣稱它比較準確。
透過 API 晉升可執行 assignment
| Method | Endpoint |
|---|---|
POST | /api/v1/pdm/model-console/assignments/{assignmentId}/promote |
晉升成功後，確認目標 assignment 為 ACTIVE、registry 版本為 PRODUCTION、舊的設備級生產 assignment 已退出、artifact 仍通過驗證，並等待新鮮的 ACTIVE runtime evidence。
頁面顯示 ACTIVE_AWAITING_EVIDENCE、STALE、FALLBACK、CONFLICT 或 ARTIFACT_UNAVAILABLE 時，不可宣稱模型已在生產中執行。
回復可執行 assignment
回復目前是管理員 API 流程：
| Method | Endpoint |
|---|---|
POST | /api/v1/pdm/model-console/assignments/{assignmentId}/rollback |
使用租戶範圍模型 API 回傳的 assignmentId，不要從 URL、模型名稱或另一個環境推測。回復後確認替代 assignment 已 ACTIVE、歷史狀態正確、新鮮執行証跡已出現，且被回復的 artifact 不再由 live assignment 引用。
回復不會刪除歷史 assignment、生命週期事件、執行証跡、Finding 或 feedback。
主要狀態
| 狀態 | 可以證明 | 不能證明 |
|---|---|---|
STAGING | Registry 版本是候選版本。 | 可以影響使用者結果。 |
SHADOW | Assignment 可進行非寫入比較。 | 它是生產模型。 |
ACTIVE | Assignment 具有生產選擇權。 | 最近一次執行成功。 |
PRODUCTION | Registry 版本在受治理範圍內是生產版本。 | 每次設備評估都使用了它。 |
RETIRED 或 ROLLED_BACK | 版本或 assignment 已成為歷史。 | 歷史稽核證據已刪除。 |
排解與驗證
| 現象 | 檢查項目 |
|---|---|
| 看不到訓練動作 | pdm:write、readiness、assignment 狀態，以及是否為 API-only 異常模型流程。 |
| 訓練被拒絕 | 設備身份、target、運轉歷史、時間窗覆蓋與回傳原因。 |
| 候選版本停留在 SHADOW | 這是發布決策前的預期安全狀態。 |
| 晉升成功但未顯示生產使用 | 檢查新鮮執行証跡、fallback 與 artifact 驗證。 |
| 找不到回復按鈕 | Assignment 回復目前由管理員 API 執行。 |
完成前請確認設備和 target 正確、兩種模型產物未混淆、訓練未暗中改變生產路徑、SHADOW 未影響使用者結果，且晉升或回復後已有新鮮 ACTIVE 執行証跡。