機器學習工程工作流程 是做什麼的？
使用此技能將模型工作轉化為具有清晰資料合約、可重複訓練、可衡量品質關卡、可部署產出物和營運監控的生產級機器學習系統。
使用時機
- 規劃或審查生產級機器學習功能、模型更新、排名系統、推薦系統、分類器、嵌入工作流程或預測管線
- 將筆記本程式碼轉換為可重複使用的訓練、評估、批次推論或在線推論管線
- 設計模型提升標準、離線/在線評估、實驗追蹤或回滾路徑
- 偵錯由資料漂移、標籤洩漏、過時特徵、產出物不匹配或不一致的訓練與服務邏輯導致的失敗
- 加入模型監控、金絲雀發布、影子流量或部署後品質檢查
範圍校準
僅使用適合當前系統的通道。此技能適用於排名、搜尋、推薦系統、分類器、預測模型、嵌入、LLM工作流程、異常檢測和批次分析，但不應強制所有情況使用同一種架構。
- 不要假設每個模型都有監督式標籤、線上服務、特徵儲存、PyTorch、GPU、人工審查、A/B測試或即時回饋。
- 當資料合約、基準線、評估腳本和回滾說明已足以使變更可審查時，不要添加過重的MLOps機制。
- 當專案缺少標籤、延遲結果、切片定義、生產流量或監控擁有權時，請明確陳述假設。
- 將範例視為可互換的框架。將指標、服務模式、資料儲存和發布機制替換為專案原生等效項。
相關技能
python-patterns和python-testing：用於Python實作和pytest覆蓋率pytorch-patterns：用於深度學習模型、資料載入器、設備處理和訓練循環eval-harness和ai-regression-testing：用於提升關卡和代理輔助的回歸檢查database-migrations、postgres-patterns和clickhouse-io：用於資料儲存和分析表面deployment-patterns、docker-patterns和security-review：用於服務、機密、容器和生產環境強化
重複使用軟體工程表面
不要將機器學習工程與軟體工程分開處理。大多數ECC SWE工作流程直接適用於機器學習系統，通常具有更嚴格的故障模式：
建議的 minimal --with capability:machine-learning 安裝可在使用此技能時保留核心代理程式表面。對於僅技能或代理受限的框架，請在目標支援代理程式的地方將 skill:mle-workflow 與 agent:mle-reviewer 配對。
| SWE 表面 | 機器學習工程用途 |
|---|---|
product-capability / architecture-decision-records | 將模型工作轉化為明確的產品合約，並記錄不可逆的資料、模型和發布選擇 |
repo-scan / codebase-onboarding / code-tour | 在引入平行機器學習堆疊之前，先找到現有的訓練、特徵、服務、評估和監控路徑 |
plan / feature-dev | 將模型變更範圍界定為具有資料、評估、服務和回滾階段的產品功能 |
tdd-workflow / python-testing | 在實作前測試特徵轉換、分割邏輯、指標計算、產出物載入和推論架構 |
code-reviewer / mle-reviewer | 審查程式碼品質以及機器學習特定的洩漏、可重現性、提升和監控風險 |
build-fix / pr-test-analyzer | 診斷損壞的CI、不穩定的評估、缺失的測試fixture以及環境特定的模型或相依性失敗 |
quality-gate / test-coverage | 要求轉換、指標、推論合約、提升關卡和回滾行為的自動化證據 |
eval-harness / verification-loop | 將離線指標、切片檢查、延遲預算和回滾演練轉化為可重複的關卡 |
ai-regression-testing | 將每個生產錯誤保留為回歸案例：缺失的特徵、過時的標籤、錯誤的產出物、架構漂移或服務不匹配 |
api-design / backend-patterns | 設計預測API、批次工作、冪等重新訓練端點和回應封裝 |
database-migrations / postgres-patterns / clickhouse-io | 版本化標籤、特徵快照、預測日誌、實驗指標和漂移分析 |
deployment-patterns / docker-patterns | 打包可重複的訓練和服務映像檔，包含健康檢查、資源限制和回滾 |
canary-watch / dashboard-builder | 透過模型版本、切片、漂移、延遲、成本和延遲標籤儀表板，使發布健康狀況可見 |
security-review / security-scan | 檢查模型產出物、筆記本、提示、資料集和日誌中是否存在機密、PII、不安全的反序列化和供應鏈風險 |
e2e-testing / browser-qa / accessibility | 測試使用預測結果的關鍵產品流程，包括可解釋性和備援UI狀態 |
benchmark / performance-optimizer | 衡量吞吐量、p95延遲、記憶體、GPU使用率以及每次預測或重新訓練的成本 |
cost-aware-llm-pipeline / token-budget-advisor | 根據品質、延遲和預算來路由LLM/嵌入工作負載，而不是預設使用最大的模型 |
documentation-lookup / search-first | 在編寫程式碼之前，驗證模型服務、特徵儲存、向量資料庫和評估工具當前的函式庫行為 |
git-workflow / github-ops / opensource-pipeline | 打包機器學習工程變更以供審查，具有清晰的範圍、排除產生的產出物，以及可重複的測試證據 |
strategic-compact / dmux-workflows | 將冗長的機器學習工作拆分為平行軌道：資料合約、評估框架、服務路徑、監控和文件 |
十項機器學習工程任務模擬
在規劃或審查機器學習工程工作時，使用這些模擬作為覆蓋率檢查。一個強大的ML工程工作流程應將每個任務減少為明確的合約、可重用的SWE表面、自動化證據和可審查的產出物。
| ID | 常見機器學習工程任務 | 簡化的ECC路徑 | 所需輸出 | 涵蓋的管線通道 |
|---|---|---|---|---|
| MLE-01 | 框架一個模糊的預測、排名、推薦、分類、嵌入或預測能力 | product-capability、plan、architecture-decision-records、mle-workflow | 反覆運算緊湊命名（誰在乎、決策擁有者、成功指標、不可接受的錯誤、假設、約束和首次實驗） | 產品合約、利害關係人損失、風險、發布 |
| MLE-02 | 定義指標目標、標籤、資料來源和錯誤預算 | repo-scan、database-reviewer、database-migrations、postgres-patterns、clickhouse-io | 資料和指標合約，包含實體粒度、標籤時機、標籤信心、特徵時機、即時點連接、分割策略和資料集快照 | 資料合約、指標設計、洩漏、可重現性 |
| MLE-03 | 在增加複雜性之前建立基準模型和評分路徑 | tdd-workflow、python-testing、python-patterns、code-reviewer | 具有混淆矩陣、校準說明、延遲/成本估計、已知弱點以及分數形狀和確定性測試的基準評分器 | 基準線、評分、測試、服務一致性 |
| MLE-04 | 從關於什麼能區分結果的假設中生成特徵 | python-patterns、pytorch-patterns、docker-patterns、deployment-patterns | 特徵計畫和轉換模組，涵蓋信號源、缺失值、異常值、相關性、洩漏檢查以及訓練/服務等效性 | 特徵管線、洩漏、訓練、產出物 |
| MLE-05 | 在權衡下調整閾值、配置和模型複雜度 | eval-harness、ai-regression-testing、quality-gate、test-coverage | 閾值/配置報告，比較精確度、召回率、F1、AUC、校準、群組切片、延遲、成本、複雜度和可接受的錯誤類別 | 評估、閾值、提升、回歸 |
| MLE-06 | 運行錯誤分析並將錯誤轉化為下一個實驗 | eval-harness、ai-regression-testing、mle-reviewer、silent-failure-hunter | 針對假陽性、假陰性、模糊標籤、過時特徵、缺失信號和錯誤追蹤的錯誤叢集報告，並記錄經驗教訓 | 錯誤分析、錯誤追蹤、迭代、回歸 |
| MLE-07 | 為批次或線上推論打包模型產出物 | api-design、backend-patterns、security-review、security-scan | 帶版本管理的產出物套件，包含預處理、配置、相依性約束、架構驗證、安全載入和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 | 觀察記錄和更新計畫，包含漂移檢查、延遲標籤健康狀況、警報擁有者、操作手冊更新、重新訓練標準和PR證據 | 監控、事件回應、重新訓練 |
反覆運算緊湊
在接觸模型程式碼之前，將工作壓縮為一個可審查的產出物。它應該足夠簡短以放入PR描述中，並且足夠精確以便其他工程師可以挑戰其中的權衡。
目標：
誰在乎：
決策擁有者：
模型改變的使用者或系統動作：
成功指標：
護欄指標：
錯誤預算：
不可接受的錯誤：
可接受的錯誤：
假設：
約束：
標籤和資料快照：
基準線：
候選信號：
閾值或配置計畫：
評估切片：
已知風險：
下一個實驗：
回滾或備援：
這個緊湊摘要相當於一個強大的SWE設計說明。它使團隊免於最佳化一個無人信任的指標、添加無法解決實際錯誤模式的特性，或在沒有回滾計畫的情況下發布複雜性。
決策大腦
每當任務模糊、影響重大或指標密集時，使用此循環：
- 從決策而不是模型開始。命名會改變下游行為的動作。
- 命名誰在乎以及為什麼。不同的利害關係人為假陽性、假陰性、延遲、計算成本、不透明性或錯失機會付出不同的代價。
- 將模糊性轉化為假設。詢問什麼信號可以區分結果，什麼證據可以反駁它，以及什麼簡單的基準線應該難以被擊敗。
- 在發明專屬系統之前，研究先前技術或附近已知的問題。
- 使用
(機率, 信心) x (成本, 嚴重性, 重要性, 影響)對選擇進行評分。 - 考慮對抗性行為、誘因、選擇性揭露、分佈轉移和反饋循環。
- 偏好能減少最重要錯誤的最簡單變更。簡單不是懶惰；它是在保持迭代速度的同時最大限度減少重大失誤的方法。
- 記錄決策、證據、反對論點和下一個可逆步驟。
指標和錯誤經濟學
根據失敗成本而非習慣來選擇指標：
- 及早使用混淆矩陣，以便團隊可以討論具體的假陽性和假陰性，而不是抽象的準確率。
- 當錯誤陽性決策的成本占主導地位時，優先考慮精確度。
- 當錯過陽性結果的成本占主導地位時，優先考慮召回率。
- 僅在精確度/召回率的權衡確實平衡且可解釋時，才使用F1分數。
- 當排序品質比單一閾值更重要時，使用AUC或排名指標。
- 將延遲、吞吐量、記憶體和成本視為一等指標，因為它們塑造了可行的模型複雜度。
- 在慶祝離線收益之前，與基準線和當前的生產模型進行比較。
- 將現實世界的回饋信號視為具有偏差、延遲和覆蓋率差距的延遲標籤；未經分析，不要將其視為真實情況。
每個指標選擇都應說明它使哪種錯誤變得更便宜、哪種錯誤變得更有可能發生，以及誰承擔該成本。
資料和特徵假設
特徵應源於區分理論：
- 文字、分類欄位、數值歷史紀錄、圖形關係、最近性、頻率和聚合值是候選信號系列，而非自動特徵。
- 對於每個特徵系列，說明為什麼它應該區分結果，以及它如何可能洩漏未來資訊。
- 對於有雜訊的標籤，考慮裁決、標籤信心、軟目標或信心加權。
- 對於類別不平衡，比較加權損失、重新取樣、閾值移動和校準決策規則。
- 對於缺失值，決定缺失是否具有資訊性、可插補，還是應放棄的原因。
- 對於異常值，決定是否進行裁剪、分桶、調查，或將其保留為罕見但重要的信號。
- 對於相關特徵，檢查它們是否冗餘、不穩定，或是不可用未來狀態的代理變數。
在錯誤分析顯示基準線因附加信號或容量合理地無法解決的原因而失敗之前，不要增加模型複雜度。
錯誤分析循環
在每次基準線、訓練執行、閾值變更或配置變更之後：
- 將錯誤分為假陽性、假陰性、棄權、低信心案例和系統故障。
- 根據共同特徵對錯誤進行分群：語言、實體類型、來源、時間、地理、設備、稀疏性、最近性、特徵新鮮度、標籤來源或模型版本。
- 將模型錯誤與資料錯誤分開...
[截斷以供翻譯]