Cada agente precisa de um juiz.

Um modelo de linguagem é ótimo a parecer que tem razão. É esse o problema. Uma resposta com o valor de reembolso errado soa tão segura como uma com o valor certo. E quem passa os olhos por uma fila de rascunhos não a apanha sempre.

Por isso não pedimos às pessoas que a apanhem. No sistema de marketplace que construímos, 90 agentes trabalham em oito departamentos, e cada equipa tem um juiz: 9 juízes ao todo. Um juiz é um segundo modelo com uma única tarefa: verificar a resposta de outro agente antes de alguém confiar nela.

Porquê um segundo modelo

Pedir ao mesmo modelo que reveja o próprio trabalho ajuda menos do que pensas. Tende a concordar consigo mesmo. E tem os mesmos pontos cegos que causaram o erro.

Por isso os nossos juízes correm numa família de modelos diferente da dos agentes que verificam. Treino diferente, hábitos diferentes, erros diferentes. Se dois modelos sem relação entre si concordam que uma resposta assenta nos dados e cumpre as políticas, isso vale muito mais do que um modelo a concordar duas vezes consigo próprio.

Um juiz também lê a resposta com outros olhos. O agente estava a tentar ajudar. O juiz só procura o que está errado. Uma tarefa estreita e mais nada para fazer: é isso que o torna útil.

Bloquear ou avaliar depois

Há duas formas de pôr um juiz no caminho. Escolher entre elas é a principal decisão de desenho.

No caminho que bloqueia, uma resposta chumbada não é deitada fora. Volta ao agente uma vez, com os motivos do juiz, e o agente tem uma hipótese de a corrigir. Se a versão corrigida voltar a falhar, sai assinalada com as reservas do juiz. Ou, quando as regras o exigem, vai para uma pessoa. Nada sai sem veredicto.

No caminho que avalia depois, a resposta sai e o juiz dá-lhe nota a seguir. As notas mostram onde um agente se desvia e alimentam as lições que o sistema aprende durante a noite. Essas lições não se aplicam sozinhas: uma pessoa aprova cada uma antes de os agentes a usarem.

O que um juiz verifica

Um juiz com uma instrução vaga (“esta resposta é boa?”) é ruído caro. Os nossos verificam coisas concretas, e cada verificação pode falhar sozinha:

A primeira verificação é a que mais importa. Um valor de reembolso, uma data de entrega ou um número de stock que não aparece em nenhum resultado das ferramentas conta como inventado. Por mais plausível que pareça.

Quanto custa, e quando dispensá-lo

Um juiz é mais uma chamada a um modelo em cada resposta. Gasta mais tokens e, no caminho que bloqueia, mais uns segundos. Numa resposta a um cliente, é um seguro barato. Noutros trabalhos, é desperdício.

Dispensamos o juiz, ou passamo-lo para avaliação posterior, quando o resultado tem pouco em jogo, se pode desfazer e é fácil de verificar. Uma sugestão de etiqueta interna que uma pessoa vê de qualquer maneira não precisa de um segundo modelo à frente. Um rascunho que alguém edita sempre antes de enviar também não.

Também nunca pedimos a um modelo que verifique o que o código consegue verificar. Um preço acima do mínimo, uma data no futuro, uma encomenda que existe: são perguntas determinísticas. Têm respostas determinísticas, mais rápidas e sem opiniões.

Um juiz serve para julgar. Se uma regra cabe em código, escreve-a em código.

Falhar à vista, não em silêncio

Os juízes também falham. Excedem o tempo limite, ou o fornecedor do modelo vai abaixo durante uns minutos. O pior que um sistema pode fazer nesse momento é fingir que a verificação aconteceu.

Quando um juiz não consegue correr, a resposta aparece com uma marca visível de “não validada”. Quem a lê decide se confia nela. Uma aprovação silenciosa parece inofensiva. É assim que um sistema perde a confiança de quem trabalha com ele. E essa confiança custa muito mais a recuperar do que um tempo limite custa a corrigir.