Como criar um loop de IA autorrevisável que detecta erros antes que você os veja

Há um momento específico que separa alguém que usa IA casualmente de alguém que realmente a opera como um sistema.

É o momento em que essa pessoa deixa de ser a que detecta o erro.

Hoje, para a maioria das pessoas, o ciclo se parece com isto: pedir algo para o Claude. Ler a resposta. Notar que algo está errado. Apontar o erro. Receber uma versão corrigida. Ler de novo. Notar outra coisa. Apontar novamente. Você é a camada de verificação, manualmente, todas as vezes, para cada tarefa.

Um loop de autocorreção remove você completamente dessa posição. O sistema gera, verifica seu próprio trabalho contra um padrão real, detecta o que errou, corrige e só então mostra o resultado. Quando você vê a saída, os erros óbvios já foram identificados e tratados. O que resta para você é o julgamento sobre o que realmente precisa de um humano, não a revisão do primeiro rascunho de uma máquina.

Esta é a construção completa. Ao final, você terá a arquitetura exata, os prompts exatos e os modos de falha exatos a testar antes de confiar isso em algo realmente importante.

Por Que Isso Não É O Mesmo Que Apenas Perguntar Duas Vezes

O primeiro instinto óbvio é simplesmente pedir ao modelo que verifique seu próprio trabalho na mesma conversa: "Revise o que você acabou de escrever e corrija quaisquer erros." Isso ajuda um pouco. Mas não constrói um verdadeiro loop de autocorreção, e entender o porquê é a base de tudo o que vem a seguir.

Um modelo revisando sua própria saída no mesmo contexto, com o mesmo raciocínio que produziu o erro em primeiro lugar, tende a defender seu próprio trabalho em vez de examiná-lo genuinamente. Isso não é uma falha específica de nenhum modelo. É um problema estrutural. A mesma passagem que gerou uma resposta plausível, mas errada, não está bem posicionada para perceber que está errada, porque, por dentro, a resposta ainda soa plausível. Perguntar "tem certeza?" produz mais reafirmação do que um reexame genuíno.

A solução não é perguntar melhor. É arquitetura. Um loop de autocorreção real separa o trabalho de produzir uma resposta do trabalho de julgá-la, usando uma passagem diferente, um prompt diferente e, idealmente, um quadro de referência completamente diferente, para que o julgamento não seja contaminado pelos mesmos pontos cegos que criaram o erro.

Os Três Papéis Que Todo Loop de Autocorreção Precisa

Todo sistema de autocorreção funcional, independentemente da tarefa específica, se reduz a três papéis distintos. Entender esses papéis claramente é mais importante do que qualquer prompt específico abaixo, porque, uma vez que você os compreende, pode construir um loop para quase qualquer tarefa, preenchendo os detalhes.

O Construtor. Produz a saída real. Escreve o código, elabora o conteúdo, faz a pesquisa, executa a tarefa. Esse papel deve receber a maior liberdade criativa e o menor número de restrições, porque seu trabalho é produzir uma primeira tentativa, não uma perfeita.

O Juiz. Não constrói nada. Sua única função é avaliar a saída do Construtor com base em um padrão escrito específico, não em uma vaga sensação de qualidade. O código passa nos testes? O rascunho está de acordo com o briefing? A pesquisa realmente responde à pergunta feita? O Juiz deve, idealmente, ter acesso a algo que o Construtor não tem: o material de origem original, o conjunto de testes, o documento de requisitos real, para que tenha uma verdade fundamental independente para verificar, em vez de apenas reler a mesma saída e formar uma nova opinião.

O Gerente. Lê o veredito do Juiz e decide o que acontece a seguir. Enviar de volta ao Construtor com feedback específico. Escalar para um humano. Marcar a tarefa como concluída. É aqui também que reside sua condição de parada, a regra que impede o loop de rodar para sempre quando algo não pode ser corrigido automaticamente.

O princípio de design crítico em todos os três papéis: a verificação precisa referenciar algo fora do raciocínio do próprio Construtor. Um conjunto de testes. Um documento de origem original. Uma lista de verificação escrita. Uma segunda chamada de IA com um enquadramento genuinamente diferente. Qualquer coisa que não seja simplesmente "o mesmo modelo, perguntado novamente, na mesma conversa."

