Artigo 3.4 — Série: Como as máquinas aprendem - Treino, validação e teste

Por que um modelo não aprende de verdade se for avaliado apenas nos dados que já viu

Índice

1. Lide
2. Introdução: o erro mais comum na compreensão do treinamento
3. O que significa dividir os dados
4. Conjunto de treino: onde o modelo aprende
5. Conjunto de validação: onde o modelo é ajustado
6. Conjunto de teste: onde o modelo é realmente examinado
7. Por que avaliar no treino engana
8. Overfitting, underfitting e generalização
9. Validação cruzada: quando uma única divisão não basta
10. Vazamento de dados: quando o modelo aprende o que não deveria saber
11. Exemplo didático 1: corrigindo provas
12. Exemplo didático 2: prever evasão escolar
13. Exemplo real 1: fraude em cartão de crédito
14. Exemplo real 2: classificação de imagens
15. Por que essa separação importa no debate público
16. Conclusão
17. Referências

Lide

Uma das confusões mais frequentes sobre machine learning é imaginar que um modelo “aprende” em um único bloco contínuo e que basta ele ir bem nos dados que recebeu para estar pronto. Não basta. Em qualquer prática séria de modelagem, os dados precisam ser separados, ao menos conceitualmente, em três momentos diferentes: treino, validação e teste. O Google explica que o conjunto original deve ser subdividido justamente para que o modelo seja treinado em uma parte e examinado em outras partes, enquanto o scikit-learn enfatiza validação cruzada e avaliação de desempenho como componentes centrais da modelagem. Em termos simples, treino é onde o modelo aprende, validação é onde ele é ajustado, e teste é onde se verifica se ele realmente funciona em dados novos. Sem essa separação, a máquina pode parecer inteligente quando, na verdade, apenas decorou o material que já viu. 

Introdução: o erro mais comum na compreensão do treinamento

Quando se fala em treinamento de modelos, muita gente imagina um processo linear: alimentam-se dados, o algoritmo aprende e, ao final, surge um sistema pronto para uso. Essa imagem é cômoda, mas incompleta. O verdadeiro problema do machine learning não é apenas aprender a partir de dados; é aprender de um jeito que funcione também fora dos dados usados no aprendizado. O Google é explícito ao afirmar que testar o modelo em exemplos diferentes daqueles usados no treinamento é uma prova mais forte de sua adequação do que testá-lo nos mesmos exemplos. 

Essa observação muda tudo. Ela mostra que desempenho no treino não é sinônimo de capacidade real. Um modelo pode acertar muito os exemplos que já viu e, ainda assim, fracassar diante de situações novas. O scikit-learn organiza sua documentação de avaliação justamente em torno dessa preocupação com estimar desempenho em dados não vistos, e o TensorFlow, ao tratar de overfitting e underfitting, também distingue explicitamente perda de treino e perda de validação. 

É por isso que a divisão entre treino, validação e teste é tão importante. Ela não é uma formalidade acadêmica. É um mecanismo de honestidade metodológica. Serve para impedir que a máquina seja aprovada por conhecer apenas o passado imediato do conjunto de dados. 

O que significa dividir os dados

Dividir os dados significa separar o conjunto disponível em subconjuntos com funções diferentes. O Google descreve a divisão clássica em treinamento, validação e teste como a forma tradicional de obter exemplos diferentes para treinar e depois avaliar o modelo. O scikit-learn complementa isso com uma estrutura mais ampla de validação cruzada e avaliação de desempenho. 

Cada subconjunto cumpre um papel específico. O treino serve para ajustar o modelo. A validação serve para comparar versões, ajustar hiperparâmetros e observar sinais de sobreajuste. O teste serve para fornecer uma medida final mais honesta do comportamento do sistema em exemplos que permaneceram afastados do processo de ajuste. Essa estrutura é consistente com o modo como Google, TensorFlow e scikit-learn apresentam o ciclo básico de desenvolvimento de modelos. 

O ponto decisivo é este: os três conjuntos não são intercambiáveis. Misturá-los ou usá-los de forma errada compromete a credibilidade da avaliação. Se o modelo vê, direta ou indiretamente, aquilo que deveria servir para avaliá-lo, o resultado fica artificialmente otimista. É isso que a documentação do scikit-learn chama de vazamento de dados. 

