🤖 AI

Agentic Synthesis against Counterexample-Supplemented Sketches

Este artigo introduz o "Agentic Synthesis against Counterexample-Supplemented Sketches", um método nativo de repositório no qual correções de política aprovadas por humanos são integradas em um esboço de código em evolução, em vez de exemplos acumulados, demonstrando que esta abordagem reduz o esforço do desenvolvedor e melhora a transferência de regras aprendidas para casos não vistos em comparação com a regeneração tradicional baseada em replay.

Autores originais: Muness Castle, Eric Rubeck

Publicado 2026-07-20

📖 8 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Muness Castle, Eric Rubeck

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mundo onde você tem um assistente robô superinteligente que pode escrever código de computador para você. É como ter um aprendiz gênio que consegue digitar mais rápido do que qualquer pessoa e conhece um milhão de truques de programação. Mas aqui está o detalhe: este robô é um pouco "agradador de pessoas". Se você disser "Conserte este botão quebrado", ele consertará o botão com prazer. Mas se o botão estava quebrado porque uma regra secreta que você nunca lhe contou (como "nunca deixe o botão ficar vermelho às terças-feiras"), o robô pode consertar o botão enquanto acidentalmente quebra essa regra secreta. Se você não pegar o erro, o robô pode cometer exatamente o mesmo erro na próxima vez, porque ele apenas lembra da correção específica, não do motivo por trás dela. Este é o problema dos "agentes de codificação" no mundo real: eles são ótimos para remendar buracos, mas terríveis em aprender as leis profundas e não escritas de como um sistema deve se comportar, a menos que alguém os ensine explicitamente.

Este artigo, escrito por Muness Castle e Eric Rubeck, aborda exatamente esse problema. Ele introduz uma nova forma de trabalhar chamada "Síntese Agêntica contra Esboços Suplementados por Contraexemplos". Pense nisso como um campo de treinamento rigoroso para codificadores de IA. Em vez de apenas deixar a IA adivinhar e testar, este método força um humano a agir como um treinador rigoroso. Quando a IA comete um erro que quebra uma regra oculta, o humano não diz apenas "conserte isso". Eles dizem: "Aqui está o erro, aqui está a resposta correta e aqui está a regra que você quebrou". A IA então tem que reescrever seu próprio "manual de instruções" (chamado de esboço ou sketch) para incluir essa nova regra antes de ser permitida a tentar novamente. O artigo testa essa ideia com um aplicativo de navegador fictício chamado "CatSynth" e descobre que este método ajuda a IA a aprender as regras melhor do que apenas mostrar a ela uma lista de erros passados, embora os autores tenham o cuidado de dizer que isso se baseia em um experimento específico, e não em uma solução mágica para todas as situações.

A História do Esboço e do Livro de Regras

Imagine que você está tentando construir um robô que escolhe o gato perfeito para uma família. Você dá ao robô um "Esboço" (Sketch). Nesta história, um Esboço não é um desenho; é um manual de instruções incompleto e rascunhado. Ele diz coisas como: "O gato deve ser peludo" e "O gato deve ser amigável". Mas está faltando a parte mais importante: "O gato não pode ser um Persa porque a família tem alergia a gatos".

No início, o robô (o agente de codificação) olha para o Esboço e diz: "Ok, Persas são peludos e amigáveis! Vou escolher um Persa!". Ele escreve o código para fazer isso. Mas então, um especialista humano (o Especialista no Assunto) olha o resultado e diz: "Opa, pare! Isso é um desastre. A família tem alergia. Você escolheu o gato errado".

No modo antigo de fazer as coisas, o humano poderia apenas dizer: "Ok, conserte isso, escolha um gato diferente". O robô então escolheria um gato diferente, talvez um Siamês. Mas o robô não aprenderia de fato a regra sobre alergias. Ele apenas lembraria de "Não escolher Persas para esta família específica". Na próxima vez, se a família mudasse de ideia sobre a alergia, mas o robô não soubesse, ou se uma nova família com alergia surgisse, o robô poderia cometer o mesmo erro novamente.

Este artigo propõe um ciclo diferente e mais rigoroso. Quando o especialista humano diz "Gato errado!", eles não corrigem apenas a saída. Eles agem como um juiz em um tribunal. Eles dizem:

O Erro: "Você escolheu um Persa."
A Correção: "O gato correto é um Siberiano."
A Regra: "A regra que você quebrou é: 'Regras rígidas (como alergias) devem sempre vencer preferências suaves (como pelagem)'."