Construindo as Transições

O trabalho real de engenharia em um loop de autocorreção não são prompts engenhosos para cada papel. É a estrutura do que passa entre eles, e esta é a parte que a maioria das pessoas que constroem seu primeiro loop ignora completamente, para depois se perguntar por que o sistema se comporta de forma imprevisível.

Uma transição precisa de três propriedades para funcionar de forma confiável. Um formato definido, para que o papel receptor não precise interpretar prosa solta e adivinhar o que é importante. Um gatilho definido, para que o Construtor não seja quem decide quando terminou. E um caminho de falha definido, para que, quando algo não correr bem, haja um próximo passo especificado, em vez de o sistema quebrar silenciosamente ou entrar em loop infinito.

Na prática, isso significa que o Construtor deve gerar algo estruturado, não apenas texto conversacional. Uma entrega clara mais uma declaração explícita do que não tem certeza. O Juiz então avalia essa saída estruturada com base em um padrão escrito e retorna seu próprio veredito estruturado, não um parágrafo de prosa cheia de ressalvas, mas um claro "aprovado", "reprovado" ou "precisa de revisão", com o motivo específico anexado. O Gerente lê esse veredito estruturado, não o conteúdo bruto, e decide a próxima ação com base em regras estabelecidas antecipadamente, não improvisando um julgamento no momento.

Aqui está um modelo de estrutura que funciona na maioria das tarefas, seja o trabalho subjacente de escrita, código ou pesquisa:

1FORMATO DA SAÍDA DO CONSTRUTOR
2Entrega: [a saída real]
3Confiança: [alta / média / baixa]
4Incertezas conhecidas: [qualquer coisa sobre a qual você não tem certeza, declarada explicitamente]
5Suposições feitas: [qualquer coisa que você assumiu sem lhe ser dito]
6
7FORMATO DO VEREDITO DO JUIZ
8Veredito: [APROVADO / REPROVADO / PRECISA DE REVISÃO]
9Verificado contra: [o padrão específico usado, ex. o briefing original,
10o conjunto de testes, o documento de origem]
11Problemas específicos encontrados: [problemas exatos, não uma impressão geral]
12Confiança neste veredito: [alta / média / baixa]
13
14AÇÃO DO GERENTE
15Se APROVADO: marcar como concluído, entregar ao usuário.
16Se REPROVADO ou PRECISA DE REVISÃO: enviar de volta ao Construtor com os
17problemas específicos do Juiz anexados. Incrementar o contador de revisões.
18Se o contador de revisões exceder [N]: parar o loop, escalar para humano
19com o histórico completo do que foi tentado e por que falhou.

Isso parece mais estrutura do que uma conversa casual de ida e volta, e é. Esse custo inicial é o que lhe garante um sistema que se comporta da mesma forma na centésima execução como na primeira, em vez de derivar imprevisivelmente à medida que o contexto se acumula.

O Juiz Precisa de Verdade Fundamental, Não Apenas de Uma Opinião

Este é o princípio mais importante em todo o sistema, e merece sua própria seção porque errar isso mina silenciosamente todo o resto.

Um Juiz que vê apenas a saída do Construtor, sem nenhuma referência independente para verificar, só pode avaliar a consistência interna, se a saída parece coerente e bem formatada. Ele não pode avaliar a correção, se a saída realmente corresponde ao que foi solicitado ou se realmente resolve o problema real. Uma resposta confiantemente errada, bem formatada e internamente consistente, passará despercebida por um Juiz sem verdade fundamental todas as vezes.

Para tarefas de codificação, a verdade fundamental é o conjunto de testes, a saída real da execução do código, os resultados do linter, o status da build. Não "esse código parece correto?", mas "ele realmente passou quando foi executado?".

Para tarefas de conteúdo, a verdade fundamental é o material de origem original e o briefing original, lado a lado com o rascunho. Não "isso está bem escrito?", mas "cada alegação específica neste rascunho pode ser rastreada até algo realmente na fonte, e o texto realmente satisfaz todos os requisitos do briefing?".

