Dataset de avaliação para agentes de IA: como criar

Um placar confiável começa antes da primeira execução

Uma equipe separa cem conversas comerciais para testar um agente. O material parece suficiente: há leads novos, negociações abertas e mensagens de clientes. A versão candidata acerta 92% dos casos e recebe aprovação.

Depois da publicação, o agente falha em oportunidades com mais de um decisor, compromissos registrados fora do CRM e condições comerciais vencidas. Esses casos quase não apareciam na amostra. O percentual estava correto para o conjunto escolhido. O conjunto é que representava mal o trabalho.

Um dataset de avaliação para agentes de IA é uma coleção versionada de unidades de trabalho, entradas, contexto permitido, resultados esperados e critérios de correção. Ele serve para comparar versões, medir regressões, testar controles e apoiar decisões de liberação.

A qualidade desse dataset depende da cobertura do processo. Volume ajuda, mas não corrige uma seleção formada apenas por casos fáceis ou por registros que sobreviveram melhor à organização dos sistemas.

Dataset de avaliação, massa de teste e dados de treinamento

Os três artefatos podem usar conteúdos parecidos, mas possuem funções diferentes.

Massa de teste

Exercita sistemas, integrações, estados e falhas em ambiente controlado. Pode incluir muitos dados sintéticos para validar schema, permissões, filas e efeitos sem copiar produção.

Dados de treinamento

São usados para ajustar parâmetros, exemplos, instruções ou outros componentes. O sistema pode aprender padrões presentes nesse material.

Dataset de avaliação

Permanece separado do processo de ajuste que será medido. Ele oferece uma referência estável para comparar versões. Se a equipe usa os mesmos casos para corrigir o agente e provar a correção, o placar passa a medir familiaridade com a amostra.

Um caso pode nascer da operação e gerar versões diferentes para cada finalidade. A cópia usada no desenvolvimento não deveria substituir a amostra reservada para avaliação final.

Comece pela unidade de trabalho

A unidade precisa corresponder ao objeto que a operação reconhece. Uma mensagem isolada pode ser insuficiente quando a decisão depende do histórico da oportunidade, do prazo e da política vigente.

Exemplos de unidades:

oportunidade comercial com próxima ação;
chamado com encaminhamento e resolução esperados;
pedido com validações e pendências;
documento com campos, fonte e decisão;
contrato com cláusulas e divergências;
cadastro com identidade e estado;
cobrança com compromisso e limite de contato;
reunião com contexto, decisões e tarefas.

Para cada unidade, descreva o ponto de entrada e o encerramento esperado. “Responder ao cliente” deixa várias interpretações abertas. “Classificar o pedido, localizar a política vigente, preparar resposta para revisão e registrar a pendência correta” permite avaliar execução e resultado.

O artigo sobre como avaliar agentes de IA organiza métricas e comparação entre versões. Aqui, o foco está no ativo que alimenta essa avaliação.

Faça um mapa do processo antes de selecionar casos

A amostra deve representar decisões, exceções e consequências, além da frequência bruta dos eventos.

Registre:

etapas do fluxo;
estados possíveis da unidade;
fontes usadas em cada etapa;
ferramentas e efeitos permitidos;
regras de negócio;
pontos de aprovação;
tipos de exceção;
falhas técnicas relevantes;
classes de risco;
resultado que o sistema oficial precisa confirmar.

Esse mapa mostra onde a cobertura precisa existir. Se o agente atua em sete etapas e todos os casos terminam antes da primeira escrita no CRM, a avaliação não prova o trecho com consequência operacional.

Monte a cobertura em camadas

Uma distribuição fiel ao volume médio ainda pode ignorar situações raras que impedem a entrada em produção. Use camadas complementares.

Casos comuns

Representam o trabalho frequente e ajudam a medir capacidade, custo, tempo e qualidade média.

Variações legítimas

Mudam linguagem, ordem, canal, quantidade de informação ou estrutura sem mudar a decisão correta. Elas mostram se o agente aprendeu a responsabilidade ou apenas um formato.

Dados incompletos

