Estrategia de fallback de modelo: un playbook de 3 flujos de trabajo

El fallback de modelo no es un solo comportamiento. Es un conjunto de decisiones de recuperación con distintos límites de seguridad.

Una estrategia de fallback de modelo en producción debe separar tres flujos de trabajo:

1. Reintento o failover equivalente cuando la solicitud sigue siendo segura para reintentarse.
2. Fallback entre modelos cuando otro modelo puede satisfacer la misma capacidad y el mismo contrato de calidad.
3. Detener, reconciliar o escalar cuando la salida ya se ha entregado al usuario o puede haber ocurrido un efecto secundario de una herramienta.

Esa separación importa porque la acción de recuperación más rápida no siempre es la más segura. Repetir una solicitud de clasificación fallida suele tener bajo riesgo. Cambiar de modelo silenciosamente a mitad de una respuesta transmitida o después de una llamada incierta a una herramienta de pagos no lo es.

Este playbook convierte la política de fallback en tres flujos de trabajo operativos que tu equipo puede implementar, probar y observar.

The model fallback decision in one table

Empieza por el estado de la solicitud, no por el nombre del proveedor.

La regla central es simple: el reintento preserva el objetivo, el failover equivalente preserva el contrato del modelo y el fallback entre modelos cambia el riesgo del contrato. Cada paso necesita una comprobación de elegibilidad más estricta.

Para un tratamiento más profundo de circuit breakers, normalización de errores y un controlador neutral respecto al proveedor, consulta el playbook de routing de fallback de la API de LLM.

Before the workflows: define one fallback envelope

Every request should enter the routing layer with a bounded envelope. The envelope tells the system how much recovery is allowed before the request must stop.

type FallbackEnvelope = {
  requestId: string;
  deadlineMs: number;
  maxAttempts: number;
  maxAddedLatencyMs: number;
  maxCostUsd?: number;
  allowEquivalentFailover: boolean;
  allowCrossModelFallback: boolean;
  allowAfterPartialOutput: false;
  sideEffectMode: "none" | "read_only" | "write_possible";
  requiredCapabilities: string[];
  requiredSchemaVersion?: string;
};

Los valores deben provenir del flujo de trabajo del producto, no de un valor predeterminado global. Un trabajo en segundo plano de resumen puede tolerar más latencia que un asistente interactivo de programación. Una respuesta de chat sin herramientas puede tolerar un comportamiento de recuperación diferente al de un agente que puede desplegar código o enviar correo electrónico.

El envelope también evita los reintentos anidados. Si el SDK, la aplicación, el gateway y el adaptador del proveedor reintentan de forma independiente, un incidente pequeño puede multiplicarse en una gran ráfaga de intentos. Elige una capa para que sea la propietaria del presupuesto total de intentos y exige que cada capa inferior informe lo que ya consumió.

Flujo de trabajo 1: reintentar y luego hacer failover equivalente

Usa este flujo de trabajo cuando la operación se puede reproducir y el sistema no ha expuesto salida parcial ni ha entrado en un estado incierto de efectos secundarios.

Un destino equivalente es otra ruta que conserva el contrato importante: la misma clase de comportamiento del modelo, las capacidades requeridas, las expectativas de esquema, la configuración de seguridad y límites de contexto compatibles. Puede ser una región, un despliegue, un endpoint de proveedor o un pool de capacidad diferente.

Paso 1: normalizar el fallo

Mapea las respuestas específicas del proveedor a una pequeña taxonomía interna:

• transport_transient
• rate_limited
• provider_overloaded
• provider_server_error
• authentication_or_permission
• invalid_request
• deadline_exhausted
• contract_failure
• partial_output
• side_effect_uncertain

Normalmente, solo los primeros cuatro califican para una reproducción automática. Los errores de autenticación, permiso y solicitud inválida deben detenerse porque es poco probable que un endpoint diferente repare la solicitud. Los fallos de contrato pertenecen al Flujo de trabajo 2. La salida parcial y los efectos secundarios inciertos pertenecen al Flujo de trabajo 3.

