Playbook de fallback multmodelo para APIs de IA confiables

Puntos clave

Reintenta la misma ruta solo ante fallos transitorios, como timeouts y respuestas 429.

Haz failover a un modelo que cumpla los mismos requisitos de capacidad y contrato de salida.

Establece un presupuesto máximo de costo y latencia para toda la solicitud, no para cada intento.

Registra el proveedor, el modelo, la clase de error, el conteo de reintentos y la ruta final para cada solicitud.

Separa reintento de fallback

Un reintento envía la solicitud de nuevo a la misma ruta porque el fallo puede ser temporal. Un fallback cambia el proveedor o el modelo porque la ruta original no está disponible o no es adecuada.

Tratar ambas acciones como un único bucle genérico de reintentos dificulta el diagnóstico de incidentes y puede multiplicar el costo sin mejorar la tasa de éxito.

Reintento: timeout, restablecimiento de conexión, 429 o respuesta 5xx temporal.
Fallback: fallo repetido del proveedor, problema de capacidad del modelo o restricción de política.
Detener: solicitud inválida, parámetro no compatible o validación de salida fallida.

Construye una tabla de rutas compatible con capacidades

Los modelos de fallback deben agruparse por capacidad y no por marca. Una solicitud de visión no puede hacer fallback a un modelo solo de texto, y un flujo estricto de JSON no debería enrutar a un modelo que infringe con frecuencia el esquema.

Modalidades de entrada y salida requeridas.
Contexto mínimo y longitud de salida.
Compatibilidad con tool calling y salida estructurada.
Precio y latencia máximos aceptables.

Aplica un único presupuesto a nivel de solicitud

El presupuesto de la solicitud debe cubrir todos los reintentos y tentativas de fallback. Antes de iniciar otro intento, comprueba si la latencia restante y el presupuesto de costo pueden soportarlo.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Mide la calidad del fallback, no solo la disponibilidad

Una solicitud que devuelve una respuesta correcta aún puede ser un fallo de producto. Haz seguimiento de la validación de salida, la tasa de corrección del usuario y la finalización de la tarea después de un evento de fallback.

Panel recomendado: éxito de ruta, tasa de fallback, latencia p95, costo estimado, tasa de validación aprobada y puntuación de calidad por modelo.

Preguntas frecuentes

¿Toda solicitud de IA fallida debe usar un modelo de fallback?

No. Los parámetros inválidos, las entradas no compatibles y las comprobaciones de seguridad fallidas deben detenerse de inmediato. El fallback es apropiado cuando otra ruta compatible puede completar de forma realista la misma tarea.

¿Cuántos intentos de fallback debería permitir una solicitud de IA?

La mayoría de los flujos interactivos deberían limitar el total a dos o tres intentos. El límite correcto depende del presupuesto de latencia restante, el valor de la tarea y el costo estimado.