Como organizar casos de avaliação para IA

Um dataset de avaliação de inteligência artificial é um artefato vivo de governança. Ele ajuda a decidir quando registra de onde os casos vieram, que papel cumprem, quais rótulos sustentam a avaliação e quando precisam ser revisados. Sem essa disciplina, a equipe pode melhorar a pontuação e continuar cega para falhas relevantes, critérios ambíguos ou exemplos antigos que já não descrevem o produto.

Quando a base de casos deixa de medir o que importa

Em muitos times, a base nasce de forma acumulativa. A equipe começa com alguns exemplos reais, adiciona situações lembradas por especialistas, inclui bugs corrigidos, copia respostas antigas, cria perguntas difíceis para testar o limite do sistema e, em pouco tempo, chama tudo isso de base de avaliação.

O problema não está em reunir casos variados. O problema está em tratar casos com funções diferentes como se fossem a mesma coisa.

Um caso frequente mostra o uso comum. Uma exceção crítica mostra risco. Um caso exploratório testa uma hipótese ainda imatura. Um bug antigo pode servir para regressão, mas talvez já não represente o comportamento esperado do produto. Quando todos entram na mesma média sem identificação, a nota final ganha aparência de objetividade, mas perde poder de decisão.

Este artigo não trata de como desenhar uma avaliação inteira, tema que se aproxima de como criar uma avaliação de uma aplicação de IA. O foco aqui é mais específico: organizar os casos de avaliação para que a liderança consiga entender o que a nota mede, o que ela não mede e que tipo de revisão ainda falta.

Uma base bem organizada não elimina julgamento humano. Ela registra esse julgamento para que possa ser comparado e revisado.

Separe casos representativos, casos críticos e casos exploratórios

A primeira decisão é separar a origem e a função de cada caso. Sem isso, a base mistura volume, risco e curiosidade técnica.

Casos representativos são aqueles que refletem usos recorrentes do produto. Eles ajudam a responder: a funcionalidade funciona bem nos cenários que as pessoas realmente encontram com frequência? Em um assistente de atendimento, por exemplo, podem incluir dúvidas sobre prazo de entrega, política de troca e status de pedido.

Casos críticos cobrem situações raras, mas com alto impacto. Eles não precisam aparecer em grande quantidade para merecer atenção. Uma resposta que autoriza cancelamento indevido, expõe informação inadequada ou orienta uma ação errada pode bloquear uma decisão mesmo que os casos comuns estejam satisfatórios.

Casos exploratórios testam hipóteses novas. Eles são úteis para aprender, mas perigosos quando entram cedo demais na métrica principal. Se toda hipótese recém-criada altera a nota oficial, a avaliação vira um instrumento instável. A equipe passa a discutir a oscilação da pontuação, não a qualidade da decisão.

Uma forma prática de organizar a base é marcar cada caso com sua função:

• Uso recorrente: mede comportamento esperado em situações comuns.
• Risco crítico: mede falhas que podem impedir exposição ou ampliar exigência de revisão.
• Regressão: mede se um problema corrigido voltou a acontecer.
• Reclamação ou evidência de campo: registra algo observado no uso real, quando houver essa evidência.
• Hipótese exploratória: investiga uma dúvida antes de virar critério oficial.

Essa separação também reduz uma confusão frequente: achar que representatividade significa apenas ter muitos exemplos. Representatividade, aqui, significa que a base cobre os usos e riscos que importam para aquela decisão de produto.

Registre rótulos como decisão, não como opinião solta

Rótulo de avaliação não é apenas a “resposta certa”. É a decisão registrada sobre o que conta como sucesso, falha, resposta incompleta ou situação que exige revisão.

Se um caso traz apenas uma entrada e uma resposta ideal, ele pode servir como referência inicial. Mas, sozinho, não explica por que uma execução futura deve passar ou falhar. Duas pessoas podem discordar razoavelmente sobre uma resposta parcialmente correta. O rótulo existe para tornar essa discordância visível e reduzir ambiguidade desnecessária.

Cada caso deveria registrar, no mínimo:

• Entrada: o pedido, contexto ou evento usado na avaliação.
• Resultado esperado: o que a funcionalidade deveria produzir ou acionar.
• Critério de sucesso: como decidir se a resposta passa, falha ou exige revisão.
• Razão do rótulo: por que aquele julgamento foi adotado.
• Origem do caso: uso recorrente, risco, regressão, reclamação, decisão de produto ou hipótese.
• Responsável pela revisão: pessoa ou papel que pode atualizar o caso.
• Status: novo, validado, em observação, obsoleto ou aposentado.