Então, um "Operador" humano (o chefe) tem que aprovar isso explicitamente. Eles dizem: "Sim, esta é uma regra real agora". Uma vez assinada, o robô deve reescrever seu Esboço para incluir essa nova regra. O robô não pode apenas remendar o código; ele tem que atualizar o manual.

A Verificação de Dois Passos: O Replay e o Comparar

Para garantir que o robô realmente aprendeu a lição, o artigo usa um teste inteligente de dois passos, como um segurança verificando um visitante no portão.

O Replay (O check "Você consertou a bagunça?"): Isso verifica se a nova resposta do robô realmente resolve o problema imediato. O robô escolheu um gato que é peludo e amigável? Se sim, o "Replay" passa.
O Compare (O check "Você seguiu as regras?"): Esta é a parte difícil. Verifica se o robô escolheu o gato certo com base na nova regra. Ele escolheu o Siberiano em vez do Persa? Ele se lembrou da alergia? Se o robo escolheu um Persa peludo que resolvia o problema da "pelagem", mas quebrava a regra da "alergia", o "Compare" falha.

O artigo chama isso de "Portão" (Gate). Se o robô passar em ambos, ele avança. Se ele falhar no Compare, significa que o robô consertou o problema superficial, mas ignorou a regra profunda. O robô tem que voltar e consertar seu Esboço novamente.

O Experimento CatSynth

Os autores testaram isso com um projeto fictício chamado CatSynth. Eles criaram um cenário onde um robô tinha que escolher um gato com base em uma lista de preferências (grande, peludo, afetuoso) e uma regra rígida (não gatos que desencadeiam alergias).

Eles rodaram uma simulação onde o robô tentou resolver 14 diferentes casos "congelados" (cenários que foram definidos antes do experimento começar).

O Resultado: Em 8 de 14 casos, o palpite inicial do robô estava errado porque ele perdeu uma regra. Esses 8 casos tornaram-se "contraexemplos".
O Processo: Para cada um desses 8 erros, um humano aprovou a correção, o robô atualizou seu Esboço e o robô tentou novamente.
O Teste: Depois que o robô terminou de aprender, os autores o testaram em 21 novos casos ocultos (casos que ele nunca tinha visto antes).

Aqui está o que eles descobriram:

Quando reconstruíram o código do robô do zero usando apenas o Esboço evoluído final (aquele que foi atualizado com todas as regras), o robô acertou 19 de 21 dos novos casos.
Quando tentaram reconstruir o robô mostrando a ele o Esboço original mais uma longa lista de todos os exemplos passados (o método "replay-all"), o robô acertou apenas 15 de 21.

Isso sugere que fazer o robô aprender as regras e escrevê-las em seu Esboço foi mais eficaz do que apenas mostrar a ele um histórico de erros. O robô que aprendeu as regras generalizou melhor para novas situações.

O Que Isso Significa (e o Que Não Significa)

O artigo é muito cuidadoso para não exagerar os resultados. Eles não afirmam que este é o "método perfeito" para consertar todos os problemas de codificação de IA para sempre. Eles admitem que isto foi uma simulação com um modelo específico (GPT-5.4-mini) e uma ordem específica de problemas. Eles não sabem se funcionaria exatamente da mesma forma com um robô diferente ou um conjunto diferente de regras.

No entanto, o experimento mostra algo importante: É melhor ensinar a uma IA o "Porquê" (a regra) do que apenas o "O quê" (o exemplo).

Se você apenas mostrar a uma IA uma lista de "Não faça X", ela pode memorizar a lista, mas perder o padrão. Mas se você forçar a IA a atualizar seu próprio manual de instruções (o Esboço) toda vez que ela quebrar uma regra, e depois testá-la jogando fora seu código antigo e reconstruindo-o a partir desse manual, você obtém uma IA mais inteligente e confiável.

Os autores também apontam que este método exige muito esforço humano. Você precisa de um especialista humano para detectar o erro, um operador humano para aprovar a nova regra e um humano para curar a lista de testes. Não é um sistema de "configurar e esquecer"; é uma parceria onde o humano é o professor e a IA é o aluno que tem que tomar notas e reescrever seu próprio livro didático.

A Conclusão

No fim, este artigo é um guia sobre como impedir que a IA seja uma corretora "plausível, mas errada". Eles argumentam que, quando uma IA comete um erro, não devemos apenas remendar o código. Devemos tratar o erro como uma lição que muda a compreensão fundamental da IA sobre o mundo. Ao usar um "Esboço" para conter as regras, um "Portão" para verificar o trabalho e um humano para aprovar as lições, podemos construir uma IA que não apenas adivinha a resposta certa, mas entende de fato por que ela está certa.

