Como avaliar inconsistências em respostas de IA

Quando uma inteligência artificial entrega três respostas diferentes para a mesma solicitação, a primeira pergunta é quais requisitos continuaram iguais. A consistência de respostas de IA deve ser avaliada contra elementos observáveis, não contra a expectativa de repetição literal. Variação de tom, ordem ou exemplo pode ser aceitável. Mudança de regra, dado, compromisso, ação ou limite deve ser tratada como falha de requisito.

Quando respostas diferentes são um problema de qualidade

Produtos com inteligência artificial tendem a gerar respostas com alguma variação. Isso não autoriza tratar qualquer diferença como defeito, nem permite ignorar inconsistências que mudam a decisão do usuário.

A pergunta útil é mais específica: a diferença alterou aquilo que o produto precisava preservar?

Se uma IA explica uma política de cancelamento em frases diferentes, mas mantém a mesma regra, o mesmo prazo e a mesma orientação, a variação pode ser apenas de linguagem. Se uma resposta diz que o usuário tem direito a reembolso e outra diz que não tem, para o mesmo caso e com as mesmas informações, a equipe está diante de uma falha de requisito.

Essa distinção muda a decisão de aceite, bloqueio, ajuste de prompt, contexto, regra ou exposição. Em vez de pedir que a IA “seja mais consistente” de forma genérica, a equipe passa a definir quais elementos da resposta não podem mudar. Um pedido vago costuma produzir ajustes vagos. Um requisito observável permite testar, comparar e decidir.

Esse tema se conecta à disciplina mais ampla de qualidade de software com IA, mas aqui o foco é uma fronteira específica: quando a variação natural de uma resposta vira descumprimento do produto.

O que precisa permanecer igual em respostas aceitáveis

Antes de comparar respostas, registre os invariantes. Invariantes são elementos que precisam permanecer estáveis para que a resposta continue correta, mesmo que a redação mude.

Em uma funcionalidade de IA, os invariantes mais relevantes costumam ser:

• A intenção principal do usuário.
• As restrições explícitas do pedido.
• As regras do produto ou da operação.
• Os fatos e dados usados na resposta.
• Os limites de autonomia da funcionalidade.
• A ação recomendada ou executada.
• O risco ou a obrigação criada para o usuário.

Imagine uma solicitação simples: “Posso cancelar minha assinatura hoje e receber reembolso?” A resposta pode começar explicando a regra, pode começar perguntando por dados faltantes, pode ser mais curta ou mais detalhada. Mas ela não pode mudar a regra aplicável, prometer uma ação que o produto não executa ou omitir uma restrição que altera a decisão do usuário.

É por isso que critérios de aceite para IA precisam proteger compromissos, não frases. Um critério como “responder de forma clara” ajuda pouco se não disser o que não pode variar. Já um critério como “não prometer reembolso quando a política cadastrada não permitir” cria uma linha de avaliação mais concreta. Esse tipo de definição dialoga com a prática de definir critérios de aceite para funcionalidades de IA, sem substituir uma avaliação completa do produto.

Variação de linguagem ou falha de requisito

Uma resposta inconsistente pode parecer errada porque soa diferente. Também pode parecer aceitável porque soa convincente. Nenhum desses sinais basta.

A equipe precisa comparar diferenças por efeito prático. Algumas variações normalmente são aceitáveis quando preservam os invariantes:

• Mudança de tom, mantendo a orientação correta.
• Ordem diferente dos argumentos, sem omitir condição relevante.
• Exemplos equivalentes, compatíveis com os mesmos fatos.
• Resposta mais curta ou mais longa, desde que não altere o compromisso.
• Formulação alternativa da mesma recomendação.

Outras diferenças devem acender alerta de falha de requisito:

• Mudança de condição, prazo, regra ou exceção.
• Omissão de alerta que o usuário precisa receber.
• Recomendação incompatível com a política do produto.
• Conclusão oposta para o mesmo caso, sem nova informação.
• Promessa de ação que o sistema não consegue cumprir.
• Afirmação de conclusão sem evidência verificável.

