RAG ou fine-tuning : que choisir pour votre projet IA ?

Utilisez le RAG (génération augmentée par récupération) quand le modèle doit connaître des faits, surtout des faits qui changent ou propres à votre entreprise : procédures, données produits, documentation. Utilisez le fine-tuning quand le modèle doit se comporter autrement : suivre un style, un format ou un schéma de tâche étroit de façon plus constante que ne le permettent les prompts. Le RAG change ce que voit le modèle ; le fine-tuning change sa façon de répondre. Le bon ordre, le plus souvent : prompting, puis RAG, et fine-tuning seulement si les tests révèlent un écart que les deux premiers ne comblent pas.

Comment fonctionne le RAG

Le RAG ajoute une étape de recherche avant la réponse du modèle :

1. Préparer les documents. Le contenu est découpé en passages (chunks) et indexé, souvent via des embeddings, représentations numériques du sens permettant une recherche par similarité.
2. Récupérer. Pour chaque question, le système cherche les passages les plus pertinents, souvent en combinant recherche sémantique et par mots-clés.
3. Enrichir. Les passages récupérés sont insérés dans le prompt avec les instructions.
4. Générer. Le modèle rédige une réponse fondée sur ces passages, idéalement en les citant.

Le modèle ne change pas : mettez à jour et réindexez un document, la réponse suivante en tient compte.

Comment fonctionne le fine-tuning

Le fine-tuning poursuit l'entraînement d'un modèle existant sur vos propres exemples, généralement des paires entrée / sortie souhaitée :

1. Rassembler des exemples. De nombreuses paires entrée-sortie de qualité qui montrent le comportement voulu.
2. Entraîner. Le fournisseur ou votre propre infrastructure ajuste le modèle sur ces exemples.
3. Évaluer. Comparez le modèle affiné au modèle de base avec prompts sur un jeu de test mis de côté.
4. Déployer. Utilisez le modèle affiné pour votre tâche.

Le modèle en tire des schémas (format, ton, frontières de classification, formulations métier), pas une base de faits fiable. Enseigner des faits par fine-tuning est inefficace, difficile à mettre à jour et ne permet pas de citer des sources.

Comparaison point par point

Critère	RAG	Fine-tuning
Objectif principal	Fournir des connaissances au moment de la requête	Façonner le comportement et le style
Faits à jour	Oui, il suffit de mettre à jour les documents	Non, réentraînement nécessaire
Cite des sources	Oui, peut citer les passages récupérés	Non
Données nécessaires	Vos documents	De nombreux exemples entrée-sortie soignés
Effort de mise en place	Chaîne d'indexation, réglage de la récupération	Préparation des données, entraînement, évaluation
Coût récurrent	Plus de tokens d'entrée par requête (contexte récupéré), plus l'infrastructure de recherche	Prompts parfois plus courts ; tarifs des modèles affinés parfois différents
Maintenance	Garder des documents propres et un index à jour	Réentraîner quand les besoins ou les modèles de base changent
Réduit les hallucinations	Oui, quand la récupération trouve les bons passages	Pas de façon fiable pour les faits
Contrôle d'accès	Filtrage possible des documents par utilisateur	Connaissances intégrées pour tous

Quand le RAG est le bon choix

• Assistants internes : répondre aux équipes à partir de manuels, procédures et règles.
• Service client : réponses fondées sur le centre d'aide, les données produits et les informations de commande.
• Questions sur des documents : contrats, manuels techniques, fonds documentaires.
• Tout ce qui comporte des faits changeants : prix, stocks, réglementation, gammes de produits.
• Quand la traçabilité est nécessaire : citer le passage source aide relecteurs et utilisateurs à vérifier, une technique clé pour réduire les hallucinations de l'IA.
• Quand l'accès varie selon l'utilisateur : la récupération peut respecter les droits de chacun.

Quand le fine-tuning est le bon choix

• Format ou style constant à fort volume, quand de longs prompts avec exemples seraient trop coûteux ou pas assez réguliers.
• Tâches étroites de classification ou d'extraction avec de nombreux exemples étiquetés.
• Formulations métier que le modèle de base gère mal même avec de bons prompts.
• Utiliser un modèle plus petit et moins cher. Un petit modèle affiné peut parfois égaler un grand sur une tâche étroite et réduire le coût par requête ; voir notre article pour réduire les coûts d'API LLM.

Avant le fine-tuning, poussez le prompting : instructions plus claires, prompt système bien structuré et quelques bons exemples (few-shot prompting). C'est moins cher à modifier et souvent suffisant.

De quoi dépend la qualité d'un RAG

Le RAG n'est pas un interrupteur ; la qualité dépend de plusieurs composants :

