Enrutamiento API LLM confiable: tiempos de espera, reintentos y retrocesos del modelo sin regresiones semánticas

Una solicitud alternativa no tiene éxito simplemente porque otro modelo devolvió HTTP 200. El reemplazo puede exceder el presupuesto de latencia original, omitir campos JSON requeridos, llamar a una herramienta diferente o producir una respuesta con una semántica materialmente diferente. Por lo tanto, el enrutamiento API de LLM confiable requiere más que una lista ordenada de modelos: requiere un contrato, un clasificador de fallas, una política de intentos limitada y validación antes de la aceptación.

La regla central es simple: reintentar solo cuando la falla sea plausiblemente temporal y retroceder solo cuando la siguiente ruta aún pueda satisfacer el contrato de solicitud original.

Defina el contrato de ruta antes de elegir modelos

Empiece por describir lo que debe proporcionar una respuesta exitosa. Este contrato de enrutamiento debe ser legible por máquina y estar adjunto a cada carga de trabajo o clase de solicitud.

{
  "carga de trabajo": "extracción_factura",
  "modalidades": ["texto", "imagen"],
  "max_input_tokens": 50000,
  "requires_tools": falso,
  "salida_estructurada": {
    "requerido": verdadero,
    "schema_id": "factura-v3",
    "estricto": verdadero
  },
  "allowed_model_classes": ["extracción de documentos"],
  "max_cost_usd": 0,08,
  "fecha límite_ms": 8000
}

El contrato debe cubrir las modalidades requeridas, la capacidad contextual, el soporte de herramientas, el comportamiento de salida estructurada, las clases de modelos aceptables, el costo máximo y el plazo de extremo a extremo. Agregue restricciones específicas de la aplicación cuando sea necesario, como regiones permitidas, longitud mínima de salida o un motivo de finalización requerido.

Recomendación: mantenga grupos de rutas separados y probados para texto sin formato, resultados restringidos por esquema, uso de herramientas, visión y solicitudes de contexto largo. Un modelo que es una alternativa de texto aceptable no es automáticamente una alternativa aceptable para la llamada de herramientas o la entrada de imágenes.

Clasifica el fallo antes de actuar

Los errores de autenticación, las solicitudes con formato incorrecto, los límites de velocidad y las fallas del servidor requieren respuestas diferentes. Tratar cada respuesta fallida como reintentable desperdicia capacidad y puede ocultar defectos.

Hecho: las solicitudes fallidas con velocidad limitada aún pueden contar en los límites del proveedor. Por lo tanto, los reintentos inmediatos agresivos pueden profundizar la limitación en lugar de resolverla. Los reintentos también consumen capacidad adicional durante una interrupción y las políticas de reintento en varias capas de aplicaciones pueden multiplicar la carga resultante.

Recomendación: permita que una capa sea dueña de los reintentos de generación de modelos. En una arquitectura típica, la puerta de enlace AI API es el propietario adecuado porque ve el estado de la ruta, el historial de intentos, la latencia y el costo. Deshabilite los reintentos automáticos en clientes de nivel inferior cuando sea posible o cuéntelos explícitamente en el mismo presupuesto de intentos.

Gastar un presupuesto de latencia de un extremo a otro

Los tiempos de espera por intento son insuficientes. Tres intentos con un tiempo de espera de cinco segundos pueden convertir una operación prevista de cinco segundos en una respuesta de quince segundos, antes de que se incluyan la retirada y la validación.

Registre una fecha límite absoluta cuando la solicitud ingresa a la puerta de enlace. Antes de cada intento, calcula el tiempo restante:

restante = fecha límite - tiempo_actual
requerido = permiso_conexión + permiso_generación + permiso_validación
si queda < requerido:
    detener_sin_lanzar_otro_intento

Para un plazo de ocho segundos, una asignación inicial razonable podría reservar 300 ms para el trabajo de la puerta de enlace y la validación final, permitir hasta 4,5 segundos para la ruta principal y retener aproximadamente 3,2 segundos para una ruta alternativa. Estos valores son un ejemplo, no un punto de referencia. Deben derivarse de distribuciones de latencia medidas para los proveedores, modelos, regiones y tamaños de salida reales.