Conjunto de treino: onde o modelo aprende

O conjunto de treino é a parte dos dados usada para ajustar os parâmetros internos do modelo. É ali que a máquina vê exemplos, calcula erros, modifica pesos, define fronteiras, escolhe divisões ou aprende estruturas matemáticas. O Google apresenta esse subconjunto como a base a partir da qual o modelo efetivamente aprende padrões. 

Em termos simples, o treino é o momento da aprendizagem formal. Numa rede neural, isso significa atualizar pesos por backpropagation; numa regressão, ajustar coeficientes; numa árvore, definir divisões; numa floresta, construir múltiplas árvores; num modelo de linguagem, ajustar a probabilidade de sequência. A forma exata varia conforme o algoritmo, mas a função do conjunto de treino permanece a mesma: fornecer o material a partir do qual o sistema modifica sua estrutura interna. Essa é uma inferência metodológica compatível com o papel atribuído ao treino nas fontes consultadas. 

Mas aqui já aparece um primeiro cuidado. O treino precisa ser representativo e suficientemente diverso, porque o modelo só pode aprender a partir do que recebeu. Se o conjunto for estreito, desequilibrado ou mal organizado, a aprendizagem já nasce limitada. O tutorial do TensorFlow sobre dados desbalanceados mostra, por exemplo, como classes raras exigem atenção especial no processo de aprendizado. 

Conjunto de validação: onde o modelo é ajustado

O conjunto de validação é a parte dos dados usada para acompanhar o comportamento do modelo durante o desenvolvimento e tomar decisões sobre ele. O Google trata explicitamente treino, validação e teste como partes distintas do processo. O TensorFlow, em seu tutorial sobre overfit e underfit, mostra graficamente a comparação entre perda de treino e perda de validação, destacando que uma validação pior do que o treino pode sinalizar problemas de generalização. 

A validação existe porque o modelo não é apenas treinado; ele também é configurado. Número de camadas, profundidade de árvore, força da regularização, escolha de kernel, taxa de aprendizado, número de vizinhos, limiares de decisão e muitos outros aspectos precisam ser ajustados. O scikit-learn afirma, inclusive, que é possível e recomendado procurar hiperparâmetros que maximizem o desempenho de validação. 

Em termos didáticos, a validação funciona como uma banca intermediária. O modelo ainda está em construção, e a validação ajuda a dizer qual versão parece melhor sem consumir o teste final. Se o teste for usado repetidamente durante esse processo, ele deixa de ser teste e passa a virar parte do ajuste. É por isso que a separação conceitual entre validação e teste é tão importante. 

Conjunto de teste: onde o modelo é realmente examinado

O conjunto de teste é o último tribunal do modelo. Ele deve permanecer, tanto quanto possível, isolado das decisões de treinamento e ajuste. O Google enfatiza que o teste em exemplos não vistos é a evidência mais forte de adequação do modelo. O scikit-learn segue a mesma lógica ao tratar a avaliação fora do treino como base para estimar desempenho real. 

O valor do teste está justamente em sua distância metodológica. O modelo não deve ter aprendido diretamente com esses exemplos, nem ter sido calibrado a partir deles. Quando isso é respeitado, o resultado do teste oferece uma estimativa mais honesta de como o sistema se comportará em produção. O Google acrescenta ainda um alerta importante: se houver duplicatas entre treino e validação ou entre treino e teste, essas duplicatas devem ser removidas, porque não é uma avaliação justa confrontar o modelo com exemplos que já viu em essência. 

Essa observação é valiosíssima. Em linguagem simples, o teste só vale como teste se for realmente novo. Caso contrário, o que parece ser generalização pode ser apenas repetição disfarçada. 

Por que avaliar no treino engana

Avaliar o modelo no mesmo conjunto em que ele foi treinado tende a inflar artificialmente a sensação de sucesso. O scikit-learn e o Google convergem em dizer que a prova relevante é o desempenho em dados não vistos. Quando o modelo é avaliado apenas no treino, ele pode estar sendo recompensado por memorizar peculiaridades locais, não por aprender estruturas robustas. 

