A maior parte dos projetos de ML não morre por falta de um modelo bom. Morre por descuido nas coisas chatas: dado que vaza, experimento que ninguém reproduz, modelo em produção apodrecendo em silêncio. As boas práticas abaixo são justamente sobre essas coisas chatas — e são elas que separam um protótipo bonitinho de um sistema que aguenta o tranco.
Comece com um baseline burro
Antes de puxar a artilharia pesada, construa a versão mais idiota possível do seu preditor. Chutar a média, prever sempre a classe majoritária, aplicar uma regra de negócio de duas linhas. Parece bobagem, mas esse baseline te dá a única coisa que importa no começo: um número real para superar.
Muita gente treina um modelo complexo, vê 87% de acurácia e comemora. Aí descobre que prever "sempre não" já dava 86%. Sem baseline, você não faz ideia se o seu modelo está aprendendo algo ou apenas decorando o óbvio.
Divida os dados com honestidade
Data leakage é o erro mais caro e mais silencioso de ML. É quando informação do futuro (ou do conjunto de teste) escapa para o treino e infla suas métricas. O modelo parece genial no notebook e desaba em produção.
A regra é simples de dizer e fácil de furar: separe treino, validação e teste antes de tocar nos dados. Normalização, imputação de faltantes, seleção de features — tudo isso se ajusta só no treino e depois se aplica aos outros conjuntos. Se você tem dados temporais, divida por tempo, nunca aleatoriamente; prever o passado com informação do futuro é trapaça. E cuidado com features que só existem depois do evento que você quer prever: elas são um vazamento disfarçado de ouro.
Rastreie seus experimentos
Sem rastreamento, você vai se enganar. É garantido. Depois de vinte rodadas mexendo em hiperparâmetro, features e seed, ninguém lembra qual combinação gerou aquele resultado bom de três dias atrás.
Guarde, para cada experimento: versão dos dados, código (commit), hiperparâmetros, métricas e o artefato do modelo. Pode ser MLflow, Weights & Biases ou uma planilha teimosa — a ferramenta importa menos que o hábito. O teste de fogo é honesto: você consegue reproduzir o número que colocou no relatório? Se a resposta for "acho que sim", a resposta é não.
Modelo simples primeiro, sempre
Existe uma vontade quase irresistível de já começar com a arquitetura mais nova que você viu no Twitter. Resista. Regressão logística, árvores e gradient boosting resolvem uma quantidade absurda de problemas reais — e vêm com bônus que deep learning cobra caro: treinam rápido, são mais fáceis de depurar e você consegue explicar para o time por que o modelo decidiu o que decidiu.
Complexidade é um custo, não uma medalha. Cada camada a mais é mais coisa para quebrar, mais lenta para servir e mais difícil de investigar quando a métrica cai. Suba a complexidade só quando o modelo simples travar de vez — e quando isso acontecer, você vai ter o baseline forte para provar que valeu a pena.
Produção não é a linha de chegada
Colocar o modelo no ar é o meio do caminho, não o fim. O mundo muda, o comportamento dos usuários muda, os dados de entrada mudam — e o modelo, coitado, não sabe de nada disso. Isso é drift, e ele corrói sua performance devagar, sem estourar nenhum alarme óbvio.
Monitore as distribuições de entrada e as métricas de negócio, não só a acurácia offline. Defina gatilhos de retreino e tenha um plano de rollback para quando um modelo novo sair pior que o antigo. Um modelo sem monitoramento é uma dívida técnica que rende juros em silêncio.
Saiba quando NÃO usar ML
A melhor prática de ML, às vezes, é não usar ML. Se um if resolve, use o if. Se uma regra de negócio, uma consulta SQL ou uma heurística simples entregam o resultado, você acabou de economizar meses de coleta de dados, treino, deploy e manutenção de um sistema que precisa ser vigiado para sempre.
ML faz sentido quando o padrão é complexo demais para escrever à mão, quando você tem dado de qualidade em volume e quando errar de vez em quando é aceitável. Não faz sentido quando você precisa de garantia determinística, quando não tem dados, ou quando o problema é, no fundo, um if com roupa de gala.
No fim, boas práticas de ML são quase todas sobre disciplina, não sobre esperteza. Baseline, dados honestos, experimentos rastreados, simplicidade e vigilância em produção não aparecem no paper nem impressionam ninguém no café — mas são exatamente o que faz o seu modelo sobreviver ao contato com o mundo real.