Como criar um agente de IA que detecta suas próprias alucinações: o padrão do agente verificador

Principais destaques

• 🪞 Pedir para uma IA “revisar o próprio trabalho” quase nunca funciona: o modelo tende a concordar com sua saída anterior porque está raciocinando com os mesmos pesos, o mesmo contexto e os mesmos vieses que geraram a resposta original.
• 🔍 O padrão do agente verificador resolve isso separando as responsabilidades: um agente “trabalhador” produz a saída, e um agente “verificador” independente, sem acesso ao raciocínio do primeiro, avalia essa saída contra critérios explícitos.
• 🔀 A peça central do sistema é a lógica de roteamento: aprovado segue para a próxima etapa, reprovado volta para revisão com um limite de tentativas, e incerto escala para um humano ou um verificador mais robusto.

Alucinações de IA são um problema bem documentado. Mas quando essas alucinações acabam dentro de um fluxo de trabalho automatizado com vários agentes, gerando relatórios, enviando e-mails, atualizando bancos de dados, elas deixam de ser uma curiosidade e passam a ser um risco real de operação.

A resposta mais comum é pedir ao modelo para “checar o próprio trabalho”. Isso quase nunca ajuda. Um modelo que inventou uma citação não vai flagrar sua própria invenção quando você pedir para ele revisar a mesma saída que acabou de produzir, já que o erro já está incorporado à sua janela de contexto.

O padrão do agente verificador resolve isso de forma diferente: atribui a verificação a um agente separado, rodando de forma independente, sem conhecimento de como a saída original foi produzida.

O resultado é um sistema capaz de genuinamente capturar alucinações, atalhos lógicos e erros factuais antes que eles se espalhem pelas etapas seguintes. Este artigo explica como esse padrão funciona, quando usá-lo e como construir um, com prompts prontos para cada etapa.

🪞 O problema central: por que a autoverificação falha

Quando você pede para um modelo verificar sua própria saída, está pedindo para ele raciocinar contra si mesmo, usando os mesmos pesos, o mesmo contexto e, muitas vezes, os mesmos vieses implícitos que produziram a resposta original.

Pesquisas de equipes de segurança em IA mostram de forma consistente que modelos têm muito mais probabilidade de concordar com suas próprias saídas anteriores do que de sinalizar erros nelas. O modelo não está sendo teimoso, ele simplesmente parte do princípio de que o que disse antes estava correto, uma suposição embutida no próprio contexto da conversa.

Existe também um problema mais sutil. Um modelo que tomou um atalho, digamos, inventando uma estatística que não conseguiu lembrar, muitas vezes não sabe que tomou esse atalho. Da perspectiva do modelo, ele respondeu com confiança.

A autorrevisão não expõe essa lacuna porque a lacuna simplesmente não é visível para o próprio modelo. É por isso que a verificação com múltiplos agentes existe: ela quebra o ciclo de retroalimentação introduzindo um agente que não tem interesse em defender a resposta original.

🧩 O que é, de fato, o padrão do agente verificador

O padrão do agente verificador é um desenho multiagente em que um agente (o “trabalhador”) produz uma saída, e um segundo agente (o “verificador”) avalia essa saída de forma independente, contra critérios específicos.

A palavra-chave é independente. O verificador não deveria receber a cadeia de raciocínio do trabalhador, seu rascunho interno ou etapas intermediárias. Ele recebe a saída e os critérios de avaliação, nada além disso. Isso força o verificador a avaliar o resultado por seus próprios méritos, em vez de herdar a lógica do trabalhador.

O padrão tem três componentes centrais:

• 👷 Agente trabalhador: completa a tarefa principal (pesquisa, resumo, geração de código, extração de dados etc.)
• 🔎 Agente verificador: recebe a saída do trabalhador e a avalia contra critérios definidos
• 🚦 Lógica de roteamento: decide o que acontece a seguir com base no veredito do verificador (aprovado, reprovado ou escalado)

