Development of an LLM-Based System for Automatic Code Generation from HEP Publications

Este artigo apresenta um sistema protótipo baseado em modelos de linguagem de grande escala (LLMs) que extrai procedimentos de análise de publicações de física de altas energias para gerar código executável, demonstrando, através de um benchmark do ATLAS, que essas ferramentas são promissoras para apoiar a reprodutibilidade com supervisão humana, embora ainda enfrentem desafios como alucinações e falhas de execução.

O essencial

Imagine que você é um cozinheiro tentando recriar o prato favorito de um famoso chef, mas você só tem o livro de receitas dele. O problema é que o livro não diz tudo: ele diz "adicione o tempero secreto", mas não diz qual é, e diz "cozinhe até ficar dourado", mas não diz por quanto tempo. Além disso, o livro faz referência a outros livros para explicar detalhes técnicos.

É exatamente esse o desafio que os físicos de alta energia enfrentam hoje. Eles publicam descobertas complexas em artigos científicos, mas recriar (ou "reproduzir") esses resultados no computador é difícil, demorado e cheio de armadilhas.

Neste artigo, os autores (do Japão) criaram um assistente inteligente baseado em Inteligência Artificial (especificamente em Modelos de Linguagem Grandes, ou LLMs) para tentar resolver esse problema. Vamos explicar como funciona usando uma analogia simples:

O Assistente "Chef Robô"

O sistema deles funciona como um chef robô que tem duas tarefas principais, divididas em duas etapas:

Etapa 1: O "Leitor" que faz a lista de compras

O primeiro trabalho do robô é ler o artigo científico (e os outros artigos que ele cita) e extrair as regras exatas.

• O que ele faz: Ele tenta entender frases como "selecione apenas partículas com mais de 50 GeV" e transforma isso em uma lista de instruções organizada.
• O problema: Às vezes, o robô alucina. Ele pode inventar um ingrediente que não existe no livro ou confundir uma medida. É como se ele lesse "sal" e escrevesse "açúcar" na lista.
• A solução: Eles testaram vários modelos de IA (alguns pequenos, outros gigantes) para ver quem lia melhor. Descobriram que os modelos maiores (como um "cérebro" de 235 bilhões de parâmetros) são ótimos em encontrar as regras certas, mas ainda cometem erros aleatórios.

Etapa 2: O "Cozinheiro" que escreve o código

Depois de ter a lista de regras, o robô precisa escrever o código de computador (a receita em linguagem de máquina) para executar a análise.

• O que ele faz: Ele pega a lista da Etapa 1 e tenta escrever um programa que simule o experimento.
• O teste: Eles usaram dados reais do CERN (o laboratório de física de partículas) como um "desafio". O robô tentou recriar um experimento específico sobre o bóson de Higgs.
• O resultado: Em algumas tentativas, o robô conseguiu escrever um código que funcionava perfeitamente e dava exatamente o mesmo resultado que os físicos humanos. Mas, na maioria das vezes, o código falhava ou produzia resultados errados, mesmo que o robô achasse que estava certo.

O Grande Aprendizado: O Robô é um Estagiário, não o Chefe

A conclusão mais importante do artigo é que a IA ainda não pode trabalhar sozinha.

Pense na IA como um estagiário muito inteligente, mas um pouco distraído.

• Ela consegue ler livros complexos e escrever códigos impressionantes.
• Ela pode fazer o trabalho de 80% do caminho.
• MAS, ela pode inventar fatos (alucinar) ou cometer erros bobos que quebram o experimento.

Por isso, os autores propõem um sistema "Humano no Comando" (Human-in-the-loop).
O fluxo ideal seria:

1. O Robô lê o artigo e faz a lista de regras.
2. O Físico (Humano) revisa a lista, corrige os erros e confirma se faz sentido.
3. O Robô escreve o código baseado na lista corrigida.
4. O Físico verifica se o código roda e se o resultado final está certo.

Por que isso é importante?

Hoje, recriar um experimento de física pode levar semanas para um estudante novo. Com essa ferramenta, o processo pode ser acelerado, permitindo que os pesquisadores foquem na física real e não na burocracia de escrever código.

Além disso, se o robô não consegue entender o artigo, isso é um sinal de alerta para os cientistas: "Ei, nosso artigo está mal escrito ou falta informação!". Isso ajuda a melhorar a qualidade da ciência publicada no futuro.

Resumo em uma frase

Os autores criaram um protótipo onde uma IA tenta transformar artigos científicos em códigos de computador executáveis; embora a IA seja promissora e rápida, ela ainda precisa de supervisão humana constante para não inventar regras ou quebrar o experimento, funcionando melhor como um assistente colaborativo do que como um cientista autônomo.

Resumo técnico

Título: Desenvolvimento de um Sistema Baseado em LLM para Geração Automática de Código a partir de Publicações de Física de Altas Energias (HEP)

1. O Problema

A análise de dados na Física de Altas Energias (HEP) tornou-se cada vez mais complexa, exigindo expertise computacional substancial e tempo significativo para configurar ambientes e escrever código. Isso cria uma barreira de entrada elevada para estudantes e novos pesquisadores. Embora os Grandes Modelos de Linguagem (LLMs) ofereçam suporte poderoso para codificação, a automação total permanece difícil de confiar devido à variação estocástica e alucinações (erros factuais). Além disso, garantir a reprodutibilidade dos resultados físicos é um desafio crítico, pois muitas vezes as descrições nos artigos são ambíguas ou delegam definições detalhadas a referências citadas.

2. Metodologia

