Theory Under Construction: Orchestrating Language Models for Research Software Where the Specification Evolves

1. Declaração do Problema: O Desafio da Co-evolução

O artigo aborda uma lacuna crítica no desenvolvimento automatizado de software de pesquisa: o problema da co-evolução. Diferentemente das tarefas padrão de engenharia de software, onde a especificação é fixa, o software de pesquisa envolve uma especificação que está em construção. A tese matemática, o código executável, as superfícies de benchmark e as afirmações públicas devem amadurecer em conjunto.

Os agentes atuais de Modelos de Linguagem (LM) falham neste regime devido a dois modos de falha específicos:

1. Acúmulo de Alucinações: Afirmações não suportadas ou dados fabricados introduzidos em uma etapa (por exemplo, em um rascunho de artigo) são tratados como verdade absoluta nas etapas subsequentes, propagando erros através do ciclo de desenvolvimento.
2. Dessincronização: O código, a teoria ou o modelo de mundo interno do LM divergem. Por exemplo, o código pode ser otimizado para uma especificação desatualizada, ou a representação interna do LM do repositório torna-se obsoleta à medida que os arquivos se acumulam, levando a uma incoerência global mesmo que a consistência entre pares exista.

As estruturas existentes (por exemplo, SWE-agent, AI Scientist) assumem tarefas fixas ou quadros de avaliação fixos, tornando-as inadequadas para pesquisas onde o próprio objetivo evolui.

2. Metodologia: Comet-H

Os autores propõem o Comet-H, um autômato de prompt iterativo projetado para orquestrar a evolução acoplada de teoria, código, evidências e afirmações.

Arquitetura Central

O Comet-H opera como uma Máquina de Estado de Co-evolução que gerencia um espaço de trabalho $W$ consistindo de seis componentes:

• $T$ (Teoria): A tese matemática mutável.
• $R$ (Repositório): A implementação do código.
• $P$ (Projeção Pública): O artigo e o README.
• $E$ (Evidência): Benchmarks e registros de fundamentação.
• $U$ (Hipótese de Utilidade): O "porquê" do software.
• $Q$ (Obrigações Abertas): Uma fila de afirmações não verificadas ou tarefas pendentes.

Mecanismos Chave

1. Gatilhos de Fundamentação Reativos:

   • Qualquer alteração em artefatos voltados ao público ($P$: artigo/README) dispara imediatamente uma Criação de Fundamentação seguida de uma Auditoria Cética.
   • Isso força o sistema a verificar afirmações contra código executável e benchmarks antes que elas possam se propagar, limitando a propagação de alucinações a uma única etapa.

2. Restrições de Adjacência:

   • O controlador impede que o sistema derive arbitrariamente. Qualquer expansão ou mudança de direção deve ser "adjacente" ao estado atual (alcançável em um único passo conceitual) e deve fortalecer benchmarks ou teorias existentes. Isso impede que o modelo salte para problemas não relacionados que carecem de superfícies de avaliação.

3. Seleção de Prompt como um Bandito Contextual:

   • O controlador seleciona o próximo prompt de um alfabeto fixo de 17 famílias de prompts (por exemplo, Ideação, Geração de Sementes, Reforço de Artigo, Auditoria Cética).
   • Pontuação: Um ponteador linear transparente e definido manualmente calcula uma pontuação com base em um vetor de características de déficits do espaço de trabalho (por exemplo, "baixa cobertura de testes", "afirmações não verificadas").
   • Decaimento de Obrigações: O trabalho de acompanhamento inacabado é armazenado em um vetor de obrigações $o_t$ que decai exponencialmente (meia-vida de 8 etapas). Isso garante que o controlador se concentre em dívidas recentes e de alta prioridade sem ser sobrecarregado por um histórico obsoleto, mimetizando estratégias de bandito não estacionário.

