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

Este artículo presenta un sistema basado en modelos de lenguaje grandes (LLM) que extrae procedimientos de análisis de publicaciones de física de altas energías para generar código ejecutable, demostrando mediante un caso de estudio de ATLAS que, aunque estos modelos son prometedores como herramientas de apoyo con intervención humana para la reproducibilidad, aún enfrentan desafíos significativos como la aleatoriedad y las alucinaciones que impiden su uso totalmente autónomo.

Lo esencial

¡Hola! Imagina que el mundo de la física de partículas es como una biblioteca gigante llena de recetas de cocina extremadamente complejas. Estas "recetas" son los artículos científicos que explican cómo los físicos descubren cosas nuevas, como el bosón de Higgs. El problema es que estas recetas están escritas en un lenguaje muy técnico, lleno de jerga, y a veces faltan ingredientes o pasos importantes.

Los científicos tienen que leer estas recetas y luego escribir sus propios programas de computadora (código) para intentar cocinar el mismo plato y ver si les sale igual. Esto es muy difícil, lento y aburrido, especialmente para los estudiantes nuevos.

¿Qué hicieron estos autores?

El equipo de investigadores de Japón (de la Universidad de Tokio y KEK) decidió usar una inteligencia artificial muy avanzada (llamada Modelo de Lenguaje Grande o LLM) para ayudar en este proceso. Su objetivo era crear un "robot ayudante" que pudiera:

1. Leer la receta científica (el artículo).
2. Entender los pasos.
3. Escribir automáticamente el código de computadora necesario para reproducir el experimento.

¿Cómo funciona su "Robot Chef"? (El sistema de dos etapas)

En lugar de pedirle a la IA que escriba el código de golpe (lo cual suele salir mal), dividieron el trabajo en dos pasos, como si fuera una cadena de montaje:

Paso 1: El Bibliotecario Inteligente (Extracción de información)
Imagina que tienes una receta que dice "usa la salsa especial del artículo X". El robot primero va a buscar ese artículo X, lo lee y extrae los detalles.

• Lo que hace: Lee el artículo principal y todos los artículos a los que hace referencia.
• El truco: No solo saca una lista de números, sino que crea una "lista de compras estructurada" con notas y referencias claras. Es como si el robot hiciera un resumen ordenado de la receta antes de empezar a cocinar.
• El problema: A veces, la IA se confunde o inventa ingredientes que no existen (lo que llaman "alucinaciones"). Por eso, los humanos tienen que revisar esta lista.

Paso 2: El Chef Programador (Generación de código)
Una vez que tienen la "lista de compras" clara, el robot intenta escribir el código de computadora.

• Lo que hace: Toma la lista y escribe el programa paso a paso.
• El ciclo de prueba: El robot escribe el código, lo ejecuta, ve si funciona y si hay errores, lo corrige solo. Es como un chef que prueba la sopa, le añade sal si falta, y vuelve a probar hasta que sabe bien.
• El resultado: El sistema compara si el plato que cocinó el robot es idéntico al plato original de los científicos.

¿Qué descubrieron? (Los resultados)

Usaron un experimento real de la colaboración ATLAS (que estudia cómo se desintegra una partícula en cuatro electrones) para probar su sistema.

• Lo bueno: ¡Funciona! Los modelos de IA más grandes y potentes (como los que tienen más de 30 mil millones de "neuronas") pudieron leer los artículos complejos y escribir código que, en algunos intentos, copia exactamente lo que hicieron los humanos.
• Lo malo: La IA es un poco impredecible. A veces funciona perfecto, y otras veces inventa reglas que no existen o falla al ejecutar el código. Es como un chef genial que a veces cocina un banquete de 5 estrellas y a veces quema la sopa porque leyó mal la receta.
• La conclusión clave: Por ahora, no podemos confiar en la IA para que trabaje sola. Necesitamos un "humano en el bucle". La IA es una herramienta increíblemente útil para hacer el trabajo sucio y rápido, pero un físico real debe revisar el trabajo final para asegurarse de que no haya errores.

¿Por qué es importante esto?

Imagina que la ciencia es un juego de "teléfono descompuesto". Si un científico escribe mal una receta, el siguiente que intente copiarla fallará.
Este sistema ayuda a:

1. Acelerar la ciencia: Los estudiantes no pierden meses aprendiendo a programar desde cero.
2. Mejorar la calidad: Si la IA no puede entender la receta, significa que el artículo original estaba mal escrito o era ambiguo. ¡La IA nos ayuda a escribir mejores artículos científicos!
3. Verificar la verdad: Permite comprobar rápidamente si los resultados publicados son realmente reproducibles.

En resumen:
Los autores crearon un asistente de IA que actúa como un traductor y un programador junior. No es un genio infalible que trabaja solo, pero es un compañero de trabajo fantástico que puede leer miles de páginas en segundos y escribir el código base, ahorrando tiempo y ayudando a que la ciencia sea más transparente y reproducible. ¡El futuro de la física podría depender de esta colaboración entre humanos y robots!

Resumen técnico

A continuación presento un resumen técnico detallado del artículo en español, estructurado según los puntos solicitados:

Resumen Técnico: Desarrollo de un Sistema Basado en LLM para la Generación Automática de Código a partir de Publicaciones de Física de Altas Energías (HEP)

1. El Problema

El análisis de datos en la Física de Altas Energías (HEP) se ha vuelto cada vez más complejo, requiriendo una gran experiencia computacional y tiempo para configurar entornos y escribir código. Esto eleva la barrera de entrada para estudiantes y nuevos investigadores. Además, garantizar la reproducibilidad de los resultados físicos es un desafío crítico. Aunque los Modelos de Lenguaje Grande (LLM) ofrecen soporte potente para la codificación, su uso en análisis totalmente automatizados es riesgoso debido a la variación estocástica y las "alucinaciones" (generación de información falsa), lo que hace necesaria una verificación cuidadosa.

