Resumo Técnico: ExecuGraph – Sistemas Multiagentes Baseados em Execução para Geração Confiável de Código de Backend

Declaração do Problema

Embora os Grandes Modelos de Linguagem (LLMs) tenham se tornado ferramentas padrão para a geração automatizada de código, a confiabilidade continua sendo uma limitação crítica, particularmente para o código de backend que exige invariantes estritas de estrutura de dados e tratamento de casos extremos. As abordagens existentes frequentemente dependem de paradigmas de agente único ou de passagem única, ou de pipelines multiagentes que confundem decomposição de papéis (atribuir tarefas diferentes a agentes diferentes) com feedback de execução (usar resultados de testes em tempo de execução para guiar o refinamento).

A lacuna de pesquisa central identificada é a falta de estudos empíricos controlados que isolem o benefício marginal da decomposição de papéis multiagentes do benefício do feedback de execução. Muitos sistemas anteriores atribuem ganhos de desempenho a arquiteturas de agentes complexas, quando esses ganhos podem ser simplesmente decorrentes da presença de um loop de execução. Além disso, mecanismos de autorrevisão textual (ex: "LLM-como-juiz") são propensos à instabilidade e falsos negativos, muitas vezes bloqueando códigos corretos com base em críticas verbais sensíveis a paráfrases, em vez de resultados de tempo de execução.

Metodologia: O Framework ExecuGraph

Os autores apresentam o ExecuGraph, um framework de fluxo de trabalho projetado explicitamente como um instrumento para desacoplar o feedback de execução da decomposição de papéis multiagentes.

Arquitetura Central

O ExecuGraph é formalizado como um sistema de transição tipado ($W = (S, A, \rho, D, T)$) sobre um objeto de estado compartilhado $S$, orquestrado via LangGraph. Ele apresenta:

1. Estado Compartilhado: Um registro tipado (GraphState) que persiste a declaração do problema, o plano, o código, os artefatos de revisão, os resultados de avaliação e as contagens de tentativas.
2. Camada de Agentes: Seis agentes especializados:
   • Planner (Planejador): Gera a estratégia algorítmica e a análise de complexidade.
   • Code Generator (Gerador de Código): Produz o código Python baseado no plano.
   • Logical Reviewer (Revisor Lógico): Fornece análise estática apenas consultiva (JSON estruturado), mas não bloqueia a aceitação.
   • Evaluator (Avaliador): A única autoridade para aceitação; executa o código em um ambiente sandbox de subprocesso e aplica testes híbridos (testes determinísticos ou testes gerados por LLM).
   • Optimizer (Otimizador): Refatora o código apenas após a execução bem-sucedida.
   • Explainer (Explicador): Gera documentação pós-aceitação.
3. Sandbox de Execução: Um ambiente isolado por subprocesso com políticas de importação estritas (prevenindo violações de sandbox para bibliotecas padrão como bisect ou heapq), limites de recursos e ambientes sanitizados.
4. Predicado de Decisão: A aceitação é determinada exclusivamente pelos resultados da execução (s.evaluation.passed = True), não pela revisão estática ou autoavaliação verbal.

Design Experimental

A principal inovação do framework é sua capacidade de colapsar em diferentes baselines via alternância de configurações dentro do mesmo código-fonte:

• Single-Agent One-Shot (SO): Apenas o gerador, sem tentativas de erro.
• Single-Agent Execution-Retry (SR): Gerador + Avaliador com tentativas (estilo Self-Debug), sem Planner/Revisor.
• Multi-Full (MF): Todos os agentes habilitados com tentativas.
• Ablações: Agentes específicos (Planner, Reviewer, Optimizer) ou a camada de Recuperação (RAG) podem ser desativados para medir a contribuição marginal.

O estudo utiliza três conjuntos de dados:

1. Internal-30: Um conjunto curado de 30 problemas (DP, Grafos, Estruturas de Dados).
2. HumanEval: O benchmark completo de 164 problemas.
3. APPS-Introductory: Um subconjunto de 50 problemas.

Os experimentos foram conduzidos utilizando modelos de pesos abertos (Qwen2.5-Coder-7B e DeepSeek-Coder-V2-Lite-16B) hospedados localmente em uma GPU de consumo (RTX 4050) para garantir a reprodutibilidade a custo zero de API.

Principais Contribuições

1. Isolamento de Mecanismos: O ExecuGraph fornece a primeira comparação controlada separando o feedback de execução da decomposição multiagente. Ao colapsar o framework nas condições SO, SR e MF, os autores demonstram que o ganho "multiagente" é frequentemente um confundimento do feedback de execução.
2. Revisor Apenas Consultivo: O framework desacopla explicitamente o papel de "crítico" da autoridade de "aceitação". O Revisor Lógico é apenas consultivo, prevenindo o risco de "falso-negativo", onde um juiz LLM confiante, porém incorreto, bloqueia um código válido.
3. Estudo Diagnóstico Empírico: O artigo apresenta um diagnóstico rigoroso mostrando que o feedback de execução impulsiona a grande maioria dos ganhos de desempenho, enquanto adicionar agentes multiagentes frequentemente gera retornos insignificantes ou negativos em relação ao custo.
4. Reprodutibilidade e Correção de Artefatos: Os autores liberaram todo o código, logs e scripts. Crucialmente, eles identificaram e corrigiram um defeito de política de importação no sandbox em seu harness original que havia rejeado falsamente programas corretos usando bibliotecas padrão (ex: bisect). Todos os resultados relatados são reavaliados usando o sandbox corrigido sem reinvocar os modelos.
5. Análise de Custo-Correção: Quantificação detalhada das trocas entre precisão, tempo de execução (wall-clock time), uso de tokens e contagens de chamadas de LLM através de diferentes configurações.

