Agents IA et automatisation

RAG et base de connaissances : ancrer un LLM dans vos propres documents

Comment fonctionne le RAG : récupérer, enrichir, répondre

Le RAG se déroule en deux phases. Une phase d'indexation prépare votre base de connaissances : les documents sont découpés en passages (chunks), chaque chunk est converti en vecteur numérique (embedding) qui capte son sens, et les vecteurs sont stockés dans une base vectorielle. Au moment de la requête, la question de l'utilisateur est vectorisée de la même façon, le système récupère les chunks les plus proches sémantiquement et insère ces passages dans le prompt comme contexte. Le LLM produit alors une réponse ancrée dans le texte récupéré plutôt que dans sa mémoire d'entraînement.

  • Découpage : segmenter les documents en passages cohérents pour que la récupération renvoie des extraits ciblés et citables.
  • Embeddings : convertir textes et questions en vecteurs pour que la similarité sémantique, et non de simples mots-clés, guide la récupération.
  • Base vectorielle et récupération : trouver les passages les plus pertinents, souvent combinés à la recherche par mots-clés (recherche hybride).
  • Enrichissement et génération : transmettre au LLM les passages récupérés et la question ; le modèle répond et peut citer ses sources.

Pourquoi l'ancrage réduit les hallucinations

Un LLM isolé répond à partir des schémas appris pendant l'entraînement. Lorsqu'un fait lui manque, il peut néanmoins produire une réponse fluide mais fausse — une hallucination. Le RAG transforme la tâche de « se souvenir » en « lire et résumer » : on remet au modèle le texte source pertinent et on lui demande d'y répondre. Cela restreint sa liberté d'inventer, garde les réponses à jour lorsque vos documents évoluent et, surtout, permet au système de montrer de quel passage provient une réponse, afin que des humains la vérifient. L'ancrage n'élimine pas totalement les erreurs : si la récupération renvoie le mauvais passage, ou si le prompt n'oblige pas le modèle à rester dans le contexte fourni, des erreurs surviennent encore.

Bâtir une base de connaissances qui tient vraiment

La qualité d'un système RAG se joue moins sur le modèle que sur la base de connaissances qui l'alimente. Des documents propres, bien structurés et à jour l'emportent sur un modèle plus gros nourri de données désordonnées.

  • Sélectionner les sources : manuels, politiques, FAQ, contrats, pages wiki — uniquement des contenus fiables et maintenables.
  • Découper avec discernement : des passages trop grands diluent la pertinence, trop petits perdent le contexte. Respecter la structure naturelle (titres, sections).
  • La garder à jour : réindexer quand les documents changent ; des chunks périmés sont une cause fréquente de réponses erronées.
  • Ajouter des métadonnées : langue, service, date de validité, niveau d'accès — pour que la récupération puisse filtrer (ex. seulement l'actuel, seulement le DE).
  • Gérer les permissions : un assistant RAG doit respecter qui a le droit de voir quel document.

RAG, fine-tuning ou fenêtre de contexte plus grande ?

Ces approches résolvent des problèmes différents et se combinent souvent. Exemples illustratifs pour une PME suisse : un assistant interne qui répond aux questions du personnel à partir du manuel RH et cite la clause ; un bot de support ancré dans la documentation produit actuelle en allemand et en français ; un assistant commercial qui récupère la dernière liste de prix au lieu de deviner.

  • Le RAG ajoute de la connaissance : idéal quand les faits changent souvent, doivent être citables ou sont trop nombreux pour un prompt. On met à jour en modifiant les documents, pas en réentraînant.
  • Le fine-tuning façonne le comportement et le style : il enseigne un format, un ton ou une compétence précise — pas un moyen fiable de stocker de nombreux faits.
  • Les grandes fenêtres de contexte permettent de coller les documents directement : simple pour quelques fichiers, mais coûteux et plus lent à grande échelle — et il faut toujours choisir quoi inclure, ce que fait précisément la récupération.