Utilice un retroceso exponencial limitado con fluctuación para reintentos transitorios:

retraso = aleatorio(0, min(cap, base * 2^retry_index))

Las sugerencias de reintento del proveedor, como un valor de reintento posterior, deben tener prioridad cuando se ajusten al plazo restante. Deténgase después de un pequeño número de intentos. Una política común es un intento principal más uno alternativo, con un reintento opcional en la misma ruta solo para una falla temprana de conexión que no pudo haber generado resultados facturables.

Compensación: el respaldo secuencial mejora la disponibilidad pero aumenta la latencia de cola. Las solicitudes paralelas o cubiertas pueden reducir la latencia durante las desaceleraciones, pero consumen más capacidad y pueden generar cargos por varias generaciones exitosas. La cobertura debe limitarse a cargas de trabajo sin efectos secundarios y con latencia crítica, con cancelación y controles de costos.

Seleccione alternativas por capacidad, no por clasificación

Una tabla alternativa debería codificar la compatibilidad en lugar de un orden de preferencia global. Filtre las rutas candidatas según el contrato antes de considerar el estado, la latencia o el precio.

candidatos = rutas
  .filtro(soporta_modalidades_requeridas)
  .filter(límite_contexto >= tamaño_entrada_estimado)
  .filtro(supports_required_tools)
  .filtro(supports_requested_schema_mode)
  .filtro (clase_modelo en clases_modelo_permitidas)
  .filter(coste_estimado <=presupuesto_coste_restante)
  .filtro(no_suprimido_temporalmente)
seleccionado = rango(candidatos, salud, latencia, costo)

El soporte de resultados estructurados merece una prueba explícita. Incluso cuando dos rutas anuncian una generación restringida por esquema, pueden admitir diferentes subconjuntos de esquemas JSON o interpretar casos extremos de manera diferente. Los modelos compatibles con herramientas también pueden diferir en la selección de herramientas, la construcción de argumentos y el comportamiento de llamadas paralelas.

Hecho: cambiar de familia de modelos puede preservar la disponibilidad del transporte y al mismo tiempo cambiar el estilo, la calidad del razonamiento, el comportamiento de seguridad, la tokenización y la selección de herramientas. El éxito de HTTP no es evidencia de equivalencia semántica.

Predicción: a medida que los catálogos de modelos se expandan, las políticas de enrutamiento de producción utilizarán cada vez más perfiles de capacidad versionados y pruebas de aceptación de cargas de trabajo específicas en lugar de listas de modelos estáticas. Trate esto como una dirección de diseño, no como una garantía sobre el comportamiento del proveedor.

Validar la respuesta antes de aceptarla

Ejecute cada respuesta, incluida la respuesta principal, a través del mismo proceso de aceptación. La validación debe realizarse antes de que el resultado se almacene en caché, se facture internamente como exitoso o se pase a un ejecutor de herramientas.

1. Confirme que el transporte se completó y se podrá analizar el sobre de respuesta.
2. Compruebe el motivo de finalización y rechace el truncamiento cuando se requiera una salida completa.
3. Validar la salida estructurada con respecto al esquema original.
4. Verifique los campos obligatorios, los valores de enumeración y las invariantes de la aplicación.
5. Permitir solo nombres de herramientas registradas y validar argumentos para cada esquema de herramienta.
6. Aplicar comprobaciones semánticas específicas de la carga de trabajo cuando una falsa aceptación sería costosa.

Para la extracción de facturas, las comprobaciones semánticas pueden requerir un total no negativo, un código de moneda admitido y totales de artículos en línea dentro de una tolerancia definida explícitamente. Para la clasificación se requiere una etiqueta del conjunto permitido. Para la generación de código, el análisis o la compilación pueden ser apropiados. Estos controles no demuestran la calidad, pero evitan que las infracciones predecibles del contrato sean tratadas como éxitos.

No repares silenciosamente cada respuesta mal formada. La normalización determinista, como la eliminación de espacios en blanco circundantes inofensivos, puede ser aceptable. Adivinar campos financieros faltantes o reescribir argumentos de herramientas cambia el significado del modelo y debería provocar rechazo o revisión humana.

