🤖 AI

Structured Feedback Improves Repair in an LLM Agent Loop

O artigo apresenta o VeriHarness, um loop de agente controlado por código que demonstra que fornecer aos LLMs feedback estruturado contendo o local da falha, valores observados e alternativas admissíveis melhora significativamente as taxas de sucesso de reparo em tarefas iterativas em comparação com diagnósticos brutos ou feedback incompleto.

Autores originais: Jaideep Ray, Ankit Goyal

Publicado 2026-07-17

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Jaideep Ray, Ankit Goyal

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 que você está ensinando um robô muito inteligente, mas um pouco literal, a jogar um videogame. Você dá ao robô um objetivo, como "encontrar o tesouro", e ele tenta se mover pelo mundo. Às vezes, o robô comete um erro — talvez tente abrir uma porta que já está aberta, ou tente pegar um item que não está lá. No mundo da Inteligência Artificial, esse robô é chamado de "agente LLM", e a parte que verifica se o movimento do robô é legal é chamada de "validador".

Por muito tempo, quando o robô errava, o validador apenas dizia: "Não, isso está errado", e deixava o robô tentar novamente. É como um professor dizendo: "Tente de novo", sem dizer ao aluno por que ele errou ou qual seria a resposta certa. O robô apenas tentaria de novo, esperando ter sorte. Mas e se o validador pudesse ser mais útil? E se ele pudesse apontar exatamente o erro, mostrar o que o robô realmente fez e até sugerir uma lista de coisas que o robô poderia ter feito em vez disso? Este artigo faz uma pergunta simples, mas poderosa: dar ao robô um "kit de reparo" detalhado de informações ajuda-o a corrigir seus erros de forma mais rápida e melhor do que apenas receber uma mensagem simples de "tente novamente"?

Os pesquisadores por trás deste estudo construíram um campo de testes especial chamado VeriHarness. Pense nele como uma fase de um videogame onde um árbitro rigoroso (o validador) observa o robô (o modelo de IA) jogar. Se o robô fizer um movimento ruim, o árbitro interrompe o jogo e entrega uma nota ao robô. A equipe queria ver que tipo de nota funciona melhor. Eles testaram quatro tipos diferentes de notas:

A Nota Bruta: Apenas a mensagem de erro, como "O Comando 1 é inválido".
A Nota em Prosa: Um parágrafo amigável explicando onde o erro aconteceu, o que o robô viu e o que ele deveria ter feito.
A Nota Estruturada: As mesmas informações da Nota em Prosa, mas formatada como uma lista técnica com rótulos (como um arquivo JSON).
A Nota de "Apenas Localização": Dizendo ao robô onde ele errou e o que ele viu, mas sem sugerir alternativas.

Eles realizaram este experimento 50 vezes com dois modelos de IA diferentes (um chamado Qwen e outro chamado Llama) jogando jogos de aventura baseados em texto. O objetivo era ver com que frequência o robô conseguia chegar à linha de chegada (vencer o jogo) dentro de um limite de quatro tentativas.

Os resultados foram uma grande surpresa para o grupo da "Nota Bruta". Quando o robô recebia as notas detalhadas que incluíam onde o erro aconteceu, o que ele observou e uma lista de alternativas admissíveis (movimentos válidos que ele poderia fazer em vez disso), ele se tornava um campeão.

Para o modelo Qwen, a taxa de sucesso saltou de 28% (com a mensagem de erro bruta) para 72% (com as notas detalhadas). Isso é um aumento de 44 pontos percentuais.
Para o modelo Llama, saltou de 16% para 58%, um aumento de 42 pontos percentuais.

A parte mais emocionante da descoberta é o porquê disso ter funcionado. Os pesquisadores suspeitaram que talvez o robô apenas gostasse do visual limpo e organizado da "Nota Estruturada" (aquela com os rótulos técnicos). Mas eles testaram isso comparando a "Nota em Prosa" (em inglês simples) com a "Nota Estruturada". O resultado? Elas performaram quase exatamente da mesma forma. O fato de o conselho estar escrito em um parágrafo amigável ou em uma lista técnica não importava muito. O ingrediente mágico não era a formatação; era o conteúdo.

