El Patrón Protégé

Un modelo de 7 mil millones de parámetros resolvió el 42,4% de las tareas de SWE-bench Verified. El récord anterior para modelos pequeños era del 17,0%. El modelo no se volvió más inteligente. El modelo aprendió cuándo pedir ayuda.¹

Kon et al. entrenaron un modelo Qwen2.5-Coder-7B-Instruct para colaborar con un modelo de frontera como experto. El experto respondió aproximadamente cuatro preguntas por tarea, consumiendo el 11% del total de tokens.¹ El 89% restante de tokens provino del modelo pequeño ejecutando operaciones rutinarias: leer archivos, ejecutar pruebas, aplicar parches. El costo bajó de $0,54-$1,24 por instancia (solo experto) a $0,13-$0,15 (protégé con experto).¹ Una reducción de costos de 8,2x con una mejora de 25 puntos de rendimiento sobre el estado del arte previo para modelos pequeños.

El resultado valida un patrón hacia el que los profesionales han estado convergiendo de manera independiente: el patrón protégé.

Resumen

El patrón protégé divide el trabajo de agentes entre un modelo pequeño y económico (el protégé) que maneja la ejecución rutinaria y un modelo de frontera (el experto) que maneja las decisiones de criterio. SWE-Protege demostró una mejora de 25,4 puntos y una reducción de costos de 8,2x.¹ El propio sistema de investigación multiagente de Anthropic utiliza la misma división por niveles: Claude Opus para el agente líder, Claude Sonnet para los subagentes.³ El patrón funciona porque la mayor parte del trabajo de agentes es mecánico. Dirigir ese trabajo mecánico a un modelo 5 veces más barato por token recupera el 80% del presupuesto de costos sin sacrificar calidad en las decisiones que realmente importan.

El Marco Experto-Protégé

SWE-Protege define la relación con precisión.¹ El protégé es el único tomador de decisiones. El experto nunca inicia. El protégé elige cuándo escalar, qué pregunta hacer y cómo incorporar la respuesta. El aprendizaje por refuerzo entrena al protégé para optimizar dos objetivos en competencia: resolver la tarea Y minimizar el uso del experto.

La estructura de recompensa del RL penaliza tres modos de fallo:

Bucle degenerativo. El protégé hace la misma pregunta repetidamente. La penalización desalienta la indefensión aprendida.

Colaboración improductiva. El protégé hace una pregunta, ignora la respuesta y continúa con su plan original. La penalización desalienta la escalación performativa.

Dependencia excesiva. El protégé dirige cada decisión al experto. La penalización desalienta que el protégé se convierta en una capa de paso.

El resultado es un protégé que desarrolla un criterio genuino sobre sus propias limitaciones. El modelo de 7B aprendió a distinguir entre tareas que podía manejar solo (lectura de archivos, ejecución de pruebas, parches directos) y tareas que requerían intervención del experto (decisiones arquitectónicas, requisitos ambiguos, análisis de dependencias entre múltiples archivos).¹

Por Qué Funciona el Enrutamiento

La base académica del enrutamiento de modelos es anterior a SWE-Protege. RouteLLM demostró que el enrutamiento entre un modelo fuerte y un modelo débil logra hasta 3,66x de ahorro en costos manteniendo el 95% de la calidad del modelo fuerte.¹¹ El enrutador aprende qué consultas requieren capacidad de frontera y cuáles maneja igualmente bien un modelo más pequeño.

IBM Research encontró resultados similares con un método de enrutamiento “frugal”: llamar a modelos más pequeños y especializados secuencialmente hasta que uno produzca una respuesta con confianza.¹⁴ El enfoque logra hasta un 85% de reducción de costos en consultas directas.

La idea subyacente es distribucional. La mayoría de las operaciones de agentes no son difíciles. Leer un archivo, ejecutar un grep, aplicar un parche bien definido, ejecutar un conjunto de pruebas: estas operaciones requieren ejecución correcta, no razonamiento profundo. Un modelo 5 veces más barato por token las maneja de forma idéntica a un modelo de frontera.⁷ Las operaciones difíciles (diagnosticar un error sutil, elegir entre enfoques arquitectónicos, evaluar si una solución es correcta) se benefician del razonamiento de frontera. El patrón protégé dirige cada operación al nivel apropiado.

