mle-workflow

Machine Learning Engineering Workflow（機器學習工程工作流程）

使用此 Skill 將模型研發工作轉化為具備明確資料合約、可重現訓練、可量化品質關卡（Quality Gates）、可部署構件（Artifacts）以及維運監控的正式環境 ML 系統。

何時啟用

• 規劃或審查正式環境的 ML 功能、模型更新、排序系統、推薦系統、分類器、Embedding 工作流程或預測管線時
• 將 Notebook 程式碼重構為可重複使用的訓練、評估、批次推論（Batch Inference）或即時推論（Online Inference）管線時
• 設計模型晉級標準、離線/線上評估、實驗追蹤或回滾機制時
• 排查因資料漂移（Data Drift）、標籤洩漏（Label Leakage）、特徵過期、構件不匹配或訓練與推論邏輯不一致所導致的故障時
• 建立模型監控、金絲雀部署（Canary Rollout）、影子流量（Shadow Traffic）或上線後品質檢查時

範圍校準

僅使用適合眼前系統的範疇。此 Skill 適用於排序、搜尋、推薦、分類器、預測、Embedding、LLM 工作流程、異常檢測和批次分析，但不應將單一架構強加於所有情境。

• 請勿假設每個模型都有監督式標籤、線上服務、Feature Store、PyTorch、GPU、人工審查、A/B 測試或即時回饋。
• 當資料合約、基準線、評估腳本和回滾說明已足以讓變更具備可審查性時，切勿加入過於繁重的 MLOps 機制。
• 當專案缺乏標籤、延遲結果（Delayed Outcomes）、切片定義、正式環境流量或監控負責人時，請務必明確標示出相關假設。
• 將範例視為可替換的腳手架。請用專案原生的同等工具來替換指標、服務模式、資料儲存庫和發布機制。

相關 Skills

• python-patterns 與 python-testing：用於 Python 實作與 pytest 測試覆蓋
• pytorch-patterns：用於深度學習模型、Data Loader、設備處理與訓練迴圈
• eval-harness 與 ai-regression-testing：用於晉級關卡與 Agent 輔助的回歸測試
• database-migrations、postgres-patterns 與 clickhouse-io：用於資料儲存與分析層
• deployment-patterns、docker-patterns 與 security-review：用於服務推論、密鑰管理、容器化與正式環境強化

重用軟體工程基礎設施

切勿將 MLE 視為獨立於軟體工程之外的領域。大部分 ECC SWE 工作流程皆可直接套用於 ML 系統，且往往伴隨著更嚴格的失效模式：

建議安裝 minimal --with capability:machine-learning，以在此 Skill 的基礎上保留核心 Agent 功能。對於僅使用 Skill 或限制 Agent 權限的環境，可在目標支援 Agent 時將 skill:mle-workflow 與 agent:mle-reviewer 搭配使用。

