RAG ou fine-tuning : comment choisir pour sa stack IA open source
Sur une stack IA auto-hébergée, deux leviers permettent d’adapter un LLM à son contexte métier : injecter de la connaissance au moment de la requête (RAG, Retrieval-Augmented Generation) ou entraîner le modèle sur ses propres données (fine-tuning). Les deux approches sont souvent présentées comme concurrentes, alors qu’elles répondent à des problèmes différents. Cet article propose une matrice de décision concrète, pensée pour des équipes qui construisent leur propre infrastructure, avec des modèles comme Mistral, Llama ou Qwen, et des briques comme pgvector, Ollama ou Unsloth.
Ce que les deux approches font vraiment
Le RAG garde le modèle tel quel et enrichit sa réponse en récupérant dynamiquement, à chaque requête, les passages pertinents d’une base documentaire. Le modèle voit ces passages dans son contexte et produit une réponse fondée sur ces sources. L’infrastructure typique associe une base vectorielle (pgvector, Qdrant), un modèle d’embeddings et un LLM d’inférence.
Le fine-tuning, à l’inverse, modifie les poids du modèle. On lui apprend un style, un vocabulaire métier, un format de sortie ou une tâche spécifique en lui présentant des milliers d’exemples. Avec des techniques comme LoRA ou QLoRA (portées par Unsloth ou Axolotl), on peut ajuster un modèle de 7 à 13 milliards de paramètres sur un seul GPU grand public.
Les critères qui tranchent
La question n’est pas « lequel est meilleur » mais « quel problème est-ce que je cherche à résoudre ». Voici les critères qui, en pratique, orientent la décision :
- La connaissance à injecter change-t-elle souvent ? Si oui (jurisprudence, documentation produit, actualité), le RAG est incontournable : on met à jour la base, pas le modèle.
- A-t-on besoin de sources citables ? Le RAG fournit nativement les passages utilisés. Un modèle fine-tuné, non : il « sait » mais ne peut pas prouver.
- Le problème est-il un défaut de format, de ton ou de comportement ? Là, le fine-tuning est plus efficace. Apprendre à un modèle à produire systématiquement du JSON valide, à répondre dans un ton institutionnel, ou à suivre un processus métier spécifique passe mal par le prompt.
- Les données sont-elles volumineuses et statiques ? Un corpus de dix mille documents techniques stables peut être fine-tuné avec bénéfice. Le même corpus mis à jour chaque semaine ne le sera pas.
- Quelle est la latence acceptable ? Un RAG ajoute un aller-retour de recherche vectorielle et une fenêtre de contexte plus longue. Un modèle fine-tuné répond en une seule passe, souvent plus vite.
- Quelle est la taille d’équipe disponible ? Le RAG est plus facile à maintenir (remplacer des documents, réindexer). Le fine-tuning demande des compétences ML, une pipeline d’entraînement, une évaluation systématique.
Une matrice de décision simple
| Besoin | Approche recommandée |
|---|---|
| Répondre à partir d’une documentation qui évolue | RAG |
| Produire des sorties au format imposé (JSON, XML, gabarits) | Fine-tuning (ou grammaire contrainte type Outlines) |
| Imiter un style rédactionnel métier | Fine-tuning |
| Répondre avec sources citables | RAG |
| Faire baisser le coût d’inférence sur un cas très répétitif | Fine-tuning d’un petit modèle |
| Maîtriser un jargon métier rare | Fine-tuning + RAG (les deux) |
| Prototyper rapidement un assistant documentaire | RAG |
Le piège classique : fine-tuner pour injecter de la connaissance
C’est l’erreur la plus fréquente. Une équipe veut qu’un modèle « connaisse » sa documentation interne, lance un fine-tuning, et constate que le modèle hallucine autant qu’avant. Le fine-tuning n’est pas un mécanisme fiable pour stocker des faits précis : il apprend des régularités statistiques, pas un index. Résultat : le modèle confond des références, invente des chiffres, mélange des procédures. Pour transmettre de la connaissance, le RAG reste la bonne voie. Le fine-tuning sert à conditionner le comportement, pas à remplir la mémoire.
La combinaison gagnante
Dans les architectures matures, on empile souvent les deux. Un modèle de base (Llama 3 ou Mistral, par exemple) est fine-tuné légèrement pour adopter un style, un format de réponse et une politique de refus adaptée. Puis ce modèle est servi derrière un RAG qui lui injecte la connaissance spécifique à chaque requête. On obtient ainsi un assistant qui parle le bon langage et qui s’appuie sur des sources à jour. C’est cette combinaison qui permet d’atteindre un niveau de qualité comparable aux grandes API propriétaires, sur une infrastructure auto-hébergée.
Par où commencer concrètement
Dans 80 % des cas d’usage d’une organisation (assistance documentaire, questions-réponses internes, analyse de contrats, synthèse de dossiers), un RAG bien construit suffit et rend des résultats dès la première semaine. Le fine-tuning ne devient intéressant qu’une fois le RAG en place, quand on a identifié précisément les défauts résiduels : un ton à ajuster, un format à fiabiliser, un vocabulaire à faire acquérir. Ouvrir un chantier de fine-tuning avant d’avoir un RAG fonctionnel, c’est très souvent résoudre le mauvais problème.
Côté outils open source, la combinaison typique aujourd’hui reste : Ollama ou vLLM pour servir le modèle, pgvector ou Qdrant pour la base vectorielle, un modèle d’embeddings type BGE ou Nomic, LangGraph ou Dify pour orchestrer, et Unsloth le jour où le fine-tuning devient pertinent. Commencer simple, mesurer, puis décider de monter en complexité : c’est la feuille de route qui évite les impasses.
