mle-workflow

Fluxo de Trabalho de Engenharia de Machine Learning

Use este skill para transformar o trabalho com modelos em um sistema de ML de produção com contratos de dados claros, treinamento repetível, gateways de qualidade mensuráveis, artefatos implantáveis e monitoramento operacional.

Quando Ativar

• Planejando ou revisando um recurso de ML de produção, atualização de modelo, sistema de ranqueamento, recomendador, classificador, fluxo de embeddings ou pipeline de previsão
• Convertendo código de notebook em um pipeline reutilizável de treinamento, avaliação, inferência em lote ou inferência online
• Projetando critérios de promoção de modelo, avaliações offline/online, rastreamento de experimentos ou caminhos de rollback
• Depurando falhas causadas por drift de dados, vazamento de rótulos, features desatualizadas, incompatibilidade de artefatos ou lógica inconsistente de treinamento e serving
• Adicionando monitoramento de modelo, rollout canário, tráfego sombra ou verificações de qualidade pós-implantação

Calibração de Escopo

Use apenas as faixas que se adequam ao sistema à sua frente. Este skill é útil para ranqueamento, busca, recomendações, classificadores, previsão, embeddings, fluxos de trabalho de LLM, detecção de anomalias e análises em lote, mas não deve forçar uma única arquitetura para todos eles.

• Não presuma que todo modelo tem rótulos supervisionados, serving online, um feature store, PyTorch, GPUs, revisão humana, testes A/B ou feedback em tempo real.
• Não adicione maquinário pesado de MLOps quando um contrato de dados, baseline, script de avaliação e nota de rollback tornariam a alteração revisável.
• Torne as suposições explícitas quando o projeto não tiver rótulos, resultados atrasados, definições de fatias, tráfego de produção ou responsabilidade pelo monitoramento.
• Trate os exemplos como scaffolds intercambiáveis. Substitua métricas, modo de serving, armazenamentos de dados e mecânicas de rollout pelos equivalentes nativos do projeto.

Skills Relacionados

• python-patterns e python-testing para implementação em Python e cobertura com pytest
• pytorch-patterns para modelos de deep learning, carregadores de dados, manipulação de dispositivo e loops de treinamento
• eval-harness e ai-regression-testing para gateways de promoção e verificações de regressão assistidas por agente
• database-migrations, postgres-patterns e clickhouse-io para armazenamento de dados e superfícies de análise
• deployment-patterns, docker-patterns e security-review para serving, segredos, contêineres e endurecimento de produção

Reutilize a Superfície de SWE

Não trate MLE como separado da engenharia de software. A maioria dos fluxos de trabalho de SWE do ECC se aplica diretamente a sistemas de ML, muitas vezes com modos de falha mais rigorosos:

A instalação recomendada minimal --with capability:machine-learning mantém a superfície principal do agente disponível junto com este skill. Para harnesses apenas de skill ou com agentes limitados, combine skill:mle-workflow com agent:mle-reviewer quando o destino suportar agentes.

Superfície SWE	Uso em MLE
product-capability / architecture-decision-records	Transformar trabalho de modelo em contratos de produto explícitos e registrar decisões irreversíveis de dados, modelo e rollout
repo-scan / codebase-onboarding / code-tour	Encontrar caminhos existentes de treinamento, feature, serving, avaliação e monitoramento antes de introduzir uma pilha de ML paralela
plan / feature-dev	Escopo de mudanças de modelo como capacidades de produto com fases de dados, avaliação, serving e rollback
tdd-workflow / python-testing	Testar transformações de features, lógica de divisão, cálculos de métricas, carregamento de artefatos e esquemas de inferência antes da implementação
code-reviewer / mle-reviewer	Revisar qualidade do código mais riscos específicos de ML: vazamento, reprodutibilidade, promoção e monitoramento
build-fix / pr-test-analyzer	Diagnosticar CI quebrado, avaliações instáveis, fixtures ausentes e falhas de modelo ou dependência específicas de ambiente
quality-gate / test-coverage	Exigir evidências automatizadas para transformações, métricas, contratos de inferência, gateways de promoção e comportamento de rollback
eval-harness / verification-loop	Transformar métricas offline, verificações de fatias, orçamentos de latência e exercícios de rollback em gateways repetíveis
ai-regression-testing	Preservar cada bug de produção como uma regressão: feature ausente, rótulo desatualizado, artefato ruim, deriva de esquema ou incompatibilidade de serving
api-design / backend-patterns	Projetar APIs de previsão, trabalhos em lote, endpoints de retreinamento idempotentes e envelopes de resposta
database-migrations / postgres-patterns / clickhouse-io	Versionar rótulos, snapshots de features, logs de previsão, métricas de experimentos e análises de drift
deployment-patterns / docker-patterns	Empacotar imagens reproduzíveis de treinamento e serving com health checks, limites de recursos e rollback
canary-watch / dashboard-builder	Tornar a saúde do rollout visível com painéis de versão de modelo, fatia, drift, latência, custo e rótulo atrasado
security-review / security-scan	Verificar artefatos de modelo, notebooks, prompts, datasets e logs em busca de segredos, PII, desserialização insegura e risco na cadeia de suprimentos
e2e-testing / browser-qa / accessibility	Testar fluxos críticos do produto que consomem previsões, incluindo explicabilidade e estados de UI de fallback
benchmark / performance-optimizer	Medir throughput, latência p95, memória, utilização de GPU e custo por previsão ou retreinamento
cost-aware-llm-pipeline / token-budget-advisor	Roteizar cargas de trabalho de LLM/embedding por qualidade, latência e orçamento em vez de usar o maior modelo por padrão
documentation-lookup / search-first	Verificar o comportamento atual da biblioteca para serving de modelo, feature stores, bancos de dados vetoriais e ferramentas de avaliação antes de codificar
git-workflow / github-ops / opensource-pipeline	Empacotar mudanças de MLE para revisão com escopo claro, artefatos gerados excluídos e evidência de teste reproduzível
strategic-compact / dmux-workflows	Dividir trabalho longo de ML em faixas paralelas: contrato de dados, harness de avaliação, caminho de serving, monitoramento e documentação

