Resumen Técnico: Agentes ReAct con Estado para la Experimentación Autónoma Eficiente en Tokens

Declaración del Problelema

El patrón "autoresearch" permite la experimentación autónoma mediante un Modelo de Lenguaje Extenso (LLM) que modifica iterativamente el código para optimizar una métrica objetivo. Aunque es efectivo, la implementación estándar es sin estado (stateless): en cada iteración, el agente debe reconstruir todo el contexto experimental releyendo el historial completo de resultados y modificaciones de código acumulados en un archivo de directiva de investigación (por ejemplo, program.md).

Este diseño incurre en una ineficiencia estructural:

• Costo de Tokens: El tamaño del prompt crece linealmente ($O(n)$) con el número de iteraciones, lo que conduce a un costo total de tokens de $O(n^2)$.
• Redundancia: El agente retransmite información que ya ha procesado en pasos previos.
• Escalabilidad: A medida que los experimentos se acumulan, el prompt se acerca a los límites de la ventana de contexto, lo que requiere truncamiento o resumen, lo cual conlleva el riesgo de perder matices experimentales críticos.

El artículo postula que, debido a que los LLM no pueden mantener un estado transitorio entre interacciones (Huang et al. [10]), la gestión de un estado externo es una necesidad arquitectónica para romper esta curva de costo cuadrática.

Metodología

Los autores reformulan el patrón de autoresearch como un agente ReAct con estado (stateful) utilizando LangGraph. En lugar de prompts monolíticos que contienen el historial completo, el agente interactúa con el sistema de ML mediante llamadas a herramientas (tool calls), mientras que el historial experimental, los rastros de razonamiento y las métricas de convergencia persisten en un grafo de estado persistente tipado.

Arquitectura

El agente opera como un grafo de estado con tres nodos principales:

1. REASON (Razonamiento): Invoca al LLM (Claude Haiku 4.5) con el contexto del estado actual. El modelo genera rastros de razonamiento y llamadas a herramientas.
2. TOOLS (Herramientas): Ejecuta llamadas a herramientas de forma determinista (por ejemplo, ejecutar experimentos, consultar resultados) y devuelve observaciones.
3. CHECK (Verificación): Evalúa los criterios de convergencia (umbral de métrica objetivo, presupuesto de iteraciones o conclusión del LLM) sin la intervención del LLM.

Las aristas condicionales dirigen el flujo: si el LLM produce llamadas a herramientas, el control pasa a TOOLS; de lo contrario, procede a CHECK. Si no hay convergencia, el bucle regresa a REASON.

Gestión de Estado

La innovación central es el AgentState (un diccionario tipado) que persiste a través de las iteraciones. Incluye:

• messages: Una ventana deslizante de los últimos 20 mensajes para limitar el costo de entrada.
• experiment_history: Una lista de todos los resultados pasados.
• current_best: El mejor resultado encontrado hasta el momento.
• train_py_content: El estado actual del código.

Crucialmente, el agente utiliza una clase auxiliar (ExperimentState o CodeState) para generar un resumen compacto para el LLM en cada paso. Este resumen incluye:

• Conteo de iteraciones actuales y mejores métricas agregadas.
• Los últimos 5 experimentos (o resultados recientes).
• Notas de estrategia y enfoques fallidos.

Esto asegura que el LLM reciba solo $O(1)$ tokens de entrada por iteración, independientemente del número total de experimentos realizados. El historial completo permanece accesible en el estado, pero se excluye del prompt a menos que se consulte explícitamente mediante herramientas.

Herramientas (Tooling)

El agente interactúa con el sistema de ML a través de herramientas específicas:

• Ajuste de Hiperparámetros: get_experiment_history y run_experiment.
• Optimización de Código: get_current_train_py, modify_train_py (con salvaguardas para preservar la lógica de evaluación), submit_training_job y query_results.

Contribuciones Clave

