Stratégie de repli des modèles : un playbook en 3 workflows

Le repli de modèle n’est pas un comportement unique. C’est un ensemble de décisions de récupération avec des limites de sécurité différentes.

Une stratégie de repli des modèles en production doit séparer trois workflows :

1. Nouvelle tentative ou basculement équivalent lorsque la requête peut encore être rejouée sans risque.
2. Repli vers un autre modèle lorsqu’un autre modèle peut satisfaire la même capacité et le même contrat de qualité.
3. Arrêter, réconcilier ou escalader lorsque la sortie a déjà été remise à l’utilisateur ou qu’un effet de bord d’un outil a peut-être eu lieu.

Cette séparation est importante, car l’action de récupération la plus rapide n’est pas toujours la plus sûre. Rejouer une requête de classification échouée présente généralement un faible risque. Basculer silencieusement vers un autre modèle au milieu d’une réponse diffusée en streaming, ou après un appel incertain à un outil de paiement, ne l’est pas.

Ce playbook transforme la politique de repli en trois workflows opérationnels que votre équipe peut implémenter, tester et observer.

La décision de repli des modèles en une table

Commencez par l’état de la requête, pas par le nom du fournisseur.

La règle fondamentale est simple : la nouvelle tentative préserve la cible, le basculement équivalent préserve le contrat du modèle, et le repli vers un autre modèle modifie le risque lié au contrat. Chaque étape nécessite une vérification d’éligibilité plus stricte.

Pour un traitement plus approfondi des disjoncteurs, de la normalisation des erreurs et d’un contrôleur agnostique vis-à-vis du fournisseur, consultez le playbook de routage de repli pour les API LLM.

Avant les workflows : définir une enveloppe de repli unique

Chaque requête doit entrer dans la couche de routage avec une enveloppe bornée. L’enveloppe indique au système combien de récupération est autorisée avant que la requête doive s’arrêter.

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;
};

Les valeurs doivent provenir du workflow produit, et non d’une valeur par défaut globale. Un job d’indexation de synthèse en arrière-plan peut tolérer davantage de latence qu’un assistant de code interactif. Une réponse de chat sans outils peut tolérer un comportement de récupération différent de celui d’un agent capable de déployer du code ou d’envoyer des e-mails.

L’enveloppe empêche aussi les nouvelles tentatives imbriquées. Si le SDK, l’application, la passerelle et l’adaptateur du fournisseur réessaient tous indépendamment, un petit incident peut se multiplier en une grosse rafale de tentatives. Choisissez une seule couche pour gérer le budget total de tentatives et exigez que chaque couche inférieure indique ce qu’elle a déjà consommé.

Workflow 1 : réessayer, puis basculer vers un équivalent

Utilisez ce workflow lorsque l’opération est rejouable et que le système n’a pas exposé de sortie partielle ni प्रवेशé dans un état d’effet secondaire incertain.

Une cible équivalente est un autre itinéraire qui préserve le contrat important : même classe de comportement du modèle, capacités requises, attentes de schéma, configuration de sécurité et limites de contexte compatibles. Il peut s’agir d’une région, d’un déploiement, d’un point de terminaison fournisseur ou d’un pool de capacité différents.

Étape 1 : normaliser l’échec

Mappez les réponses propres au fournisseur vers une petite taxonomie interne :

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

Seuls les quatre premiers correspondent normalement à un rejouement automatique. Les erreurs d’authentification, d’autorisation et de requête invalide doivent arrêter le processus, car un autre point de terminaison a peu de chances de corriger la requête. Les échecs de contrat relèvent du Workflow 2. La sortie partielle et les effets secondaires incertains relèvent du Workflow 3.

Étape 2 : calculer le budget restant

Avant chaque tentative, vérifiez :

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 l’un des budgets requis est épuisé, quittez plutôt que d’essayer un fournisseur de plus.

Étape 3 : réessayer avec backoff et jitter

Utilisez les recommandations de retry du fournisseur lorsqu’elles sont disponibles. Sinon, appliquez un backoff exponentiel avec jitter et maintenez le délai à l’intérieur du deadline de la requête.

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);
}

Le jitter compte, car de nombreux clients simultanés peuvent sinon réessayer selon le même calendrier et prolonger un événement de surcharge. Votre guide sur les limites de débit des LLM doit définir comment les RPM, les TPM, les files d’attente, la concurrence et les budgets de réessai interagissent.

