Changer de modèle sans tout casser

Ce n'est pas une éventualité, c'est un calendrier : les versions sont dépréciées, les nouvelles sortent, et une migration vous sera imposée. La seule question est de savoir si vous l'aurez préparée.

Pourquoi ce n'est pas une simple mise à jour

Un nouveau modèle est meilleur en moyenne et différent partout. Vos prompts ont été réglés sur les habitudes de l'ancien : sa verbosité, sa façon de formater, ses refus. Un modèle plus performant peut très bien dégrader votre produit précis, parce qu'il ne réagit plus pareil à vos consignes.

La performance générale ne dit rien de la performance sur votre cas.

Le jeu d'évaluation, qu'il faut avoir constitué avant

Cent à trois cents cas issus du trafic réel, avec la sortie attendue ou un critère de validation. Incluez délibérément les cas tordus : entrées vides, très longues, dans une autre langue, hostiles. Ce sont eux qui révèlent les régressions.

Sans ce jeu, une migration est un pari. Avec, c'est une décision qui prend une heure.

Migrer en parallèle

Faites tourner le nouveau modèle à côté de l'ancien sur du trafic réel, sans servir ses réponses. Vous comparez en conditions réelles, à coût maîtrisé, avant d'exposer qui que ce soit. Puis basculez progressivement, en surveillant vos signaux.

Le piège du réglage

Ne réécrivez pas vos prompts en même temps que vous changez de modèle. Deux variables qui bougent ensemble rendent tout diagnostic impossible. Migrez d'abord à prompts constants, mesurez, puis optimisez.

Ce qu'il faut garder sous la main

La possibilité de revenir à l'ancien modèle en une variable de configuration, tant qu'il est disponible. Et la date de dépréciation annoncée, dans un endroit que quelqu'un regarde.