Como criar um loop de IA de autocorreção que detecta erros antes que você os veja

Existe um momento específico que separa alguém que usa IA casualmente de alguém que realmente a executa como um sistema.

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

Agora, para a maioria das pessoas, o ciclo se parece com isso. Pedir algo para o Claude. Ler a saída. Notar que algo está errado. Apontar o erro. Obter uma versão corrigida. Ler novamente. Notar outra coisa. Apontar de novo. Você é a camada de verificação, manualmente, toda vez, 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 detectados e tratados. O que resta para você é o julgamento sobre coisas que realmente precisam de um humano, não a revisão de um 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 para testar antes de confiar isso em algo que realmente importa.

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

O primeiro instinto óbvio é simplesmente pedir ao modelo para verificar 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 cria 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 em particular. É um problema estrutural. A mesma passada que gerou uma resposta que soa plausível, mas está errada, não está bem posicionada para perceber que está errada, porque, de dentro, a resposta ainda soa plausível. Perguntar "tem certeza?" produz mais garantias do que um reexame genuíno.

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

As Três Funções Que Todo Loop de Autocorreção Precisa

Todo sistema de autocorreção funcional, independentemente da tarefa específica, se reduz a três funções distintas. Entender essas funções claramente é mais importante do que qualquer prompt específico abaixo, porque, uma vez que você as veja, pode construir um loop para quase qualquer tarefa, preenchendo os detalhes específicos.

O Construtor. Produz a saída real. Escreve o código, elabora o conteúdo, faz a pesquisa, executa a tarefa. Esta função deve receber a maior liberdade criativa e a menor restrição, 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 contra um padrão específico e escrito, não uma vaga noção de qualidade. O código passa nos testes? O rascunho corresponde ao 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 todas as três funções: 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 de engenharia real em um loop de autocorreção não são prompts inteligentes para cada função. É a estrutura do que passa entre elas, e esta é a parte que a maioria das pessoas que constroem seu primeiro loop pula completamente, e depois se pergunta 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 a função receptora não esteja analisando prosa solta e adivinhando o que é importante. Um gatilho definido, para que o Construtor não seja quem decide quando está terminado. E um caminho de falha definido, para que, quando algo não sair limpo, haja um próximo passo especificado, em vez de o sistema quebrar silenciosamente ou fazer um loop infinito.