Para tarefas de pesquisa, a verdade fundamental são os resultados de pesquisa reais e os documentos de origem nos quais a pesquisa deveria se basear. Não "este resumo parece autoritário?", mas "cada alegação pode ser rastreada até uma fonte específica, e as fontes pesquisadas eram realmente as relevantes?".

Se você não consegue articular qual é a verdade fundamental do Juiz para sua tarefa específica, você ainda não tem um loop de autocorreção. Você tem um loop de reformulação, onde o erro confiante do Construtor é confiantemente reformulado pelo Juiz em vez de ser realmente detectado.

A Condição de Parada Não É Opcional

A forma mais comum de um loop de autocorreção se tornar uma bagunça cara e fora de controle é a ausência de uma condição de parada explícita e rígida. Sem ela, um Construtor e um Juiz podem ciclar indefinidamente, cada revisão desencadeando outra avaliação, cada avaliação desencadeando outra revisão, enquanto o custo aumenta e ninguém percebe até a fatura chegar.

Uma condição de parada real precisa de três componentes, e todos os três devem ser aplicados como lógica explícita, não deixados ao julgamento do modelo no momento.

Um número máximo de iterações. Um teto rígido para ciclos de revisão, após o qual o Gerente é forçado a escalar para um humano, independentemente de o Juiz estar satisfeito ou não.

Um limite de qualidade que seja realmente mensurável, não aspiracional. "Bom o suficiente" como uma instrução dentro de um prompt não é uma condição de parada, porque é uma sugestão que o modelo pode e eventualmente ignorará sob a pressão certa. Uma barra específica e verificável, todos os onze casos de teste passam, ou o rascunho atende a todos os cinco requisitos do briefing, é uma condição de parada, porque pode ser verificada mecanicamente em vez de julgada subjetivamente cada vez.

Um teto de custo ou tempo. Um orçamento absoluto que a tarefa não pode exceder, independentemente do estado em que se encontra quando esse teto é atingido. Esta é a salvaguarda que o protege especificamente do pior cenário, uma tarefa genuinamente insolúvel em loop até que alguém note a fatura.

CONDIÇÕES DE PARADA

Revisões máximas: 3. No 3º veredito reprovado, parar e escalar

para um humano com o histórico completo de revisões anexado, não

tentar um 4º ciclo automaticamente.

Limite de qualidade: todos os itens na lista de verificação do Juiz devem mostrar APROVADO,

não "quase aprovando" ou "suficientemente próximo."

Teto de orçamento: se esta tarefa consumiu mais de [X] tokens ou

[Y] minutos, parar imediatamente, independentemente do estado atual, e relatar

o que foi concluído versus o que resta.

Escreva estas condições na lógica real do Gerente, não em uma instrução suave dentro de um prompt mais longo que o modelo pode se convencer a ignorar sob pressão.

Um Exemplo Prático: Produção de Conteúdo com Autocorreção

Para tornar isso concreto, aqui está exatamente como os três papéis e a condição de parada se unem para uma tarefa real e comum: transformar um documento de origem em uma peça de conteúdo finalizada sem um humano revisando manualmente cada rascunho.

O Construtor recebe o material de origem e o briefing, e produz um rascunho. Sua saída inclui o próprio rascunho, mais uma declaração de confiança explícita e uma lista de qualquer coisa sobre a qual não tinha certeza durante a escrita, um número específico que não tinha total certeza de que estava na fonte, uma alegação que inferiu em vez de encontrar declarada diretamente.

O Juiz recebe o rascunho e a fonte original lado a lado, nunca o rascunho isoladamente. Ele verifica três coisas específicas, cada uma com sua própria aprovação ou reprovação. Cada alegação factual no rascunho remonta a algo realmente presente na fonte? O rascunho satisfaz todos os requisitos específicos do briefing, extensão, tom, seções necessárias? O argumento ou gancho central está realmente presente e não diluído por preenchimento? O Juiz retorna um veredito estruturado com uma aprovação ou reprovação em cada uma das três verificações separadamente, porque colapsar isso em uma única pontuação geral esconde exatamente qual dimensão falhou.

