A equipe altera o prompt, executa as mesmas perguntas e comemora uma nota melhor. Depois de várias rodadas, o assistente acerta os casos conhecidos, mas continua falhando nas solicitações novas. A avaliação deixou de medir generalização e passou a recompensar a adaptação ao próprio teste.
Esse problema pode aparecer mesmo quando nenhum peso do modelo é treinado. Escolher instruções, exemplos e regras com base nos resultados de um conjunto fixo também adapta o sistema àqueles casos. Separar desenvolvimento, validação e teste ajuda a preservar uma medida mais útil da qualidade.
Resumo rápido
- Use exemplos de desenvolvimento para construir e corrigir o prompt.
- Compare versões na validação e reserve um teste final independente.
- Separe grupos relacionados para evitar que cópias da mesma situação apareçam dos dois lados.
Defina a função de cada conjunto
O conjunto de desenvolvimento fica disponível para a equipe: permite examinar erros, criar instruções e escolher demonstrações. O de validação ajuda a comparar versões candidatas. O teste final deve permanecer reservado até a decisão de liberação, reduzindo a influência dos seus exemplos sobre os ajustes.
A documentação de avaliação do LangSmith apresenta divisões entre treinamento, validação e teste como uma forma de evitar sobreajuste. Para um projeto que trabalha apenas com prompts, “desenvolvimento” é um nome mais claro para os exemplos usados na construção das instruções: não é necessário treinar um modelo para adotar essa organização.
Não existe uma proporção universal de divisão. A escolha depende do volume, da diversidade e das decisões que precisam ser avaliadas. O ponto central é reservar casos suficientes das situações importantes, incluindo perguntas incompletas, exceções e solicitações que devem ser encaminhadas.
Separe por situação, não apenas por linha da planilha
Antes de sortear exemplos, identifique duplicatas e relações entre eles. Mensagens da mesma conversa, perguntas sobre o mesmo documento e pequenas variações de um único pedido podem carregar informações quase idênticas. Se aparecerem em conjuntos diferentes, o desempenho pode parecer melhor do que seria diante de uma situação nova.
A orientação do scikit-learn sobre vazamento de dados é preservar a separação entre os dados usados para construir o sistema e aqueles destinados à avaliação. A aplicação desse princípio aos prompts exige atenção aos exemplos inseridos nas instruções, aos documentos utilizados para corrigir falhas e às respostas que o avaliador já conhece.
Uma regra editorial útil é manter a mesma conversa em um só conjunto. Para perguntas originadas de documentos, avalie se é melhor separar por documento ou por família de assunto. Se o objetivo for enfrentar mudanças ao longo do tempo, um recorte temporal pode ajudar, desde que versões futuras das regras não sejam fornecidas aos casos antigos.
Registre a origem, a categoria e o grupo de cada exemplo. Isso permite explicar como a separação foi feita e repetir a comparação quando outra pessoa assumir o projeto.
Congele a comparação antes de escolher o vencedor
Defina o que será medido: informação correta, campos obrigatórios, fonte adequada, recusa quando faltarem dados e tom de resposta. Alguns critérios podem ser verificados por código; outros exigem revisão humana ou um avaliador calibrado. Evite mudar a regra de pontuação apenas porque uma versão ficou abaixo da expectativa.
Mantenha modelo, ferramentas, documentos e configurações comparáveis quando estiver avaliando o prompt. Se mudar vários componentes de uma vez, registre isso como uma nova versão do sistema, sem atribuir todo o ganho ao texto das instruções. Em saídas variáveis, repita casos relevantes para observar a estabilidade, respeitando o orçamento do projeto.
O LangSmith permite versionar conjuntos e executar avaliações sobre subconjuntos definidos. A ferramenta pode facilitar o trabalho, mas uma planilha bem mantida também atende ao começo. O essencial é identificar o prompt, o conjunto, o avaliador e a data de cada rodada. Veja nosso guia de governança de prompts com controle de versão.
Exemplo hipotético: classificação de pedidos
Imagine uma empresa que usa IA para separar mensagens entre orçamento, suporte e cobrança. A equipe prepara casos de desenvolvimento e percebe que pedidos de segunda via caem na categoria errada. Ela acrescenta uma regra e exemplos variados ao prompt.
Na validação, uma nova versão melhora a classificação desses pedidos, mas passa a tratar toda mensagem com a palavra “pagamento” como cobrança. A análise mostra que clientes também perguntam por formas de pagamento antes de comprar. A correção precisa capturar a intenção, em vez de decorar uma palavra.
Depois de selecionar uma versão, a equipe executa o teste reservado. Se usar os erros desse teste para ajustar novamente o prompt, deve registrar que o conjunto foi consultado e planejar novos casos independentes para a próxima liberação. O exemplo é hipotético e não pressupõe um ganho numérico.
Variações de linguagem também ajudam a investigar fragilidades. O artigo sobre testes metamórficos de IA complementa essa etapa. Mantenha variações derivadas de um mesmo caso juntas para preservar a independência entre os conjuntos.
Checklist antes de liberar o novo prompt
- Verifique duplicatas e grupos relacionados antes da divisão.
- Reserve casos de exceção e ausência de informação.
- Registre versões do prompt, documentos, modelo e avaliador.
- Defina critérios de aceitação antes da comparação final.
- Observe resultados por categoria, além da média geral.
- Documente quando o conjunto de teste foi consultado ou reutilizado.
Perguntas frequentes
Preciso de milhares de exemplos para começar?
Não. É possível começar com um conjunto menor, revisado e variado. A quantidade necessária depende da tarefa; poucos exemplos não sustentam conclusões amplas sobre todos os tipos de solicitação.
Posso continuar usando os erros antigos nos testes?
Sim. Eles são úteis para verificar regressões. Preserve também casos novos e independentes para avaliar se a melhoria funciona além das situações que já orientaram a correção.
