Fine-tuning d'un LLM : quand le faire (et quand l'éviter)

Le fine-tuning (réglage fin) consiste à ré-entraîner un modèle existant sur vos données pour changer son comportement : un ton, un format de sortie, un vocabulaire métier. C'est la solution la plus coûteuse et la plus souvent mal employée : dans la plupart des cas, un bon prompt ou un RAG répond au besoin sans toucher aux poids du modèle. Cette leçon vous donne l'arbre de décision, explique ce que changent LoRA et QLoRA, nomme les outils actuels et chiffre le coût réel, en vous appuyant sur des publications citées. Public visé : développeurs et ingénieurs qui savent déjà appeler un LLM.

Ce que vous allez apprendre

• Décider entre prompt, RAG et fine-tuning selon le besoin réel
• Ce que sont LoRA et QLoRA, et pourquoi ils ont rendu le fine-tuning accessible
• Quels outils utiliser aujourd'hui (PEFT, TRL, Unsloth)
• À quoi ressemble un jeu de données d'entraînement, et pourquoi sa qualité prime
• Le coût réel et les risques : oubli catastrophique, fuite de données, reproductibilité

Prérequis

Cette leçon vient après le module RAG parce que la question « faut-il fine-tuner ? » ne se pose qu'une fois le RAG compris.

• Avoir lu l'introduction au RAG et RAG en production : sans eux, vous ne pouvez pas juger si un RAG suffit à votre besoin.
• Savoir ce qu'est la quantification d'un modèle, vue dans Comprendre la quantification : QLoRA s'appuie dessus.
• Connaître les bases d'un LLM (Anatomie d'un LLM) : poids, paramètres, entraînement.

Cette leçon est conceptuelle : elle n'entraîne aucun modèle et ne propose pas de lab. Elle vous apprend à décider, et à reconnaître le vocabulaire et les outils du domaine.

Qu'est-ce que le fine-tuning ?

Le fine-tuning est la poursuite de l'entraînement d'un LLM de base sur un jeu de données ciblé, ce qui modifie ses poids (les nombres appris qui définissent son comportement). On l'utilise pour lui faire adopter un ton, respecter un format de sortie ou maîtriser un jargon métier. On ne lui apprend pas des faits ponctuels : ça, c'est le rôle du RAG.

Les trois approches n'agissent pas au même endroit. Le prompt oriente le modèle au moment de la requête, sans rien modifier. Le RAG lui fournit des documents externes à chaque appel, ce qui change ses réponses sans toucher à ses paramètres. Le fine-tuning modifie les poids : l'effet est durable, mais il exige un jeu de données annoté et du calcul, et il fige un comportement qu'il faudra réentraîner pour le faire évoluer. Il ne se justifie donc qu'une fois les deux premières approches épuisées.

Le panorama IA n'en donne que le principe, dans un tableau à deux lignes. Cette leçon est celle qui tranche : elle détaille l'arbre de décision, les techniques et les coûts.

Faut-il choisir un prompt, un RAG ou un fine-tuning ?

La règle est simple : commencer par le moins cher et ne monter en complexité que si le besoin l'exige. L'arbre ci-dessous pose les questions dans cet ordre. Chaque question a sa sortie « oui » sur la même ligne, et seul un « non » fait descendre vers une solution plus coûteuse. La question des connaissances passe avant celle d'un style imposé partout, parce qu'un besoin de faits relève du RAG, jamais du fine-tuning.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Le tableau résume la même correspondance entre le besoin et la bonne réponse, à garder sous la main pendant une revue d'architecture :

Besoin	Bonne réponse
Changer le comportement ponctuel (ton, format)	Prompt (system prompt, few-shot)
Donner accès à des connaissances à jour ou privées	RAG
Imposer systématiquement un style, un format strict, un domaine pointu	Fine-tuning
Réduire la latence ou le coût d'un très gros prompt répété	Fine-tuning (parfois)

Glissez pour voir

Le réflexe à garder