O Gerente lê esse veredito estruturado. Uma aprovação limpa em todos os três envia o rascunho para uma fila de saída final. Uma falha na dimensão de verificação factual envia de volta ao Construtor com a alegação não verificada específica sinalizada diretamente, não uma instrução vaga para "verificar a precisão". Uma falha na conformidade com o briefing envia de volta com o requisito ausente específico nomeado. Após três ciclos falhos na mesma verificação específica, o Gerente para de loopar completamente e escala para um humano com o histórico completo do que foi tentado, em vez de continuar tentando novamente um problema que o sistema já demonstrou não conseguir resolver sozinho.

Este é um sistema pequeno. Três papéis, um formato de transição estruturado, uma condição de parada explícita. É também um sistema que você poderia genuinamente executar sem supervisão e confiar na saída, porque cada modo de falha tem um caminho definido em vez de um indefinido.

Testando o Loop Antes de Confiar Nele

Antes de confiar em qualquer sistema de autocorreção para algo realmente importante, execute-o deliberadamente através destes testes de estresse específicos. A maioria dos loops que falham em uso real teria falhado em um desses testes imediatamente, se alguém tivesse se preocupado em verificar primeiro.

O teste da tarefa insolúvel. Dê deliberadamente ao Construtor uma tarefa que ele não pode completar ao padrão do Juiz, de propósito. O Gerente atinge corretamente o teto de iterações e escala para um humano, ou ele entra em loop indefinidamente, queimando custo em uma tarefa que nunca iria ter sucesso?

O teste do erro confiante. Alimente o Juiz com uma saída que você já sabe que está sutilmente errada, algo que parece bem escrito, mas contém um erro factual ou lógico específico. O Juiz, com sua referência de verdade fundamental, o detecta corretamente? Se o Juiz aprova algo que você sabe que está quebrado, sua referência de verdade fundamental não está sendo realmente verificada, ou a verificação é superficial demais.

O teste do ponto cego do mesmo modelo. Se seu Construtor e Juiz rodam no mesmo modelo subjacente, vale a pena verificar isso diretamente. Alimente o Juiz com uma saída contendo exatamente o tipo de erro que esse modelo caracteristicamente tende a cometer. Se o Juiz a aprova, você construiu um loop que compartilha seus pontos cegos entre os papéis, o que anula todo o propósito de separá-los. Considere usar um modelo genuinamente diferente, ou no mínimo um enquadramento de prompt significativamente diferente, para o papel do Juiz especificamente.

O teste de custo descontrolado. Calcule o pior caminho possível através do seu sistema, revisões máximas, chamadas de modelo mais caras envolvidas, maior comprimento de conteúdo razoável, e calcule quanto isso realmente custa em dólares reais e tempo real. Se esse número o alarmasse aparecendo em uma fatura real, suas condições de parada não são restritas o suficiente ainda.

Executar estes quatro testes antes de confiar em um loop de autocorreção com algo real detecta a grande maioria das falhas que, de outra forma, apareceriam pela primeira vez na frente de um cliente, um chefe ou seu próprio extrato bancário.

Erros Comuns Que Silenciosamente Quebram Um Design, Fora Isso, Bom

Mesmo com a arquitetura correta de três papéis, um punhado de erros de implementação específicos aparecem repetidamente em domínios completamente diferentes, e conhecê-los com antecedência poupa você de redescobrir cada um da maneira mais difícil.

Deixar o Juiz ver apenas a saída do Construtor, sem nenhuma referência independente. Este é o erro mais comum, e silenciosamente transforma seu sistema de uma verificação de correção em uma verificação de coerência. Um Juiz sem nada para comparar só pode lhe dizer que a saída parece internamente consistente, nunca se está realmente correta.

Dar a cada papel o mesmo modelo com apenas uma diferença de instrução fina sobreposta. Se o Juiz está rodando o exato mesmo modelo subjacente que o Construtor, com apenas um prompt diferente dizendo-lhe para "ser crítico", ele muitas vezes herda os mesmos pontos cegos que o Construtor tem, porque é fundamentalmente o mesmo processo de raciocínio usando um chapéu diferente. Onde o orçamento permitir, um modelo genuinamente diferente para o papel do Juiz produz independência real em vez de independência teatral.