Exigem pedir complemento, bloquear conclusão ou encaminhar pendência. O agente precisa reconhecer o limite sem preencher lacunas por plausibilidade.

Fontes conflitantes

CRM, contrato, e-mail e documento podem divergir. O caso deve declarar qual fonte possui autoridade ou qual pessoa resolve o conflito.

Exceções de negócio

Incluem alçada, condição especial, cliente fora do padrão, documento vencido, estado incompatível e regra ausente.

Falhas de ferramenta

Timeout, permissão negada, resposta vazia, schema incompatível e confirmação perdida revelam se a execução preserva estado.

Segurança e privacidade

Dados de outro cliente, instrução maliciosa em documento, destinatário não autorizado e pedido fora do escopo devem testar barreiras objetivas.

Casos raros de alto impacto

Uma classe com baixa frequência pode merecer peso decisivo quando envolve dinheiro, exclusão, dados sensíveis, contrato ou comunicação em lote.

O dataset deve registrar frequência operacional e importância de teste como campos separados. Um caso raro não precisa dominar a média para bloquear uma versão insegura.

Use casos históricos sem transformar o passado em verdade automática

Registros reais preservam linguagem, sujeira, dependências e exceções que a equipe costuma esquecer ao inventar exemplos. Também carregam limitações.

O histórico pode conter:

decisões humanas inconsistentes;
regra antiga;
procedimento informal;
erro que nunca foi corrigido;
dados pessoais além da finalidade;
resultados sem confirmação;
casos fáceis porque os difíceis ficaram fora do sistema;
seleção enviesada pelo canal disponível.

Cada caso histórico precisa de revisão. A ação realizada no passado é evidência do que aconteceu, não prova de que era a resposta correta.

Antes de incluir o item, confirme a política aplicável na época ou escolha explicitamente avaliar pela regra atual. Registre essa decisão para evitar que a equipe compare versões contra um rótulo sem autoridade.

Combine histórico, casos dirigidos e dados sintéticos

Nenhuma origem cobre tudo sozinha.

Use históricos tratados para representar o trabalho real. Crie casos dirigidos para políticas, limites e incidentes que precisam de cobertura garantida. Use dados sintéticos para estados perigosos ou raros que não deveriam ser reconstruídos com informação de clientes.

Uma composição possível separa:

amostra de frequência, próxima da distribuição observada;
amostra de cobertura, com pelo menos um caso por regra e exceção relevante;
amostra de segurança, com tentativas de atravessar limites;
amostra de regressão, formada por falhas já corrigidas;
amostra de desempenho, com volume, tamanho e concorrência representativos.

Esses grupos não precisam virar uma única nota. Eles respondem perguntas diferentes.

Defina a resposta esperada como um contrato

Uma resposta de referência não precisa exigir o mesmo texto. Ela precisa separar o que pode variar do que deve permanecer.

Para uma tarefa comercial, o contrato pode incluir:

estágio correto da oportunidade;
compromisso mais recente;
evidências obrigatórias;
campos que podem ser propostos;
campos que não podem ser alterados;
necessidade de aprovação;
ação externa permitida;
condição de bloqueio;
próxima ação válida;
confirmação esperada no CRM.

Classifique os critérios.

Determinísticos

Schema, identificador, cálculo, enumeração, permissão, fonte, prazo e confirmação podem ser validados por regra ou código.

Semânticos

Completude, aderência ao pedido, tom e qualidade da síntese podem exigir especialista, rubric ou avaliador automatizado calibrado.

Impeditivos

Vazamento, ação indevida, mistura de clientes, ausência de aprovação e efeito duplicado devem bloquear a versão mesmo quando a média permanece alta.

Graduais

Clareza, concisão e esforço de revisão podem usar escala curta com exemplos de cada faixa.

O contrato também deve indicar quando mais de uma resposta é válida. Processos humanos admitem alternativas. Forçar uma única redação pode penalizar uma solução correta e premiar imitação.

Registre a origem e a autoridade do rótulo

Cada resultado esperado precisa de proveniência.

Inclua:

