Como definir critérios de aceite para respostas de IA

Produtos com Inteligência Artificial não se comportam como software tradicional.

Em uma funcionalidade determinística, normalmente esperamos que uma mesma entrada gere sempre a mesma saída. Em sistemas baseados em LLMs, isso muda.

A resposta pode variar na forma, na ordem das informações, no nível de detalhe e até na forma como o modelo interpreta o contexto disponível.

Por isso, aplicar critérios de aceite tradicionais sem adaptação costuma ser insuficiente.

Em produtos com IA, o objetivo não é validar apenas se a resposta “parece correta”.

É necessário avaliar também:

• se o contexto usado estava correto;
• se a resposta estava completa;
• se havia evidência suficiente;
• se o sistema respeitou as regras definidas;
• se o formato estava adequado;
• e, principalmente, se o sistema soube quando não deveria responder.

Por que critérios de aceite tradicionais não são suficientes

Em uma funcionalidade convencional, um critério de aceite pode ser bastante objetivo:

Dado que o usuário informou os campos obrigatórios, quando salvar o formulário, então o sistema deve registrar os dados.

Existe uma relação previsível entre entrada e saída.

Em IA generativa, essa lógica precisa ser ampliada.

Considere um assistente com RAG.

Mesmo que a pergunta do usuário seja a mesma, a qualidade da resposta pode depender de várias etapas anteriores:

Pergunta → recuperação de informação → seleção de contexto → geração → aplicação das regras de resposta

Se a recuperação trouxer o trecho errado ou incompleto, o problema não necessariamente estará no LLM.

Por isso, o critério de aceite precisa considerar o comportamento do sistema como um todo.

O que muda quando a resposta é probabilística

Em produtos com IA, nem sempre faz sentido escrever um critério como:

Então a resposta deve ser exatamente: “...”

Isso torna o teste frágil e pouco representativo.

O mais importante é definir o que precisa estar presente na resposta e quais limites o sistema deve respeitar.

Por exemplo:

A resposta deve explicar que o benefício depende da regra X, mencionar a exceção Y e utilizar apenas informações recuperadas da base de conhecimento.

Nesse caso, diferentes respostas podem ser aceitáveis, desde que cumpram os requisitos definidos.

A mudança de mentalidade é esta:

não validar a frase exata, mas validar as propriedades esperadas da resposta.

1. O contexto utilizado precisa estar correto

Antes de avaliar a resposta final, é importante verificar se o sistema recuperou a informação adequada.

Imagine uma base de conhecimento contendo:

• regra geral;
• exceção;
• condições específicas;
• prazos;
• critérios adicionais.

Se a busca recuperar apenas a regra geral, o modelo pode gerar uma resposta coerente, mas incompleta.

Um possível critério de aceite seria:

Dado que a pergunta exige a aplicação da regra geral e de uma exceção, quando o sistema recuperar o contexto, então ambos os trechos necessários devem estar disponíveis antes da geração da resposta.

Esse tipo de critério é especialmente importante em RAG.

2. A resposta precisa estar completa

Uma resposta pode estar factualmente correta e ainda assim não atender ao usuário.

Por exemplo, se uma pergunta envolve três condições e o sistema menciona apenas duas, a resposta está parcialmente correta.

Mas, para o produto, isso pode significar falha.

Um critério de aceite pode ser:

Quando a pergunta exigir múltiplas condições para uma conclusão, então a resposta deve apresentar todas as condições relevantes presentes no contexto recuperado.

A completude costuma ser um dos pontos mais difíceis de avaliar em sistemas generativos.

Por isso, perguntas de teste devem incluir casos nos quais informações importantes estejam distribuídas em diferentes trechos da base.

3. O sistema precisa saber quando não responder

Esse é um dos critérios mais importantes em produtos com IA.

Um modelo generativo tende a tentar responder.

Mas nem sempre responder é o comportamento desejado.

Em determinados cenários, a resposta correta do produto é reconhecer que não existe informação suficiente.

Exemplo:

Dado que a base recuperada não contém informação suficiente para responder à pergunta, quando o usuário solicitar uma conclusão, então o sistema deve informar que não possui contexto suficiente e não deve completar a resposta utilizando conhecimento externo.

Esse comportamento é particularmente importante em domínios sensíveis, como jurídico, financeiro ou saúde.

O objetivo não é fazer a IA responder sempre.

É fazer com que ela responda quando existe base suficiente para isso.

4. A saída precisa respeitar formato e regras

Produtos de IA muitas vezes possuem requisitos adicionais de apresentação.

Por exemplo:

• resposta em tópicos;
• limite de tamanho;
• estrutura JSON;
• inclusão de fontes;
• linguagem específica;
• ordem determinada das informações;
• proibição de determinados tipos de afirmação.

Esses elementos também precisam fazer parte dos critérios de aceite.

Exemplo:

Quando houver informação suficiente para responder, então a resposta deve apresentar primeiro a conclusão, depois a justificativa e, ao final, as fontes utilizadas.

