Comment faire le réglage fin d’un LLM [et quand utiliser plutôt la RAG ou l’ingénierie de requêtes]
Ce guide explique comment effectuer le réglage fin d’un LLM étape par étape, compare le réglage fin complet avec LoRA et QLoRA, et montre quand l’ingénierie de requêtes ou la RAG est la meilleure façon d’améliorer les sorties d’un modèle.

Le réglage fin d’un grand modèle de langage (LLM) consiste à perfectionner un LLM préentraîné à l’aide d’un petit jeu de données propre à une tâche, afin qu’il produise des résultats impossibles à obtenir avec les seules invites.
Le réglage fin consiste à recueillir des exemples de paires entrée/sortie qui illustrent le comportement souhaité, à exécuter des passes d’entraînement qui orientent les poids du modèle vers ces exemples, puis à comparer le résultat aux sorties du modèle d’origine. Des méthodes efficaces en paramètres comme LoRA rendent ce processus assez économique pour être exécuté sur un seul GPU.
Si les résultats du LLM ne vous satisfont pas, commencez par peaufiner vos invites et votre génération augmentée par récupération (RAG). Le réglage fin modifie le comportement du LLM. Lorsque vous avez besoin qu’il utilise des informations récentes ou exclusives, les invites et la RAG sont généralement un meilleur choix.
Voici comment effectuer le réglage fin d’un LLM étape par étape, les principales méthodes de réglage fin (LoRA et QLoRA), ainsi que les défis et les erreurs qui peuvent faire dérailler le processus.
Qu’est-ce que le réglage fin d’un LLM et en quoi diffère-t-il du préentraînement?
Le préentraînement d’un LLM développe de zéro les capacités linguistiques générales d’un modèle à partir d’un vaste corpus, tandis que le réglage fin ajuste un modèle préentraîné sur un petit jeu de données pour une tâche précise.
Le préentraînement d’un LLM est la phase gourmande en ressources qui produit un modèle de base. Le modèle apprend à partir d’un vaste corpus de textes, ce qui lui confère une maîtrise générale de la grammaire, des faits et du raisonnement, mais aucune spécialisation pour votre tâche.
Le réglage fin d’un LLM poursuit l’entraînement du modèle de base sur un petit jeu de données soigneusement choisi afin qu’il produise les résultats souhaités pour une tâche ou un cas d’utilisation précis. Pensez à un format uniforme, à une voix ou à un ton de marque, à des schémas propres à un domaine ou encore à des appels d’outils et de fonctions fiables.
Quand effectuer le réglage fin d’un LLM, et quand privilégier les invites ou la RAG
Pour améliorer les performances d’un LLM, gravissez les échelons : invites -> RAG -> réglage fin.
Peaufinez vos invites avec des instructions plus détaillées et utilisez la RAG pour fournir au modèle des informations à jour. Ne recourez au réglage fin que si les améliorations apportées aux invites et à la récupération ne donnent pas les résultats escomptés.
Approche | Ce qu’elle modifie | À utiliser quand | Principale limite |
Ingénierie des invites | La requête que vous envoyez | Le comportement est presque au point, et vous recherchez la rapidité et la réversibilité | Limitée par les capacités existantes du modèle de base |
RAG | Ce que le modèle voit au moment de l’inférence | Les faits changent souvent, et le LLM doit avoir accès à des informations à jour | Ajoute une latence de récupération et une infrastructure supplémentaire; ne modifie pas le comportement |
Réglage fin d’un LLM | Les poids du modèle (ses paramètres internes) | Vous avez besoin d’un comportement, d’un format ou d’un ton uniformes à grande échelle, ou d’invites plus courtes à chaque appel | Coût initial, connaissances intégrées aux poids qui deviennent obsolètes, risque d’oubli des comportements acquis au préentraînement |
Quand de meilleures invites l’emportent sur le réglage fin, et quand elles ne suffisent pas
Les invites constituent le levier le plus rapide et le moins coûteux. Dans bien des cas, des invites plus précises et plus détaillées suffisent à obtenir les changements de comportement souhaités.
Mais des invites plus longues ralentissent le travail et le rendent plus coûteux, sans permettre de surmonter les limites existantes du modèle.
Signes que les invites ont peut-être atteint leurs limites :
- De nouveaux cas limites ne cessent de compromettre les résultats : par exemple, le modèle renvoie du texte libre alors qu’il vous faut du JSON, ou s’écarte du ton voulu, et vous corrigez l’invite à chaque nouveau cas.
- L’invite système ne cesse de s’allonger : elle compte des centaines, voire des milliers de lignes, et devient difficile à gérer.
- Vous payez à chaque appel : l’invite est renvoyée et retraitée à chaque requête, ce qui fait grimper le coût en jetons et la latence.
- Les modifications ne changent plus rien : les nouvelles instructions n’améliorent pas les résultats.
Même dans ce cas, essayez d’abord les correctifs moins coûteux au niveau des invites. Utilisez des exemples few-shot pour montrer au modèle le schéma attendu (paires entrée/sortie), le chaînage d’invites pour diviser les tâches complexes en étapes plus petites, ou des mécanismes d’appel de fonctions pour déléguer les recherches exactes ou les calculs.
Quand la RAG est plus judicieuse que le réglage fin du modèle
La RAG modifie ce que le LLM sait, tandis que le réglage fin modifie sa façon de se comporter. Si l’écart porte sur les connaissances, surtout des connaissances qui changent souvent ou qui se trouvent dans vos propres documents, la RAG est la solution. Si l’écart porte sur le comportement, optez pour le réglage fin.
Le réglage fin modifie aussi ce que sait un modèle, mais les faits qu’il assimile sont figés au moment de l’entraînement et deviennent vite désuets dans les domaines qui évoluent rapidement. De plus, l’information est intégrée aux poids du modèle, qui ne conservent aucune trace de sa source.
Mettre à jour les documents sources qu’utilise une couche de récupération est plus rapide et moins coûteux, et celle-ci peut citer les sources exactes qu’elle a utilisées. C’est donc un meilleur choix lorsque vous avez besoin d’informations à jour et justifiables.
L’inconvénient de la RAG? Il s’agit d’une couche supplémentaire à construire et à maintenir, qui ajoute de la latence.
En pratique, vous aurez souvent besoin des deux. Les systèmes en production associent des modèles affinés à la RAG : l’un assure un comportement uniforme, l’autre fournit des faits à jour.
Pièges, risques et défis courants du réglage fin
Même lorsque le réglage fin est le bon outil, il comporte des coûts et des risques :
- Coût et temps : rassembler des données d’entraînement propres et représentatives coûte cher, tout comme la puissance de calcul nécessaire à l’entraînement.
- Oubli catastrophique : entraîné sur un jeu de données restreint, un modèle peut perdre des compétences générales et présenter de nouveaux modes de défaillance, ce qui entraîne des erreurs que le modèle de base ne commettait pas.
- Surapprentissage : avec des données trop peu nombreuses ou trop répétitives, le modèle mémorise vos exemples d’entraînement au lieu d’apprendre des schémas; il obtient donc de bons résultats sur ses échantillons d’entraînement, mais de piètres résultats sur des entrées réelles.
- Connaissances périmées : les connaissances intégrées aux poids vieillissent vite, ce qui vous oblige à réentraîner le modèle sur de nouvelles données.
- Obsolescence : lorsqu’un modèle plus performant sort, il surpasse souvent d’emblée votre modèle affiné, et vous devez refaire le travail.
- Difficultés d’évaluation et de reproduction : il est difficile de prouver que le modèle affiné surpasse le modèle de base. De plus, deux entraînements sur GPU avec les mêmes paramètres peuvent produire des modèles légèrement différents.
- Gouvernance des données : l’entraînement sur des données exclusives ou sensibles soulève des questions de confidentialité et de licences; un modèle peut ensuite faire ressurgir des fragments des données sur lesquelles il a été entraîné.
Les principales méthodes de réglage fin
Les principaux types de réglage fin des LLM se distinguent par la part du modèle qu’ils modifient : le réglage fin complet réentraîne l’ensemble du modèle, tandis que les méthodes de réglage fin efficace en paramètres (PEFT) comme LoRA et QLoRA ne mettent à jour qu’une partie des poids. Les méthodes PEFT ne consomment qu’une fraction de la mémoire requise par un réglage fin complet et, avec les bons paramètres, peuvent obtenir des résultats équivalents.
Le réglage fin complet met à jour chacun des poids du modèle. C’est la méthode la plus coûteuse et celle qui présente le risque d’oubli catastrophique le plus élevé. Réservez-la aux changements de comportement importants, lorsque vous disposez des données et de la puissance de calcul nécessaires.
L’autre option est le réglage fin efficace en paramètres, ou PEFT. Ce terme générique désigne les méthodes qui figent la majeure partie du modèle et n’entraînent qu’un petit ensemble de paramètres. Elles utilisent beaucoup moins de mémoire et sont moins sujettes à l’oubli, puisque le modèle de base reste intact.
Avec des rangs faibles, le PEFT apprend moins qu’un réglage fin complet, mais augmenter le rang et ajuster le taux d’apprentissage permet de combler l’essentiel de l’écart pour les tâches de réglage par instructions.
Parmi les méthodes PEFT, on trouve :
- LoRA (Low-Rank Adaptation, ou adaptation de faible rang) : point de départ habituel, cette méthode fige les poids d’origine et entraîne un petit ensemble de paramètres d’adaptateur ajoutés, représentant souvent moins de 1 % du total, ce qui lui permet de fonctionner sur un seul GPU grand public.
- QLoRA (Quantized Low-Rank Adaptation, ou adaptation de faible rang quantifiée) : cette méthode compresse le modèle de base à une précision de 4 bits avant d’appliquer LoRA, ce qui permet d’effectuer le réglage fin d’un grand modèle sur un seul GPU.
Méthode | Ce qu’elle met à jour | Matériel requis en pratique | À utiliser quand |
Réglage fin complet | Tous les poids du modèle | Un nœud multi-GPU pour les modèles de la classe 7B, bien davantage pour les plus gros | Vous avez besoin d’un changement de comportement profond et disposez des données et de la puissance de calcul nécessaires |
LoRA (PEFT) | Un petit ensemble de poids d’adaptateur ajoutés | Un seul GPU grand public | Votre point de départ par défaut |
QLoRA (PEFT) | Des adaptateurs LoRA sur un modèle de base compressé à 4 bits | De très grands modèles sur un seul GPU | Vous manquez de mémoire, mais voulez un gros modèle de base |
En complément, nous utilisons des méthodes de réglage par instructions et par préférences, de l’apprentissage par renforcement à partir de la rétroaction humaine (RLHF) à des solutions plus légères comme l’optimisation directe des préférences (DPO) et l’optimisation des préférences par rapport de cotes (ORPO), afin de façonner la manière dont un modèle suit les instructions et s’aligne sur les préférences humaines.
Comment effectuer le réglage fin d’un LLM étape par étape
Une fois que vous avez déterminé que le réglage fin d’un LLM est la bonne solution, voici le flux de travail à suivre.
Étape 1 : définir la tâche et la façon de mesurer la réussite
Déterminez le comportement que vous attendez du LLM et la façon dont vous saurez que vous l’avez obtenu.
Nommez la tâche précise que le modèle affiné doit accomplir, par exemple classer des demandes de soutien, résumer des contrats dans un format fixe ou générer du code selon les conventions de votre entreprise.
Définissez ensuite ce qu’est la réussite. Voici quelques options courantes :
- Validité des résultats : par exemple, le résultat est-il un JSON valide ou respecte-t-il la structure Markdown dont vous avez besoin?
- Scores automatisés : utilisez des métriques comme BLEU ou ROUGE, qui comparent le texte généré à des réponses de référence, ou l’exactitude sur la tâche mesurée à l’aide d’un jeu étiqueté.
- Évaluations humaines : une grille d’évaluation, notée ou de type réussite/échec, pour les qualités qu’un script évalue mal, comme le ton ou l’utilité.
- Fiabilité sur les entrées difficiles : le modèle gère-t-il les entrées inhabituelles qui faisaient trébucher le modèle de base?
Étape 2 : préparer votre jeu de données
La qualité des données détermine la réussite du réglage fin; consacrez donc des efforts à la constitution du bon jeu de données de réglage fin.
Structurez vos données en paires instruction/réponse au format JSONL, où chaque ligne contient l’entrée (avec tout contexte pertinent) et la sortie exacte que vous souhaitez obtenir.
Par exemple, consultez des jeux de données publics comme Alpaca-cleaned, consacré aux instructions générales, ou Dolly de Databricks, ou encore banking77, propre à une tâche, qui comprend plus de 13 000 véritables demandes de soutien étiquetées selon 77 intentions.
Pour une tâche ciblée, quelques centaines à quelques milliers d’exemples propres et variés peuvent suffire à modifier le comportement, à condition que les exemples reflètent les entrées réelles en production, y compris les cas limites, et qu’ils soient mis en forme de façon uniforme.
Vous n’avez pas encore de paires entrée/sortie? Constituez le jeu à partir des données dont vous disposez déjà, comme des demandes de soutien et leurs meilleures réponses, ou des documents et leurs résumés.
Si vous ne disposez que des sorties, utilisez un modèle plus performant pour générer une entrée plausible pour chacune d’elles, ou rédigez à la main un petit ensemble de départ et élargissez-le à l’aide d’un plus grand modèle « enseignant », puis conservez les meilleures paires.
Terminez en répartissant les données en jeux d’entraînement, de validation et de test, afin de pouvoir mesurer les performances sur des exemples que le modèle n’a jamais vus.
Étape 3 : choisir un modèle de base et une méthode
Commencez avec un petit modèle open source de 3 à 7 milliards de paramètres et une méthode de réglage fin efficace en paramètres comme LoRA ou QLoRA.
Les familles de modèles ouverts comme Llama, Mistral et Qwen vous offrent une base solide que vous pouvez héberger vous-même, et les méthodes PEFT maintiennent des exigences matérielles modestes : QLoRA quantifie le modèle de base à 4 bits, de sorte que le réglage fin d’un modèle 7B ne nécessite qu’une carte grand public de 16 à 24 Go. Le réglage fin complet de ce même modèle exige plusieurs fois cette quantité de mémoire.
Étape 4 : définir vos hyperparamètres d’entraînement
Voici les principaux paramètres de réglage fin d’un LLM et les plages de départ suggérées :
- Le taux d’apprentissage détermine l’ampleur de chaque mise à jour des poids. Une étude menée en 2024 par Biderman et al. a révélé que les meilleurs taux pour LoRA étaient environ dix fois plus élevés que ceux du réglage fin complet, soit généralement de 5e-5 à 5e-4 contre 1e-5 à 5e-5. L’étude recommande de balayer les valeurs de 1e-5 à 5e-4 et d’utiliser la valeur la plus élevée qui permet un entraînement stable.
- La taille de lot correspond au nombre d’exemples à partir desquels le modèle apprend avant chaque mise à jour des poids. Sur un seul GPU, utilisez un petit lot de 1 à 8 par appareil et l’accumulation de gradients pour atteindre un lot effectif d’environ 16 à 64.
- Le nombre d’époques correspond au nombre de fois où le modèle parcourt l’ensemble des données. Pour entraîner le modèle à accomplir des tâches précises, de 1 à 3 époques constituent une bonne règle empirique, mais les entraînements LoRA en exigent souvent davantage.
- Le rang LoRA (r) détermine la capacité de l’adaptateur, autrement dit ce qu’il est capable d’apprendre. Commencez avec une valeur de 8 à 32 pour les tâches plus simples et augmentez-la pour les plus complexes : dans l’étude LoRA de Biderman et al. citée plus haut, le réglage par instructions d’un modèle de 7 milliards de paramètres sur du code a nécessité un rang de 256 pour égaler le réglage fin complet, alors qu’un rang de 64 s’en approchait en mathématiques.
- La longueur maximale de séquence correspond à l’entrée la plus longue que l’entraînement traitera. Réglez-la de façon à couvrir vos exemples les plus longs, jusqu’à la limite de la fenêtre de contexte du modèle, car tout ce qui dépasse sera tronqué.
- Le préchauffage et le calendrier déterminent la façon dont le taux d’apprentissage augmente progressivement, puis évolue au fil de l’entraînement. Un court préchauffage et une décroissance cosinus sont les valeurs par défaut habituelles. Cependant, l’étude de Pareja et al. sur les petits modèles a révélé que supprimer le préchauffage ne nuisait pas aux résultats finaux.
Considérez ces valeurs comme des points de départ pour un balayage d’hyperparamètres, et non comme des réglages fixes.
Étape 5 : Entraîner le modèle et surveiller la perte
Pendant l’entraînement, surveillez les courbes de perte d’entraînement et de validation pour vérifier que tout fonctionne.
La perte mesure l’écart entre les sorties du modèle et vos exemples; elle devrait diminuer régulièrement au fil de l’entraînement. La perte d’entraînement porte sur les données à partir desquelles le modèle apprend. La perte de validation porte sur les exemples mis de côté.
Si la perte d’entraînement et la perte de validation diminuent ensemble, le modèle apprend à généraliser. Si la perte d’entraînement continue de baisser, mais que la perte de validation stagne ou remonte, le modèle mémorise l’ensemble d’entraînement au lieu d’apprendre le schéma sous-jacent (surapprentissage).
Étape 6 : Évaluer, puis déployer
Une faible perte d’entraînement ne garantit pas des sorties correctes; évaluez donc le modèle ajusté selon les critères définis à l’étape 1.
Une fois l’évaluation réussie, vous avez deux options de déploiement :
- Servez l’adaptateur en plus du modèle de base et chargez les deux lors de l’exécution; l’adaptateur demeure ainsi interchangeable.
- Fusionnez l’adaptateur avec les poids du modèle de base pour obtenir un modèle autonome unique, plus simple à héberger.
Utilisez Perplexity pour donner à votre LLM accès à de l’information à jour
Le réglage fin est le bon choix lorsque vous voulez adapter le comportement du modèle à vos besoins.
Si votre modèle a besoin d’information actuelle, surtout d’information qui change rapidement, il vous faut une solution RAG ou un outil de recherche tiers fiable.
Une pile de récupération sur mesure convient mieux aux jeux de données exclusifs, comme votre wiki interne, l’historique de votre service à la clientèle, vos contrats ou la documentation de vos produits.
Lorsque les connaissances que vous voulez utiliser sont publiques, inutile de bâtir une couche de récupération sur mesure. Perplexity est un moteur de réponses qui fournit des réponses accompagnées de citations cliquables intégrées, tirées d’un index Web en temps réel. Son Agent API livre ces réponses sourcées et ancrées dans le Web en un seul appel, pour que votre application puisse s’appuyer sur des sources actuelles.
Foire aux questions sur le réglage fin des LLM
Peut-on effectuer le réglage fin d’un LLM gratuitement?
Oui, vous pouvez effectuer gratuitement le réglage fin d’un petit LLM ouvert. Par exemple, l’offre gratuite de Google Colab fournit suffisamment de puissance GPU pour exécuter QLoRA sur un modèle de 3 à 8 milliards de paramètres, ce qui suffit amplement pour une tâche ciblée. Vous commencez à payer lorsque vous avez besoin de plus de mémoire, d’entraînements plus longs ou d’un modèle de base plus gros que ce que l’offre gratuite peut prendre en charge.
Avez-vous besoin de votre propre GPU, ou pouvez-vous effectuer le réglage fin dans le nuage?
Vous n’avez pas besoin de posséder un GPU pour effectuer le réglage fin de LLM. Les services gérés et les fournisseurs infonuagiques de GPU louent le matériel à l’heure : un seul GPU loué suffit donc pour un entraînement QLoRA sur un petit modèle. L’achat d’un GPU n’est rentable que si vous effectuez souvent des réglages fins ou si vous devez conserver toutes vos données sur vos propres machines.
Combien de temps prend le réglage fin d’un LLM?
Pour un petit LLM, un entraînement peut se terminer en quelques minutes ou en quelques heures, selon la taille du jeu de données et le matériel. Oumi, par exemple, a effectué le réglage fin complet d’un modèle de 0,8 milliard de paramètres en un peu plus d’une heure sur sa plateforme hébergée.
Avec des modèles plus gros ou des dizaines de milliers d’exemples, cette durée peut atteindre une journée ou plus : les entraînements LoRA d’Emburse sur un modèle de 7 milliards de paramètres ont pris 8 heures pour 5 000 exemples et environ 30 heures pour 50 000 exemples sur un seul GPU de 40 Go.
Pouvez-vous continuer à mettre à jour un modèle ajusté à mesure que vos données évoluent?
Vous pouvez refaire un réglage fin sur des données récentes, mais chaque cycle consomme des ressources de calcul et comporte un risque d’oubli catastrophique. Pour les connaissances qui changent souvent, la RAG est généralement la meilleure solution, puisque vous mettez à jour les documents sources au lieu de réentraîner le modèle.