Qu’est-ce que le RAG ?

Le RAG (retrieval augmented generation, ou génération augmentée par récupération) s’est imposé comme l’une des approches les plus prometteuses pour rendre l’intelligence artificielle plus précise et plus fiable en entreprise. Les grands modèles de langage sont impressionnants, mais ils répondent à partir de leurs seules données d’entraînement, qui peuvent être datées, incomplètes ou tout simplement fausses.

Le RAG résout ce problème en connectant les modèles d’IA à l’infrastructure de connaissances de votre organisation : avant de générer une réponse, le modèle va chercher des informations réelles et vérifiables. Mais comme le souligne Joe Antelmi, analyste chez Gartner, "les plus grands défis des systèmes RAG ne tiennent pas au choix du modèle, mais à tout ce qui se passe avant et après son intervention", à commencer par la qualité et l’organisation du socle de connaissances sur lequel le système repose.

Ce constat confirme ce que les professionnels de la gestion des connaissances répètent depuis des années : pas d’IA sans connaissance. L’architecture d’IA la plus sophistiquée échoue si le socle de connaissances qui la porte fait défaut.

Comprendre ce qu’est le RAG, comment il fonctionne et pourquoi il exige des données d’une qualité irréprochable est donc essentiel pour toute organisation qui explore l’IA. Les chiffres des grands cabinets d’analystes sont sans appel : 80 % des projets d’IA échouent, soit près du double des projets informatiques classiques, la qualité des données en tête des causes. Et le RAG amplifie les défauts de ses sources au lieu de les gommer.

Qu’est-ce que le RAG et comment fonctionne-t-il ?

Le RAG est une approche architecturale qui renforce les grands modèles de langage en les reliant à des sources de connaissances externes au moment de la requête. Plutôt que de s’appuyer uniquement sur le savoir absorbé pendant l’entraînement (ce que les chercheurs appellent la "connaissance paramétrique"), un système RAG va chercher dynamiquement l’information pertinente dans des référentiels structurés quand un utilisateur pose une question. L’architecture hybride qui en résulte combine les capacités neuronales des modèles de langage et la précision des systèmes de recherche d’information.

L’approche vient de travaux menés par Meta AI Research, l’University College London et l’université de New York, qui ont conçu le RAG comme un moyen de connecter à peu près n’importe quel grand modèle de langage à n’importe quelle ressource externe. Elle répond à une limite bien connue : les modèles excellent sur les questions générales, mais une organisation qui entretient un vaste référentiel interne ne peut pas réentraîner un modèle à chaque nouvelle information.

Les quatre étapes du pipeline RAG

Un système RAG enchaîne quatre étapes, chacune avec un rôle précis dans la récupération et la génération :

Étape 1 : ingestion et indexation

La première étape transforme des documents peu ou pas structurés en formats exploitables pour la recherche sémantique. Les documents bruts (PDF, fichiers markdown, enregistrements de bases de données, contenus web) sont convertis en représentations standardisées par embedding : le texte devient un vecteur dense dans un espace de grande dimension. Un modèle d’embedding analyse le sens et le convertit en coordonnées numériques qui préservent les relations de sens. Deux documents qui traitent d’exigences réglementaires proches, par exemple, se retrouvent voisins dans cet espace, ce qui permet de retrouver les contenus pertinents par similarité sémantique.

Ces vecteurs sont chargés dans des bases de données vectorielles, dont les algorithmes d’indexation spécialisés, comme HNSW (Hierarchical Navigable Small World) ou FAISS (Facebook AI Similarity Search), permettent des recherches rapides parmi des millions, voire des milliards de vecteurs. À grande échelle, l’infrastructure devient conséquente : indexer un milliard d’embeddings BERT-base demande environ 3,5 To de RAM, soit près de 22 000 dollars de coûts cloud par mois, hors redondance et réplication.

Étape 2 : récupération

Quand un utilisateur pose une question, le système applique la même transformation à la requête : la question en langage naturel devient un vecteur dans le même espace sémantique que les documents. Des mesures de similarité, généralement la similarité cosinus ou la distance euclidienne, identifient les vecteurs les plus proches de la requête. Les mises en œuvre modernes combinent souvent recherche sémantique et recherche classique par mots-clés : cette approche hybride capture à la fois le sens et les correspondances exactes de terminologie, ce qui compte particulièrement dans les domaines techniques, où un acronyme précis doit être retrouvé tel quel.