SWE 工具面	MLE 應用情境
product-capability / architecture-decision-records	將模型工作轉化為明確的產品合約，並記錄不可逆的資料、模型與發布決策
repo-scan / codebase-onboarding / code-tour	在引進平行 ML 堆疊之前，先找出既有的訓練、特徵、推論服務、評估與監控路徑
plan / feature-dev	將模型變更劃定為具備資料、評估、推論服務與回滾階段的產品功能
tdd-workflow / python-testing	在實作前先測試特徵轉換、切分邏輯、指標計算、構件載入與推論 Schema
code-reviewer / mle-reviewer	審查程式碼品質以及 ML 特有的洩漏、可重現性、晉級與監控風險
build-fix / pr-test-analyzer	診斷損壞的 CI、不穩定的評估、缺失的 Fixture 以及特定環境的模型或相依套件故障
quality-gate / test-coverage	要求為轉換、指標、推論合約、晉級關卡與回滾行為提供自動化驗證證據
eval-harness / verification-loop	將離線指標、切片檢查、延遲預算與回滾演練轉化為可重複執行的關卡
ai-regression-testing	將每一個正式環境 Bug 保留為回歸測試案例：缺失特徵、過期標籤、不良構件、Schema 漂移或推論不吻合
api-design / backend-patterns	設計預測 API、批次任務、等冪再訓練端點與回應外殼（Response Envelope）
database-migrations / postgres-patterns / clickhouse-io	進行標籤、特徵快照、預測日誌、實驗指標與漂移分析的版本控制
deployment-patterns / docker-patterns	打包具備健康檢查、資源限制與回滾機制的可重現訓練與推論服務 Docker 映像檔
canary-watch / dashboard-builder	透過模型版本、切片、漂移、延遲、成本與延遲標籤儀表板，讓發布健康度視覺化
security-review / security-scan	檢查模型構件、Notebook、Prompt、資料集與日誌，避免密鑰外洩、PII 洩漏、不安全的反序列化與供應鏈風險
e2e-testing / browser-qa / accessibility	測試消費預測結果的關鍵產品流程，包含可解釋性與降級（Fallback）UI 狀態
benchmark / performance-optimizer	量測吞吐量、P95 延遲、記憶體、GPU 利用率以及每次預測或再訓練的成本
cost-aware-llm-pipeline / token-budget-advisor	依品質、延遲與預算來路由 LLM/Embedding 工作負載，而非預設使用最大的模型
documentation-lookup / search-first	在撰寫程式碼前，先查驗用於模型服務、Feature Store、向量資料庫與評估工具的最新函式庫行為
git-workflow / github-ops / opensource-pipeline	以清晰的範圍劃分、排除產生的構件以及可重現的測試證據，打包 MLE 變更以供審查
strategic-compact / dmux-workflows	將耗時的 ML 工作拆分為平行軌道：資料合約、評估工具、推論服務路徑、監控與文件

十個 MLE 任務模擬

在規劃或審查 MLE 工作時，請使用這些模擬作為覆蓋率檢查。優秀的 MLE 工作流程應能將每個任務簡化為明確的合約、可重用的 SWE 工具面、自動化證據以及可審查的構件。

ID	常見 MLE 任務	精簡 ECC 路徑	必要輸出	涵蓋的管線範疇
MLE-01	定義模糊的預測、排序、推薦、分類器、Embedding 或預測能力	product-capability, plan, architecture-decision-records, mle-workflow	迭代協定（Iteration Compact）：載明利害關係人、決策擁有者、成功指標、不可接受的錯誤、假設、限制條件與首次實驗	產品合約、利害關係人損失、風險、發布
MLE-02	定義指標目標、標籤、資料源與容錯預算	repo-scan, database-reviewer, database-migrations, postgres-patterns, clickhouse-io	資料與指標合約：包含實體粒度、標籤時間點、標籤信心度、特徵時間點、時間點 Merge（Point-in-time join）、切分策略與資料集快照	資料合約、指標設計、洩漏、可重現性
MLE-03	在增加複雜度之前，先建立基準模型與評分路徑	tdd-workflow, python-testing, python-patterns, code-reviewer	基準評分器：附帶混淆矩陣（Confusion Matrix）、校準說明、延遲/成本估算、已知弱點以及評分形狀與確定性的測試	基準線、評分、測試、推論服務一致性
MLE-04	根據「什麼能區分結果」的假說生成特徵	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	特徵計劃與轉換模組：涵蓋訊號來源、缺失值、異常值、相關性、洩漏檢查與訓練/推論等價性	特徵管線、洩漏、訓練、構件
MLE-05	在權衡取捨下微調門檻、設定與模型複雜度	eval-harness, ai-regression-testing, quality-gate, test-coverage	門檻/設定報告：比較精確度（Precision）、召回率（Recall）、F1、AUC、校準度、分組切片、延遲、成本、複雜度與可接受的錯誤類型	評估、門檻、晉級、回歸
MLE-06	進行錯誤分析並將失誤轉化為下一次實驗	eval-harness, ai-regression-testing, mle-reviewer, silent-failure-hunter	錯誤群集報告：針對偽陽性（False Positive）、偽陰性（False Negative）、模糊標籤、過期特徵、缺失訊號與 Bug 追蹤，並記錄經驗教訓	錯誤分析、Bug 追蹤、迭代、回歸
MLE-07	打包用於批次或線上推論的模型構件	api-design, backend-patterns, security-review, security-scan	具版本的構件套件：包含預處理、設定、相依性限制、Schema 驗證、安全載入與 PII 安全日誌	構件、安全性、推論合約
MLE-08	發布線上推論服務或帶有回饋擷取的批次評分	api-design, backend-patterns, e2e-testing, browser-qa, accessibility	預測端點或批次任務：具備回應外殼、逾時、批次化、降級備援、模型版本、信心度、回饋日誌與產品流程測試	推論服務、批次推論、降級備援、使用者工作流程
MLE-09	透過影子流量、金絲雀發布、A/B 測試或回滾來發布模型	canary-watch, dashboard-builder, verification-loop, performance-optimizer	發布計劃：載明流量分流、儀表板、P95 延遲、成本、品質護欄、回滾構件與回滾觸發條件	部署、金絲雀發布、回滾
MLE-10	上線後維運、除錯與更新正式環境模型	silent-failure-hunter, dashboard-builder, mle-reviewer, doc-updater, github-ops	觀測日誌與更新計劃：包含漂移檢查、延遲標籤健康度、告警負責人、Runbook 更新、再訓練標準與 PR 驗證證據	監控、事件應變、再訓練