La propia documentación de Anthropic hace explícita la división por niveles. La guía “Choosing the Right Model” recomienda Haiku para “sub-agent tasks” y Opus para “professional software engineering” y “advanced agents”.⁸ La recomendación no es marketing. La recomendación refleja diferencias de rendimiento medidas a través de distribuciones de complejidad de tareas.

Implementaciones en Producción

Tres sistemas en producción demuestran el patrón protégé a escala.

El sistema de investigación multiagente de Anthropic. Claude Opus lidera, Claude Sonnet ejecuta como subagentes.³ El sistema superó al Claude Opus de agente único en un 90,2% en evaluación interna. La mejora no provino de un modelo mejor sino de una mejor descomposición de tareas. Los subagentes Sonnet consumieron la mayor parte de los tokens en operaciones de investigación mientras Opus concentraba el presupuesto de razonamiento en síntesis y criterio.

El compilador C de Carlini. Dieciséis agentes Claude en paralelo produjeron un compilador C basado en Rust de 100.000 líneas que arranca Linux 6.9.⁴ Costo: $20.000 en ~2.000 sesiones. Aunque todos los agentes operaron en el mismo nivel, el proyecto reveló la propiedad de autoorganización que el patrón protégé formaliza: los agentes naturalmente gravitaron hacia “el siguiente problema más obvio”.⁴ Ningún orquestador central asignó tareas.

Chris Lattner revisó el compilador e identificó el límite entre lo que los agentes de IA manejan bien y dónde el criterio humano sigue siendo esencial: “Reducir las barreras de implementación no reduce la importancia de los ingenieros; en cambio, eleva la importancia de la visión, el criterio y el gusto.”⁵⁶ Los agentes sobresalieron en ensamblar técnicas conocidas. Los agentes tuvieron dificultades con “la generalización abierta requerida para sistemas de calidad de producción.”⁵

Enrutamiento de modelos en la práctica. El estudio “What Claude Code Chooses” analizó 2.430 selecciones de herramientas a través de tres modelos Claude.⁹ Opus 4.6 mostró preferencias prospectivas (Drizzle 100% vs Prisma 0%), mientras que Sonnet 4.5 tomó decisiones más convencionales.⁹ La divergencia generó una discusión significativa en la comunidad.¹⁰ Los diferentes niveles aportan diferentes sesgos a las decisiones ambiguas. Un protégé que realiza selecciones rutinarias de herramientas no necesita razonamiento de frontera. Un protégé que se encuentra con una decisión arquitectónica ambigua se beneficia de la escalación.

Aritmética de Costos

La economía hace que el patrón sea convincente incluso antes de considerar las mejoras de rendimiento.

A los precios actuales de Anthropic, la diferencia entre niveles es exactamente 5x:⁷

Una sesión típica de agente consume entre 50.000 y 200.000 tokens en cada dirección. Asumiendo 100K tokens de entrada y 100K de salida a precios exclusivos de Opus, una sesión cuesta $0,50 de entrada + $2,50 de salida = $3,00. Si el protégé maneja el 80% de los tokens y el experto maneja el 20%, la misma sesión cuesta:

• Protégé (80K tokens): $0,08 entrada + $0,40 salida = $0,48
• Experto (20K tokens): $0,10 entrada + $0,50 salida = $0,60
• Total: $1,08 (64% de ahorro)

SWE-Protege logró ahorros aún más agresivos porque el experto consumió solo el 11% de los tokens, no el 20%.¹ A lo largo de 100 sesiones de agente por día, la diferencia se acumula: $300/día con solo experto versus $108/día con enrutamiento protégé. En un mes: $9.000 versus $3.240.