Étape 3 : augmentation

Plutôt que de renvoyer des résultats de recherche à l’utilisateur, le système assemble les documents récupérés et la question d’origine en un seul prompt composite, dit "prompt augmenté", transmis au modèle avec les instructions du développeur de l’application. La forme de cet assemblage pèse lourdement sur le résultat : la recherche en ingénierie de prompt montre qu’une séparation nette entre contenus récupérés et instructions, un formatage explicite des documents sources et une organisation réfléchie des passages améliorent sensiblement la qualité des réponses.

Étape 4 : génération

La dernière étape confie au modèle la synthèse d’une réponse ancrée dans le contexte augmenté. Au lieu de répondre depuis sa seule connaissance paramétrique, le modèle traite le contexte récupéré en même temps que la question : il peut intégrer des éléments précis, citer ses sources et adapter la réponse aux informations propres à l’organisation. La génération opère sous contraintes définies à l’avance : longueur maximale, température qui règle la créativité, parfois l’instruction explicite de ne s’appuyer que sur le contexte fourni. Ces contraintes, ajoutées à la présence des sources, réduisent nettement les hallucinations par rapport à une génération libre.

Les avantages sur un modèle de langage seul

Le RAG apporte trois avantages décisifs par rapport au déploiement classique d’un modèle. D’abord, il permet de remplacer les sources de connaissances "à chaud" : l’organisation peut modifier, étendre ou remplacer ses sources externes sans réentraîner le modèle ni toucher à l’infrastructure. Une politique interne change, une réglementation paraît, le marché bouge ? Le système en tient compte dès la mise à jour du référentiel, sans cycle de réentraînement long et coûteux.

Ensuite, en citant ses sources, à la manière des notes de bas de page d’un article de recherche, un système RAG instaure la confiance : chaque affirmation peut être vérifiée dans le document d’origine. Cette traçabilité est précieuse dans les secteurs réglementés, où pistes d’audit et vérification des sources sont des nécessités opérationnelles, pas des options.

Enfin, le RAG réduit nettement le risque d’hallucination (ces contenus plausibles mais faux que produisent les modèles) en ancrant les réponses dans des éléments récupérés. Des hallucinations restent possibles, même dans un système bien architecturé, à cause de sources ambiguës ou d’une récupération peu pertinente, mais l’architecture pose des garde-fous qu’une génération libre n’a pas.

Pourquoi le RAG exige-t-il des données de qualité ?

L’efficacité d’un système RAG repose fondamentalement sur la qualité et l’organisation des contenus intégrés au référentiel, une dépendance critique et pourtant très sous-estimée dans les déploiements en entreprise. CloudFactory résume le principe avec précision : "le RAG amplifie les problèmes de qualité des données au lieu de les atténuer : un système qui s’appuie sur des données pauvres, incohérentes ou périmées produira de mauvais résultats, quelle que soit la sophistication des algorithmes".

Les chiffres le confirment. Selon Gartner, 80 % des projets d’IA échouent, et 43 % des organisations citent la qualité des données comme premier obstacle. Sur l’IA générative en particulier, Gartner prévoit qu’au moins 30 % des projets seront abandonnés après la preuve de concept, la qualité des données, des contrôles de risque insuffisants, des coûts qui dérapent et une valeur métier floue en tête des causes. Plus frappant encore, jusqu’à 87 % des projets d’IA n’atteindraient jamais la production à cause de problèmes de qualité de données.

Des données propres comme fondation

Des données propres (exactes, complètes, sans erreurs) forment la colonne vertébrale de toutes les capacités d’un RAG. Le bénéfice le plus visible est la précision : des données fiables garantissent que la phase de récupération fournit une information correcte. Quand le référentiel contient des inexactitudes, des incohérences ou des détails hors sujet, ce bruit parasite la récupération : des informations erronées ou sans rapport se retrouvent dans le contexte, et les réponses deviennent trompeuses ou confuses, au point de saper la confiance dans tout le système.

L’enjeu monte d’un cran dans les secteurs réglementés, où une information fausse a des conséquences en matière de conformité et de sécurité. Un RAG médical qui récupère une littérature périmée fait courir de vrais risques pour la santé. Un système juridique adossé à une base de jurisprudence altérée expose à des manquements de conformité. Un RAG financier ancré dans des données de marché fausses fragilise les décisions d’investissement et les rapports réglementaires. Dans ces contextes, la confiance est indispensable, et tout se joue dans les pratiques de qualité des données.

