Fine-tuning ou RAG : comment spécialiser une IA sur vos données

Un grand modèle de langage sait converser sur presque tout, mais il ignore l'essentiel : vos procédures internes, votre catalogue produit, le compte rendu de votre dernière réunion, la jurisprudence propre à votre métier. Entre le modèle généraliste, brillant mais amnésique de votre contexte, et l'assistant réellement utile qui connaît vos données, il existe un fossé. Deux grandes routes permettent de le franchir : le fine-tuning, qui rééduque le modèle sur vos exemples, et le RAG, qui lui donne accès à vos documents au moment de répondre. On les oppose souvent comme des rivales. C'est une erreur de perspective. Ce sont deux outils complémentaires, chacun taillé pour un besoin précis — et le vrai savoir-faire consiste à savoir lequel dégainer, et quand les combiner.

Cet article propose un comparatif méthodique, pensé pour un décideur technique ou un porteur de projet qui doit trancher. Nous allons définir précisément chaque approche, décortiquer leur fonctionnement, confronter leurs coûts, leur fraîcheur, leur maintenance et leur fiabilité, puis dérouler une grille de décision applicable à vos propres cas d'usage. Le tout s'appuie sur des travaux de recherche publiés et vérifiables, cités en fin d'article. L'objectif n'est pas de désigner un vainqueur universel — il n'existe pas — mais de vous donner les critères pour choisir en connaissance de cause.

Un mot de cadrage, d'abord. « Spécialiser une IA sur vos données » recouvre en réalité deux besoins très différents que l'on confond volontiers. Le premier est un besoin de connaissance : je veux que le modèle réponde à partir d'informations qu'il n'a jamais vues. Le second est un besoin de comportement : je veux que le modèle adopte un ton, un format, une manière de raisonner propre à mon domaine. Comme nous le verrons, RAG excelle sur le premier, fine-tuning sur le second. Garder cette distinction en tête suffit déjà à éclairer la moitié des décisions.

Deux approches, deux philosophies

Avant de comparer, il faut définir. Les deux termes circulent partout, souvent employés de façon interchangeable, alors qu'ils désignent des opérations profondément distinctes. L'une modifie le modèle. L'autre modifie ce qu'on lui donne à lire. Cette différence de nature commande tout le reste.

Le fine-tuning : rééduquer le modèle

Le fine-tuning, ou ajustement fin, consiste à reprendre l'entraînement d'un modèle pré-entraîné sur un jeu de données ciblé, spécifique à une tâche ou à un domaine. On ne repart pas de zéro — ce serait ruineux — mais on prolonge l'apprentissage du modèle existant avec vos exemples. Concrètement, on lui présente des centaines ou des milliers de paires question-réponse, ou d'exemples de la sortie attendue, et on ajuste ses paramètres internes pour qu'il s'aligne sur ce comportement. La connaissance ou le savoir-faire s'inscrivent alors dans les poids du modèle : ils deviennent partie intégrante de lui.

L'analogie la plus juste est celle de la formation professionnelle. Un modèle généraliste est comme un diplômé polyvalent, cultivé mais sans expérience de votre secteur. Le fine-tuning est le stage d'intégration au terme duquel il maîtrise votre vocabulaire, vos réflexes, votre façon de rédiger. Une fois formé, il n'a plus besoin qu'on lui rappelle les règles à chaque question : elles font désormais partie de son intuition. En contrepartie, si les règles changent, il faut le reformer.

Le RAG : donner accès à une bibliothèque

Le RAG — Retrieval-Augmented Generation, ou génération augmentée par récupération — procède tout autrement. Le modèle reste inchangé. On lui adjoint un système de recherche qui, à chaque question posée, va chercher dans une base documentaire les passages les plus pertinents, puis les injecte dans le prompt aux côtés de la question. Le modèle génère alors sa réponse en s'appuyant à la fois sur sa culture générale et sur ces extraits fournis à la volée. La connaissance reste externe au modèle, stockée dans une base que l'on peut modifier à tout moment.

