Treinamento, validação, teste e uso de modelos

Dois momentos, duas ações

Na Loja Aurora, um modelo ajuda a classificar solicitações nas categorias entrega e troca.

Treinamento é o momento de ajustar o modelo com exemplos que já têm um rótulo conhecido. Esses exemplos ajudam o modelo a relacionar o texto da solicitação à categoria esperada.

Depois disso, vem a inferência (uso do modelo treinado): uma nova solicitação passa pelo modelo pronto, que produz uma categoria prevista. Nesse momento, o modelo está sendo usado — não ajustado.

No treinamento, os exemplos têm uma resposta já disponível. A Loja Aurora usa solicitações anteriores e seus rótulos conhecidos para fazer ajustes no modelo.

Na inferência, há uma solicitação nova. O modelo treinado recebe essa entrada e retorna uma categoria prevista. A previsão pode coincidir ou não com uma resposta que se descubra depois; aqui, o ponto é que produzir a previsão não altera o modelo.

Associe cada situação à ação principal realizada.

Antes de ajustar um modelo, a Loja Aurora separa seus exemplos em três conjuntos: Dados de treinamento, Dados de validação e Dados de teste.

A separação vem antes dos ajustes. Neste cenário, somente os Dados de treinamento entram diretamente no treinamento: são os exemplos usados para ajustar o modelo. Os outros dois conjuntos ficam reservados, sem participar desse ajuste direto.

Cada solicitação fica em um único conjunto. Não copie a mesma solicitação para treinamento e teste, por exemplo.

A tabela mostra uma organização fictícia. Os rótulos conhecidos já indicam se cada solicitação pertence à categoria entrega ou troca. O importante aqui é a separação: os exemplos das três linhas não se repetem.

Depois do ajuste direto com os Dados de treinamento, a Loja Aurora pode ter versões candidatas, como o Modelo A e o Modelo B.

A validação serve para comparar essas versões antes de decidir como prosseguir. Cada modelo recebe solicitações dos Dados de validação e produz uma categoria prevista. Essa previsão é comparada ao rótulo conhecido que já acompanha cada solicitação.

Neste cenário, os exemplos de validação ajudam a escolher entre versões, mas não entram no ajuste direto do modelo.

Veja uma comparação fictícia. As solicitações abaixo já têm rótulos conhecidos porque pertencem aos Dados de validação. A Loja Aurora observa as previsões de cada versão para decidir qual seguir usando.

Na Loja Aurora, a validação já foi usada para comparar as versões candidatas e escolher o Modelo B. Só então entram os Dados de teste.

O teste avalia a versão que já foi escolhida. Ele fica depois da escolha e antes da decisão de colocar essa versão em uso. Durante os ajustes e as comparações anteriores, seus exemplos permanecem reservados.

Validação e teste podem comparar uma categoria prevista com um rótulo conhecido. A diferença está na função e no momento de cada conjunto no processo.

O teste foi reservado para avaliar a versão já escolhida. Essa função se perde se o resultado do teste passa a decidir qual versão usar ou quais escolhas rever.

O ponto não é apenas consultar os Dados de teste mais de uma vez. O problema começa quando o que eles mostram orienta uma nova escolha de desenvolvimento.

Imagine que a Loja Aurora escolheu o Modelo B com base nos Dados de validação. Depois, a equipe consulta os Dados de teste e usa o resultado para voltar atrás: troca de versão, altera uma escolha e consulta o teste novamente.

Nesse momento, o teste deixou de ser apenas a avaliação final. Seus resultados passaram a participar das decisões que produziram a versão avaliada.

A versão atual da Loja Aurora pode receber várias solicitações novas e produzir uma categoria prevista em cada uma. Isso é uso do modelo: a versão permanece a mesma enquanto classifica as entradas.

Por exemplo: Minha encomenda ainda não chegou. → modelo treinado → categoria prevista: entrega. Essa é uma previsão fictícia; a solicitação passou pelo modelo, mas o modelo não foi ajustado por causa disso.

Durante o uso, a Loja Aurora também pode guardar uma solicitação ou registrar que uma categoria prevista deveria ter sido outra. Esses fatos podem ser úteis depois, mas registrar informação não faz ajustes no modelo por si só.

Para haver uma atualização do modelo, é necessário um processo explícito: preparar uma versão com novos ajustes e passar novamente pelas etapas de avaliação. Até isso ocorrer, a versão em uso continua sendo a anterior.

Há dois caminhos diferentes. No caminho de uso, a versão atual apenas recebe uma entrada e devolve uma categoria prevista. No caminho de atualização do modelo, informações reunidas podem participar de novos ajustes; a versão preparada passa por validação e teste antes de ser escolhida para uso.

Portanto, uma correção recebida hoje não muda retroativamente a previsão nem altera sozinha a versão que atende a próxima solicitação.

Na Loja Aurora, cada etapa tem uma fronteira clara. Primeiro, as solicitações já rotuladas são separadas. Os Dados de treinamento ajustam versões candidatas; os Dados de validação ajudam a comparar essas versões e a escolher como prosseguir; os Dados de teste avaliam a versão escolhida no final.

Depois da decisão de colocar a versão em uso, chega uma nova solicitação. Ela percorre o fluxo nova solicitação → modelo treinado → categoria prevista. Isso é inferência: usar o modelo pronto, não ajustá-lo.