RAG ou fine-tuning : ce dont votre projet LLM a vraiment besoin

« Est-ce qu'on doit fine-tuner un modèle sur nos données ? » C'est l'une des premières questions qu'on me pose sur un projet d'IA. Le plus souvent, la réponse honnête est « probablement pas tout de suite ». La plupart des équipes qui la posent ont en réalité besoin de recherche documentaire, d'un meilleur prompt, ou des deux. Le fine-tuning a sa place, mais il ne résout pas le problème que l'on croit.

Voici comment je choisis entre RAG et fine-tuning, ce que chacun coûte à construire et à maintenir, et les cas où on n'a besoin d'aucun des deux.

La version courte

Le RAG (génération augmentée par récupération) donne au modèle la bonne information au moment où il répond. Le système cherche dans vos documents, place les passages utiles dans le prompt, et le modèle répond à partir d'eux.
Le fine-tuning modifie le comportement du modèle. On le réentraîne sur des exemples pour qu'il apprenne un format, un style, un vocabulaire ou une tâche précise.

Une règle simple : le RAG apporte des connaissances, le fine-tuning apporte un savoir-faire. Si le problème est « le modèle ne connaît pas nos prix, nos procédures ou nos produits », c'est une question de connaissances. Si c'est « le modèle en sait assez, mais ne répond pas comme il faut », c'est une question de savoir-faire.

Commencer par aucun des deux : corriger le prompt

Avant de choisir, vérifiez si un prompt clair ne règle pas déjà le problème. Un nombre étonnant de projets « il nous faut du fine-tuning » se résolvent avec :

des instructions précises, y compris quoi faire quand l'information manque,
quelques bons exemples d'entrée et de sortie attendue dans le prompt,
un format de sortie défini, idéalement structuré (du JSON avec un schéma) quand un autre système le lit,
un modèle adapté à la tâche.

Cela prend des jours, pas des semaines, et vous donne une référence. Sans référence, impossible de savoir si le RAG ou le fine-tuning a servi à quelque chose.

Quand le RAG est le bon choix

Le RAG convient quand les réponses dépendent d'informations :

Propres à votre entreprise : catalogue, contrats, procédures internes, anciens tickets.
Qui changent : prix, stock, conditions. On met à jour les documents et la réponse suivante en tient compte, sans réentraînement.
Qu'il faut pouvoir citer : le RAG peut montrer de quel document vient une réponse, pour qu'une personne la vérifie.
Soumises à des droits d'accès : on filtre ce que chaque utilisateur peut récupérer. Un modèle fine-tuné ne peut pas « oublier » un document pour un seul utilisateur.

Le RAG réduit aussi le risque que le modèle invente des faits, puisqu'il répond à partir de textes fournis. Il ne le supprime pas : la recherche doit trouver le bon passage, et le modèle doit s'y tenir. La plupart des échecs de RAG que je vois sont des échecs de recherche, pas de modèle. J'ai écrit un guide à part sur construire un pipeline RAG qui tient en production.

Quand faire du fine-tuning de LLM

Le fine-tuning se justifie quand le modèle doit faire quelque chose de façon constante que le prompt n'obtient pas de manière fiable :

Un format ou un style strict sur des milliers d'appels : un style rédactionnel maison, une mise en page de rapport, une classification avec beaucoup de catégories.
Une tâche étroite et répétitive où un petit modèle affiné peut égaler un grand modèle généraliste. C'est important pour le coût et pour faire tourner le modèle sur votre propre matériel.
Un langage métier que le modèle de base maîtrise mal : jargon spécialisé, ou une langue ou un dialecte peu présent dans ses données d'entraînement, comme la darija.
Des prompts plus courts : un comportement qui demanderait de longues instructions et beaucoup d'exemples à chaque appel peut être intégré au modèle.

