機器學習工程工作流程 是做什麼的？
使用此技能將模型工作轉化為生產級機器學習系統，具備清晰的數據合約、可重複的訓練、可衡量的質量關卡、可部署的工件以及操作監控。
何時啟用
- 規劃或審查生產級機器學習功能、模型更新、排名系統、推薦系統、分類器、嵌入工作流程或預測管道
- 將筆記本代碼轉換為可重複使用的訓練、評估、批次推理或在線推理管道
- 設計模型晉升條件、離線/在線評估、實驗追蹤或回滾路徑
- 調試由數據漂移、標籤洩漏、過時特徵、工件不匹配或訓練與服務邏輯不一致導致的故障
- 添加模型監控、金絲雀發布、影子流量或部署後質量檢查
範圍校準
僅使用適合您當前系統的部分。此技能適用於排名、搜尋、推薦、分類器、預測、嵌入、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：用於服務、秘密、容器和生產環境強化
重用 SWE 表面
不要將 MLE 視為與軟體工程分離。大多數 ECC SWE 工作流程直接應用於機器學習系統，通常具有更嚴格的故障模式：
推薦的 minimal --with capability:machine-learning 安裝會在此技能旁邊保留核心代理表面。對於僅技能或代理受限的工具，請在目標支援代理的情況下將 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 | 在實現之前測試特徵轉換、分割邏輯、指標計算、工件加載和推理模式 |
code-reviewer / mle-reviewer | 審查代碼質量以及 ML 特定的洩漏、可重現性、晉升和監控風險 |
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 | 為審查打包 MLE 更改，具有清晰的範圍、排除生成的工件以及可重複的測試證據 |
strategic-compact / dmux-workflows | 將較長的 ML 工作拆分為並行軌道：數據合約、評估框架、服務路徑、監控和文檔 |
十個 MLE 任務模擬
在規劃或審查 MLE 工作時，使用這些模擬作為覆蓋率檢查。一個強大的 MLE 工作流程應將每個任務轉化為明確的合約、可重用的 SWE 表面、自動化證據和可審查的工件。
| ID | 常見 MLE 任務 | 簡化的 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 描述，並且足夠精確，以便其他工程師可以挑戰其中的權衡。
目標：
誰在乎：
決策所有者：
模型改變的用戶或系統操作：
成功指標：
護欄指標：
錯誤預算：
不可接受的錯誤：
可接受的錯誤：
假設：
約束：
標籤和數據快照：
基準：
候選信號：
閾值或配置計劃：
評估切片：
已知風險：
下一次實驗：
回滾或備用：
此壓縮是 MLE 對應於強大 SWE 設計說明的內容。它可以防止團隊優化一個沒有人信任的指標、添加無法解決實際錯誤模式的特徵，或者發布複雜性卻沒有回滾方案。
決策大腦
每當任務不明確、影響重大或指標密集時，使用此循環：
- 從決策開始，而不是模型。指明改變下游行為的操作。
- 說出誰在乎以及為什麼。不同的利益相關者為假陽性、假陰性、延遲、計算開銷、不透明性或錯失機會付出不同的成本。
- 將模糊性轉化為假設。問什麼信號可以區分結果，什麼證據可以反駁它，以及什麼簡單的基準線應該難以被擊敗。
- 在發明自定義系統之前，研究先前藝術或附近的已知問題。
- 使用
(機率，置信度) x (成本，嚴重性，重要性，影響)對選擇進行評分。 - 考慮對抗行為、激勵、選擇性披露、分佈轉移和反饋循環。
- 偏好能減少最重要錯誤的最簡單更改。簡單不是懶惰；它是在保持迭代速度的同時最小化錯誤的一種方式。
- 捕獲決策、證據、反對論點和下一個可逆步驟。
指標與錯誤經濟學
根據失敗成本選擇指標，而不是習慣：
- 儘早使用混淆矩陣，以便團隊可以討論具體的假陽性和假陰性，而不是抽象的準確率。
- 當錯誤正面決策的成本佔主導地位時，偏好精確率。
- 當錯過正面結果的成本佔主導地位時，偏好召回率。
- 僅在精確率/召回率的權衡真正平衡且可解釋時才使用 F1。
- 當排序質量比單一閾值更重要時，使用 AUC 或排名指標。
- 將延遲、吞吐量、記憶體和成本作為一流指標進行追蹤，因為它們決定了可行的模型複雜度。
- 在慶祝離線收益之前，與基準線和當前生產模型進行比較。
- 將真實世界的反饋信號視為具有偏差、滯後和覆蓋率差距的延遲標籤；未經分析不要將其視為真實情況。
每個指標選擇都應說明它使哪個錯誤變得更便宜、使哪個錯誤更可能發生，以及誰承擔該成本。
數據與特徵假設
特徵應來源於關於區分能力的理論：
- 文本、類別欄位、數值歷史、圖形關係、新近度、頻率和聚合值是候選信號族，而不是自動特徵。
- 對於每個特徵族，說明為什麼它應該區分結果以及它可能如何洩漏未來信息。
- 對於嘈雜的標籤，考慮裁決、標籤置信度、軟目標或置信度加權。
- 對於類別不平衡，比較加權損失、重採樣、閾值移動和校準決策規則。
- 對於缺失值，決定缺失是否具有信息性、可以插補，還是放棄的理由。
- 對於異常值，決定是剪裁、分桶、調查還是將其保留為罕見但重要的信號。
- 對於相關特徵，檢查它們是冗餘的、不穩定的，還是作為不可用未來狀態的代理。
在錯誤分析顯示基準線因某個原因失敗，而額外的信號或容量可以合理修復之前，不要增加模型複雜度。
錯誤分析循環
在每次基準線、訓練運行、閾值更改或配置更改之後：
- 將錯誤拆分為假陽性、假陰性、棄權、低置信度案例和系統故障。
- 根據共同特徵對錯誤進行聚類：語言、實體類型、來源、時間、地理位置、設備、稀疏性、新近度、特徵新鮮度、標籤來源或模型版本。
- 將模型錯誤與數據錯誤分開...