Scripts de treino costumam parecer pequenos demais para a quantidade de decisões que carregam. Este projeto é um bom exemplo disso.
Por trás de poucos parâmetros existe uma cadeia inteira de escolhas sobre transfer learning, augmentation, otimização, estabilidade de hardware e custo de experimento.
Comece por Transfer Learning, Não por Heroísmo
O repositório parte de pesos pré-treinados do YOLOv11:
Essa única linha já concentra boa parte da vantagem do projeto.
Transfer learning faz sentido porque o dataset é customizado e relativamente pequeno. Em vez de aprender visão computacional do zero, o modelo reaproveita features já aprendidas e as adapta às regiões semânticas das cartas.
Por Que YOLOv11n?
Há uma decisão madura aqui: começar pequeno, iterar rápido e só depois questionar o teto.
Faz sentido porque:
- o número de classes é limitado
- o dataset não é gigantesco
- velocidade de iteração vale muito
- custo de experimento também conta
Os experimentos em cloud reforçam esse ponto. Modelos maiores e resoluções maiores não ganharam de forma consistente. Isso é importante porque obriga o projeto a olhar para o gargalo real, e não para a fantasia de que "mais modelo" sempre resolve.
As Augmentations Têm Propósito
O documento training-strategies.md é um dos melhores do repositório porque liga teoria e prática. As augmentations não estão ali para deixar o treino "mais sofisticado". Cada uma responde a um modo de falha plausível do mundo real.
Mosaic
Mosaic aumenta a diversidade de contexto e ajuda principalmente em casos com objetos pequenos e composição variada de cena.
Mixup
Mixup ajuda a reduzir overconfidence e dependências ruins do fundo. Ele força o modelo a generalizar melhor em vez de decorar padrões fáceis demais.
Multi-scale
Multi-scale simula uma condição inevitável de uso real: distância variável da webcam, recorte imperfeito e enquadramentos inconsistentes.
Rotação, perspectiva, shear, HSV e erasing
Essas transformações fazem sentido porque cartas reais aparecem inclinadas, com iluminação inconsistente, parcialmente encobertas e em escalas diferentes.
O melhor ponto aqui é o seguinte: augmentation boa não é a que parece sofisticada. É a que corresponde a problemas que o produto realmente vai encontrar.
Otimização e Estabilidade
O projeto usa AdamW, cosine LR e early stopping. É um conjunto coerente para fine-tuning:
- AdamW costuma funcionar bem em datasets menores
- cosine decay ajuda a suavizar o refinamento
- early stopping evita insistir quando o ganho marginal já desapareceu
Outro ponto importante é o treino local em CPU por questões de estabilidade no stack usado com Apple Silicon. Essa decisão pode parecer conservadora, mas é exatamente o tipo de pragmatismo que separa um experimento bonito de um pipeline confiável.
Cloud Não É Mágica
Os experimentos em RunPod são valiosos porque mostram uma verdade pouco glamourosa: mais GPU, mais resolução e mais parâmetros não significam automaticamente melhor resultado.
Se o teto do sistema estiver na qualidade dos labels, um modelo maior pode apenas memorizar melhor esse limite. Nesse contexto, escalar infraestrutura não corrige o problema principal.
O Que o Histórico de Experimentos Ensina
O repositório deixa um aprendizado muito claro:
- transfer learning foi a base do desempenho
- augmentations ajudaram porque refletiam o mundo real
- estabilidade do ambiente de treino importou mais do que throughput teórico
- escalar o modelo não foi a alavanca mais forte
Isso é exatamente o tipo de conclusão útil que um bom projeto de ML deveria produzir.
Conclusão
O treinamento deste detector funciona porque as escolhas se reforçam mutuamente. Não há fetiche por complexidade. Há alinhamento entre dados, arquitetura, hardware, custo e avaliação.
Na próxima parte, vamos ler as métricas como engenheiros, e não como espectadores de benchmark.
Leituras adicionais
- Estratégias de treino:
docs/training-strategies.md - Parâmetros:
docs/parameters.md - Status dos experimentos:
docs/training-v2-status.md