Le fine-tuning n'apprend pas des faits. Si votre besoin est « le modèle doit connaître nos procédures internes », la réponse est presque toujours le RAG. Une étude de Gekhman et al. (EMNLP 2024, « Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations? ») observe que les modèles apprennent les exemples qui introduisent des connaissances nouvelles bien plus lentement que les autres, et que chaque exemple de ce type appris augmente ensuite la tendance du modèle à halluciner. Les auteurs en concluent que le modèle acquiert ses connaissances pendant le pré-entraînement et que le fine-tuning lui apprend surtout à mieux les utiliser.

En pratique, on combine souvent : un modèle fine-tuné sur le format de réponse, alimenté par un RAG pour les faits. Mais on n'y arrive qu'après avoir épuisé le prompt et le RAG seuls.

Que changent LoRA et QLoRA ?

Le fine-tuning complet met à jour tous les poids du modèle, ce qui demande des GPU hors de portée de la plupart des équipes. Les méthodes PEFT (Parameter-Efficient Fine-Tuning, réglage fin économe en paramètres) n'entraînent qu'une petite fraction des paramètres, et c'est ce qui a rendu la technique accessible.

LoRA (Low-Rank Adaptation, Hu et al., 2021) gèle le modèle d'origine et n'entraîne que de petites matrices ajoutées à certaines de ses couches. Résultat : beaucoup moins de mémoire pendant l'entraînement, et un adaptateur (le fichier des matrices entraînées) bien plus léger que le modèle, qu'on peut échanger ou retirer sans toucher au modèle de base.

QLoRA (Dettmers et al., 2023) ajoute la quantification : le modèle de base est chargé en 4 bits pendant que les matrices LoRA restent entraînées en précision supérieure. Les auteurs indiquent qu'il devient possible de fine-tuner un modèle de 65 milliards de paramètres sur un seul GPU de 48 Go, tout en préservant la performance d'un fine-tuning complet en 16 bits. Un modèle plus petit demande proportionnellement moins de mémoire, ce qui est la raison pour laquelle QLoRA est le point d'entrée habituel sur du matériel modeste.

Une fois entraîné, le modèle fine-tuné se sert comme n'importe quel autre, idéalement quantifié pour tenir en mémoire : voir Quantifier un LLM en pratique et Ollama pour le servir en local.

Quels outils utiliser pour fine-tuner un LLM ?

Trois bibliothèques open source reviennent dans l'écosystème Python en 2026. Les noms sont stables, mais leurs API évoluent vite : consultez toujours la documentation de la version que vous installez plutôt que de copier un tutoriel ancien.

• PEFT, de Hugging Face, fournit les méthodes de réglage économe, dont LoRA, à brancher sur un modèle de la bibliothèque Transformers (voir Hugging Face Transformers).
• TRL, de Hugging Face aussi, fournit les boucles d'entraînement : SFTTrainer pour le fine-tuning supervisé sur des exemples instruction-réponse, et DPOTrainer pour l'entraînement sur des préférences.
• Unsloth est une bibliothèque tierce qui annonce un entraînement plus rapide et moins gourmand en mémoire sur un seul GPU, en s'appuyant sur les mêmes briques.

La quantification en 4 bits de QLoRA passe, dans cet écosystème, par la bibliothèque bitsandbytes. Cette leçon ne reproduit volontairement aucun script d'entraînement : un exemple non rejoué vieillirait mal, et la décision de fine-tuner précède la manière de le faire.

À quoi ressemble un jeu de données de fine-tuning ?

Un jeu de données de fine-tuning est une liste d'exemples du comportement attendu, un par ligne d'un fichier JSONL. Deux formats dominent. Le premier est celui des exemples instruction-réponse, où chaque ligne contient la conversation complète avec la réponse idéale :

{"messages": [{"role": "user", "content": "Résume ce ticket en une ligne : ..."}, {"role": "assistant", "content": "Panne du service de paiement depuis 14 h, cause : certificat expiré."}]}

