#04 — Como testar uma IA sem deixar que ela veja a prova antes

Série IA sem mistério · #04 de 06. Veja a ordem completa de leitura.

Na segunda-feira, a equipe de Bruno comemorou. O sistema que previa quais pedidos precisariam de ajuda acertara quase todos os exemplos do teste. Na sexta, já em uso, ele começou a falhar justamente nos pedidos mais difíceis. Bruno abriu os dados para entender o que acontecera e encontrou uma pista: entre as informações oferecidas à IA havia um campo preenchido depois que o problema do cliente era resolvido.

Para uma pessoa, seria como fazer uma prova de adivinhação com o gabarito aparecendo no canto da folha. O resultado parece brilhante. A capacidade de prever, porém, continua desconhecida.

A história de Bruno é fictícia. O erro que ela mostra tem nome: vazamento de dados. É uma das razões pelas quais testar uma IA exige mais cuidado do que apertar um botão e ler uma porcentagem.

Primeiro, separe os exemplos

Imagine que Bruno tenha registros de pedidos antigos. Alguns precisaram de atenção extra; outros seguiram sem problemas. Para construir um sistema que antecipe essa necessidade, ele divide os registros em três grupos.

1. Treino: exemplos com que o sistema aprende a reconhecer padrões.
2. Validação: exemplos usados pela equipe para comparar versões do sistema e ajustar suas escolhas.
3. Teste final: exemplos reservados até que essas escolhas terminem. É a hora de conferir o resultado com casos que não guiaram a construção.

Essa separação ajuda a responder uma pergunta muito concreta: o sistema aprendeu a lidar com pedidos novos ou apenas se saiu bem com os pedidos que influenciaram suas escolhas? A aula 5 do curso de Machine Learning de Paulo Orenstein, no IMPA, apresenta esse papel de treino, validação e teste.

Por que a validação existe?

Bruno experimenta duas versões. Uma leva em conta poucos sinais, como tipo de pedido e prazo. Outra usa mais informações e tem mais ajustes. Ele precisa escolher qual funciona melhor. É para isso que serve o grupo de validação: experimentar sem mexer no teste final.

Se ele olhar o teste, fizer uma mudança, olhar de novo e repetir até gostar do número, aquele conjunto deixou de ser uma surpresa. Mesmo sem colocar seus registros diretamente no treino, Bruno passou a usá-los para tomar decisões. O placar final fica otimista.

É parecido com um estudante que recebe uma lista de questões para praticar, outra para verificar onde ainda erra e uma prova ao fim. Se o professor revelar a prova a cada tentativa, ela deixa de medir o que o estudante consegue fazer diante de questões desconhecidas.

Quando o gabarito entra pela porta dos fundos

O campo que Bruno encontrou indicava se o atendimento terminara com uma correção manual. Nos registros antigos, isso combinava fortemente com os pedidos problemáticos. Só havia um detalhe: no momento em que a IA teria de avisar a equipe, a correção ainda não tinha acontecido. Essa informação não existiria no uso real.

Remover esse campo é o começo. O vazamento também pode ser menos óbvio. Se registros muito parecidos do mesmo cliente caírem em grupos diferentes, o teste pode parecer mais fácil do que encontrar um cliente novo. Se a equipe selecionar as informações “mais promissoras” olhando todos os dados antes de dividi-los, parte da resposta do teste pode influenciar a seleção.

Por isso, qualquer escolha aprendida com os dados deve usar somente a parte disponível para aquela etapa. A aula do IMPA mostra um exemplo em que selecionar variáveis antes da validação cruzada produz um erro aparentemente excelente mesmo quando não há sinal útil. Ao refazer a seleção dentro de cada rodada, o resultado volta a refletir a dificuldade real.

E se há poucos exemplos?

Uma única divisão pode depender demais de quais pedidos caíram em cada grupo. A validação cruzada ajuda a reduzir essa dependência: a equipe divide os dados de desenvolvimento em partes e repete a avaliação, alternando a parte reservada para conferir o modelo. Depois reúne os resultados.

Não é um passe de mágica. Se os dados antigos não representam os pedidos de amanhã, repetir a divisão não resolve. E, quando o tempo importa, embaralhar registros de meses diferentes pode criar um teste irreal. Uma checagem com pedidos posteriores aos usados no desenvolvimento costuma se aproximar melhor do uso futuro. A escolha da divisão precisa respeitar como o sistema será usado.

O teste que importa para Bruno

Ao revisar o processo, Bruno faz três perguntas simples: essa informação estaria disponível no momento da previsão? Os exemplos de teste ficaram de fora de todas as escolhas? Os pedidos de teste se parecem com os que chegarão depois?

Ele retira o campo tardio, refaz a avaliação e vê um resultado menor. É uma notícia desconfortável, mas útil. Agora a equipe conhece melhor o limite da ferramenta e pode decidir onde pedir revisão humana, como melhorar os dados e o que acompanhar após a implantação.

Uma boa avaliação não serve para produzir um número bonito. Serve para evitar que um número bonito nos faça confiar cedo demais.

Para aprofundar: curso Machine Learning de Paulo Orenstein (IMPA, 2026), especialmente a aula 5 sobre métodos de reamostragem. A história de Bruno é um exemplo didático criado para este artigo. Veja também como avaliar os tipos de erro de uma IA.

Na série: ← #03 — Como saber se um modelo de IA é realmente bom?

Próximo artigo: #05 — Mais informações deixam uma IA mais inteligente? →

Voltar ao índice da série