Dataset de avaliação para agente de IA: monte com conversas reais

Dataset de avaliação para agente de IA: monte com conversas reais

Para montar um dataset de avaliação para agente de IA, parta de conversas reais do atendimento: selecione uma amostra que represente o dia a dia e os casos difíceis, remova os dados pessoais e rotule cada caso com o resultado esperado e o critério de aprovação. O conjunto vira o teste de regressão do agente, e toda mudança de prompt, modelo ou ferramenta roda contra ele antes de ir para produção. Comece pequeno, mas apenas com situações que de fato aconteceram.

Principais pontos

• Conversas reais mostram como o cliente escreve, erra, muda de assunto e manda áudio. Casos inventados quase sempre são educados demais.
• A amostra precisa misturar casos comuns, de borda e de risco, e não apenas os exemplos fáceis de acertar.
• Anonimizar é decidir o que o teste precisa manter (intenção, contexto, tom) e remover o resto (nome, telefone, documento, endereço).
• Cada conversa recebe um rótulo com o resultado esperado, o que o agente não pode fazer e quando deve passar para uma pessoa.
• O conjunto não é um arquivo fixo: ele cresce a cada falha encontrada em produção e é revisado por quem conhece o processo.

Por que usar conversas reais em vez de casos inventados?

Quando uma equipe escreve os próprios exemplos de teste, ela escreve como imagina que o cliente fala. O cliente real manda três perguntas na mesma mensagem, responde algo que não tem relação com a pergunta anterior, abrevia, usa gíria regional, envia foto desfocada e some por duas horas antes de voltar. Um agente que passa em exemplos limpos pode falhar justamente nessas situações.

Há também um efeito de viés. Quem cria o teste conhece o prompt e tende, sem perceber, a escrever casos que o agente já sabe resolver. Conversas reais não têm esse vício. Elas trazem as perguntas que ninguém previu na hora de escrever as instruções.

A documentação de avaliação de agentes publicada por fabricantes de modelos segue a mesma lógica: começar por tarefas reais, com critérios claros de sucesso, e ampliar o conjunto à medida que surgem falhas. Vale ler o guia da Anthropic sobre avaliações de agentes e o guia de evals da OpenAI (links ao final) para ver como cada um estrutura tarefas, execuções e avaliadores.

Como selecionar as conversas: comuns, de borda e de risco

O erro mais frequente é pegar as últimas conversas do histórico e chamar isso de amostra. As últimas conversas refletem uma semana específica, uma campanha específica, talvez um problema temporário. Prefira montar a seleção por categorias, olhando um período mais longo.

Use este guia de decisão para classificar cada conversa candidata:

• Caso comum: pergunta frequente com resposta clara (horário, status de pedido, segunda via, agendamento simples). Esses casos protegem o básico e devem ser a maior parte do conjunto.
• Caso de borda: o pedido é legítimo, mas foge do roteiro (duas intenções na mesma mensagem, cliente que corrige a informação no meio da conversa, pedido fora da área atendida, mensagem só com áudio ou imagem).
• Caso ambíguo: faltam dados para responder e o agente deveria perguntar, não adivinhar.
• Caso de risco: reclamação com tom de ameaça, pedido de reembolso, dado sensível, questão jurídica, saúde ou segurança. O resultado esperado quase sempre é encaminhar para uma pessoa.
• Tentativa de desvio: o cliente pede para o agente ignorar regras, revelar instruções ou prometer algo fora da política. Esses casos conversam com o tema de guardrails, que detalhamos em guardrails para agentes de IA.
• Caso sem resposta no material: a informação não existe na base do agente. O comportamento correto é admitir isso e encaminhar.

Se o volume permitir, peça a quem atende no dia a dia que aponte as conversas que mais deram trabalho. Essa lista costuma revelar casos de borda que nenhuma busca automática encontraria. Inclua também conversas que o atendimento humano resolveu mal, porque elas mostram onde o próprio processo é confuso e o rótulo esperado precisa de uma decisão do negócio.

Como anonimizar sem destruir o contexto?

A pergunta de partida é: o que o teste precisa para ser útil? Em geral, precisa da intenção do cliente, da sequência das mensagens, do tom e dos fatos relevantes para a decisão (por exemplo, que o pedido foi feito há alguns dias, ou que o produto está fora da garantia). Quase nunca precisa do nome verdadeiro, do telefone, do CPF ou do endereço.

Uma rotina simples de anonimização:

• Remova ou substitua identificadores diretos: nome, telefone, e-mail, CPF, CNPJ, endereço, número de pedido e placa.
• Troque por marcadores consistentes dentro da conversa, como CLIENTE_A, TELEFONE_1 e PEDIDO_X, para que o fio da conversa continue fazendo sentido.
• Revise o texto livre, onde o dado pessoal costuma se esconder: assinaturas, nomes de filhos, local de trabalho, detalhes de saúde, fotos de documentos.
• Trate mídia à parte. Áudios e imagens carregam voz, rosto e documentos. Se o teste precisa deles, use a transcrição já limpa. Sobre os cuidados com esse tipo de conteúdo, veja transcrever áudio de WhatsApp com IA.
• Faça uma segunda leitura por uma pessoa diferente da que anonimizou, antes de o conjunto entrar no repositório.

Um ponto de atenção jurídico: pela LGPD, dado realmente anonimizado, que não permite reidentificar a pessoa por meios razoáveis, sai do alcance da lei. Já dado apenas pseudonimizado (trocar o nome por um código, mantendo uma tabela de correspondência) continua sendo dado pessoal. Na prática, trate o conjunto de testes como dado pessoal até que o time responsável pela privacidade confirme que a anonimização é suficiente. Se o conjunto for enviado a um provedor de modelo fora do Brasil para rodar as avaliações, vale conferir o que dissemos em transferência internacional de dados com IA. A ANPD mantém orientações e materiais oficiais sobre o tema.

Anonimizar também é limitar o acesso. Quem pode ler o conjunto bruto, quem pode ler o conjunto anonimizado e por quanto tempo o bruto é guardado são decisões que devem estar escritas antes do primeiro arquivo ser criado.

Como rotular: o que significa resposta certa em cada conversa?

Rotular não é escrever a resposta perfeita para ser comparada palavra por palavra. Um agente pode responder bem de várias formas. O rótulo deve descrever o que precisa ser verdade na resposta e o que nunca pode acontecer.

Uma ficha de rótulo enxuta para cada conversa:

• Contexto: o que o agente sabe no início (dados do cadastro, política vigente, horário de atendimento).
• Intenção do cliente: o que a pessoa quer de fato, em uma frase.
• Resultado esperado: responder, perguntar um dado que falta, executar uma ação ou encaminhar para uma pessoa.
• Informações obrigatórias: fatos que precisam aparecer na resposta.
• Proibições: promessas, valores, prazos ou diagnósticos que o agente não pode inventar.
• Condição de encaminhamento: em que momento um humano assume e com qual resumo.
• Categoria do caso: comum, borda, ambíguo, risco ou desvio.

A parte mais valiosa costuma ser a lista de proibições. Ela força o negócio a dizer em voz alta o que o agente não pode fazer, e isso muitas vezes revela regras que viviam só na cabeça de uma atendente experiente. Se duas pessoas da operação discordam do rótulo de uma conversa, não esconda o desacordo: é sinal de que a política precisa ser definida, e o caso vira um bom item de teste depois da decisão.

O critério de aprovação pode ser verificado de três formas: regra automática (a resposta contém ou não contém determinada informação, a ação chamada foi a correta), avaliação por outro modelo seguindo uma rubrica, ou revisão humana. Use regra automática onde der, e deixe a revisão humana para os casos de julgamento. Se usar um modelo como avaliador, amostre os resultados e confira à mão, porque o avaliador também erra.

Passo a passo para montar o primeiro conjunto

Um plano que cabe em poucas semanas de trabalho parcial:

• Defina o fluxo que será testado. Escolha um só (por exemplo, agendamento ou status de pedido), não o atendimento inteiro.
• Levante a base: exporte conversas do período, apenas dos canais e fluxos escolhidos, com acesso restrito.
• Classifique por categoria usando o guia da seção anterior e corte duplicatas, mantendo variações reais de linguagem.
• Anonimize e faça a segunda leitura.
• Rotule com a ficha, com a participação de quem opera o processo.
• Separe uma parte pequena como conjunto de reserva, que ninguém usa para ajustar o prompt. Ela serve para checar se o agente melhorou de verdade ou apenas decorou os exemplos.
• Rode o agente atual e registre a linha de base: onde acerta, onde falha, onde encaminha demais.
• Corrija os rótulos que se mostraram ambíguos e só então comece a mudar o agente.

