Évaluations de régression IA : comparer prompt, modèle et index à données constantes

Le nouveau prompt résout deux demandes qui échouaient auparavant. Le tableau de synthèse progresse et l’équipe prépare la mise à jour. Une troisième demande, correctement refusée par l’ancienne version, obtient maintenant une source d’une autre société. La perte est grave, mais elle se cache dans un résultat moyen meilleur. La décision de version doit retrouver cette paire avant que le changement atteigne les utilisateurs.

En pratique, une évaluation de régression compare les mêmes demandes, attentes et règles de jugement, puis examine ce qui a été gagné et perdu. Elle doit aussi vérifier que ces résultats appartiennent aux configurations annoncées. L’industrialisation et gouvernance d’un système IA relie ce contrôle à la version déployable, au périmètre autorisé et à la personne qui décide de poursuivre ou de bloquer la promotion.

Nous utilisons huit cas entièrement fictifs et deux séries JSON écrites à la main. Un contrôleur exécuté calcule leurs différences et bloque les comparaisons incompatibles ; aucun modèle n’a produit ces sorties. La recette d’une IA sur mesure utilisée par vos équipes doit permettre de retrouver la demande qui régresse, les deux sorties et les configurations comparées. Ces chiffres montrent pourquoi deux gains ne compensent pas une divulgation interdite ; ils ne mesurent pas une performance d’inférence.

Pour qui décider d’un changement déjà candidat

Protéger une capacité qui fonctionne déjà

La démarche concerne une équipe qui modifie un prompt, un modèle, une configuration de recherche ou un outil dans un service utilisé. Elle demande si la capacité utile reste acquise après ce changement. Le protocole peut protéger une non-réponse, une citation autorisée ou une préparation sans effet distant autant qu’une réponse complète. Un refus correct fait partie du comportement à conserver ; il ne constitue pas automatiquement un échec à éliminer.

Une suite exploratoire cherche les tâches que le système pourrait mieux traiter. Une suite de régression protège des attentes déjà établies. Elles peuvent partager des cas, mais leur fonction de décision diffère. Le cadre d’évaluation d’agents présenté par Anthropic distingue ces usages et insiste sur la lecture des traces. Notre méthode en fait un dossier de changement lié aux décisions métier du service.

Définir les défauts qui empêchent une promotion

Le responsable métier et la sécurité identifient les issues éliminatoires avant la comparaison. Une réponse incomplète et une divulgation inter-sociétés ne peuvent pas se compenser simplement dans une moyenne. Les autres écarts doivent aussi garder leur conséquence : travail de correction, délai de traitement, abstention excessive ou mauvais rattachement. Le verdict de lancement dépend de ces conséquences et du périmètre que le service souhaite ouvrir.

Un service purement démonstratif peut rester dans une recette limitée, sans promotion publique. Une famille nouvelle de questions exige d’abord des attentes et une couverture suffisantes. Ajouter sa difficulté à une suite historique puis comparer deux taux sur des populations différentes n’explique pas une régression de version. Le choix initial des cas et de leurs groupes est traité dans le jeu d’évaluation IA couvrant les cas rares.

Conserver la population et les attentes comparées

Apparier les résultats par identité de cas

Une ligne de résultat doit retrouver demande, périmètre, sources disponibles et attente applicable. Deux fichiers de huit lignes ne contiennent pas nécessairement les mêmes huit cas. Les résultats sont donc appariés par une identité stable, puis le contrôleur vérifie les manquants et les doublons. Une réponse absente ne devient pas un succès ni un cas discrètement retiré du dénominateur ; son statut reste distinct jusqu’à explication.

Le référentiel conserve également les variantes liées à une même demande. La répétition d’un dossier ne crée pas une observation indépendante et ne doit pas surpondérer un incident commode. Pour un diagnostic de changement, gardez groupe et tentative à côté du cas. L’identité doit permettre de comparer la même unité, sans confondre une variante de formulation avec une nouvelle situation métier.

Geler une attente sans nier son évolution future