Composant	Ce qui peut mal tourner	Ce qui aide
Documents sources	Contenus obsolètes, en double ou contradictoires	Nettoyer et attribuer des responsables avant l'indexation
Découpage	Passages coupés au milieu d'une idée, perte de contexte	Découper selon les titres et sections ; inclure les titres
Récupération	Passage pertinent introuvable ou passages hors sujet renvoyés	Combiner recherche sémantique et par mots-clés, reclasser les résultats, régler le nombre de passages
Prompt	Le modèle ignore les sources ou ajoute ses propres connaissances	Règle explicite : répondre uniquement à partir des sources et signaler l'information manquante
Évaluation	Impossible de savoir si les réponses sont justes	Jeu de questions aux réponses connues, y compris sans réponse possible

Beaucoup de problèmes de RAG sont en fait des problèmes de documents : si la base se contredit, l'IA aussi.

Ce qu'exige le fine-tuning

• Assez de bons exemples. La qualité compte plus que la quantité, mais une poignée ne suffit pas ; les fournisseurs documentent des minimums et des recommandations.
• Des étiquettes cohérentes. Si les personnes divergent sur la bonne sortie, le modèle apprend l'incohérence.
• Un jeu de test mis à l'écart de l'entraînement pour mesurer honnêtement le progrès.
• Une référence : le meilleur résultat par prompt seul, pour juger l'apport du fine-tuning.
• Un plan de maintenance. Quand le fournisseur publie un nouveau modèle de base ou que vos besoins changent, il faudra peut-être affiner à nouveau.

Les questions de coût

Les coûts diffèrent surtout par leur structure :

• Le RAG ajoute des passages à chaque requête, ce qui augmente les tokens d'entrée, et nécessite une infrastructure de recherche. Récupérer moins de passages, mais meilleurs, contient les coûts. Le calculateur de coût d'API LLM montre l'effet de la longueur du contexte sur votre facture.
• Le fine-tuning a des coûts initiaux de préparation des données et d'entraînement, et les modèles affinés peuvent être tarifés différemment des modèles de base. Il peut réduire le coût par requête s'il permet des prompts plus courts ou des modèles plus petits.

Vérifiez les prix actuels auprès de votre fournisseur : les conditions varient et évoluent.

Un guide de décision

Posez ces questions dans l'ordre :

1. Un prompt bien rédigé avec le bon contexte fonctionne-t-il déjà ? Si oui, arrêtez-vous là.
2. Le modèle a-t-il besoin de faits qu'il ne connaît pas, ou de faits qui changent ? Utilisez le RAG.
3. Les réponses doivent-elles citer des sources ou respecter les droits des utilisateurs ? Utilisez le RAG.
4. Le problème restant concerne-t-il le style, le format ou la constance ? Essayez d'abord des exemples few-shot.
5. Les exemples dans le prompt restent-ils insuffisants, avec de nombreux bons exemples et un fort volume ? Envisagez le fine-tuning.
6. Avez-vous besoin à la fois de faits à jour et d'un comportement très spécifique ? Combinez : le RAG pour les connaissances, un modèle affiné pour le comportement.

Les approches hybrides

• RAG avec un modèle affiné : le modèle est affiné pour suivre votre format et votre ton ; les faits viennent de la récupération.
• Composants de récupération affinés : certaines équipes améliorent la recherche en adaptant à leur domaine les modèles d'embedding ou de reclassement.
• Routage : les questions simples vont à un petit modèle, les complexes à un modèle plus grand avec davantage de contexte récupéré.

Elles ajoutent de la complexité : réservez-les aux cas où plus simple ne suffit pas, pas comme architecture de départ.

Les erreurs fréquentes

• Affiner pour enseigner des faits. C'est peu fiable, difficile à mettre à jour et sans sources citables.
• Indexer des documents désordonnés. Le RAG amplifie les incohérences.
• Récupérer trop. Plus de passages, c'est plus de coût et de bruit ; un contexte ciblé donne souvent de meilleures réponses.
• Sauter l'évaluation. Sans jeu de test, impossible de comparer les approches.
• Choisir une architecture avant de définir la tâche. Partez du problème, des utilisateurs et de ce qu'est une bonne réponse.

En résumé

Le RAG donne au modèle accès à vos connaissances ; le fine-tuning change ses habitudes. Commencez par le prompting, ajoutez le RAG quand le modèle a besoin de vos faits, et n'envisagez le fine-tuning que pour un comportement que les exemples du prompt ne produisent pas de façon fiable. Testez votre choix sur de vraies questions et gardez la relecture décrite dans notre guide pour intégrer l'IA dans une PME.