Comme le soulignait Joe Antelmi au sommet Gartner Data & Analytics 2024, "la réalité désordonnée des systèmes RAG, ce sont des documents périmés, des versions contradictoires, une qualité de données médiocre et la lutte permanente pour récupérer la bonne information au bon moment". Les organisations se heurtent sans cesse à plusieurs versions du même document, à des brouillons inachevés et à des formats non structurés qui minent la précision de la récupération, quel que soit le modèle.

Des données structurées et une architecture de l’information

Au-delà de la propreté, une organisation structurée des données amplifie nettement la performance d’un RAG en facilitant une récupération rapide et exacte. Catégorisation claire, tags détaillés, indexation précise : le système identifie plus vite l’information pertinente, les temps de réponse baissent, l’expérience s’améliore.

En entreprise, en particulier quand des milliers de tables de bases de données portent des centaines d’attributs, l’enrichissement des métadonnées devient déterminant pour comprendre sémantiquement la structure et le contenu des bases. Il faut d’abord extraire et organiser les métadonnées qui décrivent le schéma, généralement exposées par des tables système comme les vues INFORMATION_SCHEMA. Une fois stockées, ces métadonnées permettent au RAG de répondre aux questions structurelles en créant un graphe de connaissances du schéma, interprétable par le modèle.

Les études qui évaluent systématiquement la composition des métadonnées et son effet sur la récupération sont parlantes : des embeddings TF-IDF combinés à un découpage récursif atteignent 82,5 % de précision et un NDCG (normalised discounted cumulative gain) de 0,807, nettement au-dessus des approches sans métadonnées riches. Le découpage récursif seul reste constant quel que soit l’embedding, avec une précision de 78,3 % à 82,5 % : il produit des représentations robustes, qui préservent l’intégrité du contexte.

La distinction "données prêtes pour l’IA"

Ce que les organisations décrivent comme un "manque de données" ne reflète généralement pas un volume insuffisant, mais un déficit de données "prêtes pour l’IA" : préparées, nettoyées, structurées et gouvernées au niveau qu’exigent entraînement et inférence. À l’heure où les volumes doublent ou triplent chaque année, le goulot d’étranglement n’est pas la rareté, c’est l’absence de données au standard de qualité que demande l’IA.

Les cadres classiques de gestion des données, efficaces pour l’analytique classique, se révèlent inadaptés à l’IA : les exigences vont bien au-delà des paramètres de qualité qui suffisaient aux générations précédentes d’outils. Plus de 75 % des organisations placent d’ailleurs les données prêtes pour l’IA dans leurs cinq premiers axes d’investissement des deux à trois prochaines années, signe que le besoin est bien identifié.

Ce déficit de préparation ne tient pas à une limite technologique, mais à la sous-estimation du travail nécessaire pour transformer des données brutes en actifs capables d’alimenter des systèmes intelligents. Les projets qui réussissent consacrent 60 à 80 % des ressources à la seule préparation des données, un effort que beaucoup d’organisations persistent à sous-évaluer.

C’est précisément là que l’infrastructure de gestion des connaissances apporte une valeur stratégique : les organisations qui ont investi dans le cycle de vie de leurs connaissances (un actif vivant, qui demande curation continue, versions et gouvernance) voient leur RAG réussir là où d’autres échouent. Le fardeau des "60 à 80 % de préparation" disparaît en grande partie quand l’infrastructure de connaissances existe déjà.

RAG ou fine-tuning ?

Pour améliorer les performances d’un modèle de langage, les organisations comparent souvent deux approches, le RAG et le fine-tuning (l’ajustement du modèle par réentraînement), qui relèvent de philosophies architecturales et opérationnelles très différentes. Toutes deux visent de meilleures performances sur des tâches spécialisées, mais leurs coûts, leur gestion de la connaissance, leur capacité à monter en charge et leurs profils de performance divergent nettement.

Fraîcheur de la connaissance et souplesse de mise à jour

Le RAG puise l’information à la volée dans des sources externes : la connaissance se met à jour quasi instantanément. Un modèle fine-tuné reste limité à ce qu’il savait lors de son dernier entraînement : l’information nouvelle n’y entre que par un cycle complet de réentraînement, et les réponses peuvent rester périmées pendant des semaines, voire des mois.