2. Metodología

Los autores desarrollaron un sistema de prueba de concepto (PoC) que utiliza LLMs de pesos abiertos (open-weight) en un flujo de trabajo de dos etapas, diseñado como un asistente "humano-en-el-bucle" (human-in-the-loop) en lugar de un agente autónomo.

• Etapa 1: Extracción de Selección (Selección de Criterios)

  • Objetivo: Extraer criterios de selección de eventos, definiciones de objetos y otra información relevante de un artículo de HEP y sus referencias citadas.
  • Proceso: Utiliza un flujo iterativo con componentes de planificación, carga (conversión de PDF a Markdown), lectura y fusión.
  • Representación Intermedia: En lugar de generar código directamente, el sistema crea una lista de selección estructurada (legible por humanos) que incluye comentarios y procedencia de las referencias. Esto permite verificar la información antes de la codificación.
  • Estrategias: Se compararon modos de "Lote" (texto completo) y "Fragmento" (segmentos secuenciales) para manejar ventanas de contexto limitadas.

• Etapa 2: Generación de Código

  • Objetivo: Convertir la lista de selección estructurada en código de análisis ejecutable.
  • Proceso: Un flujo iterativo basado en LangGraph donde un planificador descompone la tarea, un generador escribe el código, un ejecutor lo ejecuta en un contenedor aislado (Singularity con ROOT, numpy, uproot) y un validador verifica tanto la ejecución como la lógica contra criterios de finalización.
  • Limitación Controlada: Para esta evaluación, se proporcionaron explícitamente todas las especificaciones necesarias (variables disponibles, restricciones) en el prompt, sin usar RAG (Recuperación Aumentada por Generación) para conocimiento de dominio, aislando así la capacidad de traducción del modelo.

3. Contribuciones Clave

1. Flujo de Trabajo Verificable: Implementación de un pipeline que separa la comprensión del documento de la generación de código, introduciendo una representación intermedia estructurada y legible para humanos. Esto posiciona al LLM como un colaborador verificable y no como una "caja negra".
2. Evaluación Cuantitativa Separada: Uso de los datos abiertos de ATLAS ($H \to ZZ^* \to 4\ell$) como benchmark para evaluar por separado la extracción de criterios y la generación de código, permitiendo identificar cuellos de botella específicos.
3. Análisis de Modelos de Pesos Abiertos: Evaluación exhaustiva de modelos de código abierto (Qwen3, GPT-OSS) frente a modelos comerciales, demostrando su viabilidad y limitaciones en tareas de HEP.

4. Resultados

El sistema se probó utilizando datos de colisiones protón-protón de 2015-2016 de ATLAS Open Data, comparando los resultados con una implementación manual de referencia (ground truth) de 27 criterios de selección.

• Extracción (Etapa 1):

  • Los modelos con $\ge$30B parámetros (como Qwen3:235B y GPT-OSS:120B) lograron extraer la mayoría de los criterios documentados, identificando todos los 27 en algunas ejecuciones.
  • El modelo pequeño (4B) tuvo un rendimiento pobre.
  • Desafíos: Persiste una alta estocasticidad (variación entre ejecuciones) y alucinaciones contradictorias. El modo "Fragmento" mejoró la recuperación para modelos pequeños pero aumentó drásticamente la tasa de fallos y alucinaciones.

• Generación de Código (Etapa 2):

  • Coincidencia Exacta: Los modelos más grandes lograron generar código que coincidía exactamente a nivel de eventos con la implementación de referencia en algunas ejecuciones:
    • Qwen3-Coder-Next (80B): 3/10 ejecuciones.
    • GPT-OSS (120B): 2/10 ejecuciones.
    • Qwen3-Coder (30B): 0/10 ejecuciones.
  • Fallo de Ejecución: Una alta frecuencia de resultados "No coincidentes" o "Fallo de ejecución" indica que la estabilidad y corrección actuales son insuficientes para la autonomía total.
  • Hallazgo Crítico: La existencia de código ejecutable que produce selecciones de eventos incorrectas demuestra que el éxito de la ejecución no es un proxy de la corrección física, subrayando la necesidad de verificación a nivel de evento.

5. Significado y Conclusiones

• Viabilidad como Herramienta Colaborativa: Los LLMs de pesos abiertos son prometedores como herramientas de apoyo para la reproducibilidad dentro de un marco "humano-en-el-bucle", donde los físicos pueden inspeccionar estados intermedios verificables.
• Limitaciones para la Autonomía Total: Actualmente, no son lo suficientemente fiables para actuar como agentes de análisis totalmente autónomos debido a la estocasticidad, las alucinaciones y los fallos de ejecución.
• Impacto en la Reproducibilidad: El sistema sirve como un marco para evaluar la calidad de la documentación en las publicaciones de HEP; un fallo en la reproducción puede indicar descripciones ambiguas o información faltante en el artículo original.
• Futuro: Las direcciones futuras incluyen la integración de RAG para conocimiento específico de HEP (APIs de ROOT, etc.), la evaluación de extremo a extremo para ver cómo los errores de extracción afectan la generación de código, y la expansión de los benchmarks a otros análisis.

En resumen, el trabajo demuestra que, aunque la automatización completa aún no es viable, los LLMs pueden acelerar significativamente el proceso de análisis y mejorar la transparencia si se utilizan como asistentes verificables bajo supervisión humana.