Le jeu DS23-1 de notre exemple contient huit demandes et leurs propriétés attendues. Une empreinte du JSON canonique permet de constater qu’il s’agit de la même référence dans les deux séries. Modifier la demande, les sources autorisées ou l’issue attendue produit une autre version. L’empreinte ne certifie pas la justesse métier du référentiel ; elle rend visible le fait qu’une comparaison n’utilise plus la même matière.

Une attente peut légitimement changer lorsqu’une procédure ou une mission change. Cette révision doit alors être arbitrée et versionnée, puis les deux configurations réévaluées sur la nouvelle référence si l’on souhaite les comparer. Reclasser seulement l’échec du candidat en succès ferait disparaître la possibilité de constater une perte. Le journal explique le changement d’attente séparément du changement de système.

Identifier la version complète du service

Retrouver les éléments qui peuvent modifier la réponse

Une version IA comprend application, orchestration, prompt, modèle ou déploiement, paramètres, contrats d’outils, index, corpus et politique d’accès pertinents. Un nom de modèle ne décrit pas cet ensemble. Dans un RAG, une nouvelle indexation ou un filtre différent peut déplacer la réponse sans modification du prompt. Le dossier doit permettre de retrouver les composants effectivement servis à chaque tentative.

Le modèle et certains services fournisseurs peuvent garder une part variable derrière leur interface. Notez ce qui est figé, ce qui ne l’est pas et les identifiants observables à l’exécution. La présence d’une empreinte de prompt ne rend pas toute la chaîne déterministe. Elle permet de relier une trace à un contenu précis, à condition que le service journalise celui qu’il a réellement utilisé.

Isoler une modification pour expliquer son effet

Les manifestes fictifs gardent M-DEMO, I-1, C-1, G-1, ENV-1 et PARAM-1 ; seule l’étiquette de prompt passe de P-A à P-B. Cette déclaration rend la comparaison admissible au contrôleur, sans démontrer un effet du prompt : les sorties sont manuscrites. Avec un système réel, une modification à la fois facilite l’attribution, mais il faut encore observer ses résultats et leur variabilité.

Un candidat qui change simultanément prompt et index peut être comparé comme un ensemble destiné à la livraison. Il ne permet pas d’attribuer le gain à l’un de ces composants sans essais supplémentaires. Le mode du contrôleur présenté ici exige une modification unique pour ce diagnostic. Son refus « plusieurs composants » bloque cette attribution individuelle, pas toute possibilité d’évaluer une version composée.

Refuser une comparaison qui change sa référence

Faire passer une admissibilité avant le calcul des taux

Cas concret : le candidat omet V08, la demande dont le coût source est absent. Une moyenne sur les sept lignes restantes ne mesure plus la même population. Le contrôleur renvoie case_population_changed avant de produire un verdict comparatif. De même, un cas dupliqué, une empreinte de dataset différente ou un juge remplacé invalident le dossier pour la question « qu’a changé cette version sur cette référence ? ».

Les sept refus ont été provoqués séparément et vérifiés. Le jeu initial reste admissible ; les variantes ne s’accumulent pas. Le contrôleur examine des métadonnées et identités explicites, pas le contenu d’un service distant. Un environnement réel doit fournir des preuves honnêtes de ces valeurs : une étiquette C-1 conservée après modification du corpus rendrait le manifeste trompeur et le contrôle de compatibilité incapable de reconnaître ce changement.

Distinguer non comparable et moins bon

Un refus de comparabilité ne signifie pas que le candidat répond moins bien. Il signifie que la question comparative ne peut pas recevoir le verdict demandé avec ces pièces. La correction consiste à retrouver la série manquante, rejouer avec la bonne référence ou redéfinir explicitement la comparaison. Mettre « zéro » au candidat mélange un défaut de preuve avec une erreur fonctionnelle du système.

Le tutoriel Microsoft Databricks de comparaison d’évaluations conserve dataset et juges pour examiner une version améliorée. Le principe que nous appliquons est celui d’une référence retrouvable. Les services d’évaluation disponibles peuvent aider à enregistrer les séries ; leur présence ne garantit pas que l’équipe a gardé la même population ou la même interprétation du succès.

