Uma resposta convincente não basta para validar um agente que altera dados. É preciso conferir qual ação ele executou, sobre qual registro e com qual autorização. A simulação ajuda a exercitar essas combinações antes de expor o sistema a usuários reais, mas seus resultados dependem dos cenários escolhidos.

O que a apresentação propõe

Na apresentação de Zhou Yu publicada pela InfoQ, usuários sintéticos combinam perfil, objetivo e contexto para interagir com o agente em avaliação. A proposta liga a avaliação às regras e ao estado da tarefa, em vez de depender apenas de uma nota dada por outro modelo. Yu também distingue cobertura, realismo e custo da simulação, recomenda avaliação por especialistas e descreve a atualização dos cenários com evidências de uso real. É uma abordagem apresentada pela pesquisadora, não um experimento executado neste site.

Um cenário verificável: trocar uma reserva

Considere este exemplo hipotético: um assistente permite trocar a reserva de uma sala. A pessoa tem duas reservas, uma às 9h e outra às 14h, e pede apenas “passe minha reserva para amanhã”. A regra proposta para este exemplo é exigir identificação da reserva e confirmação antes da alteração. Não se trata de uma política real de um fornecedor.

O estado inicial deve ser uma fixture conhecida: duas reservas associadas à identidade A, uma reserva pertencente à identidade B e horários disponíveis definidos. As ferramentas devem operar apenas nesse ambiente de teste, sem calendários ou credenciais reais.

  • Pedido ambíguo: esperar uma pergunta para identificar a reserva; nenhuma escrita deve acontecer nesse momento.
  • Destino ocupado: informar o impedimento e manter a reserva original. Sugerir outro horário não autoriza a troca.
  • Confirmação explícita: alterar apenas a reserva escolhida e conservar seu vínculo com A.
  • Reserva de B: negar a operação no serviço, mesmo que o agente tente solicitá-la.
  • Resposta perdida: depois de um timeout simulado, conferir o estado antes de permitir nova escrita; a conversa não deve confirmar uma mudança cuja execução não foi verificada.

Como registrar o resultado

Para cada execução, guardar a versão da fixture, a identidade usada, o diálogo, as chamadas de ferramentas, o estado final e o motivo de aprovação ou falha. O verificador do estado deve ser independente do texto do agente. “Troca concluída” na conversa e reserva inalterada no armazenamento constituem uma falha, não um sucesso parcial silencioso.

Separar falhas do agente das falhas da infraestrutura também importa. Um serviço indisponível pode justificar uma resposta de impossibilidade; não justifica inventar uma confirmação. Repetir cada cenário permite observar variação entre execuções, sem escolher somente a rodada que funcionou.

Antes de comparar duas versões, fixar o conjunto de casos e o teto de custo. Relatar sucessos, falhas, execuções inconclusivas e quantidade de tentativas. Se novos casos forem descobertos durante a avaliação, adicioná-los a uma próxima rodada identificada, sem alterar retroativamente o denominador da anterior.

O que esse roteiro não demonstra

O exemplo acima é uma proposta de avaliação, não um teste realizado. Ele cobre uma operação e não comprova segurança, desempenho ou representatividade de todos os usuários. Um simulador que conhece a resposta esperada pode produzir conversas fáceis demais; por isso, convém manter casos independentes de quem configurou a simulação.

Para outra questão, a escolha entre execução por agente e testes determinísticos de interface, veja a análise do experimento de testes E2E do Slack.