4. Fases do Ciclo de Desenvolvimento:

   • Semente: Seleciona uma questão de pesquisa diferenciada e um núcleo formal.
   • Iteração Reativa: Gera código/artigos e, em seguida, os endurece iterativamente com base na superfície mais fraca (por exemplo, se os benchmarks são fracos, executa Apertamento de Benchmark).
   • Cauda: Uma sequência fixa de etapas de auditoria e polimento para garantir que a saída final seja fundamentada, independentemente do orçamento restante.

3. Contribuições Principais

1. Definição dos Modos de Falha da Co-evolução: O artigo identifica formalmente o acúmulo de alucinações e a dessincronização como as principais causas de falha na pesquisa automatizada, distintas dos erros de codificação padrão.
2. Máquina de Estado de Co-evolução: Uma estrutura formal (Definição 4.1) que trata a teoria como uma variável de estado mutável e impõe a sincronização entre artefatos através de um modo de controle finito e memória de obrigações em decaimento.
3. Orquestração Transparente: Um design inovador de controlador que combina um ponteador linear definido manualmente com um registro em desaparecimento de trabalho inacabado. Isso evita políticas aprendidas (caixas pretas) em favor de tomada de decisão auditável e interpretável.
4. Portfólio Empírico: A criação de 46 repositórios de software de pesquisa em mais de 12 domínios, demonstrando a escalabilidade da abordagem.

4. Resultados e Estudo de Caso (a3)

Os autores fornecem uma análise profunda do a3, uma ferramenta de análise estática em Python desenvolvida inteiramente dentro do ciclo Comet-H.

• Desempenho: Em um benchmark de 90 casos, o a3 alcançou uma pontuação F1 de 0,768, superando significativamente a próxima melhor linha de base de 0,364.
• Ganhos Monótonos: Estudos de ablação mostraram que cada camada adicional de acoplamento teoria/prática (por exemplo, análise interprocedural, execução simbólica dinâmica) melhorou o desempenho sem degradação.
• Evolução da Teoria: O sistema revisou com sucesso sua teoria subjacente duas vezes durante o desenvolvimento (mudando de uma estrutura de "distância à fronteira" para "certificados de segurança" e integrando solucionadores SMT) sem quebrar a base de código, demonstrando a capacidade do controlador de lidar com mudanças de especificação.
• Observações Comportamentais:
  • Domínio da Auditoria: Nas fases posteriores do desenvolvimento, a maioria dos commits foi para fundamentação, auditoria e reparo de afirmações, em vez de adicionar recursos.
  • Falha Visível: O sistema aprendeu a relatar abertamente limitações (por exemplo, vereditos "DESCONHECIDO" para casos recursivos) em vez de escondê-las, um comportamento impulsionado pelo prompt de Auditoria Cética.
  • Auto-organização: Ao longo de horizontes longos, o LM reorganizou naturalmente o código em estruturas mais composicionais (por exemplo, convertendo para submódulos) sem prompts explícitos.

5. Significado

Este artigo desloca o paradigma dos agentes de pesquisa de IA de conclusão de tarefas (resolver um problema fixo) para gerenciamento de estado (manter a integridade de um sistema em co-evolução).

• Governança sobre Geração: Argumenta que a parte mais difícil da automação de pesquisa não é gerar código, mas garantir que a tese matemática, o código e as afirmações permaneçam sincronizados.
• Novas Métricas de Avaliação: Sugere que futuras avaliações de agentes de pesquisa devem medir estabilidade, recuperabilidade de deriva e latência de reparo de integridade, em vez de apenas pontuações finais de benchmark.
• Impacto Prático: Ao provar que os LMs podem gerenciar todo o ciclo de vida do software de pesquisa — incluindo revisão de teoria e auditoria rigorosa —, o Comet-H fornece um plano de construção para sistemas de descoberta científica autônomos e confiáveis.

Em resumo, o Comet-H demonstra que, ao tratar a pesquisa como um processo co-evolutivo com mecanismos explícitos para fundamentação, auditoria e deriva limitada, os LMs podem navegar com sucesso pelo caminho complexo e não linear de criar software de pesquisa inovador.