Em uma implementação simples, o verificador apenas aprova a saída ou sinaliza problemas específicos. Em configurações mais sofisticadas, o feedback do verificador volta para o trabalhador para revisão, com um número máximo de tentativas antes de a tarefa ser escalada para um revisor humano.

🎯 Quando usar esse padrão

Nem todo fluxo de trabalho precisa de um agente verificador. Adicionar um introduz latência e chamadas extras ao modelo. A pergunta é se esse custo compensa para o seu caso de uso.

Use o padrão do agente verificador quando:

• ⚡ A saída será usada de forma automática (aciona outro sistema, envia uma mensagem, escreve em um banco de dados, executa uma transação), já que erros podem se propagar rapidamente
• 📊 A precisão factual importa: resumos de pesquisa, conteúdo médico ou jurídico, dados financeiros e documentos de conformidade se beneficiam de verificação independente
• 🧠 O trabalhador lida com raciocínio complexo, já que tarefas em várias etapas têm mais oportunidades de erros que se acumulam
• 📚 A tarefa envolve busca e recuperação de informação (RAG), um cenário em que citações inventadas, atribuições erradas de citação ou mistura incorreta de fontes são comuns
• 📈 O volume é alto, já que em escala, mesmo uma taxa de alucinação de 1% a 2% se torna um problema operacional real

Pule o verificador quando a tarefa é de baixo risco, as saídas já são revisadas por humanos de qualquer forma, ou a latência adicional quebra os requisitos do seu fluxo.

🛠️ Como desenhar um agente verificador eficaz

Um agente verificador mal desenhado é permissivo demais, rígido demais, ou está avaliando as coisas erradas. Acertar o desenho exige pensar com cuidado sobre o que “correto” significa para a sua tarefa específica.

Defina critérios de avaliação de forma explícita. O prompt do agente verificador é a decisão de desenho mais importante que você vai tomar. Critérios vagos produzem veredictos vagos. “Verifique se isso está correto” vai falhar. Em vez disso, dê ao verificador um roteiro concreto.

Para um agente de resumo de pesquisa, isso pode se parecer com:

• Toda afirmação factual do resumo aparece nos documentos de origem?
• Todas as estatísticas estão citadas corretamente (número, unidade, fonte)?
• O resumo evita introduzir afirmações não sustentadas pelas fontes?
• O tom e o tamanho são apropriados para o público-alvo?

Para um agente de extração de dados:

• Todos os campos obrigatórios estão presentes e preenchidos?
• Os valores numéricos seguem a especificação de formato (por exemplo, sem vírgulas em inteiros)?
• As datas estão no formato ISO 8601?
• Existe algum valor nulo onde o documento de origem claramente tinha dado?

Quanto mais específicos os critérios, mais confiável o verificador se torna.

Mantenha o contexto do verificador limpo. O verificador deveria receber a descrição original da tarefa (para entender o que foi pedido), a saída do trabalhador (o que foi produzido), e os critérios de avaliação (o que conta como correto). O verificador não deveria receber a cadeia de raciocínio ou o rascunho interno do trabalhador, as fontes que o trabalhador consultou (a menos que o próprio trabalho do verificador seja checar citações contra elas), ou qualquer enquadramento que sugira que a saída provavelmente está correta. Se você disser ao verificador “aqui está o que nosso agente produziu, revise por favor”, está ancorando-o sutilmente em direção à aprovação. Remova esse enquadramento e apresente a saída de forma neutra.

Use um formato de saída estruturado. Veredictos em texto livre são difíceis de rotear. Force o verificador a devolver uma saída estruturada. Um esquema mínimo seria:

json

{
  "veredito": "aprovado" | "reprovado" | "incerto",
  "problemas": ["lista de problemas específicos, se reprovado ou incerto"],
  "confianca": 0.0 - 1.0
}

Isso torna trivial interpretar o resultado e decidir o próximo passo no seu fluxo de trabalho.

Escolha o modelo certo para a função. Seu verificador não precisa ser o mesmo modelo do seu trabalhador. Em alguns casos, usar um modelo mais forte como verificador faz sentido, já que ele está fazendo uma tarefa de raciocínio mais difícil (criticar) e suas conclusões carregam mais peso. Em fluxos sensíveis a custo, dá para usar um modelo mais barato na checagem inicial e escalar para um modelo mais forte apenas quando o verificador retornar “incerto” ou “reprovado”.