Étape 4 : passer à une capacité équivalente

Si la même cible reste en mauvaise santé, redirigez vers un point de terminaison équivalent uniquement après avoir vérifié :

• Le circuit est fermé ou en demi-ouverture pour une sonde.
• La cible prend en charge les modes d’entrée et de sortie requis.
• La cible peut accepter la requête dans sa limite de contexte.
• La cible utilise la configuration de sécurité et de traitement des données attendue.
• Tentative respecte encore le délai et l’enveloppe de coûts.

Le basculement équivalent est normalement moins risqué qu’un changement de modèle, car il vise à préserver le contrat de réponse.

Étape 5 : enregistrer la raison de la récupération

Renvoyez un résultat de routage tel que :

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

N’exposez pas les détails internes du fournisseur aux utilisateurs finaux, sauf si votre produit promet cette transparence. Conservez-les toutefois dans les traces et les journaux opérationnels.

Workflow 2 : repli contrôlé entre modèles

Le repli entre modèles n’est approprié que si le modèle alternatif a été préapprouvé pour la tâche. Un modèle qui renvoie du texte ne suffit pas ; il doit satisfaire le contrat du workflow.

Étape 1 : créer un contrat de capacité

Définissez les exigences non négociables pour chaque classe de route.

{
  "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"
  ]
}

Pour les routes utilisant des outils, incluez le comportement de sélection des outils, la prise en charge des outils parallèles, la gestion du schéma des arguments et la question de savoir si le modèle respecte de manière fiable les conditions de type « ne pas appeler ». Pour les sorties structurées, validez la réponse réelle par rapport au schéma après chaque tentative.

Étape 2 : séparer le succès du transport du succès de la tâche

Une réponse HTTP réussie peut néanmoins échouer dans le workflow produit. Évaluez au moins trois niveaux :

1. Succès du transport : le fournisseur a renvoyé une réponse complète.
2. Succès du contrat : la réponse a été analysée, a correspondu au schéma et a utilisé correctement les outils pris en charge.
3. Succès de la tâche : la sortie a réellement permis à l’utilisateur d’accomplir son travail à un niveau de qualité acceptable.

Cette distinction est essentielle lors de la comparaison des candidats au repli. Un modèle avec un taux de réponse élevé mais des échecs fréquents de schéma ou d’outil n’est pas un repli fiable.

Étape 3 : classer les candidats approuvés selon la politique

Un routeur de production peut attribuer un score aux cibles éligibles à l’aide de signaux opérationnels, sans prétendre qu’un seul modèle est universellement le meilleur.

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)
  );
}

Évitez une liste statique « primaire, secours, secours » pour chaque tâche. Le meilleur ensemble de repli pour la génération de code peut différer du meilleur ensemble pour l’extraction, la traduction, la vision ou l’exécution d’outils.

Étape 4 : valider la sortie de repli

Appliquez d’abord des vérifications déterministes :

• Validation JSON ou validation de schéma
• Vérifications des champs obligatoires
• Validation des arguments d’outil
• Vérifications du format des citations ou des URL
• Contraintes de longueur et de langue
• Motifs de sortie interdits

Puis ajoutez des contrôles qualité spécifiques au workflow. Il peut s’agir de règles légères, d’un évaluateur de tâche, d’une revue humaine échantillonnée ou d’un modèle juge validé. Si le seuil de qualité échoue, ne qualifiez pas le repli de récupéré.

Étape 5 : politique de déploiement progressif

Avant d’élargir un nouveau modèle de repli :

1. Relancez un jeu d’évaluation hors ligne.
2. Exécutez du trafic en ombre lorsque la politique le permet.
3. Activez le candidat pour un petit pourcentage des échecs éligibles.
4. Comparez le succès des contrats, le succès des tâches, la latence et le coût.
5. N’élargissez que si la valeur de récupération dépasse le risque de régression.

Suivez ces mesures avec un schéma d’observabilité de l’API LLM qui enregistre une route et un span par tentative.

Workflow 3 : arrêter, réconcilier ou escalader

Certains échecs ne devraient pas déclencher un autre appel au modèle. Le bon repli est un arrêt contrôlé.

Cas 1 : sortie de streaming partielle

Une fois que des jetons de réponse ont atteint l’utilisateur, le fait de changer de modèle en silence peut créer des contradictions, du contenu dupliqué, des blocs de code cassés ou un changement de style soudain. Cela rend aussi la réponse finale difficile à attribuer et à déboguer.