Tratar o Gerente como um simples repassador em vez de dar a ele memória real de tentativas anteriores. Um Gerente sem visibilidade do que já foi tentado nesta tarefa específica enviará felizmente o mesmo feedback falho de volta ao Construtor uma segunda e terceira vez, produzindo o mesmo resultado falho idêntico cada vez, porque nada no sistema lembra que essa abordagem exata já falhou uma vez.

Pular os quatro testes de estresse porque o sistema funcionou bem na única execução de demonstração que todos observaram atentamente. Um sistema que se comporta corretamente enquanto você o observa atentamente e um sistema que se comporta corretamente enquanto roda sem supervisão são afirmações diferentes. Apenas a segunda é o ponto real de construir um loop de autocorreção em primeiro lugar. Se você não testou os modos de falha deliberadamente, você não sabe realmente qual afirmação é verdadeira sobre seu sistema ainda.

Escrever a condição de parada como uma instrução suave em vez de lógica rígida. "Pare quando estiver bom o suficiente" dentro de um prompt não é uma condição de parada, é uma sugestão que o modelo pode e eventualmente conseguirá ignorar sob a pressão certa. Um contador de iterações rígido que o Gerente verifica mecanicamente antes de permitir outro ciclo é uma condição de parada. A diferença entre esses dois importa enormemente na primeira vez que uma tarefa se revela genuinamente insolúvel.

Um Segundo Exemplo Prático: Código com Autocorreção

O mesmo esqueleto parece diferente, mas segue a lógica idêntica quando a tarefa é código em vez de conteúdo, e percorrer ambos lado a lado deixa claro quão pouco realmente muda entre os domínios.

O Construtor aqui é um agente de codificação trabalhando em uma tarefa definida: uma correção de bug, um recurso, uma refatoração. Sua saída estruturada não é apenas o diff do código, mas a saída real do comando da tentativa de executá-lo, os resultados dos testes, a saída do linter, o status da build, empacotados na transição. Um Construtor que produz código, mas nunca o executa, não está realmente preenchendo o papel de Construtor corretamente, porque código sintaticamente plausível que falha em seu próprio conjunto de testes é pior do que nenhum código, já que parece finalizado sem estar finalizado.

O Juiz verifica três coisas específicas e verificáveis. A mudança passou no conjunto de testes existente sem que os próprios testes fossem modificados? Já que um Construtor editando silenciosamente um teste para fazê-lo passar é uma falha específica e surpreendentemente comum que vale a pena verificar diretamente. A análise estática e o linting retornaram limpos? O diff realmente aborda a tarefa que foi atribuída, não um problema relacionado, mas diferente, que o Construtor decidiu que era mais interessante resolver ao longo do caminho? Cada uma dessas recebe sua própria aprovação ou reprovação explícita no veredito estruturado.

O Gerente roteia com base em qual verificação específica falhou. Um conjunto de testes falho retorna ao Construtor com a saída exata do teste falho anexada diretamente, não uma instrução genérica para "corrigir os testes". Uma incompatibilidade de escopo, onde o diff resolveu um problema diferente do atribuído, escala imediatamente para um humano em vez de loopar, porque isso é uma falha de julgamento sobre o que a tarefa realmente era, não um defeito mecânico que o Construtor pode simplesmente iterar para resolver sozinho.

Observe que o esqueleto subjacente aqui, Construtor produz e submete com evidências, Juiz verifica contra critérios nomeados específicos com um veredito por verificação, Gerente roteia com base em exatamente qual verificação falhou, é idêntico ao exemplo de produção de conteúdo acima. Esta é a lição real que vale a pena levar adiante ao ver dois domínios diferentes lado a lado. Depois que você tem o esqueleto correto, aplicá-lo a um novo tipo de tarefa é principalmente uma questão de escrever uma nova lista de verificação específica para o Juiz, não redesenhar toda a arquitetura a partir dos primeiros princípios cada vez.

Escalando Para Múltiplos Loops Concorrentes

Uma vez que um único loop de autocorreção é genuinamente confiável, a próxima questão real é como executar vários ao mesmo tempo sem que o sistema se torne ingerenciável, já que é exatamente aqui que a segunda tentativa da maioria das pessoas de escalar isso dá errado.

