Monter un RAG 100 % local pour des donnees confidentielles

Une IA capable de répondre à partir de vos propres documents, ça change la donne. Mais dans la santé, le juridique ou la défense, il y a une contrainte non négociable : les documents ne doivent jamais quitter la machine. Pas d'envoi vers une API tierce, pas de copie sur un serveur distant. C'est précisément le terrain où un RAG local prend tout son sens. Voici comment le construire proprement.

Le problème : la donnée ne doit pas sortir

Un dossier patient, un contrat, une note interne classifiée : ce sont des données dont la fuite a des conséquences graves, parfois légales. Envoyer ces contenus à un service en ligne, même réputé, c'est déjà perdre le contrôle. L'enjeu n'est pas seulement la confiance dans le prestataire, c'est la conformité et la responsabilité. La réponse la plus sûre est radicale : tout traiter en local, sans aucun appel réseau.

RAG, en une phrase

RAG signifie « génération augmentée par la récupération ». Au lieu de demander au modèle de répondre de mémoire, on lui fournit d'abord les passages pertinents de vos documents, puis on lui demande de répondre en s'appuyant uniquement dessus. Le modèle ne récite pas, il s'appuie sur une source que vous contrôlez.

La chaîne, étape par étape

Le pipeline complet tient en six étapes :

1. Ingestion : on lit les documents (PDF, Word, texte) et on en extrait le texte brut.
2. Découpage : on coupe ce texte en morceaux (les chunks) de taille raisonnable.
3. Embeddings : chaque morceau est transformé en vecteur numérique par un modèle d'embedding, lui aussi local.
4. Stockage : ces vecteurs sont rangés dans une base vectorielle, sur le disque de la machine.
5. Récupération : à chaque question, on cherche les morceaux dont le vecteur est le plus proche de celui de la question.
6. Génération ancrée : on donne ces morceaux au modèle de langage local, qui rédige la réponse à partir d'eux.

Aucune de ces étapes n'a besoin d'internet. Tout vit sur la machine.

Choisir des modèles qui tournent en local

Deux modèles entrent en jeu, et tous deux existent en versions locales légères :

• Le modèle d'embedding, qui vectorise le texte. Des familles comme bge, e5 ou nomic-embed sont compactes et tournent sans difficulté sur un CPU.
• Le modèle de langage, qui rédige la réponse. Un bon modèle de taille moyenne, quantizé, suffit pour de la synthèse à partir de passages fournis. Sur ce point, voyez l'article sur le choix de la taille d'un modèle selon la machine.

L'avantage : ces deux modèles, une fois téléchargés, ne communiquent plus avec l'extérieur.

Le découpage, là où tout se joue

C'est l'étape la plus sous-estimée, et pourtant la plus déterminante pour la qualité. Quelques principes :

• Des morceaux trop grands noient l'information utile et saturent le contexte.
• Des morceaux trop petits perdent le fil et le sens.
• Un chevauchement léger entre morceaux consécutifs évite de couper une idée en deux.
• Mieux vaut découper en respectant la structure du document (paragraphes, sections) qu'au compteur de caractères aveugle.

Un bon découpage améliore les résultats plus sûrement qu'un changement de modèle.

Garder l'ancrage et éviter l'hallucination

Le risque d'un modèle de langage, c'est d'inventer. Pour le contenir :

• Demandez explicitement de répondre uniquement à partir des passages fournis.
• Demandez de citer la source de chaque affirmation.
• Autorisez le modèle à dire « je ne trouve pas la réponse dans les documents ». Une non-réponse honnête vaut mieux qu'une invention crédible.

Réponds à la question en t'appuyant seulement sur les extraits ci-dessous.
Cite l'extrait utilisé. Si la réponse n'y figure pas, dis-le clairement.

Évaluer son RAG

On n'améliore que ce qu'on mesure. Deux indicateurs simples :

• Le taux de récupération : pour un jeu de questions tests, les bons passages remontent ils bien dans les résultats ?
• La fidélité : la réponse colle t elle vraiment aux passages, sans ajout inventé ?

Constituez une petite liste de questions dont vous connaissez la réponse, et rejouez la à chaque changement. C'est rustique, mais c'est ce qui évite de régresser sans s'en rendre compte.

Les pièges à connaître

• Index périmé : si les documents changent, il faut réindexer, sinon le RAG répond sur une version ancienne.
• PDF mal extraits : un PDF scanné ou en colonnes peut donner un texte illisible. Vérifiez toujours l'extraction avant d'indexer.
• Sécurité du disque : tout est local, donc protégez le poste lui même (chiffrement du disque, accès contrôlé). La confidentialité se joue aussi hors du logiciel.
• Tentation du réseau : assurez vous qu'aucune brique n'appelle discrètement un service distant. Le « local » doit être total pour tenir sa promesse.

La stack minimale que je recommande

Pour démarrer sans usine à gaz :

1. Un moteur local pour faire tourner les modèles, type Ollama.
2. Un modèle d'embedding compact pour vectoriser.
3. Une base vectorielle légère, qui peut tenir dans un simple fichier sur le disque.
4. Un petit script qui enchaîne ingestion, recherche et génération.

C'est suffisant pour un premier RAG confidentiel qui fonctionne, et c'est extensible ensuite. L'essentiel n'est pas la sophistication de l'outil, mais la garantie que rien ne sort de la machine.

La meilleure donnée envoyée à un tiers reste celle qu'on n'envoie pas. Un RAG local, c'est cette promesse appliquée à vos propres documents.