Dez Simulações de Tarefas MLE

Use estas simulações como verificações de cobertura ao planejar ou revisar trabalho de MLE. Um fluxo de trabalho MLE forte deve reduzir cada tarefa a contratos explícitos, superfícies SWE reutilizáveis, evidências automatizadas e um artefato revisável.

ID	Tarefa MLE comum	Caminho ECC simplificado	Saída necessária	Faixas de pipeline cobertas
MLE-01	Enquadrar uma capacidade ambígua de previsão, ranqueamento, recomendador, classificador, embedding ou previsão	product-capability, plan, architecture-decision-records, mle-workflow	Iteration Compact nomeando quem se importa, dono da decisão, métrica de sucesso, erros inaceitáveis, suposições, restrições e primeiro experimento	contrato de produto, perda do stakeholder, risco, rollout
MLE-02	Definir metas de métrica, rótulos, fontes de dados e o orçamento de erros	repo-scan, database-reviewer, database-migrations, postgres-patterns, clickhouse-io	Contrato de dados e métrica com granularidade da entidade, tempo do rótulo, confiança do rótulo, tempo da feature, joins pontuais, política de divisão e snapshot do dataset	contrato de dados, design de métrica, vazamento, reprodutibilidade
MLE-03	Construir um modelo baseline e caminho de pontuação antes de adicionar complexidade	tdd-workflow, python-testing, python-patterns, code-reviewer	Pontuador baseline com matriz de confusão, notas de calibração, estimativa de latência/custo, fraquezas conhecidas e testes para formato e determinismo da pontuação	baseline, pontuação, teste, paridade de serving
MLE-04	Gerar features a partir de hipóteses sobre o que separa os resultados	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	Plano de features e módulo de transformação cobrindo fonte de sinal, valores ausentes, outliers, correlações, verificações de vazamento e equivalência treinamento/serving	pipeline de features, vazamento, treinamento, artefatos
MLE-05	Ajustar thresholds, configurações e complexidade do modelo sob tradeoffs	eval-harness, ai-regression-testing, quality-gate, test-coverage	Relatório de threshold/config comparando precisão, recall, F1, AUC, calibração, fatias de grupo, latência, custo, complexidade e classes de erro aceitáveis	avaliação, threshold, promoção, regressão
MLE-06	Executar análise de erros e transformar erros no próximo experimento	eval-harness, ai-regression-testing, mle-reviewer, silent-failure-hunter	Relatório de cluster de erros para falsos positivos, falsos negativos, rótulos ambíguos, features desatualizadas, sinais ausentes e rastros de bugs com lições aprendidas	análise de erros, rastro de bug, iteração, regressão
MLE-07	Empacotar um artefato de modelo para inferência em lote ou online	api-design, backend-patterns, security-review, security-scan	Pacote de artefato versionado com pré-processamento, configuração, restrições de dependência, validação de esquema, carregamento seguro e logs seguros de PII	artefato, segurança, contrato de inferência
MLE-08	Enviar serving online ou pontuação em lote com captura de feedback	api-design, backend-patterns, e2e-testing, browser-qa, accessibility	Endpoint de previsão ou trabalho em lote com envelope de resposta, timeout, loteamento, fallback, versão do modelo, confiança, registro de feedback e testes de fluxo do produto	serving, inferência em lote, fallback, fluxo de trabalho do usuário
MLE-09	Lançar um modelo com tráfego sombra, canário, teste A/B ou rollback	canary-watch, dashboard-builder, verification-loop, performance-optimizer	Plano de rollout nomeando divisão de tráfego, painéis, latência p95, custo, guardrails de qualidade, artefato de rollback e gatilho de rollback	implantação, canário, rollback
MLE-10	Operar, depurar e atualizar um modelo de produção após o lançamento	silent-failure-hunter, dashboard-builder, mle-reviewer, doc-updater, github-ops	Diário de observação e plano de atualização com verificações de drift, saúde de rótulo atrasado, proprietários de alertas, atualizações de runbook, critérios de retreinamento e evidências de PR	monitoramento, resposta a incidentes, retreinamento