La différence pèse lourd partout où l’information bouge vite ou doit être à jour en temps réel : marchés financiers, recherche médicale, cadres réglementaires, politiques produit. Le RAG excelle dans ces scénarios : il fournit une information à jour sans effort. Un modèle fine-tuné s’y retrouve face à un choix inconfortable : accepter l’information périmée, ou payer des cycles de réentraînement périodiques.

Structures de coûts et arbitrages économiques

Le fine-tuning implique des coûts initiaux élevés (ressources de calcul, étiquetage des données), puis l’usage du modèle revient au coût standard de l’inférence. Le RAG fait l’économie de l’entraînement, mais génère des coûts d’infrastructure permanents : systèmes de récupération, bases vectorielles, modèles d’embedding. Il ajoute aussi une surcharge à l’exécution, la recherche précédant la génération, ce qui peut allonger la latence ou compliquer la montée en charge.

Pour une organisation au domaine stable, où la connaissance change peu, le fine-tuning amortit son coût initial sur la durée et peut revenir moins cher à l’inférence que l’entretien permanent d’une infrastructure RAG. À l’inverse, dans un domaine mouvant, il faut mettre en balance les coûts de réentraînement du fine-tuning et les coûts d’infrastructure du RAG.

Profils de performance et cas d’usage

Le fine-tuning atteint généralement une très grande précision sur les tâches de son domaine, qu’il a apprises en profondeur : sorties bien calibrées, terminologie exacte, solutions dans la droite ligne des exemples d’entraînement. Sur un banc d’essai de questions juridiques, un modèle juridique fine-tuné devancera sans doute aussi bien un modèle généraliste qu’une approche RAG.

Le RAG, lui, améliore la précision factuelle en ancrant les réponses dans des données réelles : le modèle reçoit des extraits de sources de référence, ce qui réduit le risque d’hallucination en reprenant les formulations et les chiffres exacts des documents. La qualité finale dépend toutefois de la capacité du modèle à exploiter le contexte, et une récupération médiocre entraîne des réponses médiocres.

Les approches hybrides, pour le meilleur des deux

Les bonnes pratiques actuelles combinent de plus en plus les deux approches dans des architectures hybrides : le volet fine-tuné apporte l’expertise du domaine, la terminologie et le format de sortie appropriés ; le volet RAG garantit l’accès à des données à jour, aux documents récents et aux derniers développements. Le système combine alors raisonnement spécialisé et information à jour.

Les grands défis de mise en œuvre

Au-delà de l’architecture technique, déployer un RAG à l’échelle d’une entreprise se heurte à des défis systémiques : complexité organisationnelle, fragmentation des données, exigences de sécurité, gouvernance. L’étude de Zeta Alpha sur l’échec des projets pilotes d’IA générative recense des difficultés récurrentes qui dépassent largement le choix du modèle ou de la base vectorielle.

Fragmentation des données et complexité d’accès

Les données d’entreprise résident rarement dans un référentiel unifié : l’information se disperse entre stockage cloud, plateformes de communication, dépôts de code, CRM, systèmes de gestion de contenu et bases historiques. Le cas typique : des contenus éparpillés entre OneDrive ou SharePoint, les conversations Microsoft Teams, des dépôts GitHub, des tickets Jira, des tableaux Trello, Dropbox, des compartiments Amazon S3, le CRM HubSpot, des wikis Confluence et une multitude de portails internes. Les utilisateurs attendent une interface de recherche unique, capable de retrouver l’information où qu’elle soit ; chaque source impose pourtant ses droits d’accès, ses formats et ses fréquences de mise à jour.

Cette fragmentation n’a rien de nouveau. Les plateformes de gestion des connaissances y répondent depuis des années en créant une couche de savoir unifiée, qui agrège, structure et entretient l’information de l’entreprise à travers les sources. Ce qui a changé : avec le RAG, cette consolidation n’est plus un confort, c’est une condition. Sans socle unifié, le système ne peut pas récupérer de façon fiable la bonne information au bon moment.

Sécurité et conformité

Dans les secteurs réglementés, un RAG d’entreprise doit appliquer un contrôle d’accès par rôle (RBAC), imposé via l’intégration du fournisseur d’identité. Tous les collaborateurs n’ont pas les mêmes droits : certains fichiers restent privés, d’autres se partagent en groupe restreint, d’autres sont publics. Le système doit respecter ces permissions fines à la récupération, à l’indexation et à la génération, pour ne jamais faire remonter une information à laquelle l’utilisateur n’a pas droit.

