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

Le fine-tuning consiste à ré-entraîner un modèle existant sur vos données pour modifier son comportement (style, format, domaine). C'est puissant, mais c'est aussi la solution la plus coûteuse et la plus souvent mal employée : dans la majorité des cas, un bon prompt ou un RAG répond au besoin sans toucher aux poids du modèle. Cette page vous donne l'arbre de décision : quand fine-tuner, quand s'en passer, et ce que coûtent réellement LoRA et QLoRA. 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 démocratisé le fine-tuning
Le coût réel (GPU, données, maintenance) et les risques à connaître
Pourquoi la qualité du dataset prime sur la technique

Qu'est-ce que le fine-tuning

Un LLM de base a été entraîné sur un corpus généraliste. Le fine-tuning poursuit cet entraînement sur un jeu de données ciblé pour spécialiser le modèle : 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), on modifie sa façon de répondre.

L'analogie utile : le prompt donne des instructions à un employé compétent ; le RAG lui fournit la documentation à consulter ; le fine-tuning l'envoie en formation pour changer durablement ses réflexes. La formation coûte cher et ne se justifie que quand les deux premiers ne suffisent pas.

Prompt vs RAG vs fine-tuning : l'arbre de décision

C'est la question à se poser avant tout. La règle est simple : commencer par le moins cher et ne monter en complexité que si le besoin l'exige.

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/coût d'un très gros prompt répété	Fine-tuning (parfois)

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.

LoRA et QLoRA : le fine-tuning devenu accessible

Le fine-tuning complet (mettre à jour tous les poids) exige des GPU hors de portée de la plupart des équipes. Les méthodes PEFT (Parameter-Efficient Fine-Tuning) ont changé la donne en n'entraînant qu'une petite fraction des paramètres.

LoRA (Low-Rank Adaptation) gèle le modèle d'origine et n'entraîne que de petites matrices ajoutées. Résultat : beaucoup moins de mémoire et des adaptateurs de quelques mégaoctets, échangeables à volonté.
QLoRA ajoute la quantification (le modèle de base est chargé en 4 bits) : on fine-tune un modèle de plusieurs milliards de paramètres sur un seul GPU grand public. C'est la méthode la plus répandue aujourd'hui.

Concrètement, LoRA et QLoRA permettent d'obtenir 80 à 95 % du gain d'un fine-tuning complet pour une fraction du coût. C'est le point d'entrée recommandé.

Le coût réel (et les risques)

Le coût GPU de l'entraînement n'est que la partie visible. Le vrai coût est ailleurs :

Les données : constituer un dataset propre et représentatif est le poste le plus lourd, et le plus déterminant.
L'évaluation : sans mesure avant/après, vous ne savez pas si le modèle s'est amélioré ou s'il a régressé (oubli catastrophique).
La maintenance : un modèle fine-tuné est figé ; chaque évolution du besoin relance un cycle.

Côté risques sécurité, deux points méritent l'attention de tout ingénieur : la fuite de données d'entraînement (le modèle peut restituer des exemples sensibles) et la reproductibilité (versionner dataset, seeds et hyperparamètres, sous peine de résultats impossibles à rejouer).

La qualité du dataset prime sur la technique

Un fine-tuning réussi tient à 80 % au dataset. Quelques centaines d'exemples soigneusement écrits battent des milliers d'exemples bruités. Les points clés : des exemples cohérents avec le comportement visé, dédoublonnés, au bon format (instruction/réponse, ou paires de préférences), et équilibrés. Mieux vaut peu de données excellentes que beaucoup de données moyennes.

Pièges courants

Fine-tuner au lieu de faire du RAG : le piège n°1. Pour des connaissances, RAG d'abord.
Pas d'évaluation : impossible de prouver le gain, ni de détecter une régression.
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 → RAG → fine-tuning, du moins cher au plus cher.
LoRA/QLoRA rendent le fine-tuning accessible sur un seul GPU.
Le dataset fait le résultat ; l'évaluation avant/après n'est pas optionnelle.
Pensez coût total, fuite de données et reproductibilité.

Prochaines étapes

Construire un RAG Souvent la bonne réponse avant de fine-tuner : ancrer le modèle sur vos données.

Quantification des LLM Réduire la mémoire d'un modèle, y compris après fine-tuning.

Faire tourner un LLM en local Servir un modèle (de base ou fine-tuné) avec Ollama.

Le parcours IA complet Revenir au sommaire de la formation IA.