A linha divisória é esta: se a diferença muda a decisão, a expectativa, o custo, a obrigação ou a proteção do usuário, ela deixou de ser apenas variação.

Essa avaliação também evita um erro comum: transformar estilo em proxy de qualidade. Uma resposta polida pode estar errada. Uma resposta menos elegante pode preservar todos os requisitos críticos. Para qualidade de IA em produto, a forma importa, mas não substitui verificação.

Um exemplo fictício de avaliação de respostas inconsistentes

Considere um exemplo fictício: uma empresa oferece uma IA para responder dúvidas sobre cancelamento de assinatura. A regra cadastrada no produto diz que o usuário pode cancelar a qualquer momento, mas o reembolso só é aplicável quando a solicitação cumpre a condição prevista na política interna exibida ao atendimento.

Entrada repetida para teste: “Quero cancelar minha assinatura hoje. Vou receber reembolso?”

Primeira resposta: “Você pode cancelar sua assinatura hoje. Para saber se há reembolso, preciso verificar se seu caso atende à condição prevista na política. Se quiser, posso orientar o próximo passo.”

Segunda resposta: “Sim, o cancelamento pode ser feito hoje. O reembolso depende da condição aplicável ao seu plano. Antes de confirmar qualquer valor, é necessário checar essa regra.”

Terceira resposta: “Sim. Ao cancelar hoje, você receberá reembolso automaticamente.”

As duas primeiras respostas variam em linguagem. Uma começa pela ação de cancelar, outra pelo cuidado com o reembolso. A ordem muda. O tom muda. Mas os invariantes permanecem: cancelamento é possível, reembolso depende de condição, nenhuma garantia indevida é criada.

A terceira resposta falha. Ela promete reembolso automático sem verificar a condição. A inconsistência não é estética. Ela muda expectativa, possível obrigação operacional e risco de frustração para o usuário.

Em um teste como esse, a anotação não deveria ser “respostas diferentes”. Deveria separar os casos:

• Resposta 1: variação aceitável, requisito preservado.
• Resposta 2: variação aceitável, requisito preservado.
• Resposta 3: falha de requisito, promessa incompatível com a regra.

Essa diferença de anotação melhora a conversa com quem ajusta prompt, configurações, regras de recuperação de informação ou fluxos de atendimento. O problema não é “a IA está criativa demais”. O problema é “a IA prometeu uma consequência que o produto não autorizou”.

Checklist para decidir se a inconsistência pode ir adiante

Use este checklist em amostras repetidas para o mesmo caso. Ele não elimina a necessidade de testes mais amplos, mas ajuda a classificar a inconsistência antes que ela vire uma discussão subjetiva.

A intenção principal foi preservada?

A variação é aceitável quando a resposta usa caminhos diferentes, mas resolve a mesma intenção. É falha quando atende outra intenção ou reinterpreta a pergunta sem base.

As restrições explícitas foram respeitadas?

A variação é aceitável quando reorganiza a explicação sem violar limites declarados. É falha quando ignora uma condição, prazo, exceção ou regra informada.

Os fatos relevantes permaneceram estáveis?

A variação é aceitável quando escolhe exemplos diferentes, mas compatíveis com os mesmos fatos. É falha quando altera um valor, inventa uma condição ou contradiz informação usada no próprio fluxo.

A recomendação final é compatível entre tentativas?

A variação é aceitável quando recomenda o mesmo caminho com tom ou ordem diferente. É falha quando uma resposta aprova e outra nega o mesmo caso sem nova informação.

A resposta mantém os limites de autonomia?

A variação é aceitável quando a IA sinaliza incerteza ou orienta o próximo passo previsto. É falha quando promete uma ação, decisão ou garantia que o produto não pode cumprir.

O resultado pode ser verificado fora da própria resposta?