Na prática, isso significa que o Construtor deve produzir algo estruturado, não apenas texto conversacional. Uma entrega clara mais uma declaração explícita sobre o que não tem certeza. O Juiz então avalia essa saída estruturada contra 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-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 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, declarado explicitamente]
5Suposições feitas: [qualquer coisa que você assumiu sem ser informado]
6
7FORMATO DO VEREDITO DO JUIZ
8Veredito: [APROVADO / REPROVADO / PRECISA REVISÃO]
9Verificado contra: [o padrão específico usado, por exemplo, 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 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 desviar-se 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á direto 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 construção. 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 se lê bem", mas "cada afirmação específica neste rascunho remonta a algo realmente na fonte, e a peça realmente satisfaz todos os requisitos no 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 "esse resumo soa autoritário", mas "cada afirmação pode ser rastreada até uma fonte específica, e as fontes que foram 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 realmente ser detectado.

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

A maneira 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 uma, 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 conta 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 limite rígido nos 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 corresponde a todos os cinco requisitos declarados do briefing, é uma condição de parada, porque pode ser verificada mecanicamente, em vez de julgada subjetivamente a cada vez.

Um limite de custo ou tempo. Um orçamento absoluto que a tarefa não pode exceder, independentemente do estado em que se encontra quando esse limite é atingido. Esta é a barreira de proteção que protege você especificamente do pior cenário, uma tarefa genuinamente insolúvel em loop até que alguém perceba 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 aprovado" ou "suficientemente próximo."

Limite 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 as três funções 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 rascunho em si, mais uma declaração de confiança explícita e uma lista de qualquer coisa sobre a qual não tinha certeza ao escrever, um número específico que não tinha certeza se estava na fonte, uma afirmação que inferiu em vez de encontrada 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 seu próprio aprovado ou reprovado. Cada afirmação factual no rascunho remonta a algo realmente presente na fonte? O rascunho satisfaz cada requisito específico no briefing, extensão, tom, seções necessárias? O argumento central ou gancho está realmente presente e não diluído por conteúdo de preenchimento? O Juiz retorna um veredito estruturado com um aprovado ou reprovado 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 de fatos envia de volta ao Construtor com a afirmaçã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 fazer loop completamente e escala para um humano com o histórico completo do que foi tentado, em vez de continuar a tentar novamente um problema que o sistema já demonstrou que não pode resolver sozinho.

Este é um sistema pequeno. Três funções, 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 que realmente importa, 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 limite de iteração e escala para um humano, ou ele gira indefinidamente, queimando custo em uma tarefa que nunca ia ter sucesso?

O teste do erro confiante. Alimente o Juiz com uma saída que você já sabe que está sutilmente errada, algo que se lê bem, mas contém um erro factual ou lógico específico. O Juiz, com sua referência de verdade fundamental, a 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 é muito superficial.

O teste do ponto cego do mesmo modelo. Se seu Construtor e Juiz são executados 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 as funções, o que derrota o propósito inteiro de separá-las. Considere usar um modelo genuinamente diferente, ou no mínimo um enquadramento de prompt significativamente diferente, para a função do Juiz especificamente.

O teste de custo descontrolado. Calcule o pior caminho possível através do seu sistema, número máximo de revisões, chamadas de modelo mais caras envolvidas, comprimento de conteúdo razoável mais longo, e descubra o que 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 ainda não são rigorosas o suficiente.

Executar esses quatro testes antes de confiar 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 De Outra Forma Bom

Mesmo com a arquitetura correta de três funções, um punhado de erros de implementação específicos aparecem repetidamente em domínios completamente diferentes, e conhecê-los com antecedência economiza o trabalho 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 dizer que a saída parece internamente consistente, nunca se está realmente correta.

Dar a cada função o mesmo modelo com apenas uma diferença de instrução superficial sobreposta. Se o Juiz está executando exatamente o mesmo modelo subjacente que o Construtor, com apenas um prompt diferente dizendo 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 a função do Juiz produz independência real, em vez de independência teatral.

Tratar o Gerente como uma simples passagem 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 a cada vez, porque nada no sistema se lembra de 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 é executado 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 para o seu sistema ainda.

Escrever a condição de parada como uma instrução suave em vez de lógica dura. "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 se convencerá a ignorar sob a pressão certa. Um contador de iteração duro 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 mostra 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 o 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 ao tentar executá-lo, os resultados do teste, a saída do linter, o status da construção, agrupados na transição. Um Construtor que produz código, mas nunca o executa, não está realmente preenchendo a função de Construtor corretamente, porque código sintaticamente plausível que falha em seu próprio conjunto de testes é pior do que nenhum código, pois parece finalizado sem estar finalizado.

O Juiz verifica três coisas específicas e verificáveis. A alteração 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 no caminho? Cada uma dessas obtém seu próprio aprovado ou reprovado explícito no veredito estruturado.

O Gerente roteia com base em qual verificação específica falhou. Um conjunto de testes com falha volta para o Construtor com a saída exata do teste com falha 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 fazer loop, porque isso é uma falha de julgamento sobre o que a tarefa realmente era, não um defeito mecânico que o Construtor pode simplesmente corrigir iterativamente por conta própria.

Observe que o esqueleto subjacente aqui, Construtor produz e submete com evidência, 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. Uma vez que você tenha 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, enfrentando 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 despercebido, 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 escalonamento mais seguro é a expansão sequencial com um limite de confiança genuíno em cada etapa. Obtenha um loop funcionando 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 durante 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 vários loops concorrentes, dê séria consideração a um painel de custos compartilhado entre todos eles, não um rastreamento por loop isoladamente. Um único loop com um orçamento razoável por tarefa parece completamente bom isoladamente. Dez loops, cada um individualmente dentro do orçamento, ainda podem somar um total genuinamente alarmante que ninguém percebe até que a conta agregada chegue, precisamente porque o rastreamento de cada loop individual parecia bom por si só.

O único hábito que previne problemas de escalonamento 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 limite máximo de iteração e escala para um humano está fazendo exatamente o que deveria fazer, mas se um loop específico está atingindo esse limite constantemente enquanto outros raramente o fazem, isso é um sinal de que o padrão do Juiz para aquela tarefa específica está mal calibrado, muito rigoroso para realmente passar, ou verificando contra a verdade fundamental completamente errada. Esse padrão é invisível se você está apenas rastreando os sucessos e tratando cada escalonamento como um evento isolado e não notável, 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 na 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 funções 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 a 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 algo que realmente importa, não depois que algo já deu errado na frente de alguém. Adicione a condição de parada como lógica real e dura 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, executando sem supervisão, detectando erros reais, parando limpo quando deve, 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 esperança.

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

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