Iteration Compact（迭代協定）

在動手修改模型程式碼之前，先將工作壓縮為一份可審查的構件。這份文件應足夠簡短以放入 PR 說明中，且足夠精準以供其他工程師對權衡取捨提出質疑。

Goal:
Who cares:
Decision owner:
User or system action changed by the model:
Success metric:
Guardrail metrics:
Mistake budget:
Unacceptable mistakes:
Acceptable mistakes:
Assumptions:
Constraints:
Labels and data snapshot:
Baseline:
Candidate signals:
Threshold or config plan:
Eval slices:
Known risks:
Next experiment:
Rollback or fallback:

這份協定是 MLE 領域中相當於優良 SWE 設計說明（Design Note）的存在。它能避免團隊優化無人信任的指標、添加無法解決真正錯誤模式的特徵，或是在沒有回滾機制的情況下發布複雜系統。

Decision Brain（決策大腦）

每當任務模糊、影響重大或高度依賴指標時，請使用此循環：

1. 從「決策」出發，而非模型。明確指出會改變下游行為的操作。
2. 指出誰在乎以及為什麼。不同的利害關係人對於偽陽性、偽陰性、延遲、運算成本、不透明度或錯失機會所付出的代價各不相同。
3. 將模糊不清轉化為假設。詢問什麼訊號能區分結果、什麼證據能反駁它，以及什麼簡單的基準線應該很難被超越。
4. 在發明自訂系統之前，先研究先前的作法或附近已知的問題。
5. 使用 (機率, 信心度) x (成本, 嚴重性, 重要性, 影響度) 為選項打分。
6. 考量對抗行為、誘因機制、選擇性揭露、分佈偏移（Distribution Shift）與回饋循環。
7. 優先選擇能減少最重要錯誤的最簡單變更。簡單並非怠惰，而是在保留迭代速度的同時降低犯下大錯的方法。
8. 記錄決策、證據、反對意見與下一個可逆的步驟。

Metric and Mistake Economics（指標與錯誤經濟學）

根據失敗成本選擇指標，而非出於習慣：

• 儘早使用混淆矩陣，使團隊能討論具體的偽陽性與偽...

<!-- truncated for translation batch; full body continues in source -->