Model routing: usar el modelo adecuado en cada paso

Un agente puede necesitar un razonamiento complejo para decidir cómo abordar un expediente y, segundos después, realizar veinte extracciones casi idénticas. Utilizar el mismo modelo en ambos pasos obliga a pagar capacidad que la segunda tarea apenas aprovecha o a confiar la primera a un modelo insuficiente.

El model routing asigna a cada tarea el modelo que alcanza la calidad requerida con el menor coste total. Esta arquitectura funciona mejor cuando la aplicación es agnóstica por diseño: el proceso, los datos, los permisos, las herramientas y las evaluaciones permanecen separados de cualquier proveedor.

Una sola ejecución contiene trabajos muy distintos

«Usamos el mejor modelo» parece una decisión prudente, aunque rara vez describe bien un sistema de producción. Una gestión completa puede incluir clasificación, recuperación documental, planificación, extracción, redacción, llamadas a herramientas y comprobaciones. Cada paso presenta una combinación diferente de dificultad, riesgo y posibilidad de verificación.

Una clasificación con categorías estables puede resolverse con un modelo rápido y una validación sencilla. Preparar una estrategia ante información contradictoria exige más capacidad. Ejecutar una transferencia bancaria requiere controles deterministas y autorización, con independencia del modelo que haya propuesto la acción.

La guía de OpenAI para construir agentes recomienda establecer primero una línea base con un modelo capaz y sustituir después componentes por modelos más pequeños cuando mantengan la calidad (OpenAI). Este orden permite comprobar primero que el flujo funciona y optimizar después con evidencia.

El patrón de dos modelos

Una arquitectura de dos modelos reparte el trabajo según la incertidumbre:

• Modelo avanzado. Interpreta objetivos ambiguos, prepara planes, resuelve conflictos, integra evidencia y atiende excepciones con impacto.
• Modelo eficiente. Ejecuta tareas frecuentes, acotadas y fáciles de comprobar: clasificar, extraer campos, normalizar resultados o aplicar una instrucción bien definida.
• Orquestador. Conserva el estado, asigna cada paso, aplica presupuestos y decide cuándo escalar.
• Verificadores. Comprueban esquemas, reglas, evidencia, permisos y criterios de aceptación antes de permitir que el flujo avance.

El modelo avanzado puede crear un plan que el modelo eficiente desarrolla paso a paso. También puede intervenir solo después de un fallo verificable. La segunda opción suele ahorrar más cuando la mayoría de los casos son sencillos, aunque añade el coste del primer intento y del verificador.

La separación debe responder a datos del proceso. Si el modelo eficiente provoca más correcciones, repite herramientas o escala casi todo, el reparto ha trasladado el coste en lugar de reducirlo.

La IA agnóstica convierte el routing en arquitectura

Cambiar el nombre del modelo dentro de una llamada ofrece una portabilidad superficial. Cada proveedor representa de forma distinta los mensajes, las herramientas, las salidas estructuradas, la caché, los errores y el uso de contexto. Un flujo acoplado a esas diferencias pierde la capacidad de comparar modelos por tarea.

La IA agnóstica por diseño de INSTINTIA separa los modelos de la lógica, los datos, las integraciones y la experiencia de usuario. La aplicación trabaja con contratos propios —por ejemplo, «extraer cláusulas», «proponer respuesta» o «solicitar aprobación»— y cada adaptador traduce esos contratos al proveedor elegido.

Esta capa permite:

• incorporar un modelo especializado sin reconstruir el proceso;
• comparar candidatos con las mismas entradas y evaluaciones;
• mantener una ruta alternativa ante cambios de precio o disponibilidad;
• restringir cada tarea a los proveedores, regiones y políticas permitidos;
• conservar trazas comparables aunque cambie el modelo.

El diseño agnóstico tampoco exige renunciar a funciones exclusivas. Una capacidad nativa puede aportar una ventaja clara. Conviene aislarla, registrar la dependencia y conocer qué ocurrirá si otra ruta carece de ella. El artículo sobre arquitecturas preparadas para cambiar de modelo desarrolla estos contratos con más detalle.

Qué debe decidir el router

El router parte de restricciones obligatorias y optimiza dentro del conjunto permitido. Los datos sensibles pueden limitar proveedor o región. Una acción de alto impacto puede exigir un modelo evaluado para ese caso y una aprobación humana. Una interacción de voz impone una latencia que descarta rutas demasiado lentas.

