Comment faites-vous sortir un modèle d'un notebook pour le mettre en production ?

Sortez la logique des cellules vers des modules testés, avec une ingénierie de variables partagée entre l'entraînement et le service pour que les deux ne puissent pas diverger. Emballez l'entraînement en job paramétré, sérialisez tout le pipeline y compris le prétraitement plutôt que le seul estimateur, et exposez le scoring derrière une interface avec validation des entrées. Ajoutez la supervision des entrées et des prédictions avant le lancement, pas après.

Le notebook, c'est là où je découvre ce qu'est le modèle, pas ce qui part en production. Le premier geste, c'est de sortir la logique dans un module avec des fonctions que je peux importer et tester, plus deux ou trois tests unitaires sur les transformations de variables avec un tout petit jeu de données de référence, parce que c'est là que vivent les bugs subtils. La règle sur laquelle je suis le plus strict, c'est que l'entraînement et le service appellent le même code de variables. Dès que quelqu'un réimplémente les variables dans le service, elles dérivent, et vous obtenez un modèle qui score différemment en production pour des raisons que personne ne trouve pendant une semaine. Ensuite je sérialise le pipeline entier, imputeur, encodeur, scaler, modèle, comme un seul objet, pour que le service ne puisse pas oublier une étape de prétraitement. L'entraînement devient un job qui prend une configuration et une plage de dates et écrit un artefact versionné. Côté service, je valide les entrées et je rejette ou remplace par une valeur par défaut tout ce qui sort des bornes plutôt que de scorer silencieusement n'importe quoi. Et la supervision arrive avant le lancement : distributions des entrées, distribution des prédictions, taux de valeurs nulles, latence. Si je n'ai droit qu'à une seule, je prends la dérive des entrées, parce que c'est ce qui change en premier.