Resumen Técnico: Evoflux

Planteamiento del Problema

El artículo aborda las limitaciones de los modelos de lenguaje compactos (1.5B–4B de parámetros) cuando se despliegan como agentes de uso de herramientas en entornos dinámicos y en vivo como el Protocolo de Contexto de Modelo (MCP). Aunque los modelos compactos ofrecen ventajas en costo, latencia y privacidad, son frágiles al construir flujos de trabajo ejecutables. Los planificadores pequeños suelen generar grafos que parecen plausibles textualmente, pero que fallan durante la resolución de herramientas, la validación de parámetros, el seguimiento de dependencias o la ejecución.

Los autores argumentan que los enfoques estándar de destilación (Ajuste Fino Supervisado o SFT, y Optimización de Preferencia Directa o DPO) son insuficientes en este régimen. Entrenar con un presupuesto escaso de trazas de profesor (unos pocos cientos) enseña formatos de flujo de trabajo superficiales, pero no logra capturar los comportamientos de recuperación necesarios para reparar planes cuando los catálogos de herramientas cambian o la ejecución falla. Además, el olvido catastrófico en el ajuste de instrucciones continuo y estrecho plantea riesgos para los modelos compactos. La pregunta central es si se debe gastar cómputo en actualizaciones de pesos (entrenamiento) o en la reparación en tiempo de inferencia (búsqueda) dado el mismo presupuesto de supervisión escasa.

Metodología: Evoflux

Los autores presentan Evoflux, un procedimiento de búsqueda evolutiva en tiempo de inferencia diseñado para tratar el uso de herramientas compacto como un problema de reparación de flujo de trabajo ejecutable, en lugar de una tarea de generación de un solo paso.

Mecanismo Central

Evoflux opera como un bucle evolutivo acotado donde el modelo compacto actúa como un operador de propuesta dentro de un ciclo de reparación, en lugar de un generador estático.

1. Representación: Los planes se representan como grafos de flujo de trabajo tipados que contienen nodos de herramientas, aristas de dependencia, nodos validadores y salidas terminales.
2. Calificación Basada en Ejecución: Los candidatos no se califican solo por su validez sintáctica. Se compilan, se validan contra los esquemas de las herramientas y se ejecutan en un entorno vivo ($E$). Se deriva una puntuación escalar de un juez de LLM (MCP-Bench LLMJUDGE) basada en seis dimensiones subsidiarias: cumplimiento de la tarea, fundamentación, idoneidad de la herramienta, precisión de los parámetros, conciencia de las dependencias y paralelismo/eficiencia.
3. Bucle Evolutivo:
   • Inicialización: El planificador intenta generar un flujo de trabajo factible mediante reintentos, utilizando los errores de ejecución como contexto para intentos posteriores.
   • Mutación y Edición: El sistema evoluciona la población de grafos candidatos a través de un lenguaje de edición tipado finito que refleja modos de falla comunes:
     • Intercambio de Herramientas (Tool Swaps): Reemplazar herramientas no disponibles.
     • Edición de Parámetros: Corregir errores de esquema o vincular argumentos a salidas ascendentes (upstream).
     • Inserción/Eliminación: Añadir pasos de recolección de evidencia o eliminar pasos redundantes.
     • Reordenamiento: Corregir estructuras de dependencia.
   • Intensidad Adaptativa: Una estadística de crecimiento ($G$) rastrea el progreso reciente. Si el progreso se estanca, la intensidad de la búsqueda aumenta, activando mutaciones más exploratorias (ediciones aleatorias) y potencialmente Guía Meta (Meta Guidance).
   • Guía Meta: Cuando la mutación local se estanca, el planificador es instado a realizar un rediseño de alto nivel (por ejemplo, reemplazar un camino de un solo servidor por un flujo de trabajo entre múltiples servidores) utilizando el mejor candidato actual y los miembros más débiles de la población como contexto.
   • Poda de Diversidad: La población se limita ($K$) y se poda mediante el agrupamiento por hash de acciones (action-hash binning) para evitar el colapso en flujos de trabajo casi duplicados mientras se preservan las variantes de alta puntuación.

