Deux configurations doivent figurer dans une revue de mise à niveau : celle déjà acceptée pour la tâche et le remplacement proposé. Sans preuve pour les deux, l'équipe peut décrire le nouveau logiciel mais ne peut expliquer le changement dans son propre flux de travail. Notre recommandation est d'intégrer un enregistrement d'acceptation dans la mise à niveau, avant que l'ancienne configuration ne disparaisse.
Cet article de rattrapage d'août a été recherché et publié en septembre. Il propose une méthode de revue pratique ; il ne rapporte pas un déploiement client mesuré ni ne promet une amélioration particulière.
Conservez l'ancienne décision
Commencez par la raison pour laquelle la configuration existante a été acceptée. Localisez l'identité du modèle, la version d'exécution, les entrées de test et les critères de revue. Si cet enregistrement n'existe pas, notez ce qui peut encore être vérifié et identifiez les parties manquantes. Ne reconstituez pas un test réussi de mémoire et ne le présentez pas comme une observation.
Maintenez l'ancienne configuration disponible via le processus normal de gestion des changements de l'organisation pendant que le candidat est évalué. Cela peut nécessiter d'enregistrer plus que le fichier modèle : la collection de documents, le modèle de prompt et les paramètres de l'application peuvent aussi affecter la tâche. Enregistrez les parties importantes pour le changement proposé.
Pour un déploiement partagé AI Server, nommez les flux de travail applicatifs qui dépendent du service. Un changement qui aide un flux de travail peut nécessiter une décision d'acceptation différente pour un autre. Traitez les utilisateurs du service comme faisant partie de la limite de revue plutôt que de supposer qu'une démonstration les représente tous.
Indiquez l'amélioration prévue
Une mise à niveau doit avoir une raison concrète. L'équipe peut rechercher un runtime supporté, une correction d'une défaillance connue ou de meilleurs résultats sur une tâche particulière. Rédigez cette raison sous une forme vérifiable. « Utiliser le modèle plus récent » nomme une action ; cela ne définit pas le bénéfice attendu.
L'aperçu du NIST sur l'AI RMF décrit la prise en compte de la fiabilité à travers la conception, l'utilisation et l'évaluation des systèmes d'IA.[1] Notre application de ce principe est de maintenir l'évaluation attachée au changement. Une décision d'acceptation précédente ne doit pas devenir silencieusement une preuve pour une configuration qui n'a jamais fait partie du test.
Indiquez également ce qui doit rester acceptable. Si le flux de travail exporte des données structurées, l'export doit toujours satisfaire son contrat de réception. Si les réviseurs dépendent des références sources, ces références doivent toujours soutenir la réponse. Ces conditions doivent figurer à côté de l'amélioration souhaitée, pas dans une liste de contrôle oubliée séparée.
Comparez le même travail
Utilisez l'ensemble d'entrées conservé pour les configurations ancienne et candidate. Appliquez les mêmes critères de revue. Enregistrez les changements de sortie importants pour la tâche, y compris les nouvelles défaillances. Un évaluateur ne doit pas avoir à deviner si un résultat favorable provient de la mise à niveau ou du remplacement des entrées de test difficiles.
MLCommons définit des benchmarks d'inférence avec des charges de travail et des conditions de qualité spécifiées.[2] La leçon transférable pour une revue interne est l'importance des conditions, et non un droit d'emprunter un résultat de performance externe. Mesurez le flux de travail réel et documentez la manière dont il a été exécuté.
Séparez la revue de la correction du chronométrage. Une réponse qui arrive plus tôt mais omet un élément requis ne respecte pas la règle d'acceptation. Une réponse plus longue qui n'apporte aucune preuve utile supplémentaire ne doit pas être considérée comme une amélioration simplement parce qu'il y a plus de texte à afficher.
Utilisez un enregistrement avec un espace pour le désaccord. Si deux réviseurs interprètent différemment une sortie, conservez l'exemple contesté et résolvez le critère d'acceptation. Moyenniser le désaccord peut masquer une ambiguïté dans la tâche elle-même.
Décidez avant d'élargir la modification.
La revue peut produire une décision restreinte : accepter le candidat pour le flux de travail testé, répéter un test nommé, ou conserver la configuration existante. Décrivez les preuves à l'appui de cette décision et les limitations restantes. Un essai réussi pour un ensemble de documents ne doit pas être décrit comme une approbation pour toutes les applications sur le serveur.
Définissez la procédure de retour en arrière avant le déploiement. Nommez qui peut prendre la décision et quelles preuves la déclencheraient. Gardez la procédure suffisamment spécifique pour être exécutée sous pression. Notre article compagnon sur le registre de sélection de modèle explique pourquoi l'identité exacte du candidat est importante ici.
La vue d'ensemble de la plateforme entreprise peut aider à cadrer la discussion sur le déploiement. La décision de mise à niveau doit toujours être liée à une tâche observée, sa règle d'acceptation et un enregistrement qu'une autre personne peut inspecter.
Références
- NIST. Cadre de gestion des risques liés à l'IA. Consulté le 12-09-2026.
- MLCommons. MLPerf Inference : Datacenter. Consulté le 12-09-2026.