Como testar um assistente de IA antes do lançamento: monte um conjunto de teste com os seus próprios casos, defina notas de corte e decida quem aprova

Um assistente de IA pode responder a perguntas com base nos seus documentos, redigir respostas para clientes ou extrair dados de formulários. Uma demo mostra que ele consegue, mas não com que frequência ele erra nos seus próprios casos, nem de que forma. Para isso, você precisa de um teste montado com casos reais do passado. O seu pessoal escreve a resposta certa para cada um, e você combina com antecedência quantos erros de cada tipo aceita. Depois, uma pessoa designada do seu lado aprova os resultados.

Por que uma boa demo de IA não é um teste?

Uma demo mostra perguntas escolhidas pelo vendedor, cada uma respondida uma única vez. Os seus clientes e funcionários vão fazer outras perguntas, com as próprias palavras, e a mesma pergunta pode receber uma resposta diferente na segunda tentativa.

O guia da OpenAI sobre boas práticas de avaliação começa justamente por esse ponto: “A IA generativa é variável. Os modelos às vezes produzem saídas diferentes a partir da mesma entrada, o que torna os métodos tradicionais de teste de software insuficientes para arquiteturas de IA.” Todas as fontes deste artigo foram consultadas em 4 de novembro de 2026.

O guia chama de evals, abreviação de evaluations (avaliações), os testes das respostas de um modelo. Um dos erros que ele lista é a avaliação por impressão (vibe-based eval): “Usar ‘parece que está funcionando’ como estratégia de avaliação, ou esperar até o lançamento para implementar qualquer eval.”

O NIST, o Instituto Nacional de Padrões e Tecnologia dos EUA, publicou em julho de 2024 um Generative AI Profile (perfil de IA generativa), uma orientação de adesão voluntária. O perfil abrevia IA generativa como GAI. Uma das ações sugeridas por ele diz: “Evite extrapolar o desempenho ou as capacidades de sistemas de GAI a partir de avaliações restritas, não sistemáticas e anedóticas.”

Um conjunto de teste faz o que uma demo não consegue: é uma lista de casos reais, cada um com a resposta que você espera, pontuados da mesma forma depois de cada mudança.

De onde devem vir os casos de teste?

Do seu próprio trabalho, mais ou menos na mesma proporção que o assistente vai enfrentar. O guia da Anthropic sobre como definir critérios de sucesso e criar avaliações para os modelos Claude diz: “Projete evals que reflitam a distribuição das suas tarefas no mundo real.”

O guia da OpenAI acrescenta: “Garanta que os seus dados de teste incluam casos típicos, casos atípicos e casos adversariais.” Casos atípicos são entradas raras ou difíceis de tratar. Casos adversariais tentam fazer o assistente se comportar mal. Tire os casos destas fontes:

• Perguntas e tickets antigos de um ano inteiro e de todas as categorias, para que os casos sazonais apareçam
• Documentos de todos os tipos que o assistente vai ler, incluindo digitalizações e layouts incomuns
• Casos complicados, como uma pergunta que mistura dois assuntos ou um formulário com um campo faltando
• Perguntas que os seus documentos não respondem, em que o resultado certo é dizer isso e passar o caso para uma pessoa
• Casos de tolerância zero, como um pedido de dados de outro cliente ou um reembolso que a sua política proíbe
• Tentativas de enganar o assistente, como instruções escondidas em um ticket ou em um arquivo enviado

Não existe um tamanho padrão para um conjunto de teste. Um começo prático são algumas dezenas de casos por tipo de pergunta, já que, com apenas dez casos, uma única falha muda a nota desse tipo em dez pontos percentuais. Escreva cada caso de tolerância zero com várias formulações, porque um modelo pode recusar uma formulação e aceitar outra.

O conjunto contém dados reais de clientes, então aplique a ele as mesmas regras de acesso dos tickets e documentos de onde ele saiu.

Quem escreve as respostas esperadas, e o que entra nelas?

Quem escreve as respostas esperadas são os seus próprios especialistas, não a empresa que está construindo o assistente. Uma resposta esperada, que os engenheiros chamam de ground truth, é a resposta que um funcionário cuidadoso aceitaria. O formato dela depende da tarefa:

