Resposta direta
O conjunto de teste só aprova o que já funciona porque reproduz o caso médio. A correção é tratar dificuldade como item de projeto: classificar cada caso por tipo de entrada, listar onde o sistema erra hoje e converter cada erro observado em caso permanente. Dificuldade não vem de inventar exemplos raros, vem de registrar o que já falhou. Depois, aprovar só quando o resultado por faixa de dificuldade estiver visível, e não pela média geral. Sem esse recorte, a média esconde a falha que aparece no uso.
- Objetivo
- Orientar implementação
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a composição de dificuldade do conjunto de teste e a leitura do resultado por faixa, ponto que as outras páginas do tema não cobrem.
Como o caso fácil entra no conjunto
O conjunto de teste costuma nascer do material disponível: exemplos da documentação, pedidos escritos com clareza, entradas no formato previsto. São casos que a equipe sabe responder. Por isso passam.
Esse recorte não é desonesto, é o caminho de menor esforço. O problema aparece quando a decisão de liberar uma mudança usa a média desses casos. A média trata entrada ambígua e entrada limpa com o mesmo peso.
Repor dificuldade a partir do que já falhou
A fonte mais confiável de caso difícil é a operação: toda saída errada registrada, com a entrada original e o resultado esperado. Cada falha vira um caso fixo, com data e origem.
Antes de rodar, cada caso recebe uma faixa de dificuldade conforme o tipo de erro que provoca. A leitura do resultado passa a ser por faixa. Uma mudança que melhora a faixa difícil e piora a fácil é uma troca, e precisa ser decidida como troca.
O que a correção não resolve
Aumentar a dificuldade do conjunto não conserta critério de aceitação mal definido. Se duas pessoas discordam do que é resposta correta, o caso não tem gabarito, e a contagem de acerto perde sentido.
Também não cobre falha de origem externa, como dado desatualizado na fonte ou mudança no sistema vizinho. E o conjunto envelhece: a distribuição das entradas reais muda, e um caso difícil de hoje pode virar caso comum. Revisar a composição faz parte da rotina, junto com o critério de aprovação.
Recurso prático
Da falha observada ao caso de teste
- Registrar falhas reais da operação com entrada original, resultado esperado e o que o sistema devolveu, indicando data e origem.
- Classificar cada caso por tipo de entrada: texto curto, texto ambíguo, dado ausente, pedido fora do escopo, formato incomum.
- Marcar a faixa de dificuldade antes de rodar, conforme o erro que o caso provoca, e não conforme a facilidade de montar.
- Rodar a avaliação e ler o resultado separado por faixa, mostrando o que passou e o que falhou em cada uma.
- Congelar no conjunto os casos que falharam e revisar a composição a cada mudança de regra, de fonte de dado ou de modelo.
O erro mais comum é montar casos difíceis a partir de exemplos imaginados. Caso inventado raramente representa a falha real e costuma puxar o teste para o que a equipe já sabe responder. O caso difícil que importa vem de um erro já registrado em operação, com entrada e resultado esperado anotados.
Sobre o que está escrito aqui
Conceitos relacionados: conjunto de teste · faixa de dificuldade · caso de regressão · erro por segmento · critério de aprovação. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Workshop executivo, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- IA aplicada e agentes — Página central do tema
- Ferramentas isoladas: como organizar o fluxo… — ferramentas isoladas
- Ferramentas isoladas: como medir o impacto no… — ferramentas isoladas
Páginas relacionadas
O mesmo problema em outro objetivo
- Conjunto de teste fácil demais: onde a avaliação engana — Diagnosticar
- Teste só com casos fáceis: o que a avaliação não mede — Organizar um processo
- Teste só com casos fáceis: o que a comparação esconde — Comparar alternativas
- Avaliação só com casos fáceis: o que a nota esconde — Explicar medição
- Avaliação só com casos fáceis: o que exigir do fornecedor — Orientar avaliação e contratação
Outras leituras em IA aplicada e agentes
- Avaliar resposta de IA antes de produção: um conjunto de teste que caiba na rotina — Como montar um conjunto de teste com casos reais, o que medir e o critério de aprovação por tipo de uso.
- Modelo escolhido por reputação: como colocar em teste — Descreve como tratar a indicação de mercado como lista de candidatos e usar critério de aceite, teste pequeno e registro para sustentar a escolha.
- Modelo escolhido por reputação: o que verificar na contratação — O que separar entre reputação e evidência ao contratar um modelo de IA: critérios de avaliação, responsabilidade e o que fica fora do contrato.
- Sem caso extremo: como avaliar IA pelo que já acontece — Avaliação de IA a partir de casos comuns: amostra da rotina, classes por consequência do erro e critério de aceite definido antes de ver o resultado.
- Resposta longa tratada como boa: onde entra o critério — Descreve por que extensão é lida como qualidade em respostas de IA e como amarrar o critério de aceite ao uso declarado antes da aprovação.