Ou:

A resposta deve retornar um JSON válido contendo obrigatoriamente os campos status, motivo e fonte.

Formato também é comportamento de produto.

5. O comportamento de erro também é requisito

Um erro comum em produtos de IA é testar apenas o cenário ideal.

Mas o comportamento diante de falhas precisa ser especificado.

Alguns exemplos:

• nenhum documento recuperado;
• documento ilegível;
• contexto contraditório;
• timeout de integração;
• resposta inválida do modelo;
• classificação com baixa confiança;
• consulta fora do escopo.

Esses cenários deveriam ter critérios claros.

Por exemplo:

Dado que nenhum conteúdo relevante foi recuperado, quando o sistema tentar gerar uma resposta, então a geração deve ser interrompida e o usuário deve receber uma mensagem informando que não foi possível localizar informação suficiente.

Isso evita que a camada generativa tente compensar uma falha anterior.

Como escrever critérios de aceite testáveis

Uma forma prática é separar a avaliação em dimensões.

Contexto

Pergunte:

• o conteúdo correto foi recuperado?
• existem trechos essenciais ausentes?
• foram recuperadas informações irrelevantes?

Completude

Pergunte:

• todos os pontos necessários estão presentes?
• alguma condição importante foi omitida?
• a resposta apresenta apenas parte da informação?

Fundamentação

Pergunte:

• a resposta está sustentada pelo contexto?
• existem afirmações que não aparecem na base?
• as fontes utilizadas são compatíveis com a resposta?

Segurança

Pergunte:

• o sistema respondeu mesmo sem contexto suficiente?
• extrapolou o conteúdo disponível?
• respeitou as regras de negativa?

Formato

Pergunte:

• a resposta possui a estrutura esperada?
• os campos obrigatórios estão presentes?
• o resultado pode ser consumido pelo próximo sistema?

Esse modelo ajuda a sair de uma avaliação subjetiva como:

“Gostei da resposta.”

para algo verificável:

“A resposta contém os três elementos obrigatórios, utiliza apenas o contexto recuperado e apresenta as fontes correspondentes.”

Exemplos práticos

Exemplo 1: pergunta respondida pela base

Dado que a base contém todas as informações necessárias para responder à pergunta,

Quando o usuário realizar a consulta,

Então o sistema deve:

• recuperar o conteúdo relevante;
• responder utilizando exclusivamente o contexto disponível;
• incluir todas as condições necessárias;
• apresentar as referências utilizadas.

Exemplo 2: informação incompleta

Dado que a recuperação encontrou apenas parte da informação necessária,

Quando a resposta depender de conteúdo ausente,

Então o sistema não deve apresentar uma conclusão definitiva.

Exemplo 3: pergunta fora da base

Dado que não exista conteúdo relacionado à pergunta na base,

Quando o usuário realizar a consulta,

Então o sistema deve informar que não possui informação suficiente para responder e não deve utilizar conhecimento externo.

Exemplo 4: saída estruturada

Dado que a funcionalidade exige integração com outro sistema,

Quando a IA finalizar o processamento,

Então a saída deve ser um JSON válido e conter todos os campos obrigatórios definidos no contrato.

Critérios de aceite não substituem avaliação de IA

Existe ainda uma diferença importante entre critérios de aceite e avaliação contínua.

Critérios de aceite ajudam a definir se uma funcionalidade atende às regras mínimas para avançar.

Mas produtos de IA precisam também de conjuntos maiores de testes.

Isso pode envolver:

• perguntas de referência;
• respostas esperadas;
• avaliação de relevância;
• avaliação de completude;
• análise de groundedness;
• comparação entre versões;
• testes de regressão.

Em vez de avaliar apenas uma resposta individual, passa a ser possível observar o comportamento do sistema em dezenas ou centenas de cenários.

Checklist para critérios de aceite em produtos com IA

Antes de considerar uma funcionalidade pronta, eu verificaria:

• O sistema recuperou o contexto correto?
• A informação recuperada é suficiente?
• A resposta está completa?
• A resposta está fundamentada?
• Existe conteúdo externo à base?
• O sistema sabe quando não responder?
• O formato de saída está correto?
• Cenários de erro foram considerados?
• Existem testes para exceções?
• O comportamento pode ser validado novamente após mudanças?

Conclusão

Em produtos com IA, um critério de aceite não deve avaliar apenas se a resposta parece boa.

Ele precisa definir o comportamento esperado do sistema.

Isso envolve recuperação, contexto, completude, fundamentação, formato, segurança e tratamento de falhas.

Quanto mais claro estiver o comportamento esperado, menos a validação depende de percepção subjetiva.

E isso muda a pergunta de:

“A IA respondeu certo?”

para:

“O sistema se comportou como o produto deveria se comportar?”

Essa segunda pergunta costuma ser muito mais útil para construir produtos de IA confiáveis.

Texto autoral, baseado em aprendizados de projetos reais, com informações sensíveis removidas.