Migrer un agent d’un modèle à l’autre sans régression

Migrer un agent d’un modèle à l’autre consiste à remplacer le modèle de langage qui l’anime, sans changer sa fonction, en vérifiant que son comportement reste au moins aussi bon sur les cas métier réels. C’est une opération devenue routinière, et toujours risquée.

Un système en production peut devoir changer de modèle : parce que le fournisseur déprécie une version, parce qu’un modèle moins cher fait aussi bien, ou parce qu’une nouvelle génération sort.

Cette opération est traitée comme une mise à jour de dépendance. Elle n’en est pas une : le comportement change de façon diffuse, sur des cas que les tests techniques seuls ne représentent pas. Quand le changement est subi plutôt que choisi, le scénario ressemble à celui décrit dans le jour où le modèle a changé sans prévenir.

L’erreur la plus commune lors d’une migration de modèle consiste à tout changer d’un coup, modèle et prompts ensemble, ce qui rend impossible d’attribuer une régression à sa cause. Ce que je vois régulièrement : on profite du changement de modèle pour retoucher les prompts, parce qu’on sait que le nouveau modèle « préfère » d’autres formulations.

Résultat : quand la qualité bouge, on ne sait pas si c’est le modèle ou le prompt. Et comme la mesure porte sur l’ensemble, on ne peut pas revenir en arrière partiellement.

La règle est donc stricte : d’abord le modèle seul, à prompt identique, mesuré. Ensuite seulement, l’optimisation du prompt pour le nouveau modèle, mesurée à son tour.

La migration d’un agent sans régression suit quatre étapes : changer le modèle seul, ajuster ensuite le prompt, basculer le trafic par paliers et consigner les mesures. Chaque étape est mesurée avant de passer à la suivante.

1. Changer le modèle seul, à prompt identique, et rejouer le jeu de tests métier. C’est cette mesure qui dit ce que le modèle change.
2. Ajuster le prompt pour le nouveau modèle, puis rejouer le même jeu. Le gain ou la perte est alors attribuable.
3. Basculer par paliers : une petite part du trafic d’abord, avec comparaison du taux de correction humaine entre les deux populations, puis élargissement.
4. Consigner la version remplacée, la version installée et les mesures avant et après.

Le jeu de tests de l’étape 1 doit exister avant la migration ; la méthode pour le constituer figure dans construire un jeu de tests en une journée.

La comparaison avant migration couvre la réussite métier, les cas critiques, les formats, les refus et les coûts, en examinant chaque dimension séparément.

• Le taux de réussite sur le jeu de tests métier, cas par cas et pas seulement en moyenne.
• Les cas qui basculent : un modèle peut améliorer la moyenne en dégradant précisément les cas critiques.
• Le respect du format : la régression la plus fréquente et la plus silencieuse, quand la sortie doit être structurée.
• Le comportement en l’absence d’information : le nouveau modèle refuse-t-il toujours de répondre quand il ne sait pas ?
• Le coût et la latence réels, mesurés sur les mêmes cas et non sur la grille tarifaire.

Une migration de modèle doit être bloquée dès qu’un cas critique bascule, que la validité du format baisse ou que le modèle cesse de refuser quand l’information manque, même si la moyenne progresse. La moyenne ne suffit jamais à décider.

Le refus est un comportement à préserver, pas un défaut à corriger, comme l’explique le refus de répondre est une fonctionnalité. Le coût se mesure par tâche, selon la méthode de mesurer le coût par fonctionnalité.

Un modèle plus capable peut respecter moins strictement un format de sortie contraint, et cette régression passe souvent inaperçue en test pour se révéler en production. C’est le défaut le plus coûteux d’une bascule.

Un exemple illustratif : un système qui attend une sortie structurée fonctionne parfaitement sur les trente cas du jeu de tests, puis échoue sur une petite fraction du trafic réel parce que le nouveau modèle ajoute une phrase d’introduction, ou change une casse. Même une sortie invalide de temps en temps suffit à casser une chaîne automatisée, alors que les autres réponses sont meilleures qu’avant.

Le jeu de tests doit donc mesurer la validité du format séparément de la justesse du contenu. La parade n’est pas dans le prompt : c’est une validation stricte de la sortie, avec reprise bornée lorsque cette reprise ne répète pas un effet externe, et une alerte si le taux de reprise dépasse un seuil.

Les sorties contraintes par un schéma réduisent certains défauts syntaxiques, sans garantir la justesse métier ni exclure un refus ou une sortie interrompue, et il subsiste sur tout ce qui n’est pas contraint par un schéma. C’est le raisonnement de sorties structurées.

Les paliers d’une bascule progressive se choisissent selon le risque, le volume observé et la capacité de retour, avec des conditions d’arrêt définies avant l’exposition. Une petite part du trafic peut révéler des cas absents des tests, sans garantir de tous les rencontrer.

Le chapitre Canarying Releases de Google décrit ce principe de comparaison progressive. Fixez les indicateurs, le responsable et la procédure de retour avant de lancer le palier. N’élargissez pas sur la seule absence d’alerte si trop peu de cas critiques ont été observés.

Deux prérequis rendent une migration de modèle maîtrisable : une couche d’abstraction qui isole l’appel au modèle et un jeu de tests métier maintenu, tous deux posés bien avant le premier changement. Rien de ce qui précède n’est réalisable sans eux.

C’est pour cela que je les installe dès la première semaine d’une mission, même quand le système ne compte que trois cas d’usage. Leur utilité apparaît lors des changements et des incidents ; les ajouter tardivement demande de reconstituer des contrats qui n’avaient pas été explicités.

Quand les générations de modèles se succèdent à un rythme soutenu, la migration n’est plus un événement mais une routine, et la question n’est plus de l’éviter mais de la rendre indolore. Les deux prérequis font toute la différence.

Une équipe disposant de ces prérequis peut isoler les étapes : changer l’identifiant, rejouer les cas, comparer et basculer par paliers, avec un effort dépendant du périmètre.

Sans ces prérequis, il faut d’abord identifier les appels dispersés et construire une référence de comportement. L’écart d’effort initial est faible, l’écart cumulé sur plusieurs années est considérable, comme détaillé dans la couche qui rend le modèle remplaçable.

À chaque migration, il faut consigner quelle version était en service, quelle version l’a remplacée, et ce que le jeu de tests a mesuré avant et après. Ces informations doivent renvoyer aux configurations et résultats complets, plutôt qu’à une simple appréciation.

Leur absence produit une situation fréquente en reprise : un système qui fonctionne moins bien qu’avant, sans que personne ne puisse dater le changement ni identifier ce qui l’a causé. La démarche pour s’en sortir est décrite dans reprendre un système d’IA construit par quelqu’un d’autre.

Cette consignation contribue au dossier de suivi des changements ; sa périodicité dépend des évolutions et des obligations applicables. Pour vérifier qu’un système est prêt à changer de modèle sans risque, un audit IA examine précisément ces deux prérequis et cette trace.

Lectures complémentaires : préparer un contrôle de conformité en deux semaines. Ces liens complètent la navigation du site.

Avant une migration, l’équipe doit définir la comparaison, la validité des sorties, la progression du trafic et les traces nécessaires pour revenir à la version précédente.