Essa estrutura não precisa começar sofisticada. Pode começar simples. O ponto é impedir que a base dependa de memória oral. Quando um rótulo não explica sua razão, a avaliação fica vulnerável a duas distorções: repetir decisões antigas sem contexto ou ajustar o critério para caber no resultado desejado.

Em funcionalidades com IA, isso é especialmente relevante porque a resposta pode variar. A avaliação não deve depender apenas de comparação literal com uma resposta modelo. Em muitos casos, a pergunta correta é: esta resposta é aceitável para o usuário, respeita o limite do produto e evita uma ação perigosa?

Essa distinção se conecta a discussões maiores sobre qualidade de software com IA, mas a decisão prática aqui é menor e mais operacional: todo rótulo precisa carregar o julgamento que permitirá comparar execuções futuras.

Registre que tipo de evidência cada caso exige

Em funcionalidades simples, talvez baste verificar a resposta final. Em fluxos com agentes, ferramentas externas ou múltiplas etapas, isso pode ser insuficiente.

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 basta para comprovar o resultado. Essa distinção é útil para organizar casos de avaliação, porque resultado e trajetória respondem a perguntas diferentes.

Resultado final pergunta: a tarefa foi concluída no ambiente esperado? A informação foi registrada? A resposta entregue ao usuário está correta? A ação solicitada foi realmente executada?

Trajetória pergunta: o agente seguiu etapas aceitáveis? Consultou a fonte correta? Evitou uma ferramenta proibida? Pediu confirmação quando deveria? Interrompeu a execução ao encontrar uma condição insegura?

Nem todo caso precisa avaliar trajetória. Se a experiência do usuário depende apenas da resposta final e não há risco relevante no caminho, registrar etapas pode virar ruído. Mas, quando o desenho do produto faz o caminho afetar segurança, custo, privacidade, rastreabilidade ou reversão, a trajetória vira parte do critério.

A mesma fonte da Anthropic descreve avaliações com entradas, critérios de sucesso e verificadores, e aponta que podem ser necessárias várias tentativas em avaliações de agentes. Como critério prático, a base de casos deve explicitar o que será verificado, em vez de presumir que uma resposta confiante equivale a sucesso.

Um caso pode ter, por exemplo:

• Verificador de resposta: compara se a orientação final está dentro da política do produto.
• Verificador de ambiente: confirma se a alteração pretendida ocorreu de fato.
• Verificador de trajetória: identifica se o agente usou uma fonte permitida ou pediu confirmação antes de agir.
• Verificador humano: exige revisão quando o julgamento depende de contexto ainda não automatizado.

Isso evita um falso conforto. A IA pode declarar que resolveu. A base de avaliação precisa dizer que evidência comprova isso.

Crie uma rotina para promover, revisar e aposentar casos

Uma base de casos muda junto com o produto. Casos ganham relevância, perdem função ou precisam ser reclassificados.

O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade. Também recomenda manter e revisar suítes de teste, em vez de tratar qualidade como uma etapa posterior ao desenvolvimento. Essa orientação sustenta um ponto simples para avaliações de IA: o dataset precisa de manutenção, não apenas de expansão.

Adicionar casos aumenta cobertura aparente. Decidir o que cada caso passa a significar aumenta a utilidade da base.

Uma rotina saudável pode tratar casos novos como observação antes de promovê-los para a métrica principal. Isso dá tempo para revisar o rótulo, entender se o caso representa uso recorrente ou exceção crítica, definir o verificador adequado e decidir se ele deve influenciar a nota agregada.

Também é necessário aposentar casos. Um exemplo pode ficar obsoleto porque a política do produto mudou, porque a funcionalidade deixou de existir, porque o risco foi redesenhado ou porque o caso era uma hipótese exploratória que não se confirmou como relevante. Manter tudo para sempre não aumenta rigor. Muitas vezes, apenas preserva decisões antigas que ninguém quer mais defender.

Uma rotina simples de revisão pode responder:

• Este caso ainda representa uso, risco ou decisão atual do produto?
• O rótulo continua compreensível para alguém que não participou da discussão original?
• O critério de sucesso está mais claro do que estava na última revisão?
• Este caso deve entrar na métrica principal, ficar em observação ou ser aposentado?
• Houve mudança no produto que exige novo verificador?