Iteration Compact

Antes de tocar no código do modelo, comprima o trabalho em um artefato revisável. Deve ser curto o suficiente para caber na descrição de um PR e preciso o suficiente para que outro engenheiro possa questionar os tradeoffs.

Objetivo:
Quem se importa:
Dono da decisão:
Ação do usuário ou sistema alterada pelo modelo:
Métrica de sucesso:
Métricas de guardrail:
Orçamento de erros:
Erros inaceitáveis:
Erros aceitáveis:
Suposições:
Restrições:
Rótulos e snapshot de dados:
Baseline:
Sinais candidatos:
Plano de threshold ou configuração:
Fatias de avaliação:
Riscos conhecidos:
Próximo experimento:
Rollback ou fallback:

Este compact é o equivalente MLE de uma nota de design SWE forte. Ele impede que a equipe otimize uma métrica em que ninguém confia, adicione features que não abordam o modo de erro real ou envie complexidade sem um rollback.

Cérebro de Decisão

Use este loop sempre que a tarefa for ambígua, de alto impacto ou pesada em métricas:

1. Comece pela decisão, não pelo modelo. Nomeie a ação que altera o comportamento downstream.
2. Nomeie quem se importa e por quê. Diferentes stakeholders pagam custos diferentes por falsos positivos, falsos negativos, latência, gasto computacional, opacidade ou oportunidades perdidas.
3. Converta ambiguidade em hipóteses. Pergunte que sinal separaria os resultados, que evidência o refutaria e que baseline simples deveria ser difícil de superar.
4. Pesquise trabalhos anteriores ou um problema conhecido próximo antes de inventar um sistema sob medida.
5. Pontue escolhas com (probabilidade, confiança) x (custo, gravidade, importância, impacto).
6. Considere comportamento adversarial, incentivos, divulgação seletiva, mudança de distribuição e loops de feedback.
7. Prefira a mudança mais simples que reduza o erro mais importante. Simplicidade não é preguiça; é uma forma de minimizar erros grosseiros enquanto preserva a velocidade de iteração.
8. Capture a decisão, evidência, contra-argumento e próximo passo reversível.

Economia de Métricas e Erros

Escolha métricas a partir dos custos de falha, não por hábito:

• Use uma matriz de confusão cedo para que a equipe possa discutir falsos positivos e falsos negativos concretos em vez de acurácia abstrata.
• Favoreça precisão quando o custo de uma decisão positiva incorreta domina.
• Favoreça recall quando o custo de um positivo perdido domina.
• Use F1 apenas quando o tradeoff precisão/recall for genuinamente equilibrado e explicável.
• Use AUC ou métricas de ranqueamento quando a qualidade da ordenação importa mais que um único threshold.
• Rastreie latência, throughput, memória e custo como métricas de primeira classe porque elas moldam a complexidade viável do modelo.
• Compare com um baseline e o modelo de produção atual antes de celebrar um ganho offline.
• Trate sinais de feedback do mundo real como rótulos atrasados com viés, lag e lacunas de cobertura; não os trate como verdade absoluta sem análise.

Cada escolha de métrica deve declarar qual erro ela torna mais barato, qual erro ela torna mais provável e quem absorve esse custo.

Dados e Hipóteses de Features

As features devem vir de uma teoria de separação:

• Texto, campos categóricos, históricos numéricos, relações de grafo, recência, frequência e agregados são famílias de sinal candidatas, não features automáticas.
• Para cada família de feature, declare por que ela deve separar os resultados e como poderia vazar informações futuras.
• Para rótulos ruidosos, considere arbitragem, confiança do rótulo, alvos suaves ou ponderação por confiança.
• Para desbalanceamento de classe, compare perda ponderada, reamostragem, movimento de threshold e regras de decisão calibradas.
• Para valores ausentes, decida se a ausência é informativa, imputável ou uma razão para se abster.
• Para outliers, decida se devem ser cortados, agrupados, investigados ou preservados como sinal raro, mas importante.
• Para features correlacionadas, verifique se são redundantes, instáveis ou proxies para um estado futuro indisponível.

Não adicione complexidade ao modelo até que a análise de erros mostre que o baseline está falhando por uma razão que sinal adicional ou capacidade pode plausivelmente corrigir.

Loop de Análise de Erros

Após cada baseline, execução de treinamento, alteração de threshold ou alteração de configuração:

1. Divida erros em falsos positivos, falsos negativos, abstenções, casos de baixa confiança e falhas de sistema.
2. Agrupe erros por características compartilhadas: idioma, tipo de entidade, fonte, tempo, geografia, dispositivo, esparsidade, recência, frescor de feature, fonte do rótulo ou versão do modelo.
3. Separe erros de modelo de bugs de dados

…

[truncado para tradução]