A analogia mais simples é escolar. Imagine um professor que ensina dez exercícios e depois aplica exatamente os mesmos dez na prova final. Um aluno pode ir muito bem sem ter aprendido o conteúdo de fato; talvez apenas tenha decorado o padrão. Com modelos ocorre algo semelhante. Se o sistema é treinado e julgado no mesmo material, o desempenho parece ótimo, mas a capacidade de lidar com casos novos permanece incerta. Essa analogia é didática, mas fiel à lógica das fontes. 

É por isso que o treino, sozinho, não prova nada de decisivo sobre o valor prático do modelo. O que importa não é apenas o quanto ele se ajusta ao passado, mas o quanto se sustenta diante do novo. 

Overfitting, underfitting e generalização

O TensorFlow descreve overfitting e underfitting como dois problemas centrais do aprendizado. Underfitting ocorre quando o modelo é simples demais ou mal treinado e falha tanto no treino quanto na validação. Overfitting ocorre quando o modelo se ajusta bem demais ao treino, mas a perda de validação piora, indicando que ele não generaliza bem. 

A generalização é o conceito que resolve essa tensão. Generalizar significa funcionar razoavelmente bem em dados que o modelo não viu durante o ajuste. O Google, ao tratar de subdivisão de datasets, reforça exatamente esse princípio ao defender o uso de treino, validação e teste. 

Isso permite entender por que a divisão dos dados não é apenas operacional, mas conceitual. Ela torna visível a diferença entre decorar e aprender. Se o desempenho do treino sobe e o da validação cai, o modelo está ficando mais “esperto” apenas dentro do seu passado imediato. Se ambos evoluem de forma consistente, há sinal melhor de generalização. 

Validação cruzada: quando uma única divisão não basta

Em muitos cenários, uma única divisão entre treino e validação pode ser insuficiente ou muito sensível ao acaso. O scikit-learn dedica uma seção inteira à validação cruzada como estratégia para avaliar estimadores em diferentes partições dos dados. Também oferece funções como cross_val_score e cross_validate para estimar o desempenho do modelo em múltiplas divisões. 

A ideia é elegante. Em vez de confiar em uma única separação potencialmente acidental, o modelo é treinado e avaliado várias vezes em partições diferentes. Isso tende a fornecer uma estimativa mais estável do seu comportamento médio. Além disso, ajuda na comparação entre modelos e na escolha de hiperparâmetros. O scikit-learn recomenda justamente a busca por hiperparâmetros com base em pontuação de validação cruzada. 

Em linguagem simples, a validação cruzada funciona como repetir a prova em versões levemente diferentes para ver se o bom desempenho se sustenta. Ela não substitui toda a lógica de treino/validação/teste em todos os contextos, mas reforça a robustez da avaliação. 

Vazamento de dados: quando o modelo aprende o que não deveria saber

O scikit-learn define vazamento de dados de maneira muito clara: ele ocorre quando informações que não estariam disponíveis no momento da predição acabam sendo usadas na construção do modelo, produzindo estimativas de desempenho excessivamente otimistas. A documentação também alerta para vazamento durante o pré-processamento e recomenda o uso correto de pipelines. 

Esse é um dos problemas mais perigosos e menos intuitivos para iniciantes. O modelo pode parecer excelente não porque aprendeu de forma legítima, mas porque recebeu pistas indevidas sobre o futuro. Isso pode acontecer, por exemplo, quando a normalização é ajustada com base em todos os dados antes da separação, quando variáveis derivadas contêm informação do alvo futuro ou quando há duplicatas entre treino e teste. O Google já chamou atenção para esse último caso na subdivisão do dataset. 

Em termos didáticos, vazamento é como deixar respostas anotadas no canto da folha e depois elogiar o aluno por ter acertado tudo. O resultado impressiona, mas é falso. 

Exemplo didático 1: corrigindo provas

Imagine um professor que quer avaliar se os alunos aprenderam frações. Ele ensina 100 exercícios resolvidos. Se a prova final contiver exatamente os mesmos 100 exercícios, muitos alunos irão bem. Mas isso não prova que dominam o tema; talvez tenham apenas memorizado o padrão. Agora imagine que a prova final contenha exercícios diferentes, porém do mesmo conteúdo. Aí sim a avaliação fica mais séria.

