mle-workflow

Fluxo de Trabalho de Engenharia de Machine Learning

Use este skill para transformar o trabalho do modelo em um sistema de ML de produção com contratos de dados claros, treinamento repetível, gates 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 trabalho de embeddings ou pipeline de previsão
• Convertendo código de notebook em um pipeline de treinamento, avaliação, inferência em lote ou inferência online reutilizável
• Projetando critérios de promoção de modelo, avaliações offline/online, rastreamento de experimentos ou caminhos de rollback
• Depurando falhas causadas por deriva de dados, vazamento de rótulo, características desatualizadas, incompatibilidade de artefatos ou lógica de treinamento e serviço inconsistente
• 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 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 tenha rótulos supervisionados, serviço online, um feature store, PyTorch, GPUs, revisão humana, testes A/B ou feedback em tempo real.
• Não adicione maquinário MLOps pesado quando um contrato de dados, linha de base, script de avaliação e nota de rollback tornariam a mudança 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 de monitoramento.
• Trate os exemplos como scaffolds intercambiáveis. Substitua métricas, modo de serviço, armazenamentos de dados e mecânicas de rollout pelos equivalentes nativos do projeto.

Habilidades Relacionadas

• python-patterns e python-testing para implementação Python e cobertura pytest
• pytorch-patterns para modelos de deep learning, carregadores de dados, tratamento de dispositivo e loops de treinamento
• eval-harness e ai-regression-testing para gates 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 serviço, segredos, contêineres e fortalecimento 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 central do agente disponível junto com este skill. Para harnesses apenas de skill ou limitados a agente, emparelhe skill:mle-workflow com agent:mle-reviewer onde o alvo suportar agentes.

Superfície SWE	Uso MLE
product-capability / architecture-decision-records	Transforme o trabalho do modelo em contratos de produto explícitos e registre decisões irreversíveis de dados, modelo e rollout
repo-scan / codebase-onboarding / code-tour	Encontre caminhos existentes de treinamento, características, serviço, avaliação e monitoramento antes de introduzir uma stack ML paralela
plan / feature-dev	Escopo as mudanças do modelo como capacidades de produto com fases de dados, avaliação, serviço e rollback
tdd-workflow / python-testing	Teste transformações de características, 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	Revise a qualidade do código mais riscos específicos de ML: vazamento, reprodutibilidade, promoção e monitoramento
build-fix / pr-test-analyzer	Diagnostique CI quebrado, avaliações instáveis, fixtures ausentes e falhas de modelo ou dependência específicas de ambiente
quality-gate / test-coverage	Exija evidências automatizadas para transformações, métricas, contratos de inferência, gates de promoção e comportamento de rollback
eval-harness / verification-loop	Transforme métricas offline, verificações de fatias, orçamentos de latência e exercícios de rollback em gates repetíveis
ai-regression-testing	Preserve todo bug de produção como uma regressão: característica ausente, rótulo desatualizado, artefato ruim, deriva de esquema ou incompatibilidade de serviço
api-design / backend-patterns	Projete APIs de previsão, trabalhos em lote, endpoints de retreinamento idempotentes e envelopes de resposta
database-migrations / postgres-patterns / clickhouse-io	Versionamento de rótulos, snapshots de características, logs de previsão, métricas de experimento e análises de deriva
deployment-patterns / docker-patterns	Empacote imagens reproduzíveis de treinamento e serviço com verificações de saúde, limites de recursos e rollback
canary-watch / dashboard-builder	Torne a saúde do rollout visível com painéis de versão do modelo, fatia, deriva, latência, custo e rótulo atrasado
security-review / security-scan	Verifique artefatos de modelo, notebooks, prompts, conjuntos de dados e logs em busca de segredos, PII, desserialização insegura e risco de cadeia de suprimentos
e2e-testing / browser-qa / accessibility	Teste fluxos de produto críticos que consomem previsões, incluindo explicabilidade e estados de UI de fallback
benchmark / performance-optimizer	Meça throughput, latência p95, memória, utilização de GPU e custo por previsão ou retreinamento
cost-aware-llm-pipeline / token-budget-advisor	Roteie cargas de trabalho de LLM/embedding por qualidade, latência e orçamento em vez de usar o modelo maior por padrão
documentation-lookup / search-first	Verifique o comportamento atual da biblioteca para serviço de modelo, feature stores, bancos de dados vetoriais e ferramentas de avaliação antes de codificar
git-workflow / github-ops / opensource-pipeline	Empacote alterações MLE para revisão com escopo claro, artefatos gerados excluídos e evidências de teste reproduzíveis
strategic-compact / dmux-workflows	Divida o trabalho de ML longo em faixas paralelas: contrato de dados, harness de avaliação, caminho de serviço, monitoramento e documentação