• Respostas com base em documentos: os fatos que a resposta precisa conter, o documento e a seção de onde eles vêm, e o que ela não pode dizer. Uma resposta-modelo completa ajuda menos, já que uma resposta correta pode ser redigida de muitas formas
• Rascunhos de resposta: um checklist curto, como os fatos certos, a política seguida e nenhuma promessa fora da política
• Dados extraídos de documentos: o valor correto de cada campo, do jeito que o seu sistema o armazena

O exemplo da OpenAI para perguntas sobre documentos monta os dados de teste, em parte, com “respostas corretas pré-definidas para perguntas criadas por especialistas no assunto”. Na sua empresa, esses especialistas são os líderes de suporte e os responsáveis pelas políticas.

Um segundo especialista confere cada resposta. Quando duas pessoas cuidadosas discordam, a política por trás do caso provavelmente não está clara, e um assistente que a ler também vai ter dificuldade. O guia da Anthropic cita esses casos entre os exemplos de casos atípicos: “Casos de teste ambíguos em que até mesmo pessoas teriam dificuldade de chegar a um consenso na avaliação”. O responsável pela política decide, e você corrige o documento junto com o caso de teste.

Em cada caso, registre o tipo de pergunta e a versão do documento em que ele se baseia. Quando uma política mudar, atualize esses casos, ou o conjunto vai reprovar respostas que agora estão corretas.

Como definimos as notas de corte?

A nota de corte é o menor resultado que você aceita antes do lançamento. Defina uma por tipo de pergunta e por tipo de erro, porque uma única nota de corte para o assistente inteiro esconde demais. O guia da Anthropic observa: “A maioria dos casos de uso precisa de uma avaliação multidimensional, segundo vários critérios de sucesso.”

Classifique cada caso que falhou em um único tipo de erro:

• Fato errado: a resposta afirma algo falso. O perfil do NIST chama isso de confabulação: “A produção de conteúdo errôneo ou falso, mas afirmado com confiança (conhecido coloquialmente como ‘alucinações’ ou ‘fabricações’), que pode enganar ou iludir os usuários.”
• Resposta ausente: os documentos tinham a resposta, mas o assistente disse que não sabia ou deixou de fora um fato essencial
• Fonte errada: a resposta cita um documento que não a sustenta, ou uma versão desatualizada dele
• Resposta perigosa: um caso de tolerância zero deu errado
• Forma e tom: os fatos estão certos, mas a resposta é seca demais ou está no formato errado

Esses erros não custam o mesmo. Uma resposta ausente normalmente termina com uma pessoa assumindo o caso. Um fato errado chega ao cliente com cara de certo, e pode ser que ninguém perceba. Por isso, fatos errados recebem uma nota de corte mais rigorosa do que respostas ausentes, e o tom, a mais branda de todas.

Todos os casos de tolerância zero precisam passar. Uma única falha interrompe o lançamento até que você corrija a causa e o conjunto inteiro passe de novo.

Os tipos de pergunta também diferem, já que um deslize sobre o horário de funcionamento custa menos do que um deslize sobre tarifas. Baseie cada nota de corte no que esse erro custa para você e na frequência com que o seu time erra hoje os mesmos casos. Registre as notas de corte por escrito antes da primeira rodada, para que ninguém as ajuste aos resultados.

Quem ou o que avalia as respostas do assistente?

Dados extraídos de documentos podem ser avaliados por código: cada campo corresponde ao valor esperado ou não. Respostas em texto livre e rascunhos exigem julgamento, de pessoas ou de um segundo modelo de linguagem que trabalhe a partir do checklist.

O guia da Anthropic descreve a avaliação feita por pessoas como “A mais flexível e de alta qualidade, mas lenta e cara. Evite se possível.” Já a avaliação feita por um modelo, ele descreve como “Rápida e flexível, escalável e adequada para julgamentos complexos”, e então aconselha: “Primeiro teste para garantir a confiabilidade, depois escale.”

Um modelo usado como avaliador tem vícios conhecidos. O guia da OpenAI inclui “Viés de posição (ordem das respostas), viés de verbosidade (preferência por respostas mais longas)” entre os desafios que aponta. Ou seja, a ordem das respostas pode influenciar o veredito, e uma resposta mais longa pode ganhar só por ser mais longa. As dicas do guia incluem: “Use feedback humano para calibrar a pontuação automatizada.” Na prática, os seus especialistas avaliam uma amostra que o modelo também avalia, e você corrige o checklist onde quer que eles discordem.

