Aller au contenu principal
Essentiel•8–12 heures

Laboratoire d’enveloppe de release pour le serving IA

Construisez un contrat de release gouverné pour un runtime IA : empreinte exacte modèle/configuration, contrôles de readiness, retries bornés, canary, rollback et vérification du runtime au lieu de supposer qu’un CI vert représente déjà la vérité de production.

serving IAenveloppes de releasevérification runtimedéploiement canaryrollbackingénierie de fiabilité

Scénario

Tâche

L’équipe modifie le modèle, le prompt, l’index de retrieval ou la configuration des tools et obtient un CI vert. La production peut pourtant exécuter une autre révision de modèle, un prompt périmé, un index incomplet ou d’anciens scopes de tools. Construisez une enveloppe de release qui lie le candidat vérifié au runtime réel et prouve que le canary et la production exécutent exactement la configuration testée.

Exécution pas à pas

1. Définissez une unité de release plus large qu’un commit Git

Résultat: L’équipe peut identifier sans ambiguïté la configuration comportementale réellement vérifiée.

Tâches

  • →Collecter l’empreinte code/modèle/prompt/retrieval/tools/policy/dépendances
  • →Conserver des identifiants de version immuables ou résolubles
  • →Attribuer un owner à chaque composant mutable
  • →Interdire les alias ambigus dans les preuves de production sans version résolue

Vérifications

  • ✓Une enveloppe approuvée correspond à une configuration reproductible
  • ✓Changer un alias de modèle ou un index de retrieval change l’empreinte
  • ✓Les secrets n’entrent pas dans l’artefact de preuve

2. Construisez le contrat de readiness et de panne

Résultat: Le runtime n’accepte pas de trafic lorsqu’une dépendance critique ou un état de policy n’est pas prêt.

Tâches

  • →Séparer liveness et readiness
  • →Définir timeout, cancellation et retries bornés
  • →Ajouter la santé provider/retrieval/tools
  • →Définir les modes dégradés et conditions d’arrêt

Vérifications

  • ✓Un échec de readiness n’est pas masqué par un liveness réussi
  • ✓Le budget de retries ne crée pas de retry storm
  • ✓Le mode dégradé n’élargit ni l’autorité ni le périmètre des données

3. Exécutez un rollout progressif

Résultat: Le candidat reçoit une exposition production bornée avant promotion complète.

Tâches

  • →Exécuter shadow ou replay lorsque possible
  • →Définir une cohorte canary
  • →Comparer qualité, fiabilité et coût à la baseline
  • →Enregistrer un verdict explicite promote/hold/rollback

Vérifications

  • ✓Une régression critique de safety ou d’autorité bloque la promotion quel que soit le score agrégé
  • ✓La fenêtre d’observation du canary correspond à la classe de risque
  • ✓La cible de rollback est vérifiée avant le rollout

4. Prouvez la vérité du runtime

Résultat: Le statut production est confirmé par une preuve runtime et non par la fin du pipeline.

Tâches

  • →Lire l’empreinte réelle du runtime
  • →La comparer à l’enveloppe approuvée
  • →Simuler un mismatch modèle/prompt/index périmé
  • →Conserver un artefact de vérification du deployment

Vérifications

  • ✓Un mismatch se termine par FAIL ou UNKNOWN, jamais PASS
  • ✓CI PASS ne remplace pas la vérification du deployment
  • ✓Le rollback est lui aussi confirmé par l’empreinte réelle du runtime

Critères d’acceptation

  • L’enveloppe versionne code, modèle, prompt, retrieval, tools, policies, dépendances et dataset d’évaluation
  • Readiness contrôle les dépendances IA critiques avec des règles bornées de timeout/retry/cancellation
  • Le canary possède des critères explicites promote/hold/rollback et une cible known-good de rollback
  • La vérification production compare automatiquement l’empreinte runtime réelle à l’enveloppe approuvée
  • Une configuration runtime périmée ou divergente ne peut pas recevoir PASS