Comment gérez-vous les versions de modèles pour pouvoir revenir en arrière rapidement quand ça tourne mal ?

Traitez les modèles comme des artefacts versionnés immuables dans un registre, jamais comme un fichier écrasé sur place. Chaque version enregistre le commit du code d'entraînement, l'instantané de données, ses métriques, et un stade comme préproduction ou production. Le service lit dans la configuration quelle version charger, donc le retour arrière est un changement de configuration de quelques secondes, et la version précédente reste chargeable sans reconstruction.

Règle numéro un : un artefact de modèle est immuable. Il reçoit une version, il est écrit une fois, et rien ne l'écrase jamais, parce que le jour où vous avez besoin de revenir en arrière est le jour où vous découvrez que l'ancien fichier a été remplacé. Chaque version porte sa traçabilité : le SHA git du code d'entraînement, l'identifiant de l'instantané de données, la configuration des hyperparamètres, les métriques d'évaluation, et qui l'a promue. Ça veut dire que quand quelqu'un demande dans trois mois pourquoi le modèle s'est mis à se comporter différemment en avril, c'est une simple recherche et pas un chantier d'archéologie. Le service ne code pas une version en dur. Il lit un pointeur dans la configuration, donc promouvoir c'est changer le pointeur et revenir en arrière c'est le remettre, les deux en quelques secondes. Je garde la version précédente chargée en mémoire quand l'empreinte le permet, donc un retour arrière n'exige ni redéploiement ni démarrage à froid sur un conteneur neuf. Et je le répète, parce qu'un chemin de retour arrière non testé n'est pas un chemin de retour arrière. Dans ma dernière équipe nous en faisions un délibérément de temps en temps sur une fenêtre à faible trafic, et c'est comme ça que nous avons découvert que le changement de configuration se propageait bien mais qu'un cache en aval gardait l'ancien seuil pendant dix minutes de plus.