Le second est celui des paires de préférences : pour une même question, une réponse préférée (chosen) et une réponse rejetée (rejected). On s'en sert pour apprendre au modèle à choisir entre deux réponses plausibles, par exemple avec la méthode DPO (Direct Preference Optimization) proposée par DPOTrainer :

{"prompt": "Explique un pod Kubernetes.", "chosen": "Un pod est la plus petite unité déployable ...", "rejected": "Un pod est un conteneur Docker."}

Ces formats sont ceux de la documentation de TRL au moment de la rédaction : vérifiez les noms de champs dans la version que vous utilisez.

Pourquoi la qualité du dataset prime-t-elle sur la technique ?

La qualité des exemples pèse plus lourd que leur nombre. L'étude LIMA (Zhou et al., 2023) a affiné un modèle de 65 milliards de paramètres sur seulement 1 000 exemples soigneusement choisis, et obtenu des réponses jugées équivalentes ou préférées à GPT-4 dans 43 % des cas ; ses auteurs en tirent que presque toute la connaissance d'un modèle vient du pré-entraînement, le réglage fin servant surtout à lui apprendre le format de ses réponses. Les auteurs de QLoRA font un constat voisin : un petit jeu de données de haute qualité suffit à des résultats de pointe.

Concrètement, visez des exemples cohérents avec le comportement voulu, dédoublonnés, au bon format et équilibrés entre les cas à couvrir. Quelques centaines d'exemples relus à la main valent mieux que des milliers d'exemples bruités : le modèle apprend vos erreurs aussi bien que vos réussites.

Combien coûte vraiment un fine-tuning ?

Le coût GPU de l'entraînement n'est que la partie visible. Le vrai coût est ailleurs, et il se compte en travail humain.

• Les données : constituer un jeu propre et représentatif est le poste le plus lourd et le plus déterminant.
• L'évaluation : sans mesure avant/après sur un jeu de test que le modèle n'a pas vu, vous ne savez pas si le modèle s'est amélioré ou s'il a régressé. Une régression typique est l'oubli catastrophique : en se spécialisant sur vos exemples, le modèle perd une partie de ses capacités générales, comme répondre correctement hors de votre domaine.
• La maintenance : un modèle fine-tuné est figé ; chaque évolution du besoin ou chaque nouveau modèle de base relance un cycle complet.

Côté sécurité, deux risques méritent l'attention : la fuite de données d'entraînement (le modèle peut restituer des exemples sensibles, ne l'entraînez donc jamais sur des secrets ni des données personnelles non nécessaires) et la reproductibilité (versionnez le dataset, les graines aléatoires et les hyperparamètres, sous peine de résultats impossibles à rejouer).

Quels pièges éviter ?

Quatre erreurs reviennent presque à chaque projet de fine-tuning, et la première est de loin la plus fréquente.

• Fine-tuner au lieu de faire du RAG : le piège numéro un. Pour des connaissances, RAG d'abord.
• Ne pas évaluer : impossible de prouver le gain ni de détecter une régression.
• Un dataset bruité ou minuscule : le modèle apprend vos erreurs ou n'apprend rien.
• Oublier la quantification au service : un modèle fine-tuné se sert ensuite, idéalement quantifié pour tenir en mémoire.

À retenir

• Le fine-tuning change le comportement, pas les connaissances : pour les faits, RAG.
• Ordre de décision : prompt, puis RAG, puis fine-tuning, du moins cher au plus cher.
• LoRA n'entraîne que de petites matrices ; QLoRA y ajoute un modèle de base en 4 bits, ce qui permet de fine-tuner un modèle de 65 milliards de paramètres sur un GPU de 48 Go (Dettmers et al., 2023).
• Les outils actuels sont PEFT, TRL et Unsloth ; vérifiez leur documentation, les API évoluent.
• La qualité du dataset fait le résultat (LIMA : 1 000 exemples soignés) ; l'évaluation avant/après n'est pas optionnelle.
• Pensez coût total, oubli catastrophique, fuite de données et reproductibilité.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →