A Resposta Curta
O teste de agentes não é um teste de software clássico. Não há uma única resposta correta; a mesma pergunta pode ser formulada de vinte maneiras diferentes, e a falha geralmente não é um erro, mas sim uma resposta razoável que omite uma condição essencial. Portanto, é necessário um método diferente: um conjunto representativo de casos, critérios de aceitação em vez de respostas exatas, e medição em diversas dimensões separadamente.
A separação entre as dimensões é o que torna o teste útil. “A resposta não é boa” não é um achado; “o tópico foi corretamente identificado, mas a fonte relevante não foi recuperada” é um achado que pode ser corrigido.
As Quatro Dimensões de Avaliação
| Dimensão | O que é Avaliado | Como é Medido | Quem Corrige |
|---|---|---|---|
| Identificação do Tópico | Se o agente compreendeu o assunto | Comparação com o tópico esperado | Quem escreve instruções e descrições de Actions |
| Recuperação | Se a fonte correta foi recuperada | Se a seção esperada apareceu na recuperação | Proprietário do conteúdo e da tag |
| Resposta | Se o conteúdo está correto e completo | Critérios de aceitação: obrigatório, proibido, citação | Conteúdo e instruções |
| Processo | Se a Action correta foi executada e a escalada foi mantida | Verificação da sequência de Actions e decisão de parada | Actions e regras de escalada |
Construindo um Conjunto de Testes Representativo
A fonte de material são interações reais, e não cenários criados em reuniões. Transcrições, e-mails e descrições de Case contêm o que falta em cenários inventados: erros de digitação, formulações incompletas, duas perguntas em uma única frase e informações ausentes.
Composição recomendada: cerca de metade de casos comuns, aproximadamente um quarto de casos extremos — exceções, condições de elegibilidade limítrofes, perguntas de múltiplas partes — e cerca de um quarto de casos que devem falhar intencionalmente: solicitações fora do escopo, tentativas de extrair informações não autorizadas e clientes que solicitam um agente humano.
Para cada caso, quatro campos são definidos: a solicitação conforme formulada, o tópico esperado, o critério de aceitação para a resposta e o comportamento processual esperado — incluindo “deve escalar” como um resultado correto e não como uma falha.
Critério de Aceitação em Vez de Resposta Exata
Este é o princípio que permite qualquer teste. Em vez de escrever a resposta correta, escreva três listas curtas: fatos que devem aparecer, afirmações que não devem aparecer e a fonte que deve ser citada.
O exemplo típico: uma pergunta sobre elegibilidade para reembolso. É obrigatório que o período de tempo e as condições de estado do produto apareçam; é proibido que um compromisso de crédito apareça; a fonte deve ser a política de reembolso em sua versão válida. Duas formulações completamente diferentes podem ser aceitas.
Esta é também a forma que permite uma avaliação automatizada confiável — a verificação da presença de um fato definido é muito mais precisa do que pedir a um modelo para avaliar a “qualidade”.
Automação vs. Julgamento Humano
Scorers automatizados são adequados para identificação de tópicos, presença de citação válida, conformidade com formato, comprimento e identificação de declarações proibidas. Eles são executados em todo o conjunto em cada versão, com baixo custo.
O julgamento humano é necessário para a precisão do conteúdo em áreas sensíveis e para a formulação com o cliente. Não é necessário testar todo o conjunto — uma amostra fixa de vinte a trinta casos em cada versão, selecionada para incluir os casos extremos.
O perigo de depender totalmente de um avaliador automático é a tendência para respostas que soam autoritárias. Uma resposta convincente que omite uma condição de elegibilidade passará automaticamente e será detectada por um avaliador humano.
Como os resultados dos testes se conectam ao monitoramento de produção é explicado em Observabilidade para Agentforce.
Cenários de Borda para Incluir Sempre
Uma pergunta com dois tópicos em uma frase. Uma solicitação com informações essenciais ausentes — o agente faz uma pergunta de esclarecimento ou adivinha. Um cliente que formula em tom negativo — a escalada é acionada. Uma solicitação de ação não permitida para o usuário. Uma pergunta sobre um produto que não existe — o agente admite ou inventa. Conteúdo que contém uma instrução disfarçada que tenta alterar o comportamento.
Esses seis cobrem a maioria das falhas que vimos em produção, e são de baixo custo para serem executados repetidamente.
Os cenários de bypass se conectam aos testes de segurança detalhados em Segurança do Agentforce e Responsabilidade Compartilhada.
Limites para Lançamento
O limite não é um número uniforme, mas derivado do canal e do risco. Um agente interno de suporte ao representante pode operar com um nível de precisão mais baixo, pois o representante filtra. Um agente que interage com clientes requer um limite significativamente maior, e principalmente zero falhas nas categorias críticas.
A regra mais importante do que o número: zero falhas nas categorias obrigatórias. Exposição de informações não autorizadas, ação irreversível sem aprovação, falha na escalada em uma solicitação explícita por um humano — cada um desses bloqueia o lançamento, independentemente da pontuação geral.
Cenário: Conjunto Pequeno que Evitou um Mau Lançamento
Uma empresa de turismo planejava lançar um agente de clientes após um piloto interno apresentar bom desempenho. O conjunto de testes construído incluiu 90 casos, dos quais 22 eram casos extremos de interações reais.
A execução revelou um padrão: em perguntas sobre alteração de datas com condições especiais de cancelamento, o agente fornecia uma resposta geralmente correta, mas omitia as taxas de alteração em um terço dos casos. Nos testes internos, isso não foi detectado – os representantes sabiam como adicionar as informações por conta própria.
O lançamento foi adiado por três semanas. A correção foi no conteúdo: as condições de cobrança foram movidas para uma seção separada e destacada em cada artigo relevante, e um critério de aceitação explícito foi adicionado. A reexecução foi bem-sucedida, e o lançamento ocorreu sem incidentes.
Riscos e Ações Preventivas
| Risco | Como é Detectado | Ação Preventiva |
|---|---|---|
| Conjunto de testes inventado | Tudo passa no teste e falha em produção | Casos de interações reais |
| Avaliação apenas por pontuação geral | Não se sabe o que corrigir | Medição separada para as quatro dimensões |
| Dependência de avaliador automático | Respostas convincentes com omissões são aceitas | Amostra humana fixa para cada versão |
| Sem casos que devem falhar | O agente responde ao que não deveria | Um quarto do conjunto: fora do escopo e bypass |
| Sem regressão | Uma pequena correção quebra outro cenário | Execução do conjunto antes de cada atualização de versão |
Métricas de Teste
| Métrica | Definição | Limiar de Princípio |
|---|---|---|
| Topic accuracy | Porcentagem de identificação correta do tópico | Alta; falha aqui quebra todo o resto |
| Retrieval hit rate | Porcentagem de casos em que a fonte esperada foi recuperada | Alto em canais de cliente |
| Answer acceptance | Porcentagem de respostas que atenderam aos critérios de aceitação | Derivado do canal e do risco |
| Process compliance | Porcentagem de casos em que a ação ou escalada correta foi realizada | Zero desvios para categorias obrigatórias |
| Regression delta | Mudança nas pontuações em relação à versão anterior | Sem declínio inexplicável |
Quando necessário suporte para a construção de um conjunto de testes e a definição de limites de lançamento, o Serviço Agentforce e IA é o caminho prático a seguir.
Checklist para Testes
- ☐ O conjunto de testes foi construído a partir de interações reais
- ☐ A composição inclui casos comuns, extremos e que devem falhar
- ☐ Para cada caso, um critério de aceitação: obrigatório, proibido, fonte
- ☐ A medição é dividida em tópico, recuperação, resposta e processo
- ☐ Scorers automáticos são executados em todo o conjunto
- ☐ Uma amostra humana fixa é revisada em cada versão
- ☐ Cenários de bypass e instruções disfarçadas foram incluídos
- ☐ Categorias obrigatórias com tolerância zero foram definidas
- ☐ O conjunto é executado como regressão antes de cada atualização de versão
- ☐ Os resultados dos testes são documentados e comparados com a versão anterior