Erreurs fréquentes et comment les éviter

  • Traiter le RAG comme du plug-and-play : la qualité de récupération doit être testée et réglée (découpage, recherche hybride, re-ranking).
  • Aucune citation des sources : sans montrer les passages, les utilisateurs ne peuvent pas vérifier et la confiance s'érode.
  • Ignorer l'évaluation : mesurer si les réponses sont ancrées dans le texte récupéré, pas seulement si elles sonnent bien.
  • Laisser le modèle répondre au-delà du contexte : lui demander de dire « introuvable dans les sources » plutôt que de deviner.
  • Oublier la gouvernance des données : les documents sensibles dans un index nécessitent toujours un contrôle d'accès et une base légale.

Perspective suisse et DACH : protection des données dès la conception

Pour les organisations suisses, une base de connaissances RAG contient souvent des données personnelles ou confidentielles ; la protection des données fait donc partie de la conception, pas d'un ajout tardif. En vertu de la loi fédérale révisée sur la protection des données (revDSG/nFADP), supervisée par le PFPDT (EDÖB), vous avez besoin d'une base légale, de transparence et d'une sécurité appropriée pour les données personnelles que vous indexez et traitez. Si vous servez des utilisateurs de l'UE ou y déployez des systèmes d'IA, l'EU AI Act peut s'appliquer de façon extraterritoriale.

  • Résidence des données et choix du prestataire : savoir où ont lieu l'indexation, l'embedding et la génération ; un hébergement en Suisse ou dans l'UE peut être requis pour les données sensibles.
  • Contrôle d'accès : la récupération doit respecter les permissions des documents pour que l'assistant ne révèle jamais de données qu'un utilisateur n'a pas le droit de voir.
  • Transparence et supervision humaine : indiquer aux utilisateurs qu'ils interagissent avec la KI, montrer les sources et garder un humain dans la boucle pour les réponses à fort enjeu.
  • Minimisation des données : n'indexer que ce dont le cas d'usage a besoin ; ne pas verser de données sensibles dans la base de connaissances sans justification.

Questions fréquentes

Qu'est-ce qu'une base de connaissances RAG ?

Une base de connaissances RAG est l'ensemble de vos propres documents préparé pour la récupération par un modèle de langage : le contenu est découpé en passages, stocké sous forme d'embeddings dans une base vectorielle et interrogé par pertinence à chaque question. Les passages correspondants sont fournis au LLM comme contexte, afin qu'il réponde à partir des faits et puisse citer ses sources.

Le RAG empêche-t-il totalement les hallucinations ?

Non. Le RAG réduit fortement les hallucinations car le modèle répond à partir du texte source fourni plutôt que de sa mémoire, mais il ne les supprime pas totalement. Des erreurs restent possibles si la récupération renvoie le mauvais passage, si les documents sont périmés ou si le modèle n'est pas invité à rester dans le contexte. D'où l'importance des citations et de l'évaluation.

RAG ou fine-tuning : lequel est meilleur pour la connaissance d'entreprise ?

Pour la connaissance d'entreprise, le RAG est généralement le meilleur choix, car les faits changent souvent, doivent être citables et se mettent à jour en modifiant les documents plutôt qu'en réentraînant. Le fine-tuning convient pour façonner un format, un ton ou une compétence précise, pas pour stocker de nombreux faits de façon fiable. On combine souvent les deux.

Quelles données conviennent à une base de connaissances ?

Conviennent les contenus fiables et maintenables : manuels, politiques, FAQ, documentation produit, contrats ou pages wiki. L'important est d'être à jour, bien structuré et doté de métadonnées comme la langue et la date de validité. N'indexer les données personnelles sensibles qu'avec une base légale et un contrôle d'accès, selon le principe de minimisation du revDSG/nFADP.

Comment maintenir une base de connaissances RAG à jour ?

En réindexant ou en mettant à jour de façon ciblée dès qu'un document change, et en utilisant des métadonnées comme la date de validité pour filtrer les passages périmés. Vérifier régulièrement les réponses par rapport aux sources révèle si des chunks manquent ou sont obsolètes. Le contenu périmé est l'une des causes les plus fréquentes de réponses erronées.

Termes du glossaire

← Retour à l’aperçu

L’IA pratique pour votre entreprise

De l’idée à la mise en œuvre – nous vous montrons ce qui est concrètement possible dans votre cas.

Demander une démo