1. Reformulación Arquitectónica: Transformar el patrón de autoresearch sin estado en un agente ReAct con estado usando LangGraph, desacoplando la memoria de trabajo del agente de su contexto de prompt.
2. Eficiencia de Tokens: Demostrar una reducción estructural en el costo de tokens de $O(n^2)$ (sin estado) a $O(n)$ (con estado) en total, con un costo de $O(1)$ por iteración.
3. Plano de Implementación: Proporcionar una arquitectura detallada y reproducible (incluyendo esquemas de estado, lógica de grafo y definiciones de herramientas) para que los profesionales implementen agentes con estado.

Resultados Experimentales

Los autores evaluaron el agente con estado frente a un baseline sin estado en dos tareas de benchmark utilizando 3 semillas aleatorias.

Tarea 1: Ajuste de Hiperparámetros (Observaciones Pequeñas)

• Configuración: 15 iteraciones optimizando XGBoost en el conjunto de datos UCI Covertype. Las observaciones eran pequeñas (~200 tokens: configuración JSON + métricas).
• Resultados:
  • Reducción de Tokens: El agente con estado consumió 90% menos tokens (2,492 vs. 24,465), una reducción de 9.8×.
  • Desempeño: Ambos agentes lograron puntuaciones F1 comparables (0.779 vs. 0.764), con diferencias atribuidas a la varianza de la semilla más que a una superioridad arquitectónica.
  • Curva de Costo: El costo de entrada del agente sin estado creció linealmente de ~700 a ~1,900 tokens por iteración; el costo del agente con estado se mantuvo plano en ~100 tokens.

Tarea 2: Optimización de Desempeño de Código (Observaciones Grandes)

• Configuración: 40 iteraciones optimizando una función de procesamiento de datos en Python. Las observaciones eran grandes (~1,500–3,000 tokens: código fuente completo + benchmarks).
• Resultados:
  • Reducción de Tokens: El agente con estado consumió 52% menos tokens (627K vs. 1,275K), una reducción de 2.0×.
  • Desempeño: Ambos agentes lograron aceleraciones comparables (~1.9× sobre el baseline).
  • Curva de Costo: Aunque el agente con estado aún incurría en un costo fijo para enviar el "mejor código actual" (~1,500 tokens) en cada paso, el costo total se estabilizó. En contraste, el costo del agente sin estado continuó aumentando linealmente, acumulando más de 80,000 tokens de historial hacia la iteración 40.

Análisis Comparativo

La ratio de reducción de tokens es inversamente proporcional al tamaño de la observación respecto al resumen de estado.

• Observaciones Pequeñas: El resumen de tamaño fijo es drásticamente más pequeño que el historial acumulado, lo que genera ratios de reducción altos (9.8×).
• Observaciones Grandes: El agente con estado aún debe transmitir el artefacto de código actual, lo que limita la ratio (2.0×). Sin embargo, el artículo señala que a medida que las iteraciones aumentan (por ejemplo, a 100 o 200), la divergencia de $O(n^2)$ vs. $O(n)$ hará que la ratio se amplíe significativamente (proyectado de 4× a 7×).

Significancia y Reivindicaciones

El artículo sostiene que la contribución principal es la eficiencia estructural, no necesariamente una mejora en la calidad de la optimización. El agente con estado logra un desempeño de optimización comparable al baseline sin estado mientras reduce drásticamente el consumo de tokens.

• Escalabilidad: El costo de $O(1)$ por iteración permite secuencias de experimentación arbitrariamente largas sin truncamiento de prompts ni pérdida de capacidad de toma de decisiones.
• Impacto Económico: Aunque los ahorros son modestos para ejecuciones cortas, se vuelven materiales para la investigación a gran escala (cientos de experimentos diarios), donde el costo cuadrático de la ejecución sin estado se convierte en un cuello de botella dominante.
• Perspectiva Futura: Los autores sugieren que, a medida que los horizontes de experimentación se alarguen, el costo de tokens cuadrático de la ejecución sin estado será la restricción principal, haciendo que las arquitecturas con estado sean esenciales para una experimentación autónoma sostenible.

Los autores mantienen la modestia respecto a la calidad de la optimización, declarando explícitamente que las diferencias observadas en las métricas están dentro del ruido y no deben interpretarse como una ventaja de calidad del enfoque con estado. El enfoque permanece estrictamente en las ganancias de eficiencia derivadas del cambio arquitectónico.