O conjunto de treino funciona como os exercícios resolvidos em sala. O conjunto de validação funciona como um simulado usado para ajustar a estratégia de estudo. O conjunto de teste é a prova final. Se o estudante tiver acesso antecipado à prova final, a avaliação deixa de medir aprendizagem real. Essa analogia resume com clareza a lógica defendida pelo Google e pelo scikit-learn para a separação entre treino, validação e teste. 

Exemplo didático 2: prever evasão escolar

Suponha um modelo construído para prever evasão escolar. Há dados históricos sobre frequência, notas, atrasos e uso do ambiente virtual. O conjunto de treino inclui registros de anos anteriores e serve para ensinar o modelo. O conjunto de validação ajuda a escolher, por exemplo, quantas árvores usar numa floresta aleatória ou qual limiar de decisão adotar. O conjunto de teste contém estudantes que o modelo nunca viu durante o ajuste. Só aí se mede se a previsão realmente funciona. Essa estrutura é compatível com a lógica geral de treino, validação e teste descrita nas documentações técnicas consultadas. 

Se o sistema for ajustado olhando repetidamente para o teste, ele pode acabar “decorando” aquele conjunto. E, se uma variável do futuro, como “status final lançado no sistema”, entrar indevidamente no treino, haverá vazamento. Nesse caso, o modelo parecerá ótimo, mas será enganoso. O conceito de vazamento do scikit-learn se aplica exatamente a esse tipo de erro. 

Exemplo real 1: fraude em cartão de crédito

O tutorial do TensorFlow sobre classificação em dados desbalanceados usa um exemplo real de detecção de fraude em cartão de crédito, com 492 transações fraudulentas em 284.807 transações totais. Esse caso é excelente para mostrar por que a separação entre treino, validação e teste importa tanto. Em problemas assim, um modelo pode parecer bom só porque quase tudo é não fraude; por isso, além da divisão correta dos dados, é preciso olhar métricas adequadas. 

Se esse tipo de modelo fosse treinado e testado no mesmo conjunto, ou se o pré-processamento vazasse informação do conjunto completo, a sensação de desempenho seria artificial. Como fraude é evento raro, qualquer exagero na avaliação pode produzir falsa confiança institucional. Esse exemplo mostra que a divisão de dados não é apenas uma exigência acadêmica: ela tem consequências reais sobre sistemas financeiros. 

Exemplo real 2: classificação de imagens

O TensorFlow oferece um tutorial de classificação de imagens de roupas com tf.keras, e também um tutorial de classificação de gatos e cachorros por transfer learning. Em ambos, há separação entre dados usados para treinar e dados usados para avaliar o comportamento do modelo. Isso permite verificar se a rede aprendeu padrões gerais de imagem e não apenas detalhes específicos das fotos vistas no ajuste. 

Esse exemplo é didaticamente poderoso porque deixa muito claro o perigo da memorização. Uma rede profunda pode aprender muito rapidamente detalhes do conjunto de treino. Sem validação e teste, seria fácil concluir que ela “entendeu” a tarefa, quando talvez só tenha se adaptado aos exemplos específicos. O próprio TensorFlow, ao tratar de overfit e underfit, usa a comparação entre treino e validação para tornar visível esse risco. 

Por que essa separação importa no debate público

À primeira vista, treino, validação e teste parecem um assunto técnico restrito a engenheiros e cientistas de dados. Não são. Essa separação importa publicamente porque muitos sistemas algorítmicos já influenciam crédito, saúde, educação, segurança, consumo e recomendação. Quando um modelo é anunciado como “preciso” ou “inteligente”, a pergunta decisiva deveria ser: preciso em quê, medido como, em quais dados e sob qual protocolo de avaliação? O scikit-learn e o Google deixam claro que sem avaliação adequada em dados não vistos não há boa evidência de desempenho real. 

Isso significa que o debate democrático sobre algoritmos precisa ir além do resultado bruto. Um modelo pode parecer ótimo porque foi mal testado, porque houve vazamento ou porque o conjunto de avaliação não representa o mundo real. O Google observa inclusive que, se o conjunto de validação divergir do dado ao vivo, é preciso atualizá-lo. 

Em outras palavras, a forma como se divide e se usa os dados já é parte da política de confiabilidade de um sistema. Não se trata apenas de estatística; trata-se de legitimidade. 

