Changer de modèle de base IA sans perte de qualité : Evals, Canary et Rollback

Un nouveau modèle de base IA promet souvent de meilleures réponses, des coûts réduits ou des temps de réaction plus courts. Pour un chatbot de site web en production, ce changement ne s'apparente toutefois pas au simple remplacement d'un paquet logiciel quelconque. Une simple mise à jour de version de modèle peut pondérer différemment les instructions, formuler des réponses plus détaillées, générer des données structurées divergentes ou appeler des outils dans un ordre différent. Une migration n'est donc réussie que si le chatbot accomplit ses tâches concrètes au moins aussi fiablement qu'auparavant — et si l'équipe peut revenir en arrière en quelques minutes en cas de problème.

Les fournisseurs annoncent régulièrement la fin de vie de leurs modèles. La documentation d'OpenAI sur les dépréciations répertorie les dates d'arrêt et les modèles de remplacement recommandés ; Anthropic distingue dans son cycle de vie des modèles les statuts « Active », « Legacy », « Deprecated » et « Retired ». Ces échéances sont l'occasion de la migration, mais pas sa preuve de qualité. Seule une procédure de test et de déploiement adaptée à votre propre chatbot peut apporter cette preuve.

Ce qui change réellement lors d'un changement de modèle de base

Ce processus doit être clairement distingué d'une migration du modèle d'embedding . Lors d'un changement d'embedding, les documents doivent être re-vectorisés et les index de recherche doivent rester compatibles. Lors d'un changement de modèle de base, l'index de recherche reste généralement inchangé ; c'est le modèle qui génère la réponse à partir de l'instruction système, de la conversation, des sources trouvées et des résultats d'outils qui est modifié. On teste donc le comportement de réponse, l'ancrage dans les sources, le format, l'utilisation des outils, la sécurité, la latence et les coûts.

De même, un test général en Shadow Mode avant le lancement sur le site web ne résout qu'une partie du problème. Le trafic Shadow peut alimenter deux modèles avec les mêmes entrées sans distribuer la nouvelle réponse. Le changement de modèle de base décrit ici va plus loin : il définit au préalable une matrice de recette, redirige une faible part du trafic réel vers le candidat, surveille les signaux des utilisateurs et du système, et garde une procédure de retour testée sous la main.

Avant le test : définir un contrat de migration clair

Les comparaisons ne valent rien si plusieurs éléments changent en même temps. Pour la première phase, maintenez constants le prompt système, la configuration du retrieval, les schémas d'outils, la température, la longueur maximale de sortie et les règles de sécurité, et documentez les ajustements de paramètres inévitables (comme les options d'échantillonnage non prises en compte). Documentez le modèle actuel comme base et le nouveau modèle comme candidat. Utilisez si possible des versions explicites du modèle plutôt qu'un alias dynamique. Un alias pourrait plus tard pointer vers un autre instantané et altérer une comparaison qu'on croyait reproductible.

Le contrat de migration définit également les groupes d'utilisateurs et les fonctionnalités initialement exclus. Un chatbot de FAQ peut par exemple passer rapidement en version Canary, tandis que les accès en écriture aux commandes, les demandes de contrats ou les cas de support particulièrement sensibles restent plus longtemps sur la base. Le risque est ainsi limité selon l'impact métier et non selon la seule complexité technique.

Le jeu de données de test doit refléter le trafic réel

Un Golden Set ne doit pas contenir uniquement des questions parfaites et classiques. Rassemblez des cas anonymisés ou synthétiques issus des principaux intents : questions précises, formulations ambiguës, relances, documents manquants, sources contradictoires, erreurs d'outils et requêtes nécessitant une escalade vers un humain. Répartissez les cas par langue, appareil, type de client et classe de risque. Vous éviterez ainsi qu'un bon score global ne masque de sous-groupes restreints mais critiques pour votre activité.

Le guide officiel d' Anthropic sur les critères de réussite et les Evals recommande des critères spécifiques, mesurables et adaptés au cas d'usage, ainsi que des cas limites réalistes. De même, le guide d' OpenAI sur les Evals décrit les tests comme un élément essentiel d'applications fiables, en particulier lors des mises à niveau ou de l'évaluation de nouveaux modèles. Étant donné qu'OpenAI annonce sur cette même page la dépréciation de sa plateforme Evals historique, il convient de conserver votre propre Golden Set dans un format portable et non lié à un tableau de bord unique.

Une matrice d'évaluation plutôt qu'une valeur moyenne unique

Les seuils suivants sont donnés à titre d'exemple et non comme une règle universelle. Définissez-les en fonction des performances actuelles en production et du coût potentiel d'une erreur. Un candidat ne doit pas compenser un prix de jeton inférieur par un moins bon ancrage dans les sources.

Les contrôles automatiques sont adaptés aux les schémas JSON, les formulations obligatoires, les liens, les arguments d'outils et les règles métier déterministes. Pour le ton, l'exhaustivité et l'utilité des explications, une grille d'évaluation claire reste indispensable ; un échantillonnage par des experts permet de calibrer un évaluateur basé sur un LLM. Les résultats doivent être enregistrés par intent et par classe de risque, et non sous la forme d'un score unique. La structure d'un tel jeu de données est également présentée dans notre guide sur la qualité des réponses avec Golden Set.

Exemple concret : Changement de modèle dans le support B2B

