5 La meilleure architecture de stockage pour la génération augmentée par récupération (RAG) est généralement une architecture en couches qui associe un stockage objet pour le jeu de données de référence à des bases de données et des index optimisés pour la récupération. On parle souvent du RAG comme si le stockage commençait et s’arrêtait à la base de données vectorielle. Ce n’est pas le cas. Un système RAG en production peut devoir conserver des millions ou des milliards d’objets sources, du texte extrait, des embeddings, des métadonnées, des index, des artefacts de modèles et des versions continuellement mises à jour de ces données. Chaque élément a des exigences différentes. Pour le RAG d’entreprise, l’architecture de stockage doit donc remplir deux missions distinctes : garder le corpus de connaissances sous-jacent durable, évolutif et gouvernable, et rendre rapide la récupération des parties pertinentes de ce corpus lors de l’inférence. Cette distinction prend de l’importance à mesure que le RAG passe de petites expérimentations à des systèmes de connaissances d’entreprise contenant des centaines de téraoctets, voire des pétaoctets, de données non structurées. La réponse courte : utiliser le stockage objet comme socle de données Une bonne architecture de stockage pour le RAG ressemble généralement à ceci : Données sources → stockage objet → traitement des données → embeddings/index → couche de récupération → LLM Le stockage objet sert de socle de données durable. Il peut contenir des documents, des images, des vidéos, de l’audio, des journaux, des jeux de données, du contenu extrait et d’autres informations non structurées utilisées par le pipeline RAG. Une base de données vectorielle, un moteur de recherche ou un autre système de récupération maintient ensuite les structures nécessaires pour localiser rapidement les informations pertinentes. Cette séparation compte, car une base de données vectorielle est conçue avant tout pour trouver l’information, tandis que le système de stockage sous-jacent est chargé de conserver et gérer l’information elle-même. Dans les grands environnements d’entreprise, demander à un seul système de jouer les deux rôles peut créer des problèmes inutiles de coût, d’évolutivité et de gouvernance. Pourquoi le stockage du RAG diffère du stockage applicatif classique Les applications traditionnelles manipulent souvent des enregistrements relativement structurés avec des profils d’accès prévisibles. Les systèmes RAG fonctionnent autrement. Un corpus de connaissances d’entreprise type peut contenir : des PDF et des documents Office des e-mails et des articles de base de connaissances des images, de l’audio et de la vidéo des journaux applicatifs et machines des jeux de données de recherche du code source de la documentation produit des documents métier archivés des données de capteurs et d’IoT du contenu déjà généré par l’IA L’essentiel de ces informations est non structuré ou semi-structuré. Le pipeline RAG doit ingérer le matériau source, en extraire ou en transformer le contenu, découper l’information en unités exploitables, générer des embeddings ou d’autres représentations pour la récupération, associer des métadonnées et rendre l’information obtenue consultable. Dans le même temps, le matériau source d’origine doit souvent rester disponible. Cela crée plusieurs exigences de stockage au lieu d’une seule. Les quatre couches de stockage d’une architecture RAG Une façon utile d’aborder le stockage du RAG est de le considérer comme quatre couches logiques. 1. Le stockage des données sources C’est le corpus de référence dont le système RAG tire ses connaissances. La couche source peut contenir d’énormes quantités d’informations non structurées et tire généralement parti d’un stockage qui offre : une grande capacité une forte durabilité une évolutivité horizontale des métadonnées riches un accès parallèle la compatibilité S3 la gestion du cycle de vie la sécurité et les contrôles d’accès Le stockage objet convient particulièrement à ce rôle, car il a été conçu pour gérer de grandes collections de données non structurées sans exiger de système de fichiers hiérarchique traditionnel. Le corpus source a aussi tendance à croître en continu. Une application RAG peut démarrer avec quelques téraoctets de documents, puis intégrer des années d’informations historiques, des ressources multimédias, des données applicatives et d’autres référentiels de l’entreprise. L’architecture doit donc être conçue en fonction du corpus attendu à long terme, et pas seulement de la taille du projet RAG initial. 2. Le stockage du traitement et des données intermédiaires Avant de devenir consultable, l’information passe généralement par un pipeline d’ingestion. Selon la charge de travail, ce processus peut produire du texte extrait, des documents normalisés, des fragments (chunks), des métadonnées, des jeux de données temporaires et d’autres objets intermédiaires. Séparer ces artefacts du corpus d’origine peut faciliter la réexécution et le dépannage des pipelines. Cela évite aussi aux équipes de répéter des transformations coûteuses sur les mêmes données sources. Le stockage objet peut là encore être utile, car les jeux de données intermédiaires peuvent devenir étonnamment volumineux à grande échelle. 3. Le stockage des embeddings et de la récupération C’est ici que la base de données vectorielle, l’index de recherche ou une autre technologie de récupération entre dans l’architecture. Les embeddings représentent l’information sous forme mathématique afin qu’un système de récupération puisse identifier le contenu lié à une requête. Les bases de données vectorielles sont conçues pour effectuer ces recherches efficacement. Mais les embeddings ne constituent pas forcément la copie de référence de l’information d’entreprise. Ils en sont dérivés. Cette distinction a des conséquences sur l’architecture. Si un modèle d’embedding change, si les stratégies de découpage sont modifiées ou si les métadonnées doivent être reconstruites, les organisations peuvent devoir régénérer une grande partie de la couche de récupération. Garder les jeux de données d’origine et traités disponibles de manière indépendante rend cela possible sans reconstituer le corpus de connaissances à partir de systèmes externes. 4. Le stockage des modèles et du pipeline d’IA L’infrastructure RAG peut aussi produire ou consommer des fichiers de modèles, des points de contrôle, des jeux de données d’évaluation, des bibliothèques de prompts et d’autres artefacts d’IA. Certains de ces jeux de données exigent des performances très élevées. D’autres ont besoin d’une conservation à long terme peu coûteuse. Il en résulte souvent une architecture de données d’IA plus large, dans laquelle différentes technologies de stockage servent différentes étapes du pipeline. L’objectif n’est pas d’imposer à chaque charge de travail le stockage le plus rapide disponible, mais de fournir les performances adaptées là où elles apportent un bénéfice mesurable. Pourquoi le stockage objet convient bien au RAG Le stockage objet présente plusieurs caractéristiques particulièrement en phase avec le RAG d’entreprise. Il évolue avec le corpus de connaissances Les systèmes RAG deviennent plus utiles à mesure qu’ils accèdent à davantage d’informations pertinentes. La capacité de stockage peut ainsi devenir une question d’architecture à long terme. Un assistant départemental peut fonctionner sur un référentiel documentaire relativement petit. Une plateforme RAG d’entreprise pourrait finir par indexer les informations de dizaines d’applications et d’entités. Le stockage objet est conçu pour évoluer horizontalement sur de très grands jeux de données, ce qui le rend adapté à des référentiels de connaissances susceptibles de passer de quelques téraoctets à des pétaoctets. Il gère naturellement les données non structurées Les informations sources du RAG entrent rarement proprement dans des tables de base de données. Le stockage objet peut conserver des fichiers et d’autres objets de données avec leurs métadonnées sans imposer de schéma rigide à l’ensemble du référentiel. Différents pipelines d’IA peuvent ainsi traiter la même information sous-jacente de différentes manières. Un document peut servir aujourd’hui à une application de recherche sémantique et devenir plus tard des données d’entraînement ou d’évaluation pour un autre système d’IA. Il sépare les données durables des index temporaires Les index changent. Les modèles d’embedding s’améliorent. Les stratégies de découpage évoluent. Les algorithmes de récupération changent. De nouvelles applications peuvent exiger des représentations différentes des mêmes données. L’information d’entreprise sous-jacente ne devrait pas avoir à être déplacée chaque fois que la technologie de récupération change. Utiliser un stockage objet évolutif comme couche de données durable donne aux organisations un socle relativement stable sous une pile logicielle d’IA qui évolue plus vite. Il prend en charge l’accès parallèle aux données Les pipelines d’IA doivent souvent traiter simultanément un grand nombre d’objets. Plusieurs workers peuvent extraire des documents, générer des embeddings ou enrichir des métadonnées en parallèle. Les architectures de stockage objet peuvent fournir un débit agrégé considérable lorsque de nombreux clients accèdent simultanément au référentiel. Cette caractéristique prend de l’importance à mesure que les pipelines d’ingestion s’étendent. Le RAG exige-t-il un stockage full flash ? Pas nécessairement. Les performances du RAG sont souvent associées à l’infrastructure GPU, ce qui peut amener les équipes à penser que tout le jeu de données RAG doit résider sur un stockage flash haute performance. Le chemin de récupération doit effectivement être assez rapide pour que l’inférence reste réactive. Les index vectoriels, les données fréquemment consultées et les jeux de travail sensibles à la latence peuvent donc tirer parti de la flash ou d’un autre stockage haute performance. Mais le corpus de connaissances complet peut être bien plus vaste que les données réellement sollicitées lors d’une opération de récupération donnée. Prenons un environnement RAG contenant des centaines de téraoctets de documents historiques. Seule une infime fraction de ces documents peut être pertinente pour un prompt donné. Conserver tout le corpus sur de la flash haut de gamme peut augmenter les coûts d’infrastructure sans améliorer proportionnellement la latence des requêtes. Une meilleure architecture place un stockage haute performance autour du jeu de travail de récupération et utilise un stockage objet évolutif pour le corpus persistant, bien plus volumineux. Faut-il utiliser une base de données vectorielle ou un stockage objet pour le RAG ? Dans de nombreuses architectures, on utilise les deux. Ils résolvent des problèmes différents. ExigenceStockage objetBase de données vectorielleStocker les documents d’origineExcellentPas sa vocation premièreStocker des jeux de données non structurées massifsExcellentLimité par conception et par son coûtRecherche par similarité sémantiquePas sa vocation premièreExcellentStocker des embeddingsPossibleExcellentConservation des données à long termeExcellentPas sa vocation premièreAccès applicatif S3ExcellentVariableIndexation pour la récupérationLimitéExcellentReconstruire les index à partir des données sourcesSocle idéalDépend de la disponibilité des sources La base de données vectorielle fait partie de l’infrastructure de récupération. Le stockage objet fait partie de l’infrastructure de données. Les considérer comme concurrents, c’est mal comprendre le rôle de chacun. Et le stockage de fichiers pour le RAG ? Le stockage de fichiers peut encore jouer un rôle important. Certains frameworks et applications d’IA attendent un accès POSIX ou fondé sur des fichiers. Les systèmes de fichiers haute performance peuvent aussi être précieux lorsque les charges impliquent un grand nombre de petits fichiers, un calcul étroitement couplé ou des profils d’accès HPC et GPU spécifiques. Les architectures RAG d’entreprise n’ont pas à choisir exclusivement entre protocoles fichier et objet. Une architecture de données plus large peut exposer les données via différentes méthodes d’accès selon l’application, tout en conservant un socle de stockage évolutif commun lorsque c’est pertinent. Le choix doit être guidé par les profils d’accès des applications plutôt que par l’hypothèse que toutes les charges d’IA exigent le même protocole. Une architecture de stockage RAG d’entreprise concrète Pour un déploiement en grande entreprise, l’architecture pourrait fonctionner ainsi. Étape 1 : consolider le corpus de connaissances Les documents et autres jeux de données sources sont rassemblés depuis les systèmes de l’entreprise dans un stockage évolutif. L’information d’origine reste disponible comme source de référence pour les traitements futurs. Étape 2 : traiter et enrichir les données Un pipeline d’ingestion extrait le contenu, le nettoie, applique des métadonnées et le découpe en fragments adaptés à la récupération. Les résultats du traitement peuvent aussi être conservés afin que les étapes suivantes n’aient pas à répéter chaque transformation. Étape 3 : générer les embeddings Une infrastructure GPU ou CPU convertit les fragments en embeddings à l’aide du modèle d’embedding choisi par l’organisation. Ces embeddings sont chargés dans le système de récupération. Étape 4 : construire la couche de récupération Une base de données vectorielle ou une plateforme de recherche indexe les embeddings et les métadonnées associées. Cette couche est optimisée pour des requêtes à faible latence plutôt que pour la conservation en masse de tout le corpus source. Étape 5 : récupérer le contexte pertinent Lorsqu’un utilisateur envoie un prompt, l’application interroge la couche de récupération pour trouver les informations pertinentes. Le système peut alors récupérer le contexte nécessaire et le fournir au LLM. Étape 6 : préserver les données sous-jacentes Les données sources et traitées restent disponibles de manière indépendante. Si l’organisation change de modèle d’embedding, de moteur de récupération ou d’application d’IA, elle peut retraiter le corpus sans réacquérir toute l’information d’origine. C’est l’un des principaux avantages architecturaux de la séparation entre couche de données et couche de récupération. Que rechercher dans un stockage pour le RAG ? La meilleure architecture dépend de la taille de la charge et des profils d’accès, mais les équipes d’entreprise doivent évaluer plusieurs caractéristiques. Évolutivité Estimez la taille de l’ensemble du patrimoine de données d’IA, et pas seulement celle du premier index vectoriel. Incluez les documents sources, les données traitées, les versions multiples, les métadonnées, les artefacts de modèles et la croissance future attendue. Débit L’ingestion RAG peut impliquer des milliers d’opérations de traitement simultanées. Le débit agrégé peut donc compter autant que la latence de chaque requête. Capacités de métadonnées Les métadonnées sont au cœur de la récupération. Les autorisations, horodatages, types de documents, classifications métier et autres attributs peuvent aider à restreindre les recherches et à améliorer la pertinence. L’architecture de stockage doit préserver les métadonnées utiles plutôt que de priver l’information sous-jacente de son contexte. Protection des données Une base de connaissances RAG peut contenir certaines des informations les plus précieuses d’une organisation. Le stockage doit donc offrir les mécanismes adaptés de chiffrement, de contrôle d’accès, d’immuabilité, de réplication et de reprise. Protéger l’application d’IA sans protéger le corpus de connaissances sous-jacent laisse une faille importante. Souveraineté des données Le RAG d’entreprise intègre souvent des informations internes sensibles. Les organisations peuvent devoir maîtriser l’endroit où résident ces informations, qui peut y accéder et quelle infrastructure les traite. Un stockage objet sur site ou en cloud privé peut aider les organisations à construire des systèmes RAG tout en gardant le contrôle de l’emplacement physique et administratif de leurs jeux de données. Compatibilité S3 S3 est devenu une interface largement prise en charge dans les écosystèmes de données et d’IA. Un stockage compatible S3 peut faciliter la connexion des pipelines de données, des outils d’analytique, des frameworks d’IA et d’autres applications à un référentiel de données commun, sans concevoir d’intégrations de stockage sur mesure pour chaque charge de travail. La place de Scality dans une architecture de stockage RAG Scality RING fournit un stockage fichier et objet évolutif pour les grands jeux de données non structurées, ce qui le rend pertinent comme couche de données persistante sous les environnements d’IA et de RAG d’entreprise. Dans le cadre de la stratégie plus large d’Autonomous Data Infrastructure (ADI) de Scality, l’objectif est de fournir une infrastructure capable de prendre en charge de grands jeux de données d’IA tout en répondant aux exigences d’évolutivité, de cyber-résilience et de contrôle souverain. Pour le RAG, ce rôle porte avant tout sur le socle de données. RING peut conserver les documents sources, les jeux de données et les informations dérivées qui alimentent les pipelines d’IA, tandis que des technologies de récupération comme les bases de données vectorielles assurent la recherche sémantique spécialisée. Les entreprises peuvent ainsi faire évoluer les modèles d’embedding, les moteurs de récupération et les applications d’IA sans faire de ces systèmes l’unique référentiel des connaissances sous-jacentes. Pour les organisations qui construisent du RAG sur de grands patrimoines de données existants, cette séparation peut prendre de plus en plus de valeur à mesure que le corpus et le nombre d’applications d’IA augmentent. La meilleure architecture de stockage RAG est en couches Aucune technologie de stockage n’accomplit de façon optimale toutes les tâches d’un pipeline RAG. L’architecture la plus pragmatique sépare les responsabilités : Le stockage objet fournit le socle évolutif et durable du corpus de connaissances. L’infrastructure de traitement transforme et enrichit les données. Les bases de données vectorielles et les moteurs de recherche assurent une récupération rapide. Le stockage haute performance peut accélérer les jeux de travail sensibles à la latence lorsque c’est nécessaire. Cette approche en couches évite que le système de récupération ne devienne le référentiel de données à long terme et que tout le corpus de l’entreprise ne doive résider sur le niveau de stockage le plus coûteux. Pour les petites applications RAG, cette distinction compte peu. Pour les déploiements d’entreprise portant sur des pétaoctets de données non structurées, elle peut déterminer si l’architecture reste maîtrisable à mesure que le système grandit. FAQ Quel est le meilleur stockage pour le RAG ? Le stockage objet est un bon choix pour la couche de données persistante du RAG, car il peut évoluer jusqu’à de grands jeux de données non structurées tout en offrant durabilité, métadonnées et large compatibilité S3. Des bases de données vectorielles ou des index de recherche peuvent ensuite fournir la couche de récupération spécialisée. Le RAG a-t-il besoin d’une base de données vectorielle ? Le RAG exige un mécanisme pour récupérer les informations pertinentes, mais il ne s’agit pas toujours d’une base de données vectorielle dédiée. Les systèmes peuvent utiliser la recherche vectorielle, la recherche par mots-clés, la recherche hybride, des graphes de connaissances ou une combinaison de ces approches selon l’application. Le RAG peut-il utiliser un stockage objet compatible S3 ? Oui. Un stockage objet compatible S3 peut contenir les documents sources, les jeux de données traités et d’autres artefacts d’IA tout en s’intégrant aux outils de traitement de données et d’IA qui prennent en charge l’API S3. Le stockage objet est-il assez rapide pour le RAG ? Cela dépend de sa place dans l’architecture. Le stockage objet n’a pas à remplacer l’index vectoriel à faible latence. Il peut fournir un débit agrégé élevé pour l’ingestion et un stockage durable pour le corpus de connaissances, bien plus volumineux, tandis qu’une infrastructure de récupération spécialisée gère les recherches sensibles à la latence. De combien de stockage un système RAG a-t-il besoin ? Les besoins dépendent de la taille du corpus source, du nombre de copies traitées, de la stratégie d’embedding, des métadonnées, des index et des exigences de conservation. Les entreprises doivent planifier l’ensemble du cycle de vie des données d’IA plutôt que d’estimer la capacité uniquement d’après la taille de la base de données vectorielle. Faut-il stocker les données RAG sur site ou dans le cloud ? Les deux sont viables. La décision dépend de la gravité des données, de l’économie, de la sécurité, de la souveraineté et de l’endroit où s’exécute le calcul d’IA. Les organisations qui disposent de jeux de données d’entreprise très volumineux ou sensibles peuvent préférer une infrastructure privée ou sur site, tandis que d’autres charges peuvent tirer parti des services du cloud public.
