Entrar Ainda não tem acesso?
2
respostas

[Projeto] Aula 5 — Carregamento de Dados II (PyTorch): early stopping + melhor modelo restaurado

Referente ao curso Treinando uma Rede Neural: Deep Learning com PyTorch, no capítulo Datasets e Fluxo de Validação e atividade Projeto final do curso

por Carlos Virgílio Beltrão Lessa
| 71.4k xp | 46 posts

Pessoal, compartilho aqui meu notebook da última aula do curso. Mantive a estrutura do material e adicionei mecanismos de reprodutibilidade e treino mais robusto (early stopping + restauração do melhor estado).

O que foi alterado/melhorado

  • Restauração do melhor modelo: importei copy e salvo uma cópia profunda de state_dict() quando a val loss melhora; no fim do treino, restauro os melhores pesos.
  • Hiperparâmetros: lr=1e-3, weight_decay=1e-5, early_stopping_patience=20.
  • Seeds globais: torch.manual_seed, np.random.seed, torch.cuda.manual_seed_all (quando aplicável).
  • Escalonamento: uso StandardScaler apenas nas features, mantendo o alvo na escala original; isso ajuda a estabilizar gradientes antes de reduzir a taxa de aprendizado.
  • Early stopping: monitora a menor loss de validação, interrompe após 20 épocas sem melhora real e restaura os pesos da “época campeã”.

Resultados (resumo dos logs)

Local (CPU)

  • Melhor época: 185 — val loss 28.6814.
  • Treino foi até a época 199 (limite), e no final restaurei o estado da época 185.

Colab (GPU / CUDA)

  • Early stopping ativado na época 132.
  • Melhor época: 112 — val loss 27.6826.
  • Modelo restaurado para a época 112.

Os tempos por época e desvios padrão estão nos logs do notebook.

Nota sobre reprodutibilidade

Mesmo com seeds fixas, ao usar DataLoader(num_workers>0) os batches podem ser embaralhados em threads diferentes; além disso, CPU x GPU podem divergir levemente (FMA, kernels do cuDNN, etc.). Por isso é comum a “época campeã” mudar entre ambientes.

Espero que ajude quem está fechando o curso e quer métricas/logs mais confiáveis para comparar execuções.

Matricule-se agora e aproveite até 50% OFF

O maior desconto do ano para você evoluir com a maior escola de tecnologia

QUERO APROVEITAR
2 respostas
por Monalisa Meyrelle de Sousa Silva
| 3377.6k xp | 7630 posts
Alura Scuba Team

Oi, Carlos! Como vai?

Agradeço por compartilhar seus aprendizados com a comunidade Alura.

Gostei da forma como você aprimorou o projeto, incluindo early stopping e restauração do melhor modelo, esses ajustes tornam o treinamento mais eficiente e garantem resultados mais estáveis. Sua observação sobre reprodutibilidade entre CPU e GPU mostra um excelente entendimento das nuances práticas do PyTorch.

Continue explorando essas melhorias! Conte com o apoio do Fórum na sua jornada. Abraços e bons estudos!

Ícone de sugestão Para saber mais:

Sugestão de conteúdo para você mergulhar:

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!
por Carlos Virgílio Beltrão Lessa
| 71.4k xp | 46 posts

Oi, Monalisa! Obrigado pelo incentivo — fico feliz que você tenha curtido o early stopping, a restauração dos melhores pesos e as notas de reprodutibilidade CPU/GPU.
Para complementar a discussão, deixo abaixo uma revisão do bloco de features e do pipeline que estou aplicando no Bike Sharing (hour.csv) — pode ajudar a evitar inconsistências no treino de modelos.

Pessoal,

Ao revisar o notebook da aula do Bike Sharing Dataset (base hour.csv), notei alguns pontos de engenharia de variáveis e higiene do pipeline que valem atenção — especialmente para evitar inconsistências ao treinar modelos.

Split temporal e escalonamento

  • Divisão por tempo: treinar no passado e validar/testar no futuro.
  • Escalonar com StandardScaler (ou similar) fitado só no treino e aplicado em validação/teste.

Holiday vs Workingday

  • holiday e workingday são binárias, mas não são complementares. Fim de semana costuma ser holiday=0 e workingday=0.
    Ressalva: feriados oficiais que caem no fim de semana aparecem com holiday=1.
  • Sugestão: manter holiday (0/1), derivar is_weekend a partir de weekday e dropar workingday (redundante quando já controlamos feriado e fim de semana separadamente).
  • Binárias podem seguir como 0/1 (não precisa one-hot).

Codificação cíclica e categóricas

  • Cíclicas: hr (24h), weekday (7), mnth (12) → sen/cos para preservar periodicidade.
  • Categóricas: season, weathersit → one-hot.

Seleção de colunas por nome (evitar iloc por posição)

  • Para não "pegar colunas erradas" se a ordem mudar, prefirir lista de inclusão (o que entra) ou lista de exclusão (o que sai).
  • Observação importante: casual e registered não devem ser usadas como features para prever cnt, porque cnt = casual + registered (vazamento).
  • Atenção ao arquivo: o day.csv não tem exatamente as mesmas colunas do hour.csv (por exemplo, não possui hr). Isso reforça a seleção por nome.

Nota: o tripé da Ciência de Dados (Matemática/Estatística, Computação e Negócio)

É fácil focar no "lado técnico" (pipeline, PyTorch, métricas) e deixar de checar o dado e o contexto de negócio. Este caso ilustra bem:

  • Matemática/Estatística: entender periodicidade, escolher perdas adequadas a contagens e evitar dependências determinísticas.
  • Computação: pipelines reprodutíveis (fit no treino, features por nome, lags/rollings sem "olhar o futuro").
  • Negócio: interpretar corretamente dia útil, feriado e fim de semana — e como isso afeta a demanda real.

Moral da história: antes de "apertar o botão do treino", fazer uma passada de sanidade de negócio:

  • confirmar dicionário de dados e regras (o que é "working day" aqui?);
  • procurar relações determinísticas com a target;
  • simular o ambiente de produção (essas features estarão disponíveis na hora da previsão?);
  • e só então partir para a modelagem.