Mettre du contenu « public » dans son RAG : la question piège que tout le monde se pose mal

Il y a une erreur de raisonnement très répandue chez ceux qui construisent leur premier système RAG. Elle semble logique en surface. Elle est pourtant responsable de la majorité des déceptions en production.

L’erreur, la voici : « Le LLM connaît déjà ces informations, inutile de les mettre dans ma base de connaissance. »

C’est faux. Pas « un peu faux ». Fondamentalement faux, parce que la question n’a jamais été est-ce que le modèle sait ? mais est-ce que je veux contrôler ce qu’il dit ?

Ce que RAG signifie vraiment, et ce que beaucoup oublient

Rappel rapide pour ceux qui débarquent : un système RAG (Retrieval-Augmented Generation) fonctionne en deux temps. D’abord, une phase de retrieval : on cherche dans une base vectorielle les passages les plus pertinents par rapport à la question posée. Ensuite, une phase de generation : le LLM produit sa réponse en s’appuyant sur ces passages comme contexte injecté dans le prompt.

L’idée centrale est simple : ancrer la génération dans des sources connues, datées, maîtrisées. Pas laisser le modèle improviser à partir de sa mémoire paramétrique, cette compression statistique de milliards de pages web qui date, au mieux, de plusieurs mois avant aujourd’hui. Si vous débutez sur le sujet, j’ai publié un guide complet sur le pipeline RAG qui couvre les sept décisions techniques structurantes, du chunking au reranking.

Pour une vision illustrée du fonctionnement d’un système RAG, cette vidéo résume l’essentiel en 10 minutes :

Le problème avec la question « faut-il inclure du contenu public ? » c’est qu’elle présuppose que la valeur d’un document dans le RAG est liée à son caractère exclusif. Ce n’est pas le cas.

L’argument « bruit » : légitime mais mal calibré

L’objection la plus solide qu’on entend : inclure du contenu générique va polluer le retrieval. Quand quelqu’un pose une question précise sur votre procédure interne de gestion des incidents, vous ne voulez pas que le système remonte un tutoriel Wikipedia sur l’ITIL.

C’est vrai. Mais c’est un problème de chunking, de métadonnées et de reranking, pas un problème inhérent à la nature publique ou privée du contenu.

Un retriever mal configuré va effectivement mélanger l’essentiel et l’accessoire. La solution n’est pas d’appauvrir votre base de connaissance, c’est de mieux structurer ce que vous y mettez : typage des sources, filtrage par namespace, reranker croisé (cross-encoder ou LLM-as-judge), seuil de similarité ajusté. Les outils existent. Le problème est opérationnel, pas conceptuel.

Et pour ceux qui s’inquiètent de la montée en charge : le vrai problème de performance à grande échelle, c’est que tout finit par se ressembler mathématiquement : le retriever ne distingue plus le signal du bruit. Ce n’est pas en appauvrissant votre base que vous l’éviterez. C’est en travaillant votre architecture de retrieval.

Quatre raisons concrètes d’inclure du contenu « déjà connu »

1. La version exacte compte plus que vous ne le croyez

Le LLM, seul, vous donne la version moyenne et lissée d’une information. La résultante d’un entraînement sur des milliers de sources contradictoires, parfois datées, souvent en anglais.

Exemple concret : vous gérez des appartements meublés en location courte durée. Le régime fiscal applicable (micro-BIC, abattement réel, seuils LMNP, cotisations sociales depuis la loi de finances 2024) a évolué plusieurs fois en deux ans. Si vous demandez à un LLM nu « quel est mon abattement fiscal en meublé ? », il va vous sortir quelque chose de plausible et de faux. Si votre base RAG contient les textes réglementaires à jour, les circulaires, et votre propre synthèse commentée, la réponse change radicalement.

Le sujet est « public » ? Absolument. Mais le modèle ne connaît pas votre version, votre interprétation, votre mise à jour du mois dernier.

2. Le RAG réduit les hallucinations même sur des sujets connus