A variação é aceitável quando há evidência objetiva de que a tarefa foi concluída conforme esperado. É falha quando a única prova é a IA dizer que terminou ou que está correta.

A inconsistência muda risco, custo ou obrigação?

A variação é aceitável quando não altera escolha, expectativa, responsabilidade ou consequência prática. É falha quando induz uma decisão errada, cria obrigação indevida ou reduz uma proteção esperada.

Use a classificação para decidir o próximo passo:

• Aceitar a variação quando ela fica em linguagem.
• Ajustar prompt, contexto ou configuração quando há ambiguidade recorrente.
• Criar teste adicional quando um requisito crítico apareceu sem cobertura.
• Revisar o requisito quando a própria equipe não consegue dizer qual resposta deveria ser correta.
• Bloquear exposição quando a diferença muda risco para o usuário.

Resultado verificável além da mensagem da IA

Quando a IA apenas responde uma dúvida, a análise textual já ajuda bastante. Quando ela orienta ou executa uma ação, a mensagem não basta.

A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente. Também observa que uma mensagem dizendo que a tarefa terminou não comprova, sozinha, que o resultado esperado ocorreu. Em avaliações, isso pede entradas, critérios de sucesso e verificadores.

A implicação para respostas inconsistentes é direta. Se a IA diz “cancelei sua assinatura”, a equipe precisa verificar o estado da assinatura. Se diz “enviei a solicitação”, é preciso verificar se a solicitação foi registrada no sistema certo. Se diz “apliquei a regra”, é preciso verificar qual regra foi aplicada.

Mesmo quando não há um agente executando ações, vale o princípio: não confie apenas na autodeclaração da IA. Compare a resposta com uma fonte de verdade, com uma regra documentada ou com um verificador externo ao texto gerado.

Isso também protege contra uma falsa sensação de estabilidade. Três respostas podem parecer parecidas e ainda assim falhar no mesmo ponto. Por outro lado, três respostas podem soar diferentes e preservar o resultado esperado. A consistência que interessa é a dos requisitos, não a da superfície verbal.

O DORA recomenda testes ao longo do desenvolvimento, combinando automação com atividades manuais como exploração e usabilidade, além de manter e revisar suítes de teste em vez de tratar qualidade como etapa posterior ao desenvolvimento. Para IA, essa disciplina ajuda a não deixar a avaliação de inconsistência apenas para o fim do projeto.

Como tratar inconsistência antes de ampliar exposição

Nem toda inconsistência exige bloquear uma funcionalidade. Mas inconsistências que mudam regra, promessa, ação ou risco pedem contenção antes de ampliar exposição.

O capítulo de canarying do Google SRE trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição.

Aplicado a produtos com IA, esse raciocínio ajuda a reduzir decisões binárias. A equipe pode ativar a funcionalidade em um escopo menor, observar casos críticos antes de ampliar e separar públicos, fluxos ou tipos de solicitação conforme o risco.

Há também um limite de interpretação. A atualização de fevereiro de 2026 da METR considera novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades de medir tempo com agentes concorrentes. Essa fonte não deve ser usada para concluir valor comercial de uma funcionalidade específica.

Para respostas inconsistentes, a decisão concreta é classificar a diferença antes de agir sobre ela. Se a intenção, as restrições, os fatos, a recomendação, os limites de autonomia e o efeito prático foram preservados, registre como variação aceitável. Se qualquer item crítico mudou, trate como falha de requisito.

A decisão final é definir quais compromissos a resposta não pode quebrar, como eles serão verificados e até onde a funcionalidade pode avançar quando uma falha aparecer.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Como decidir se uma funcionalidade de IA pode ir para produção
• Como medir a produtividade de desenvolvedores com IA

Fontes

• DORA: automação de testes
• Anthropic: avaliações de agentes
• Google SRE: lançamentos graduais
• METR: limites da medição de produtividade

Para continuar esta leitura

• Como identificar testes frágeis escritos por IA