Há uma analogia útil com lançamentos graduais. O capítulo de Google SRE sobre canários trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar exposição e distingue disponibilizar código de ativar funcionalidades. Para uma base de avaliação, a implicação não é copiar o processo de canário, mas preservar a mesma disciplina: separar preparação, ativação e ampliação da confiança.

Um caso pode estar disponível na base, mas ainda não ativado na métrica principal. Essa separação ajuda a aprender sem transformar toda descoberta em bloqueio imediato ou em ruído estatístico.

Exemplo fictício: base de casos para um assistente de atendimento

Considere um exemplo fictício: uma empresa cria um assistente de atendimento para responder dúvidas sobre pedidos, trocas e cancelamentos. O objetivo da base não é provar que o assistente “é bom”. É apoiar decisões sobre liberação, revisão e limites de autonomia.

Um caso representativo poderia ser uma pergunta sobre prazo de troca de um produto comprado recentemente. A entrada registra a pergunta do usuário e o contexto permitido. O rótulo define que a resposta deve explicar a política de troca vigente, informar o canal adequado e evitar prometer exceções. O critério de sucesso aceita variações de linguagem, mas falha respostas que inventem prazo, ignorem restrições ou encaminhem para um canal inexistente.

Um caso crítico poderia envolver cancelamento de pedido. A entrada simula um usuário pedindo cancelamento imediato de uma compra feita por outra pessoa da conta. O rótulo não deve apenas dizer “não cancelar”. Deve explicar que o assistente precisa pedir confirmação adequada ou encaminhar para revisão, conforme o desenho do produto. O verificador, nesse caso, pode olhar tanto a resposta quanto a ação executada. Se o assistente apenas disser que cancelou, isso não comprova nada. Se ele executar cancelamento sem condição necessária, o caso falha.

Um caso exploratório poderia testar ambiguidade de intenção: “não quero mais esse pedido desse jeito”. A equipe ainda não sabe se essa frase deve acionar troca, cancelamento, atendimento humano ou pedido de esclarecimento. Em vez de jogar o caso na métrica principal, ele entra como hipótese exploratória. O rótulo fica em observação até que produto, atendimento e qualidade decidam o comportamento esperado.

Um caso de regressão poderia vir de um bug já corrigido: o assistente confundia política de troca com política de garantia. Esse caso entra com origem marcada como regressão. Ele pode fazer parte da métrica principal se o risco ainda for relevante, ou ficar em uma suíte específica para impedir retorno do problema.

O mesmo caso, portanto, não é apenas uma linha na planilha. Ele carrega entrada, rótulo, critério de sucesso, risco, origem, verificador e status de revisão. Essa é a diferença entre uma coleção de exemplos e um dataset de avaliação de IA que sustenta decisão.

Critério de prontidão: a base serve para decidir ou só para pontuar?

A pergunta final não é se a base está grande. É se ela permite uma decisão honesta.

Um dataset de avaliação de IA está mais pronto quando a liderança consegue olhar para a nota e, ao mesmo tempo, entender sua composição. Quais casos medem uso comum? Quais cobrem exceções críticas? Quais ainda são exploração? Quais rótulos foram revisados? Quais verificadores comprovam resultado no ambiente, e não apenas uma declaração do modelo?

Revise estes campos antes de tratar a base como referência para decisão:

• Origem e função: cada caso indica de onde veio e que papel cumpre na avaliação?
• Peso na decisão: falhas raras e graves aparecem identificadas sem serem diluídas na média geral?
• Rótulo: o caso registra resultado esperado e motivo do julgamento?
• Critério de sucesso: a base diferencia resposta aceitável, ideal, perigosa e incompleta?
• Evidência exigida: está claro se será avaliado resultado final, trajetória de execução, evidência no ambiente ou combinação desses elementos?
• Revisão: cada caso tem status, responsável ou motivo para próxima revisão?
• Uso da métrica: a equipe separa casos da métrica principal de casos usados apenas para investigação?

Se a resposta for negativa em muitos pontos, a base talvez ainda sirva para aprender, mas não para decidir sozinha. Esse limite precisa aparecer no próprio status da base, para separar aprendizado, investigação e referência de decisão.

A decisão concreta é organizar a base em três camadas: representatividade, rótulos e revisão. Com isso, a nota deixa de ser um placar isolado e passa a mostrar quais casos sustentam a decisão, quais ainda estão em observação e quais já deveriam ser aposentados.

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

Leituras para continuar

• Como avaliar um agente que executa ações
• Como testar regressões em funcionalidades de IA

Fontes

• DORA: automação de testes
• Anthropic: avaliações de agentes
• Google SRE: lançamentos graduais