Especificamente, a nota de "Apenas Localização" (que dizia ao robô onde ele falhou, mas não lhe dava novas ideias) não ajudou muito. Ela permaneceu próxima da baixa taxa de sucesso das mensagens de erro brutas. Isso prova que simplesmente apontar o erro não é suficiente; o robô precisa receber uma lista de alternativas válidas para escolher entre elas. É a diferença entre um professor dizer: "Você escreveu 'gato' errado", versus "Você escreveu 'gato' errado; você poderia ter escrito 'rato', 'pato' ou 'mato'".

O estudo também verificou se esse truque funciona para tarefas de programação (usando um conjunto de problemas chamado HumanEval). Eles descobriram que o método só funciona se o validador puder realmente ver o erro. Se o robô passa em um teste visível, mas falha em um teste oculto que o validador não consegue ver, nenhum nível de feedback pode corrigir isso. Isso sugere que, embora o feedback detalhado seja um superpoder, não é mágica — ele só pode corrigir o que consegue ver.

No fim, este artigo sugere que, se quisermos que nossos agentes de IA sejam melhores em corrigir seus próprios erros, não devemos apenas deixá-los adivinhar novamente. Precisamos construir validadores que atuem como treinadores prestativos: apontando o erro específico, mostrando o que realmente aconteceu e oferecendo um menu de opções corretas para tentar a seguir. Acontece que, para a IA, um pouco de conselho específico e acionável vale mais do que mil "tente novamente".

Resumo Técnico: Feedback Estruturado Melhora o Reparo em um Loop de Agente LLM

Declaração do Problema

Embora agentes de Grandes Modelos de Linguagem (LLMs) frequentemente utilizem loops iterativos onde um modelo gera um candidato e um validador externo o rejeita, a interface entre o validador e a chamada subsequente do modelo permanece subespecificada. Os sistemas atuais muitas vezes dependem de "diagnósticos brutos" — mensagens simples de rejeição (ex: "O Comando 1 não é admissível") — que podem carecer do contexto específico necessário para que o modelo gere um reparo bem-sucedido. A questão central é: Qual informação específica um validador determinístico deve retornar para a próxima chamada do modelo para maximizar o sucesso do reparo?

Metodologia

Arquitetura do Sistema: VeriHarness

Os autores introduzem o VeriHarness, um loop de agente controlado por código que separa a geração da aceitação.

Orquestração: Um orquestrador principal gerencia o estado, orçamentos e rastreios fora da janela de contexto do modelo.
Fluxo de Trabalho: O trabalhador LLM gera um candidato estruturado (ex: um plano JSON). Portões externos (validadores) verificam o candidato contra esquemas, artefatos e comportamento do ambiente.
Loop de Feedback: Se um candidato falha, um "codificador de falha" mapeia detalhes específicos do portão para uma interface comum, retornando um payload de reparo ao modelo. O modelo recebe apenas o estado compacto da tarefa e o feedback de reparo atual; ele não pode se autovalidar.

Desenho Experimental

O estudo avalia políticas de feedback através de 50 jogos pareados de TextWorld (3 salas, 4 objetos, missões de 2 etapas) usando dois modelos: Qwen2.5-Coder-14B e Llama-3.1-8B. A restrição primária é um limite de quatro chamadas por jogo.

Os autores comparam quatro políticas de feedback (Tabela 1):

RawDiag: Retorna a string de erro de validação original sem campos de reparo explícitos.
SameNL: Fornece a localização da falha, o valor observado e as alternativas admissíveis em prosa de linguagem natural, sem rótulos tipados.
LocObs: Fornece um rótulo de falha e campos JSON nomeados para localização e valor observado, mas omite as alternativas admissíveis.
TypedFields: Fornece um rótulo de falha, campos JSON nomeados para localização e valor observado, além de um campo contendo a lista de alternativas admissíveis.

Verificações de Robustez