Séparer erreur de système et erreur de jugement

Choisir le contrôle adapté à la propriété

Une référence structurée de source autorisée, un identifiant ou un effet constaté peuvent recevoir une assertion explicite. Une réponse libre demande souvent une revue de son sens, de sa preuve et de ses réserves. Notre juge local compare issue, valeur, références de sources et effet déclarés dans les JSON fictifs. Il n’analyse pas sémantiquement un passage documentaire et ne vérifie pas une action dans un ERP.

Le métier a fixé les valeurs attendues du jeu : prix fictif de 40 EUR, devise EUR, demande de précision lorsque le stock manque et refus de source étrangère. Ces attentes constituent l’entrée du contrat d’évaluation. La sortie conserve verdict, motif et gravité. La responsabilité de cette référence reste humaine ; le code applique ses règles sans établir seul qu’elles couvrent toutes les situations d’une application.

Garder le juge stable pendant la comparaison

Si un évaluateur automatique change de prompt, de modèle ou de seuil, le taux peut bouger sans changement des réponses du service. Versionnez sa grille et sa configuration, puis examinez les désaccords avec les réviseurs. Une nouvelle calibration peut être utile, mais elle doit requalifier les deux séries pour conserver une lecture cohérente. Changer le juge seulement pour le candidat ferait entrer une deuxième expérience dans la comparaison.

Un jugement indéterminé garde un statut propre et une demande d’arbitrage. Il ne devient pas un succès par défaut ni une erreur éliminatoire inventée. Le journal précise les règles retenues après revue, les preuves examinées et la version de référence concernée. La relecture des traces peut révéler un défaut de grille, une source manquante ou une véritable régression ; ces causes n’appellent pas le même correctif.

Huit paires fictives et un défaut critique

Lire les issues avant leur moyenne

Second cas concret : la série de base invente un stock sur V02 et répond USD au lieu d’EUR sur V03. La candidate clarifie le stock manquant et corrige la devise. Mais elle répond à V04 avec FOREIGN_B, une référence interdite à cet utilisateur. Le juge marque cette source comme défaut critique et impose de bloquer la promotion. Les cinq autres paires restent acceptées selon le contrat synthétique.

« Acceptée » qualifie ici une sortie conforme à l’attente, même lorsqu’elle refuse l’action demandée. Sur V04, la base est acceptée précisément parce qu’elle refuse la source. Sur V05, le champ d’effet décrit le brouillon fictif attendu ; aucune création réelle n’est réalisée par le contrôleur. Le rapport de comparaison doit conserver ces significations pour éviter de confondre réussite de la recette et exécution d’une opération.

Vérifier une cause critique au niveau de sa paire

Le contrôle de V04 détecte une référence hors liste autorisée, une mauvaise issue et une valeur qui ne devrait pas exister dans cette sortie. La gravité vient de la source interdite, pas du seul nombre de propriétés différentes. Le rapport permet de retrouver les deux JSON et leur attente. Il ne dit pas si la cause réelle serait recherche, filtre de droits, prompt ou restitution : aucun de ces composants n’a été exécuté ici.

Dans une recette RAG réelle, il faudra retrouver passages récupérés, filtres effectifs et affirmations produites. Une erreur à la recherche peut être masquée par une réponse prudente, tandis qu’une bonne recherche peut être suivie d’une affirmation injustifiée. Le contrat RAG entre corpus, accès et preuve précise ces dimensions. La paire signale ce qu’il faut investiguer sans fabriquer sa cause.

Calculer la différence sans la réduire à une moyenne

Conserver gains, pertes et gravité ensemble

La base accepte 6 sorties sur 8, soit 75 %. La candidate en accepte 7 sur 8, soit 87,5 %. Le solde vient de deux gains et d’une régression ; cinq paires restent acceptées. Paradoxalement, le meilleur taux doit donc être bloqué par notre règle, car V04 introduit un défaut critique. Ces pourcentages décrivent seulement les JSON fictifs et ne permettent aucune estimation de fiabilité d’un service.