responsável pelo rótulo;
função ou competência da pessoa;
fonte e versão da regra;
data da revisão;
justificativa para casos ambíguos;
divergências entre avaliadores;
decisão final e autoridade;
próxima data de validade, quando aplicável.

Se dois especialistas discordam com frequência, o dataset encontrou um problema do processo. Resolver essa divergência antes de culpar o agente melhora a política e reduz revisão futura.

Separe desenvolvimento, validação e teste reservado

A equipe precisa corrigir erros observados durante o desenvolvimento. Para isso, alguns casos ficam visíveis e podem orientar ajustes.

Outros devem permanecer reservados para a decisão final.

Uma estrutura simples usa:

desenvolvimento: casos conhecidos, usados para depurar e melhorar;
validação: amostra usada para comparar candidatas durante o ciclo;
teste reservado: casos não usados no ajuste, abertos somente no gate definido;
produção observada: casos reais acompanhados em modo sombra ou alcance limitado.

A divisão deve ocorrer pela unidade operacional. Separar mensagens da mesma oportunidade entre desenvolvimento e teste deixa parte do contexto vazar. Documentos duplicados, conversas encadeadas e versões do mesmo caso também precisam permanecer no mesmo grupo.

Controle contaminação e memorização

Um caso deixa de ser independente quando aparece em prompts, exemplos, tickets de correção, documentação pública ou arquivos acessíveis ao agente durante a avaliação.

Mapeie:

casos usados em desenvolvimento;
incidentes transformados em exemplo;
artefatos incluídos na base de conhecimento;
respostas compartilhadas com fornecedores;
datasets usados em fine-tuning;
execuções anteriores que alimentam memória;
duplicatas ou variações quase idênticas;
conteúdo público possivelmente conhecido pelo modelo.

Contaminação não torna o caso inútil. Muda sua função. Ele pode continuar na regressão, mas não deveria sustentar sozinho uma afirmação de generalização.

Quando houver suspeita, marque o item e leia o resultado separadamente. Uma nota única esconde a diferença entre casos novos e casos já familiares.

Proteja dados e respeite a finalidade

Datasets de avaliação costumam concentrar conversas, documentos, erros e exceções. Esse acervo pode ser mais sensível que a própria base operacional porque reúne exemplos de várias áreas e clientes em um só lugar.

Defina:

finalidade da coleção;
base autorizada para uso;
classes de dados permitidas;
anonimização ou pseudonimização necessárias;
acesso por papel;
ambiente de armazenamento;
fornecedores que podem receber o material;
prazo de retenção;
procedimento de correção e exclusão;
proibição de uso para treinamento não autorizado.

Use a minimização de dados para retirar campos sem função avaliativa. Preserve as características que mudam a decisão sem carregar identidade completa por conveniência.

Versione o dataset como parte da versão do agente

Processos mudam. Políticas, campos, produtos, integrações e comportamentos de clientes também. Um dataset pode continuar estável e deixar de representar a operação.

Registre em cada versão:

identificador;
unidades incluídas e retiradas;
schema dos casos;
distribuição por classe;
regras e fontes vigentes;
resultados esperados;
origem de cada item;
divisão entre conjuntos;
transformações de privacidade;
ferramentas simuladas ou reais;
data e responsáveis;
motivo da mudança.

Não substitua silenciosamente a amostra depois de uma queda de resultado. Preserve a versão anterior para explicar a regressão e publique uma nova composição com justificativa.

O controle de mudanças em agentes de IA deve vincular a versão candidata ao dataset, ao ambiente e ao resultado executado.

Evite que o placar esconda as classes críticas

Uma média geral pode melhorar enquanto o agente piora exatamente onde possui mais autonomia.

Leia resultados por:

tipo de unidade;
etapa do processo;
fonte;
canal;
complexidade;
risco;
ação permitida;
caso comum ou exceção;
histórico ou sintético;
conhecido ou reservado;
versão da política;
necessidade de intervenção humana.

Defina pesos apenas quando representam uma decisão real. Ajustar pesos depois de ver o resultado transforma avaliação em negociação com o placar.

