Resumo Técnico: Articulando Suposições em Análises Científicas Geradas por IA através da Decomposição de Tarefas

Declaração do Problema

A integração de Modelos de Linguagem de Grande Escala (LLMs) na computação científica oferece o potencial de automatizar a geração de código de análise executável a partir de especificações em linguagem natural. No entanto, essa capacidade introduz riscos significativos em relação à compreensibilidade e reprodutibilidade dos resultados científicos. Existem duas fontes primárias de incerteza:

1. Ambiguidade de Especificação: Pedidos em linguagem natural frequentemente carecem das definições procedimentais estritas exigidas para a computação, deixando aspectos críticos (ex: critérios de seleção de objetos, unidades de agregação, regras de derivação) abertos à interpretação.
2. Variabilidade Estocástica: Os LLMs podem produzir códigos diferentes, incompletos ou semanticamente incorretos para prompts idênticos.

Consequentemente, mesmo que o código gerado seja executado sem erros, ele pode não refletir a física pretendida pelo pesquisador. A "executabilidade" do código não garante que as suposições subjacentes, as definições de objetos ou os caminhos computacionais sejam explícitos ou corretos. Isso é particularmente crítico na física de altas energias (HEP), onde os resultados dependem de definições precisas de coleções de partículas, observáveis compostos e cortes de seleção (selection cuts).

Metodologia: Um Framework Multi-Agente

Os autores propõem um framework multi-agente que decompõe o fluxo de trabalho de análise científica em estágios distintos e auditáveis. Em vez de depender de um único prompt para gerar código, o sistema orquestra agentes especializados para gerenciar a geração de código, execução, rastreamento e crítica. O fluxo de trabalho é projetado para ser agnóstico ao domínio, com conhecimento específico do domínio encapsulado em pacotes intercambiáveis.

O fluxo de trabalho central consiste nos seguintes estágios:

1. Inicialização do Domínio: Um pacote de domínio (ex: para dados do LHC Olympics) fornece um perfil de geração, um registro de auxiliares (helper registry), políticas de seleção e contextos de crítica. Isso separa a lógica de orquestração geral dos recursos específicos do domínio.
2. Seleção de Auxiliares (Helper Selection): Um agente dedicado analisa o cartão de tarefa do usuário e um registro de funções auxiliares pré-definidas (ex: reconstrução cinemática, seleção de objetos) para identificar as utilidades mais relevantes. Este passo restringe a geração de código subsequente, impedindo o modelo de inventar funções ou usar incorretamente ferramentas do domínio.
3. Geração de Código: Um agente gera um script Python usando o cartão de tarefa enriquecido (pedido original + auxiliares selecionados) e o perfil de geração do domínio.
4. Execução e Reparo Iterativo: O código gerado é executado em um ambiente de teste (sandbox). Se ocorrerem erros, um agente Fixer tenta corrigir o código com base em diagnósticos de tempo de execução. Se os reparos falharem, um agente Regenerator produz uma nova implementação.
5. Rastreamento de Implementação (Implementation Tracing): Uma vez obtido o código executável, um agente Tracer reconstrói uma "especificação conforme implementada". Ele extrai fragmentos de código correspondentes a cada item no cartão de tarefa, mapeando-os para definições de variáveis, cadeias de dependência e referências de linhas de origem. Isso cria uma representação estruturada do que o código realmente faz, independente do texto bruto do código fonte.
6. Crítica Pós-Geração: Um agente de Crítica compara o cartão de tarefa original com a especificação reconstruída. Ele identifica discrepâncias, requisitos ausentes, suposições ocultas ou violações semânticas (ex: computar um observável composto diretamente de partículas brutas em vez de um objeto reconstruído).
7. Detecção de Ambiguidade (Oráculo Golden Axe): Antes da geração de código, um módulo Oracle inspeciona a entrada de linguagem natural do usuário em busca de ambiguidades de alto risco. Ele identifica frases que poderiam levar a múltiplas implementações válidas (ex: "jato líder" vs. "jato líder após cortes") e propõe perguntas de esclarecimento ao usuário, oferecendo interpretações "Golden" (recomendada) e "Silver" (alternativa).

Principais Contribuições

1. Decomposição de Tarefas para Modelos Pequenos

Uma descoberta central é que decompor a tarefa de geração permite que modelos de LLM substancialmente menores executem fluxos de trabalho científicos complexos. Enquanto abordagens anteriores (ex: CoLLM) exigiam modelos de ~70B de parâmetros para resultados confiáveis, este framework permite que modelos tão pequenos quanto 14B de parâmetros (ex: Qwen2.5-14B, Qwen3-14B) completem com sucesso todo o pipeline. O Helper Selector é crítico aqui, pois guia o gerador injetando utilidades de domínio relevantes, reduzindo a carga cognitiva do modelo.

