Automating Computational Reproducibility in Social Science: Comparing Prompt-Based and Agent-Based Approaches

Resumo Técnico: Automatizando a Reprodutibilidade Computacional em Ciências Sociais

1. O Problema

A reprodutibilidade computacional em pesquisas científicas, especialmente nas ciências sociais, enfrenta barreiras práticas significativas. Embora a teoria sugira que reexecutar código compartilhado em dados compartilhados seja simples, na prática, a maioria das análises publicadas falha ao ser reexecutada. As causas incluem:

• Dependências ausentes ou incompatíveis.
• Caminhos de arquivos (paths) frágeis ou incorretos.
• Incompatibilidades de versão de pacotes.
• Gaps na lógica computacional: Omissões estruturais no código que impedem a execução, mesmo quando o código é tecnicamente "legível".

A falta de reprodutibilidade compromete a verificação de resultados e a utilidade de longo prazo do trabalho científico. Embora modelos de linguagem grandes (LLMs) e agentes de IA tenham sido propostos como soluções para depuração, não há evidências empíricas robustas sobre até que ponto essas ferramentas podem reparar automaticamente análises falhas em cenários realistas de ciências sociais, nem qual abordagem (baseada apenas em prompts vs. agentes autônomos) é mais eficaz.

2. Metodologia

Os autores desenvolveram um benchmark sintético controlado para avaliar duas abordagens de reparo automatizado:

A. Criação do Benchmark Sintético:

• Base: Cinco estudos de ciências sociais baseados em R, totalmente reprodutíveis (ground-truth).
• Injeção de Erros: Foram criados 130 casos de teste sintéticos introduzindo erros realistas baseados em falhas comuns de reprodutibilidade.
• Categorização dos Erros:
  • Categoria A (Erros de Execução): Problemas simples como caminhos de arquivo errados, pacotes faltantes ou erros de sintaxe básicos.
  • Categoria B (Erros Contextuais): Requerem correções mais nuanceadas no nível do código, lógica de análise incorreta ou combinações de erros da Categoria A.
  • Categoria C (Erros Estruturais): Lacunas na lógica analítica, funções ausentes, blocos de código incompletos ou falhas complexas que afetam múltiplos arquivos simultaneamente.
• Ambiente: Todos os testes foram executados em contêineres Docker isolados para garantir consistência.

B. Abordagens de Reparo Avaliadas:

1. Fluxo de Trabalho Baseado em Prompt (Prompt-based):
   • LLMs (GPT-4o, Gemini 2.5 Pro, Qwen3-Coder) recebem o script e logs de erro.
   • O modelo propõe correções iterativamente (máximo de 5 iterações).
   • Variação de Contexto: Três níveis de riqueza de contexto foram testados:
     • Mínimo: Apenas script e logs.
     • Médio: Script, logs + texto do artigo (Markdown).
     • Completo: Script, logs, texto do artigo + scripts de suporte e instruções detalhadas.
2. Fluxo de Trabalho Baseado em Agente (Agent-based):
   • Agentes de IA autônomos (OpenCode e Claude Code) operam diretamente dentro do ambiente Docker.
   • Eles têm capacidade de inspecionar arquivos, modificar código, reexecutar análises e analisar logs de erro iterativamente até o sucesso ou esgotamento do tempo limite (20 min).
   • Utilizou-se o modelo Qwen3-Coder como base para ambos os agentes para isolar a variável do "agente" vs. "prompt".

C. Validação:

• O sucesso não é medido apenas pela execução do código, mas pela correspondência exata das saídas (outputs) com os dados de ground-truth originais.

3. Contribuições Principais

1. Novo Benchmark Sintético: Um conjunto de dados padronizado com 130 casos de teste injetados em estudos reais de ciências sociais, categorizados por complexidade e diversidade de erros, permitindo comparações controladas.
2. Comparação Empírica Direta: A primeira avaliação sistemática comparando fluxos de trabalho puramente baseados em prompts versus fluxos baseados em agentes autônomos para reparo de reprodutibilidade.
3. Análise de Contexto: Demonstração de como a quantidade e o tipo de informação contextual (artigo, scripts auxiliares) influenciam a capacidade de reparo dos LLMs.
4. Framework de Validação Rigoroso: Estabelecimento de um protocolo onde o sucesso é definido pela reprodução exata dos resultados analíticos, não apenas pela ausência de erros de sintaxe.

4. Resultados Chave

Desempenho Baseado em Prompt:

• A taxa de sucesso variou drasticamente (31% a 79%), dependendo da complexidade do erro e do contexto.
• Gemini 2.5 Pro foi o mais robusto, mantendo bom desempenho mesmo com prompts mínimos.
• GPT-4o e Qwen3-Coder dependiam fortemente de contexto rico. O GPT-4o, por exemplo, saltou de 42,9% (prompts mínimos) para 71,4% (prompts completos) em erros complexos (Categoria C).
• Conclusão: LLMs podem reparar erros, mas são altamente sensíveis à qualidade do prompt e à disponibilidade de contexto analítico.

Desempenho Baseado em Agente:

• Os agentes superaram consistentemente as abordagens baseadas apenas em prompts em todas as categorias.
• Claude Code: Alcançou taxas de sucesso de 96,3% (Cat. A), 91,7% (Cat. B) e 82,1% (Cat. C).
• OpenCode: Alcançou 81,5% (Cat. A), 76,9% (Cat. B) e 69,2% (Cat. C).
• Comparação Direta (usando Qwen3-Coder): O fluxo baseado em agente superou o fluxo baseado em prompt (com contexto completo) em até 43,4 pontos percentuais para erros simples e 27,9 pontos percentuais para erros estruturais complexos.

Fatores de Sucesso:

• A capacidade do agente de interagir ativamente com o ambiente (ler arquivos, rodar testes, analisar logs de erro em tempo real) fornece uma vantagem decisiva sobre a abordagem estática de "enviar prompt e receber resposta".

5. Significado e Conclusão

O estudo conclui que, embora os LLMs baseados em prompts possam reduzir o esforço manual de depuração em casos simples, sistemas baseados em agentes autônomos são superiores para garantir a reprodutibilidade computacional realista.

• Implicação Prática: A simples disponibilidade de código e dados não é suficiente; a reprodutibilidade exige ferramentas capazes de navegar, entender o contexto do projeto e iterar dinamicamente.
• Futuro: Os autores sugerem que a autonomia e o acesso ao ambiente de execução são fatores mais críticos para o sucesso do reparo do que a capacidade bruta do modelo de linguagem.
• Limitações: O estudo ainda é um benchmark sintético e a validação futura deve garantir que os agentes não acessem os dados de ground-truth durante o processo de reparo (evitando vazamento de dados).

Em suma, a automação da reprodutibilidade em ciências sociais avança de uma ferramenta de "sugestão de código" para uma ferramenta de "agente de reparo" que pode restaurar análises científicas falhas de forma confiável.