Resumen Técnico: Articulación de Supuestos en Análisis Científicos Generados por IA mediante la Descomposición de Tareas

Planteamiento del Problema

La integración de los Modelos de Lenguaje de Gran Escala (LLM) en la computación científica ofrece el potencial de automatizar la generación de código de análisis ejecutable a partir de especificaciones en lenguaje natural. Sin embargo, esta capacidad introduce riesgos significativos respecto a la comprensibilidad y reproducibilidad de los resultados científicos. Existen dos fuentes primarias de incertidumbre:

1. Ambigüedad de la Especificación: Las solicitudes en lenguaje natural suelen carecer de las definiciones procedimentales estrictas requeridas para la computación, dejando aspectos críticos (por ejemplo, criterios de selección de objetos, unidades de agregación, reglas de derivación) abiertos a la interpretación.
2. Variabilidad Estocástica: Los LLM pueden producir código diferente, incompleto o semánticamente incorrecto para prompts idénticos.

En consecuencia, incluso si el código generado se ejecuta sin errores, puede no reflejar la física pretendida por el investigador. La "ejecutabilidad" del código no garantiza que los supuestos subyacentes, las definiciones de objetos o las rutas computacionales sean explícitos o correctos. Esto es particularmente crítico en la física de altas energías (HEP), donde los resultados dependen de definiciones precisas de colecciones de partículas, observables compuestos y cortes de selección.

Metodología: Un Marco de Trabajo Multi-Agente

Los autores proponen un marco de trabajo multi-agente que descompone el flujo de trabajo de análisis científico en etapas distintas y auditables. En lugar de depender de un único prompt para generar código, el sistema orquesta agentes especializados para gestionar la generación de código, la ejecución, el rastreo y la crítica. El flujo de trabajo está diseñado para ser agnóstico al dominio, con paquetes intercambiables que encapsulan el conocimiento específico del dominio.

El flujo de trabajo central consiste en las siguientes etapas:

1. Inicialización del Dominio: Un paquete de dominio (por ejemplo, para datos de LHC Olympics) proporciona un perfil de generación, un registro de funciones auxiliares, políticas de selección y contextos de crítica. Esto separa la lógica de orquestación general de los recursos específicos del dominio.
2. Selección de Auxiliares (Helpers): Un agente dedicado analiza la tarjeta de tarea del usuario y un registro de funciones auxiliares predefinidas (por ejemplo, reconstrucción cinemática, selección de objetos) para identificar las utilidades más relevantes. Este paso restringe la generación de código subsiguiente, evitando que el modelo invente funciones o haga un uso incorrecto de las herramientas del dominio.
3. Generación de Código: Un agente genera un script de Python utilizando la tarjeta de tarea enriquecida (solicitud original + auxiliares seleccionados) y el perfil de generación del dominio.
4. Ejecución y Reparación Iterativa: El código generado se ejecuta en un entorno de pruebas (sandbox). Si ocurren errores, un agente Fixer intenta parchear el código basándose en diagnósticos de tiempo de ejecución. Si las reparaciones fallan, un agente Regenerator produce una implementación nueva.
5. Rastreo de Implementación: Una vez obtenido el código ejecutable, un agente Tracer reconstruye una "especificación tal como se implementó". Este extrae fragmentos de código correspondientes a cada elemento de la tarjeta de tarea, mapeándolos a definiciones de variables, cadenas de dependencia y referencias de líneas de código fuente. Esto crea una representación estructurada de lo que el código realmente hace, independientemente del texto bruto del código fuente.
6. Crítica Post-Generación: Un agente de Crítica compara la tarjeta de tarea original con la especificación reconstruida. Identifica discrepancias, requisitos faltantes, supuestos ocultos o violaciones semánticas (por ejemplo, calcular un observable compuesto directamente desde partículas crudas en lugar de un objeto reconstruido).
7. Detección de Ambigüedad (Oráculo Golden Axe): Antes de la generación de código, un módulo Oráculo inspecciona la entrada de lenguaje natural del usuario en busca de ambigüedas de alto riesgo. Identifica frases que podrían conducir a múltiples implementaciones válidas (por ejemplo, "jet líder" frente a "jet líder después de los cortes") y propone preguntas de aclaración al usuario, ofreciendo interpretaciones "Golden" (recomendadas) y "Silver" (alternativas).

Contribuciones Clave

1. Descomposición de Tareas para Modelos Pequeños

Un hallazgo central es que descomponer la tarea de generación permite que modelos de LLM sustancialmente más pequeños ejecuten flujos de trabajo científicos complejos. Mientras que enfoques previos (por ejemplo, CoLLM) requerían modelos de ~70B de parámetros para obtener resultados fiables, este marco permite que modelos tan pequeños como 14B de parámetros (por ejemplo, Qwen2.5-14B, Qwen3-14B) completen con éxito todo el pipeline. El Selector de Auxiliares es crítico aquí, ya que guía al generador mediante la inyección de utilidades de dominio relevantes, reduciendo la carga cognitiva del modelo.

