Resumen Técnico: Agente-como-Enrutador

1. Declaración del Problema

Los usuarios del mundo real suelen tener acceso a múltiples Modelos de Lenguaje Extensos (LLMs) de diferentes proveedores, cada uno de los cuales destaca en dominios distintos (por ejemplo, diseño de algoritmos, ciencia de datos o completado de código), pero ninguno domina todas las tareas. Los agentes de codificación actuales suelen depender de un único LLM fijo para todas las tareas, un diseño que prioriza la predictibilidad por parte del proveedor sobre la eficiencia de costos centrada en el usuario y la calidad a nivel de tarea.

El problema central es el enrutamiento automático de modelos: determinar qué modelo debe manejar cada tarea de codificación entrante para maximizar el rendimiento minimizando el costo. Los métodos de enrutamiento existentes tratan esto como un problema de clasificación estático y de una sola vez, empleando a menudo modelos de lenguaje como políticas de enrutamiento. Sin embargo, experimentos preliminares revelan una brecha de rendimiento significativa entre estos enrutadores estáticos y un "oráculo por tarea" (que conoce el mejor modelo para cada tarea específica). El artículo identifica que el cuello de botella para los enrutadores existentes no es la falta de capacidad de razonamiento, sino un déficit de información: los enrutadores estáticos no logran acumular experiencia basada en la ejecución durante el despliegue.

2. Metodología

2.1. Diagnóstico: Déficit de Información

Los autores realizaron un estudio de ablación utilizando un enrutador LLM zero-shot (impulsado por Claude Sonnet 4.6).

• Enrutador Vanilla: Obtuvo un 41.41% de AvgPerf.
• +Estadísticas de Rendimiento: Cuando se le proporcionaron estadísticas de rendimiento previas de un conjunto de sondeo (probing set) mantenido fuera del entrenamiento, la puntuación aumentó a 47.74% (+15.3% de ganancia relativa), superando incluso al mejor enrutador heurístico (47.50%) que codificaba los mismos priors estáticos.
• Conclusión: La limitación principal es la falta de información dinámica basada en la ejecución, no la capacidad de razonamiento del modelo de enrutamiento en sí.

2.2. El Marco de Trabajo Agente-como-Enrutador

Para abordar el déficit de información, los autores proponen Agente-como-Enrutador, un marco que formaliza el enrutamiento como un bucle de Contexto-Acción-Retroalimentación (C-A-F). A diferencia de los enrutadores estáticos, este marco evoluciona a través de un flujo de tareas:

1. Contexto ($c_i$): El enrutador observa el prompt de la tarea, los metadatos y el historial acumulado (Memoria) de bucles anteriores.
2. Acción ($a_i$): El enrutador selecciona un modelo del grupo de candidatos.
3. Retroalimentación ($f_i$): La salida del modelo seleccionado se ejecuta en un sandbox, y un verificador genera una puntuación y un costo.
4. Actualización: La retroalimentación se memoriza y se fusiona en el contexto para la siguiente tarea ($c_{i+1}$).

Esta formulación se relaciona con un problema de bandido multibrazo contextual, donde la métrica natural de evaluación es el arrepentimiento acumulado (la brecha acumulada entre el rendimiento del enrutador y el oráculo por tarea).

2.3. Instanciación ACRouter

El marco se instancia como ACRouter, que comprende tres módulos principales:

• Orquestador: Toma decisiones de enrutamiento integrando el prior DimensionBest, los 10 vecinos históricos superiores (recuperados mediante kNN de coseno desde la Memoria) y metadatos de la tarea. Utiliza un modelo Qwen3.5-0.8B ligero y ajustado (fine-tuned) combinado con reglas heurísticas mediante votación ponderada.
• Verificador: Evalúa las salidas de los modelos en un entorno de sandbox. Agrega señales (análisis AST, resultados de ejecución, LLM-as-Judge) en una puntuación de rendimiento unificada ($u_i \in [0, 1]$).
• Memoria: Un almacén vectorial en línea indexado por embeddings de tareas. Registra el modelo elegido, el rendimiento, el costo y los rastreos de verificación. Utiliza un almacén limitado por FIFO (20K entradas) para permitir una recuperación detallada y sensible al contexto de éxitos y fallos pasados.

2.4. CodeRouterBench

Para evaluar el enrutamiento en tareas de flujo continuo, los autores introducen CodeRouterBench, un benchmark que comprende:

• ~10,000 tareas a través de 10 dimensiones de codificación (9 tareas de un solo turno dentro de la distribución y 1 dimensión de programación agéntica fuera de la distribución).
• 8 LLMs de frontera (incluyendo Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5, etc.).
• Puntuaciones Verificadas por Ejecución: Las tareas se califican mediante ejecución en sandbox o LLM-as-Judge, proporcionando una matriz de observación de verdad fundamental para la comparación basada en arrepentimiento.