Resultados

1. Feedback de Execução vs. Decomposição Multiagente

No benchmark HumanEval (164 problemas), o estudo descobriu:

• Feedback de Execução é Crítico: O modo de agente único com tentativa de erro (SR) superou o de passagem única (SO) em +25,6 pontos percentuais (81,7% vs. 56,1%, $p < 0,0001$).
• Decomposição Multiagente Não Adiciona Valor Mensurável: Adicionar cinco agentes sobre o loop de tentativa (MF) resultou em uma perda de -1,2 pontos percentuais em relação ao SR (80,5% vs. 81,7%, $p = 0,76$).
• Controle de Amostragem: Um controle de amostragem "best-of-5" (cinco tentativas independentes de passagem única filtradas pelo sandbox) com um orçamento de computação similar ao MF ganhou apenas +0,4 pp sobre a passagem única. Isso confirma que os ganhos do SR se devem ao feedback, não meramente ao aumento da diversidade de amostragem.

2. Análise de Custo

• Single-Retry (SR): Alcançou alta precisão (81,7%) com ~1,5 chamadas de LLM e ~13,3s de tempo de execução.
• Multi-Full (MF): Exigiu ~5,3 chamadas de LLM e ~59,8s de tempo de execução (3,6x mais chamadas, 7,3x mais tokens) para uma precisão estatisticamente indistinguível.
• Conclusão: Para modelos na escala de 7B, a configuração de tentativa única (Single-Retry) é o caminho mais econômico.

3. Efeitos de Modelo e Categoria

• DeepSeek-Coder-V2-Lite (16B MoE): A decomposição multiagente mostrou um ganho de +20,0 pp especificamente em problemas de Grafos (90,0% vs. 70,0%), mas causou uma queda de -10,0 pp em Programação Dinâmica e Estruturas de Dados. O resultado líquido foi nenhuma mudança na precisão geral (83,3%). Isso sugere uma redistribuição de capacidade em vez de um ganho de escala universal.
• Efeito Distrator do Planner: Em análise qualitativa, o agente Planner foi encontrado como um potencial "distrator" em modelos de 7B. Se o Planner emitisse uma restrição estrutural falha (ex: inicialização incorreta de caso base), o Gerador seguiria fielmente essa instrução, e as tentativas subsequentes falhariam em corrigir o erro porque o plano falho era preservado no contexto. Remover o Planner em estudos de ablação na verdade melhorou a precisão em 8,0 pp.

4. Recuperação (RAG)

Habilitar a camada de recuperação (alimentando o Planner com trechos algorítmicos) não rendeu nenhum ganho mensurável (78,7% vs. 82,0% de baseline). Os autores atribuem isso à pequena escala do repositório de vetores e ao fato de que modelos de código de 7B já possuem forte conhecimento paramétrico de algoritmos padrão.

Significância e Alegações

O artigo afirma modestamente que o feedback de execução é o principal motor de confiabilidade na síntese de código por LLM, não a decomposição de papéis multiagentes.

• O Resultado "Negativo" é Seguro: A descoberta de que a decomposição multiagente não adiciona valor sobre a tentativa de erro de agente único é a alegação mais robusta do artigo, pois ambas as condições recebem feedback de execução, eliminando o confundimento da visibilidade de testes.
• Implicação Prática: Os autores recomendam o Single-Retry (SR) como a configuração de implantação padrão para geração de código de backend em escalas de 7 bilhões de parâmetros. Ele alcança precisão equivalente ao Multi-Full com aproximadamente 28% das chamadas de modelo e 14% do custo de tokens.
• Valor do Artefato: Os autores reconhecem que o Multi-Full ainda pode ser valioso para gerar artefatos (ex: listas de invariantes, explicações) úteis para governança de software, mas não para melhorar a correção bruta.
• Perigo da Fundamentação em Execução: O artigo destaca uma lição crítica: a avaliação fundamentada em execução é tão confiável quanto sua implementação. Um erro no sandbox (o defeito de política de importação) pode corromper silenciosamente os resultados, convertendo programas corretos em falhas. Os autores defendem controles de solução de referência em qualquer sistema onde o critério de aceitação seja a execução de código.

Em resumo, o ExecuGraph demonstra que, para a geração de código de backend confiável, um simples loop de tentativa de erro de execução é superior à orquestração multiagente complexa em termos de eficiência de custo e precisão, desde que o ambiente de execução (sandbox) esteja corretamente implementado.