6 Retrieval-Augmented Generation steht und fällt mit der darunterliegenden Speicherebene. Das Sprachmodell ist ein festes Asset; der Korpus, den das Modell bei jedem Aufruf liest, ist das lebendige. RAG-Datenspeicher bezeichnet die Disziplin, das Fundament zu entwerfen, das Quelldokumente, geparste Chunks, Vektor-Embeddings, Indizes und Metadaten enthält und sie bei jeder Inferencing-Anfrage mit Produktionslatenz zurückliefert. Dieser Leitfaden konzentriert sich ausschließlich auf den Speicher – nicht auf Pipeline-Design, nicht auf die Wahl des Embedding-Modells, nicht auf Prompt Engineering. Was verlangt ein RAG-Workload von der Speicherebene? Wo scheitern generische Dateisysteme und Objekt-Buckets mit nur einer Ebene? Und wie bildet das vierstufige Fundament von Scality ADI diese Anforderungen ab? Was ist RAG-Datenspeicher? RAG-Datenspeicher ist das mehrschichtige Speicherfundament, aus dem eine RAG-Anwendung im Unternehmen liest und in das sie schreibt. Er ist keine einzelne Datenbank und kein einzelner Bucket, sondern ein koordinierter Verbund von Speichern, die jeweils auf ein anderes Zugriffsmuster abgestimmt sind und den Korpus gemeinsam durch Ingestion, Indexierung und Retrieval tragen. Ein produktives RAG-Deployment unterhält typischerweise sieben verschiedene Speicher: Quellarchiv. Die dauerhafte Kopie jedes aufgenommenen Dokuments in seiner ursprünglichen Form. Schreibintensiv in Schüben während des Backfills, danach selten gelesen. Speicher für geparste Chunks. Vorverarbeitete Textsegmente, bereit für das Embedding oder Re-Embedding. Leseintensiv beim Neuaufbau von Indizes. Embedding-Speicher. Die dauerhafte, versionierte Kopie jedes jemals erzeugten Vektors. Wird von Index-Buildern mit hohem Fan-out gelesen. Vektorindex. Die heiße, leistungsoptimierte Struktur, die beim Inferencing Ähnlichkeitsabfragen bedient. Keyword-Index. Der lexikalische Index – meist BM25 –, der Eigennamen, Fehlercodes und seltene Fachbegriffe abdeckt. Metadatenschicht. Einträge zu Herkunft, Klassifizierung, Version und Zugriffskontrolle, die jedem Chunk zugeordnet sind. Aufbewahrungsarchiv. Die Compliance-Kopie der Quellinhalte und historischen Embeddings, aufbewahrt für die regulatorische Frist. Jeder Speicher hat sein eigenes Latenzbudget, sein eigenes Schreibmuster und sein eigenes Kostenprofil. Sie als einen einzigen Workload zu behandeln, ist der häufigste Fehler im Speicherdesign. Warum sich RAG-Datenspeicher von generischem KI-Speicher unterscheidet Eine Trainingspipeline liest einen Datensatz, berechnet Gradienten, schreibt Checkpoints und läuft im Batch. Das Lesemuster ist vorhersehbar, und das Latenzbudget wird in Sekunden gemessen. RAG ist ein anderer Workload. RAG-Datenspeicher liegt im heißen Pfad jedes Inferencing-Aufrufs. Der Retrieval-Schritt muss eine Top-k-Kandidatenmenge im 95. Perzentil innerhalb weniger Dutzend Millisekunden liefern. Der Korpus dahinter kann Hunderte Millionen Chunks umfassen. Neue Dokumente kommen laufend hinzu, und der Index muss sie ohne globalen Neuaufbau abbilden. Dasselbe Fundament muss einen schubweisen Ingestion-Strom, einen Embedding-Aufbau mit hohem Fan-out und einen Abfrage-Workload mit niedriger Latenz aufnehmen – gleichzeitig und ohne dass einer die anderen ausbremst. Vier Eigenschaften unterscheiden den RAG-Fall von generischem KI-Speicher: Vektor- und Dokumentdaten liegen nebeneinander. Embeddings und Quell-Chunks teilen sich Namespace und Lebenszyklus, sodass das Retrieval einen Vektortreffer liefern und sofort zum übergeordneten Dokument erweitern kann. Die Retrieval-Latenz ist nicht verhandelbar. Ein Retrieval unter 100 Millisekunden im P95 bei einem Korpus mit einer Milliarde Chunks ist die Grunderwartung. Indexdateien müssen auf Flash oder im Arbeitsspeicher liegen; Speicher der Kapazitätsebene im Retrieval-Pfad ist eine Latenzmauer. Versionierung zählt. Embedding-Modelle ändern sich. Chunking-Strategien ändern sich. Index-Familien ändern sich. Ohne versionierten Embedding-Speicher und versioniertes Quellarchiv erzwingt jede Änderung eine vollständige Neuaufnahme von Grund auf – den teuersten Schritt der Pipeline. Aktualität ist eine Speicheranforderung, keine Funktion. Ein RAG-System, das nicht aktualisiert wird, liefert selbstbewusst veraltete Antworten. Das Speicherfundament muss gleichzeitige Ingestion und Abfragen ohne Sperren aufnehmen, sonst wird die Aktualisierungsverzögerung für Nutzer als veralteter Stand sichtbar. Den übergreifenden Ablauf im Zusammenhang beschreibt der Beitrag Retrieval-Augmented Generation und Speicher für KI aus End-to-End-Sicht. Vektor- und Dokumentspeicher: das Problem der zwei Korpora Ein RAG-Korpus besteht eigentlich aus zwei Korpora, die im Gleichschritt laufen. Der Vektorspeicher enthält die dichten Repräsentationen, gegen die der Retriever abfragt. Der Dokumentspeicher enthält die Quellinhalte, die der Retriever zurückgibt und das Sprachmodell liest. Die meisten frühen RAG-Deployments trennen beide – eine verwaltete Vektordatenbank für die Embeddings, eine generische Dateifreigabe oder ein S3-Bucket für die Dokumente – und zahlen später für diese Entscheidung. Die Kosten zeigen sich an drei Stellen. Latenz, weil jeder Retrieval-Treffer einen systemübergreifenden Abruf auslöst, um den Kontextblock zusammenzustellen. Konsistenz, weil Vektor- und Dokumentspeicher auseinanderdriften, wenn sich Quelldokumente schneller ändern, als die Embedding-Pipeline läuft. Governance, weil Zugriffskontrollen, Herkunftsnachweise und Audit-Logs über zwei Systeme mit unterschiedlichen Sicherheitsmodellen abgeglichen werden müssen. Eine einheitliche RAG-Datenspeicherschicht hält Vektoren und Dokumente in einem Namespace – mit einem Zugriffskontrollmodell, einem Herkunftsnachweis und einer Lifecycle-Richtlinie. Das Retrieval erweitert einen Vektortreffer in einem einzigen Durchlauf zum übergeordneten Chunk und zum übergeordneten Dokument. Beim Neuaufbau von Indizes werden Embeddings und Quellinhalte ohne systemübergreifende Orchestrierung aus demselben dauerhaften Fundament gelesen. Speicher für Vektordatenbanken behandelt die Anforderungen auf der Vektorseite; die Anforderungen auf der Dokumentseite sehen im großen Maßstab sehr ähnlich aus. Retrieval mit niedriger Latenz: wo die Indexdateien liegen Der Vektorindex ist die heiße Datei im Stack. HNSW-Graphen, IVF-PQ-Cluster und Graphstrukturen der DiskANN-Klasse erwarten zufällige Lesezugriffe mit Flash-Latenzen. Ein HNSW-Graph mit einer Milliarde Vektoren, der auf rotierende Festplatten ausgelagert wird, macht aus einer Ähnlichkeitsabfrage im Submillisekundenbereich eine mehrsekündige – und im großen Maßstab summieren sich langsame Retrieval-Warteschlangen zu mehrsekündigen P99-Latenzen für Endnutzer. Zwei Speicherentscheidungen prägen die Retrieval-Latenz. Erstens: das Medium unter den Indexdateien. Heiße Ebenen auf TLC-Flash mit latenzarmen Netzwerkpfaden halten speicherabgebildete Indizes und die Graphtraversierung auf dem Datenträger im Budget. DiskANN wurde eigens für den Betrieb auf Flash entwickelt; auf Medien der Kapazitätsebene verfehlt diese Index-Familie ihren Zweck. Zweitens: das Protokoll zwischen Retrieval-Dienst und Speicherebene. S3 over RDMA – Remote Direct Memory Access – senkt die Latenz von Objektlesezugriffen in den Bereich unter 50 Mikrosekunden; das ist der Unterschied zwischen Flash, der mit lokalem NVMe mithalten kann, und Flash, der es nicht kann. Die GPU-Direct-Ebene von Scality ADI bietet genau diesen Protokollpfad. Derselbe Flash liegt hinter den Indexdateien, hinter dem invertierten Keyword-Index und hinter der Metadatenschicht, die Retrieval-Kandidaten nach Klassifizierung, Rechtsordnung oder Version filtert. Versionierung: warum Unveränderlichkeit eine RAG-Anforderung ist Embedding-Modelle werden besser. Das Team wählt einen stärkeren Encoder, trainiert den bestehenden mit Fachinhalten nach oder wechselt von einem Modell mit 768 Dimensionen zu einem mit 1.024 Dimensionen. Jede Änderung macht den bestehenden Vektorindex ungültig. Ohne dauerhaften, versionierten Embedding-Speicher muss das Team den gesamten Korpus aus den geparsten Chunks neu einbetten – und wenn sich die Chunks selbst geändert haben, aus dem Quellarchiv. Die Kosten eines vollständigen Re-Embedding-Durchlaufs werden im Unternehmensmaßstab in GPU-Tagen gemessen. Die Kosten einer Neuaufnahme aus der Quelle werden in GPU-Tagen plus Parsing-Zeit gemessen – plus dem betrieblichen Risiko, die Ingestion gegen Systeme erneut abzuspielen, deren Änderungshistorie verloren sein kann. Ein versioniertes Quellarchiv und ein versionierter Embedding-Speicher reduzieren diese Kosten auf einen Re-Indexierungsdurchlauf, der mit hohem Fan-out aus dauerhaftem Speicher liest und in Stunden statt Tagen abgeschlossen ist. Unveränderlichkeit reicht über die Versionierung hinaus bis in die Compliance. Quelldokumente in regulierten Umgebungen – Finanzunterlagen, klinische Forschung, Behördendaten – müssen für die Aufbewahrungsfrist unverändert erhalten bleiben. Object Lock und Write-once-Semantik im Quellarchiv machen Quellenangaben über die gesamte Aufbewahrungsfrist prüfbar und schützen den Korpus vor Ransomware, die gezielt Trainingsdaten und Wissensdatenbanken angreift. Speicher für Vektordatenbanken und der übergreifende Beitrag zur RAG-Speicherarchitektur behandeln die Unveränderlichkeit ausführlicher. Aktualität: wie RAG-Datenspeicher laufende Änderungen aufnimmt Quellinhalte ändern sich ständig. Richtlinien werden aktualisiert, Preise ändern sich, Produkte kommen auf den Markt, Vorschriften verschieben sich. Ein veralteter Index macht das Modell zu einem selbstbewussten Lieferanten veralteter Antworten – genau das Fehlerbild, das RAG beseitigen sollte. Drei Muster für die Aktualität dominieren, und jedes stellt andere Anforderungen an den RAG-Datenspeicher: Geplante Re-Indexierung. Regelmäßige vollständige oder inkrementelle Neuaufbauten, meist täglich oder wöchentlich. Toleriert Sperren und Lesezugriffe auf der Kapazitätsebene, macht die Verzögerung aber für Endnutzer sichtbar. Ingestion per Change Data Capture. Quellsysteme senden Änderungsereignisse; die Ingestion-Pipeline schreibt neue und aktualisierte Objekte direkt in das Quellarchiv, und nachgelagertes Chunking und Embedding folgen dem Änderungsstrom. Erfordert gleichzeitiges Schreiben und Lesen im Fundament, ohne die Abfragelatenz zu verschlechtern. Hybride Aktualität. Eine Live-Ebene mit den jüngsten Änderungen liegt neben dem Hauptindex. Das Retrieval fragt beide ab; die Live-Ebene wird regelmäßig in den Hauptindex übernommen. Das anspruchsvollste Muster, weil der Schreibpfad der Live-Ebene gleichzeitig mit dem leseintensiven Retrieval-Pfad läuft. CDC und hybride Aktualität sind die Muster, auf die RAG-Deployments in Unternehmen zusteuern, weil Nutzer keine Antworten akzeptieren, die einen Tag alt sind. Das Speicherfundament muss gleichzeitige Ingestion und Abfragen ohne Sperrkonflikte bewältigen, und die Metadatenschicht muss mit Milliarden von Objekten skalieren, damit Filter-und-Abruf-Abfragen – „nur die aktuelle Version, nur diese Rechtsordnung“ – auch bei wachsendem Korpus schnell bleiben. Wie Scality ADI die Anforderungen an RAG-Datenspeicher abbildet Scality ADI (Autonomous Data Infrastructure) ist eine Dateninfrastruktur für Enterprise-KI, Cyber-Resilienz und souveräne Kontrolle, die autonom und nachhaltig die passenden Speichermedien im Maßstab von mehreren Petabyte bis Exabyte zuordnet. Das vierstufige Fundament von Scality ADI bildet die sieben Speicher eines produktiven RAG-Deployments direkt ab. RAG-Speicher Zugriffsmuster Scality-ADI-Ebene Quellarchiv Schreibintensiv in Schüben, selten gelesen Warm (NL-SSD / HDD) und Cold (Band) Speicher für geparste Chunks Leseintensiv beim Neuaufbau Warm Embedding-Speicher Lesezugriffe mit hoher Parallelität beim Neuaufbau Hot (QLC / NL-SSD) Vektorindex Zufällige Lesezugriffe, Submillisekundenbereich GPU-Direct (TLC + S3 over RDMA) Keyword-Index Zufällige Lesezugriffe, überwiegend gecacht GPU-Direct Metadatenschicht Filtern und Abrufen bei der Abfrage GPU-Direct Aufbewahrungsarchiv Seltene Lesezugriffe, regulatorische Sperre Cold Mehrere Funktionen von Scality ADI adressieren die oben genannten Anforderungen direkt: GPU-Direct-Ebene mit S3 over RDMA. Eine Latenz unter 50 Mikrosekunden auf TLC-Flash hält Lesezugriffe auf den Vektorindex, die Graphtraversierung auf dem Datenträger bei Indizes der DiskANN-Klasse und Abfragen im Keyword-Index innerhalb des Retrieval-Budgets. Ein Namespace über alle vier Ebenen. Quelldokumente, geparste Chunks und gespeicherte Embeddings liegen in einem einzigen S3-kompatiblen Namespace, sodass Vektortreffer in einem Durchlauf zu den übergeordneten Dokumenten erweitert werden und vorhandene Tools – LangChain-Retriever, LlamaIndex, Vektordatenbanken – sich über die standardmäßige S3-API-Kompatibilität nahtlos anbinden. CORE5-Cyber-Resilienz. Unveränderlichkeit, Erasure Coding, Metadatenschutz, standortübergreifende Ausfallsicherheit und richtliniengesteuerter Lebenszyklus halten das Quellarchiv nachweislich unverfälscht. Quellenangaben bleiben über die gesamte Aufbewahrungsfrist prüfbar. Temperaturübergreifender Lebenszyklus ohne Tickets an den Betrieb. Heiße Embeddings und Indizes bleiben auf Flash. Warme geparste Chunks werden per Richtlinie herabgestuft. Kalte Versionen des Quellarchivs landen auf Band. Hoch- und Herabstufung erfolgen per Richtlinie, nicht durch manuelle Datenverschiebung. Metadaten auf Objektebene im großen Maßstab. Milliarden von Chunks erzeugen Milliarden von Metadateneinträgen. Die Metadatenschicht hält Filter-und-Abruf-Abfragen auch bei wachsendem Korpus schnell. Guardian mit Agenten für den autonomen Betrieb. Empfehlungen zu Erweiterung, Rebalancing und Tiering werden innerhalb kundendefinierter Richtlinien bereitgestellt, die Ausführung genehmigen Menschen. Ein RAG-Korpus, der von einer auf zehn Milliarden Chunks wächst, muss das Betriebsteam nicht im gleichen Maß vergrößern. Scality ADI ersetzt nicht die Designarbeit in einem RAG-System. Chunking-Strategie, Wahl des Embedding-Modells, Index-Familie und Aktualitätsmuster bleiben Aufgabe des Teams, das die Retrieval-Schicht baut. Scality ADI beseitigt die Einschränkungen auf Fundamentebene – Lock-in auf eine einzige Ebene, Metadatendienste, die bei einer Milliarde Einträgen einknicken, Sperrkonflikte bei gleichzeitiger Ingestion und Abfrage –, die Teams sonst zu Kompromissen bei diesen Entscheidungen zwingen. So unterstützt Scality ADI RAG-Datenspeicher für Enterprise-KI Häufig gestellte Fragen Was ist RAG-Datenspeicher? RAG-Datenspeicher ist das mehrschichtige Speicherfundament hinter einer Anwendung für Retrieval-Augmented Generation. Er umfasst Quellarchiv, Speicher für geparste Chunks, Embedding-Speicher, Vektorindex, Keyword-Index, Metadatenschicht und Aufbewahrungsarchiv. Jede Schicht hat ihr eigenes Zugriffsmuster und Latenzbudget, und alle müssen im heißen Pfad jedes Inferencing-Aufrufs zusammenarbeiten. Worin unterscheidet sich RAG-Datenspeicher von Speicher für KI-Training? Trainingsspeicher ist batchorientiert, mit vorhersehbaren Lesezugriffen und Latenzbudgets im Sekundenbereich. RAG-Datenspeicher liegt im heißen Pfad des Inferencing, mit Erwartungen an ein Retrieval unter 100 Millisekunden bei Korpora mit einer Milliarde Chunks und gleichzeitigen Ingestion-, Embedding- und Abfrage-Workloads auf demselben Fundament. Müssen Vektor- und Dokumentspeicher vereinheitlicht werden? Im Produktivbetrieb ja. Ihre Trennung erzeugt bei jedem Retrieval systemübergreifende Latenz, Abweichungen zwischen Vektoren und Quelldokumenten bei Inhaltsänderungen und eine über zwei Sicherheitsmodelle aufgeteilte Governance. Ein einheitlicher Namespace mit einem Zugriffskontrollmodell hält Retrieval, Aktualität und Audit konsistent. Warum braucht RAG-Datenspeicher Versionierung? Embedding-Modelle, Chunking-Strategien und Index-Familien ändern sich. Ohne versionierten Embedding-Speicher und versioniertes Quellarchiv erzwingt jede Änderung einen Re-Embedding-Durchlauf – oder schlimmer noch eine vollständige Neuaufnahme –, der im Unternehmensmaßstab GPU-Tage kostet. Versionierung macht daraus Re-Indexierungsdurchläufe, die in Stunden gemessen werden. Welche Latenz erfordert RAG-Retrieval? Produktive Deployments zielen für den Schritt aus Abruf und Ranking auf unter 100 Millisekunden im 95. Perzentil bei einem Korpus mit einer Milliarde Chunks. Dieses Budget verlangt, dass Vektorindex, Keyword-Index und Metadatenschicht auf Flash mit einem latenzarmen Protokollpfad liegen – an der Spitze S3 over RDMA – und schließt Medien der Kapazitätsebene im Retrieval-Pfad aus. Weiterführende Artikel Retrieval-Augmented Generation und Speicher für KI RAG-Speicherarchitektur Speicher für Vektordatenbanken Agentische KI-Speicherinfrastruktur Speicher für KI-Trainingspipelines GPU-Direct Storage Metadatenindexierung im Objektspeicher Fazit RAG-Datenspeicher wird nicht durch die Vektordatenbank definiert, die die Embeddings enthält, oder durch den Objekt-Bucket mit den Quelldokumenten. Er wird dadurch definiert, wie sauber die sieben Speicher im heißen Pfad jedes Inferencing-Aufrufs zusammenarbeiten – und ob das Fundament darunter Vektor- und Dokumentdaten nebeneinander tragen, das Retrieval mit einer Latenz unter 100 Millisekunden bedienen, Embeddings und Quellinhalte über Modellwechsel hinweg versionieren und laufende Aktualisierungen aufnehmen kann, ohne Abfragen zu verlangsamen. Stimmt das Fundament, hat die Retrieval-Schicht darüber Raum, gut zu sein. Stimmt es nicht, gleicht kein noch so gutes Prompt Engineering die Lücke aus.
