Apprentissage incrémental avec partial_fit : features stables, liste des classes et évaluation honnête

Ce qu'apporte la méthode

L'apprentissage incrémental met à jour un estimateur existant à partir de lots successifs. Il permet de traiter une archive plus volumineuse que la RAM ou un flux dont les labels arrivent au fil du temps. Un système out-of-core a néanmoins besoin d'un lecteur de données, d'une représentation cohérente des features et d'un estimateur qui prend en charge les mises à jour incrémentales : un petit lot ne rend pas à lui seul un algorithme quelconque incrémental. [1]

Le contrat de mise à jour

Pour SGDClassifier, partial_fit effectue une époque d'entraînement sur le lot fourni. Rien ne garantit la convergence à l'issue de cet appel. Le premier appel exige la liste complète des classes prévues via classes, même si ce lot ne contient qu'une partie d'entre elles. Les appels suivants doivent conserver la dimension des features et l'interprétation des labels. Des appels répétés à fit constituent une opération différente : même avec warm_start, le comportement de leur compteur de taux d'apprentissage n'est pas le même. [2]

Une conception pragmatique fixe le vocabulaire des features ou utilise une représentation par hachage sans état. Si le prétraitement numérique change en cours d'exploitation, les coefficients du modèle et les coordonnées des features transformées doivent rester cohérents ; mettre à jour un scaler de son côté n'est pas automatiquement une stratégie d'adaptation valide. Il s'agit d'une conséquence pratique de l'exigence de conserver des entrées porteuses de sens pour le modèle.

Exemple illustratif

Prenons une archive de 100000 messages de support, traitée par lots de 2000, avec trois labels prédéfinis : facturation, technique et général. Un vectoriseur par hachage de dimension fixe projette chaque lot dans le même espace de features. Le premier lot peut ne contenir que des messages de facturation et techniques, mais les trois classes sont fournies dès l'initialisation. Cinquante lots couvrent un passage complet sur l'archive ; cela n'établit pas que le modèle obtenu soit précis ni entièrement optimisé.

Évaluation et exploitation

Pour un flux en production, conservez chaque prédiction avec la version du modèle qui l'a produite avant d'utiliser le label correspondant pour une mise à jour. Une fois le label arrivé, évaluez cette prédiction stockée, et seulement ensuite entraînez le modèle sur l'exemple. Ce protocole d'évaluation proposé évite de mesurer une prédiction alors que le modèle a déjà appris la réponse.

Gardez un jeu d'évaluation indépendant pour les décisions de mise en production, ou appliquez un protocole temporel documenté. Consignez l'ordre des lots, la configuration des features, les paramètres de l'optimiseur, les définitions des classes et les checkpoints du modèle, afin de pouvoir enquêter sur une mise à jour suspecte.

Limites et cas d'échec

Les mises à jour incrémentales ne détectent pas automatiquement la dérive conceptuelle (concept drift), ne gèrent pas une classe cible réellement nouvelle et ne préservent pas les performances sur les cas plus anciens. Un taux d'apprentissage décroissant peut réduire l'adaptation aux exemples plus tardifs. [1, 2] Surveillez séparément les tranches d'évaluation récentes et historiques. Des labels erronés, des lots répétés et des features dont le sens a changé peuvent dégrader le modèle alors même que l'appel de mise à jour réussit. Aucune expérience d'entraînement ni mesure de débit n'est rapportée ici.

Sources

[1] Strategies to scale computationally: bigger data

[2] SGDClassifier