Aujourd'hui, le fine-tuning veut généralement dire fine-tuning efficace en paramètres, comme LoRA. Au lieu de modifier tous les poids du modèle, on entraîne un petit ensemble de poids supplémentaires au-dessus d'un modèle de base figé. Cela demande beaucoup moins de mémoire GPU, et le résultat est un petit fichier d'adaptateur qu'on peut activer ou retirer. Affiner un modèle ouvert sur du matériel modeste devient réaliste.

Ce que le fine-tuning fait mal : apprendre des faits qui changent. Si vous intégrez vos prix dans un modèle, il faut le réentraîner à chaque changement, et vous ne voyez pas facilement d'où vient une réponse.

Ce que chacun coûte

Le RAG :

Construire la chaîne d'ingestion et de recherche : lecture des documents, découpage, embeddings, index de recherche.
Un travail continu pour garder l'index à jour et les droits d'accès corrects.
Des prompts plus longs à chaque appel, puisqu'on y ajoute les passages récupérés.

Le fine-tuning :

Collecter et nettoyer les données d'entraînement. C'est le vrai coût. Il faut en général des centaines à des milliers de bons exemples, qui reflètent vraiment ce que vous voulez, erreurs comprises.
Les entraînements et l'évaluation, à refaire quand le modèle de base ou vos besoins changent.
L'hébergement du modèle affiné, ou le tarif d'un fournisseur pour les modèles personnalisés.

Dans les deux cas, il vous faut un jeu d'évaluation : quelques centaines d'exemples réels avec des réponses de référence, pour mesurer si un changement a aidé. Sans lui, vous devinez.

Quand utiliser les deux

Certains systèmes ont besoin des deux. Un schéma courant : on affine un modèle pour qu'il respecte toujours votre format et votre ton, puis on utilise le RAG pour lui fournir les faits à jour. Par exemple, un assistant de support affiné sur la façon dont vos meilleurs conseillers rédigent, avec des réponses appuyées sur vos conditions actuelles. Le fine-tuning gère comment il répond, la recherche gère ce qu'il dit.

Je ne le recommande qu'une fois le RAG seul mesuré et jugé insuffisant. Ce sont deux briques à maintenir au lieu d'une.

Une checklist de décision

Un bon prompt avec quelques exemples suffit-il ? Alors arrêtez-vous là.
Le problème vient-il d'informations manquantes ou changeantes ? RAG.
Faut-il des citations ou des droits d'accès par utilisateur ? RAG.
Le problème est-il un format, un style ou une tâche étroite à gros volume ? Envisagez le fine-tuning.
Avez-vous des centaines d'exemples de qualité ? Sinon, vous n'êtes pas prêt pour le fine-tuning.
Voulez-vous un petit modèle sur vos serveurs pour le coût ou la confidentialité ? Affiner un petit modèle ouvert est souvent le chemin.

La question des données privées

Les deux approches peuvent garder les données sensibles en interne. Le RAG peut tourner avec un modèle et un index locaux, sans que les documents quittent votre réseau. Affiner un modèle ouvert sur votre matériel évite aussi d'envoyer vos données d'entraînement à un tiers. Si c'est votre question, je compare les options dans IA privée et LLM on-premise.

Une mise en garde : un modèle affiné peut restituer des morceaux de ses données d'entraînement. N'affinez pas sur des données personnelles que vous ne voudriez pas voir répétées au mauvais utilisateur. Pour ce type de données, un RAG avec un vrai filtrage des accès est généralement plus sûr.

Travailler ensemble

Je suis Driss Briksine, ingénieur logiciel et ML basé au Maroc. Je construis des systèmes d'IA de bout en bout, de la recherche documentaire et du travail sur les modèles jusqu'au logiciel en production, et la plupart de mes systèmes tournent sur des modèles locaux. Vous pouvez voir mes études de cas.

Si vous hésitez entre RAG et fine-tuning, décrivez-moi la tâche en quelques lignes. Je vous dirai par quoi je commencerais, et comment mesurer si ça a marché.