6 Die beste Speicherarchitektur für Retrieval-Augmented Generation (RAG) ist meist eine Schichtarchitektur, die Objektspeicher für den maßgeblichen Datenbestand mit Datenbanken und Indizes kombiniert, die für das Retrieval optimiert sind. RAG wird oft so diskutiert, als beginne und ende der Speicher bei einer Vektordatenbank. Das ist nicht so. Ein produktives RAG-System muss womöglich Millionen oder Milliarden Quellobjekte, extrahierten Text, Embeddings, Metadaten, Indizes, Modellartefakte und laufend aktualisierte Versionen dieser Daten vorhalten. Jeder Teil hat andere Anforderungen. Für RAG im Unternehmen muss die Speicherarchitektur daher zwei unterschiedliche Aufgaben erfüllen: den zugrunde liegenden Wissenskorpus langlebig, skalierbar und steuerbar halten und die relevanten Teile dieses Korpus während der Inferenz schnell abrufbar machen. Diese Unterscheidung wird immer wichtiger, je mehr sich RAG von kleinen Experimenten zu Wissenssystemen im Unternehmen mit Hunderten Terabyte oder Petabyte unstrukturierter Daten entwickelt. Die kurze Antwort: Objektspeicher als Datengrundlage nutzen Eine starke Speicherarchitektur für RAG sieht typischerweise so aus: Quelldaten → Objektspeicher → Datenverarbeitung → Embeddings/Indizes → Retrieval-Schicht → LLM Objektspeicher dient als dauerhafte Datengrundlage. Er kann Dokumente, Bilder, Videos, Audio, Logs, Datensätze, extrahierte Inhalte und andere unstrukturierte Informationen vorhalten, die die RAG-Pipeline nutzt. Eine Vektordatenbank, eine Suchmaschine oder ein anderes Retrieval-System pflegt dann die Strukturen, die nötig sind, um relevante Informationen schnell zu finden. Diese Trennung ist wichtig, weil eine Vektordatenbank in erster Linie dafür ausgelegt ist, Informationen zu finden, während das zugrunde liegende Speichersystem dafür zuständig ist, die Informationen selbst vorzuhalten und zu verwalten. In großen Unternehmensumgebungen kann es unnötige Probleme bei Kosten, Skalierung und Governance verursachen, wenn ein einziges System beide Rollen übernehmen soll. Warum Speicher für RAG sich von gewöhnlichem Anwendungsspeicher unterscheidet Klassische Anwendungen arbeiten oft mit relativ strukturierten Datensätzen und vorhersehbaren Zugriffsmustern. RAG-Systeme funktionieren anders. Ein typischer Wissenskorpus im Unternehmen kann enthalten: PDFs und Office-Dokumente E-Mails und Wissensdatenbank-Artikel Bilder, Audio und Video Anwendungs- und Maschinenlogs Forschungsdatensätze Quellcode Produktdokumentation Archivierte Geschäftsunterlagen Sensor- und IoT-Daten Zuvor generierte KI-Inhalte Die meisten dieser Informationen sind unstrukturiert oder halbstrukturiert. Die RAG-Pipeline muss das Quellmaterial aufnehmen, seine Inhalte extrahieren oder umwandeln, Informationen in nutzbare Einheiten aufteilen, Embeddings oder andere Retrieval-Repräsentationen erzeugen, Metadaten zuordnen und die Ergebnisse durchsuchbar machen. Gleichzeitig muss das ursprüngliche Quellmaterial oft verfügbar bleiben. Daraus ergeben sich mehrere Speicheranforderungen statt einer. Die vier Speicherschichten einer RAG-Architektur Hilfreich ist es, Speicher für RAG als vier logische Schichten zu betrachten. 1. Speicher für Quelldaten Das ist der maßgebliche Korpus, aus dem das RAG-System sein Wissen bezieht. Die Quellschicht kann enorme Mengen unstrukturierter Informationen enthalten und profitiert in der Regel von Speicher, der Folgendes bietet: Hohe Kapazität Hohe Langlebigkeit Horizontale Skalierbarkeit Umfangreiche Metadaten Parallelen Zugriff S3-Kompatibilität Lifecycle-Management Sicherheit und Zugriffskontrollen Objektspeicher eignet sich für diese Rolle besonders gut, weil er dafür entwickelt wurde, große Sammlungen unstrukturierter Daten ohne klassisches hierarchisches Dateisystem zu verwalten. Der Quellkorpus wächst zudem meist kontinuierlich. Eine RAG-Anwendung beginnt vielleicht mit einigen Terabyte an Dokumenten, bezieht aber irgendwann jahrelang gesammelte historische Informationen, Multimedia-Assets, Anwendungsdaten und weitere Unternehmens-Repositories ein. Die Architektur sollte daher auf den langfristig erwarteten Korpus ausgelegt sein und nicht nur auf die Größe des ersten RAG-Projekts. 2. Speicher für Verarbeitung und Zwischenergebnisse Bevor Informationen durchsuchbar werden, durchlaufen sie meist eine Ingestion-Pipeline. Je nach Workload entstehen dabei extrahierter Text, normalisierte Dokumente, Chunks, Metadaten, temporäre Datensätze und andere Zwischenobjekte. Diese Artefakte getrennt vom ursprünglichen Korpus zu halten, erleichtert es, Pipelines erneut auszuführen und Fehler zu beheben. Zudem müssen Teams aufwendige Transformationen nicht immer wieder auf dieselben Quelldaten anwenden. Auch hier kann Objektspeicher hilfreich sein, weil Zwischendatensätze im großen Maßstab überraschend umfangreich werden können. 3. Speicher für Embeddings und Retrieval Hier kommen Vektordatenbank, Suchindex oder eine andere Retrieval-Technologie in die Architektur. Embeddings stellen Informationen mathematisch dar, sodass ein Retrieval-System Inhalte erkennen kann, die zu einer Anfrage passen. Vektordatenbanken sind darauf ausgelegt, diese Suchen effizient durchzuführen. Doch Embeddings sind nicht unbedingt die maßgebliche Kopie der Unternehmensinformationen. Sie sind daraus abgeleitet. Diese Unterscheidung wirkt sich auf die Architektur aus. Ändert sich ein Embedding-Modell, werden Chunking-Strategien angepasst oder müssen Metadaten neu aufgebaut werden, müssen Organisationen womöglich große Teile der Retrieval-Schicht neu erzeugen. Wenn die ursprünglichen und verarbeiteten Datensätze unabhängig verfügbar bleiben, ist das möglich, ohne den Wissenskorpus aus externen Systemen neu aufzubauen. 4. Speicher für Modelle und KI-Pipelines RAG-Infrastruktur kann zudem Modelldateien, Checkpoints, Evaluierungsdatensätze, Prompt-Bibliotheken und andere KI-Artefakte erzeugen oder nutzen. Manche dieser Datensätze erfordern sehr hohe Leistung. Andere brauchen günstige Langzeitaufbewahrung. Das Ergebnis ist oft eine umfassendere KI-Datenarchitektur, in der unterschiedliche Speichertechnologien unterschiedliche Phasen der Pipeline bedienen. Ziel ist nicht, jeden Workload auf den schnellsten verfügbaren Speicher zu zwingen. Ziel ist, die passende Leistung dort bereitzustellen, wo sie einen messbaren Nutzen bringt. Warum Objektspeicher gut zu RAG passt Objektspeicher hat mehrere Eigenschaften, die besonders gut zu RAG im Unternehmen passen. Er skaliert mit dem Wissenskorpus RAG-Systeme werden nützlicher, je mehr relevante Informationen sie erschließen. Dadurch kann die Speicherkapazität zu einer langfristigen Architekturfrage werden. Ein Assistent für eine Abteilung arbeitet vielleicht mit einem relativ kleinen Dokumenten-Repository. Eine unternehmensweite RAG-Plattform könnte irgendwann Informationen aus Dutzenden Anwendungen und Geschäftsbereichen indexieren. Objektspeicher ist darauf ausgelegt, über sehr große Datensätze horizontal zu skalieren, und eignet sich daher für Wissens-Repositories, die von Terabyte in Richtung Petabyte wachsen können. Er verarbeitet unstrukturierte Daten auf natürliche Weise Quellinformationen für RAG passen selten sauber in Datenbanktabellen. Objektspeicher kann Dateien und andere Datenobjekte zusammen mit Metadaten vorhalten, ohne dem gesamten Repository ein starres Schema aufzuzwingen. So können verschiedene KI-Pipelines dieselben zugrunde liegenden Informationen auf unterschiedliche Weise verarbeiten. Ein Dokument kann heute von einer Anwendung für semantische Suche genutzt werden und später zu Trainings- oder Evaluierungsdaten für ein anderes KI-System werden. Er trennt dauerhafte Daten von temporären Indizes Indizes ändern sich. Embedding-Modelle werden besser. Chunking-Strategien entwickeln sich weiter. Retrieval-Algorithmen ändern sich. Neue Anwendungen benötigen womöglich andere Repräsentationen derselben Daten. Die zugrunde liegenden Unternehmensinformationen sollten nicht jedes Mal umziehen müssen, wenn sich die Retrieval-Technologie ändert. Skalierbarer Objektspeicher als dauerhafte Datenschicht gibt Organisationen eine relativ stabile Grundlage unter einem sich schneller verändernden KI-Software-Stack. Er unterstützt parallelen Datenzugriff KI-Pipelines müssen oft große Mengen an Objekten gleichzeitig verarbeiten. Mehrere Worker extrahieren womöglich parallel Dokumente, erzeugen Embeddings oder reichern Metadaten an. Objektspeicherarchitekturen können erheblichen aggregierten Durchsatz liefern, wenn viele Clients gleichzeitig auf das Repository zugreifen. Diese Eigenschaft wird mit wachsenden Ingestion-Pipelines immer wichtiger. Braucht RAG All-Flash-Speicher? Nicht unbedingt. Die Leistung von RAG wird häufig mit GPU-Infrastruktur verbunden, was Teams zu der Annahme verleiten kann, der gesamte RAG-Datensatz gehöre auf leistungsstarken Flash-Speicher. Der Retrieval-Pfad muss schnell genug sein, damit die Inferenz reaktionsschnell bleibt. Vektorindizes, häufig genutzte Daten und latenzempfindliche Arbeitsdatensätze können daher von Flash oder anderem Hochleistungsspeicher profitieren. Doch der vollständige Wissenskorpus kann weit größer sein als die Daten, die an einem einzelnen Retrieval-Vorgang aktiv beteiligt sind. Nehmen wir eine RAG-Umgebung mit Hunderten Terabyte historischer Dokumente. Für einen bestimmten Prompt ist womöglich nur ein winziger Bruchteil davon relevant. Den gesamten Korpus auf Premium-Flash vorzuhalten, kann die Infrastrukturkosten erhöhen, ohne die Abfragelatenz proportional zu verbessern. Eine bessere Architektur platziert Hochleistungsspeicher rund um den Arbeitsdatensatz des Retrievals und nutzt skalierbaren Objektspeicher für den weit größeren persistenten Korpus. Vektordatenbank oder Objektspeicher für RAG? In vielen Architekturen nutzt man beides. Sie lösen unterschiedliche Probleme. AnforderungObjektspeicherVektordatenbankOriginaldokumente speichernSehr gutNicht der HauptzweckRiesige unstrukturierte Datensätze speichernSehr gutDurch Design und Kosten begrenztSemantische ÄhnlichkeitssucheNicht der HauptzweckSehr gutEmbeddings speichernMöglichSehr gutLangzeitaufbewahrung von DatenSehr gutNicht der HauptzweckAnwendungszugriff über S3Sehr gutUnterschiedlichIndexierung für das RetrievalBegrenztSehr gutIndizes aus Quelldaten neu aufbauenSehr gute GrundlageHängt von der Verfügbarkeit der Quelldaten ab Die Vektordatenbank ist Teil der Retrieval-Infrastruktur. Objektspeicher ist Teil der Dateninfrastruktur. Wer die beiden als Konkurrenten betrachtet, verkennt die Rolle, die jede spielt. Und Dateispeicher für RAG? Dateispeicher kann weiterhin eine wichtige Rolle spielen. Manche KI-Frameworks und Anwendungen erwarten POSIX- oder dateibasierten Zugriff. Hochleistungs-Dateisysteme können zudem wertvoll sein, wenn Workloads sehr viele kleine Dateien, eng gekoppelte Rechenleistung oder bestimmte HPC- und GPU-Zugriffsmuster umfassen. RAG-Architekturen im Unternehmen müssen sich nicht ausschließlich zwischen Datei- und Objektprotokollen entscheiden. Eine umfassendere Datenarchitektur kann Daten je nach Anwendung über verschiedene Zugriffsmethoden bereitstellen und dabei, wo sinnvoll, eine gemeinsame skalierbare Speichergrundlage beibehalten. Die Entscheidung sollte sich an den Zugriffsmustern der Anwendungen orientieren und nicht an der Annahme, jeder KI-Workload brauche dasselbe Protokoll. Eine praxistaugliche Speicherarchitektur für RAG im Unternehmen Bei einer Bereitstellung in einem Großunternehmen könnte die Architektur folgendermaßen funktionieren. Schritt 1: Den Wissenskorpus konsolidieren Dokumente und andere Quelldatensätze werden aus den Unternehmenssystemen in skalierbarem Speicher zusammengeführt. Die ursprünglichen Informationen bleiben als maßgebliche Quelle für künftige Verarbeitung verfügbar. Schritt 2: Die Daten verarbeiten und anreichern Eine Ingestion-Pipeline extrahiert Inhalte, bereinigt sie, ergänzt Metadaten und teilt sie in Chunks auf, die sich für das Retrieval eignen. Verarbeitete Ergebnisse können ebenfalls aufbewahrt werden, damit spätere Phasen nicht jede Transformation wiederholen müssen. Schritt 3: Embeddings erzeugen GPU- oder CPU-Infrastruktur wandelt Chunks mit dem gewählten Embedding-Modell der Organisation in Embeddings um. Diese Embeddings werden in das Retrieval-System geladen. Schritt 4: Die Retrieval-Schicht aufbauen Eine Vektordatenbank oder Suchplattform indexiert Embeddings und zugehörige Metadaten. Diese Schicht ist auf Abfragen mit niedriger Latenz optimiert, nicht auf die massenhafte Aufbewahrung des vollständigen Quellkorpus. Schritt 5: Relevanten Kontext abrufen Sendet ein Benutzer einen Prompt, durchsucht die Anwendung die Retrieval-Schicht nach relevanten Informationen. Das System kann dann den nötigen Kontext abrufen und an das LLM übergeben. Schritt 6: Die zugrunde liegenden Daten bewahren Quell- und verarbeitete Daten bleiben unabhängig verfügbar. Wechselt die Organisation Embedding-Modelle, Retrieval-Engines oder KI-Anwendungen, kann sie den Korpus neu verarbeiten, ohne alle ursprünglichen Informationen erneut beschaffen zu müssen. Das ist einer der wichtigsten architektonischen Vorteile der Trennung von Datenschicht und Retrieval-Schicht. Worauf sollten Unternehmen bei Speicher für RAG achten? Die beste Architektur hängt von Workload-Größe und Zugriffsmustern ab, doch Unternehmensteams sollten mehrere Eigenschaften bewerten. Skalierbarkeit Schätzen Sie die Größe des gesamten KI-Datenbestands, nicht nur die des ersten Vektorindex. Beziehen Sie Quelldokumente, verarbeitete Daten, mehrere Versionen, Metadaten, Modellartefakte und das erwartete künftige Wachstum ein. Durchsatz Die Ingestion für RAG kann Tausende gleichzeitige Verarbeitungsvorgänge umfassen. Der aggregierte Durchsatz kann daher ebenso wichtig sein wie die Latenz einzelner Anfragen. Metadatenfunktionen Metadaten sind zentral für das Retrieval. Berechtigungen, Zeitstempel, Dokumenttypen, geschäftliche Klassifizierungen und andere Attribute können helfen, Suchen einzugrenzen und die Relevanz zu verbessern. Die Speicherarchitektur sollte nützliche Metadaten bewahren, statt den zugrunde liegenden Informationen ihren Kontext zu nehmen. Datensicherung Eine RAG-Wissensbasis kann einige der wertvollsten Informationen einer Organisation enthalten. Der Speicher sollte daher geeignete Mechanismen für Verschlüsselung, Zugriffskontrolle, Unveränderlichkeit, Replikation und Wiederherstellung bieten. Wer die KI-Anwendung schützt, ohne ihren zugrunde liegenden Wissenskorpus zu schützen, lässt eine erhebliche Lücke. Datensouveränität RAG im Unternehmen bezieht häufig sensible interne Informationen ein. Organisationen brauchen womöglich die Kontrolle darüber, wo diese Informationen liegen, wer darauf zugreifen kann und welche Infrastruktur sie verarbeitet. Objektspeicher On-Premises oder in einer Private Cloud kann Organisationen helfen, RAG-Systeme aufzubauen und dabei die Kontrolle über den physischen und administrativen Standort ihrer Datensätze zu behalten. S3-Kompatibilität S3 ist zu einer weit unterstützten Schnittstelle in Daten- und KI-Ökosystemen geworden. S3-kompatibler Speicher kann es erleichtern, Datenpipelines, Analysewerkzeuge, KI-Frameworks und andere Anwendungen an ein gemeinsames Daten-Repository anzubinden, ohne für jeden Workload eigene Speicherintegrationen entwickeln zu müssen. Wie Scality in eine Speicherarchitektur für RAG passt Scality RING bietet skalierbaren Datei- und Objektspeicher für große unstrukturierte Datensätze und ist damit als persistente Datenschicht unter KI- und RAG-Umgebungen im Unternehmen relevant. Im Rahmen der umfassenderen Strategie Autonomous Data Infrastructure (ADI) von Scality besteht das Ziel darin, eine Infrastruktur bereitzustellen, die große KI-Datensätze unterstützt und zugleich Anforderungen an Skalierbarkeit, Cyber-Resilienz und souveräne Kontrolle erfüllt. Für RAG geht es bei dieser Rolle vor allem um die Datengrundlage. RING kann die Quelldokumente, Datensätze und abgeleiteten Informationen vorhalten, die KI-Pipelines speisen, während Retrieval-Technologien wie Vektordatenbanken die spezialisierte semantische Suche übernehmen. So können Unternehmen Embedding-Modelle, Retrieval-Engines und KI-Anwendungen weiterentwickeln, ohne diese Systeme zum einzigen Repository für das zugrunde liegende Wissen zu machen. Für Organisationen, die RAG über große bestehende Datenbestände aufbauen, kann diese Trennung immer wertvoller werden, je mehr sowohl der Korpus als auch die Zahl der KI-Anwendungen wachsen. Die beste Speicherarchitektur für RAG ist geschichtet Es gibt keine einzelne Speichertechnologie, die jede Aufgabe in einer RAG-Pipeline optimal erfüllt. Die praxistauglichste Architektur trennt die Zuständigkeiten: Objektspeicher bildet die skalierbare, dauerhafte Grundlage für den Wissenskorpus. Die Verarbeitungsinfrastruktur wandelt die Daten um und reichert sie an. Vektordatenbanken und Suchmaschinen sorgen für schnelles Retrieval. Hochleistungsspeicher kann latenzempfindliche Arbeitsdatensätze bei Bedarf beschleunigen. Dieser geschichtete Ansatz verhindert, dass das Retrieval-System zum langfristigen Daten-Repository wird, und dass der gesamte Unternehmenskorpus auf der teuersten Speicherstufe liegen muss. Bei kleinen RAG-Anwendungen spielt diese Unterscheidung womöglich kaum eine Rolle. Bei Unternehmensbereitstellungen über Petabyte unstrukturierter Daten kann sie darüber entscheiden, ob die Architektur mit wachsendem System beherrschbar bleibt. FAQ Welcher Speicher ist am besten für RAG? Objektspeicher ist eine starke Wahl für die persistente Datenschicht von RAG, weil er auf große unstrukturierte Datensätze skalieren kann und zugleich Langlebigkeit, Metadaten und breite S3-Kompatibilität bietet. Vektordatenbanken oder Suchindizes können dann die spezialisierte Retrieval-Schicht bilden. Braucht RAG eine Vektordatenbank? RAG benötigt einen Mechanismus, um relevante Informationen abzurufen, doch das muss nicht immer eine dedizierte Vektordatenbank sein. Je nach Anwendung können Systeme Vektorsuche, Stichwortsuche, hybride Suche, Wissensgraphen oder Kombinationen dieser Ansätze nutzen. Kann RAG S3-kompatiblen Objektspeicher nutzen? Ja. S3-kompatibler Objektspeicher kann Quelldokumente, verarbeitete Datensätze und andere KI-Artefakte vorhalten und sich mit Datenverarbeitungs- und KI-Werkzeugen integrieren, die die S3-API unterstützen. Ist Objektspeicher schnell genug für RAG? Das hängt davon ab, wo er in der Architektur sitzt. Objektspeicher muss den Vektorindex mit niedriger Latenz nicht ersetzen. Er kann hohen aggregierten Durchsatz für die Ingestion und dauerhaften Speicher für den weit größeren Wissenskorpus liefern, während spezialisierte Retrieval-Infrastruktur latenzempfindliche Suchen übernimmt. Wie viel Speicher benötigt ein RAG-System? Der Speicherbedarf hängt von der Größe des Quellkorpus, der Zahl verarbeiteter Kopien, der Embedding-Strategie, Metadaten, Indizes und Aufbewahrungsanforderungen ab. Unternehmen sollten für den gesamten KI-Datenlebenszyklus planen, statt die Kapazität allein anhand der Größe der Vektordatenbank zu schätzen. Sollten RAG-Daten On-Premises oder in der Cloud gespeichert werden? Beides ist möglich. Die Entscheidung hängt von Data Gravity, Wirtschaftlichkeit, Sicherheit, Souveränität und dem Standort der KI-Rechenleistung ab. Organisationen mit sehr großen oder sensiblen Unternehmensdatensätzen bevorzugen womöglich private oder On-Premises-Infrastruktur, während andere Workloads von Public-Cloud-Diensten profitieren können.
