Testes metamórficos avaliam a relação entre respostas de uma IA quando a entrada muda de maneira controlada. Em vez de exigir uma frase perfeita como gabarito, você define o que precisa permanecer igual e o que deve mudar. Trocar a ordem de dois parágrafos pode preservar os fatos de um resumo; trocar uma data precisa alterar a data extraída.
O método ajuda quando existem muitas respostas aceitáveis, mas algumas propriedades são obrigatórias. Para começar, escolha uma tarefa pequena, escreva uma transformação com significado claro e compare campos observáveis das duas saídas. O resultado revela inconsistências, embora não prove que a resposta original seja verdadeira.
Resumo rápido
- Uma relação metamórfica descreve como a saída deve reagir a uma mudança específica na entrada.
- Preservar sentido, alterar um fato e retirar evidência exigem expectativas diferentes.
- Compare fatos, decisões e restrições, evitando cobrar igualdade literal de textos livres.
- Valide as próprias transformações antes de atribuir uma falha ao modelo.
- Combine esses testes com exemplos anotados e revisão humana de casos relevantes.
O que uma relação metamórfica consegue mostrar
Considere um assistente que extrai o prazo de entrega de um pedido. A entrada original diz “entrega prevista para sexta-feira”. Uma variante diz “a previsão de entrega é sexta-feira”. A construção muda, mas a informação central permanece. A relação esperada é manter o mesmo prazo, junto da indicação de que se trata de previsão.
Agora substitua sexta-feira por segunda-feira. A expectativa deixa de ser estabilidade: o prazo extraído deve acompanhar a mudança. Se a resposta continuar em sexta-feira, a aplicação pode estar usando um exemplo do prompt ou um resultado anterior indevidamente. O teste procura uma dependência correta entre entrada e saída.
A metodologia CheckList organiza testes comportamentais de linguagem por capacidades e tipos de teste. Sua contribuição ajuda a pensar além da média de acertos. Uma aplicação prática, proposta aqui, é manter uma ficha por comportamento: tarefa, mudança aplicada, hipótese, comparação e exceções.
A relação pode ser satisfeita por duas respostas igualmente erradas. Um extrator pode manter o mesmo valor inventado em todas as paráfrases. Por isso, inclua casos com verdade conhecida e verificações de fonte. Metamorfismo complementa o gabarito; não elimina a necessidade de conhecer o processo que está sendo automatizado.
Escolha transformações que respeitem a tarefa
Uma transformação só é válida se a expectativa fizer sentido no domínio. Retirar acentos de um identificador pode ser irrelevante para uma classificação de intenção e decisivo para identificar uma pessoa. Reordenar documentos pode preservar uma lista de fatos, mas modificar legitimamente a resposta quando a regra é usar o registro mais recente apresentado.
| Transformação | Expectativa possível | Cuidado necessário |
|---|---|---|
| Parafrasear uma solicitação | Preservar intenção e condições | Conferir se a paráfrase não criou obrigação nova |
| Trocar nome fictício de cliente | Preservar decisão sem dependência do nome | Não alterar dados usados por uma regra legítima |
| Substituir uma quantidade | Atualizar quantidade e cálculos derivados | Recalcular as consequências esperadas |
| Remover o trecho que sustenta uma resposta | Indicar informação ausente | Garantir que outra passagem não fornece a evidência |
| Acrescentar informação irrelevante | Preservar a decisão principal | Verificar se o acréscimo é realmente irrelevante |
Evite começar com alterações acumuladas. Se você troca nome, valor, ordem, pontuação e idioma ao mesmo tempo, uma divergência fica difícil de explicar. Construa pares com uma mudança e só depois experimente combinações. O objetivo inicial é localizar o comportamento vulnerável com precisão suficiente para corrigi-lo.
A pesquisa sobre sistematicidade, composicionalidade e transitividade discute relações que vão além da resistência a ruído. Isso inspira testes de composição: uma lista contendo dois pedidos independentes deve preservar os dados de ambos quando eles são reunidos, desde que essa seja a regra declarada da tarefa.
Monte uma suíte pequena e rastreável
Comece registrando a tarefa de forma operacional. “Fazer um bom resumo” é amplo demais. Uma especificação testável seria “listar os itens solicitados, manter as condições de entrega e sinalizar os campos ausentes, sem completar com conhecimento externo”. Essa definição permite escolher relações adequadas e comparar o mesmo comportamento entre versões.
Use identificadores estáveis para o caso original e cada variante. Guarde texto original, transformação, texto transformado, saída completa, campos extraídos e resultado da comparação. Inclua versão do prompt, configuração da chamada e identificação do modelo conforme seu ambiente. Isso evita confundir alteração de comportamento com mudança silenciosa da aplicação.
- Selecione mensagens representativas da operação, removendo dados pessoais desnecessários.
- Escreva a propriedade esperada em linguagem compreensível pela equipe responsável.
- Crie a variante e peça a outra pessoa para validar a relação sem ver a resposta do modelo.
- Execute original e variante sem compartilhar o histórico entre as chamadas.
- Compare os campos definidos e separe falha confirmada de teste inválido.
- Registre a causa provável e uma ação responsável pela correção.
O repositório dos autores do CheckList reúne exemplos de templates, perturbações e funções de expectativa. Esses materiais ajudam a estruturar a automação. A adoção de uma biblioteca deve vir depois de uma definição clara dos comportamentos; um script simples também pode executar uma suíte inicial bem delimitada.
Não reutilize automaticamente a resposta original como verdade de referência. Quando a relação exigir conferir um cálculo, obtenha o resultado esperado por código independente. Quando exigir preservar condições comerciais, valide as condições na própria entrada. Um avaliador que apenas pergunta “as duas respostas parecem iguais?” pode ignorar uma omissão importante.
Compare significado e registre a variabilidade
Para saídas estruturadas, normalize somente o que não faz parte do contrato. Ordenar uma lista de itens pode ser aceitável se a ordem não tiver significado. Converter “três” para 3 ajuda a comparar quantidades. Remover palavras como “talvez”, “estimado” ou “confirmado” é arriscado, pois elas mudam o grau de certeza.
Para textos livres, use uma rubrica curta: fatos preservados, fatos alterados conforme a variante, condições mantidas, nenhuma informação sem apoio. Um avaliador humano pode aplicar esses critérios a uma amostra. Um segundo modelo pode auxiliar, mas precisa ser validado contra decisões humanas e não deve ser tratado como juiz infalível.
Separe divergência de redação de violação funcional. “O cliente prefere retirar o produto” e “a retirada foi indicada como preferência” podem expressar o mesmo fato. Já “o cliente retirará o produto” transforma preferência em compromisso. Similaridade textual isolada não captura essa diferença com segurança.
Modelos gerativos podem variar entre execuções. Como método proposto, repita pares relevantes sob a configuração real da aplicação e observe também a estabilidade do original. Registre número de execuções, violações e tipos de erro. Não atribua causalidade à transformação com base em uma única mudança que também aparece sem ela.
A pesquisa Metamorphic Testing of Large Language Models for Natural Language Processing trata diretamente desse uso em modelos de linguagem. Seus resultados não substituem uma validação local: idioma, documentos, prompt e regra de negócio da sua aplicação precisam aparecer nos testes que sustentam sua decisão.
Exemplo: pedidos de uma gráfica em Belo Horizonte
Imagine uma gráfica de Belo Horizonte que usa IA para transformar mensagens em uma ficha de orçamento. O caso é ilustrativo. A mensagem original pede “200 cartões, frente e verso, retirar na loja; preciso saber se fica pronto até quinta”. A ficha deve manter quantidade, acabamento, retirada e pergunta sobre prazo, sem prometer produção.
Uma primeira variante troca a redação para “quero duzentos cartões impressos dos dois lados e vou buscar aí; conseguem entregar até quinta?”. A quantidade e o acabamento precisam permanecer equivalentes. A expressão “entregar” está no pedido de prazo, mas a preferência explícita de retirada continua sendo relevante. Um avaliador deve conferir essa ambiguidade antes de rotular o resultado.
Na segunda variante, a equipe troca 200 por 500 e mantém o restante. A ficha precisa atualizar a quantidade. Na terceira, remove a menção à retirada. O campo deve ficar sem informação ou pedir esclarecimento, conforme o contrato da aplicação. Assumir entrega em domicílio nessa versão seria completar uma lacuna indevidamente.
Na quarta, acrescenta “gostei da cor da fachada de vocês”. A observação não deveria alterar a quantidade nem a modalidade já informada. Se passar a ser uma especificação de cor do cartão, surgiu uma falha de atribuição: o sistema transformou comentário social em requisito de produção.
Para investigar problemas com negação, a equipe pode consultar o guia de avaliação de negação em classificadores de texto. Para organizar os pares como parte de uma rotina maior, o material sobre testes de regressão de prompts ajuda a conectar casos persistentes e mudanças de aplicação.
Erros comuns
Considerar toda paráfrase equivalente. Trocar “posso retirar” por “vou retirar” altera possibilidade e compromisso. Revise verbos, negações e condições. Um gerador de variantes também erra; mantenha uma etapa explícita para rejeitar transformações que mudaram o significado sem intenção.
Premiar respostas invariáveis. Um modelo que repete a mesma saída passa por testes de estabilidade e falha diante de fatos novos. Equilibre relações de preservação com relações de mudança e de retirada de evidência. A suíte precisa exigir sensibilidade ao que realmente importa.
Divulgar uma taxa única sem composição. Muitas variantes fáceis podem esconder uma falha recorrente em prazos condicionais. Apresente resultados por relação, tarefa e gravidade, junto de exemplos concretos. Não use o volume de variações como substituto para diversidade de comportamentos.
Corrigir o teste para aprovar a versão nova. Quando a especificação continua válida, preserve o caso como regressão. Se a regra mudou de propósito, registre a decisão e versione a expectativa. Também reserve exemplos que não foram usados para ajustar o prompt, reduzindo a adaptação excessiva à suíte conhecida.
Perguntas frequentes
Preciso ter um gabarito para cada resposta?
Não para a redação completa. Você precisa de uma expectativa verificável sobre a relação entre saídas. Ainda assim, alguns casos com fatos conhecidos são necessários para evitar que respostas consistentemente erradas pareçam adequadas.
Posso gerar todas as variantes com outra IA?
Pode usar IA como apoio, mas valide a transformação antes da execução. Guarde a versão aprovada e sua justificativa. Se o significado mudou de forma indevida, descarte a variante em vez de registrar uma falha do sistema avaliado.
O teste serve para sistemas com busca em documentos?
Sim. Você pode variar pergunta e documentos separadamente. Ao remover uma evidência, confira se a mesma informação não está em outro trecho. Registre também o material recuperado para distinguir falha de busca de falha de interpretação.
Quantas relações devo criar primeiro?
Não existe uma quantidade universal. Comece pelos comportamentos com impacto operacional claro e aumente a cobertura conforme os erros observados. Cada relação deve ter responsável, justificativa e uma comparação que a equipe consiga revisar.
Uma falha impede colocar a aplicação em uso?
Depende do efeito da falha e dos controles do processo. Inventar um compromisso comercial pode justificar bloquear a ação automática. Uma diferença de estilo pode gerar apenas revisão. Defina critérios de aprovação antes de conhecer os resultados.
