Changer de modèle IA : comment repérer ce que la nouvelle version dégrade

Un modèle mieux classé peut dégrader votre assistant sur une tâche précise. Avant de le remplacer, il faut faire passer l’ancienne et la nouvelle configuration sur les mêmes situations, observer les erreurs nouvelles et décider quelles dégradations sont inacceptables. Un test de non-régression protège les comportements déjà utiles ; il ne cherche pas seulement une meilleure moyenne.

Cet article propose un protocole pour une équipe qui dispose déjà d’un assistant documentaire. Il complète le dossier sur les conditions de comparaison des benchmarks : ici, la question est de savoir si une modification déterminée peut être livrée à des utilisateurs existants.

Définir exactement ce qui change

« Nouveau modèle » est une description insuffisante de l’expérience. Le résultat dépend aussi des instructions, des documents accessibles, des outils, des paramètres et du logiciel qui assemble ces éléments. Si plusieurs composants changent simultanément, le test évalue le nouveau système complet. Il ne permet pas d’attribuer chaque différence au seul modèle.

Préparer une fiche avec identifiant précis de modèle, date, version des instructions, version documentaire, paramètres disponibles et environnement d’exécution. Si un service ne donne pas accès à une version immuable, le signaler. On peut comparer deux observations datées sans prétendre pouvoir les reproduire indéfiniment à l’identique.

Le NIST AI RMF fournit un cadre volontaire pour intégrer l’évaluation et la gestion des risques dans le cycle de vie. Le protocole présenté ici est une adaptation éditoriale pratique, pas une certification délivrée par le NIST.

Construire trois familles de cas

Un corpus uniquement composé de questions faciles montre ce que le service sait déjà faire. Pour protéger un usage réel, proposer trois familles distinctes : demandes courantes, difficultés connues et interdits. Cette séparation rend une régression localisable.

Famille	Exemple pédagogique	Résultat attendu
Demande courante	Retrouver une procédure présente dans le corpus autorisé	Réponse correcte avec référence vérifiable
Difficulté connue	Deux documents donnent des consignes incompatibles	Identifier le conflit sans choisir arbitrairement
Information absente	La date demandée n’existe dans aucun document	Dire ce qui manque, sans inventer
Droit d’accès	La réponse existe seulement dans un document interdit au compte	Ne pas révéler son contenu
Action sensible	Une demande ambiguë pourrait déclencher une modification	Respecter le niveau d’autorisation prévu

Ce sont des exemples de conception de test, pas des observations sur un produit particulier. Pour les cas réels, retirer les données inutiles et vérifier que leur réutilisation est autorisée. Un corpus de test peut lui-même devenir une copie sensible de documents internes.

Conserver une partie des cas hors des séances d’amélioration. Sinon, l’équipe risque de corriger les exemples qu’elle connaît sans savoir si le comportement se généralise. Le nombre de cas doit être justifié par la diversité et les conséquences des erreurs ; aucun nombre rond ne garantit une couverture suffisante.

Écrire les critères avant de lire les réponses

« Réponse satisfaisante » laisse trop de place à l’interprétation. Transformer l’attente en critères observables : le bon document est-il cité ? La date correspond-elle à la source ? Une information absente est-elle reconnue ? Une action non autorisée a-t-elle été exécutée ?

Séparer les critères bloquants des préférences. La confidentialité ne se compense pas par une formulation plus agréable. Une réponse légèrement longue peut rester utilisable, alors qu’une seule donnée inventée peut rendre un cas invalide. Cette hiérarchie doit venir du service attendu et du risque, pas du score qui arrange le mieux la nouvelle version.

Pour les sorties structurées, vérifier automatiquement le format et les champs obligatoires. Pour une explication, une comparaison humaine selon une grille peut être nécessaire. Le fait qu’une réponse ressemble au texte de référence ne démontre pas qu’elle respecte toutes les contraintes du cas.

Lire les transitions, pas seulement les totaux

Voici un exemple entièrement fictif sur 100 cas, avec un critère binaire de réussite fixé à l’avance.

Transition entre ancienne et nouvelle version	Nombre fictif
Réussite conservée	82
Échec corrigé	10
Nouvelle régression	5
Échec conservé	3

L’ancienne version réussit 87 cas ; la nouvelle en réussit 92. Le gain net est de cinq points. Mais cinq cas auparavant réussis échouent désormais. Si l’un révèle une information interdite, la moyenne de 92 % ne règle pas le problème.

La fiche de décision doit donc montrer chaque nouvelle régression, son impact et son statut. Une erreur réparée ne neutralise pas automatiquement une erreur introduite ailleurs. Le résultat peut conduire à limiter le déploiement à certaines tâches, à corriger une instruction ou à maintenir la version actuelle.

Traiter la variabilité comme une observation

Une exécution unique peut être insuffisante lorsque les sorties varient. Répéter les cas sensibles permet d’observer cette variabilité, à configuration documentée. Il faut compter les répétitions et conserver les échecs, pas sélectionner la meilleure réponse pour chaque version.

Distinguer également absence de réponse, erreur technique, réponse incorrecte et résultat inutilisable pour dépassement de délai. Les retirer du tableau favorise artificiellement la configuration qui échoue le plus souvent à produire une sortie. Un coût ou une latence ne devient comparable que si le traitement de ces événements est identique.

Sur un petit échantillon, éviter de présenter une différence minime comme une supériorité établie. L’incertitude dépend notamment de la sélection des cas et de la variabilité observée. Une collection de cas choisis par l’équipe sert à vérifier ces situations ; elle ne mesure pas automatiquement un taux d’erreur dans toute la population des utilisateurs.

Un modèle juge doit lui aussi être évalué

Faire noter les réponses par un autre modèle peut accélérer le tri, mais ajoute un système d’évaluation avec ses propres limites. La documentation Google sur l’évaluation d’un modèle juge demande de comparer ses scores à des évaluations humaines adaptées au cas d’usage. Elle distingue notamment notation d’une sortie et préférence entre deux sorties.

Dans le protocole proposé, masquer l’identité des versions, alterner l’ordre de présentation et examiner les désaccords. Conserver la justification du juge sans la traiter comme une preuve. Les cas touchant aux droits d’accès ou aux actions autorisées doivent aussi être contrôlés sur les traces effectives du système, pas uniquement sur ce que la réponse affirme avoir fait.

Livrer avec une condition de retour arrière

Un test préalable ne couvre pas toutes les situations futures. Préparer le retour à la configuration précédente, les indicateurs à surveiller et la personne responsable de la décision. Le retour doit inclure les composants modifiés : restaurer seulement le nom du modèle ne suffit pas si les instructions ou le stockage ont aussi changé.

La dérive d’un système IA concerne l’évolution dans le temps ; le test de non-régression traite ici un changement identifié. Les deux se complètent. La livraison peut être acceptée pour un périmètre documenté, avec des limites connues, sans être déclarée fiable dans tous les usages.

Sources et portée

Sources consultées le 22 octobre 2026 : NIST, AI Risk Management Framework ; Google Cloud, Evaluate a judge model, documentation actualisée le 21 octobre 2026. Les familles de cas, le tableau de transition et les conditions de livraison sont des propositions méthodologiques de Pnebbula. Aucun résultat de modèle commercial n’est revendiqué.