Module 7 — Affinage économique d'un petit modèle
Après quantification, notre modèle atteint 91 % sur les 200 tickets d'évaluation. Après distillation (module 3), 91 % aussi — mais avec un modèle qui ne connaît toujours pas les cinq catégories internes propres à notre entreprise, absentes des données d'entraînement d'origine. L'affinage LoRA fait franchir la barrière des 95 % pour quelques dizaines d'euros et quelques centaines d'exemples soigneusement annotés. Ce module explique comment.
Ce que LoRA change au calcul
Le cours 19 a détaillé LoRA en profondeur ; nous en reprenons les éléments qui pèsent ici. LoRA ne modifie pas les poids du modèle : il ajoute des matrices d'adaptation de petite taille (rang 8, 16 ou 32) à côté des couches d'attention et parfois des couches MLP. Seules ces matrices sont apprises ; les poids d'origine restent gelés. Sur un modèle 3B, LoRA ajoute environ 5 à 25 millions de paramètres entraînables, contre 3 milliards en affinage complet — soit 0,2 à 0,8 % du modèle.
Deux conséquences directes. Le calcul de rétropropagation ne traverse plus les 3 milliards de poids, ce qui divise par 5 à 8 le temps de rétropropagation et l'empreinte mémoire. Et l'adaptateur produit à la fin pèse quelques dizaines de mégaoctets, ce qui permet de garder plusieurs adaptateurs spécialisés — un pour la classification, un pour le résumé, un pour l'extraction de références — et de basculer entre eux sans recharger le modèle de base.
QLoRA ajoute une astuce : entraîner l'adaptateur alors que le modèle de base est déjà quantifié en 4 bits. La mémoire GPU nécessaire tombe de 24 Go (LoRA classique sur 3B en 16 bits) à 7 Go — un modèle 3B tient alors sur une RTX 3060 12 Go, voire sur une 3050 8 Go pour les plus petits. C'est ce que permet en pratique l'affinage sur poste de développeur, sans passer par un fournisseur cloud.
Le jeu de tickets annotés
Le levier de qualité n'est pas dans les hyperparamètres, il est dans le jeu d'annotations. Deux règles gouvernent sa constitution.
Cent exemples propres valent mille exemples douteux. Il vaut infiniment mieux 300 tickets relus par deux experts métier, annotés en catégorie et avec un résumé écrit à la main, que 5 000 tickets annotés vite fait par le premier stagiaire disponible. Le modèle apprend le bruit qu'on lui donne ; un jeu propre plafonne haut, un jeu bruité plafonne bas quelle que soit la quantité.
La distribution des catégories doit refléter la production. Si en production 60 % des tickets tombent dans la catégorie « facturation », 60 % du jeu d'entraînement doit venir de cette catégorie. Un rééquilibrage à parts égales artificielles apprend au modèle une répartition qu'il ne verra jamais et dégrade l'exactitude réelle.
Pour notre projet, 800 tickets annotés, relus par un binôme d'agents seniors sur trois demi-journées, produisent un jeu suffisant. Nous en gardons 600 pour l'entraînement, 200 pour la validation — jamais confondus avec les 200 tickets d'évaluation intouchables du protocole général.
Le budget en minutes GPU et en euros
Sur un modèle 3B en QLoRA, rang 16, deux époques d'entraînement sur 600 exemples, la durée typique est de :
- 20 minutes sur RTX 4070 12 Go
- 35 minutes sur RTX 3060 12 Go
- 1 h 10 sur RTX 3050 8 Go
- 2 h 30 sur MacBook Pro M3 Pro
À 0,50 euro l'heure de RTX 4070 en location cloud (2026), une itération complète coûte 0,17 euro. On peut réellement se permettre cinq à dix itérations pour tester des taux d'apprentissage, des rangs et des mélanges de données différents, sans dépasser 2 euros au total. C'est ce qui rend cet affinage économique : à peu près trois cafés.
Ce qu'on observe pendant l'entraînement
Sur nos 600 exemples, la perte de validation descend de 1,8 à 0,42 en deux époques, puis remonte à 0,55 dès la troisième — signe classique de surapprentissage. L'arrêt anticipé sur la meilleure perte de validation retient les poids de l'époque 2. L'exactitude sur les 200 tickets d'évaluation passe alors de 91 % (modèle quantifié brut) à 96 %, avec un résumé jugé « correct ou meilleur » par nos experts humains dans 87 % des cas contre 68 % auparavant.
À ce stade, l'écart avec le grand modèle en API se referme presque totalement. Sur cette tâche étroite, précise et bien annotée, un modèle 3B affiné rivalise avec un modèle 70B en API. Ce résultat n'est pas garanti pour toutes les tâches, il est simplement caractéristique de ce que produit un affinage propre sur une tâche bien cadrée.
Les pièges qui ruinent un affinage
Trois erreurs récurrentes.
Taux d'apprentissage trop élevé. LoRA demande des taux plus bas qu'un affinage complet (1e-4 à 3e-4 typiquement, à comparer à 5e-5 pour un affinage complet). Un taux à 1e-3 casse le modèle de base en deux étapes.
Rang trop grand. Passer de rang 8 à rang 128 multiplie les paramètres par 16 et rapproche LoRA d'un affinage complet, avec les mêmes risques de surapprentissage. Rang 16 est la valeur par défaut raisonnable ; monter au-delà exige une justification par la validation.
Contamination entre validation et entraînement. Un ticket qui apparaît dans les deux ensembles fausse toutes les mesures. Vérifier la disjonction par hachage stable des textes, pas par ordre de tirage.
Le fichier d'adaptateur LoRA final pèse 40 à 80 Mo. On peut donc versionner et distribuer les adaptateurs comme du code : chaque équipe entretient son propre adaptateur au-dessus d'un modèle de base commun, et une mise à jour du modèle de base ne casse pas les adaptateurs si le rang et la cible restent inchangés. C'est le déploiement continu appliqué aux modèles.
En résumé
- LoRA n'affine que 0,2 à 0,8 % du modèle, ce qui divise par 5 à 8 le coût de rétropropagation et produit un adaptateur de quelques dizaines de mégaoctets.
- QLoRA ajoute une quantification 4 bits sur le modèle de base et fait tenir un affinage 3B sur une RTX 3060 12 Go, soit 20 à 70 minutes selon la carte.
- La qualité des annotations compte davantage que leur volume ; 300 à 800 tickets propres, avec une distribution fidèle à la production, suffisent.
- Sur notre fil rouge, l'affinage fait passer l'exactitude de 91 à 96 % et le résumé de 68 à 87 % de succès, pour un budget d'environ 2 euros.
Module suivant : déployer ce modèle affiné et quantifié directement sur le poste de l'agent, sans connexion au nuage, avec Ollama ou llama.cpp.