Pour reprendre l'analogie, le RAG ne forme pas l'employé : il lui offre un accès permanent à la documentation de l'entreprise et l'autorise à la consulter avant chaque réponse. L'employé n'a pas mémorisé le manuel, mais il sait où trouver la bonne page en quelques secondes. Si le manuel est mis à jour, il lira simplement la nouvelle version la prochaine fois — sans nouvelle formation.

Le fine-tuning change le modèle ; le RAG change ce que le modèle lit avant de répondre. Toute la décision découle de cette distinction fondamentale.

Comment fonctionne le RAG, brique par brique

Pour choisir en connaissance de cause, il faut comprendre la mécanique interne de chaque approche. Commençons par le RAG, car son architecture éclaire directement ses forces et ses limites. Un système RAG se déroule en deux temps : une phase d'indexation, réalisée en amont, et une phase de récupération, exécutée à chaque requête.

La phase d'indexation, en coulisses

Avant toute question, il faut préparer la bibliothèque. Cette phase, hors ligne, transforme vos documents bruts en une base interrogeable :

• Le découpage (chunking) : les documents sont segmentés en petits fragments cohérents. La bonne pratique courante consiste à produire des morceaux de quelques centaines de mots en respectant les frontières de phrases ou de paragraphes, afin que chaque fragment reste porteur de sens.
• Le calcul des embeddings : chaque fragment est converti en un vecteur numérique — une liste de nombres — par un modèle d'embedding. Ce vecteur capture le sens du texte : deux passages parlant de la même chose auront des vecteurs proches, même s'ils n'emploient pas les mêmes mots.
• L'indexation : ces vecteurs sont stockés dans une base de données vectorielle, optimisée pour retrouver rapidement les vecteurs les plus proches d'un vecteur donné.

Une règle d'or régit cette étape et mérite d'être martelée : le même modèle d'embedding doit servir à l'indexation des documents et à l'encodage des questions. Si vous indexez avec un modèle et interrogez avec un autre, les vecteurs vivent dans des espaces mathématiques différents et la recherche de similarité perd tout son sens. C'est l'une des erreurs de débutant les plus fréquentes, et l'une des plus silencieuses : le système fonctionne, mais retourne des passages non pertinents.

La phase de récupération, à chaque question

Quand un utilisateur pose une question, le système enchaîne plusieurs opérations en une fraction de seconde. La question est d'abord convertie en vecteur par le même modèle d'embedding. La base vectorielle recherche ensuite les fragments dont les vecteurs sont les plus proches — c'est la recherche sémantique. Les meilleurs candidats, typiquement cinq à dix fragments, sont sélectionnés. Ils sont alors assemblés avec la question dans un prompt enrichi, transmis au modèle de langage, qui rédige enfin une réponse ancrée dans ces extraits.

Ce mécanisme explique la principale vertu du RAG : la traçabilité. Puisque la réponse s'appuie sur des passages identifiables, on peut afficher les sources, permettre à l'utilisateur de vérifier, et réduire ainsi le risque que le modèle invente. C'est un atout décisif dans les domaines où la justification compte autant que la réponse : santé, droit, finance, support technique.

Comment fonctionne le fine-tuning, du complet au léger

Le fine-tuning a longtemps été perçu comme réservé aux laboratoires disposant de fermes de GPU. Cette image est aujourd'hui dépassée, grâce à une famille de techniques qui en ont radicalement abaissé le coût. Il faut distinguer deux grandes familles.

Le fine-tuning complet

Dans sa forme classique, le fine-tuning ajuste l'ensemble des paramètres du modèle. Pour un modèle de plusieurs milliards de paramètres, cela suppose de conserver en mémoire les poids, leurs gradients et les états de l'optimiseur — soit un besoin mémoire de plusieurs fois la taille du modèle. C'est cette exigence qui rendait l'opération coûteuse et réservée aux gros acteurs. Le fine-tuning complet reste la référence en qualité quand les moyens suivent, mais il n'est plus la seule voie.

