Leonardo Peron5 min de leitura
Alguns meses depois de subir, aparece a pergunta na reunião: o agente está funcionando? A resposta costuma ser "está indo bem" ou "teve umas reclamações" — impressões. E impressão sobre um sistema que processa milhares de casos por mês é a lembrança de dois ou três casos marcantes.
O problema começou antes, na demonstração: alguém testou um punhado de casos, o resultado pareceu bom, e "parece bom" virou a única evidência que o projeto tem.
Parece bom é uma amostra enviesada
Quem testa escolhe os casos que consegue lembrar, e os que se lembra são os típicos: o documento limpo, o pedido comum, a pergunta direta. Os difíceis são raros — é por isso que são difíceis — e ninguém tem um à mão na hora de demonstrar.
Há um segundo viés. Quem testa já sabe a resposta certa antes de ler a saída, e isso muda o julgamento: resposta ambígua parece correta quando você já sabe o que ela deveria dizer. É a diferença entre conferir e reconhecer.
Medir corrige as duas distorções, e a maior parte disso precisa existir antes de entrar em produção.
O conjunto de casos com resposta conhecida
Antes de ligar, monte uma base de avaliação: um conjunto de casos reais, cada um com a resposta correta escrita ao lado. Três detalhes decidem se ela vai servir para alguma coisa.
Os casos saem da operação, não da imaginação. Caso inventado tem a forma que quem inventou esperava, e é a forma inesperada que derruba o agente em produção.
Os difíceis entram de propósito. O documento escaneado torto, o pedido com itens cancelados no meio, a mensagem que mistura dois assuntos, o caso em que a resposta certa é dizer que não dá para saber. Base só com caso fácil dá nota alta e nenhuma informação.
A resposta certa é escrita antes de ver a saída do modelo, e por quem faz o trabalho hoje — não por quem está implementando. Definir o gabarito depois é ajustar o critério ao resultado, e acontece sem nenhuma má-fé: o texto do modelo é convincente.
O valor da base não está na nota de uma rodada. Está na diferença entre rodadas. Alguém ajusta a instrução para resolver uma reclamação, roda de novo e descobre que quebrou outra coisa. Sem a base, esse ajuste é fé — e vale igual para troca de modelo, que costuma acontecer sem ninguém do seu lado decidir.
Os três números depois que sobe
Taxa de intervenção humana. A proporção de casos que precisou de pessoa. É a medida do ganho: automação que empurra quase tudo para a fila não economizou nada, apenas acrescentou uma etapa antes da mesma pessoa.
Cuidado com a leitura fácil: essa taxa também cai quando a fila humana desiste de olhar. Se ela melhorar sem que nada tenha mudado no sistema, procure a explicação no time antes de comemorar.
Retrabalho. Casos concluídos que voltaram: o cliente reclamou, alguém reabriu, o financeiro estornou. É o número mais difícil de obter e o mais honesto, porque mede o que o processo sentiu, não o que o sistema achou de si mesmo.
Para existir, precisa haver como ligar o caso que voltou ao original. Se a reabertura vira um chamado novo sem referência, o número não existe — e ninguém percebe que não existe, porque a tela continua mostrando uma fila saudável.
Tempo até a conclusão. Do momento em que o caso entra até estar resolvido, contando a espera na fila humana — não o tempo de resposta do modelo, que é rápido e irrelevante para quem espera. Um agente que responde em segundos dentro de um processo que fecha em três dias não mudou a experiência de ninguém.
Por que acerto sozinho engana
Contar a proporção de respostas certas trata todos os erros como iguais, e eles não são. Dois agentes com o mesmo acerto podem ter valor oposto se um erra nos casos baratos e o outro nos caros. A média apaga a informação que decide.
Há também um problema de origem. Acerto medido sobre o que passou pela revisão humana é acerto medido sobre a parte que o próprio agente já achava duvidosa — a amostra menos representativa possível. O que precisa ser conferido é uma amostra do que ele resolveu sozinho, e isso não acontece por acaso: alguém precisa ter a tarefa no nome. O desenho dessa conferência é assunto de outro texto.
A linha de base que quase ninguém mede
Falta uma medida, e é a que decide se o projeto foi bom: como o processo estava antes. Quanto tempo o caso levava, quantos voltavam, quantos ficavam parados. Medir isso depois de automatizar é impossível, porque o antes já não existe — e sem ele qualquer discussão de resultado vira opinião contra opinião.
Vale medir também a taxa de erro humana no mesmo trabalho. Comparar a IA com uma pessoa idealizada que nunca erra é a comparação que mata projeto viável. A pergunta nunca foi se o agente é perfeito; é se o processo com ele fica melhor que sem ele.
O exercício
Separe hoje, antes de qualquer ajuste, trinta casos do mês passado com a resposta que a operação deu. Salve num arquivo que não muda mais. Rode o agente contra eles e anote quantos bateram e onde divergiram.
Da próxima vez que alguém disser que melhorou o prompt, rode de novo e compare com o que você anotou. Se não der para dizer o que melhorou e o que piorou, o ajuste não foi um ajuste — foi uma aposta.