Fine-tuning avec LoRA et QLoRA

Le fine-tuning règle le comportement, pas les connaissances. C'est le bon outil quand le modèle connaît la matière mais exécute la mauvaise danse : mauvais format de sortie, mauvais ton, mauvais dialecte de domaine, mauvais étalonnage des refus. C'est le mauvais outil pour « connaît mes documents » — ça, c'est de la récupération : RAG.

Fine-tuner ou pas

Si un prompt ou un schéma peut le faire, préférez le prompt ou le schéma. Réglez quand vous vous surprenez à coller les mêmes 300 jetons d'instructions dans chaque appel.

LoRA en un paragraphe

Figez tous les poids de base. Pour chaque matrice de poids cible, ajoutez deux petites matrices entraînables — A (r×d) et B (d×r) — et entraînez seulement celles-là. La mise à jour est de rang faible :

W' = W + (alpha / r) · B·A      # A est r×d, B est d×r, rang r << d

Concret : une matrice d = 4096 au rang r = 16 exige 2 × 4096 × 16 = 131k paramètres d'adaptateur au lieu de 4096² ≈ 16.8M denses — 0.8% de cette matrice. Sur un modèle 7–8B, les adaptateurs totalisent ~40–80M paramètres : 0.5–1% de la base, quelques centaines de MB. C'est assez de capacité pour déplacer fortement style et format, parce que ces comportements vivent dans des directions fortement de rang faible.

QLoRA : une carte grand public

QLoRA garde la base figée quantifiée en 4 bits (NF4) pendant l'entraînement et exécute les adaptateurs en 16 bits. Chiffres de travail sur les piles actuelles : un modèle 7–8B s'entraîne en QLoRA sur un seul GPU 24GB ; un 3B s'entraîne confortablement en 8GB. Checkpointing de gradient et optimiseurs paginés sont gérés par l'outillage — ce que vous fournissez, c'est le calcul de budget : calcul de VRAM.

Les données battent tout

500–5,000 paires de haute qualité battent 100k paires grattées, à chaque fois. Les règles qui comptent :

• Un format cohérent. Utilisez le gabarit de conversation exact avec lequel vous servirez — un décalage de gabarit entraînement/service défait tout le run.
• La qualité plutôt que le volume. Chaque paire devrait être une sortie que vous accepteriez du modèle. Dédupliquez ; jetez les exemples paresseux.
• Couverture. Incluez les cas où vous voulez que le modèle refuse ou traite spécialement — sinon il sur-généralise son nouveau comportement sur tout.
• Vérifications de contamination. Assurez-vous que les questions d'éval n'apparaissent pas dans les données d'entraînement — sinon vous notez de la mémorisation.
• Jeu d'éval mis à part. 50–100 exemples jamais entraînés, notés avant et après.

À quoi ressemble une paire (le format messages que la plupart des outils consomment) :

{"messages": [{"role": "system", "content": "Tu es un assistant pour manuels d'équipement de 1998."},
              {"role": "user", "content": "Comment réinitialiser le compteur de service ?"},
              {"role": "assistant", "content": "Appuie sur MENU et maintiens 3 secondes..."}]}

Outils

À ce jour, les trois sont activement maintenus : unsloth, axolotl, llama-factory.

Les hyperparamètres qui comptent vraiment

Par ordre d'impact :

• Taux d'apprentissage — 1e-4 à 2e-4 pour QLoRA est la bande saine ; trop haut est la cause habituelle de la bouillie.
• Époques — 1–3. Plus, et voilà d'où vient l'homme-oui.
• Rang / alpha — r 8–32 avec alpha 16–32 couvre la plupart des ajustements de comportement ; rang plus gros pour les décalages lourds de domaine.
• Longueur de contexte — réglée sur votre plus long vrai exemple, pas le défaut du trainer.
• Taille de lot — 1–8 est normal pour QLoRA sur une carte ; c'est un réglage de débit, pas de qualité.

Si un run déçoit, corrigez les données d'abord, le taux d'apprentissage ensuite, le rang en dernier.

Temps et coût

QLoRA sur 2,000 paires, 3 époques, modèle 7–8B : attendez 1–3 heures sur une carte de classe RTX 3090/4090. C'est de l'électricité, pas des factures d'API, et l'itération tient au pire une nuit. Voilà pourquoi le fine-tuning local est un loisir, pas un processus d'achat.

Budgétez l'itération : le premier run vous apprend les problèmes de données, le second est celui que vous gardez.

Évaluez avant de livrer

Exécutez une suite fixe de 30–50 prompts — jeu mis à part compris — avant et après ; comparez les sorties côte à côte. Puis vérifiez par régression le chat général : l'échec classique est un modèle réglé domaine qui répond à tout au format rapport de bug. Si la qualité générale a chuté, utilisez moins d'époques, un taux d'apprentissage plus bas, ou mélangez 10–30% de données d'instructions générales au run.

Les courbes de loss servent à repérer la divergence, pas à noter : la loss d'entraînement doit tomber et s'aplatir. La suite d'éval est l'arbitre.

Exporter et servir

Deux chemins depuis un adaptateur entraîné :

• Fusionner le LoRA dans la base en fp16, puis convertir en GGUF pour llama.cpp — l'artefact compatible avec le forum : un fichier, tout moteur : formats de modèles, quantification.
• Garder l'adaptateur séparé pour transformers/vLLM, qui chargent base + adaptateur à l'exécution — moins cher à itérer, spécifique au moteur.

Modes de défaillance

• Surapprentissage / homme-oui — renvoie votre prompt en écho, approuve tout ; loss d'entraînement basse, éval pire. Correctif : moins d'époques, LR plus bas, données plus diverses.
• Oubli catastrophique — compétence de domaine en haut, capacité générale en bas. Correctif : mélanger des données générales ; LR plus bas.
• Dérive de gabarit — entraîné avec un gabarit de conversation, servi avec un autre ; les symptômes sont les classiques de dépannage.

DPO après SFT

Quand le format est bon mais les préférences décalées — trop verbeux, mauvais ton, refuse trop — un petit run DPO sur des paires de préférences (réponses choisies vs rejetées) ajuste le comportement sans nouvelle passe SFT. Bon marché, stable, et le second stade standard de la recette SFT-puis-DPO.

Voir aussi : RAG · formats de modèles · quantification · calcul de VRAM