Os autores concluem que, embora este método não tenha resolvido todos os problemas em sua simulação (o robô ainda errou 2 de 21 casos ocultos), ele provou que o "Esboço evoluído" carregava o conhecimento melhor do que um simples histórico de exemplos. É um passo para tornar a codificação por IA mais parecida com um aprendizado disciplinado e menos com um palpite de sorte.

Resumo Técnico: Síntese Agêntica contra Esboços Suplementados por Contraexemplos

Definição do Problema

Agentes de codificação podem gerar patches plausíveis que satisfazem sinais imediatos (ex: testes falhando, deltas de estado ou instruções de prompt) enquanto violam regras de domínio subjacentes que ainda não foram codificadas no repositório. Quando um Especialista no Assunto (SME) rejeita um reparo devido a uma violação de política, essa regra frequentemente permanece na memória humana ou nos históricos de chat, em vez de no código-fonte. Consequentemente, execuções subsequentes do agente podem repetir o mesmo "erro plausível". O problema central é que os loops de reparo padrão carecem de um mecanismo para converter um único reparo rejeitado em uma política governante durável e nativa do repositório que previna a recorrência desse modo específico de falha.

Metodologia: O Loop Sketch-CE

O artigo propõe a Síntese Agêntica contra Esboços Suplementados por Contraexemplos (Sketch-CE), um fluxo de trabalho nativo de repositório projetado para evoluir uma política governante (o "esboço") através da aprovação explícita de contraexemplos por um operador. O método baseia-se em seis artefatos específicos e uma separação estrita de funções.

Artefatos Principais

Esboço ( $S$ ): Um artefato revisável e editável pelo agente contendo prosa, estruturas de código e regras de política. Ele define o espaço de estratégia, a ordem de prioridade e as lacunas a serem preenchidas. Crucialmente, o esboço evolui; cada contraexemplo aceito deve revisar o esboço para codificar a nova regra.
Arquivo de Contraexemplos Aceitos ( $A$ ): A proveniência completa de falhas aprovadas. Cada registro inclui a entrada, a saída corrigida autoritativa, a saída errada "tentadora", a regra distintiva e a aprovação do operador.
Conjunto de Regressão ( $R \subseteq A$ ): Um subconjunto curado de casos executáveis selecionados para rejeitar implementações erradas conhecidas e proteger fronteiras específicas de política.
Âncoras de Código Conhecido ( $K$ ): Formas existentes do repositório (APIs, convenções, fixtures) que o agente deve preservar para evitar a invenção de convenções locais paralelas.
Superfície de Implementação: O código versionado (Oráculo A) ou o texto do prompt (Oráculo B) que aplica as regras do esboço. Estes são substituíveis; uma implementação nova deve ser regenerável a partir do esboço evoluído e das âncoras sem reexecutar todo o arquivo.
Portão ( $G$ ): Um pacote de validação executável com duas camadas distintas:
- Replay: Verifica se a saída candidata repara a lacuna de estado codificada (ex: a matemática funciona?).
- Comparação Semântica: Verifica se a saída corresponde à expectativa aprovada nos campos que carregam a política (ex: a operação correta foi selecionada?).

Papéis e Fluxo de Trabalho

O loop envolve atores distintos para evitar a autojustificação:

SME (Especialista no Assunto): Julga saídas concretas e fornece correções com explicações.
Operador: Aprova explicitamente contraexemplos que contradizem o esboço atual. Essa aprovação concede ao caso "autoridade de especificação" e exige uma revisão do esboço.
Mantenedor: Curadoria do conjunto de regressão e manutenção da maquinaria.
Agente de Codificação: Repara superfícies de implementação (código ou prompts) sob as restrições do esboço atual, âncoras e a falha ativa única.

A Sequência do Loop:

Um caso observado falha na implementação atual.
Se a falha contradiz o esboço, o SME fornece uma correção.
O Operador aprova explicitamente o contraexemplo.
O Desenvolvedor (agente) revisa o esboço para codificar a nova regra e repara a superfície de implementação para aquela falha específica.
O Portão executa o caso ativo e o conjunto de regressão ( $R$ ).
Se o portão passar, o caso é curado para $R$ (se ainda não estiver coberto), e o próximo caso é revelado. Se falhar, o agente repara a regressão específica.
Regeneração Limpa Periódica: Para verificar se o esboço carrega a política aprendida, a implementação é descartada e regenerada apenas a partir do esboço evoluído e das âncoras. Se isso falhar, o esboço não sintetizou a política suficientemente.