Reintentos de generación separados de los efectos secundarios

Las solicitudes de LLM suelen utilizar HTTP POST, que no es inherentemente idempotente. Más importante aún, una respuesta modelo puede iniciar una acción externa, como cobrar un método de pago, enviar un mensaje, crear un ticket o modificar la infraestructura. Reintentar la generación y repetir esa acción son decisiones independientes.

Asigne un ID de operación en el límite de la aplicación y un ID de intento a cada llamada de modelo. Persistir en el estado de ejecución de la herramienta frente a una clave determinista, como por ejemplo:

clave_ejecución = id_operación + nombre_herramienta + hash_argumentos_canónicos

Antes de ejecutar una herramienta, verifique si esa clave está pendiente, completada o fallida. Devuelve el resultado almacenado para una ejecución completa en lugar de ejecutarlo nuevamente. Para operaciones cuyos argumentos puedan cambiar legítimamente, se requiere aprobación a nivel de aplicación o un nuevo ID de operación.

Un tiempo de espera ambiguo requiere un tratamiento especial. Si la conexión falla después de que se transmitió una solicitud, es posible que la puerta de enlace no sepa si se produjo la generación. Una clave de idempotencia respaldada por el proveedor puede ayudar cuando esté disponible. De lo contrario, registre el resultado como desconocido y aplique una política de reproducción específica de la carga de trabajo en lugar de asumir que no pasó nada.

Suprime las rutas en mal estado y expone todos los intentos

Un disyuntor o una supresión temporal del estado evitan que cada nueva solicitud redescubra la misma ruta defectuosa. Abra el circuito después de una tasa de error definida o un umbral de falla consecutiva, luego admita sondas limitadas en un estado medio abierto. Ajuste los umbrales por ruta y clase de error para que una solicitud de cliente con formato incorrecto no pueda hacer que un modelo en buen estado parezca no disponible.

Registra un evento a nivel de solicitud y un evento por intento. Los campos útiles incluyen ID de operación, ID de intento, proveedor y modelo seleccionados, clase de falla, código de estado, latencia, recuento de tokens, costo estimado, motivo de reserva, resultado de validación, estado del circuito y resultado final. Redacte o haga hash de mensajes, resultados y argumentos de herramientas según sus requisitos de sensibilidad y retención.

Las métricas operativas útiles incluyen la tasa de respaldo, los intentos por solicitud completada, la tasa de agotamiento de los plazos, la tasa de rechazo de validación, los resultados ambiguos, el costo por respuesta aceptada y la latencia por ruta final. Una creciente tasa de éxito de HTTP junto con una creciente tasa de rechazo de validación es una advertencia de que la disponibilidad del transporte está enmascarando fallas en los contratos.

Lista de verificación de implementación de producción

• Defina un contrato de enrutamiento versionado para cada clase de carga de trabajo.
• Asigna los errores del proveedor a categorías permanentes, transitorias, incompatibles, de respuesta no válida y ambiguas.
• Elija un propietario de reintento y limite el total de intentos.
• Propagar una fecha límite absoluta a través de la puerta de enlace, el cliente del proveedor, la validación y la ejecución de la herramienta.
• Cree grupos de respaldo con capacidad probada en lugar de una cadena de modelo global.
• Validar esquemas, llamadas a herramientas, motivos de finalización e invariantes de dominio.
• Deduplicar efectos secundarios con claves de operación y ejecución.
• Agregue supresión de rutas con sondas semiabiertas limitadas.
• Registrar la latencia a nivel de intento, los tokens, el costo, los errores y los resultados de aceptación.
• Inyecta tiempos de espera, 429, errores 5xx seleccionados, JSON con formato incorrecto, desbordamiento de contexto y éxitos lentos en la preparación.

Comience con una ruta principal y una alternativa compatible para una única carga de trabajo de bajo riesgo. Compare la calidad, la latencia y el costo de la respuesta aceptada antes de ampliar la política. El objetivo no es la tasa de retroceso más alta posible. Es un sistema limitado que devuelve una respuesta que satisface el contrato original o falla claramente antes de causar trabajo duplicado o daño semántico.

Lectura relacionada

• Nota de prueba de API anterior
• anterior Artículo en inglés