Orquestación de modelos: cómo los sistemas de IA eligen y combinan modelos

Regla de oro: No orquestes modelos porque suene sofisticado. Hazlo cuando distintos tipos de trabajo tengan requisitos claramente diferentes y puedas medir cuándo basta la vía barata, cuándo debe entregar la tarea a una vía más potente y cuándo debe detenerse el sistema.

Qué es y qué no es

La orquestación de modelos es la capa operativa que elige el modelo, la configuración y el siguiente paso para cada parte de una tarea. Puede decidir entre un modelo pequeño y rápido, un modelo frontera más caro, un modelo local o código determinista. Impone límites de presupuesto y latencia y controla la sensibilidad de los datos, la calidad del resultado y la respuesta ante fallos.

No es otro nombre para un sistema multiagente. Un flujo fijo puede utilizar tres modelos y seguir siendo un flujo fijo. Tampoco es un proxy universal que se limita a cambiar nombres de endpoints. Los modelos difieren en el uso de herramientas, los límites de contexto, la salida estructurada, el comportamiento de seguridad y los modos de fallo. Y no es una razón para repartir un prompt sencillo entre cinco modelos.

Empieza con una referencia basada en un único modelo bien elegido. Añade orquestación solo cuando los registros muestren un problema concreto: las tareas rutinarias cuestan demasiado, una clase de tareas funciona mal, ciertos datos deben permanecer en local o hace falta una comprobación independiente.

Árbol de decisión para el routing

Un router no tiene por qué empezar siendo otro LLM. La primera versión suele entenderse mejor como un pequeño conjunto de reglas:

¿La tarea es determinista?
├─ sí → código, SQL, búsqueda o un validador sin LLM
└─ no
   ¿Los datos deben permanecer en una región o dispositivo?
   ├─ sí → modelo local o aprobado para esa región
   └─ no
      ¿El resultado es irreversible o de alto riesgo?
      ├─ sí → modelo más potente + verificación + quizá una persona
      └─ no
         ¿El modelo barato supera las evaluaciones de esta clase?
         ├─ sí → modelo barato
         └─ no → modelo más potente

Después de cada paso:
- error de esquema o herramienta → reparar una vez y luego transferir
- baja confianza verificable → retrieval, modelo más potente o persona
- timeout o caída del proveedor → vía de respaldo compatible
- problema de seguridad → detenerse, no improvisar

Las señales de routing deben estar disponibles antes de llamar al modelo caro: tipo de solicitud, idioma, tamaño de entrada, origen de los datos, herramientas necesarias, tenant, SLA y nivel de riesgo. La autoevaluación del modelo puede ser una señal, pero no la única prueba. Un modelo puede aprobar su propio error con total seguridad.

Un plano práctico de arquitectura

Una arquitectura útil tiene pocas capas, todas explícitas:

1. Normalización de entrada elimina datos innecesarios, asigna el tenant y crea un identificador de ejecución.
2. Puerta de políticas determina proveedores y regiones permitidos, clasificación de datos, gasto máximo y acciones que requieren aprobación.
3. Router elige una vía mediante reglas versionadas o un clasificador y devuelve el motivo de la decisión.
4. Adaptador de modelo traduce el formato interno de mensajes, herramientas y salida estructurada a la API del proveedor.
5. Ejecutor lanza modelos y herramientas con timeout, límite de pasos y clave de idempotencia.
6. Verificador comprueba el esquema, las citas, las reglas de negocio u otro resultado verificable por máquina.
7. Controlador de transferencias decide entre reparar, escalar, cambiar de modelo, pedir revisión humana o detenerse.
8. Observabilidad y almacén de evaluaciones registran la versión del prompt, el modelo, el motivo del routing, latencia, coste, resultado de la verificación y estado final.

La lógica de dominio no debería conocer nombres de proveedores. Un contrato interno compacto puede contener task, risk, data_class, allowed_tools, output_schema y budget. Los adaptadores resuelven las diferencias. Sin embargo, la abstracción no debe reducirlo todo al mínimo común denominador. Si una capacidad propia de un modelo mejora el resultado de forma medible, exponla mediante una bandera explícita y conserva una vía alternativa.

Transferencias y fallbacks sin caos silencioso

Una transferencia envía el trabajo a otra vía por una razón sustantiva: la entrada resultó más difícil, falló la verificación o se necesita otra capacidad. Transfiere estado estructurado, no toda la conversación sin procesar. El siguiente modelo necesita el objetivo original, hechos verificados, resultados de herramientas, fallos anteriores y presupuesto restante.

Un fallback resuelve una indisponibilidad o un modo de fallo conocido. El orden debe definirse de antemano. Por ejemplo: repetir el mismo modelo solo ante un error temporal de red; reparar la salida tras una infracción del esquema; usar un modelo más potente tras fallar una comprobación factual; cambiar de proveedor durante una caída; recurrir a una persona para una acción irreversible. Una cadena infinita de reintentos no es resiliencia. Es una factura oculta.

Cada transición debe conservar la política de seguridad. El modelo de respaldo no puede recibir datos que el principal tenía prohibido recibir por requisitos de localización. Un fallback tampoco puede convertir «requiere aprobación» en «inténtalo automáticamente».

Evaluaciones y coste por éxito

El precio por millón de tokens es un dato de compra, no una métrica del sistema. La medida útil es el coste por tarea completada con éxito:

coste total + retrieval + herramientas + verificación + corrección humana
───────────────────────────────────────────────────────────────────────
número de tareas que superaron el criterio de éxito definido

