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

A continuación se presenta un resumen técnico detallado del artículo "Orquestando Modelos de Lenguaje para Software de Investigación donde la Especificación Evoluciona", de Halley Young y Nikolaj Bjørner.

1. Planteamiento del Problema: El Desafío de la Co-evolución

El artículo aborda una brecha crítica en el desarrollo automatizado de software de investigación: el problema de la co-evolución. A diferencia de las tareas de ingeniería de software estándar donde la especificación es fija, el software de investigación implica una especificación que está en construcción. La tesis matemática, el código ejecutable, las superficies de evaluación y las afirmaciones públicas deben madurar conjuntamente.

Los agentes actuales de Modelos de Lenguaje (LM) fallan en este régimen debido a dos modos de fallo específicos:

1. Acumulación de Alucinaciones: Afirmaciones sin apoyo o datos fabricados introducidos en un paso (por ejemplo, en un borrador de artículo) se tratan como verdad fundamental en pasos posteriores, propagando errores a través del bucle de desarrollo.
2. Desincronización: El código, la teoría o el modelo interno del mundo del LM se separan. Por ejemplo, el código puede optimizarse para una especificación desactualizada, o la representación interna del repositorio del LM puede volverse obsoleta a medida que se acumulan archivos, lo que lleva a una incoherencia global incluso si existe consistencia por pares.

Los marcos existentes (por ejemplo, SWE-agent, AI Scientist) asumen tareas fijas o marcos de evaluación fijos, lo que los hace inadecuados para la investigación donde el objetivo en sí mismo evoluciona.

2. Metodología: Comet-H

Los autores proponen Comet-H, un autómata de prompts iterativo diseñado para orquestar la evolución acoplada de la teoría, el código, la evidencia y las afirmaciones.

Arquitectura Central

Comet-H opera como una Máquina de Estados de Co-evolución que gestiona un espacio de trabajo $W$ compuesto por seis componentes:

• $T$ (Teoría): La tesis matemática mutable.
• $R$ (Repositorio): La implementación del código.
• $P$ (Proyección Pública): El artículo y el README.
• $E$ (Evidencia): Benchmarks y libros de contabilidad de fundamentación.
• $U$ (Hipótesis de Utilidad): El "por qué" del software.
• $Q$ (Obligaciones Abiertas): Una cola de afirmaciones no verificadas o tareas pendientes.

Mecanismos Clave

1. Disparadores Reactivos de Fundamentación:

   • Cualquier cambio en los artefactos de cara al público ($P$: artículo/README) desencadena inmediatamente una Creación de Fundamentación seguida de una Auditoría Escéptica.
   • Esto obliga al sistema a verificar las afirmaciones contra el código ejecutable y los benchmarks antes de que puedan propagarse, acotando la propagación de alucinaciones a un solo paso.

2. Restricciones de Adyacencia:

   • El controlador evita que el sistema se desvíe arbitrariamente. Cualquier expansión o giro debe ser "adyacente" al estado actual (alcanzable en un solo paso conceptual) y debe fortalecer los benchmarks o la teoría existentes. Esto evita que el modelo salte a problemas no relacionados que carecen de superficies de evaluación.

3. Selección de Prompts como un Bandido Contextual:

   • El controlador selecciona el siguiente prompt de un alfabeto fijo de 17 familias de prompts (por ejemplo, Ideación, Generación de Semillas, Fortalecimiento de Artículos, Auditoría Escéptica).
   • Puntuación: Un puntuador lineal transparente y establecido manualmente calcula una puntuación basada en un vector de características de déficits del espacio de trabajo (por ejemplo, "baja cobertura de pruebas", "afirmaciones no verificadas").
   • Decaimiento de Obligaciones: El trabajo de seguimiento sin terminar se almacena en un vector de obligaciones $o_t$ que decae exponencialmente (vida media de 8 pasos). Esto asegura que el controlador se centre en deudas recientes y de alta prioridad sin verse abrumado por una historia obsoleta, imitando estrategias de bandidos no estacionarios.