📋 Passo a passo: construindo o fluxo de agente verificador

Passo 1: mapeie os modos de falha do seu trabalhador

Antes de construir qualquer coisa, liste as formas como seu agente trabalhador costuma falhar. Rode-o em 20 a 30 casos de teste, revise manualmente as saídas e categorize os erros. Categorias comuns de falha: fatos alucinados (afirmações não sustentadas pelo contexto disponível), saída incompleta (campos ou seções obrigatórias ausentes), violação de formato (a saída não bate com o esquema ou os requisitos de estilo), erros lógicos (conclusões que não seguem das premissas), e fuga de escopo (o agente respondeu a uma pergunta diferente da que foi feita). Os critérios do seu verificador deveriam mapear diretamente para essas categorias de falha.

Passo 2: escreva o prompt do verificador

Prompt pronto para adaptar como verificador:

Você é um revisor de qualidade avaliando a saída de um agente de IA. Sua
função é identificar problemas específicos e verificáveis no resultado
abaixo, não elogiar ou resumir o que foi feito.

Avalie contra estes critérios:
1. [CRITÉRIO 1, ex: toda afirmação factual aparece nos documentos de origem]
2. [CRITÉRIO 2, ex: estatísticas citadas corretamente, com número, unidade e fonte]
3. [CRITÉRIO 3, ex: nenhuma afirmação além do que as fontes sustentam]

Retorne o veredito neste formato JSON:
{"veredito": "aprovado|reprovado|incerto", "problemas": [...], "confianca": 0.0-1.0}

Não invente problemas que não existem. Não aprove uma saída com problemas
claros. Seja específico.

Tarefa original:
[DESCREVA O QUE FOI PEDIDO AO AGENTE TRABALHADOR]

Saída a ser avaliada:
[COLE A SAÍDA DO AGENTE TRABALHADOR]

A última instrução do prompt importa bastante. Verificadores tendem a ser generosos por padrão, e instruir explicitamente o verificador a ser honesto (não severo, apenas honesto) ajuda a calibrar o comportamento.

Passo 3: construa a lógica de roteamento

Depois que o verificador devolve seu veredito, seu fluxo de trabalho precisa decidir o que acontece a seguir. Uma estrutura comum de três caminhos:

• ✅ Aprovado → envia a saída para a próxima etapa do pipeline
• ❌ Reprovado → devolve a saída e a lista de problemas ao agente trabalhador para revisão (com um contador de tentativas)
• ❓ Incerto → encaminha para um revisor humano ou um verificador secundário com um modelo mais forte

Defina um número máximo de tentativas (geralmente 2 a 3) antes de qualquer tarefa reprovada escalar para revisão humana. Sem esse teto, dá para ficar preso em ciclos de revisão que nunca convergem.

Prompt para o agente trabalhador processar o feedback de reprovação:

Sua saída anterior foi avaliada e reprovada pelos seguintes motivos:

[COLE A LISTA DE PROBLEMAS RETORNADA PELO VERIFICADOR]

Revise sua saída original, corrigindo especificamente cada um desses
pontos. Não reescreva partes que não foram sinalizadas como problema.

Saída original:
[COLE A SAÍDA ORIGINAL]

Tarefa original:
[DESCREVA A TAREFA ORIGINAL]

Passo 4: teste o verificador contra falhas conhecidas

Antes de colocar em produção, rode o verificador contra saídas que você já sabe que estão erradas, usando os casos de falha documentados no passo 1. Se o verificador não perceber erros claros, revise os critérios. Se ele estiver sinalizando coisas que não são de fato problemas, aperte o roteiro. Um verificador permissivo demais não te protege; um verificador rígido demais rejeita saídas válidas e cria ciclos infinitos de revisão. Busque uma taxa de falso positivo abaixo de 10%, e uma taxa de falso negativo o mais próxima de zero que seu caso de uso exigir.