{
  "changedComponent": "prompt",
  "baselinePass": 6,
  "candidatePass": 7,
  "denominator": 8,
  "gains": 2,
  "regressions": 1,
  "stablePasses": 5,
  "gate": "blocked_critical_regression"
}

Le contrôle de promotion exige zéro défaut critique dans la candidate. Ce seuil est une décision locale du contrat illustré, pas une certification de sécurité. Une candidate sans défaut critique ne serait que recevable pour la suite de revue : budget, droits, dépendances et exploitation restent à valider. Le contrôleur ne donne pas automatiquement l’autorisation de déployer parce qu’un taux dépasse celui de la base.

Examiner la régression ordinaire sans cacher son coût

Une perte non critique peut parfois être acceptée pour un périmètre limité, mais elle exige un arbitrage documenté. Quelle population est touchée ? Quel travail revient au gestionnaire ? Quel repli conserve le service utile ? La moyenne générale ne répond pas à ces questions. Le coût caché apparaît lorsqu’un gain de formulation transfère davantage de dossiers vers une vérification humaine que l’équipe ne peut absorber.

La décision indique également les cas connus qui restent défaillants des deux côtés. Notre exemple n’en contient pas, mais un rapport réel ne doit pas les perdre au profit des seuls changements. Une régression et une limite historique ne sont pas la même alerte ; elles peuvent toutefois interdire la même ouverture. La priorité de correction dépend de la conséquence métier, de l’exposition et des solutions de repli disponibles.

Éprouver la variabilité et l’environnement réel

Répéter des tentatives qui gardent leur contexte

Une sortie d’inférence peut varier même pour une configuration et une demande identiques. Un essai par cas ne décrit pas cette dispersion. Définissez le nombre de tentatives et les critères avec l’équipe d’évaluation, puis gardez toutes les traces, y compris les échecs et les réponses indéterminées. Choisir uniquement la meilleure sortie de chaque version transforme une comparaison en sélection favorable.

Le banc de cet exemple applique une fois son juge déterministe à chaque sortie manuscrite. Il ne teste donc pas de variabilité de modèle et ne calcule pas d’intervalle statistique. Une évaluation réelle doit distinguer tentatives, groupes de demandes et causes communes. Plusieurs échecs liés à une même panne d’outil ne constituent pas nécessairement des observations indépendantes sur la qualité du modèle.

Réinitialiser ce qui pourrait aider une version suivante

Cache, mémoire de conversation, état d’outil et données modifiées peuvent influencer un nouvel essai. Le contrat de recette indique les éléments réinitialisés et ceux volontairement conservés. Le premier candidat ne doit pas laisser un brouillon ou un résultat de recherche qui donne au second un contexte supplémentaire. Pour un workflow à effets, les essais utilisent un environnement adapté et une preuve de restauration.

Le dossier d’entrée relie cette politique à la version de l’environnement ; le runbook précise comment vérifier la remise à l’état attendu. La sortie garde les exceptions et les essais invalidés. Si une dépendance externe a changé pendant la comparaison, l’équipe peut devoir rejouer les cas concernés. La traçabilité explique pourquoi une preuve est conservée, corrigée ou écartée sans réécrire l’historique du résultat.

Relier le contrôle de promotion au candidat

Empêcher une preuve ancienne d’accompagner un nouveau contenu

Le rapport valide une configuration précise. Une correction après recette change ce candidat et demande les contrôles pertinents avant promotion. Le pipeline rapproche empreintes et identifiants des composants évalués avec ceux de la livraison. Une variable de configuration modifiée à la main ou un index remplacé après les essais ne doit pas conserver le statut « testé » au seul motif que le ticket de travail est le même.

Les évaluations de modèles et applications décrites par Microsoft Foundry aident à organiser données, mesures et résultats. La décision de promotion appartient encore à votre dispositif. Le service garde le lien entre preuve et version, ainsi que les vérifications de droits et d’exploitation que la mesure de qualité ne couvre pas.

Préparer le retrait sans réutiliser une preuve périmée