Sensibilidade ao Orçamento: Testado com orçamentos de chamadas de 2, 4, 6 e 8 em um subconjunto de 15 jogos.
Variância de Decodificação: Testado com Qwen usando decodificação amostrada (temperatura 0.3, top-p 0.9) através de três sementes (seeds).
Verificação de Escopo: Um experimento HumanEval onde o validador vê apenas uma asserção pública, garantindo que o mecanismo seja testado apenas quando uma falha é realmente exposta.

Resultados Principais

1. Feedback Estruturado Melhora Significativamente o Sucesso

Sob um limite de quatro chamadas, o feedback contendo localização, valor observado e alternativas admissíveis supera drasticamente os diagnósticos brutos.

Qwen2.5-Coder-14B: A taxa de sucesso aumentou de 28% (RawDiag) para 72% (TypedFields) (+44 pontos percentuais).
Llama-3.1-8B: A taxa de sucesso aumentou de 16% (RawDiag) para 58% (TypedFields) (+42 pontos percentuais).
Significância Estatística: Essas melhorias são estatisticamente significativas (Holm-adjusted $p < 0.001$ ) com intervalos de bootstrap de 95% de [28–60] para Qwen e [28–56] para Llama.

2. A Fonte da Melhoria: Valores de Reparo vs. Formato

Estudos de ablação isolam a causa do ganho de desempenho:

Alternativas Admissíveis são Críticas: A política LocObs (localização + observação, mas sem alternativas) teve desempenho próximo à linha de base RawDiag (36% vs. 28% para Qwen; 18% vs. 16% para Llama). Isso indica que saber apenas onde e o que falhou é insuficiente sem saber o que fazer em vez disso.
O Formato é Secundário: SameNL (prosa) e TypedFields (JSON com chaves) tiveram desempenho quase idêntico.
- Qwen: SameNL (70%) vs. TypedFields (72%).
- Llama: SameNL (58%) vs. TypedFields (58%).
- Testes estatísticos não mostram diferença significativa ( $p=1.0$ ) entre formatos de prosa e JSON quando os valores de reparo são correspondidos. O formato JSON não proporcionou vantagem de raciocínio, embora tenha reduzido ligeiramente o número total de chamadas necessárias.

3. Robustez de Orçamento e Decodificação

Sensibilidade ao Orçamento: A lacuna de desempenho entre o feedback estruturado e os diagnósticos brutos aumenta conforme o orçamento de chamadas aumenta de 2 para 4. O desempenho do RawDiag estabiliza após 4 chamadas, enquanto o feedback estruturado continua a melhorar com chamadas adicionais.
Decodificação: A ordenação dos resultados (TypedFields/SameNL > LocObs > RawDiag) persistiu sob configurações de decodificação amostrada.

4. Limitações Expostas pelo HumanEval

No teste de escopo HumanEval, a primeira resposta passou no teste visível para todas as 15 tarefas, o que significa que o validador nunca retornou uma oportunidade de reparo. Consequentemente, todas as políticas pararam após uma chamada com taxas de sucesso idênticas (14/15). Isso confirma que o feedback estruturado não pode reparar falhas que o validador não detecta ou expõe.

Significância e Alegações

O artigo alega que o principal gargalo no loop de reparo de agentes LLM não é a capacidade de raciocínio do modelo, mas o conteúdo informacional do feedback.

Design de Validador: Os validadores devem retornar informações de reparo específicas — especificamente a localização da falha, o valor observado e uma lista de alternativas admissíveis — em vez de mensagens de rejeição genéricas.
Agnosticismo de Formato: A sintaxe específica (JSON vs. prosa) é menos importante do que a presença dos próprios valores de reparo. Embora o JSON ajude na log e no roteamento, ele não melhora inerentemente as capacidades de raciocínio do modelo neste contexto.
Utilidade Condicional: O mecanismo é eficaz apenas quando o validador consegue expor a falha. Se um validador não consegue enumerar alternativas ou detectar o erro específico, o loop de reparo não pode funcionar.

Os autores concluem que, para o design de agentes, o foco deve mudar da otimização da orquestração de prompts para a engenharia de validadores determinísticos que retornam alternativas enumeradas e acionáveis após uma falha.