O passo da linha de base é o que mais se pula e o que mais faz falta. Sem ele, qualquer melhoria é impressão. Com ele, a conversa com a diretoria muda de achamos que melhorou para este grupo de casos passou a funcionar e este continua falhando.

Cenário ilustrativo: clínica que reagenda consultas no WhatsApp

Cenário ilustrativo, sem relação com cliente real. Uma clínica pequena quer um agente que reagende consultas pelo WhatsApp. A equipe exporta conversas de reagendamento de vários meses e separa por categoria.

Os casos comuns são pedidos diretos de troca de horário. Entre os de borda, aparecem um paciente que pede para trocar o dia e, na mesma mensagem, pergunta se o exame exige jejum, e outro que diz remarcar para a semana que vem sem informar o dia. Há um caso ambíguo em que a mensagem diz só preciso mudar, sem contexto. Entre os de risco, um paciente relata sintoma forte e pede para adiantar a consulta, e o resultado esperado é encaminhar de imediato para uma pessoa, sem o agente opinar sobre o sintoma. Há ainda um caso de desvio, em que alguém pede para o agente informar os horários de outro paciente.

Na anonimização, nomes viram PACIENTE_A, e os detalhes de saúde são generalizados sempre que o teste não depende deles. Na rotulagem, a lista de proibições inclui dar orientação clínica, confirmar horário que não esteja na agenda e revelar dados de terceiros. Ao rodar o agente, a equipe descobre que ele responde bem aos casos comuns, mas tenta orientar sobre o jejum sem ter a informação. Esse achado vira uma correção de instruções e um caso permanente do conjunto.

Como manter o conjunto vivo e ligá-lo à operação?

Um conjunto de testes parado envelhece. Políticas mudam, produtos mudam, o cliente passa a escrever de outro jeito. Defina um ritual simples: toda falha relevante em produção, revisada por uma pessoa, vira um novo caso rotulado; toda mudança de prompt, modelo, ferramenta ou base de conhecimento roda o conjunto antes de ser liberada; e, de tempos em tempos, casos obsoletos são revisados ou removidos.

O conjunto também precisa conversar com os indicadores do negócio. Ele mede se o agente se comporta bem em situações conhecidas, mas não substitui o acompanhamento de resolução, tempo de atendimento e satisfação em produção, tema de indicadores de atendimento com IA. Os dois olhares se complementam: o dataset avisa antes de publicar, os indicadores confirmam depois.

No método que usamos, isso se encaixa em quatro movimentos. Mapear: entender o processo atual e registrar a linha de base com conversas reais. Limitar: decidir quais dados entram no conjunto e quais ações o agente nunca executa sozinho. Pilotar: rodar um fluxo real com logs e uma métrica de sucesso combinada, usando o conjunto como porta de entrada para cada mudança. Transferir: entregar o conjunto, a ficha de rótulo e o ritual de atualização para a equipe, que então decide se amplia, ajusta ou interrompe. O dataset é parte do que se entrega, não um material de bastidor.

Perguntas frequentes

Quantas conversas preciso para começar? Comece com o suficiente para cobrir cada categoria de caso do fluxo escolhido, de modo que você consiga ler e discutir cada uma com a equipe. Um conjunto pequeno e bem rotulado vale mais do que um grande e confuso. Amplie à medida que surgirem falhas novas.

Posso usar as conversas dos clientes para testar o agente sem pedir nada a eles? Depende da finalidade informada, da base legal que você adota e do nível de anonimização aplicado. Trate o material como dado pessoal até que o responsável por privacidade valide o processo, e deixe o aviso de privacidade coerente com esse uso. Em caso de dúvida, consulte a orientação da ANPD e o seu jurídico.

Preciso de uma ferramenta específica de avaliação? Não para começar. Uma planilha ou um arquivo estruturado com as fichas de rótulo e um script que rode o agente sobre cada caso já resolvem o primeiro ciclo. Ferramentas de avaliação ajudam depois, quando o volume de casos e de execuções justificar a automação.

O conjunto de testes garante que o agente não vai errar em produção? Não. Ele reduz a chance de regressões conhecidas e dá evidência para decidir, mas o cliente sempre trará situações novas. Por isso o conjunto deve ser combinado com logs, revisão humana de amostras e regras claras de encaminhamento para uma pessoa.

Fontes

• Anthropic: Demystifying evals for AI agents
• OpenAI: Evals guide
• ANPD: Autoridade Nacional de Proteção de Dados