Paso 2: calcular el presupuesto restante

Antes de cada intento, comprueba:

remaining time > estimated next-attempt latency + response safety margin
remaining attempts > 0
remaining added latency > 0
remaining cost budget > estimated attempt cost, when a cost ceiling exists

Si cualquier presupuesto requerido se agota, sal en lugar de intentar un proveedor más.

Paso 3: reintentar con backoff y jitter

Usa la guía de reintento del proveedor cuando esté disponible. De lo contrario, aplica retroceso exponencial con jitter y mantén el retraso dentro del plazo de la solicitud.

function retryDelayMs(attempt: number, retryAfterMs?: number): number {
  if (retryAfterMs !== undefined) return retryAfterMs;

  const base = Math.min(250 * 2 ** attempt, 4_000);
  const jitter = Math.random() * base * 0.3;
  return Math.round(base + jitter);
}

El jitter importa porque, de otro modo, muchos clientes simultáneos pueden reintentar con el mismo cronograma y prolongar un evento de sobrecarga. Tu guía sobre límites de tasa de LLM debería definir cómo interactúan RPM, TPM, colas, concurrencia y presupuestos de reintentos.

Paso 4: pasar a capacidad equivalente

Si el mismo destino sigue sin estar saludable, enruta a un endpoint equivalente solo después de verificar:

• El circuito está cerrado o en estado half-open para una sonda.
• El destino admite los modos de entrada y salida requeridos.
• El destino puede aceptar la solicitud dentro de su límite de contexto.
• El destino usa la configuración esperada de seguridad y manejo de datos.
• El intento aún encaja en el plazo y el margen de costes.

El failover equivalente suele ser menos arriesgado que cambiar de modelo porque pretende preservar el contrato de respuesta.

Paso 5: registrar el motivo de la recuperación

Devuelve un resultado de ruta como:

{
  "workflow": "retry_equivalent_failover",
  "primary_attempts": 2,
  "equivalent_failover_attempts": 1,
  "recovered": true,
  "recovery_reason": "provider_overloaded",
  "added_latency_ms": 684
}

No expongas detalles internos del proveedor a los usuarios finales, a menos que tu producto prometa esa transparencia. Sí consérvalos en trazas y registros operativos.

Flujo de trabajo 2: fallback controlado entre modelos

El fallback entre modelos solo es apropiado cuando el modelo alternativo ha sido preaprobado para la tarea. Que un modelo devuelva texto no es suficiente; debe cumplir el contrato del flujo de trabajo.

Paso 1: crear un contrato de capacidades

Define los requisitos no negociables para cada clase de ruta.

{
  "route_class": "support_ticket_triage_v3",
  "required": {
    "input": ["text"],
    "output": ["json_schema"],
    "tools": [],
    "minimum_context_tokens": 24000,
    "schema": "triage-result-v3",
    "languages": ["en", "es", "de"],
    "safety_profile": "customer-support-standard"
  },
  "fallback_models": [
    "approved-model-b",
    "approved-model-c"
  ]
}

Para rutas que usan herramientas, incluye el comportamiento de elección de herramientas, soporte para herramientas en paralelo, el manejo del esquema de argumentos y si el modelo sigue de forma fiable las condiciones de “no llamar”. Para salidas estructuradas, valida la respuesta real contra el esquema después de cada intento.

Paso 2: separar el éxito de transporte del éxito de la tarea

Una respuesta HTTP exitosa aún puede fallar en el flujo de trabajo del producto. Evalúa al menos tres capas:

1. Éxito de transporte: el proveedor devolvió una respuesta completa.
2. Éxito del contrato: la respuesta se parseó, coincidió con el esquema y usó correctamente las herramientas admitidas.
3. Éxito de la tarea: la salida realmente completó el trabajo del usuario con un nivel de calidad aceptable.