Une version de repli doit rester compatible avec l’état courant des outils et du corpus. Revenir à un ancien prompt ne restaure pas forcément les anciennes sources ni leurs permissions. Le dossier de changement décrit ce qui peut être retiré, qui déclenche la décision et quelle capacité devient indisponible. Le rollback exige donc ses conditions d’applicabilité ; il ne se réduit pas à conserver une chaîne de caractères ancienne.

La supervision distingue erreurs nouvelles, refus attendus et changements d’environnement après ouverture. Un incident confirmé rejoint la suite de régression avec une attente arbitrée. Le traitement des instructions injectées dans les contenus et outils fournit des cas utiles lorsque la chaîne a confondu données et autorité. Leur ajout versionne la référence au lieu de maquiller une preuve antérieure.

Erreurs fréquentes dans la non-régression IA

Agréger avant de retrouver les cas perdus

Une première erreur compare deux taux sans vérifier le dénominateur. Une deuxième choisit le meilleur essai par version. Une troisième écarte un refus correct parce que la réponse paraît moins complète. Ces habitudes peuvent produire un tableau en progrès alors que l’usage a perdu une protection. Le rapport doit conserver identité de cas, issue attendue, verdict et gravité avant de construire sa synthèse.

Un signal faible est l’absence de lien entre une cellule rouge et sa sortie exacte. Un autre est une liste de cas modifiée pour chaque modèle sans justification de population. L’équipe doit pouvoir expliquer ce qui a été exécuté, sur quelle référence et avec quel juge. Une capture de moyenne ne permet pas de déterminer si la correction doit viser système, environnement ou grille de jugement.

Réparer le verdict plutôt que le défaut

Assouplir l’attente après avoir vu le candidat, changer le juge seulement pour cette série ou conserver un alias de version après modification efface le défaut de preuve. Une correction légitime de référence peut être nécessaire ; elle doit être relue et appliquée de façon cohérente. Le journal garde la raison et permet de retrouver ce que disait le contrôle précédent.

La démonstration n’affirme pas que P-B provoque une fuite ou qu’un modèle M-DEMO existe. Les étiquettes servent à tester le contrôleur sur des sorties fictives. Une équipe qui attribuerait directement les huit résultats au changement déclaré dépasserait la preuve. Le diagnostic causal demande les configurations exécutées, les traces et les essais complémentaires ; l’admissibilité du dossier est une condition, pas cette conclusion.

Plan d’action pour une première comparaison versionnée

Écrire la question de changement avant les résultats

Commencez par un candidat et une mission déjà qualifiés. Le propriétaire du service nomme la capacité à conserver, les défauts bloquants et le changement étudié. L’équipe d’évaluation retrouve la référence, les configurations et le juge. Ce cadrage doit distinguer une comparaison d’ensemble pour la livraison d’un diagnostic cherchant à attribuer un effet à un seul composant ; leurs critères d’admissibilité ne sont pas identiques.

1. Documenter cas, groupes, sources autorisées et attentes avec leur version. Conserver l’empreinte utile et les règles de traitement des réponses absentes ; vérifier que chaque résultat retrouve une identité du jeu.
2. Associer les séries à leur configuration réellement exécutée : prompt, modèle, index, corpus, outils, paramètres et environnement pertinents. Déclarer les éléments variables et les preuves qui permettent de constater leur changement.
3. Rapprocher population, référence et juge avant de calculer les taux. Refuser la comparaison incompatible ou rejouer les deux configurations sur un cadre commun, en gardant la raison de cette nouvelle exécution.
4. Examiner gains, régressions et gravité par paire, puis lire les sorties et les traces. Vérifier les jugements douteux avec le responsable métier ; distinguer une erreur de grille d’un défaut effectivement produit par le système.
5. Soumettre le candidat avec ses limites et son verdict de régression au circuit de promotion. Contrôler que la version livrée correspond à la preuve, prévoir la suspension et garder les conditions du repli applicable.