Para rascunhos, um teste cego ajuda. Misture os rascunhos do assistente com as respostas da sua equipe aos mesmos tickets e deixe os revisores avaliá-los sem saber qual é qual. O guia da OpenAI cita um “teste randomizado e cego” como um exemplo de avaliação feita por pessoas.

Como cada resposta esperada indica a fonte dela, você também pode verificar a recuperação (retrieval), a etapa de busca que encontra os trechos que o modelo lê. Se a busca nunca encontrou o trecho certo, corrija a busca, não o modelo. O perfil do NIST sugere uma verificação relacionada: “Revise e verifique as fontes e as citações nas saídas de sistemas de GAI durante a medição de riscos antes da implantação e as atividades de monitoramento contínuo.”

Rode cada caso várias vezes e faça as perguntas principais com mais de uma formulação. O guia da Anthropic trata a consistência como um critério à parte: “Se um usuário fizer a mesma pergunta duas vezes, qual é a importância de ele receber respostas semanticamente semelhantes?” Semanticamente semelhantes quer dizer que as respostas dizem a mesma coisa, ainda que com palavras diferentes.

Quando rodamos o conjunto de teste de novo?

Depois de cada mudança, antes que ela chegue aos clientes. Isso vale para uma nova versão do modelo, documentos editados, novas configurações de busca ou um novo prompt, as instruções escritas que o modelo segue. O guia da OpenAI transforma isso em uma etapa própria: “Configure a avaliação contínua (CE) para rodar evals a cada mudança”.

Cada rodada procura regressões, ou seja, casos que passavam antes de uma mudança e falham depois dela. A média pode subir enquanto um tipo de pergunta quebra, então olhe cada tipo separadamente. Uma mudança só entra em produção quando:

• Nenhum caso de tolerância zero falha
• Nenhum tipo de pergunta fica abaixo da sua nota de corte
• Uma pessoa leu cada falha nova e sabe a causa dela

Guarde os resultados de cada rodada, com as versões do modelo, do prompt e dos documentos testados.

Os provedores também aposentam modelos no próprio cronograma. A página de descontinuações da OpenAI prevê um aviso prévio de pelo menos seis meses para os modelos com disponibilidade geral, a menos que questões de segurança ou de compliance exijam um prazo mais curto. Modelos em preview podem ser aposentados com um aviso bem mais curto. A página da Anthropic prevê um aviso prévio de pelo menos 60 dias para os modelos lançados publicamente e alerta: “Requisições a modelos que passaram da data de aposentadoria vão falhar.”

Esse aviso prévio é a sua janela para rodar o conjunto no modelo substituto, corrigir o que falhar e aprovar de novo. Inclua isso no planejamento e no orçamento desde o início.

O que verificamos depois do lançamento?

Toda semana, um especialista avalia com o mesmo checklist uma amostra aleatória de respostas e rascunhos reais, porque o tráfego real traz casos em que ninguém pensou. É uma revisão humana por amostragem, e não de cada resposta.

O AI Risk Management Framework do NIST, uma orientação de adesão voluntária de janeiro de 2023, diz: “Os sistemas de IA devem ser testados antes da sua implantação e regularmente durante a operação.” O NIST diz que uma versão revisada está em preparação.

Dê aos funcionários e aos clientes um jeito fácil de sinalizar uma resposta ruim e transforme cada falha confirmada em um novo caso de teste. Uma das dicas da OpenAI diz: “Registre logs enquanto desenvolve, para poder garimpar neles bons casos de eval.”

Quem aprova o lançamento, e com base em quais evidências?

Quem aprova é o dono do processo: no caso de um assistente de suporte, por exemplo, o responsável pela área de suporte. A área de compliance ou o jurídico aprova os casos de tolerância zero. Quem construiu o assistente apresenta os resultados, mas não aprova o próprio trabalho.

O framework do NIST descreve uma separação parecida para as avaliações: “Especialistas internos que não atuaram como desenvolvedores de linha de frente do sistema e/ou avaliadores independentes participam das avaliações e atualizações regulares.” Em seguida, a parte do framework chamada Manage (gerenciar) começa com uma decisão sobre o sistema de IA: “se o seu desenvolvimento ou a sua implantação deve prosseguir.”