Las señales útiles proceden del propio flujo:

País, sensibilidad, tipo documental y fase del proceso suelen estar disponibles como datos estructurados. Resulta innecesario pedir a otro modelo que los adivine. Un clasificador o router aprendido aporta valor cuando la dificultad es ambigua y existe suficiente historial etiquetado.

Tres formas de repartir el trabajo

La opción más simple es una tabla fija: extracción al modelo eficiente, planificación al avanzado y acciones sensibles a la ruta supervisada. Es fácil de explicar y auditar.

Otra posibilidad es el escalado por validación. El modelo eficiente realiza el primer intento; un verificador acepta el resultado o deriva el caso. Funciona bien cuando el control es barato y detecta los errores relevantes. Un JSON válido demuestra formato, pero no demuestra que las cláusulas extraídas sean correctas: cada verificador debe corresponder al riesgo real.

Los routers aprendidos predicen qué modelo alcanzará el umbral de calidad. Necesitan resultados comparables de los candidatos, etiquetas fiables y recalibración cuando cambian los modelos o la distribución de tareas. La investigación de RouteLLM mostró reducciones de coste superiores a dos veces en determinados benchmarks sin pérdida de calidad agregada; el resultado pertenece a esas pruebas y no constituye una previsión para cualquier sistema (Ong et al., 2024).

Los servicios gestionados ya aplican este patrón. Microsoft Foundry ofrece un router que selecciona modelos por solicitud y recomienda evaluarlo contra la ruta que ya utiliza cada carga de trabajo (Microsoft Foundry). Es una opción operativa, no un sustituto de las evaluaciones propias ni de la capa agnóstica.

La métrica es el coste por tarea correcta

El precio por millón de tokens solo mide una parte. El coste de una tarea incluye las inferencias, la decisión del router, los reintentos, las herramientas, la infraestructura, la validación y el tiempo de revisión humana.

Coste por tarea correcta = coste total de ejecuciones e intervenciones / tareas que superan el umbral de calidad.

OpenAI propone esta misma lógica para medir el coste de un resultado satisfactorio y advierte que un modelo barato puede necesitar más intentos o revisión (OpenAI, julio de 2026). El análisis del coste real de un agente explica cómo atribuir también herramientas, infraestructura y supervisión.

La comparación debe segmentarse por tipo de tarea y dificultad. Una media global puede ocultar que el modelo eficiente resuelve el 90 % de las extracciones sencillas y falla precisamente en los documentos con mayor impacto. También conviene observar latencia, tasa de escalado, número de intentos y correcciones posteriores.

Riesgos que pueden anular el ahorro

El routing añade complejidad operativa. Hay que versionar reglas, registrar qué modelo atendió cada paso y reproducir la decisión ante un incidente. Un cambio silencioso en el conjunto de modelos puede modificar la calidad sin alterar el código de la aplicación.

También aparecen estos fallos:

• Escalado tardío. El modelo eficiente consume varios intentos antes de reconocer un caso difícil.
• Validación débil. El sistema acepta una salida formalmente correcta con errores de contenido.
• Contexto desigual. Dos modelos reciben instrucciones o herramientas distintas y la comparación deja de ser válida.
• Fallback inseguro. Una caída envía datos a un proveedor o región que la política no permite.
• Ahorro aparente. Baja la factura de inferencia mientras aumentan la latencia y la revisión humana.

La respuesta consiste en conservar versiones fijadas, evaluaciones de regresión, límites de reintento y rutas explícitas de contingencia. Las decisiones sensibles deben mantener sus controles aunque cambie el modelo.

Cómo empezar con dos modelos

1. Definir tareas. Separar planificación, ejecución, herramientas y validación dentro del flujo.
2. Fijar la calidad. Establecer criterios y una línea base con un modelo capaz.
3. Elegir un candidato eficiente. Sustituir primero una tarea frecuente, acotada y verificable.
4. Ejecutar en sombra. Comparar ambos modelos sobre los mismos casos sin afectar al usuario.
5. Medir el recorrido completo. Incluir fallos, escalados, herramientas y revisión en el coste.
6. Ampliar por evidencia. Añadir tareas o modelos cuando la calidad se mantenga por segmento.

Preguntas frecuentes