4. Fases del Bucle de Desarrollo:

   • Semilla: Selecciona una pregunta de investigación diferenciada y un núcleo formal.
   • Iteración Reactiva: Genera código/artículos y luego los endurece iterativamente basándose en la superficie más débil (por ejemplo, si los benchmarks son débiles, ejecuta Endurecimiento de Benchmarks).
   • Cola: Una secuencia fija de pasos de auditoría y pulido para asegurar que la salida final esté fundamentada, independientemente del presupuesto restante.

3. Contribuciones Clave

1. Definición de Modos de Fallo de Co-evolución: El artículo identifica formalmente la acumulación de alucinaciones y la desincronización como las causas principales de fallo en la investigación automatizada, distintas de los errores de codificación estándar.
2. Máquina de Estados de Co-evolución: Un marco formal (Definición 4.1) que trata la teoría como una variable de estado mutable y hace cumplir la sincronización entre artefactos mediante un modo de control finito y una memoria de obligaciones en decaimiento.
3. Orquestación Transparente: Un diseño novedoso de controlador que combina un puntuador lineal establecido manualmente con un registro desvanecido de trabajo sin terminar. Esto evita políticas aprendidas (cajas negras) en favor de una toma de decisiones auditable e interpretable.
4. Portafolio Empírico: La creación de 46 repositorios de software de investigación en más de 12 dominios, demostrando la escalabilidad del enfoque.

4. Resultados y Estudio de Caso (a3)

Los autores ofrecen un análisis profundo de a3, una herramienta de análisis estático en Python desarrollada enteramente dentro del bucle Comet-H.

• Rendimiento: En un benchmark de 90 casos, a3 logró una puntuación F1 de 0.768, superando significativamente al siguiente mejor baseline de 0.364.
• Ganancias Monótonas: Los estudios de ablación mostraron que cada capa añadida de acoplamiento teoría/práctica (por ejemplo, análisis interprocedimental, ejecución simbólica dinámica) mejoró el rendimiento sin degradación.
• Evolución de la Teoría: El sistema revisó con éxito su teoría subyacente dos veces durante el desarrollo (cambiando de un marco de "distancia al límite" a "certificados de seguridad" e integrando solucionadores SMT) sin romper la base de código, demostrando la capacidad del controlador para manejar giros en la especificación.
• Observaciones Conductuales:
  • Dominio de la Auditoría: En las fases posteriores del desarrollo, la mayoría de los commits fueron para fundamentar, auditar y reparar afirmaciones en lugar de añadir características.
  • Fallo Visible: El sistema aprendió a informar abiertamente sobre limitaciones (por ejemplo, veredictos "DESCONOCIDO" para casos recursivos) en lugar de ocultarlas, un comportamiento impulsado por el prompt de Auditoría Escéptica.
  • Auto-organización: A lo largo de horizontes largos, el LM reorganizó naturalmente el código en estructuras más composicionales (por ejemplo, convirtiendo a submódulos) sin prompts explícitos.

5. Significado

Este artículo cambia el paradigma de los agentes de investigación de IA de la completación de tareas (resolver un problema fijo) a la gestión de estados (mantener la integridad de un sistema en co-evolución).

• Gobernanza sobre Generación: Argumenta que la parte más difícil de la automatización de la investigación no es generar código, sino asegurar que la tesis matemática, el código y las afirmaciones permanezcan sincronizados.
• Nuevas Métricas de Evaluación: Sugiere que las futuras evaluaciones de agentes de investigación deberían medir la estabilidad, la recuperabilidad ante la deriva y la latencia de reparación de la integridad, en lugar de solo las puntuaciones finales de los benchmarks.
• Impacto Práctico: Al demostrar que los LM pueden gestionar el ciclo de vida completo del software de investigación, incluida la revisión teórica y la auditoría rigurosa, Comet-H proporciona un plano para construir sistemas de descubrimiento científico autónomos y confiables.

En resumen, Comet-H demuestra que al tratar la investigación como un proceso co-evolutivo con mecanismos explícitos para la fundamentación, la auditoría y la deriva acotada, los LM pueden navegar con éxito el camino complejo y no lineal de crear software de investigación novedoso.