Fine-tuning ou RAG : comment choisir la bonne approche pour votre LLM

La confusion entre fine-tuningfine-tuningFine-tuning adapts a pre-trained model to a specific task or domain by continuing training on a smaller, targeted dataset, improving accuracy and style for that use case.Voir la définition complète → et RAG (Retrieval-Augmented Generation) est l'une des plus coûteuses que l'on observe dans les projets IA en entreprise. Des équipes passent des semaines à préparer des données d'entraînement, engagent des budgets significatifs, puis découvrent que leur cas d'usage aurait simplement nécessité un pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → de récupération documentaire. L'inverse arrive aussi : on construit un système RAG complexe pour un besoin qui aurait été mieux servi par un modèle spécialisé. Le choix entre les deux n'est pas une question de sophistication technique ; c'est une question de diagnostic précis du problème à résoudre.

Pourquoi ce choix engage autant de ressources

Pour un professionnel qui supervise ou commande des projets IA, la distinction entre les deux approches a des conséquences directes sur le budget, le calendrier et la maintenabilité du système.

Le fine-tuning implique de ré-entraîner un modèle existant sur un corpus de données propre à l'entreprise. Cela modifie les poids du modèle de façon permanente. Les coûts varient considérablement selon le modèle de base choisi : affiner un modèle de taille moyenne via les APIs d'OpenAI peut coûter quelques centaines de dollars pour un premier run, mais un fine-tuning sérieux avec itérations de validation, préparation de données et tests peut rapidement dépasser 20 000 à 50 000 euros une fois l'ingénierie intégrée. Surtout, chaque mise à jour des données métier impose potentiellement un nouveau cycle d'entraînement.

Le RAG, de son côté, conserve le modèle de base intact. Il ajoute une étape de recherche : avant de générer une réponse, le système interroge une base documentaire (souvent via une base vectorielle comme Pinecone, Weaviate ou pgvector), extrait les passages pertinents, et les injecte dans le prompt. L'investissement se concentre sur l'ingestion et l'indexation des documents, pas sur l'entraînement. Mettre à jour la base de connaissances revient à mettre à jour une base de données, pas à relancer un entraînement.

Comment fonctionnent les deux mécanismes, concrètement

Imaginons une banque qui veut automatiser les réponses à ses conseillers sur les produits réglementaires. Elle dispose de deux types de besoins distincts.

Premier besoin : les conseillers ont besoin d'accéder rapidement aux circulaires de l'AMF, aux fiches produits mises à jour trimestriellement et aux notes internes de conformité. Ces documents changent souvent et représentent plusieurs milliers de pages. Ici, le RAG s'impose. Quand un conseiller pose une question sur les conditions d'éligibilité à un produit structuré, le système récupère les sections pertinentes des documents les plus récents, les insère dans le contexte du modèle, et génère une réponse ancrée dans ces sources. Si la réglementation change en mars, il suffit de réindexer les nouveaux documents. Aucun re-entraînement.

Second besoin : les mêmes conseillers rédigent des synthèses clients selon un style maison très codifié, avec une terminologie interne et un format narratif spécifique que le modèle généraliste ne produira jamais spontanément. Là, le fine-tuning devient pertinent. On entraîne le modèle sur plusieurs centaines d'exemples de synthèses validées, et il internalise le registre, la structure, les formulations attendues. Le style devient une capacité du modèle, pas une instruction à répéter dans chaque prompt.

Cette distinction révèle la logique profonde des deux approches. Le RAG répond à la question : "De quoi le modèle a-t-il besoin de savoir pour répondre ?" Le fine-tuning répond à : "Comment le modèle doit-il se comporter et s'exprimer ?"

Les honnêtes compromis de chaque approche

Le RAG a des limites réelles que ses promoteurs commerciaux minorent souvent. La qualité des réponses dépend entièrement de la qualité de la récupération. Si les documents sont mal structurés, mal indexés, ou si la requête utilisateur est ambiguë, le système remonte des passages non pertinents et le modèle hallucine ou répond à côté. La latence est aussi un facteur : une chaîne RAG bien construite ajoute 300 à 800 ms par rapport à un appel direct au modèle, ce qui peut devenir problématique dans des interfaces conversationnelles à fort volume. Enfin, injecter de longs contextes documentaires dans chaque prompt a un coût en tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète → qui s'accumule à grande échelle.

Le fine-tuning, lui, est mal adapté à tout ce qui exige de la fraîcheur. Un modèle fine-tuné sur des données de janvier n'a aucune connaissance de ce qui s'est passé en avril. Il ne peut pas non plus facilement citer ses sources : la connaissance est intégrée dans les poids, invisible. Pour des usages réglementaires ou auditables, c'est un défaut sérieux. Par ailleurs, les cas où le fine-tuning déçoit sont souvent liés à un volume de données insuffisant : en dessous de quelques centaines d'exemples bien construits, les gains sont marginaux.

Il existe une troisième option, moins discutée : combiner les deux. Anthropic et OpenAI ont tous deux documenté des cas d'usage où un modèle fine-tuné pour un comportement ou un format spécifique est ensuite alimenté par un pipeline RAG pour l'accès aux connaissances factuelles. C'est une architecture plus complexe, mais elle résout précisément la tension entre style stable et contenu dynamique.

Le critère de décision le plus fiable reste celui-ci : si le problème est un problème d'accès à l'information, pensez RAG. Si c'est un problème de comportement, de ton, de format ou de raisonnement spécialisé, envisagez le fine-tuning. Dans la plupart des projets entreprise que l'on observe en 2026, le RAG répond à 70 à 80 % des besoins à moindre coût et avec bien plus de flexibilité. Le fine-tuning reste puissant, mais uniquement quand le diagnostic l'exige vraiment.