Définit le comportement souhaité, les limites, les réponses en cas d’échec, les contrôles humains et les exigences de sécurité pour le repli de modèle. Cette référence fixe la limite d’adoption, le comportement en cas d’échec et les preuves observables tout en laissant les limites spécifiques à l’environnement configurables.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n’est faite quant à la réussite de leur passage par une implémentation adoptante.
Décision
Pour le repli de modèle, adopter une politique d’orchestration versionnée et une limite explicite d’appel de modèle. Rendre explicite la promesse visible par l’utilisateur, les exclusions, l’autorité et la réponse en cas d’échec tout en laissant les seuils mesurés comme choix d’adoption. Ce bloc d’exigences se concentre spécifiquement sur les exigences et la politique. Ce package est un contrat de référence : l’équipe adoptante doit choisir les limites numériques, les fournisseurs, les juridictions et les responsables opérationnels à partir des preuves dans son propre environnement.
Portée
- Les acteurs, entrées, sorties, états, versions de politique ou de schéma, et résultats visibles de l’extérieur du repli de modèle requis pour le focus exigences et politique de ce bloc d’exigences.
- Interfaces principales et alternatives, travaux en arrière-plan, caches, intégrations, chemins de support et preuves pouvant exercer la même limite.
- Configuration spécifique à l’adoption, déploiement, récupération et responsabilités de vérification nécessaires pour appliquer la référence en toute sécurité.
Hors de ce bloc
- Choisir un fournisseur universel, un cadre, une juridiction, un seuil numérique, une période de rétention ou un objectif de niveau de service pour chaque adoptant.
- Affirmer que les scénarios packagés ont été exécutés contre une implémentation en aval ou que cette référence accorde une certification légale, de sécurité ou d’accessibilité.
Contrat
- Conserver les versions du prompt, outil, récupération, modèle et politique nécessaires pour reproduire ou expliquer chaque résultat matériel.
- Valider la sortie structurée avant tout effet secondaire ; une sortie malformée ou incomplète est une erreur, pas une autorité partielle.
- Séparer le contenu utilisateur non fiable ou récupéré de la politique système et étiqueter chaque élément de contexte avec son origine et sa classe de confiance.
- Limiter les tokens, appels d’outil, latence et dépenses par requête ; dépasser une limite entraîne un repli nommé au lieu de continuer sans limite.
- Indiquer quel acteur reçoit quel résultat sous chaque état matériel, y compris indisponible, non autorisé, vide et partiel.
- Marquer les limites et politiques configurables comme choix avec propriétaires ; ne pas présenter de valeurs d’exemple comme exigences universelles.
- Déclarer l’ordre de repli par capacité, politique de sécurité, région de données, latence, coût, longueur de contexte et contrat de sortie plutôt que de substituer aveuglément un modèle disponible.
- Revalider les entrées et sorties à chaque limite de fournisseur, exposer la dégradation matérielle de qualité et préserver une identité d’opération unique pour que le repli ne puisse pas répéter les outils ou effets secondaires.
- Pour la variante exigences et politique, appliquer cette limite déclarée : définit le comportement souhaité, les limites, les réponses en cas d’échec, les contrôles humains et les exigences de sécurité pour le repli de modèle.
Guide de mise en œuvre
- Examiner le contrat avec le produit, l’implémentation, les opérations, la sécurité et les utilisateurs concernés avant de le promouvoir au-delà de la revue.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves du repli de modèle avant de sélectionner les détails du cadre ou du fournisseur.
- Stocker la version applicable du contrat ou de la politique de repli de modèle avec l’état matériel pour que les migrations, rejouages et décisions de support restent attribuables.
- Introduire le chemin derrière un déploiement contrôlé, comparer les résultats attendus et observés, et conserver une route de récupération testée jusqu’à ce que les preuves d’adoption soient complètes.
Gestion des échecs et protections
- Échec du fournisseur, sortie non sécurisée ou budget épuisé retourne un repli borné et conserve des preuves diagnostiques sûres pour la corrélation.
- État de repli de modèle invalide ou contradictoire est rejeté ou mis en quarantaine ; l’implémentation ne devine jamais une valeur qui élargit l’autorité ou duplique un effet.
- Les tentatives sont limitées et utilisent une identité durable ; après épuisement, le travail atteint un état terminal inspectable avec un propriétaire responsable.
Vérification et opérations
- Associer chaque promesse et exclusion à au moins un scénario observable et confirmer qu’aucun état ne requiert des résultats contradictoires.
- Surveiller le succès, le refus, l’échec de validation, l’échec de dépendance, l’épuisement des tentatives et la récupération du repli de modèle par version de contrat sans dimensions sensibles de charge utile.
- Relancer les fixtures positifs et négatifs appariés après changements de politique, schéma, dépendance, migration ou limite et conserver les preuves résultantes.
Hypothèses d’adoption
- Les noms et valeurs dans l’exemple sont un fixture concret, pas des valeurs par défaut universelles ; les adoptants les remplacent par des preuves et une propriété documentées.
- Le système adoptant peut fournir une identité authentifiée, des versions durables d’opération ou d’enregistrement, une télémétrie bornée et un chemin contrôlé pour le changement.
Les exemples à l’apparence exécutable dans ce package sont des fixtures et contrats d’acceptation. Exécutez le validateur de collection pour vérifier la structure et les métadonnées, puis traduisez et exécutez les scénarios dans le dépôt cible avant d’enregistrer les preuves d’implémentation.
Références
- NIST AI 600-1, Profil d’IA générative (applicable à partir du 2026-09-08)