Líneas Base de Entrenamiento

Para evaluar el compromiso (trade-off), los autores comparan Evoflux contra:

• Decodificación Zero-shot.
• Ajuste Fino Supervisado (SFT) sobre trazas de profesor extraídas de la búsqueda.
• SFT + Optimización de Preferencia Directa (DPO) utilizando preferencias de pares de los mismos datos de búsqueda.
• ReAct: Una línea base de razonamiento y acción secuencial.

Todas las líneas base de entrenamiento utilizan el mismo presupuesto limitado de trazas extraídas de la búsqueda para asegurar una comparación justa entre las actualizaciones de pesos y la búsqueda en tiempo de inferencia.

Resultados Clave

La evaluación se realizó en tareas de retención (held-out) de MCP-Bench, que abarca 28 servidores MCP en vivo y 250 herramientas en diversos dominios.

1. Factibilidad de Ejecución: Evoflux mejora significativamente la factibilidad de ejecución para planificadores compactos. En tareas de retención, la factibilidad aumentó de un promedio de aproximadamente 3% en la línea base a un 17–24% en modelos como Llama-3.2-3B, Qwen3.5-4B y SmolLM3-3B.
2. Fracaso del Entrenamiento con Corpus Pequeño: En contraste con Evoflux, el SFT y el SFT+DPO sobre los mismos datos de búsqueda no proporcionaron mejoras fiables. En varios casos, los puntos de control entrenados igualaron o incluso tuvieron un rendimiento inferior a la línea base zero-shot. Notablemente, el modelo Qwen3.5-4B entrenado con SFT+DPO sufrió un "colapso de planificación", fallando al emitir planes utilizables y recurriendo a heurísticas, lo que resultó en una factibilidad menor que la del modelo sin entrenar (zero-shot).
3. Comparación con ReAct: ReAct logró un mayor rendimiento pico en planificadores más fuertes (ej. Qwen3.5-4B), pero exhibió una mayor varianza y costos de tokens significativamente más altos debido a la acumulación de contexto en trayectorias largas. Evoflux proporcionó mejoras más estables y predecibles con un presupuesto de tokens menor.
4. Eficiencia de Tokens: Aunque Evoflux incurre en mayores costos de tokens que la inferencia de un solo paso (SFT/Zero-shot), es más eficiente en tokens que ReAct. El proceso de búsqueda concentra los costos en los tokens de prompt para la evaluación de candidatos, mientras que los costos de ReAct escalan rápidamente con la longitud de la trayectoria.

Significado y Reivindicaciones

El artículo sostiene que, para agentes compactos que operan bajo presupuestos escasos de trazas de profesor, la búsqueda basada en la ejecución es un apalancamiento más fiable para mejorar el rendimiento que las actualizaciones de pesos.

• Reparación sobre Imitación: Los resultados sugieren que el ajuste fino con corpus pequeños a menudo conduce a una imitación superficial de las formas de flujo de trabajo sin interiorizar los procesos de reparación adaptativos necesarios para una ejecución robusta.
• Cómputo en Tiempo de Inferencia: Gastar cómputo en línea para reparar, mutar y validar flujos de trabajo contra catálogos de herramientas en vivo produce una mejor generalización a tareas no vistas que intentar destilar esos comportamientos de reparación en los pesos del modelo con datos limitados.
• Mitigación de Riesgos: El estudio destaca un riesgo específico en el despliegue de agentes compactos: entrenar con conjuntos de datos pequeños extraídos de la búsqueda puede degradar el rendimiento (colapsar por debajo del nivel zero-shot) en lugar de mejorarlo, haciendo que la evolución en tiempo de inferencia sea una estrategia más segura y efectiva para asegurar la fiabilidad ejecutable.

Los autores concluyen que, si bien la destilación a gran escala puede seguir siendo viable con conjuntos de datos masivos, el régimen actual de trazas escasas favorece la búsqueda evolutiva en tiempo de inferencia para la construcción de flujos de trabajo de herramientas fiables y ejecutables.