Dez Simulações de Tarefas MLE

Use estas simulações como verificações de cobertura ao planejar ou revisar o 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	Compacto de Iteração 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 das partes interessadas, risco, rollout
MLE-02	Definir metas de métricas, 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 granulação de entidade, tempo de rótulo, confiança do rótulo, tempo de característica, junções point-in-time, política de divisão e snapshot do conjunto de dados	contrato de dados, design de métrica, vazamento, reprodutibilidade
MLE-03	Construir um modelo de linha de base e caminho de pontuação antes de adicionar complexidade	tdd-workflow, python-testing, python-patterns, code-reviewer	Pontuador de linha de base com matriz de confusão, notas de calibração, estimativa de latência/custo, fraquezas conhecidas e testes para forma de pontuação e determinismo	linha de base, pontuação, teste, paridade de serviço
MLE-04	Gerar características a partir de hipóteses sobre o que separa os resultados	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	Plano de características e módulo de transformação cobrindo fonte de sinal, valores ausentes, outliers, correlações, verificações de vazamento e equivalência treino/serviço	pipeline de características, vazamento, treinamento, artefatos
MLE-05	Ajustar limites, configurações e complexidade do modelo sob trade-offs	eval-harness, ai-regression-testing, quality-gate, test-coverage	Relatório de limite/configuração comparando precisão, recall, F1, AUC, calibração, fatias de grupo, latência, custo, complexidade e classes de erro aceitáveis	avaliação, limite, 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, características desatualizadas, sinais ausentes e rastros de bugs com lições capturadas	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	Entregar serviço 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, agrupamento, fallback, versão do modelo, confiança, log de feedback e testes de fluxo de produto	serviço, 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	Registro de observação e plano de atualização com verificações de deriva, 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

Compacto de Iteração

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 desafiar os trade-offs.

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:
Linha de base:
Sinais candidatos:
Plano de limite ou configuração:
Fatias de avaliação:
Riscos conhecidos:
Próximo experimento:
Rollback ou fallback:

Este compacto é o equivalente MLE de uma nota de design SWE forte. Ele impede que a equipe otimize uma métrica da qual ninguém confia, adicione características que não abordam o modo de erro real, ou entregue complexidade sem um rollback.

Máquina 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 porquê. Diferentes partes interessadas pagam custos diferentes por falsos positivos, falsos negativos, latência, gasto computacional, opacidade ou oportunidades perdidas.
3. Converta ambiguidade em hipóteses. Pergunte qual sinal separaria os resultados, que evidência o refutaria e qual linha de base simples deve ser difícil de superar.
4. Pesquise arte anterior ou um problema conhecido próximo antes de inventar um sistema personalizado.
5. Pontue as 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 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 do hábito:

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

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

Hipóteses de Dados e Características

As características 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 características automáticas.
• Para cada família de características, 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 de confiança.
• Para desbalanceamento de classe, compare perda ponderada, reamostragem, movimento de limite e regras de decisão calibradas.
• Para valores ausentes, decida se a ausência é informativa, imputável ou um motivo para se abster.
• Para outliers, decida se deve cortar, agrupar, investigar ou preservá-los como sinal raro, mas importante.
• Para características 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 a linha de base está falhando por um motivo que sinal ou capacidade adicional possa plausivelmente corrigir.

Loop de Análise de Erros

Após cada linha de base, execução de treinamento, mudança de limite ou mudança de configuração:

1. Divida os erros em falsos positivos, falsos negativos, abstenções, casos de baixa confiança e falhas de sistema.
2. Agrupe os erros por características compartilhadas: idioma, tipo de entidade, fonte, tempo, geografia, dispositivo, esparsidade, recência, frescor da característica, fonte do rótulo ou versão do modelo.
3. Separe erros do modelo de bugs de dados e erros de configuração.
4. Para cada cluster, determine a resposta: mais dados, novo sinal, engenharia de característica, ajuste de limite, rerranqueamento, fallback, amostragem corretiva, anotação mais clara, melhor validação ou rejeição explícita.
5. Converta a resposta mais importante no próximo experimento no Compacto de Iteração.
6. Preserve o bug como um teste de regressão para garantir que não retorne sem aviso.

Pipeline de Dados

O caminho de dados deve ser explícito e reproduzível:

• Armazene snapshots de conjuntos de dados por data, hash ou tag de experimento.
• Use junções point-in-time para evitar vazamento de rótulo e característica: não use informações futuras para prever o passado.
• Valide o esquema do conjunto de dados, tipos e estatísticas resumidas (contagem, valores ausentes, valores únicos, distribuições) antes do treinamento.
• Separe dados de treino, validação e teste de forma consistente e registre a política de divisão.
• Para séries temporais, use janelas deslizantes ou divisões baseadas em tempo para respeitar a ordem cronológica.
• Evite o vazamento de dados entre conjuntos de treino e teste, verificando duplicatas, derivadas de destino comuns e transformações que vazam o destino.
• Toda transformação de dados deve ter uma representação idempotente, livre de estado e reproduzível tanto no treinamento quanto no serviço.

Pipeline de Características

Construa características como módulos testáveis, não scripts:

• Cada função ou classe de característica deve aceitar um DataFrame ou lote e retornar um DataFrame com nomes de coluna estáveis.
• Características derivadas de agregações históricas, joins ou janelas temporais devem especificar fonte, janela, política de atualização e opção de valor ausente.
• Características de texto, imagem ou gráfico devem incluir pré-processamento e lógica de tokenização/embedding que seja idêntica entre treinamento e serviço.
• Empilhe transformações em uma pipeline que possa ser serializada e inspecionada.
• Registre um esquema de características incluindo nome, tipo, faixa, valor ausente permitido e comportamento de outlier.
• Teste cada módulo de característica para forma de saída, determinismo e estabilidade de linha de base.
• Conjuntos de características que dependem de labels futuros, joins que olham para frente, ou transformações que usam escala de todo o conjunto de dados são vazamentos e devem ser detectados em revisão.

Pipeline de Treinamento

O treinamento deve ser reproduzível e inspecionável:

• Armazene tudo o que for necessário para reproduzir um modelo: snapshot de dados, características, código do modelo, hiperparâmetros, configuração, bibliotecas, semente aleatória e métricas.
• Use a mesma pipeline de características e pré-processamento no treinamento e no serviço para evitar incompatibilidade treino-serviço.
• Implemente validação de entrada no início do treinamento para rejeitar dados que violem expectativas de esquema, alcance ou distribuição.
• Registre curvas de perda e métricas de validação em cada época para detectar overfitting ou underfitting mais cedo.
• Salve o modelo final em um formato que inclua parâmetros, configuração, assinatura de entrada/saída e versão da biblioteca.
• Use um diretório de artefatos versionado ou registro de modelo para implantação e rollback.
• Escreva um teste de sanidade que carregue o artefato e execute uma única previsão determinística.

Pipeline de Avaliação

A avaliação deve conectar métricas offline aos objetivos de negócio:

• Execute a avaliação em um conjunto de teste de hold-out que nunca vazou para treinamento ou seleção de características.
• Calcule a matriz de confusão e métricas derivadas (precisão, recall, F1, especificidade, NPV, precisão balanceada).
• Para problemas de ranqueamento, use NDCG, MAP, MRR ou métricas de ranqueamento personalizadas.
• Para previsão, use MAE, RMSE, MAPE ou erro de quantil.
• Para classificação multirrótulo ou multi-classe, use macro/micro F1, perda de log ou erro de classificação por classe.
• Para calibração, use o gráfico de confiabilidade e o erro de calibração esperado (ECE).
• Avalie por fatias importantes (grupo demográfico, tipo de fonte, período de tempo, nível de confiança, etc.) para detectar desempenho desigual.
• Compare o modelo candidato com a linha de base e o modelo de produção atual usando o mesmo protocolo de avaliação.
• Relate intervalos de confiança ou testes de significância para mudanças de métrica sempre que possível.

Pipeline de Implantação

Implantação é a transferência de um artefato verificado para um ambiente de serviço:

• O artefato de modelo deve incluir tudo o que for necessário para o serviço: parâmetros, gráfico/computação, pré-processamento, pós-processamento, dependências e esquema de entrada/saída.
• Containerize o artefato em uma imagem de serviço reproduzível que possa ser testada offline.
• Implemente uma verificação de saúde específica do modelo (por exemplo, faça uma previsão com um registro de teste conhecido e verifique a saída).
• Use gate de promoção que exija aprovação em testes de avaliação, latência e integração antes da implantação de produção.
• Prefira rollouts graduais: tráfego sombra, canário por porcentagem, canário por segmento ou implantação azul-verde.
• Monitore a qualidade da previsão, latência, taxa de erro e utilização de recursos durante o rollout.
• Mantenha o artefato da versão anterior implantado até que o novo seja confirmado estável.
• Registre cada implantação com modelo, data, artefato hash, estratégia de rollout e resultado.

Pipeline de Serviço

O serviço online deve ser rápido, confiável e observável:

• Projete um endpoint de previsão que aceite entradas estruturadas e retorne uma previsão mais confiança, versão do modelo e metadados de depuração opcionais.
• Implemente lógica de fallback se o modelo estiver indisponível ou retornar uma previsão de baixa confiança (por exemplo, regressão à média, heurística, modelo mais simples).
• Defina timeouts no nível do modelo e no nível do endpoint para evitar efeitos de cauda longa.
• Agrupe previsões se a latência e a taxa de transferência permitirem, mas garanta que os resultados permaneçam independentes.
• Ative o log de previsões para análise offline de feedback e detecção de deriva.
• Monitore a latência da previsão, taxa de erro, volume de tráfego e deriva de entrada.
• Para inferência em lote, projete o trabalho para ser idempotente, tolerante a falhas e registrado com metadados de modelo e dados.
• Valide as entradas de previsão em relação ao esquema esperado e rejeite ou sinalize registros inválidos.
• Implemente a detecção de deriva de dados de entrada comparando distribuições de características recentes com as distribuições de treinamento ou de serviço anterior.

Pipeline de Monitoramento

O monitoramento deve detectar deterioração antes que ela se torne visível para o usuário:

• Acompanhe a qualidade da previsão (quando labels atrasados estão disponíveis) como uma medida atrasada da saúde do modelo.
• Monitore a deriva de características de entrada (deriva de dados), deriva de conceito (mudança na relação entrada/saída) e deriva de labels (distribuição de labels mudou).
• Configure alarmes para desvios significativos nas métricas de qualidade, latência, taxa de erro, volume de previsão ou estatísticas de entrada.
• Mantenha um diário de bordo de observações: cada incidente, investigação, alteração e resultado com carimbo de data/hora.
• Defina critérios de retreinamento com base em deriva de dados, queda de qualidade, mudança de conceito ou cronograma.
• Documente runbooks para incidentes comuns: queda de modelo, deriva de características, regressão de latência, quebra de dependência.
• Monitore o custo de serviço e retreinamento; otimize quando os retornos diminuírem.

Gerenciamento de Artefatos

Gerencie artefatos de modelo como ativos de software:

• Atribua um identificador único (hash, versão semântica, carimbo de data/hora) a cada artefato.
• Armazene artefatos em um registro de modelo ou sistema de arquivos versionado com metadados: dados de origem, características, hiperparâmetros, métricas, data de criação, autor.
• Implemente uma política de retenção de artefatos para gerenciar o custo de armazenamento, preservando artefatos de produção e versões de auditoria.
• Marque artefatos com tags de ambiente (dev, staging, canário, produção) e status (candidato, aprovado, rejeitado, promovido, arquivado).
• Mantenha um changelog de artefatos anotando o que mudou entre as versões, por que, e com que impacto.
• Torne os artefatos imutáveis após a criação: se um modelo precisar ser alterado, crie um novo artefato.

Estratégia de Rollback

Rollback não é um sinal de fracasso; é um mecanismo de segurança:

• Defina um gatilho de rollback para cada implantação: queda de métrica, pico de erro, aumento de latência, violação de guardrail.
• Mantenha o artefato da versão anterior implantado e pronto para ativar.
• Elabore um plano de rollback para cada lançamento: quem aciona, como, quais verificações executar após.
• Pratique rollbacks em ambientes de teste para garantir que funcionem suavemente.
• Documente cada rollback com causa, ações tomadas, resultado e lições aprendidas.
• Após um rollback, investigue a causa raiz e corrija antes de retentar o lançamento.

Tratamento de Falhas Silenciosas

Nem toda falha produz um erro explícito. Falhas silenciosas ocorrem quando um modelo degrada, mas não falha abertamente:

• Monitore a degradação silenciosa através de métricas de qualidade contínuas, verificação de deriva e validação de saída.
• Implemente verificações de sanidade no servidor de previsão: forma de saída, faixa, monotonicidade para características conhecidas.
• Use tráfego sombra para testar um novo modelo lado a lado com o modelo de produção sem impacto no usuário; meça a concordância e as diferenças.
• Acompanhe a cobertura de previsão: o modelo recusa ou abstém-se com mais frequência? A taxa de abstenção mudou?
• Incorpore feedback de atraso de rótulo: uma vez que os rótulos verdadeiros chegam, execute avaliação offline das previsões e compare com as métricas de serviço.

Segurança e Conformidade

Sistemas de ML introduzem riscos de segurança e privacidade específicos:

• Os artefatos do modelo podem conter PII, informações proprietárias ou vieses. Proteja-os com controles de acesso e criptografia.
• Os dados de treinamento podem conter PII, segredos ou outras informações sensíveis. Limpe e anonimize conforme necessário.
• As entradas de previsão podem conter dados do usuário. Registre-as de forma segura, com PII mascarada ou excluída após a retenção necessária.
• Os logs do modelo não devem vazar dados do usuário, segredos ou informações internas. Use sanitizadores de log.
• Ataques adversariais a modelos (exemplos adversariais, envenenamento, extração de modelo) devem ser modelados e mitigados com base na ameaça.
• A cadeia de suprimentos de dependências de ML (bibliotecas, conjuntos de dados, modelos pré-treinados) deve ser verificada quanto à segurança e licenciamento.
• A conformidade regulatória (GDPR, CCPA, etc.) pode exigir explicabilidade, direito à exclusão de dados de treinamento e imparcialidade do modelo.

Considerações sobre LLM e Agente

Para fluxos de trabalho envolvendo LLMs ou agentes, considere riscos adicionais:

• Injeção de prompt: entradas do usuário que alteram o comportamento do modelo. Implemente guardrails de entrada e saída.
• Alucinação: o modelo gera saída factualmente incorreta. Valide saídas contra fontes confiáveis onde possível.
• Excesso de confiança: o modelo expressa alta confiança mesmo quando errado. Use calibração e verificação de fatos.
• Custo por token: o orçamento de LLM pode explodir. Implemente limites de orçamento, limitação de taxa e roteamento para o modelo mais barato apropriado.
• Latência: LLMs podem ser lentos. Use cache, agrupamento e modelos menores para tarefas simples.
• Segurança: LLMs podem gerar conteúdo prejudicial. Use filtros de conteúdo e moderação humana crítica.
• Justiça: LLMs podem amplificar vieses. Teste em subpopulações e mitigue quando detectado.

Estrutura do Projeto

Um projeto MLE típico pode ser organizado como:

project/
├── data/
│   ├── contracts/          # Contratos de dados e métricas
│   ├── snapshots/          # Instantâneos de conjuntos de dados
│   └── features/           # Definições de características
├── models/
│   ├── baselines/          # Linhas de base e modelos simples
│   ├── experiments/        # Experimentos com hiperparâmetros e configurações
│   └── artifacts/          # Artefatos de modelo versionados
├── pipelines/
│   ├── training/           # Pipeline de treinamento
│   ├── evaluation/         # Pipeline de avaliação
│   ├── serving/            # Pipeline de serviço (online/batch)
│   └── monitoring/         # Pipeline de monitoramento
├── tests/
│   ├── unit/               # Testes unitários para transformações, métricas, lógica
│   ├── integration/        # Testes de integração para pipelines
│   └── regression/         # Testes de regressão para bugs conhecidos
├── deploy/
│   ├── images/             # Imagens Docker para treinamento e serviço
│   └── config/             # Configurações de implantação
├── docs/
│   ├── adrs/               # Registros de Decisão de Arquitetura
│   ├── runbooks/           # Runbooks para incidentes comuns
│   └── contracts/          # Contratos de dados e modelo
└── notebooks/              # Notebooks exploratórios (não para produção)

Esta estrutura é um guia, não uma regra. Adapte-a ao seu projeto, linguagem e cultura de equipe.

Fundamentos de Reproducibilidade

Reproducibilidade é a base de um MLE confiável:

• Fixe versões de bibliotecas e dependências (use um gerenciador de pacotes, arquivo de lock ou imagem de contêiner).
• Use sementes aleatórias fixas em todo o código que dependa de aleatoriedade.
• Armazene hiperparâmetros e configuração junto com o modelo.
• Mantenha um registro de experimentos com data, configuração, semente, conjunto de dados hash, resultado da métrica.
• Containerize o ambiente de treinamento para eliminar dependências do sistema host.
• Teste a reprodutibilidade executando o treinamento duas vezes e comparando o modelo e as métricas.
• Documente quaisquer fatores não determinísticos (precisão de GPU, paralelismo, bibliotecas com comportamento não determinístico).

Conclusão

Este fluxo de trabalho MLE fornece uma abordagem sistemática para construir, revisar e operar sistemas de ML de produção. Ao quebrar o trabalho em contratos, pipelines, avaliações, implantações e loops de monitoramento, ele reduz a complexidade, aumenta a confiabilidade e torna cada alteração revisável. Comece com o Compacto de Iteração, siga a Máquina de Decisão e use as simulações MLE para verificar a cobertura. Adapte as práticas ao seu projeto, linguagem e cultura.

"Simplicidade não é preguiça; é uma forma de minimizar erros enquanto preserva a velocidade de iteração."