Un établissement de santé qui traite des données médicales protégées devra satisfaire aux exigences HIPAA : chiffrement au repos et en transit, journalisation des accès, procédures de notification des violations. Les institutions financières répondent au PCI-DSS, les cabinets d’avocats préservent le secret professionnel, les administrations appliquent leurs systèmes de classification. En Europe, le RGPD s’applique dès qu’une donnée personnelle entre dans le référentiel, et l’hébergement de données de santé en France exige un hébergeur certifié HDS.

La prolifération des RAG

La multiplication de systèmes RAG développés indépendamment dans une grande organisation crée une dette technique qui s’aggrave avec le temps. Chaque système exige un entretien continu : pipelines d’ingestion, index vectoriels, connexions aux sources internes ou tierces, mises à jour à chaque nouvelle version de modèle ou de technologie de récupération. Le travail se fait en double : chaque équipe réinvente ses mécanismes de récupération, ses pipelines et ses prompts.

Cette prolifération (le "RAG sprawl") déclenche des difficultés en cascade : effort de développement multiplié, expérience utilisateur inégale d’un système à l’autre, données fragmentées en silos, sécurité complexifiée par autant de surfaces vulnérables indépendantes, montée en charge difficile, coûts démultipliés, et une dette technique qui grossit à chaque nouvelle obligation de maintenance.

Comment préparer ses données pour réussir son RAG ?

Réussir un RAG demande une démarche systématique, sur le plan technique comme sur ceux de l’organisation et de la gouvernance. Bâtir un socle de données prêt pour l’IA exige un investissement qui va bien au-delà de la gestion de données classique.

C’est ici que la distinction entre "avoir des données" et "avoir une infrastructure de connaissances" devient décisive. Comme l’explore notre article sur l’IA et la gestion des connaissances, un RAG n’a pas besoin de plus de documents. Il a besoin de connaissances structurées, entretenues et gouvernées, préparées pour la récupération intelligente.

Poser les trois piliers fondamentaux

Gartner identifie trois piliers de la préparation à l’IA. Le premier, la gestion des métadonnées, fonde la découverte des données. Les métadonnées (le "qui", "quoi", "où", "quand" et "comment" derrière chaque donnée) transforment une information isolée en enseignement exploitable. Bien gérées, elles donnent une visibilité complète sur les actifs de données, leur origine, leur structure et leurs usages par département, ce qui améliore leur découvrabilité et leur réutilisation tout en rapprochant équipes métier et IT.

Les plateformes de gestion des connaissances modernes intègrent cette gestion des métadonnées à tout le cycle de vie du contenu : auteurs, historique des mises à jour, statistiques d’usage et relations contextuelles sont capturés automatiquement à mesure que le contenu évolue, sans enrichissement rétroactif.

Le deuxième pilier, la qualité des données elle-même, dépasse largement la gestion de qualité traditionnelle. Le modèle le plus avancé échoue sur des données médiocres : des données incohérentes ou peu fiables minent les résultats, la confiance et la conformité. Avec des volumes en croissance exponentielle, l’information servie aux modèles doit être propre, standardisée et dédoublonnée.

C’est là que la gestion du cycle de vie des connaissances devient essentielle. Comme le montre notre analyse sur la connaissance comme fondation de l’IA, traiter le savoir comme un actif vivant, entretenu en continu (flux d’approbation, dates d’expiration, suivi des usages, cycles de relecture), prévient la dette de connaissances qui tue les projets RAG. Le savoir ne s’entretient pas tout seul : sans gestion active, il cesse d’être prêt pour l’IA.

Le troisième pilier, l’observabilité des données, permet de surveiller leur santé en temps réel. À mesure que les volumes croissent, l’organisation doit contrôler en continu que ses systèmes de données fonctionnent comme prévu. Alertes en temps réel, investigation proactive, traçage des flux : les équipes détectent les anomalies et les corrigent avant qu’elles ne touchent l’activité.

Choisir des stratégies concrètes de découpage et de récupération

