Playbook de repli multi-modèle pour des API IA fiables

Points clés à retenir

Relancez la même route uniquement pour des échecs transitoires tels que les timeouts et les réponses 429.

Basculez vers un modèle qui satisfait aux mêmes exigences de capacité et de contrat de sortie.

Définissez un budget maximal de coût et de latence pour la requête entière, et non pour chaque tentative.

Journalisez le fournisseur, le modèle, la classe d’erreur, le nombre de relances et la route finale pour chaque requête.

Séparer la relance du repli

Une relance renvoie la requête vers la même route, car l’échec peut être temporaire. Un repli change de fournisseur ou de modèle, car la route d’origine est indisponible ou inadaptée.

Traiter ces deux actions comme une seule boucle générique de relance rend les incidents plus difficiles à diagnostiquer et peut multiplier les coûts sans améliorer le taux de réussite.

Relance : timeout, réinitialisation de connexion, réponse 429 ou 5xx temporaire.
Repli : échec répété du fournisseur, problème de capacité du modèle ou restriction de politique.
Arrêt : requête invalide, paramètre non pris en charge ou validation de sortie échouée.

Construire une table de routes compatible avec les capacités

Les modèles de repli doivent être regroupés par capacité plutôt que par marque. Une requête vision ne peut pas basculer vers un modèle texte seul, et un flux JSON strict ne doit pas être routé vers un modèle qui viole régulièrement le schéma.

Modalités d’entrée et de sortie requises.
Contexte minimal et longueur de sortie.
Prise en charge de l’appel d’outils et des sorties structurées.
Prix et latence maximaux acceptables.

Appliquer un budget unique au niveau de la requête

Le budget de requête doit couvrir chaque tentative de relance et de repli. Avant de lancer une autre tentative, vérifiez si le budget restant en latence et en coût peut la supporter.

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

Mesurer la qualité du repli, pas seulement la disponibilité

Une requête qui se termine avec succès peut tout de même constituer un échec produit. Suivez la validation de sortie, le taux de correction par l’utilisateur et la réussite de la tâche après un événement de repli.

Tableau de bord recommandé : réussite des routes, taux de repli, latence p95, coût estimé, taux de validation réussie et score de qualité par modèle.

Foire aux questions

Chaque requête IA en échec doit-elle utiliser un modèle de repli ?

Non. Les paramètres invalides, les entrées non prises en charge et les vérifications de sécurité échouées doivent s’arrêter immédiatement. Le repli est approprié lorsqu’une autre route compatible peut raisonnablement accomplir la même tâche.

Combien de tentatives de repli une requête IA doit-elle autoriser ?

La plupart des flux interactifs devraient limiter le total à deux ou trois tentatives. La limite correcte dépend du budget de latence restant, de la valeur de la tâche et du coût estimé.