La tabla de clasificación de SWE-bench proporciona el contexto de rendimiento.¹² Claude 4.5 Opus con razonamiento alto alcanza una tasa de resolución del 76,8% a $0,754 por instancia. Un enfoque con enrutamiento protégé al 42,4% de tasa de resolución cuesta $0,13-$0,15 por instancia.¹ Para tareas dentro de la capacidad del protégé, el costo por tarea resuelta favorece el enrutamiento. Para tareas que requieren razonamiento de frontera, el experto permanece disponible bajo demanda.

El Fenómeno de la Colaboratividad

Wang et al. descubrieron una propiedad que explica por qué el patrón protégé produce mejores resultados que cualquiera de los modelos por separado.¹³ El artículo “Mixture-of-Agents” encontró que los modelos generan mejores respuestas cuando se les presentan resultados de otros modelos, incluso cuando esos otros modelos son menos capaces.¹³

El hallazgo invierte la jerarquía esperada. Un modelo de frontera que lee el análisis inicial y las lecturas de archivos de un modelo pequeño produce mejor resultado que el modelo de frontera partiendo de cero. El trabajo del modelo pequeño no es solo mano de obra barata descargada del experto. El trabajo del modelo pequeño proporciona contexto estructurado que mejora el razonamiento del experto.

La investigación multiagente de Anthropic confirmó el patrón: actualizar los subagentes de Sonnet 3.7 a Sonnet 4 produjo “una ganancia de rendimiento mayor que duplicar el presupuesto de tokens con Claude Sonnet 3.7.”³ La calidad del modelo en el nivel protégé importa. Un mejor protégé produce un mejor experto.

Lo Que Puede Construir

Tres patrones de escalación se corresponden con implementaciones progresivamente más autónomas.

Patrón 1: Enrutamiento basado en confianza. La implementación más simple. El protégé genera una respuesta y una puntuación de confianza. Por debajo de un umbral, la consulta se dirige al experto. RouteLLM proporciona un marco de código abierto para entrenar el enrutador.¹¹ Comience aquí.

Patrón 2: Enrutamiento por tipo de tarea. Clasifique las operaciones por tipo y enrute de forma determinista. Lectura de archivos, ejecución de pruebas y formateo a Haiku. Revisión de código, decisiones de arquitectura y requisitos ambiguos a Opus. La guía “Building Effective Agents” de Anthropic llama a esto el patrón de enrutamiento: “clasificar entradas y dirigir preguntas fáciles/comunes a modelos más pequeños y eficientes en costo.”²

Patrón 3: Escalación aprendida. El enfoque de SWE-Protege. Entrene al protégé para decidir sus propios puntos de escalación mediante aprendizaje por refuerzo.¹ El protégé desarrolla un criterio genuino sobre sus limitaciones. El patrón más sofisticado y de mayor rendimiento, pero requiere infraestructura de RL y datos de entrenamiento etiquetados por expertos.

Cada patrón intercambia complejidad de implementación por ahorro en costos y autonomía. El Patrón 1 requiere un conjunto de datos de calibración de confianza. El Patrón 2 requiere una taxonomía de tareas. El Patrón 3 requiere ejecuciones de entrenamiento de RL. Los tres superan el despliegue de un solo nivel en rendimiento ajustado por costo.

Conclusiones Clave

• El patrón protégé no es balanceo de carga. El protégé toma decisiones sobre sus propias limitaciones. El experto proporciona criterio, no capacidad de procesamiento.
• La mayor parte del trabajo de agentes es mecánico. Dirigir ese trabajo a un modelo 5 veces más barato recupera el presupuesto de costos para las decisiones que requieren razonamiento de frontera.
• Mejores protégés producen mejores expertos. El fenómeno de colaboratividad significa que los resultados de modelos pequeños mejoran el razonamiento de modelos de frontera.¹³
• La observación de Lattner se aplica al patrón mismo: “A medida que escribir código se vuelve más fácil, diseñar software se vuelve más importante que nunca.”⁵ El protégé maneja la escritura más fácil. El experto maneja el diseño más difícil.

Parte de la serie AI Engineering. Véase también: El Contexto Es la Nueva Memoria, Claude Code como Infraestructura, y La Pared del 10%.