Le catastrophic forgetting fine-tuning est la régression silencieuse que personne ne surveille. Vous fine-tunez un Mistral 7B sur vos données métier, les scores sur votre jeu de test s'améliorent, vous déployez — et deux semaines plus tard les utilisateurs remontent des sorties bizarres sur des questions pourtant basiques. Le modèle a oublié ce qu'il savait faire avant. Pas d'un coup. Progressivement, par érosion des poids.
L'oubli catastrophique en LLM se produit quand le fine-tuning réoriente trop brutalement les paramètres du modèle vers la tâche cible, au détriment des représentations générales acquises durant le pré-entraînement. Ce guide explique le mécanisme précis, les signaux qui trahissent le problème, et les leviers concrets pour l'éviter : LoRA/PEFT, replay de données, learning rate modéré, contrôle des epochs, eval de régression.
Le mécanisme : pourquoi les poids oublient
Un LLM pré-entraîné a passé des semaines à apprendre des représentations générales du langage sur des centaines de milliards de tokens : syntaxe, raisonnement, faits du monde, structure des conversations, suivi d'instructions. Ces connaissances sont encodées dans ses milliards de paramètres, distribuées de façon diffuse dans tout le réseau.
Quand on fine-tune, on applique un gradient de mise à jour à ces mêmes paramètres. La descente de gradient optimise les poids pour minimiser la loss sur votre dataset spécialisé. Problème : si ce dataset est étroit et homogène, les gradients poussent systématiquement dans la même direction — la direction qui favorise la tâche cible. Les poids qui portaient des représentations générales bougent. Parfois un peu. Parfois beaucoup.
C'est ce qu'on appelle le catastrophic forgetting, décrit formellement depuis les années 1980 dans les réseaux de neurones (McCloskey & Cohen, 1989 ; Goodfellow et al., 2013). Les LLM n'y échappent pas — ils sont juste suffisamment grands pour que le phénomène soit plus lent et plus partiel.
Soyons précis sur ce qui se passe réellement :
- Le modèle ne perd pas toutes ses connaissances générales d'un coup. Il les dégrade partiellement, de façon inégale selon les couches.
- Les couches profondes (embeddings, attention bas niveau) sont moins affectées que les couches hautes, plus spécialisables.
- Un dataset large et diversifié ralentit le phénomène ; un dataset petit et répétitif l'accélère fortement.
- Un trop grand nombre d'epochs sur un dataset fixe aggrave la situation à chaque passe supplémentaire.
Signaux que ça se produit
Le catastrophic forgetting est sournois parce que les métriques sur votre tâche cible restent bonnes — c'est précisément le problème. On a optimisé la tâche cible au détriment du reste. Voici les signaux concrets à surveiller.
Signaux dans les sorties
- Répétitions en boucle. Le modèle commence à répéter des phrases ou des formulations issues de votre dataset d'entraînement, même hors contexte. C'est souvent le premier signe visible.
- Dégradation du suivi d'instructions. Des instructions système simples ("réponds toujours en JSON", "limite ta réponse à 100 mots") que le modèle respectait avant ne sont plus systématiquement suivies.
- Cohérence hors domaine. Posez au modèle des questions ouvertes sur des sujets généraux. Si les réponses deviennent vagues, décousues ou mélangent les langues, l'oubli est en cours.
- Hallucinations accrues sur les cas limites. Hors de la distribution d'entraînement, le modèle "invente" davantage, faute de représentations générales solides pour ancrer ses réponses.
Signaux dans les métriques
Le seul moyen fiable de détecter l'oubli catastrophique est un eval de régression AVANT/APRÈS sur un golden set. En pratique, on évalue le modèle de base et le modèle fine-tuné sur le même ensemble de tâches générales — reformulation, résumé, Q&A hors domaine, instructions complexes — et on compare les scores.
Une chute de 10 à 15 % sur ces tâches générales est un signal d'alarme. Une chute supérieure à 20 % indique un oubli sévère qui justifie de revoir l'approche d'entraînement avant tout déploiement.
Les pièges classiques qui déclenchent l'oubli
On en voit régulièrement sur des projets qui arrivent en audit après un fine-tuning décevant. Trois pièges reviennent systématiquement.
Trop d'epochs
C'est la cause la plus fréquente. On pense que plus on entraîne longtemps, mieux le modèle apprend. Sur un dataset petit et homogène, c'est exactement l'inverse : après 3-4 epochs, le modèle commence à memoriser les exemples d'entraînement plutôt qu'à généraliser. Les poids se verrouillent sur les patterns du dataset. Tout ce qui était en dehors s'efface.
Règle pratique : surveiller la validation loss à chaque checkpoint. Dès qu'elle stagne ou remonte, arrêter l'entraînement — pas attendre la fin des epochs planifiées. Avec les librairies modernes comme Axolotl ou TRL (Hugging Face), le early stopping s'active en quelques lignes de config.
Dataset trop étroit
Un dataset de 300 exemples tous issus du même type de document (des devis, des emails de réclamation, des notices techniques dans le même format) est une recette pour l'oubli. Le modèle n'a vu pendant le fine-tuning qu'une infime tranche du langage. Ses gradients poussent dans une seule direction.
Ce n'est pas un problème de volume : 300 exemples de qualité suffisent pour fine-tuner avec LoRA. C'est un problème de diversité. Si tous vos exemples se ressemblent syntaxiquement et stylistiquement, ajoutez du replay.
Learning rate trop élevé
Un learning rate de 5e-4 ou 1e-3 sur un fine-tuning LoRA, c'est trop haut pour la plupart des architectures actuelles. À ces valeurs, les mises à jour des adaptateurs LoRA sont si larges qu'elles perturbent les couches adjacentes et propagent des gradients qui déstabilisent les représentations profondes. La zone sûre se situe entre 1e-4 et 5e-5, avec un scheduler cosine et un warmup de 5 à 10 % des steps totaux.
Leviers anti-oubli : le tableau de bord
| Technique | Effet sur l'oubli | Coût / complexité | Quand l'utiliser |
|---|---|---|---|
| LoRA / QLoRA (PEFT) | Fort — seuls <1 % des paramètres sont modifiés ; les couches gelées préservent les représentations générales | Faible — standard aujourd'hui, supporté nativement par PEFT, TRL, Axolotl, Unsloth | Toujours en priorité, sauf besoin de full fine-tuning justifié |
| Replay de données générales | Moyen à fort — maintient la diversité des gradients et préserve les représentations générales | Faible — ajouter 10-20 % de données générales dans le dataset | Dès que le dataset est petit (<2 000 exemples) ou très homogène |
| Learning rate modéré + scheduler cosine | Moyen — évite les mises à jour trop brutales au démarrage | Nul — un paramètre à ajuster dans la config | Systématiquement (LR entre 1e-4 et 5e-5, warmup 5-10 %) |
| Early stopping (1-3 epochs) | Moyen — évite la surspécialisation progressive par epochs successives | Nul — surveiller la validation loss et arrêter tôt | Toujours, surtout avec dataset <5 000 exemples |
| Eval de régression golden set | Détection — ne prévient pas mais mesure l'oubli avant déploiement | Faible — constituer un jeu de 50-100 exemples généraux à maintenir | Avant chaque déploiement, systématiquement |
| Elastic Weight Consolidation (EWC) | Fort — pénalise les modifications des paramètres importants pour les tâches générales | Élevé — implémentation non triviale, calcul de la Fisher information matrix | Projets de continual learning avec plusieurs tâches successives |
LoRA et PEFT : pourquoi ils réduisent structurellement l'oubli
LoRA (Low-Rank Adaptation) n'a pas été conçu initialement pour prévenir l'oubli catastrophique, mais c'est l'un de ses bénéfices majeurs. Le principe : au lieu de modifier tous les poids du modèle, on gèle le modèle de base et on ajoute de petites matrices de rang faible ($\Delta W = BA$) sur les couches d'attention et de projection. Ces matrices représentent typiquement 0,1 à 1 % du volume de paramètres total.
Conséquence directe : les poids qui encodent les représentations générales acquises lors du pré-entraînement restent figés. Seules les adaptateurs LoRA bougent. L'oubli ne peut affecter que ce qu'elles encodent, pas les représentations profondes du modèle de base.
Ce n'est pas une protection absolue. Un LoRA mal calibré peut quand même dégrader les sorties générales, notamment si le learning rate est trop élevé ou si l'on entraîne trop longtemps. Mais le risque est structurellement beaucoup plus faible qu'avec un full fine-tuning.
Pour les projets où le budget de compute est serré, QLoRA (LoRA avec quantification en 4 bits du modèle de base via bitsandbytes) offre les mêmes garanties anti-oubli avec une consommation mémoire divisée par 3 ou 4. Fine-tuner Mistral 7B sur un A100 40 Go passe de ~80 Go en full FP16 à ~10 Go en QLoRA 4 bits. C'est ce qui rend le fine-tuning accessible sur GPU cloud à la demande pour moins de 500 €.
Pour aller plus loin sur LoRA, QLoRA et les alternatives (IA3, DoRA, RSLoRA), l'article sur LoRA et QLoRA pour le fine-tuning LLM détaille les différences pratiques et les cas d'usage de chacun.
Le replay de données : mélanger pour ne pas oublier
L'idée est simple. Si le modèle voit pendant le fine-tuning uniquement vos 400 exemples de classification de tickets SAV, ses gradients sont 100 % orientés vers cette tâche. En mélangeant dans le dataset 10 à 20 % de données générales (Wikipedia en français, articles techniques, conversations ouvertes), on force la diversité des gradients. Le modèle apprend la tâche cible tout en continuant à "pratiquer" le langage général.
En pratique, on constitue un corpus de replay à partir de sources ouvertes : sous-ensemble de Wikipedia FR, données CommonCrawl filtrées, ou simplement les données système d'un dataset public comme Dolly-15k ou OpenHermes. Le ratio classique est 80-90 % données métier / 10-20 % données générales.
Le replay a un coût marginal : il allonge légèrement l'entraînement (plus d'exemples par epoch) et nécessite de préparer ce corpus. Mais sur des projets où le dataset métier est petit et homogène, c'est souvent la technique la plus efficace pour préserver la qualité générale du modèle.
Pour construire et préparer ces datasets correctement, l'article sur la préparation d'un dataset de fine-tuning couvre les formats, les ratios et les erreurs d'annotation à éviter.
L'eval de régression : la garde-fou avant déploiement
Aucune des techniques précédentes ne dispense d'un eval de régression AVANT/APRÈS. C'est la seule façon de savoir avec certitude si le fine-tuning a dégradé les capacités générales du modèle.
Structure d'un golden set anti-régression
On le compose de deux parties distinctes :
- Partie tâche cible — 50 à 100 exemples représentatifs de votre cas d'usage, avec la sortie attendue. Mesure les gains du fine-tuning.
- Partie générale — 30 à 50 exemples de tâches que le modèle de base gérait bien : résumé de texte hors domaine, réponse à des questions générales, suivi d'instructions avec contraintes multiples, reformulation dans un style différent.
On évalue les deux modèles (base et fine-tuné) sur les deux parties. Le tableau de résultats ressemble à ça :
| Modèle | Score tâche cible | Score tâches générales | Décision |
|---|---|---|---|
| Mistral 7B base | 61 % | 78 % | — |
| + Fine-tuning LoRA 3 epochs | 87 % | 74 % | Acceptable (-4 % général) |
| + Fine-tuning full 8 epochs | 89 % | 51 % | Rejet — oubli sévère |
| + LoRA + replay 15 % | 85 % | 76 % | Optimal |
Ce type de tableau, on devrait le produire systématiquement avant tout passage en production. Dans les faits, sur les projets qu'on audite, il est absent dans la majorité des cas. L'eval s'arrête aux métriques sur la tâche cible et personne ne regarde ce qui a régressé ailleurs.
Pour aller plus loin sur la construction d'un système d'évaluation solide, l'article sur l'évaluation d'un modèle fine-tuné et la détection de l'overfitting détaille les métriques, les outils (LangSmith, Weights & Biases, DeepEval) et les protocoles d'évaluation humaine.
Limites et cas où l'oubli est inévitable
Soyons honnêtes : pour certains projets, l'oubli catastrophique partiel est un compromis accepté, pas un accident.
Si vous fine-tunez un modèle pour une tâche très étroite — classifier des codes NAF, extraire des montants de factures dans un format normé — et que ce modèle ne sera jamais utilisé pour autre chose, une régression sur les tâches générales est sans conséquence. Ce qui compte, c'est la précision sur la tâche cible.
Ce qui n'est jamais acceptable :
- Déployer un modèle "assistant" polyvalent sans avoir mesuré les régressions générales.
- Utiliser un modèle fine-tuné pour des tâches mixtes (extraction ET conversation) sans avoir testé les deux dimensions.
- Enchaîner plusieurs fine-tunings successifs sur un même modèle sans repartir du modèle de base entre chaque — l'oubli s'accumule.
Sur les projets de fine-tuning LLM que nous accompagnons, la règle est simple : si le modèle a vocation à faire autre chose que la tâche cible, on mesure les deux dimensions avant de décider si le fine-tuning est la bonne approche ou si une architecture hybride (RAG + modèle de base) est plus résiliente à long terme.
Pour aller plus loin
- LoRA et QLoRA pour le fine-tuning LLM : guide complet sur les techniques PEFT, les différences pratiques et les librairies (Unsloth, TRL, Axolotl, PEFT).
- Préparer un dataset de fine-tuning : formats, ratios, erreurs d'annotation et diversité des exemples pour limiter l'oubli.
- Évaluer un modèle fine-tuné et détecter l'overfitting : golden set, métriques métier, outils d'évaluation et protocole AVANT/APRÈS.
- Fine-tuning LLM pour PME : quand ça vaut le coup : arbres de décision, budget réel et comparatif LoRA vs full fine-tuning.
- Évaluer un LLM sur votre cas d'usage métier : métriques et benchmarks pour choisir le bon modèle de base avant de fine-tuner.
- Fine-tuner Mistral sur vos données métier : étapes concrètes, configuration QLoRA et coûts GPU sur infrastructure souveraine.
- Goodfellow et al. (2013) — An Empirical Investigation of Catastrophic Forgetting : la référence académique fondatrice sur le phénomène.
- Documentation PEFT / LoRA de Hugging Face : implémentation de référence pour LoRA, QLoRA, IA3 et les variantes modernes.
Vous hésitez encore ?
Votre fine-tuning régresse ? 30 minutes pour diagnostiquer la cause et définir la correction.
En résumé : l'oubli catastrophique se prévient, pas se répare
Un fine-tuning qui régresse n'est pas une fatalité. C'est presque toujours le résultat de trois variables mal calibrées : trop d'epochs, dataset trop étroit, learning rate trop élevé. Et l'absence d'un eval de régression pour le détecter avant le déploiement.
Les leviers sont connus et accessibles : LoRA/PEFT en premier recours pour limiter la surface de modification des poids, replay de 10-20 % de données générales pour maintenir la diversité des gradients, early stopping à 1-3 epochs, LR entre 5e-5 et 1e-4. Et systématiquement, un golden set qui évalue les deux dimensions — tâche cible et capacités générales — AVANT de merger en production.
Le catastrophic forgetting fine-tuning est le bug silencieux des projets LLM : invisible dans les métriques de la tâche cible, douloureux en production. La seule vraie protection, c'est de le chercher activement avant que les utilisateurs le trouvent à votre place.
Questions fréquentes sur le catastrophic forgetting et le fine-tuning
Le catastrophic forgetting (oubli catastrophique) est le phénomène par lequel un modèle de langage fine-tuné sur un jeu de données spécialisé perd ses capacités générales acquises lors du pré-entraînement. Les poids du réseau se réorientent vers la tâche cible et écrasent en partie les représentations générales antérieures. Le modèle devient meilleur sur sa tâche spécifique mais peut régresser sur des compétences de base comme le raisonnement, la cohérence ou la compréhension de textes hors domaine.
Les signaux typiques : le modèle performe bien sur vos exemples métier mais répond de façon incohérente sur des questions générales qu'il gérait auparavant ; ses sorties hors domaine deviennent répétitives ou décousues ; il oublie des instructions système simples ; ses scores sur un golden set de tâches générales chutent significativement après fine-tuning. Un eval de régression AVANT/APRÈS est le seul moyen de le détecter de façon systématique.
LoRA réduit fortement le risque d'oubli catastrophique car il ne modifie qu'une infime fraction des paramètres du modèle (souvent moins de 1 %). Les représentations générales stockées dans les couches gelées restent intactes. Ce n'est pas une garantie absolue : un LoRA avec un learning rate trop élevé, trop d'epochs ou un dataset trop étroit peut quand même provoquer une régression partielle. Il faut toujours valider sur un golden set après entraînement.
Le replay consiste à mélanger dans votre dataset de fine-tuning un sous-ensemble de données générales issues du pré-entraînement ou d'un corpus ouvert (Wikipedia, Common Crawl, textes techniques généraux). En pratique, on conseille un ratio de 10 à 20 % de données générales pour 80 à 90 % de données métier. Cette technique préserve les représentations générales du modèle tout en lui enseignant la tâche cible. Elle est compatible avec LoRA et ajoute un coût d'entraînement modeste.
Pour un fine-tuning supervisé sur quelques centaines à quelques milliers d'exemples, 1 à 3 epochs suffisent dans la plupart des cas. Au-delà de 5 epochs, le risque d'overfitting et d'oubli catastrophique augmente significativement, surtout si le dataset est petit et homogène. La règle pratique : surveiller la loss de validation à chaque epoch et s'arrêter dès que la courbe stagne ou remonte.
Pour un fine-tuning LoRA sur un LLM, les learning rates efficaces se situent typiquement entre 1e-4 et 5e-5. Un LR supérieur à 2e-4 commence à surspécialiser rapidement les adaptateurs LoRA. On recommande d'utiliser un scheduler cosine avec warmup sur les 5 à 10 premiers % des steps, ce qui stabilise les premières mises à jour et réduit le risque de divergence initiale.
Un golden set anti-régression comporte deux parties : (1) 50 à 100 exemples de la tâche cible avec les sorties attendues, pour mesurer les gains du fine-tuning ; (2) 30 à 50 exemples de tâches générales que le modèle de base gérait bien (reformulation, résumé, Q&A hors domaine, suivi d'instructions complexes). On compare les scores du modèle de base et du modèle fine-tuné sur les deux parties. Un gain sur la partie 1 avec une chute sur la partie 2 est le signe d'un oubli catastrophique partiel.