Utilisez plutôt l’un de ces résultats explicites :

• Terminez le flux avec une erreur récupérable et une action « réessayer ».
• Proposez de recommencer la réponse depuis le début.
• Ne continuez que si l’application dispose d’un protocole de reprise conçu à cet effet et que le nouveau modèle reçoit exactement le préfixe accepté.

La valeur par défaut devrait être allowAfterPartialOutput: false.

Cas 2 : effets secondaires d’outils incertains

Supposons qu’un modèle ait sélectionné un outil de paiement, d’e-mail, de déploiement, de ticket ou d’écriture en base de données. L’outil peut avoir réussi même si la connexion a échoué avant que votre orchestrateur n’enregistre le résultat. Rejouer le workflow complet peut dupliquer l’effet secondaire.

Protégez les outils d’écriture avec :

• Une clé d’idempotence basée sur l’opération utilisateur, et non sur la tentative du fournisseur.
• Un enregistrement d’exécution durable avec les états planned, started, succeeded, failed et unknown.
• La déduplication à la frontière de l’outil.
• Une requête de réconciliation avant tout nouveau rejouement.
• Une revue humaine pour les actions à fort impact qui restent incertaines.

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";
}

Conservez séparés les identifiants du fournisseur et les identifiants des outils. Le guide de gestion sécurisée des clés API couvre le modèle de secrets et de contrôle d’accès environnant.

Cas 3 : incertitude liée à la sécurité, aux permissions ou aux politiques

La disponibilité ne doit pas affaiblir une décision de sécurité ou d’autorisation. Si le candidat de repli ne prend pas en charge les contrôles de politique requis, la route est inéligible. Si le système ne peut pas déterminer si une opération est autorisée, refusez par défaut ou escaladez selon le modèle de risque du produit.

Cas 4 : aucun candidat ne satisfait au contrat

Renvoyez un échec typé que l’application peut gérer :

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

Une réponse dégradée claire vaut mieux qu’une réponse qui semble réussie mais viole le schéma, utilise les mauvais outils ou provoque le mauvais effet de bord.

Regroupez les trois workflows dans une seule machine à états

La couche d’orchestration doit rendre la transition explicite.

START
  -> PRIMARY_ATTEMPT
     -> SUCCESS: valider et retourner
     -> TRANSIENT + rejouable: WORKFLOW_1
     -> CONTRACT_FAILURE + alternative approuvée: WORKFLOW_2
     -> PARTIAL_OUTPUT or SIDE_EFFECT_UNCERTAIN: WORKFLOW_3

WORKFLOW_1
  -> réessayer dans la limite du budget
  -> bascule équivalente dans la limite du budget
  -> si une alternative compatible est autorisée: WORKFLOW_2
  -> sinon: STOP

WORKFLOW_2
  -> vérification des capacités
  -> tentative sur l’alternative
  -> validation du contrat et de la tâche
  -> retour uniquement en cas de succès validé
  -> sinon: STOP

WORKFLOW_3
  -> marquer l’état partiel ou incertain
  -> réconcilier les effets de bord externes lorsque c’est possible
  -> proposer un redémarrage explicite ou une escalade humaine
  -> ne jamais rejouer silencieusement un travail dangereux

C’est aussi la bonne limite pour une passerelle multi-modèles. Centraliser l’accès aux modèles derrière un endpoint compatible OpenAI peut réduire la duplication d’intégration, mais l’application doit toujours fournir l’intention du workflow : échéances, mode d’effets secondaires, outils requis, version du schéma et indication si le repli inter-modèles est autorisé. Flatkey fournit une couche d’accès API unifiée pour les équipes qui veulent une seule clé et une seule surface d’intégration sur plusieurs fournisseurs de modèles ; la politique de routage la plus sûre commence toujours par des contrats applicatifs explicites.

Checklist de déploiement de la stratégie de repli des modèles

Politique

• [ ] Chaque classe de route dispose d’une enveloppe de repli.
• [ ] Les erreurs récupérables sont normalisées entre les fournisseurs.
• [ ] Le budget total de retry a un seul propriétaire.
• [ ] Les endpoints équivalents sont distingués des modèles alternatifs.
• [ ] Les candidats de repli inter-modèles disposent de contrats de capacité versionnés.
• [ ] Un output partiel désactive par défaut le repli transparent.
• [ ] Les outils côté écriture utilisent des enregistrements d’idempotence durables.

