机器学习工程工作流
使用此技能，将模型工作转化为生产级 ML 系统，具备清晰的数据契约、可重复的训练、可衡量的质量门禁、可部署的工件以及运营监控。
何时激活
- 规划或审查生产级 ML 功能、模型更新、排名系统、推荐系统、分类器、嵌入工作流或预测管道
- 将 Notebook 代码转化为可重用的训练、评估、批量推理或在线推理管道
- 设计模型提升标准、离线/在线评估、实验追踪或回滚路径
- 调试由数据漂移、标签泄漏、陈旧特征、工件不匹配或训练与推理逻辑不一致导致的故障
- 添加模型监控、金丝雀发布、影子流量或部署后质量检查
范围校准
只使用与你当前系统匹配的环节。此技能适用于排名、搜索、推荐、分类器、预测、嵌入、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 工作流直接适用于 ML 系统，通常具有更严格的失败模式：
推荐的 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、不稳定的评估、缺失的测试夹具以及环境特定的模型或依赖失败 |
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 | 检查模型工件、Notebook、提示、数据集和日志中是否存在密钥、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 描述，并足够精确以使其他工程师能够挑战其中的权衡。
目标：
谁在乎：
决策所有者：
模型改变的用户或系统行为：
成功指标：
护栏指标：
错误预算：
不可接受的错误：
可接受的错误：
假设：
约束：
标签和数据快照：
基线：
候选信号：
阈值或配置计划：
评估切片：
已知风险：
下一个实验：
回滚或备选方案：
这个精简是强大的 SWE 设计说明的 MLE 等价物。它可以防止团队优化一个没人相信的指标、添加无法解决实际错误模式的特征，或者在没有回滚的情况下发布复杂性。
决策大脑
每当任务模糊、影响重大或指标繁重时，使用此循环：
- 从决策开始，而不是模型。说出改变下游行为的动作。
- 说出谁在乎以及为什么。不同的利益相关者为假阳性、假阴性、延迟、计算开销、不透明性或错失机会支付不同的成本。
- 将模糊性转化为假设。问什么信号可以分离结果，什么证据可以反驳它，以及什么简单基线应该难以击败。
- 在发明定制系统之前，研究先前成果或附近已知的问题。
- 用(概率, 置信度) x (成本, 严重性, 重要性, 影响) 对选择进行评分。
- 考虑对抗行为、激励机制、选择性披露、分布偏移和反馈循环。
- 优先选择能减少最重要错误的最简单变更。简单不是懒惰；它是在保持迭代速度的同时最小化失误的方法。
- 捕获决策、证据、反驳论点和下一个可逆步骤。
指标和错误经济学
根据失败成本选择指标，而不是凭习惯：
- 尽早使用混淆矩阵，以便团队可以讨论具体的假阳性和假阴性，而不是抽象的准确率。
- 当错误阳性决策的成本占主导地位时，倾向于精确率。
- 当遗漏阳性的成本占主导地位时，倾向于召回率。
- 仅当精确率/召回率的权衡真正平衡且可解释时，才使用 F1。
- 当排序质量比单个阈值更重要时，使用 AUC 或排名指标。
- 将延迟、吞吐量、内存和成本作为第一类指标进行跟踪，因为它们决定了可行的模型复杂度。
- 在庆祝离线提升之前，与基线和当前生产模型进行比较。
- 将真实世界的反馈信号视为具有偏差、滞后和覆盖差距的延迟标签；未经分析不要将其视为真实情况。
每个指标选择都应说明它使哪种错误变得代价更低，使哪种错误更可能发生，以及谁承担该成本。
数据和特征假设
特征应来自分离理论：
- 文本、分类字段、数值历史、图关系、新旧程度、频率和聚合值是候选信号族，而不是自动特征。
- 对于每个特征族，说明它为何能分离结果以及它如何可能泄露未来信息。
- 对于噪声标签，考虑裁决、标签置信度、软目标或置信度加权。
- 对于类别不平衡，比较加权损失、重采样、阈值移动和校准决策规则。
- 对于缺失值，决定缺失信息是有信息量、可插补还是弃权的理由。
- 对于异常值，决定是裁剪、分桶、调查还是保留为罕见但重要的信号。
- 对于相关特征，检查它们是否是冗余的、不稳定的，或者是不可用未来状态的代理。
在错误分析表明基线因额外信号或容量可能修复的原因而失败之前，不要增加模型复杂度。
错误分析循环
每次基线、训练运行、阈值更改或配置更改后：
- 将错误拆分为假阳性、假阴性、弃权、低置信度案例和系统故障。
- 按共享特征对错误进行聚类：语言、实体类型、来源、时间、地理位置、设备、稀疏性、新旧程度、特征新鲜度、标签来源或模型版本。
- 将模型错误与数据错误、模式错误、标签错误和特征错误分开。
- 对于每个聚类，询问模型中的哪些遗漏概念或数据中的哪些噪声结构会导致该模式。
- 确定下一个实验：特征工程、数据质量、重采样、标签改进、模型架构、阈值优化或扩展监控和回滚。