Conclusão

A distinção entre treino, validação e teste é uma das chaves mais importantes para compreender o machine learning de forma séria. O treino é onde o modelo aprende. A validação é onde ele é ajustado. O teste é onde ele é realmente examinado. Confundir esses papéis produz ilusões de desempenho, falsa confiança e, muitas vezes, sistemas que parecem brilhantes no laboratório, mas fracassam no mundo real. O Google, o scikit-learn e o TensorFlow convergem precisamente nesse ponto: sem dados não vistos e sem avaliação metodologicamente correta, não há boa evidência de generalização. 

No fim, compreender essas três fases não é apenas entender uma etapa operacional do desenvolvimento de modelos. É perceber que o verdadeiro aprendizado de máquina não se mede pelo quanto um algoritmo se ajusta ao passado, mas pelo quanto consegue responder com consistência ao novo. E isso muda a qualidade da conversa pública sobre inteligência artificial, porque devolve à avaliação aquilo que o entusiasmo tecnológico frequentemente tenta apagar: método, prudência e honestidade inferencial. 

Referências

GOOGLE. Dividing the original dataset. Google Developers, 2025. Disponível em: https://developers.google.com/machine-learning/crash-course/overfitting/dividing-datasets. Acesso em: 30 mar. 2026. 

GOOGLE. Datasets, generalization, and overfitting. Google Developers, 2025. Disponível em: https://developers.google.com/machine-learning/crash-course/overfitting. Acesso em: 30 mar. 2026. 

GOOGLE. Step 3: Prepare your data. Google Developers, 2025. Disponível em: https://developers.google.com/machine-learning/guides/text-classification/step-3. Acesso em: 30 mar. 2026. 

GOOGLE. ML pipelines. Google Developers, 2025. Disponível em: https://developers.google.com/machine-learning/managing-ml-projects/pipelines. Acesso em: 30 mar. 2026. 

GOOGLE. Deployment testing. Google Developers, 2025. Disponível em: https://developers.google.com/machine-learning/crash-course/production-ml-systems/deployment-testing. Acesso em: 30 mar. 2026. 

SCIKIT-LEARN DEVELOPERS. Cross-validation: evaluating estimator performance. Scikit-learn Documentation, 2026. Disponível em: https://scikit-learn.org/stable/modules/cross_validation.html. Acesso em: 30 mar. 2026. 

SCIKIT-LEARN DEVELOPERS. Common pitfalls and recommended practices. Scikit-learn Documentation, 2026. Disponível em: https://scikit-learn.org/stable/common_pitfalls.html. Acesso em: 30 mar. 2026. 

SCIKIT-LEARN DEVELOPERS. Metrics and scoring: quantifying the quality of predictions. Scikit-learn Documentation, 2026. Disponível em: https://scikit-learn.org/stable/modules/model_evaluation.html. Acesso em: 30 mar. 2026. 

SCIKIT-LEARN DEVELOPERS. Tuning the hyper-parameters of an estimator. Scikit-learn Documentation, 2026. Disponível em: https://scikit-learn.org/stable/modules/grid_search.html. Acesso em: 30 mar. 2026. 

TENSORFLOW. Overfit and underfit. TensorFlow Core, 2024. Disponível em: https://www.tensorflow.org/tutorials/keras/overfit_and_underfit. Acesso em: 30 mar. 2026. 

TENSORFLOW. Training & evaluation with the built-in methods. TensorFlow Guide, 2023. Disponível em: https://www.tensorflow.org/guide/keras/training_with_built_in_methods. Acesso em: 30 mar. 2026. 

TENSORFLOW. Classification on imbalanced data. TensorFlow Core, 2024. Disponível em: https://www.tensorflow.org/tutorials/structured_data/imbalanced_data. Acesso em: 30 mar. 2026. 

TENSORFLOW. Basic classification: classify images of clothing. TensorFlow Tutorials, 2024. Disponível em: https://www.tensorflow.org/tutorials/keras/classification. Acesso em: 30 mar. 2026. 

TENSORFLOW. Transfer learning and fine-tuning. TensorFlow Tutorials, 2024. Disponível em: https://www.tensorflow.org/tutorials/images/transfer_learning. Acesso em: 30 mar. 2026.