Construire un RAG sur des documents sensibles

La génération augmentée par récupération (RAG) fournit à un modèle de langage le bon contexte au bon moment. C'est la façon la moins coûteuse de rendre une IA utile sur des documents qu'elle n'a jamais vus. C'est aussi un champ de mines pour la confidentialité quand ces documents sont sensibles. Voici l'architecture que nous utilisons pour le désamorcer.

Ce que fait le RAG, en bref

Un pipeline RAG transforme vos documents en vecteurs, les indexe, et au moment de la requête récupère les fragments les plus pertinents à envoyer au modèle de langage avec la question de l'utilisateur. Le modèle répond ensuite en s'appuyant sur ces fragments. Comparé au fine-tuning, le RAG est rapide à mettre en place, facile à mettre à jour, et fonctionne sur de petits volumes.

Le problème de confidentialité

Un pipeline RAG standard transmet du contenu sensible à un tiers à trois moments distincts :

• Embedding. Le texte original est envoyé à un modèle d'embedding (OpenAI, Cohere, Voyage). Même si l'API ne retient pas le texte, les octets ont quitté votre réseau.
• Charge utile de récupération. Au moment de la requête, les fragments récupérés sont insérés dans le prompt et envoyés au LLM. Noms, montants et dates les accompagnent.
• Index persisté. Le vector store vit souvent dans le cloud. Le chiffrement au repos ne suffit pas quand un administrateur ou une décision de justice peut imposer l'accès.

Trois approches, classées par sûreté

A. RAG totalement local avec LLM local

Tout tourne sur votre machine : embedding, récupération, génération. Garantie de confidentialité maximale. Plus difficile à opérer en qualité. Utile pour les workflows très sensibles, où une qualité « suffisante » prime sur la qualité de pointe.

B. RAG anonymisé avec LLM cloud

Les documents sont anonymisés avant l'embedding. Le vector store ne contient que des fragments protégés. À la requête, les fragments récupérés (toujours protégés) sont envoyés à un LLM cloud. La réponse revient avec des marqueurs, échangés en local contre les valeurs réelles. C'est l'architecture que nous recommandons, et celle dans laquelle Hexagone AI s'insère.

C. RAG cloud, documents bruts

Le réglage par défaut dans la plupart des démos. Facile. Bon marché. Catastrophique sur des données sensibles. À éviter.

L'architecture, étape par étape

1. Ingestion, en local. Hexagone AI passe chaque document dans son moteur de détection local. Les identifiants sont remplacés par des marqueurs stables (CLIENT_3, MONTANT_8, DATE_14). La correspondance est écrite dans votre store local.
2. Embedder la version protégée. Seul le texte protégé est envoyé à votre fournisseur d'embeddings, ou à votre modèle d'embedding local. Le vector store, où qu'il soit, ne contient jamais vos données client réelles.
3. Récupérer sur protégé. La question de l'utilisateur est elle-même anonymisée via la même correspondance avant d'être embedée, pour que la requête et l'index parlent la même langue protégée.
4. Générer. Les fragments protégés récupérés + la question protégée vont au LLM. Le LLM répond en langue protégée, avec les mêmes marqueurs.
5. Restituer, en local. Sur votre machine, la réponse est rendue avec les valeurs réelles. L'utilisateur lit une réponse claire. Le LLM cloud n'a jamais vu de valeur réelle.

Notes de performance

• Les embeddings anonymisés retrouvent aussi bien que les embeddings bruts sur la plupart des tâches. La perte est de quelques pourcents dans nos benchmarks.
• Des marqueurs stables sont essentiels. Des jetons aléatoires détruisent le rappel.
• Le débit d'indexation reste proche d'un pipeline classique sur du matériel récent.

Où Hexagone AI s'insère

Nous ne remplaçons pas votre vector store, votre fournisseur d'embeddings, ni votre LLM. Nous nous insérons à la couche d'ingestion et à la couche de requête, sur la machine de l'utilisateur. Le reste de la pile reste exactement tel quel. Votre RAG existant, avec les propriétés de confidentialité que la plupart des équipes pensaient avoir depuis le début.