Les méthodes efficientes : PEFT et LoRA

La rupture est venue des méthodes dites d'ajustement à paramètres efficients (PEFT, pour Parameter-Efficient Fine-Tuning). L'idée : geler la quasi-totalité du modèle pré-entraîné et n'entraîner qu'un petit nombre de paramètres additionnels. La plus populaire de ces méthodes est LoRA (Low-Rank Adaptation), proposée par des chercheurs de Microsoft en 2021.

LoRA repose sur une observation élégante : lorsqu'on adapte un grand modèle à une tâche, les modifications apportées à ses poids se révèlent de « faible rang intrinsèque » — autrement dit, elles peuvent être représentées de façon très compacte. Plutôt que de modifier directement les énormes matrices de poids, LoRA les laisse figées et leur adjoint, à chaque couche, deux petites matrices entraînables dont le produit encode l'adaptation. Les chiffres avancés par les auteurs sont éloquents : par rapport à un fine-tuning complet de GPT-3 à 175 milliards de paramètres avec l'optimiseur Adam, LoRA réduit le nombre de paramètres entraînables d'un facteur allant jusqu'à 10 000 et divise par trois le besoin en mémoire GPU, sans perte de qualité mesurable sur les tâches en aval.

Un raffinement supplémentaire, QLoRA, a repoussé encore la frontière en 2023. En combinant LoRA avec une quantification en 4 bits du modèle de base — une compression des poids —, ses auteurs (Dettmers et ses collègues de l'université de Washington) sont parvenus à ajuster finement un modèle de 65 milliards de paramètres sur une seule carte graphique de 48 Go, tout en préservant la qualité d'un fine-tuning en pleine précision. Le modèle Guanaco, entraîné ainsi, a atteint 99,3 % du niveau de ChatGPT sur le banc d'essai Vicuna après seulement 24 heures d'entraînement sur un unique GPU.

Avec LoRA et QLoRA, le fine-tuning n'est plus l'apanage des géants : adapter un grand modèle tient désormais sur une seule carte graphique et un budget d'heures, non de mois.

Cette démocratisation change la donne de notre comparatif. Il y a quelques années, opposer RAG et fine-tuning revenait presque à opposer l'accessible au réservé aux happy few. Ce n'est plus le cas. Les deux approches sont aujourd'hui à la portée d'une équipe modeste, ce qui rend le choix d'autant plus intéressant : il se joue désormais sur les mérites intrinsèques de chaque méthode, non sur une barrière de coût d'entrée.

Ce que dit la recherche : RAG mène sur la connaissance

Passons des principes aux preuves. Plusieurs travaux publiés ont comparé rigoureusement les deux approches, et leurs conclusions convergent de façon éclairante — à condition de bien lire la question posée.

Injecter une connaissance nouvelle : l'avantage au RAG

L'étude la plus citée sur le sujet, « Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs », publiée à la conférence EMNLP 2024 par Ovadia et ses coauteurs, tranche nettement pour un besoin précis : celui d'apprendre au modèle des faits qu'il ne connaît pas. Ses auteurs constatent que le RAG surpasse systématiquement le fine-tuning non supervisé, aussi bien pour des connaissances déjà rencontrées à l'entraînement que pour des connaissances entièrement nouvelles.

La raison de fond est instructive. Injecter un fait par fine-tuning revient à espérer que le modèle mémorise une information précise en modifiant statistiquement ses poids — une opération peu fiable pour un fait isolé, surtout s'il est rare. Une autre étude, menée par Soudani et ses collègues sur les « connaissances peu populaires », renforce ce constat : c'est précisément sur les faits rares, les entités peu représentées dans les données d'entraînement, que le RAG creuse l'écart le plus large avec le fine-tuning. Là où le fine-tuning peine à ancrer une information marginale, le RAG la retrouve dans la base et la sert telle quelle.

La leçon est claire : pour un besoin de connaissance factuelle — répondre à partir de documents, restituer des chiffres exacts, citer une procédure —, le RAG part avec une longueur d'avance. Et ce d'autant plus que ces faits sont spécifiques et rares, c'est-à-dire exactement le cas de figure d'une entreprise qui veut exploiter ses propres données.

Les deux ensemble : un effet cumulatif

La nuance vient d'une seconde étude majeure, signée par une équipe de Microsoft : « RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture », publiée début 2024. Les auteurs y construisent un pipeline complet et le testent sur un cas concret : fournir à un agriculteur des recommandations adaptées à sa localisation, à partir de plusieurs modèles dont Llama 2-13B, GPT-3.5 et GPT-4.

Leurs résultats sont particulièrement éclairants car ils mesurent les deux approches, séparément et combinées. Le fine-tuning apporte un gain de précision de plus de 6 points de pourcentage. Le RAG, appliqué par-dessus, ajoute encore environ 5 points supplémentaires. Autrement dit, les deux effets s'additionnent : loin de se concurrencer, ils se cumulent. Dans une expérience marquante, le modèle ajusté parvient à mobiliser des informations issues de différentes zones géographiques, faisant passer la similarité des réponses de 47 % à 72 %.

Mais l'étude pointe aussi la principale faiblesse du fine-tuning, révélée dès que les agriculteurs réclament des recommandations en temps réel liées à des facteurs imprévisibles — la météo, par exemple. Le modèle ajusté, par nature statique, ne peut intégrer une information nouvelle sans un ré-entraînement. Cette rigidité est le talon d'Achille du fine-tuning, et la force native du RAG.

Le comparatif critère par critère

Rassemblons maintenant les enseignements sous forme de grille. Cinq critères suffisent à couvrir l'essentiel des situations : la fraîcheur de l'information, le coût, la maintenance, la nature de ce qu'on cherche à transmettre, et la fiabilité.

La fraîcheur de l'information

C'est le critère le plus discriminant. Le RAG interroge une base que l'on peut mettre à jour à tout instant : ajouter un document le rend immédiatement disponible, sans toucher au modèle. Le fine-tuning, à l'inverse, fige la connaissance au moment de l'entraînement ; toute mise à jour impose de reconstituer un jeu de données et de relancer l'opération. Pour une information qui change souvent — tarifs, stocks, actualités, réglementation évolutive —, le RAG est nettement préférable. Pour un savoir stable — la grammaire d'un langage métier, un style rédactionnel —, cette rigidité du fine-tuning n'est plus un défaut.

Le coût

Le coût se lit à deux moments. À la mise en place, le fine-tuning demande un effort de constitution d'un jeu de données de qualité et une phase d'entraînement — coûteuse en fine-tuning complet, désormais modeste avec LoRA ou QLoRA. Le RAG demande, lui, de bâtir et d'indexer une base vectorielle. À l'usage, le RAG a un coût récurrent souvent sous-estimé : chaque requête consomme davantage de tokens, puisque les passages récupérés viennent gonfler le prompt. Le fine-tuning, une fois réalisé, n'alourdit pas les requêtes — et avec LoRA, il n'ajoute même aucune latence à l'inférence, car les adaptateurs se fondent dans les poids. Le calcul dépend donc du volume de requêtes : à fort trafic, l'économie de tokens du modèle ajusté peut compenser son coût d'entraînement.

La maintenance

Un système RAG comporte davantage de pièces mobiles : base vectorielle, modèle d'embedding, pipeline d'ingestion, mécanisme de récupération. Chacune peut se dérégler et demande une surveillance. Un modèle ajusté est plus simple à servir — c'est un fichier de poids —, mais sa maintenance se paie autrement : chaque évolution du savoir suppose un nouveau cycle d'entraînement. On échange une complexité d'architecture (RAG) contre une complexité de cycle de vie (fine-tuning).

Connaissance ou comportement ?

C'est la question de fond, celle par laquelle nous avons commencé. Si votre besoin est de connaissance — restituer des faits, répondre à partir de documents —, le RAG domine, la recherche le confirme. Si votre besoin est de comportement — imposer un format de sortie strict, adopter un ton précis, maîtriser un jargon, suivre un raisonnement propre à votre métier —, le fine-tuning est dans son élément : il inscrit ces réflexes dans le modèle lui-même, de façon bien plus robuste qu'une consigne répétée dans chaque prompt.

La fiabilité et la traçabilité

Le RAG offre un avantage précieux : il permet de citer ses sources. Une réponse peut être accompagnée des passages qui la fondent, ce qui autorise la vérification et réduit la tentation, pour le modèle, d'inventer. Le fine-tuning ne procure pas cette traçabilité : la connaissance étant dissoute dans les poids, on ne peut pas remonter à la source d'une affirmation. Dans les domaines réglementés ou sensibles, cette différence pèse lourd.

Critère	RAG	Fine-tuning
Fraîcheur de l'info	Excellente (mise à jour instantanée)	Figée à l'entraînement
Injection de faits rares	Point fort	Peu fiable
Style, ton, format	Limité	Point fort
Coût par requête	Plus élevé (tokens du contexte)	Faible, sans surcoût de latence (LoRA)
Traçabilité des sources	Native	Absente
Complexité	Architecture (plusieurs briques)	Cycle de vie (ré-entraînements)

Une grille de décision applicable

Les principes posés, voici comment trancher pour un cas réel. La démarche tient en quelques questions, à se poser dans l'ordre.

Première question : connaissance ou comportement ?

Si vous voulez surtout que le modèle sache des choses qu'il ignore — le contenu de vos documents, votre base de connaissances, vos données —, orientez-vous vers le RAG. Si vous voulez surtout qu'il se comporte d'une certaine manière — répondre dans un format JSON strict, adopter la voix de votre marque, manier un vocabulaire technique très spécialisé —, orientez-vous vers le fine-tuning. Cette seule question résout une majorité de cas.

Deuxième question : l'information change-t-elle souvent ?

Si votre connaissance est volatile — mise à jour quotidienne ou hebdomadaire —, le RAG s'impose presque mécaniquement : mettre à jour une base est trivial, ré-entraîner un modèle ne l'est pas. Si votre connaissance est stable sur des mois, le fine-tuning redevient envisageable, sa rigidité n'étant plus pénalisante.

Troisième question : avez-vous besoin de citer vos sources ?

Si votre application exige de justifier chaque réponse — conformité, secteur réglementé, exigence de vérifiabilité —, le RAG est le choix naturel, car il apporte la traçabilité de série. Le fine-tuning, opaque par construction, ne peut l'offrir.

Quatrième question : quel est votre profil de requêtes ?

À très fort volume, le surcoût en tokens du RAG à chaque requête peut peser lourd sur la facture ; un modèle ajusté, plus sobre à l'usage, amortit alors son coût d'entraînement. À faible volume, ce calcul s'inverse : le RAG évite tout entraînement, et le prix des tokens supplémentaires reste marginal.

Une réponse fréquente : les deux

La conclusion la plus solide de la littérature est qu'il ne faut pas toujours choisir. L'étude sur l'agriculture l'a chiffré : les gains du fine-tuning et du RAG s'additionnent. En pratique, une architecture hybride mature combine souvent un modèle légèrement ajusté — pour le ton, le format et le raisonnement métier — et une couche RAG — pour la connaissance factuelle à jour et traçable. C'est le meilleur des deux mondes : le comportement inscrit dans le modèle, la connaissance servie de l'extérieur. Cette combinaison n'est pas un compromis mou, mais la réponse la plus complète pour les applications exigeantes.

La question la plus utile n'est pas « RAG ou fine-tuning ? » mais « qu'est-ce que je veux transmettre — un savoir ou un savoir-faire ? ». Souvent, la bonne réponse combine les deux.

Trois cas d'usage pour ancrer la théorie

Rien ne vaut des exemples concrets pour transformer une grille abstraite en réflexe. Prenons trois situations typiques et déroulons le raisonnement de bout en bout, comme on le ferait devant un vrai projet.

Un assistant de support client sur une base documentaire

Une entreprise dispose d'une documentation produit fournie, de guides de dépannage et d'un historique de tickets résolus. Elle veut un assistant capable de répondre aux questions des clients à partir de ce corpus. Déroulons la grille. Le besoin est d'abord de connaissance : répondre à partir de documents précis. L'information change souvent : la documentation évolue à chaque nouvelle version du produit. La traçabilité importe : on veut pouvoir renvoyer le client vers la page exacte du manuel. Le verdict est sans appel : c'est un cas de RAG par excellence. Toute tentative d'injecter cette documentation par fine-tuning se heurterait à sa volatilité et à l'impossibilité de citer les sources. Le RAG permet ici d'ajouter la documentation de la dernière version le jour même de sa sortie, et de fonder chaque réponse sur un passage identifiable.

Un générateur de réponses au format et au ton imposés

Une seconde entreprise veut que son modèle rédige systématiquement ses réponses selon une structure stricte — un objet JSON avec des champs précis, ou un modèle de courriel à la voix de marque très codifiée. Ici, le besoin n'est pas de connaissance mais de comportement : peu importe le contenu factuel, ce qui compte est la forme, invariable. Cette exigence de format est stable : elle ne change pas d'une semaine à l'autre. Le fine-tuning est ici dans son élément. Quelques centaines d'exemples bien construits suffisent souvent à ancrer le format dans le modèle, de façon bien plus fiable qu'une longue consigne répétée à chaque requête — consigne que le modèle finit d'ailleurs parfois par négliger sur les prompts complexes. Un ajustement par LoRA, léger et sans surcoût de latence, répond parfaitement au besoin.

Un conseiller expert dans un domaine réglementé

Troisième situation, la plus riche : un cabinet veut un assistant qui manie le vocabulaire juridique ou médical de son domaine et réponde à partir d'une base documentaire tenue à jour, tout en citant ses sources. Ce besoin est double — comportement (le jargon, le raisonnement propre au métier) et connaissance (les textes, la jurisprudence, les référentiels à jour et traçables). C'est le cas typique où l'hybride s'impose. On ajuste légèrement le modèle pour qu'il adopte le registre et la rigueur attendus, puis on l'adosse à une couche RAG qui lui fournit les documents pertinents à chaque question. Le fine-tuning garantit la forme et le raisonnement ; le RAG garantit l'exactitude factuelle et la vérifiabilité. C'est exactement la combinaison que la recherche a montrée cumulative, et elle prend ici tout son sens.

Ces trois cas illustrent une vérité simple : la bonne architecture n'est pas une question de préférence technique, mais de nature du besoin. En qualifiant honnêtement ce que l'on cherche à obtenir, la solution se dessine presque d'elle-même. C'est pourquoi le temps passé à cadrer le besoin, en amont, est le mieux investi de tout le projet.

Les pièges courants, et comment les éviter

Connaître la théorie ne suffit pas ; encore faut-il déjouer les erreurs classiques qui plombent les projets. En voici les plus fréquentes, côté RAG comme côté fine-tuning.

Côté RAG

• Un découpage inadapté. Des fragments trop courts perdent le contexte ; trop longs, ils diluent l'information pertinente et gonflent le prompt. Le calibrage du découpage est l'un des leviers les plus déterminants de la qualité d'un RAG, et l'un des plus négligés.
• Un modèle d'embedding mal choisi ou incohérent. Rappelons-le : le même modèle doit indexer et interroger. Et sa qualité conditionne directement la pertinence des passages retrouvés — un mauvais embedding retourne des extraits hors sujet, que même le meilleur des modèles de langage ne pourra rattraper.
• La récupération de passages non pertinents. Si les fragments injectés sont à côté de la plaque, le modèle produira une réponse à côté de la plaque, avec une belle assurance. C'est le principe « déchets en entrée, déchets en sortie ». D'où l'intérêt de mesurer la qualité de la récupération, indépendamment de la génération.

Côté fine-tuning

• Un jeu de données de mauvaise qualité. Le fine-tuning est aussi bon que ses exemples. Des données bruitées, mal formatées ou incohérentes produisent un modèle bruité, mal formaté et incohérent. La constitution du jeu de données est souvent l'étape la plus coûteuse en temps, et la plus déterminante.
• Le surapprentissage. Sur un jeu trop restreint ou trop répétitif, le modèle mémorise ses exemples au lieu de généraliser, et devient sensible aux moindres variations de formulation. La littérature note d'ailleurs que le fine-tuning est sensible aux variations de prompt et sujet au surapprentissage — un risque à surveiller de près.
• Espérer injecter des faits par ce biais. C'est l'erreur de cadrage la plus répandue : vouloir « apprendre » au modèle le contenu de documents par fine-tuning. La recherche est nette sur ce point — c'est le terrain du RAG, pas du fine-tuning.

Choisir avec méthode plutôt que par mode

Que retenir de ce parcours ? D'abord, que RAG et fine-tuning ne sont pas des rivaux mais des outils complémentaires, chacun taillé pour un usage. Le RAG excelle à donner accès à une connaissance factuelle, fraîche et traçable — la recherche le confirme sans ambiguïté, en particulier pour les faits rares et spécifiques qui caractérisent les données d'une entreprise. Le fine-tuning excelle, lui, à inscrire un comportement, un style, un savoir-faire durable dans le modèle lui-même.

Ensuite, que l'accessibilité a changé la donne. Avec LoRA et QLoRA, le fine-tuning n'est plus un luxe réservé aux grands laboratoires : il tient sur une seule carte graphique et un budget d'heures. Le débat s'est déplacé du « qui peut se le permettre ? » vers le « qu'est-ce qui sert le mieux mon besoin ? » — un progrès pour tout porteur de projet.

Enfin, que la meilleure réponse est souvent nuancée. Les gains des deux approches se cumulent, et les architectures les plus abouties les marient : un modèle ajusté pour le ton et le format, une couche RAG pour la connaissance à jour. Plutôt que de suivre une mode ou de trancher par réflexe, la bonne démarche consiste à qualifier précisément son besoin — savoir ou savoir-faire, information stable ou volatile, exigence ou non de traçabilité, volume de requêtes — puis à laisser ces critères désigner la solution. C'est cette méthode, et non un dogme, qui distingue un projet d'IA qui tient ses promesses d'un projet qui déçoit. Spécialiser une IA sur vos données n'a rien d'un pari : c'est une décision d'ingénierie, et elle se prend avec des critères clairs.

Sources

Cet article s'appuie sur des travaux de recherche et des ressources techniques publics et vérifiables :

• Ovadia et al., « Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs » (EMNLP 2024) — arXiv 2312.05934 (le RAG surpasse le fine-tuning non supervisé pour l'injection de connaissances).
• Balaguer et al. (Microsoft), « RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture » — arXiv 2401.08406 (gains cumulatifs : +6 pts fine-tuning, +5 pts RAG ; similarité 47 % → 72 %).
• Soudani et al., « Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge » — arXiv 2403.01432 (avantage marqué du RAG sur les connaissances rares).
• Hu et al. (Microsoft), « LoRA: Low-Rank Adaptation of Large Language Models » — arXiv 2106.09685 (réduction jusqu'à 10 000× des paramètres entraînables).
• Dettmers et al., « QLoRA: Efficient Finetuning of Quantized LLMs » — arXiv 2305.14314 (fine-tuning d'un modèle 65B sur un seul GPU 48 Go).
• IBM, « RAG vs. Fine-tuning » — ibm.com/think (synthèse pratique des cas d'usage).