Les modèles à grand contexte peuvent en théorie absorber plus de données, mais le découpage (chunking) reste indispensable pour maîtriser les coûts et la précision de la recherche. Le découpage en blocs de taille fixe se révèle trop simpliste : il coupe le contexte au mauvais endroit. Le découpage sémantique et le découpage sensible au contenu préservent bien mieux le sens d’une section à l’autre.

La recherche hybride, qui combine mots-clés et vecteurs, affiche des performances supérieures, tandis que la réécriture de requête (l’IA reformule les questions vagues pour en clarifier l’intention) et le re-ranking (récupérer plus de documents, puis ne retenir que les meilleurs) affinent les résultats. Les approches d’auto-évaluation permettent même au système de juger la qualité de sa propre récupération et d’ajuster dynamiquement ses résultats.

Préparer l’organisation, pas seulement la technique

Une évaluation stratégique établit où en est l’organisation : infrastructure de données, capacités de gouvernance, ressources techniques, préparation des équipes. Seules 21 % des entreprises remplissent pleinement les critères de préparation, ce qui explique bien des déceptions. L’évaluation identifie les cas d’usage des premiers pilotes et fixe des indicateurs mesurables, liés aux résultats métier. Des cas d’usage à faible risque laissent aux équipes le temps de monter en compétence avant les scénarios complexes.

La conduite du changement est tout aussi déterminante : la résistance des équipes peut faire dérailler la mise en œuvre la mieux conçue. Il faut un programme complet, qui réponde aux inquiétudes, forme et accompagne, et établisse clairement que l’IA augmente les capacités humaines au lieu de les remplacer.

Les organisations qui réussissent leur RAG partagent un trait : elles ont compris que le RAG est d’abord un problème de connaissance, pas seulement un problème d’IA. En posant d’abord l’infrastructure de connaissances (un socle unifié, gouverné, entretenu), elles ont fait du RAG non plus une expérimentation technique risquée, mais un outil fiable en production. Les modèles d’IA se remplacent et s’améliorent sans cesse. Votre infrastructure de connaissances, elle, est l’actif stratégique durable qui les fait réellement fonctionner.

FAQ

Questions fréquentes sur le RAG (retrieval augmented generation)

RAG signifie retrieval augmented generation, ou génération augmentée par récupération : une architecture d’IA qui renforce les grands modèles de langage en les connectant à des sources de connaissances externes. Au lieu de répondre depuis ses seules données d’entraînement, un système RAG récupère l’information pertinente dans les documents et bases de votre organisation avant de générer sa réponse, qui reste ainsi exacte, à jour et ancrée dans des sources de référence.

Un modèle de langage classique répond uniquement à partir du savoir absorbé pendant son entraînement, qui peut être daté ou incomplet. Un système RAG va chercher l’information dans des référentiels à jour au moment de répondre : il cite ses sources, intègre les mises à jour récentes et adapte ses réponses aux informations propres à l’organisation, sans réentraînement coûteux du modèle.

Les études montrent que 80 % des projets d’IA échouent d’abord à cause de la qualité des données, pas de la technologie. Le RAG amplifie les problèmes de qualité au lieu de les atténuer : bâti sur des documents désordonnés, périmés ou contradictoires, il produit des réponses peu fiables, quel que soit le modèle. Les organisations sous-estiment que 60 à 80 % des ressources du projet doivent aller à la préparation, au nettoyage et à la gouvernance des données. La solution n’est pas un meilleur modèle : c’est de poser d’abord une vraie infrastructure de connaissances, en traitant le savoir comme un actif géré plutôt que comme des documents éparpillés.

Le RAG réduit nettement le risque d’hallucination en ancrant les réponses dans des éléments récupérés, mais il ne l’élimine pas totalement. Des hallucinations restent possibles : sources ambiguës, récupération peu pertinente, contexte trop volumineux qui embrouille le modèle. L’architecture pose néanmoins des garde-fous, citations des sources et génération sous contraintes, qu’une génération sans ancrage n’offre pas.

Tout dépend du cas d’usage. Le RAG excelle quand l’information change souvent, quand il faut citer ses sources ou quand les ressources manquent pour réentraîner régulièrement. Le fine-tuning convient aux domaines stables, qui exigent une terminologie spécialisée et un format de sortie constant. Les bonnes pratiques combinent de plus en plus les deux : un modèle fine-tuné pour l’expertise du domaine, le RAG pour l’accès à une information à jour.

Pour aller plus loin :

Qu’est-ce que le RAG (retrieval augmented generation) ?