Fine-tuning de modèles open source sur vos propres données

Les grands modèles de langage arrivent pré-entraînés sur de vastes portions du web public. Cette largeur les rend impressionnamment polyvalents — mais polyvalent ne signifie pas expert. Quand votre activité a besoin d’un modèle qui comprend votre taxonomie interne, écrit dans votre style maison ou raisonne sur des processus propriétaires, trois voies d’adaptation s’ouvrent : le prompt engineering, la génération augmentée par récupération (RAG) et le fine-tuning. Chacune a sa place, et choisir la bonne — ou la bonne combinaison — peut faire la différence entre un prototype et un système en production. Privonis aide les organisations européennes à naviguer dans ce choix et à l’exécuter entièrement au sein de leur propre infrastructure.

Trois voies vers l’adaptation au domaine

Le prompt engineering ne coûte rien au-delà des essais et des erreurs, mais il se heurte à un mur dur : vous ne pouvez mettre que tant de contexte dans une fenêtre, et le modèle peut tout simplement manquer des connaissances du domaine dont vous avez besoin. Le RAG contourne la limite de contexte en récupérant des segments pertinents d’une base de connaissance au moment de la requête et en les transmettant au modèle. C’est puissant et étonnamment bon marché, mais la qualité de la récupération plafonne la qualité des réponses — si le bon segment n’est pas trouvé, le modèle ne peut pas raisonner dessus.

Le fine-tuning adopte une approche différente : il met à jour les poids du modèle sur votre jeu de données curé afin que la connaissance du domaine devienne intrinsèque. Le résultat est un modèle qui répond à partir d’une expertise intégrée plutôt que de fragments récupérés. Il est généralement plus performant sur les tâches sensibles au style, les sorties structurées et les pipelines critiques en termes de latence où vous ne pouvez pas vous permettre un aller-retour de récupération supplémentaire. L’inconvénient est le coût — tant en temps GPU qu’en préparation des données — donc cela vaut la peine d’y recourir lorsque les deux autres méthodes ont atteint leur plateau.

Quand le fine-tuning est le bon choix

• Vos sorties doivent suivre un format précis (notes cliniques, clauses juridiques, JSON structuré) que les templates de prompt ne peuvent pas appliquer de façon fiable.
• Le modèle manque systématiquement de vocabulaire du domaine, d’acronymes ou de noms de produits qui n’ont jamais figuré dans son corpus de pré-entraînement.
• Les exigences de latence excluent un saut de récupération à chaque requête.
• Vous voulez compresser un prompt complexe multi-exemples en comportement zéro-exemple pour le coût et la vitesse.
• Vous distillez un modèle plus grand dans un modèle plus petit et moins coûteux pour un déploiement sur edge ou on-premise.

LoRA et QLoRA : fine-tuning sans budget de centre de données

Le fine-tuning complet met à jour chaque poids du modèle, ce qui est prohibitivement coûteux pour des modèles de dizaines de milliards de paramètres. L’adaptation par rang bas (LoRA) contourne cela en injectant de petites matrices entraînables dans les couches d’attention tout en gelant les poids d’origine. Le nombre de paramètres entraînables chute d’un facteur 100 ou plus, mais le modèle résultant égale ou dépasse la qualité du fine-tuning complet sur la plupart des tâches. QLoRA ajoute la quantization à cette approche — le modèle de base gelé est chargé en précision 4 bits, réduisant si dramatiquement les besoins en mémoire GPU qu’un modèle de 70 milliards de paramètres peut être affiné sur un seul A100.

Avec QLoRA, une équipe qui possède un A100 peut affiner un modèle open source de pointe en une après-midi — sans compte cloud, sans donnée quittant les locaux.

Préparation des données : l’étape décisive

La qualité du modèle est bornée par la qualité des données. Avant tout cycle d’entraînement, Privonis travaille avec ses clients pour constituer un jeu de données supervisé de paires entrée-sortie qui représente exactement le comportement souhaité. Les sources typiques incluent : interactions clients vérifiées, sorties de modèle corrigées, documents annotés par des experts et données synthétiques générées par un modèle enseignant plus puissant puis filtrées. Le volume compte moins que la diversité et la correction — mille exemples soigneusement vérifiés surpassent souvent dix mille exemples bruités. Les pipelines de nettoyage des données gèrent la déduplication, le rognage en longueur et la normalisation du format avant le début de l’entraînement.

Évaluation : savoir quand on a terminé

Le fine-tuning sans évaluation rigoureuse est une optimisation dans l’obscurité. Un jeu d’évaluation mis de côté — jamais vu pendant l’entraînement — mesure si le modèle a généralisé ou simplement mémorisé. Les métriques dépendent de la tâche : correspondance exacte et F1 pour les tâches d’extraction, ROUGE pour le résumé, évaluations de préférence humaine pour la génération ouverte. Privonis exécute des évaluations automatisées après chaque point de contrôle et signale l’oubli catastrophique — les cas où le modèle gagne en compétences du domaine mais perd en raisonnement général — en incluant un échantillon de benchmark standard dans chaque suite d’évaluation.

Les poids vous appartiennent

C’est le point qui se perd souvent dans les discussions sur les API de fine-tuning hébergées dans le cloud : quand vous affinez via un service tiers, les poids résultants peuvent être verrouillés chez ce fournisseur. Avec Privonis, le modèle de base est open-weight, la session d’entraînement se déroule sur du matériel que vous contrôlez, et l’adaptateur LoRA ou le point de contrôle fusionné vous appartient pour le conserver, le versionner et le déployer où vous le souhaitez. Cela signifie aucune dépendance fournisseur, aucun frais au token sur un modèle que vous avez payé pour entraîner, et aucun risque que le fournisseur ré-entraîne sur vos données. Pour les entreprises européennes qui traitent des informations sensibles, conserver les poids n’est pas un avantage agréable à avoir — c’est une exigence de gouvernance.