10 La génération augmentée par récupération (en anglais) vit ou meurt par la couche de stockage qui la soutient. Le modèle de langage est un actif figé ; le corpus que le modèle lit à chaque appel est l’élément vivant. Le stockage des données RAG est la discipline qui consiste à concevoir le socle qui héberge les documents sources, les fragments analysés, les embeddings vectoriels, les index et les métadonnées, et qui les restitue à une latence de production à chaque requête d’inférence. Ce guide porte spécifiquement sur le stockage — ni la conception des pipelines, ni le choix du modèle d’embedding, ni le prompt engineering. Qu’exige une charge RAG de la couche de stockage ? Où les systèmes de fichiers génériques et les buckets objet à niveau unique cèdent-ils ? Et comment le socle à quatre niveaux de Scality ADI répond-il à ces exigences ? Qu’est-ce que le stockage des données RAG ? Le stockage des données RAG est le socle de stockage multicouche dans lequel une application RAG d’entreprise lit et écrit. Ce n’est ni une base de données unique ni un bucket unique. C’est un ensemble coordonné de magasins, chacun réglé pour un profil d’accès différent, qui portent ensemble le corpus à travers l’ingestion, l’indexation et la récupération. Un déploiement RAG de production maintient généralement sept magasins distincts : Archive des sources. La copie durable de chaque document ingéré, sous sa forme d’origine. Écritures par rafales lors du chargement initial, lectures froides ensuite. Magasin de fragments analysés. Les segments de texte prétraités, prêts à être encodés ou réencodés. Lectures intensives lors des reconstructions d’index. Magasin d’embeddings. La copie durable et versionnée de chaque vecteur jamais produit. Lu avec une forte dispersion par les constructeurs d’index. Index vectoriel. La structure chaude, optimisée pour la performance, qui sert les requêtes de similarité au moment de l’inférence. Index lexical. L’index par mots-clés — généralement BM25 — qui gère les entités nommées, les codes d’erreur et les termes techniques rares. Couche de métadonnées. Les lignes de provenance, de classification, de version et de contrôle d’accès associées à chaque fragment. Archive de rétention. La copie de conformité du contenu source et des embeddings historiques, conservée pendant la durée réglementaire. Chaque magasin a son propre budget de latence, son propre profil d’écriture et son propre profil de coût. Les traiter comme une seule charge de travail est l’erreur de conception de stockage la plus courante. Pourquoi le stockage des données RAG diffère du stockage IA générique Un pipeline d’entraînement lit un jeu de données, calcule des gradients, écrit des checkpoints et fonctionne par lots. Le profil de lecture est prévisible et le budget de latence se mesure en secondes. Le RAG n’est pas cette charge. Le stockage des données RAG se trouve sur le chemin critique de chaque appel d’inférence. L’étape de récupération doit renvoyer un ensemble de candidats top-k en quelques dizaines de millisecondes au 95ᵉ centile. Le corpus derrière peut compter des centaines de millions de fragments. De nouveaux documents arrivent en continu, et l’index doit les refléter sans reconstruction globale. Le même socle doit absorber un flux d’ingestion par rafales, une construction d’embeddings à forte dispersion et une charge de requêtes à faible latence — en même temps, sans que l’une affame les autres. Quatre propriétés distinguent le cas RAG du stockage IA générique : Les données vectorielles et documentaires cohabitent. Embeddings et fragments sources partagent un espace de noms et un cycle de vie, de sorte que la récupération peut renvoyer un résultat vectoriel et l’étendre immédiatement au document parent. La latence de récupération n’est pas négociable. Une récupération sous 100 ms au P95 sur un corpus d’un milliard de fragments est l’attente de base. Les fichiers d’index doivent résider sur flash ou en mémoire ; un stockage de niveau capacité sur le chemin de récupération est un mur de latence. Le versioning compte. Les modèles d’embedding changent. Les stratégies de découpage changent. Les familles d’index changent. Sans magasin d’embeddings versionné ni archive des sources versionnée, chaque changement impose une réingestion complète — l’étape la plus coûteuse du pipeline. La fraîcheur est une exigence de stockage, pas une fonctionnalité. Un système RAG qui ne se met pas à jour devient un générateur assuré de réponses obsolètes. Le socle de stockage doit absorber ingestion et requêtes concurrentes sans verrouillage, faute de quoi le retard de fraîcheur devient une obsolescence visible pour les utilisateurs. Pour une vue d’ensemble du flux, génération augmentée par récupération et stockage pour l’IA couvre la vision de bout en bout. Magasin vectoriel et magasin documentaire : le problème des deux corpus Un corpus RAG est en réalité deux corpus qui avancent de concert. Le magasin vectoriel contient les représentations denses que le moteur de récupération interroge. Le magasin documentaire contient le contenu source que le moteur renvoie et que le modèle de langage lit. La plupart des premiers déploiements RAG séparent les deux — une base vectorielle managée pour les embeddings, un partage de fichiers générique ou un bucket S3 pour les documents — et paient ce choix plus tard. Le coût apparaît à trois endroits. La latence, car chaque résultat de récupération déclenche une lecture inter-systèmes pour assembler le bloc de contexte. La cohérence, car le magasin vectoriel et le magasin documentaire se désynchronisent lorsque les documents sources évoluent plus vite que le pipeline d’embedding. La gouvernance, car les contrôles d’accès, la provenance et les journaux d’audit doivent être réconciliés entre deux systèmes aux modèles de sécurité différents. Une couche unifiée de stockage des données RAG conserve vecteurs et documents sous un même espace de noms, avec un seul modèle de contrôle d’accès, une seule piste de provenance et une seule politique de cycle de vie. La récupération étend un résultat vectoriel à son fragment et à son document parents en un seul aller-retour. Les reconstructions d’index lisent embeddings et contenu source depuis le même socle durable, sans orchestration inter-systèmes. Le stockage des bases de données vectorielles couvre les exigences côté vecteurs ; celles côté documents sont très similaires à grande échelle. Récupération à faible latence : où résident les fichiers d’index L’index vectoriel est le fichier chaud de la pile. Les graphes HNSW, les clusters IVF-PQ et les structures de graphe de type DiskANN attendent tous des lectures aléatoires à latence flash. Un graphe HNSW d’un milliard de vecteurs paginé depuis un disque rotatif transforme une requête de similarité inférieure à la milliseconde en requête de plusieurs secondes — et à grande échelle, les files de récupération lente s’accumulent en latences P99 de plusieurs secondes pour l’utilisateur final. Deux décisions de stockage façonnent la latence de récupération. D’abord, le type de support sous les fichiers d’index. Des niveaux chauds sur flash TLC avec des chemins réseau à faible latence maintiennent dans le budget les index mappés en mémoire et le parcours de graphe sur disque. DiskANN, en particulier, a été conçu pour fonctionner sur flash ; l’exécuter sur un support de niveau capacité va à l’encontre de cette famille d’index. Ensuite, le protocole entre le service de récupération et la couche de stockage. S3 over RDMA — accès direct à la mémoire à distance — ramène la latence des lectures d’objets sous les 50 µs, ce qui fait la différence entre une flash qui rivalise avec le NVMe local et une flash qui n’y parvient pas. Le niveau GPU-Direct de Scality ADI fournit ce chemin protocolaire. La même flash se trouve derrière les fichiers d’index, derrière l’index inversé lexical et derrière la couche de métadonnées qui filtre les candidats par classification, juridiction ou version. Versioning : pourquoi l’immuabilité est une exigence du RAG Les modèles d’embedding progressent. L’équipe choisit un encodeur plus performant, affine l’existant sur du contenu métier ou passe d’un modèle à 768 dimensions à un modèle à 1 024 dimensions. Chaque changement invalide l’index vectoriel existant. Sans magasin d’embeddings durable et versionné, l’équipe doit réencoder tout le corpus à partir des fragments analysés — et si les fragments eux-mêmes ont changé, à partir de l’archive des sources. À l’échelle d’une entreprise, le coût d’un réencodage complet se mesure en jours-GPU. Celui d’une réingestion depuis les sources se mesure en jours-GPU, plus le temps d’analyse du contenu, plus le risque opérationnel de rejouer l’ingestion sur des systèmes qui ont pu perdre leur historique de modifications. Une archive des sources versionnée et un magasin d’embeddings versionné ramènent ce coût à une réindexation, qui lit depuis un stockage durable avec une forte dispersion et se termine en heures plutôt qu’en jours. L’immuabilité va au-delà du versioning, jusqu’à la conformité. Dans les environnements réglementés — dossiers financiers, recherche clinique, données publiques — les documents sources doivent être conservés inaltérés pendant la durée de rétention. Object Lock et la sémantique WORM sur l’archive des sources rendent les citations auditables sur toute cette durée et protègent le corpus contre les ransomwares qui ciblent les données d’entraînement et les bases de connaissances. Le stockage des bases de données vectorielles et l’analyse plus large de l’architecture de stockage RAG approfondissent la question de l’immuabilité. Fraîcheur : comment le stockage des données RAG absorbe le changement continu Le contenu source change en permanence. Les politiques évoluent, les prix changent, des produits sont lancés, la réglementation bouge. Un index périmé transforme le modèle en générateur assuré de réponses obsolètes — précisément le mode de défaillance que le RAG devait éliminer. Trois modèles de fraîcheur dominent, et chacun impose des exigences différentes au stockage des données RAG : Réindexation planifiée. Reconstructions complètes ou incrémentales périodiques, généralement quotidiennes ou hebdomadaires. Tolère le verrouillage et les lectures de niveau capacité, mais expose un retard aux utilisateurs finaux. Ingestion par capture des changements (CDC). Les systèmes sources émettent des événements de modification ; le pipeline d’ingestion écrit directement les objets nouveaux et mis à jour dans l’archive des sources, et le découpage et l’encodage en aval suivent le flux de changements. Exige des écritures et des lectures concurrentes sur le socle sans dégrader la latence des requêtes. Fraîcheur hybride. Une surcouche en direct des changements récents coexiste avec l’index principal. La récupération consulte les deux ; la surcouche est fusionnée dans l’index principal à intervalle régulier. C’est le modèle le plus exigeant, car le chemin d’écriture de la surcouche s’exécute en même temps que le chemin de récupération, très sollicité en lecture. La CDC et la fraîcheur hybride sont les modèles vers lesquels convergent les déploiements RAG d’entreprise, car les utilisateurs ne tolèrent pas des réponses vieilles d’un jour. Le socle de stockage doit gérer ingestion et requêtes concurrentes sans contention de verrous, et la couche de métadonnées doit évoluer jusqu’à des milliards d’objets pour que les requêtes de filtrage et de récupération — « uniquement la version actuelle, uniquement cette juridiction » — restent rapides à mesure que le corpus grandit. Comment Scality ADI répond aux exigences du stockage des données RAG Scality ADI (Autonomous Data Infrastructure) est une infrastructure de données pour l’IA d’entreprise, la cyber-résilience et le contrôle souverain, qui aligne de manière autonome et durable les bons supports de stockage, de l’échelle multi-pétaoctet à l’exaoctet. Le socle à quatre niveaux de Scality ADI correspond directement aux sept magasins d’un déploiement RAG de production. Magasin RAGProfil d’accèsNiveau Scality ADIArchive des sourcesÉcritures par rafales, lectures froidesWarm (NL-SSD / HDD) et Cold (bande)Magasin de fragments analysésLectures intensives lors des reconstructionsWarmMagasin d’embeddingsLectures à forte concurrence lors des reconstructionsHot (QLC / NL-SSD)Index vectorielLectures aléatoires, sous la millisecondeGPU-Direct (TLC + S3 over RDMA)Index lexicalLectures aléatoires, majoritairement en cacheGPU-DirectCouche de métadonnéesFiltrage et récupération à la requêteGPU-DirectArchive de rétentionLectures rares, conservation réglementaireCold Plusieurs capacités de Scality ADI répondent directement aux exigences ci-dessus : Niveau GPU-Direct avec S3 over RDMA. Une latence inférieure à 50 µs sur flash TLC maintient dans le budget de récupération les lectures d’index vectoriel, le parcours de graphe sur disque des index de type DiskANN et les recherches dans l’index lexical. Un espace de noms unique sur les quatre niveaux. Documents sources, fragments analysés et embeddings persistés résident dans un même espace de noms compatible S3 : les résultats vectoriels s’étendent aux documents parents en un seul aller-retour, et les outils existants — retrievers LangChain, LlamaIndex, bases vectorielles — se connectent via la surface standard de compatibilité de l’API S3. Cyber-résilience CORE5. Immuabilité, erasure coding, protection des métadonnées, durabilité multisite et cycle de vie piloté par des politiques garantissent de manière démontrable l’intégrité de l’archive des sources. Les citations restent auditables sur toute la durée de rétention. Cycle de vie multi-température sans tickets d’exploitation. Les embeddings et index chauds restent sur flash. Les fragments analysés tièdes sont rétrogradés selon les politiques. Les versions froides de l’archive des sources atterrissent sur bande. Promotion et rétrogradation se font par politique, et non par déplacement manuel des données. Des métadonnées au niveau objet à grande échelle. Des milliards de fragments produisent des milliards de lignes de métadonnées. La couche de métadonnées maintient la rapidité des requêtes de filtrage et de récupération à mesure que le corpus grandit. Des agents Guardian pour des opérations autonomes. Les recommandations d’extension, de rééquilibrage et de hiérarchisation sont formulées dans le cadre des politiques définies par le client, l’exécution étant validée par des humains. Un corpus RAG qui passe d’un à dix milliards de fragments n’oblige pas l’équipe d’exploitation à grandir au même rythme. Scality ADI ne remplace pas le travail de conception d’un système RAG. La stratégie de découpage, le choix du modèle d’embedding, la famille d’index et le modèle de fraîcheur restent du ressort de l’équipe qui construit la couche de récupération. Scality ADI supprime les contraintes au niveau du socle — enfermement dans un niveau unique, services de métadonnées qui cèdent au milliard de lignes, contention de verrous sous ingestion et requêtes concurrentes — qui obligent les équipes à transiger sur ces choix. Découvrez comment Scality ADI prend en charge le stockage des données RAG pour l’IA d’entreprise Questions fréquentes Qu’est-ce que le stockage des données RAG ? Le stockage des données RAG est le socle de stockage multicouche qui soutient une application de génération augmentée par récupération. Il porte l’archive des sources, le magasin de fragments analysés, le magasin d’embeddings, l’index vectoriel, l’index lexical, la couche de métadonnées et l’archive de rétention. Chaque couche a son propre profil d’accès et son propre budget de latence, et toutes doivent fonctionner ensemble sur le chemin critique de chaque appel d’inférence. En quoi le stockage des données RAG diffère-t-il du stockage pour l’entraînement IA ? Le stockage d’entraînement est orienté lots, avec des lectures prévisibles et des budgets de latence mesurés en secondes. Le stockage des données RAG se trouve sur le chemin critique de l’inférence, avec des attentes de récupération sous 100 ms sur des corpus d’un milliard de fragments et des charges concurrentes d’ingestion, d’encodage et de requêtes sur le même socle. Faut-il unifier magasins vectoriels et magasins documentaires ? En production, oui. Les séparer crée une latence inter-systèmes à chaque récupération, une dérive entre vecteurs et documents sources à mesure que le contenu évolue, et une gouvernance éclatée entre deux modèles de sécurité. Un espace de noms unifié sous un seul modèle de contrôle d’accès maintient la cohérence de la récupération, de la fraîcheur et de l’audit. Pourquoi le stockage des données RAG a-t-il besoin du versioning ? Les modèles d’embedding, les stratégies de découpage et les familles d’index changent. Sans magasin d’embeddings versionné ni archive des sources versionnée, chaque changement impose un réencodage — voire une réingestion complète — qui coûte des jours-GPU à l’échelle de l’entreprise. Le versioning transforme ces événements en réindexations mesurées en heures. Quelle latence la récupération RAG exige-t-elle ? Les déploiements de production visent moins de 100 ms au 95ᵉ centile pour l’étape de récupération et de classement sur un corpus d’un milliard de fragments. Ce budget impose de placer l’index vectoriel, l’index lexical et la couche de métadonnées sur flash avec un chemin protocolaire à faible latence — S3 over RDMA à la pointe — et exclut les supports de niveau capacité sur le chemin de récupération. Pour aller plus loin Génération augmentée par récupération et stockage pour l’IA Architecture de stockage RAG Stockage des bases de données vectorielles Infrastructure de stockage pour l’IA agentique Stockage des pipelines d’entraînement IA Stockage GPU-direct Indexation des métadonnées du stockage objet Conclusion Le stockage des données RAG ne se définit ni par la base vectorielle qui héberge les embeddings, ni par le bucket objet qui héberge les documents sources. Il se définit par la fluidité avec laquelle les sept magasins fonctionnent ensemble sur le chemin critique de chaque appel d’inférence, et par la capacité du socle sous-jacent à porter côte à côte données vectorielles et documentaires, à servir la récupération sous 100 ms, à versionner embeddings et contenu source au fil des changements de modèle, et à absorber des écritures de fraîcheur continues sans dégrader les requêtes. Avec le bon socle, la couche de récupération au-dessus a toute latitude pour être performante. Avec le mauvais, aucun prompt engineering ne comblera l’écart.
