« Il faudrait entraîner le modèle sur nos données. » La phrase revient dans presque tous les comités de projet, et neuf fois sur dix elle désigne un besoin que l'entraînement ne résoudra pas. Le débat fine tuning ou RAG se tranche pourtant assez simplement, à condition de poser la bonne question de départ : votre problème porte-t-il sur ce que le modèle sait, ou sur la façon dont il se comporte ?
Ce sont deux problèmes distincts, traités par deux mécanismes distincts. Le RAG donne au modèle les documents pertinents au moment de la question : il agit sur la connaissance. Le fine-tuning ajuste les paramètres du modèle sur des exemples : il agit sur le comportement, le style, le format, la manière de traiter une tâche répétitive.
Confondre les deux coûte cher, et pas seulement en argent. Une entreprise qui entraîne un modèle sur son catalogue produit se retrouve avec un modèle qui parle correctement de produits qui n'existent plus, et qu'il faudra réentraîner à chaque mise à jour. Voyons comment éviter cela.
Ce que le RAG traite bien
Le RAG répond à un besoin de connaissance factuelle, changeante et vérifiable. Il excelle sur quatre situations :
- Les informations qui évoluent : tarifs, procédures, catalogues, jurisprudence interne, documentation technique.
- Le besoin de citer ses sources : quand l'utilisateur doit pouvoir remonter au document d'origine.
- Les droits d'accès différenciés : chacun n'interroge que ce qu'il a le droit de voir, filtrage impossible avec un modèle entraîné.
- Les volumes documentaires importants : rien n'oblige à tout mémoriser, il suffit de savoir retrouver.
Son avantage décisif est la fraîcheur. Mettre à jour un RAG consiste à réindexer un document, opération de quelques secondes. Le mécanisme complet, du découpage à la réponse sourcée, est détaillé dans notre article sur le RAG appliqué aux documents d'entreprise.
Ses limites sont tout aussi nettes. Le RAG n'apprend pas un style. Il ne raccourcit pas les réponses, ne fait pas adopter votre nomenclature interne, et n'améliore pas la fiabilité d'un format de sortie. Il ne réduit pas non plus le coût par requête, puisqu'il ajoute des extraits à chaque appel.
Ce que le fine-tuning traite bien
Le fine-tuning consiste à poursuivre l'entraînement d'un modèle existant sur vos exemples. Aujourd'hui, cela se fait rarement en modifiant tous les paramètres : on utilise des méthodes d'adaptation légère qui n'entraînent qu'un petit nombre de paramètres supplémentaires, ce qui réduit fortement le coût et la taille du résultat.
Quatre besoins le justifient réellement :
- Un format de sortie strict et répétitif : extraction de champs, classification dans une nomenclature maison, production de structures que le modèle de base rate encore une fois sur dix.
- Un style ou un ton propre difficile à décrire mais facile à montrer sur des centaines d'exemples.
- Une tâche unique à très fort volume, où l'on veut réduire la longueur des consignes envoyées à chaque appel, donc le coût et la latence.
- Un jargon métier dense que le modèle interprète mal malgré un contexte fourni.
Là encore, les limites comptent autant. Un modèle entraîné ne cite pas ses sources. Il n'a aucune notion de droits d'accès. Il fige la connaissance au jour de l'entraînement, et il vous lie à un modèle de base que vous aurez choisi selon une grille de sélection qu'il faudra rejouer à chaque évolution. Et il ne supprime pas les inventions : il apprend même à en produire de nouvelles si vos exemples en contiennent.
Fine tuning ou RAG : les deux approches face à face
| Critère | RAG | Fine-tuning |
|---|---|---|
| Nature du besoin | Connaissance factuelle | Comportement, style, format |
| Mise à jour | Réindexation, quelques secondes | Nouvel entraînement, quelques heures à quelques jours |
| Sources citables | Oui, par construction | Non |
| Gestion des droits | Possible, au niveau de chaque extrait | Impossible |
| Données nécessaires | Vos documents, tels quels | Des centaines à des milliers d'exemples annotés |
| Délai de mise en place | Quelques jours pour un premier résultat | Plusieurs semaines, dont l'essentiel en préparation des données |
| Coût par requête | Plus élevé, le contexte est plus long | Plus faible, consigne courte |
| Compétence requise | Développement applicatif et rigueur documentaire | Préparation de jeux de données et évaluation |
Le troisième chemin, et il gagne souvent
Avant d'arbitrer entre les deux, vérifiez que la question se pose. Dans un grand nombre de projets, le résultat insatisfaisant vient d'une consigne incomplète, pas d'une limite du modèle. Un format mal respecté parce qu'il n'a jamais été décrit précisément, un ton inadapté parce qu'aucun exemple n'a été fourni, des inventions parce que rien n'autorise le modèle à dire qu'il ne sait pas.
Le test est rapide : reprenez la demande en appliquant la méthode complète décrite dans notre article sur la façon d'écrire un bon prompt, avec deux ou trois exemples représentatifs placés dans la consigne. Si le taux de réussite passe de 70 à 92 pour cent, vous venez d'économiser plusieurs semaines. Si vous plafonnez encore, alors la question du fine-tuning devient légitime.
Cette étape est d'autant plus rentable qu'elle produit un sous-produit indispensable : le jeu de cas de test qui servira, si vous entraînez finalement un modèle, à mesurer si l'entraînement a servi à quelque chose.
Ce que coûte réellement un fine-tuning
Le calcul de puissance est la partie la moins chère, et c'est contre-intuitif. Avec les méthodes d'adaptation légère, l'entraînement d'un modèle de taille moyenne sur quelques milliers d'exemples se compte en dizaines à centaines d'euros de machine.
Le coût réel se situe ailleurs, en trois postes :
- La constitution du jeu d'exemples. Il en faut des centaines au minimum, souvent quelques milliers, tous cohérents entre eux. Les produire ou les vérifier représente des jours-hommes, parfois des semaines. Un jeu de données contradictoire donne un modèle pire que celui de départ.
- L'évaluation. Sans jeu de test séparé, vous ne saurez jamais si le modèle entraîné est meilleur. C'est la partie que les projets sautent, et c'est pourquoi tant d'entre eux ne savent pas dire ce que leur fine-tuning a apporté.
- Le cycle de vie. Un modèle entraîné se réentraîne quand la tâche évolue, se réévalue à chaque changement de modèle de base, et se documente pour rester reproductible. C'est un actif à maintenir, pas un livrable.
L'arbre de décision en cinq questions
- L'information nécessaire change-t-elle plus d'une fois par trimestre ? Si oui, c'est du RAG. Le fine-tuning est éliminé, quelle que soit la suite.
- L'utilisateur doit-il pouvoir vérifier la source ? Si oui, c'est du RAG.
- Tous les utilisateurs ont-ils accès aux mêmes documents ? Si non, c'est du RAG, seul capable de filtrer.
- Le problème est-il un format ou un ton, reproduit des centaines de fois à l'identique ? Si oui, et seulement si vous disposez déjà des exemples, le fine-tuning se justifie.
- Avez-vous mesuré le résultat après une consigne correctement rédigée ? Si non, commencez par là avant tout le reste.
Dernière remarque, souvent utile en réunion : les deux approches ne s'excluent pas. La configuration la plus efficace sur les tâches matures combine un modèle légèrement spécialisé pour le format et la nomenclature, alimenté par un RAG pour la connaissance à jour. Chacun traite ce qu'il sait traiter. Mais on n'arrive à cette combinaison qu'après avoir fait fonctionner le RAG seul, et mesuré ce qui manquait encore.
Ce qu'il faut retenir
Trancher entre fine tuning ou RAG revient à distinguer ce que le modèle doit savoir de la manière dont il doit se comporter. La connaissance qui bouge relève du RAG, presque toujours. Le comportement qu'on veut figer relève du fine-tuning, à condition d'avoir les exemples et de savoir mesurer. Et dans un nombre de cas plus élevé qu'on ne l'admet, la bonne réponse consiste à réécrire la consigne et à en rester là. Commencez par mesurer : sans jeu de test, le débat restera une affaire d'opinions, et l'entraînement une dépense dont personne ne saura dire si elle a servi.
Laisser un commentaire