Esta distinción es esencial al comparar candidatos de fallback. Un modelo con una alta tasa de respuesta, pero con fallos frecuentes de esquema o de herramientas, no es un fallback fiable.

Paso 3: clasificar los candidatos aprobados por política

Un router de producción puede puntuar los destinos elegibles utilizando señales operativas sin fingir que un modelo sea universalmente el mejor.

type Candidate = {
  id: string;
  capabilitiesPass: boolean;
  circuitOpen: boolean;
  estimatedLatencyMs: number;
  estimatedCostUsd: number;
  recentContractSuccess: number;
  recentTaskSuccess: number;
};

function eligible(candidate: Candidate, envelope: FallbackEnvelope): boolean {
  return (
    candidate.capabilitiesPass &&
    !candidate.circuitOpen &&
    candidate.estimatedLatencyMs <= envelope.maxAddedLatencyMs &&
    (envelope.maxCostUsd === undefined ||
      candidate.estimatedCostUsd <= envelope.maxCostUsd)
  );
}

Evita una lista estática de “principal, respaldo, respaldo” para cada tarea. El mejor conjunto de fallback para generación de código puede diferir del mejor conjunto para extracción, traducción, visión o ejecución de herramientas.

Paso 4: validar la salida de fallback

Aplica primero comprobaciones deterministas:

• Validación de JSON o de esquema
• Comprobaciones de campos obligatorios
• Validación de argumentos de herramientas
• Comprobaciones de formato de citas o URL
• Restricciones de longitud y lenguaje
• Patrones de salida prohibidos

Luego añade comprobaciones de calidad específicas del flujo de trabajo. Estas pueden ser reglas ligeras, un evaluador de tareas, revisión humana de muestras o un modelo juez validado. Si la barrera de calidad falla, no etiquetes el fallback como recuperado.

Paso 5: cambios de política con canary

Antes de ampliar un nuevo modelo de fallback:

1. Reproduce un conjunto de evaluación sin conexión.
2. Ejecuta tráfico en sombra donde la política lo permita.
3. Activa el candidato para un pequeño porcentaje de fallos elegibles.
4. Compara éxito de contrato, éxito de tarea, latencia y coste.
5. Amplía solo si el valor de recuperación supera el riesgo de regresión.

Registra estas métricas con un esquema de observabilidad de la API de LLM que registre una ruta y un span por intento.

Flujo de trabajo 3: detener, reconciliar o escalar

Algunos fallos no deberían desencadenar otra llamada al modelo. El fallback correcto es una detención controlada.

Caso 1: salida parcial en streaming

Una vez que los tokens de respuesta han llegado al usuario, cambiar de modelo en silencio puede crear contradicciones, contenido duplicado, bloques de código rotos o un cambio repentino de estilo. También dificulta atribuir y depurar la respuesta final.

Usa una de estas salidas explícitas en su lugar:

• Terminar el flujo con un error recuperable y una acción de “reintentar”.
• Ofrecer reiniciar la respuesta desde el principio.
• Continuar solo si la aplicación tiene un protocolo de reanudación diseñado y el nuevo modelo recibe exactamente el prefijo aceptado.

El valor predeterminado debería ser allowAfterPartialOutput: false.

Caso 2: efectos secundarios inciertos de herramientas

Supón que un modelo seleccionó una herramienta de pago, correo electrónico, despliegue, ticket o escritura en base de datos. La herramienta puede haber tenido éxito incluso si la conexión falló antes de que tu orquestador registrara el resultado. Reproducir todo el flujo de trabajo puede duplicar el efecto secundario.

Protege las herramientas de escritura con:

• Una clave de idempotencia basada en la operación del usuario, no en el intento del proveedor.
• Un registro de ejecución duradero con estados planned, started, succeeded, failed y unknown.
• Desduplicación en el límite de la herramienta.
• Una consulta de reconciliación antes de cualquier repetición.
• Revisión humana para acciones de alto impacto que sigan siendo inciertas.