Validation

• [ ] Le transport, le contrat et la réussite de la tâche sont mesurés séparément.
• [ ] Les sorties structurées sont validées après le repli.
• [ ] Les arguments d’outils et le comportement de tool-choice sont testés par modèle.
• [ ] Les ensembles d’évaluation du repli représentent des classes de routes réelles.
• [ ] Les nouveaux candidats passent une évaluation hors ligne et un canari en production.

Opérations

• [ ] Chaque tentative enregistre la raison de routage, la cible, la latence et le résultat.
• [ ] Les tableaux de bord affichent séparément le primaire, le retry, le basculement équivalent et la récupération inter-modèles.
• [ ] Les alertes incluent l’épuisement des délais et les taux de no-eligible-fallback.
• [ ] Les disjoncteurs utilisent des sondes half-open contrôlées.
• [ ] La revue d’incident inclut la qualité visible par l’utilisateur et le risque de double effet secondaire.

Métriques qui prouvent que le repli est utile

N’optimisez pas uniquement le taux d’erreur du fournisseur. Suivez le résultat utilisateur.

Segmentez ces métriques par classe de route. Un taux de récupération agrégé peut masquer le fait que le repli fonctionne bien pour l’extraction mais mal pour la génération de code ou l’utilisation d’outils.

Questions fréquemment posées

Qu’est-ce qu’une stratégie de repli des modèles ?

Une stratégie de repli des modèles est une politique permettant de décider quand une requête d’IA doit réessayer la même cible, basculer vers une capacité équivalente, passer à un modèle alternatif approuvé ou s’arrêter parce qu’un renvoi serait dangereux.

Quelle est la différence entre retry et fallback ?

Un retry répète la requête vers la même cible ou le même déploiement. Un basculement vers une capacité équivalente déplace la requête vers une capacité destinée à préserver le même contrat de modèle. Le fallback inter-modèles change le modèle et nécessite donc une validation des capacités et de la qualité.

Une erreur 429 doit-elle toujours déclencher un autre modèle ?

Non. Classez d’abord la limite, respectez les consignes de retry, vérifiez le délai restant et utilisez un retry borné ou une file d’attente. Le changement de modèle peut aider lorsqu’une capacité alternative approuvée existe, mais il peut aussi modifier la qualité de sortie, le comportement des outils ou le coût.

Une réponse en streaming peut-elle basculer au milieu de la réponse ?

Il est généralement plus sûr de ne pas changer de manière transparente après que des jetons ont été transmis à l’utilisateur. Arrêtez le flux et proposez un redémarrage explicite, sauf si l’application dispose d’un protocole de reprise testé.

Combien de modèles de repli une route devrait-elle avoir ?

Utilisez le plus petit ensemble approuvé qui offre une véritable capacité de récupération. Chaque candidat ajoute du travail d’évaluation, de surveillance et de réponse aux incidents. Une longue liste non testée n’est pas de la résilience.

Où la logique de repli devrait-elle se trouver ?

Centralisez la normalisation des fournisseurs, le routage, les budgets de tentatives et l’observabilité dans une passerelle ou une couche d’orchestration. Gardez l’intention spécifique au workflow — risque d’effets de bord, exigences de schéma, politique de sécurité et seuils de qualité — au plus près de l’application.

Construire le repli autour du risque du workflow

La meilleure stratégie de repli des modèles n’est pas « essayer le modèle suivant ». C’est un système de décision borné :

• Workflow 1 récupère les requêtes rejouables avec des retries et une capacité équivalente.
• Workflow 2 change de modèle uniquement après des vérifications de capacité et de qualité.
• Workflow 3 arrête le renvoi automatique lorsque la sortie ou les effets de bord rendent la récupération dangereuse.

Cette conception améliore la disponibilité sans masquer les défaillances de contrat ni dupliquer les actions de l’utilisateur. Si votre équipe standardise l’accès entre plusieurs fournisseurs de modèles, utilisez la couche d’API unifiée compatible OpenAI de Flatkey comme surface d’intégration, puis attachez ces enveloppes spécifiques à chaque workflow à chaque route de production.

Sources et lectures complémentaires

• Codes d’erreur de l’API OpenAI
• Sorties structurées OpenAI
• Erreurs de l’API Anthropic
• Messages en streaming Anthropic
• Modèle AWS de retry avec backoff
• Modèle AWS circuit breaker
• Stratégie de retry Google Cloud