Imaginons qu'un éditeur de logiciels B2B exploite un chatbot pour les questions produit, la gestion de compte et la préparation des tickets de support. L'équipe prépare 240 cas de test : 120 questions fréquentes, 40 questions de suivi ambiguës, 30 cas sans source disponible, 25 simulations d'outils et 25 cas de sécurité ou de transfert vers un agent humain. Les deux modèles reçoivent exactement les mêmes prompts, extraits de documents et résultats d'outils simulés.

Le modèle candidat répond plus vite et à moindre coût aux questions courantes, mais perd le contexte du message précédent sur cinq questions de suivi. Le score global resterait néanmoins supérieur. L'analyse par segment révèle toutefois une perte de qualité évidente. L'équipe ne crée pas d'exception arbitraire : elle affine la règle de conversation, enrichit le jeu de test avec des cas similaires et reteste les deux modèles. Le déploiement Canary en production ne commence qu'une fois que le candidat a franchi tous les critères stricts.

Au démarrage, deux pour cent des nouvelles conversations éligibles sont attribuées au candidat. L'attribution au début de la conversation est calculée par exemple par un hachage de l'ID de conversation et conservée pendant toute sa durée ; les paliers Canary supérieurs ne s'appliquent qu'aux nouvelles conversations. Les appels d'outils en écriture et les intents à haut risque restent au départ sur le modèle de base. Après une période d'observation suffisante, le trafic passe à 10, 25, 50 puis 100 pour cent — à condition que chaque critère reste au vert. Les étapes et la taille minimale d'échantillon sont fixées à l'avance pour éviter que la pression du calendrier ne vienne assouplir les règles.

Les signaux en ligne qui comptent vraiment

En phase Canary, les erreurs HTTP et la latence moyenne ne suffisent pas. Observez le taux d'absence de réponse, les abandons dès la première réponse, les questions répétées, le taux de transfert, les clics sur les sources, les erreurs de schéma et les échecs d'outils séparément pour la base et pour le candidat. Une trace commune relie la version du modèle, la version du prompt, les résultats du retrieval et les étapes d'outils, sans stocker de données personnelles inutilement. Notre article sur l' observabilité des chatbots détaille cette piste d'audit.

Comparez également le coût par cas résolu avec succès au lieu de vous limiter au coût par million de jetons. Un modèle moins cher qui génère davantage de relances ou nécessite une intervention humaine plus fréquente peut s'avérer plus coûteux à l'usage. À l'inverse, une légère hausse de la latence peut être acceptable si elle s'accompagne de réponses manifestement plus précises dans une catégorie à haut risque.

Le rollback est une fonctionnalité, pas un document

L'option de retour en arrière doit être testée techniquement avant le premier palier Canary. L'identifiant du modèle et ses paramètres associés doivent figurer dans une configuration versionnée ou dépendre d'un feature flag contrôlé. Tant que le fournisseur prend en charge l'ancienne version, celle-ci reste disponible comme cible de secours pendant le Canary ; avant sa date d'arrêt définitif, un fallback compatible supplémentaire doit être prêt. Les conversations en cours doivent soit rester sur leur modèle d'origine, soit basculer selon une règle explicitement validée.

Définissez des déclencheurs stricts : par exemple une erreur de schéma lors d'une action en écriture, une détérioration sur un intent critique pour la sécurité, une augmentation nette du taux d'erreur ou le dépassement du budget de latence. En présence d'un tel signal, le basculement est déclenché automatiquement ou par une personne d'astreinte clairement identifiée. Les journaux, la version du candidat et l'échantillon concerné sont conservés pour analyser la cause racine. Une procédure préparée est bien plus fiable qu'un déploiement de code improvisé ; un playbook complet de réponse aux incidents apporte un soutien complémentaire.

Check-list de validation

• Consigner la date de fin de vie, le modèle de remplacement et les endpoints concernés depuis la documentation officielle du fournisseur.
• Figer la base et le candidat avec des configurations de prompt, de retrieval et d'outils identiques.
• Segmenter le Golden Set par intent, langue et niveau de risque ; ajouter des cas limites et des erreurs réelles observées.
• Définir des portes de validation strictes pour l'ancrage des sources, les sorties structurées, les outils, la sécurité et l'escalade.
• Mesurer la latence, le taux d'erreur, les jetons et le coût par cas résolu.
• Garantir la stabilité de l'attribution Canary sur toute la conversation et exclure au départ les fonctionnalités sensibles.
• Documenter les paliers, la taille minimale d'échantillon, la durée d'observation et les seuils d'arrêt avant le déploiement.
• Tester le rollback sur le plan technique, désigner les responsables et maintenir une cible de secours supportée par le fournisseur.
• Continuer la surveillance après le passage à 100 % et enrichir le Golden Set avec les nouveaux cas rencontrés en production.

Conclusion : Le nom du modèle n'est qu'un début

Un changement maîtrisé de modèle de base allie qualité du produit et sécurité d'exploitation. Les annonces officielles de fin de vie fixent les délais, les Evals apportent la preuve de la pertinence, le trafic Canary limite l'impact des erreurs imprévues et un rollback testé réduit le temps de réaction. En transformant ces quatre piliers en un processus répétable, vous profitez des nouveaux modèles sans transformer votre chatbot de site web en laboratoire d'expérimentation pour vos utilisateurs.

Vous souhaitez planifier de façon structurée les versions de modèles, les critères de qualité et le déploiement de votre chatbot de site web ? ChatReact vous aide à configurer votre base de connaissances, vos comportements de réponse et vos escalades pour que chaque modification reste mesurable et sous contrôle.