type ToolExecution = {
  operationId: string;
  toolName: string;
  state: "planned" | "started" | "succeeded" | "failed" | "unknown";
  externalReference?: string;
};

function nextAction(execution: ToolExecution): "continue" | "reconcile" | "stop" {
  if (execution.state === "succeeded") return "continue";
  if (execution.state === "failed") return "stop";
  return "reconcile";
}

Mantén separados las credenciales del proveedor y las credenciales de la herramienta. La guía de gestión segura de claves API cubre el modelo circundante de secretos y control de acceso.

Caso 3: incertidumbre de seguridad, permisos o política

La disponibilidad no debe debilitar una decisión de seguridad o autorización. Si el candidato de fallback no admite los controles de política requeridos, la ruta no es elegible. Si el sistema no puede determinar si una operación está permitida, falla de forma cerrada o escala según el modelo de riesgo del producto.

Caso 4: ningún candidato satisface el contrato

Devuelve un fallo tipado que la aplicación pueda manejar:

{
  "status": "unavailable",
  "reason": "no_eligible_fallback",
  "retryable": true,
  "retry_after_ms": 30000,
  "request_id": "req_123"
}

Una respuesta degradada clara es mejor que una respuesta que parece exitosa pero viola el esquema, usa las herramientas equivocadas o provoca el efecto secundario incorrecto.

Pon los tres flujos de trabajo en una sola máquina de estados

La capa de orquestación debe hacer explícita la transición.

START
  -> PRIMARY_ATTEMPT
     -> SUCCESS: validar y devolver
     -> TRANSIENT + replayable: WORKFLOW_1
     -> CONTRACT_FAILURE + approved alternate: WORKFLOW_2
     -> PARTIAL_OUTPUT or SIDE_EFFECT_UNCERTAIN: WORKFLOW_3

WORKFLOW_1
  -> retry inside budget
  -> equivalent failover inside budget
  -> if compatible alternate allowed: WORKFLOW_2
  -> otherwise: STOP

WORKFLOW_2
  -> capability check
  -> alternate attempt
  -> contract and task validation
  -> return only on validated success
  -> otherwise: STOP

WORKFLOW_3
  -> mark partial or uncertain state
  -> reconcile external side effects when possible
  -> offer explicit restart or human escalation
  -> never silently replay unsafe work

Este también es el límite adecuado para un gateway multimodelo. Centralizar el acceso a los modelos detrás de un endpoint compatible con OpenAI puede reducir la duplicación de integraciones, pero la aplicación sigue necesitando proporcionar la intención del flujo de trabajo: plazos, modo de efectos secundarios, herramientas requeridas, versión de esquema y si se permite el fallback entre modelos. Flatkey proporciona una capa unificada de acceso a API para equipos que quieren una sola clave y una única superficie de integración entre proveedores de modelos; la política de enrutamiento más segura sigue comenzando con contratos explícitos de la aplicación.

Lista de verificación para implementar una estrategia de fallback de modelo

Política

• [ ] Cada clase de ruta tiene un sobre de fallback.
• [ ] Los errores recuperables se normalizan entre proveedores.
• [ ] El presupuesto total de reintentos tiene un único responsable.
• [ ] Los endpoints equivalentes se distinguen de los modelos alternativos.
• [ ] Los candidatos de fallback entre modelos tienen contratos de capacidad versionados.
• [ ] La salida parcial deshabilita el fallback transparente por defecto.
• [ ] Las herramientas de escritura usan registros duraderos de idempotencia.

Validación

• [ ] El transporte, el contrato y el éxito de la tarea se miden por separado.
• [ ] Las salidas estructuradas se validan después del fallback.
• [ ] Los argumentos de las herramientas y el comportamiento de selección de herramientas se prueban por modelo.
• [ ] Los conjuntos de evaluación de fallback representan clases de ruta reales.
• [ ] Los nuevos candidatos pasan una evaluación offline y un canario en producción.