Contribuições Principais

Artefato Nativo de Repositório: A introdução do "esboço suplementado por contraexemplos" como um artefato central que vincula decisões do operador, registros de arquivo e cláusulas de política revisadas.
Modelo de Processo: Um fluxo de trabalho que transforma correções aprovadas pelo operador em um esboço evoluído, um arquivo completo e um conjunto de regressão curado, separando o modelo governante do histórico de implementação.
Implementação de Duplo Oráculo: Uma abordagem híbrida usando código determinístico (Oráculo A) para regras codificáveis e conclusão mediada por prompt (Oráculo B) para políticas narrativas ou sub-codificadas, ambos restritos pelo mesmo esboço e portão.
Teorema de Regressão Finita: Uma formalização da condição "Passagem de Portão" (Gate Pass), provando que um portão que passa garante a correção de $R$ (satisfação de reparo de estado e campos de política) para o conjunto de regressão específico, limitado pelos verificadores atuais e linhas aprovadas.
Validação Empírica (CatSynth): Um experimento de aplicação de navegador sintética demonstrando a mecânica do método e comparando-o com condições de controle.

Resultados Experimentais (CatSynth)

Os autores avaliaram o método usando o CatSynth, uma aplicação sintética envolvendo seleção de pets com regras de política rígidas (ex: alergias) e preferências suaves. O experimento usou GPT-5.4-mini como Desenvolvedor.

Configuração: Uma execução de mundo aberto onde o agente descobriu regras via contraexemplos, comparado a dois controles:
- Replay-All: Reconstruir a partir do esboço inicial e dar replay em todos os exemplos aceitos como contexto.
- Evolved-Sketch Rebuild: Reconstruir a partir do esboço evoluído e âncoras apenas (regeneração limpa).
Descobertas:
- Retenção de Política: O "Evolved-Sketch Rebuild" passou em 19 de 21 casos retidos, superando o "Replay-All" que passou em 15 de 21. Isso sugere que o esboço evoluído sintetizou a política aprendida melhor do que o modelo redescobrindo regras a partir de exemplos brutos.
- Eficiência: Manter o código entre contraexemplos (Sketch-CE) exigiu 9 chamadas de Desenvolvedor e 719 linhas de churn de artefato, comparado a 15 chamadas e 2.394 linhas para a abordagem Replay-All.
- Densidade de Contraexemplos: Na execução de mundo aberto, 8 de 14 casos candidatos congelados tornaram-se contraexemplos. Todos os três caminhos (Sketch-CE, Replay-All, Evolved-Sketch) passaram os 8 casos aceitos.
- Uso de Tokens: A abordagem Sketch-CE consumiu mais tokens durante a fase de aceitação visível (1.021.822) em comparação aos controles, em grande parte devido ao custo de avaliar candidatos externos e propor regras gerais, em vez de gerá-las.

Alegações e Significância

O artigo faz alegações modestas e delimitadas sobre sua significância:

Inspecionabilidade: A principal contribuição é um fluxo de trabalho inspecionável onde cada contraexemplo aceito conecta uma decisão do operador, um registro de arquivo e uma cláusula de esboço revisada. Isso evita que "reparos errados plausíveis" desapareçam no histórico de chat.
Política vs. Implementação: O método demonstra que um esboço nativo do repositório pode carregar a "política aprendida" de tal forma que uma nova implementação pode ser regenerada sem reexibir todo o histórico de exemplos.
Redução de Retrabalho: No caso específico do CatSynth, manter o código entre contraexemplos reduziu o churn de implementação e as chamadas de desenvolvedor em comparação com o replay de todos os exemplos.
Corretude Limitada: Os autores afirmam explicitamente que um portão que passa não prova corretude geral ou superioridade. A alegação é limitada ao conjunto de regressão atual, aos predicados de replay/comparação codificados e às linhas esperadas aprovadas. Os resultados não estabelecem superioridade ou corretude geral do modelo além das verificações codificadas.
Limitações: O artigo reconhece que a evidência é limitada a um modelo, uma ordem de revelação e dados sintéticos. Não pretende resolver o problema da verificação formal ou substituir o julgamento humano na definição de políticas.

Em resumo, o artigo argumenta que para reparos pesados em termos de política, o repositório deve tratar o esboço como o modelo governante durável e o arquivo de contraexemplos como a fonte de evolução da política, em vez de depender apenas do acúmulo de histórico de prompts ou casos de teste.