3. Contribuciones Clave

1. Marco de Trabajo: La propuesta de Agente-como-Enrutador, que formaliza el enrutamiento de modelos como un bucle C-A-F, permitiendo que los enrutadores cierren activamente la brecha de información mediante retroalimentación basada en la ejecución.
2. Artefactos:
   • ACRouter: Una instanciación concreta del marco con módulos de Orquestador, Verificador y Memoria.
   • CodeRouterBench: Un entorno de evaluación estandarizado (~10K tareas, 8 LLMs) diseñado específicamente para la comparación de enrutadores basada en arrepentimiento en tareas de flujo continuo, incluyendo un banco de pruebas de programación agéntica OOD (fuera de distribución).
3. Hallazgos:
   • Déficit de Información: El cuello de botella del enrutamiento es el acceso a la información, no el razonamiento. Proporcionar estadísticas de rendimiento genera una ganancia relativa del 15.3%.
   • Rendimiento: ACRouter logra el menor arrepentimiento acumulado en tareas dentro de la distribución (ID) y se generaliza eficazmente a tareas de programación agéntica fuera de la distribución (OOD).
   • Limitaciones Estáticas: Los enrutadores estáticos ligeros (clasificadores entrenados, heurísticas) funcionan razonablemente en tareas ID, pero fallan significativamente en tareas OOD, donde ACRouter mantiene un fuerte rendimiento.

4. Resultados Experimentales

Los experimentos se realizaron tanto en flujos de tareas dentro de la distribución (ID) como fuera de la distribución (OOD).

• Rendimiento en la Distribución (In-Distribution):

  • ACRouter logró el mayor rendimiento promedio (49.98%) y el menor arrepentimiento acumulado (205.5), superando al heurístico "DimensionBest" (47.50%) y a todas las líneas base de políticas entrenadas.
  • También demostró una mayor eficiencia de costos (relación Perf/$ de 3.79) en comparación con usar siempre el modelo más fuerte (Always-Opus 4.6, que tuvo una relación de 1.29).

• Generalización Fuera de la Distribución (OOD):

  • En el banco de pruebas de programación agéntica (176 tareas), ACRouter alcanzó un 62.50% de AvgPerf, superando significativamente a la línea base Always-Opus (57.14%) y a todos los demás enrutadores.
  • Los clasificadores estáticos (ej. LogReg, RouteLLM-BERT) colapsaron en tareas OOD, con un rendimiento que cayó al 8.93%–21.43%, incluso por debajo de la selección aleatoria.
  • La capacidad de ACRouter para acumular experiencia verificada durante el flujo le permitió adaptarse a la nueva distribución de tareas, mientras que los métodos estáticos que dependen de priors congelados fallaron en generalizar.

• Análisis de Costos:

  • Aunque ACRouter incurre en gastos de gestión para los módulos de Memoria y Verificador, sigue siendo más rentable que seleccionar siempre el modelo más caro (Opus 4.6) al tiempo que ofrece una mayor calidad.
  • La estrategia "Always-Kimi-K2.5" ofreció la mayor eficiencia de costos (Perf/$ 12.62) pero con un costo sustancial en el rendimiento absoluto (36.66% AvgPerf).

5. Significado y Reivindicaciones

El artículo afirma que cerrar activamente la brecha de información mediante retroalimentación basada en la ejecución es un principio general para construir sistemas agénticos que deben enrutar entre herramientas o modelos heterogéneos.

• Cambio de Paradigma: El trabajo mueve el enrutamiento de un problema de clasificación estática a un proceso dinámico y autoadaptativo (bucle C-A-F).
• Utilidad Práctica: Demuestra que los usuarios pueden lograr un rendimiento cercano al oráculo y eficiencia de costos mediante el enrutamiento dinámico de tareas, en lugar de depender de un único "mejor" modelo.
• Generalizabilidad: El bucle C-A-F se presenta no solo como un mecanismo de enrutamiento, sino como un paradigma de toma de decisiones más amplio aplicable a la selección de herramientas, la selección de endpoints de API y la asignación de esfuerzos.
• Modestia: Los autores reconocen limitaciones, como la incapacidad de observar las tasas de acierto de caché del lado del proveedor (lo que hace que las estimaciones de costo sean relativas en lugar de absolutas) y el uso de un límite de pasos reducido para tareas OOD para mantener la tractabilidad del presupuesto. Observan que, aunque su instanciación actual utiliza una política de LLM con memoria kNN, aún quedan por explorar otras técnicas de memoria a nivel de parámetros.

En resumen, el artículo sostiene que, para los sistemas de codificación agéntica, el futuro no reside en encontrar un único modelo dominante, sino en construir enrutadores adaptativos que aprendan de la retroalimentación de la ejecución para seleccionar la herramienta adecuada para el trabajo adecuado.