Operaciones

• [ ] Cada intento registra el motivo de la ruta, el destino, la latencia y el resultado.
• [ ] Los paneles muestran por separado el primario, el reintento, el failover equivalente y la recuperación entre modelos.
• [ ] Las alertas incluyen el agotamiento del plazo y las tasas sin fallback elegible.
• [ ] Los circuit breakers usan sondeos controlados half-open.
• [ ] La revisión de incidentes incluye la calidad visible para el usuario y el riesgo de efectos secundarios duplicados.

Métricas que demuestran que el fallback está ayudando

No optimices solo para la tasa de error del proveedor. Haz seguimiento del resultado para el usuario.

Segmenta estas métricas por clase de ruta. Una tasa de recuperación agregada puede ocultar que el fallback funciona bien para extracción, pero mal para generación de código o uso de herramientas.

Preguntas frecuentes

¿Qué es una estrategia de fallback de modelo?

Una estrategia de fallback de modelo es una política para decidir cuándo una solicitud de IA debe reintentar el mismo destino, hacer failover a capacidad equivalente, cambiar a un modelo alternativo aprobado o detenerse porque la repetición sería insegura.

¿Cuál es la diferencia entre retry y fallback?

Un retry repite la solicitud contra el mismo destino o despliegue. El failover equivalente mueve la solicitud a una capacidad destinada a preservar el mismo contrato de modelo. El fallback entre modelos cambia el modelo y, por lo tanto, requiere validación de capacidad y calidad.

¿Debería cada error 429 activar otro modelo?

No. Primero clasifique el límite, respete la guía de reintento, compruebe el plazo restante y use un retry acotado o una cola. Cambiar de modelo puede ayudar cuando existe capacidad alternativa aprobada, pero también puede cambiar la calidad de salida, el comportamiento de las herramientas o el coste.

¿Puede una respuesta transmitida hacer fallback a mitad de la respuesta?

Por lo general, es más seguro no cambiar de forma transparente después de que los tokens hayan llegado al usuario. Detenga el stream y ofrezca un reinicio explícito, a menos que la aplicación tenga un protocolo de reanudación probado.

¿Cuántos modelos de fallback debería tener una ruta?

Use el conjunto aprobado más pequeño que proporcione una recuperación significativa. Cada candidato añade trabajo de evaluación, monitorización y respuesta a incidentes. Una lista larga sin probar no es resiliencia.

¿Dónde debería vivir la lógica de fallback?

Centralice la normalización del proveedor, el enrutamiento, los presupuestos de intentos y la observabilidad en una gateway o capa de orquestación. Mantenga cerca de la aplicación la intención específica del flujo de trabajo —riesgo de efectos secundarios, requisitos de esquema, política de seguridad y umbrales de calidad—.

Construya el fallback en torno al riesgo del flujo de trabajo

La mejor estrategia de fallback de modelo no es “probar el siguiente modelo”. Es un sistema de decisión acotado:

• Workflow 1 recupera solicitudes repetibles con retries y capacidad equivalente.
• Workflow 2 cambia de modelo solo después de comprobaciones de capacidad y calidad.
• Workflow 3 detiene la repetición automática cuando la salida o los efectos secundarios hacen que la recuperación sea insegura.

Ese diseño mejora la disponibilidad sin ocultar fallos de contrato ni duplicar acciones del usuario. Si su equipo está estandarizando el acceso entre proveedores de modelos, use la capa de API unificada compatible con OpenAI de Flatkey como superficie de integración y luego adjunte estos contenedores específicos del flujo de trabajo a cada ruta de producción.

Fuentes y lectura adicional

• Códigos de error de la API de OpenAI
• Salidas estructuradas de OpenAI
• Errores de la API de Anthropic
• Mensajes en streaming de Anthropic
• Patrón de retry con backoff de AWS
• Patrón de circuit breaker de AWS
• Estrategia de retry de Google Cloud