Passo 5: adicione registro e monitoramento

Veredictos do verificador são dados valiosos. Registre cada veredito com o tipo de tarefa, o modelo usado pelo trabalhador, o veredito e os problemas do verificador, se a saída final foi aprovada depois de revisão, e o tempo até a resolução. Com o tempo, esses dados mostram quais tipos de tarefa falham com mais frequência, se determinados modelos produzem mais erros, e se os critérios do seu verificador precisam de atualização.

⚠️ Modos de falha comuns em sistemas de agente verificador

• 🤝 O problema da bajulação: alguns modelos, atuando como verificadores, tendem à concordância, mencionando problemas menores mas ainda assim retornando “aprovado”; contorne isso instruindo explicitamente que aprovar uma saída com falhas é considerado uma falha do próprio verificador
• 🔄 Raciocínio circular entre agentes: se o trabalhador e o verificador compartilham o mesmo modelo base, especialmente com o mesmo prompt de sistema ou contexto, os dois agentes podem acabar cometendo os mesmos erros; use modelos diferentes para trabalhador e verificador sempre que possível
• 🎯 O problema do alvo móvel: tarefas que envolvem julgamento criativo (tom, estilo, persuasão) são mais difíceis de verificar de forma sistemática, já que não existe uma verdade objetiva; para essas tarefas, restrinja o escopo do verificador a coisas avaliáveis objetivamente (contagem de palavras, inclusões obrigatórias, parâmetros de tom), deixando julgamentos subjetivos de qualidade para humanos
• 🛌 Dependência excessiva do verificador: adicionar um verificador não significa que o trabalhador pode ser mais relapso; o modelo mental correto é otimizar o trabalhador primeiro, e só então adicionar o verificador para capturar erros residuais, não para fazer o trabalho principal de qualidade

🚀 Variações avançadas do padrão

• 🧵 Pipelines com múltiplos verificadores: para tarefas de alto risco, use vários verificadores com focos de avaliação diferentes (um checa precisão factual, outro checa conformidade de formato, um terceiro checa consistência lógica), cada um rodando em paralelo e reportando problemas de forma independente
• ⚔️ Agentes verificadores adversariais: em vez de pedir para o verificador avaliar a saída de forma neutra, peça para ele argumentar contra a saída, encontrando todo motivo pelo qual a resposta poderia estar errada; esse enquadramento adversarial revela mais problemas do que uma revisão padrão, ainda que também aumente a taxa de falsos positivos
• 🎚️ Roteamento calibrado por confiança: em vez de um binário aprovado/reprovado, use a pontuação de confiança do verificador para rotear de forma dinâmica; alta confiança com aprovação segue direto; baixa confiança com aprovação vai para uma fila de checagem humana pontual; alta confiança com reprovação volta ao trabalhador; baixa confiança com reprovação escala imediatamente
• 📈 Critérios de verificador autoaperfeiçoáveis: registre todos os veredictos do verificador e as decisões humanas que seguem escalonamentos; revise periodicamente os casos em que o verificador disse “aprovado” mas um humano encontrou problemas, e os casos em que o verificador disse “reprovado” mas o humano aprovou, usando essas discrepâncias para refinar os critérios de avaliação

Pedir para uma IA revisar o próprio trabalho quase nunca funciona, porque o modelo está avaliando sua saída usando o mesmo contexto e os mesmos vieses que a produziram.

O padrão do agente verificador resolve isso introduzindo um segundo agente, genuinamente independente, que avalia a saída do trabalhador contra critérios explícitos, sem acesso ao raciocínio que a gerou.

O desenho eficaz depende de três coisas: critérios de avaliação claros, isolamento limpo de contexto, e formatação estruturada de saída, com uma lógica de roteamento que trata veredictos de aprovação, reprovação e incerteza de formas diferentes, sempre com um limite de tentativas antes de escalar para revisão humana.

Registrar esses veredictos ao longo do tempo transforma o sistema de controle de qualidade em um conjunto de dados que se autoaperfeiçoa, ajudando a refinar tanto o agente trabalhador quanto o verificador.