Além da qualidade, acompanhe tempo, custo, chamadas de ferramenta, correção humana, efeito confirmado e estabilidade entre repetições. Um agente pode acertar mais e consumir revisão suficiente para eliminar o ganho operacional.

Faça manutenção orientada por mudanças reais

O dataset precisa receber novos casos quando:

ocorre incidente ou quase incidente;
aparece exceção sem cobertura;
uma regra muda;
fonte ou integração ganha nova versão;
o agente recebe outra ferramenta;
a autonomia aumenta;
entra novo cliente, produto ou canal;
avaliadores discordam de forma recorrente;
a produção mostra distribuição diferente da amostra;
um caso antigo perde validade.

Nem todo evento entra para sempre. Casos redundantes podem ser consolidados. Itens vencidos saem da avaliação corrente e permanecem somente quando ajudam a investigar versões antigas.

A manutenção deve preservar cobertura e legibilidade. Acumular cada falha cria uma suíte lenta, cara e cheia de repetições.

Um workflow mínimo para empresas

1. Escolha uma responsabilidade delimitada

Defina unidade, entrada, saída, fontes, efeitos e responsável.

2. Mapeie classes e riscos

Liste caminho comum, variações, exceções, falhas, segurança e ações impeditivas.

3. Selecione históricos e crie lacunas

Revise casos reais, retire dados sem finalidade e complete a cobertura com cenários dirigidos ou sintéticos.

4. Rotule com autoridade

Use regra, sistema oficial e especialista. Registre discordância e decisão.

5. Separe os conjuntos

Evite que ajuste, validação e teste reservado compartilhem a mesma unidade ou duplicatas.

6. Execute uma linha de base

Rode a versão atual e registre qualidade, erros críticos, custo, tempo e revisão.

7. Teste a candidata

Congele composição, ambiente e dataset. Compare as mesmas classes.

8. Decida por gate

Aprovar, limitar, corrigir ou rejeitar conforme métricas e erros impeditivos definidos antes.

9. Observe produção limitada

Confirme se a amostra representa o fluxo e se usuários incorporam o resultado.

10. Atualize com evidência

Transforme falhas novas em cobertura sem apagar o histórico da versão.

Checklist do dataset de avaliação

[ ] A unidade corresponde ao trabalho real?
[ ] O mapa cobre etapas, fontes, regras e efeitos?
[ ] Casos comuns e variações legítimas estão representados?
[ ] Dados incompletos, conflitos e exceções possuem cobertura?
[ ] Falhas técnicas e estados incertos foram incluídos?
[ ] Casos raros de alto impacto têm critérios impeditivos?
[ ] Históricos foram revisados em vez de copiados como verdade?
[ ] Dados sintéticos completam lacunas sem inventar autoridade?
[ ] Cada caso possui resultado esperado e fonte do rótulo?
[ ] Critérios determinísticos e semânticos estão separados?
[ ] Desenvolvimento, validação e teste reservado não compartilham unidades?
[ ] Duplicatas e contaminação são detectadas?
[ ] Dados pessoais e de clientes seguem finalidade, acesso e retenção?
[ ] Dataset, políticas e schemas possuem versão?
[ ] O placar abre resultado por classe de risco?
[ ] Incidentes e mudanças alimentam manutenção controlada?
[ ] A decisão termina em escopo e autonomia autorizados?

A base de avaliação precisa representar decisões

Um dataset útil permite que a empresa compare versões sem depender de demonstrações escolhidas pelo fornecedor ou de respostas que apenas parecem corretas.

Ele reúne o trabalho frequente, as exceções que consomem especialistas, os limites que protegem a operação e os efeitos que precisam ser confirmados. Também preserva origem, regra, versão e responsabilidade sobre cada expectativa.

Quando esse ativo existe, trocar modelo, ajustar instrução ou ampliar autonomia deixa de ser uma aposta baseada em algumas respostas. A empresa consegue dizer em quais classes a versão melhorou, onde ainda falha e qual alcance a evidência realmente autoriza.