El conjunto de evaluación debe incluir clases de trabajo reales, casos límite, entradas largas, varios idiomas y escenarios de seguridad. Para cada vía, mide tasa de éxito, latencia, intentos, frecuencia de transferencias, intervención humana y tipos de error. Compara el orquestador con una referencia de un solo modelo. Un router optimizado solo por coste aprende a fallar barato; uno optimizado solo por calidad media envía todo al modelo frontera.

Cambia una decisión de routing cada vez y repite el mismo conjunto. Vigila producción por separado, porque un cambio en la mezcla de solicitudes puede invalidar una política antigua. Los benchmarks públicos no demuestran nada sobre tu producto. Importa el rendimiento en tus tareas y según tu definición de éxito.

Seguridad y localización de datos

El router es infraestructura sensible. Ve los metadatos empleados para decidir adónde van los datos. Por eso la clasificación debe ocurrir antes de seleccionar proveedor y una capa de políticas debe imponerla; no basta con escribirla en el prompt.

Para cada modelo registra regiones aprobadas, condiciones de retención, política de uso para entrenamiento, cifrado disponible, funciones de auditoría y herramientas permitidas. Minimiza o elimina datos personales y secretos antes de cualquier llamada. Los logs no deben recrear una fuga guardando el prompt completo. Mantén las credenciales de herramientas fuera del contexto y autoriza cada herramienta para la ejecución concreta.

Un modelo local no es seguro por definición, ni uno en la nube es inseguro por definición. Importa el recorrido completo: dónde se ejecuta la inferencia, adónde va la telemetría, qué queda en caché, quién accede a los logs y si las acciones pueden auditarse.

Fallos habituales

• Routing por intuición: las tareas «difíciles» no tienen definición. Solución: taxonomía, evaluaciones y política versionada.
• Modelo frontera para todo: se supone que la calidad prémium aporta valor incluso donde no cambia nada. Solución: referencia más barata y coste por éxito.
• Modelo más barato para todo: el ahorro desaparece en reintentos y correcciones humanas. Solución: contar la ejecución completa.
• Fallback silencioso: un incidente parece un éxito. Solución: registrar motivo, recorrido y estado final, y mostrar la degradación.
• Estado perdido al transferir: el segundo modelo repite trabajo o acepta una afirmación sin verificar. Solución: paquete de transferencia estructurado.
• El modelo se evalúa a sí mismo: el mismo punto ciego pasa dos veces. Solución: comprobación determinista, evaluador independiente o persona según el riesgo.
• La abstracción posee el workflow: el producto depende de un Agent Builder visual, su memoria y definiciones propietarias de herramientas. Si desaparece el servicio, desaparece la salida. Solución: conservar estado, prompts, esquemas, evaluaciones y políticas en un formato propio y versionado.
• Cambio de proveedor sin evaluaciones: un JSON compatible no implica un comportamiento compatible. Solución: repetir tareas representativas antes del cambio.

Ejemplo: clasificación de solicitudes de clientes

Una empresa recibe correos de soporte en varios idiomas. El sistema debe asignar una categoría, recuperar documentación pertinente y preparar un borrador. Los cambios de contrato y reembolsos requieren una persona.

1. El código elimina firmas, detecta adjuntos y marca datos personales.
2. Un modelo local pequeño clasifica idioma, tema y riesgo en un esquema JSON fijo.
3. La puerta de políticas impide enviar adjuntos sensibles a APIs externas y permite un proveedor de nube aprobado para consultas normales.
4. Un modelo más barato recibe los artículos recuperados y produce un borrador con citas.
5. El verificador confirma que los documentos citados existen, que no hay promesas prohibidas y que cada afirmación sobre el producto tiene respaldo.
6. Una infracción del esquema recibe una reparación dirigida. Una discrepancia factual transfiere el objetivo, las fuentes y el resultado de la comprobación a un modelo más potente. Un caso de alto riesgo va directamente a una persona.
7. El sistema registra la vía, el motivo, el coste total y si la persona aceptó, editó o rechazó el borrador.

Tras varios ciclos de evaluación, el equipo puede descubrir que el modelo barato resuelve consultas rutinarias, pero necesita reparaciones frecuentes en reclamaciones ambiguas. El router escala entonces según la combinación de tema, riesgo y resultado del retrieval, no por la longitud del correo. Eso es orquestación basada en pruebas, no una jerarquía de marcas.

Fuentes

• Building effective agents (Anthropic) - diferencia práctica entre flujos sencillos y sistemas agénticos, con un buen argumento a favor del diseño más simple que funcione.
• RouteLLM (LMSYS) - investigación sobre routers que eligen entre vías potentes y baratas según la consulta.
• FrugalGPT (Stanford University) - trabajo temprano sobre cascadas de modelos, presupuestos y optimización entre calidad y coste.
• NIST AI Risk Management Framework - marco para identificar, medir y gestionar riesgos de IA, incluida la responsabilidad operativa.
• OWASP Top 10 for LLM Applications - catálogo de ataques y riesgos operativos que deben respetar routers, herramientas y fallbacks.
• OpenAI Evals - marco abierto y ejemplos para describir tareas de evaluación y comparar el comportamiento de modelos.

Qué recordar

La orquestación no es una colección de modelos. Es la capa de control para decisiones, transferencias, verificación y parada. Empieza con un modelo y una referencia medible. Decide rutas con pruebas, no por prestigio de marca. Cuenta el coste por éxito, incluidos reintentos y trabajo humano. Impón la política de seguridad antes del modelo y consérvala en los fallbacks. Mantén estado, evaluaciones y contratos de herramientas en un formato propio. Una buena orquestación es aburrida, auditable y reemplazable.