C’est contre-intuitif mais documenté : un LLM hallucine davantage sur des sujets qu’il croit maîtriser que sur des sujets où il avoue son ignorance. La confiance paramétrique est un facteur de risque.

Pour voir concrètement pourquoi les LLM hallucinent + comment RAG règle ça (regarde 0:46 pour les causes, 1:55 pour les solutions RAG), cette vidéo :

Quand le contexte RAG est présent (même si l’information qu’il contient est techniquement « publique »), le modèle s’ancre dessus. Il n’a plus à interpoler entre dix mille sources vaguement contradictoires. Il a trois chunks précis, datés, cohérents. Des études récentes, dont celles publiées par l’équipe de recherche de Facebook AI qui a formalisé l’architecture RAG en 2020, montrent des réductions d’hallucinations documentées entre 20 et 70 % selon le domaine, la qualité du retrieval et la variante utilisée : RAG standard, SELF-RAG (qui s’auto-évalue et décide si le retrieval est utile avant de répondre) ou CRAG (qui corrige activement les chunks mal retrievés) pouvant pousser ce chiffre encore plus loin sur des corpus bien structurés. Sur des sujets très bien couverts à l’entraînement, le gain descend parfois à 10-25 % seulement, ce qui reste significatif et ne justifie en rien de s’en passer. Pour suivre l’évolution des taux d’hallucination par modèle en temps réel, le Vectara Hallucination Leaderboard et le baromètre AIMultiple constituent les deux références les plus régulièrement mises à jour.

Il est d’ailleurs utile de rappeler ce que les LLMs voient réellement quand ils lisent vos sources : pas un document intègre, mais une fraction tronquée à quelques dizaines de milliers de tokens, avec tout le bruit structurel que ça implique. Injecter vos chunks directement dans le contexte court-circuite ce problème.

3. La traçabilité : ce que le LLM nu ne pourra jamais vous donner

Un LLM seul ne peut pas citer de manière fiable. Il peut prétendre sourcer, en inventant des URLs plausibles ou en attribuant des formulations à des documents qui ne les contiennent pas. C’est un des vecteurs d’hallucination les mieux documentés.

Un RAG correctement configuré fait exactement le contraire : il retourne non seulement une réponse, mais les chunks sources avec leurs métadonnées : URL du document officiel, numéro de page, date de version. En production, ça change tout. L’utilisateur peut cliquer, vérifier, auditer. Il ne fait pas confiance à une boîte noire : il fait confiance à une référence.

C’est particulièrement critique sur du contenu réglementaire ou contractuel. Si votre système répond « selon l’article L. 145-2 du Code de commerce… » et qu’il peut pointer vers le texte exact sur Légifrance, vous avez un outil utilisable. S’il génère ça de mémoire, vous avez une bombe à retardement.

4. Votre vocabulaire, votre grille de lecture, votre niveau de détail

C’est la dimension la plus sous-estimée. Même sur un concept générique, la façon dont vous le définissez à vos utilisateurs ou à votre équipe compte. Et c’est précisément l’argument central que je développe sur l’IA comme commodité : les modèles sont devenus interchangeables, ce qui reste différenciant c’est le corpus propriétaire qu’on leur donne à interpréter.

Illustration : « qu’est-ce qu’une anomalie critique dans notre système ? » Un LLM vous sort une définition ITIL correcte. Votre document interne dit : « P0 : impact sur plus de 500 utilisateurs actifs OU indisponibilité de l’API de paiement OU compromission de données personnelles. Escalade PagerDuty immédiate. » C’est la même famille de concept. C’est une réponse radicalement différente, et c’est celle qui compte.

Les vrais cas où on peut se passer du contenu public

Soyons honnêtes : il y a des situations où l’exclusion est défendable.

Un POC ou une démonstration où vous testez uniquement le pipeline technique, pas la qualité des réponses. Inutile de monter une base de connaissance exhaustive pour valider que votre modèle d’embedding fonctionne.