A tentação é iniciar muitos loops simultaneamente no momento em que o primeiro funciona, atacando cinco tarefas diferentes em paralelo porque a arquitetura tecnicamente suporta isso. Resista a isso por mais tempo do que parece necessário. Cada loop concorrente adicional é outro lugar onde uma condição de parada pode falhar silenciosamente, outro lugar onde o custo pode sair do controle despercebidamente, outro lugar onde a referência de verdade fundamental de um Juiz pode estar sutilmente errada de uma forma que só aparece sob volume real, em vez de em uma única execução de teste.

O caminho de escalabilidade mais seguro é a expansão sequencial com um limite de confiança genuíno em cada etapa. Coloque um loop para funcionar de forma confiável o suficiente para que você tenha parado de verificar sua saída de perto, o que significa que ele passa consistentemente em suas próprias verificações pontuais manuais ao longo de um período real de tempo, não apenas uma única execução de demonstração bem-sucedida. Só então adicione um segundo loop para uma tarefa diferente. Acompanhe a taxa de falha real de cada loop ao longo do tempo, não apenas se ele pareceu funcionar nas execuções que você observou.

Quando você executar múltiplos loops concorrentemente, dê séria consideração a um painel de custo compartilhado em todos eles, não um rastreamento por loop isoladamente. Um único loop com um orçamento razoável por tarefa parece completamente bem isoladamente. Dez loops, cada um individualmente dentro do orçamento, ainda podem somar um total genuinamente alarmante que ninguém notou até a fatura agregada chegar, precisamente porque o rastreamento de cada loop individual parecia bem por si só.

O único hábito que previne problemas de escalabilidade antes que eles comecem: registre cada gatilho de condição de parada em todos os loops, não apenas as conclusões bem-sucedidas. Um loop que atinge seu teto máximo de iterações e escala para um humano está fazendo exatamente o que deveria fazer, mas se um loop específico está atingindo esse teto constantemente enquanto outros raramente o fazem, isso é um sinal de que o padrão do Juiz para aquela tarefa específica está ou mal calibrado, muito rigoroso para realmente passar, ou verificando contra a verdade fundamental errada completamente. Esse padrão é invisível se você está apenas rastreando sucessos e tratando cada escalação como um evento isolado e irrelevante, em vez de um ponto de dados sobre o design daquele loop específico.

Por Onde Começar Esta Semana

Não tente construir um sistema de autocorreção totalmente geral em sua primeira tentativa. Escolha uma tarefa específica, estreita e bem definida que você já faz regularmente, algo com um padrão claro que você poderia escrever se lhe perguntassem, e construa o loop de três papéis em torno dessa única tarefa primeiro.

Escreva a lista de verificação do Juiz explicitamente antes de escrever uma única linha do prompt do Construtor. O padrão contra o qual você está verificando deve moldar o que você pede ao Construtor para produzir, não o contrário. Se você ainda não consegue escrever a lista de verificação, você ainda não sabe o que "correto" significa para esta tarefa bem o suficiente para automatizar sua verificação, e isso vale a pena descobrir antes de construir qualquer coisa.

Execute os quatro testes de estresse acima antes de confiar o loop a qualquer coisa que realmente importe, não depois que algo já deu errado na frente de alguém. Adicione a condição de parada como lógica real e rígida desde a primeira versão, não como uma reflexão tardia depois que você já foi queimado por um loop descontrolado uma vez.

Uma vez que um loop é genuinamente confiável, rodando sem supervisão, detectando erros reais, parando limpo quando deveria, o segundo vai muito mais rápido. Não porque os prompts se transferem diretamente, eles geralmente precisam ser reescritos para a nova tarefa, mas porque você já entende a forma real do problema. Separe a construção do julgamento. Dê ao julgamento algo real para verificar. Escreva a condição de parada como lógica, não como esperança.

Essa forma é toda a disciplina. Todo o resto é apenas aplicá-la à tarefa que estiver à sua frente.

Siga @cyrilXBT para os templates exatos de loop e as configurações de Construtor-Juiz-Gerente por trás de tudo neste artigo.