2. Reconstrução Semântica e Rastreamento

A introdução do módulo Tracer aborda a natureza de "caixa preta" do código gerado. Ao reconstruir a especificação de implementação a partir do código, o framework torna explícitas as definições das coleções selecionadas, seleções de eventos e quantidades compostas. Isso permite uma comparação semântica entre a intenção do usuário e o comportamento do código, em vez de uma verificação sintática superficial.

3. Resolução Explícita de Ambiguidade

O módulo Golden Axe Oracle transfere o ônus da resolução de ambiguidades do LLM para o pesquisador humano. Ao detectar frases ambíguas antes da geração de código e apresentar interpretações alternativas, o sistema evita que o modelo tome incorretamente suposições silenciosas.

4. Adaptabilidade de Domínio Modular

O framework é projetado com uma interface fixa para ativos de domínio. Embora a implementação atual foque em Física de Altas Energias (especificamente o formato LHC Olympics), a arquitetura permite a adaptação para outros domínios científicos ao trocar o pacote de domínio (perfil de geração, registro de auxiliares, contexto de crítica) sem alterar a lógica central de orquestração.

Resultados e Validação

O framework foi validado em cinco análises representativas de física de colisores (ex: $W^+W^-$, $t\bar{t}$, $H \to \gamma\gamma$) usando o formato de evento LHC Olympics.

• Estabilidade da Seleção de Auxiliares: O Helper Selector melhorou significamente a estabilidade. Enquanto modelos de 70B mostraram alta consistência, modelos de 14B também alcançaram uma seleção de auxiliares confiável quando guiados pelo registro, ao passo que abordagens anteriores de agente único falharam com modelos desse tamanho.
• Qualidade do Código e Fidelidade Semântica:
  • O código gerado por modelos de 14B foi frequentemente "parcialmente bem-sucedido", implementando a lógica central de seleção, mas falhando em observáveis compostos complexos (ex: calcular $\Delta\phi$ entre um sistema de dijet vs. jatos individuais).
  • A etapa de Crítica identificou com sucesso essas discrepâncias semânticas, como a aplicação incorreta de veto de $b$-jet (aplicando a jatos brutos vs. jatos selecionados) ou a ordem incorreta de preenchimento de histogramas.
• Detecção de Ambiguidade:
  • Modelos maiores (72B) detectaram mais ambiguidades (28/30 possíveis) do que modelos menores (14B detectou 13/30).
  • A introdução do Oracle-templated (oraclet), que restringe a busca de ambiguidade a categorias específicas (Escopo de Coleção, Objeto de Múltiplas Partes, Tempo de Saída), melhorou significamente o desempenho de modelos menores (ex: modelos de 7B detectaram 27/30 ambiguidades úteis com a abordagem de template).
• Refinamento do Cartão de Tarefa: O estudo demonstrou que definir explicitamente a construção de objetos compostos dentro do cartão de tarefa (em vez de confiar em convenções implícitas do modelo) melhorou drasticamente a estabilidade e a consistência da geração em execuções repetidas.

Significância e Alegações

O artigo alega que a reprodutibilidade e transparência na ciência gerada por IA requerem mais do que apenas código executável; elas exigem uma prestação de contas explícita das suposições e dos caminhos computacionais utilizados.

• Mudança de Paradigma: O trabalho afasta-se de tratar a geração de código como um único passo de inferência, movendo-se em direção a um processo estruturado com múltiplos pontos de inspeção.
• Acessibilidade: Ao permitir o uso de modelos de 14B, o framework torna a análise científica avançada assistida por IA acessível em recursos computacionais locais, reduzindo a dependência de acesso caro a modelos proprietários massivos.
• Humano no Ciclo (Human-in-the-Loop): O framework não visa a autonomia total. Em vez disso, posiciona o LLM como uma ferramenta que gera candidatos, enquanto os agentes Tracer e Critique, juntamente com o Oracle, facilitam a inspeção e verificação humana. Os artefatos intermediários (listas de auxiliares, especificações reconstruídas, relatórios de crítica) servem como um registro de proveniência, permitindo que os pesquisadores auditem exatamente como um resultado foi derivado.

Em conclusão, os autores argumentam que esta abordagem multi-agente modular aumenta a confiabilidade das análises científicas geradas por LLM ao tornar explícitas as suposições implícitas e permitir o uso de modelos menores e mais acessíveis sem sacrificar o rigor necessário para a descoberta científica.