Un domaine complètement hors-scope de votre système. Si votre RAG est conçu pour répondre sur vos produits e-commerce et qu’un utilisateur demande la définition de la photosynthèse, il vaut mieux laisser le LLM répondre librement (ou bloquer la requête) plutôt que de polluer votre base avec du contenu encyclopédique général.

Une veille large et exploratoire, où vous voulez précisément la synthèse du web, pas votre perspective maîtrisée. Dans ce cas, un accès direct au web via un LLM outillé est plus adapté qu’un RAG.

Il faut aussi mentionner une alternative architecturale qui commence à s’imposer dans certains contextes : le Cache-Augmented Generation (CAG). Quand votre corpus tient dans la fenêtre de contexte du modèle, charger l’intégralité des documents à chaque requête peut se révéler plus simple et plus précis que de maintenir une infrastructure RAG complète, sans les approximations induites par le retrieval vectoriel. CAG brille particulièrement quand votre corpus entier tient dans les 128k à 1M tokens que les meilleurs modèles 2026 offrent désormais, et que la fraîcheur des données n’est pas critique : la latence chute, la complexité opérationnelle aussi. Parfait pour tester vite un POC avec un petit corpus statique (<1M tokens) sans galérer avec une base vectorielle.

Pour un aperçu visuel des différences pratiques entre RAG et CAG, cette vidéo résume les forces et limites de chaque approche :

En dehors de ces cas, l’argument « le LLM le sait déjà » est une fausse économie.

Le vrai arbitrage : contrôle versus délégation

La bonne question à se poser pour chaque corpus potentiel n’est pas « ce contenu est-il exclusif ? » mais « est-ce que je veux être responsable de ce qui est dit sur ce sujet ? »

Si la réponse est oui (et dans 90 % des usages professionnels ou semi-professionnels elle l’est), alors le document a sa place dans votre base, qu’il soit public, semi-public ou parfaitement confidentiel.

Cet arbitrage contrôle/délégation se double d’un second, plus opérationnel : précision versus coût. Injecter cinq chunks pertinents dans le contexte coûte moins cher que d’en injecter vingt approximatifs. Ce n’est pas un argument pour appauvrir votre corpus, c’est un argument pour soigner votre chunking et votre reranker, afin de ne remonter que ce qui compte vraiment. Un RAG bien calibré est moins cher qu’un LLM nu qui hallucine et force l’utilisateur à reformuler.

Le RAG n’est pas un coffre-fort pour secrets industriels. C’est un mécanisme de contrôle éditorial appliqué à la génération automatique. La distinction public/privé est secondaire par rapport à la distinction contrôlé/non-contrôlé.

Ce que ça change en pratique

Pour ceux qui construisent activement leur pipeline, quelques implications concrètes :

Tagger systématiquement chaque document avec son type (réglementaire, interne, référence-externe), sa date de validité, et son niveau d’autorité. Le LLM peut s’appuyer sur ces métadonnées pour pondérer sa réponse.

Ne pas confondre retrieval et génération. Si vous avez peur du bruit, travaillez votre reranker et vos seuils de score, pas la taille de votre base. la recherche par mots-clés traditionnelle (BM25) reste une alternative sérieuse au retrieval vectoriel pur sur des corpus avec des identifiants précis (SKU, références normatives, codes).

Tester avec un golden dataset minimal : 15 à 20 questions représentatives de votre usage réel. Ajouter ou retirer des documents et mesurer l’impact sur la précision perçue. C’est la seule façon de trancher empiriquement.

Préférer le surplus au déficit. Un retriever qui remonte un document légèrement hors-sujet, c’est un cas de reranking à ajuster. Un retriever qui ne trouve rien parce que vous avez trop épuré votre base, c’est un LLM qui part en improvisation, et c’est infiniment plus dangereux.

Si vous voulez voir un pipeline RAG concret implémenté étape par étape, ce tutoriel vidéo est un bon point de départ :

Récapitulatif

La prochaine fois que vous hésitez à inclure un document parce qu’il traite d’un sujet « public », posez-vous cette seule question : si le système dit quelque chose de faux sur ce sujet, est-ce que ça me pose un problème ?

Si oui, mettez le document.