La sortie est un dossier de changement avec configurations, référence, résultats, écarts et décision motivée. Elle peut demander correction, essais complémentaires ou arrêt de promotion. Un candidat bloqué ne devient pas acceptable parce qu’un autre tableau affiche un gain moyen. Les critères locaux sont conservés avant la nouvelle tentative, et la correction doit fermer la cause en gardant les autres attentes intactes.

Garder une suite utile au fil des incidents

Après l’ouverture, les responsables ajoutent les incidents reproduits et les changements de mission à une référence versionnée. Ils évitent d’accumuler des variantes sans attente ou de laisser des critères métier obsolètes bloquer toute évolution. Chaque ajout possède une cause, une conséquence et un propriétaire d’arbitrage. L’automatisation du contrôle facilite les exécutions ; elle ne remplace pas cette maintenance de la signification du succès.

La suite de régression peut rester stable pour comparer les versions, tandis qu’un ensemble exploratoire ouvre de nouvelles difficultés. Un cas devenu acquis peut rejoindre la première après décision. Le suivi distingue ainsi progrès sur de nouvelles capacités et maintien des capacités existantes, sans prétendre qu’un taux élevé sur un petit jeu couvre toutes les demandes que les utilisateurs rencontreront.

Guides complémentaires pour la recette et l’ouverture

Choisir une référence qui éprouve les conséquences

Le jeu de test IA avec cas rares et erreurs graves construit la population, les attentes et les groupes avant l’évaluation. Il distingue situations fréquentes, issues critiques et abstentions utiles. Cette préparation évite qu’une suite de régression ne protège uniquement les demandes les plus simples ou les formulations déjà réglées pendant le développement.

Une fois cette référence décidée, le contrôle de changement conserve son identité et relie les nouvelles séries à leurs configurations. La moyenne doit rester lisible avec sa couverture et ses limites. Un changement de mission peut demander une nouvelle référence plutôt qu’une accumulation de tolérances qui rendrait impossible de savoir ce que le service devait conserver.

Insérer la comparaison dans une décision de lancement

Le dossier de lancement d’un système IA en production rassemble droits, exploitation, dépendances et preuves de version. La régression fonctionnelle en constitue une pièce, avec ses défauts et son périmètre. Elle ne prouve pas seule que l’astreinte sait suspendre une capacité ou que le gestionnaire pourra traiter les exceptions restantes.

Le candidat doit conserver les mêmes limites dans la recette, le dossier d’ouverture et la configuration livrée. Cette continuité empêche une équipe de promouvoir une capacité plus large que celle évaluée. Le rapport peut alors servir au support et à la gouvernance après la livraison, lorsque la question devient de retrouver ce qui a changé et quelle preuve reste applicable.

Conclusion : conserver ce que la version devait savoir faire

Une régression IA se juge sur des attentes et des configurations retrouvables. Même population, même référence et même juge permettent de lire ce qui a été gagné ou perdu. Les changements du cadre restent possibles, mais ils doivent être déclarés et réévalués ; ils ne servent pas à effacer les défauts d’un candidat sous une moyenne plus favorable.

Le contrôleur exécuté sur huit paires fictives constate deux gains, une régression critique et cinq succès stables. La candidate passe de 6 à 7 sorties acceptées sur 8, mais sa promotion reste bloquée. Sept variantes incompatibles sont également refusées avant comparaison. Ces résultats éprouvent les contrôles de comparaison et de promotion ; aucun prompt, index ou modèle réel n’a été évalué par cette démonstration.

L’industrialisation des versions IA ajoute les exécutions réelles, leurs traces et leur variabilité, puis rapproche la preuve du candidat livré. La décision conserve les défauts bloquants, les arbitrages et le repli applicable. Une évolution utile améliore le service sans perdre silencieusement la capacité ou la protection qu’il devait maintenir.

Dawap accompagne les changements de version de votre IA sur mesure en conservant les paires de réponses et leurs conditions d’exécution. Avec le responsable du service, nous définissons quels défauts bloquent la promotion et comment reconnaître un corpus ou un juge modifié. La revue peut alors accepter les gains, refuser une régression précise ou demander une nouvelle comparaison avant de déployer.