Os autores desenvolveram um fluxo de trabalho de Proof-of-Concept (PoC) em duas etapas, utilizando LLMs de pesos abertos (open-weight) e frameworks como LangChain e LangGraph. O sistema não gera código diretamente do texto bruto, mas utiliza uma representação intermediária estruturada e legível por humanos para atuar como um colaborador verificável.

• Etapa 1: Extração de Seleção (Selection Extraction)

  • Objetivo: Extrair critérios de seleção de eventos, definições de objetos e outras informações relevantes do artigo-alvo e de suas referências citadas.
  • Fluxo: Um sistema iterativo composto por quatro componentes:
    1. Planner: Determina qual referência ler a seguir e formula objetivos de leitura específicos.
    2. Loader: Converte PDFs para Markdown, isola textos relevantes e mapeia citações para IDs do arXiv.
    3. Reader: Extrai os critérios com base nos objetivos (testado em modos "Bulk" e "Chunk").
    4. Merger: Integra os novos resultados à lista estruturada existente, tratando referências como suplementares para evitar sobrescrita indevida.
  • Saída: Uma lista de seleção estruturada com comentários e proveniência das referências.

• Etapa 2: Geração de Código (Code Generation)

  • Objetivo: Gerar código de análise executável a partir da lista estruturada da Etapa 1.
  • Fluxo: Um workflow iterativo baseado em LangGraph:
    1. Planner: Decompõe a tarefa em subtarefas sequenciais.
    2. Generator: Produz código para a subtarefa atual, recebendo feedback de validação e erros de execução anteriores.
    3. Executor: Executa o código em um container Singularity isolado (com ROOT, numpy, uproot).
    4. Validator: Avalia os resultados de execução e o próprio código contra critérios de conclusão. Se falhar, o código é revisado.
  • Contexto: A geração ocorre em um ambiente controlado onde o prompt fornece todas as especificações necessárias (variáveis disponíveis, restrições), sem recuperação autônoma de conhecimento de domínio (RAG) nesta fase inicial.

3. Benchmark e Avaliação

• Dataset: Análise ATLAS $H \to ZZ^* \to 4\ell$ (bóson de Higgs decaindo em quatro léptons) usando dados de colisão próton-próton de 2015-2016 do ATLAS Open Data.
• Ground Truth: Uma implementação manual da análise (baseline) e uma lista de 27 critérios de seleção explicitamente identificáveis.
• Métricas:
  • Etapa 1: Número de cortes corretamente extraídos e número de alucinações contraditórias.
  • Etapa 2: Comparação no nível de eventos (event level) entre o código gerado e a baseline. Categorias: "Exatamente Correspondido" (lista de eventos idêntica), "Não Correspondido" (execução válida, mas eventos diferentes) ou "Falha na Execução".
• Modelos Testados: Modelos de pesos abertos (Qwen3 em várias escalas, GPT-OSS) e modelos comerciais (Gemini 2.5) como baseline. Cada modelo foi executado 10 vezes para avaliar a estocasticidade.

4. Resultados Principais

• Extração de Seleção (Etapa 1):
  • Modelos com $\ge 30B$ parâmetros (como Qwen3:235B e Gemini 2.5 Flash) conseguiram extrair a maioria dos critérios documentados, identificando todos os 27 cortes em algumas execuções.
  • O modelo menor (4B) teve desempenho pobre.
  • Desafios: Alta variação entre execuções (estocasticidade) e alucinações persistentes, mesmo nos modelos maiores. O modo "Chunk" (processamento por segmentos) melhorou a recuperação de cortes para modelos pequenos, mas aumentou drasticamente a taxa de falha e alucinações.
• Geração de Código (Etapa 2):
  • Modelos maiores (Qwen3-Coder-Next:80B e GPT-OSS:120B) conseguiram gerar código que correspondia exatamente à implementação manual em 3/10 e 2/10 execuções, respectivamente.
  • O modelo de 30B não obteve nenhuma correspondência exata.
  • Desafios: Alta frequência de resultados "Não Correspondidos" e falhas de execução. O fato de existir código executável que produz seleções de eventos incorretas destaca que o sucesso da execução não é um proxy para a correção física.

5. Contribuições Chave

1. Fluxo de Trabalho Verificável: Implementação de um pipeline que separa a compreensão do documento da geração de código, introduzindo uma representação intermediária estruturada para permitir a verificação humana.
2. Avaliação Quantitativa de Reprodutibilidade: Uso do ATLAS Open Data como benchmark para avaliar separadamente a capacidade de extração de informações e a geração de código, esclarecendo as limitações atuais dos LLMs de pesos abertos.
3. Framework de Avaliação de Estocasticidade: Demonstração rigorosa de que a variabilidade entre execuções é um obstáculo significativo para a automação total.

6. Significado e Conclusão

O estudo conclui que os LLMs de pesos abertos atuais ainda não são confiáveis o suficiente para atuar como agentes de análise totalmente autônomos na HEP devido a alucinações, estocasticidade e falhas de execução.

No entanto, eles mostram grande promessa como ferramentas de colaboração "human-in-the-loop" (humano no ciclo). O sistema pode acelerar a extração de procedimentos e a geração de código inicial, mas a verificação humana de estados intermediários e resultados finais permanece essencial.

Direções Futuras:

• Avaliação end-to-end para entender como erros na extração (Etapa 1) propagam para a geração de código (Etapa 2).
• Integração de RAG (Retrieval-Augmented Generation) para conhecimento específico de domínio (ex: APIs do ROOT).
• Expansão do benchmark para outros tipos de análises.
• Uso da ferramenta para identificar ambiguidades em artigos antes da publicação, melhorando a transparência e reprodutibilidade da literatura de HEP.