O dossiê de evidências para essa decisão deve mostrar:

• Como o conjunto foi montado, o tamanho dele por tipo de pergunta e quem escreveu as respostas
• As versões testadas: modelo, prompt, documentos e configurações de busca
• Os resultados por tipo de pergunta e por tipo de erro, comparados com notas de corte acordadas com antecedência
• Cada caso de tolerância zero e o seu resultado
• Cada falha, lida e explicada
• Os resultados do seu time nos mesmos casos
• O que o assistente não atende e quem revisa a amostra semanal depois do lançamento

A aprovação pode ser parcial. O assistente pode entrar em produção para os tipos de pergunta que passaram, enquanto os demais vão para uma pessoa até que também passem.

De quem é o conjunto de teste?

A sua empresa deve ser a dona dos casos, das respostas esperadas, dos checklists, dos scripts e do histórico de resultados. Juntos, eles são a sua definição por escrito de uma boa resposta. Com eles, você pode cobrar o mesmo padrão de qualquer modelo ou fornecedor que vier depois.

Guarde-os em um armazenamento que você controla, porque as ferramentas dos fornecedores também são descontinuadas. A página de descontinuações da OpenAI diz que a empresa avisou os desenvolvedores que usam a plataforma Evals dela, em 3 de junho de 2026, que o produto está sendo descontinuado. A página indica 31 de outubro de 2026 como a data em que as evals existentes passam a ser somente leitura, e 30 de novembro de 2026 para o desligamento programado do dashboard e da API.

Defina do seu lado um responsável pelo conjunto, com tempo para acrescentar casos e atualizar as respostas quando as políticas mudarem.

O que devemos perguntar a um fornecedor ou a uma empresa que construiria o assistente?

Quando um fornecedor citar um número de acurácia, pergunte em que ele foi medido. O perfil do NIST sugere: “Avalie as alegações sobre as capacidades de modelos usando métodos validados empiricamente.” Depois, faça estas perguntas a cada fornecedor ou empresa da sua lista:

• Vocês vão testar com os nossos casos, com respostas esperadas escritas pelo nosso pessoal?
• Que parte do conjunto de teste vocês não vão ver antes da rodada final?
• Que notas de corte vocês propõem para cada tipo de pergunta e tipo de erro, e por quê?
• Como vocês avaliam texto livre, e como conferiram o modelo avaliador de vocês em comparação com pessoas?
• Podemos rodar de novo o conjunto inteiro por conta própria depois de cada mudança, sem vocês?
• Quem paga pelo novo teste quando o provedor aposentar o modelo?
• Vamos receber os casos, os checklists, os scripts e o histórico de resultados no fim?

Onde a amBrain se encaixa?

A amBrain publica este blog. Sobre o próprio produto, ela diz: “Nosso produto próprio, o shyash.ai, roda em agentes de IA que pesquisam, escrevem, verificam e medem a partir de uma memória compartilhada dos fatos da empresa. Uma pessoa aprova tudo o que sai.”

Sobre o trabalho para clientes com um modelo de linguagem, a amBrain diz: “Levamos à produção uma integração de LLM dentro do perímetro de FinTech de um cliente: extração e normalização de avisos não estruturados de corretoras e de venues — eventos corporativos, alterações de instrumentos e de margem — em registros estruturados que o sistema de trading consome.”

Este artigo não é um estudo de caso e não descreve nenhum trabalho para clientes além dessa frase, que não diz como o projeto foi testado. Nada aqui afirma que a amBrain construiu os conjuntos de teste, as notas de corte ou as etapas de aprovação descritos acima, nem diz como o shyash.ai é testado. Os exemplos são gerais, não tirados do trabalho da amBrain.

As organizações mencionadas aqui são citadas com base nas páginas que publicaram. O artigo não afirma nenhuma relação entre a amBrain e qualquer uma delas e não traz preços nem prazos da amBrain.

A amBrain constrói software desde 2019. Sobre como trabalha com os clientes, ela diz: “Três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.” A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” Peça a lista desses componentes, nome por nome, antes de assinar.

Este artigo também não é aconselhamento jurídico. Pergunte aos seus advogados como a legislação de privacidade se aplica a conjuntos de teste montados com dados de clientes. Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que a qualquer outra empresa.