Machine Learning: Design do Projeto
Última atualização: 2026-08-26
Um bom começo é metade da batalha — o design do sistema faz ou quebra um projeto, então desenhe a planta antes de construir.
1. O que você vai aprender
- Análise de requisitos: objetivos de negócio (previsão de receita mensal com MAPE < 10%), histórias de usuário e definições de métricas principais
- Arquitetura de dados: fontes de dados (pedidos/usuários/produtos/logs) → data lake → feature store
- Arquitetura de modelos: um roteiro de evolução da linha de base (LinearRegression) → avançado (XGBoost) → aprendizado profundo (MLP)
- Arquitetura de implantação: gerenciamento de experimentos com MLflow + serviço de inferência FastAPI + containerização Docker + monitoramento e alertas
- Cronograma do projeto e colaboração da equipe: divisão de trabalho entre Alice (Engenharia de Dados), Bob (Engenharia de ML) e Charlie (Backend/DevOps)
2. A história real de uma equipe de startup
(1) O problema: pular direto para o código levou a três reescritas completas
Bob fez sua equipe começar a programar imediatamente. Duas semanas depois, descobriram que o design da fonte de dados estava falho e tiveram que refazer. Quatro semanas depois, descobriram que a arquitetura do modelo não suportava previsão online e tiveram que mudar de novo. Oito semanas depois, perceberam que o plano de implantação ignorava monitoramento e tiveram que refatorar mais uma vez. Em um projeto sem design, cada etapa é uma "surpresa".
(2) A solução com design de sistema
O design de sistema força você a pensar "o que construir" e "como construir" com antecedência — requisitos → dados → modelo → implantação → monitoramento, com um plano claro para cada etapa.
# Design do projeto como código
project_config = {
"name": "SalesPredict",
"goal": "Previsão de receita mensal MAPE < 10%",
"data_sources": ["pedidos", "usuários", "produtos", "logs_anuncios"],
"model_pipeline": "LinearRegression → XGBoost → MLP",
"deployment": "FastAPI + Docker + MLflow",
"team": {"Alice": "Engenharia de Dados", "Bob": "Engenharia de ML", "Charlie": "DevOps"},
}
(3) O resultado: design primeiro, zero retrabalho no desenvolvimento
Depois que Bob passou uma semana no design do sistema, as oito semanas de desenvolvimento tiveram zero retrabalho e entregaram no prazo. O design custou apenas 10% do tempo total do projeto, mas evitou mais de 50% do risco de retrabalho.
3. Análise de Requisitos
(1) Definindo o objetivo de negócio
▶ Exemplo: Modelo de documento de requisitos
# Requisitos como config estruturado
requirements = {
"objetivo_negocio": "Prever a receita do próximo mês por categoria de produto",
"metricas_sucesso": {
"primaria": "MAPE < 10% para previsão de receita mensal",
"secundarias": ["MAE < 50k USD por categoria", "Latência de previsão < 100ms"],
},
"historias_usuario": [
"Como Bob (Operações), quero previsões de receita mensal para otimizar o estoque",
"Como Alice (Gerente EUA), quero previsões em USD para o mercado dos EUA",
"Como Charlie (Gerente UE), quero previsões em EUR para o mercado da UE",
"Como CFO, quero intervalos de confiança das previsões para planejamento orçamentário",
],
"restricoes": {
"latencia_dados": "Atualização em lote diária às 6:00",
"sla_previsao": "Resposta da API < 100ms p95",
"retreinamento_modelo": "Re-treinamento automatizado semanal",
"compliance": "GDPR para dados de usuários da UE",
},
"escopo": {
"dentro_escopo": ["3 regiões de mercado", "5 categorias de produtos", "Previsões mensais e semanais"],
"fora_escopo": ["Previsão em tempo real por pedido", "Classificação de produtos baseada em imagem"],
},
}
Saída:
# Executado com sucesso
| Dimensão | Definição | Meta do SalesPredict |
|---|---|---|
| Métrica principal | KPI de desempenho do modelo | MAPE < 10% |
| Métrica de negócio | Medida de valor de negócio | Redução de 20% no custo de estoque |
| SLA | Acordo de nível de serviço | API < 100ms p95 |
| Frescor dos dados | Frequência de atualização dos dados | Lote diário |
| Compliance | Restrições regulatórias | GDPR (dados da UE) |
4. Arquitetura de Dados
(1) Fontes de dados e fluxo de dados
graph TB
ORDERS[DB de Pedidos<br/>Dados de Transação] --> ETL[Pipeline ETL<br/>Lote Diário]
USERS[Perfis de Usuários] --> ETL
PRODUCTS[Catálogo de Produtos] --> ETL
ADLOGS[Logs da Plataforma de Anúncios] --> ETL
ETL --> DATALAKE[Data Lake<br/>S3 / GCS]
DATALAKE --> FEATURE[Feature Store<br/>Features Engenharia]
FEATURE --> TRAIN[Pipeline de Treinamento]
FEATURE --> SERVE[Camada de Serving<br/>Features Online]
SERVE --> API[API de Previsão]
▶ Exemplo: Definições de fontes de dados
data_sources = {
"pedidos": {
"fonte": "PostgreSQL (DB de produção)",
"campos": ["order_id", "user_id", "product_id", "amount_usd", "order_date", "category"],
"volume": "~500k linhas/mês",
"latencia": "T+1 (disponível no dia seguinte)",
},
"usuarios": {
"fonte": "Sistema CRM",
"campos": ["user_id", "region", "segment", "register_date", "lifetime_value"],
"volume": "~50k usuários ativos",
"latencia": "T+1",
},
"ad_spend": {
"fonte": "Google Ads + Facebook Ads API",
"campos": ["date", "channel", "campaign", "spend_usd", "impressions", "clicks"],
"volume": "~10k linhas/mês",
"latencia": "T+2",
},
"catalogo_produtos": {
"fonte": "Sistema PIM",
"campos": ["product_id", "category", "price_usd", "margin_pct", "launch_date"],
"volume": "~5k produtos",
"latencia": "Atualização semanal",
},
}
Saída:
# Executado com sucesso
(2) Design do Feature Store
| Grupo de Features | # Features | Frequência de Atualização | Armazenamento |
|---|---|---|---|
| Features RFM | 12 | Diário | Parquet (offline) + Redis (online) |
| Features de anúncios | 8 | Diário | Parquet |
| Features temporais | 6 | Computado em tempo real | Lógica de código |
| Features de categoria | 5 | Tabela de dimensão semanal | Parquet |
| Estatísticas agregadas | 10 | Diário | Parquet |
5. Arquitetura de Modelos
(1) Roteiro de evolução dos modelos
▶ Exemplo: Definição da arquitetura de modelos
model_architecture = {
"estagio_1_linha_base": {
"modelo": "LinearRegression + Pipeline",
"r2_esperado": "0,72-0,78",
"mape_esperado": "12-15%",
"proposito": "Estabelecer linha de base, validar pipeline de dados",
"cronograma": "Semana 1-2",
},
"estagio_2_avancado": {
"modelo": "XGBoost + Engenharia de Features",
"r2_esperado": "0,85-0,89",
"mape_esperado": "8-10%",
"proposito": "Modelo de produção, atingir meta de MAPE < 10%",
"cronograma": "Semana 3-5",
},
"estagio_3_deep_learning": {
"modelo": "MLP / LSTM (série temporal)",
"r2_esperado": "0,87-0,92",
"mape_esperado": "7-9%",
"proposito": "Melhoria incremental, capturar padrões temporais",
"cronograma": "Semana 6-8",
},
}
Saída:
# Executado com sucesso
| Estágio | Modelo | MAPE | Tempo de Treinamento | Prioridade |
|---|---|---|---|---|
| Estágio 1 | LinearRegression | 12-15% | <1min | P0 |
| Estágio 2 | XGBoost | 8-10% | ~5min | P0 |
| Estágio 3 | MLP/LSTM | 7-9% | ~30min | P1 |
(2) Estratégia de avaliação
evaluation_strategy = {
"metodo_cv": "TimeSeriesSplit(n_splits=5)",
"metrica_primaria": "MAPE",
"metricas_secundarias": ["MAE", "RMSE", "R2"],
"alinhamento_negocio": {
"MAPE_10pct": "Erro de previsão dentro de 10% da receita real",
"MAE_50k": "Erro absoluto médio menor que 50k USD por categoria",
"custo_erro": "1% MAPE ≈ 100k USD de desperdício anual de estoque",
},
"teste_ab": {
"duracao": "3 semanas",
"metrica": "MAPE de previsão de receita vs valores reais",
"tamanho_amostra": "Todas as categorias, todos os mercados",
},
}
6. Arquitetura de Implantação e Papéis da Equipe
(1) Arquitetura de implantação
graph TB
CLIENT[Apps Cliente] --> NGINX[Balanceador Nginx]
NGINX --> API1[Worker FastAPI 1]
NGINX --> API2[Worker FastAPI 2]
API1 --> MODEL[MLflow Model Registry<br/>Modelo de Produção]
API2 --> MODEL
API1 --> REDIS[(Cache Redis)]
API2 --> REDIS
MODEL --> MLFLOW[MLflow Tracking<br/>Histórico de Experimentos]
MLFLOW --> MONITOR[Stack de Monitoramento<br/>Prometheus + Grafana]
MONITOR --> ALERT[Alert Manager<br/>Detecção de Drift]
ALERT --> RETRAIN[Pipeline de Re-treinamento<br/>Airflow/Dagster]
RETRAIN --> MLFLOW
(2) Papéis da equipe
▶ Exemplo: Registro de Riscos
risk_register = {
"qualidade_dados": {
"risco": "Dados brutos têm >5% de valores ausentes em features-chave",
"probabilidade": "Alta",
"impacto": "Crítico - modelo treinado em dados enviesados",
"mitigacao": "Verificações automatizadas de qualidade de dados no pipeline ETL",
"responsavel": "Alice",
},
"sobreajuste_modelo": {
"risco": "XGBoost sobreajusta em amostras pequenas de categoria",
"probabilidade": "Média",
"impacto": "Alto - generalização ruim para novos mercados",
"mitigacao": "TimeSeriesSplit CV, regularização, early stopping",
"responsavel": "Bob",
},
"latencia_api": {
"risco": "API de previsão excede SLA de 100ms sob carga",
"probabilidade": "Média",
"impacto": "Médio - degradação da experiência do usuário",
"mitigacao": "Cache Redis para queries quentes, rate limiting no Nginx",
"responsavel": "Charlie",
},
}
Saída:
# Executado com sucesso
▶ Exemplo: Cronograma do projeto
project_schedule = {
"Semana 1-2: Dados e Linha de Base": {
"Alice": "Pipeline ETL, configuração do data lake, verificações de qualidade dos dados",
"Bob": "EDA, engenharia de features, linha de base LinearRegression",
"Charlie": "Ambiente de dev, configuração do MLflow, pipeline de CI/CD",
},
"Semana 3-5: Modelo Avançado": {
"Alice": "Feature store, camada de serving online, monitoramento de dados",
"Bob": "Treinamento XGBoost, ajuste de hiperparâmetros, avaliação do modelo",
"Charlie": "Scaffold FastAPI, configuração Docker, testes de carga",
},
"Semana 6-8: Deep Learning e Implantação": {
"Alice": "Features em tempo real, detecção de drift de dados",
"Bob": "Experimentos MLP/LSTM, design de teste A/B",
"Charlie": "Implantação em produção, dashboard de monitoramento, alertas",
},
"Semana 9-10: Lançamento e Monitoramento": {
"Alice": "Monitoramento do pipeline de dados, validação de features",
"Bob": "Monitoramento de modelo, pipeline de re-treinamento",
"Charlie": "Execução de teste A/B, rollout gradual, configuração de on-call",
},
}
Saída:
# Executado com sucesso
| Papel | Responsável | Responsabilidades | Entregáveis |
|---|---|---|---|
| Engenharia de Dados | Alice | ETL/data lake/feature store | Pipeline de dados + features |
| Engenharia de ML | Bob | Engenharia de features/treinamento de modelo/avaliação | Melhor modelo + logs de experimentos |
| Backend/DevOps | Charlie | API/implantação/monitoramento | Serviço de produção + monitoramento |
❓ Perguntas Frequentes
P: Quão detalhada deve ser a análise de requisitos? R: No mínimo ela deve incluir — 1) um objetivo de negócio claro com KPIs quantificados; 2) histórias de usuário (quem usa o que para fazer o quê); 3) restrições (latência/compliance/orçamento); 4) limites de escopo (o que está dentro e o que está fora). Requisitos vagos são a principal causa de retrabalho.
P: Um modelo de linha de base é realmente necessário? R: Com certeza. A linha de base estabelece um piso de desempenho e valida o pipeline de dados. Sem ela, você não consegue dizer se uma melhoria do XGBoost veio do modelo ou da correção do pipeline de dados.
P: Quantas pessoas devem estar na equipe? R: Um projeto de ML precisa de pelo menos três pessoas — uma para dados, uma para ML e uma para DevOps. Uma única pessoa full-stack pode funcionar, mas é menos eficiente e cria um ponto único de conhecimento. O importante é que todos os três papéis sejam cobertos, não a quantidade de pessoas.
P: Devemos trabalhar em dados ou no modelo primeiro? R: Dados primeiro. Dados sujos + um bom modelo = resultados lixo. Passe as primeiras uma a duas semanas construindo um pipeline de dados confiável, depois treine modelos. Quanto mais cedo você detectar problemas de dados, mais barato é corrigi-los.
P: Quanto tempo deve durar a fase de design? R: Cerca de 10-15% da duração total do projeto. Gastar uma semana em design para um projeto de oito semanas é razoável. O custo do retrabalho de um design insuficiente excede em muito o custo de uma semana extra de design.
P: Como garantir que o design seja realmente implementado? R: O documento de design deve incluir — 1) entregáveis claros e critérios de aceitação; 2) templates/scaffolding de código; 3) uma estratégia de teste; 4) checkpoints de marcos. Cada marco verifica se o design está sendo executado corretamente.
📖 Resumo
- Os três pilares da análise de requisitos: objetivos quantificados (MAPE < 10%), histórias de usuário e restrições (latência/compliance)
- Arquitetura de dados: fontes de dados → ETL → data lake → feature store → dois caminhos para treinamento e serving
- Evolução da arquitetura de modelos: LinearRegression (linha de base) → XGBoost (cavalo de batalha) → MLP/LSTM (ganhos incrementais)
- Arquitetura de implantação: FastAPI + cache Redis + balanceamento de carga Nginx + gerenciamento de modelos MLflow + monitoramento Prometheus
- Papéis da equipe: Alice (Engenharia de Dados) + Bob (Engenharia de ML) + Charlie (DevOps) colaborando entre três papéis
- Design primeiro, zero retrabalho no desenvolvimento — 10% do tempo em design evita 50% do retrabalho
📝 Exercícios
- Básico (Dificuldade ⭐): Escreva um documento de requisitos para seu próprio projeto de ML, incluindo o objetivo de negócio, métricas de sucesso e limites de escopo. Dica: consulte o modelo de documento de requisitos na Seção 3.
- Intermediário (Dificuldade ⭐⭐): Desenhe um diagrama completo de arquitetura de dados (Mermaid) para o SalesPredict, rotulando cada fonte de dados, etapa ETL e método de armazenamento. Dica: consulte o diagrama de arquitetura de dados na Seção 4.
- Desafio (Dificuldade ⭐⭐⭐): Projete um projeto completo de ML de ponta a ponta — requisitos → dados → modelo → implantação → monitoramento → equipe — e produza um plano de projeto executável (com cronograma e entregáveis). Dica: combine todos os elementos de design das Seções 3-6.
← Anterior: Monitoramento em Produção e Drift de Modelo | Próximo: Desenvolvimento do Projeto →