2. Reconstrucción Semántica y Rastreo

La introducción del módulo Tracer aborda la naturaleza de "caja negra" del código generado. Al reconstruir la especificación de implementación a partir del código, el marco hace explícitas las definiciones de las colecciones seleccionadas, las selecciones de eventos y las cantidades compuestas. Esto permite una comparación semántica entre la intención del usuario y el comportamiento del código, en lugar de una simple verificación de sintaxis.

3. Resolución Explícita de Ambigüedades

El módulo Golden Axe Oracle traslada la carga de resolver la ambigüedad del LLM al investigador humano. Al detectar frases ambiguas antes de la generación de código y presentar interpretaciones alternativas, el sistema evita que el modelo tome erróneamente supuestos de forma silenciosa.

4. Adaptabilidad de Dominio Modular

El marco está diseñado con una interfaz fija para los activos del dominio. Aunque la implementación actual se centra en la física de altas energías (específicamente el formato LHC Olympics), la arquitectura permite la adaptación a otros dominios científicos mediante el intercambio del paquete de dominio (perfil de generación, registro de auxiliares, contexto de crítica) sin alterar la lógica de orquestación central.

Resultados y Validación

El marco fue validado en cinco análisis representativos de física de colisionadores (por ejemplo, $W^+W^-$, $t\bar{t}$, $H \to \gamma\gamma$) utilizando el formato de eventos de LHC Olympics.

• Estabilidad de la Selección de Auxiliares: El Selector de Auxiliares mejoró significamente la estabilidad. Mientras que los modelos de 70B mostraron una alta consistencia, los modelos de 14B también lograron una selección de auxiliares fiable cuando fueron guiados por el registro, mientras que los enfoques anteriores de un solo agente fallaron con modelos de este tamaño.
• Calidad del Código y Fidelidad Semántica:
  • El código generado por modelos de 14B fue a menudo "parcialmente exitoso", implementando la lógica de selección central pero fallando en observables compuestos complejos (por ejemplo, calcular $\Delta\phi$ entre un sistema de dijets frente a jets individuales).
  • La etapa de Crítica identificó con éxito estos desajustes semánticos, tales como la aplicación incorrecta de veto de $b$-jets (aplicándolo a jets crudos en lugar de jets seleccionados) o el orden incorrecto de llenado de histogramas.
• Detección de Ambigüedades:
  • Los modelos más grandes (72B) detectaron más ambigüedades (28/30 posibles) que los modelos más pequeños (el de 14B detectó 13/30).
  • La introducción de oraclet (templated por el Oráculo), que restringe la búsqueda de ambigüedades a categorías específicas (Alcance de Colección, Objeto de Varias Partes, Tiempo de Salida), mejoró significamente el rendimiento de los modelos más pequeños (por ejemplo, los modelos de 7B detectaron 27/30 ambigüedades útiles con el enfoque basado en plantillas).
• Refinamiento de la Tarjeta de Tarea: El estudio demostró que definir explícitamente la construcción de objetos compuestos dentro de la tarjeta de tarea (en lugar de confiar en convenciones implícitas del modelo) mejoró drásticamente la estabilidad y la consistencia de la generación en ejecuciones repetidas.

Significado y Reivindicaciones

El artículo sostiene que la reproducibilidad y transparencia en la ciencia generada por IA requieren más que solo código ejecutable; requieren una contabilidad explícita de los supuestos y las rutas computacionales utilizadas.

• Cambio de Paradigma: Este trabajo se aleja de tratar la generación de código como un único paso de inferencia hacia un proceso estructurado con múltiples puntos de inspección.
• Accesibilidad: Al permitir el uso de modelos de 14B, el marco hace que el análisis científico avanzado asistido por IA sea accesible en recursos de computación locales, reduciendo la dependencia de acceso a costosos modelos propietarios masivos.
• Humano en el Bucle (Human-in-the-Loop): El marco no pretende la autonomía total. En su lugar, posiciona al LLM como una herramienta que genera candidatos, mientras que los agentes Tracer y Critique, junto con el Oracle, facilitan la inspección y verificación humana. Los artefactos intermedios (listas de auxiliares, especificaciones reconstruidas, reportes de crítica) sirven como un registro de procedencia, permitiendo a los investigadores auditar exactamente cómo se derivó un resultado.

En conclusión, los autores argumentan que este enfoque modular multi-agente mejora la fiabilidad de los análisis científicos generados por LLM al hacer explícitos los supuestos implícitos y permitir el uso de modelos más pequeños y accesibles sin sacrificar el rigor requerido para el descubrimiento científico.