WISSEN > KI INFRASTRUKTU > RAG ARCHITEKTUR
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Eine RAG-Architektur ist mehr als eine Vektordatenbank
Wie Unternehmensdaten den Weg in den Kontext eines Sprachmodells finden
Das sollten Sie mitnehmen:
- RAG erweitert den Kontext eines Sprachmodells, nicht sein Training.
Informationen werden zur Laufzeit gesucht und zusammen mit der Frage an das Modell übergeben, statt in dessen Parameter eingebaut zu werden.
- Die Qualität einer RAG-Anwendung entsteht, bevor das Sprachmodell überhaupt anfängt.
Wie Inhalte aus Dateien herausgelöst, zerlegt, indexiert und wiedergefunden werden, bestimmt, was das Modell zu sehen bekommt.
- Eine Vektordatenbank ist ein Baustein, nicht die Architektur.
Datenquellen, Verarbeitung, Retrieval, Berechtigungen, Aktualisierung und das Sprachmodell gehören ebenso dazu.
- Suchen und Antworten sind zwei verschiedene Aufgaben.
Das Retrieval-System entscheidet, welche Informationen verfügbar sind. Das Sprachmodell entscheidet, was es daraus macht.
- RAG verhindert falsche Antworten nicht automatisch.
Wenn veraltete oder unpassende Informationen gefunden werden, kann auch eine RAG-Anwendung danebenliegen.
Eine RAG-Architektur ist mehr als eine Vektordatenbank
Inhaltsverzeichnis
- Was Retrieval-Augmented Generation bedeutet
- Jede RAG-Architektur besitzt zwei getrennte Datenpfade
- Ingestion und Extraction: Daten aufnehmen und Inhalte herauslösen
- Chunking: die Größe der Abschnitte entscheidet über die Auffindbarkeit
- Embeddings und Index: Bedeutung wird zu Zahlen
- Query Processing: die Frage wird für die Suche umgeschrieben
- Reranking und Context Assembly: mehr Kontext ist nicht besser
- Das Sprachmodell erzeugt die Antwort, nicht deren Grundlage
- Warum RAG falsche Antworten nicht grundsätzlich verhindert
- Naive, Advanced und Agentic RAG
- Was daraus für die Infrastruktur folgt
- Fazit
- Quellen
Retrieval-Augmented Generation, kurz RAG, verbindet ein Sprachmodell mit externen Informationsquellen. Statt eine Frage allein aus dem zu beantworten, was im Training des Modells enthalten war, sucht das System zunächst nach passenden Informationen und stellt sie dem Modell als zusätzlichen Kontext bereit.
Rund um dieses einfache Prinzip hat sich ein Vokabular gebildet, das komplizierter klingt als der Ablauf dahinter. Die Vorbereitung der Daten heißt Ingestion, Extraction, Chunking und Embeddings – also: Daten übernehmen, Inhalte herauslösen, in sinnvolle Abschnitte teilen und diese Abschnitte mathematisch repräsentieren. Bei einer späteren Frage folgt eine zweite Kette aus Query Processing, Retrieval, Reranking, Context Assembly und der Antwort des Sprachmodells – also: Frage aufbereiten, passende Informationen suchen, Treffer neu bewerten, den Kontext zusammenstellen, Antwort erzeugen.
Nicht jede Implementierung enthält alle diese Schritte. Reranking und eine aufwendige Aufbereitung der Frage sind optionale Erweiterungen. Das Grundprinzip bleibt gleich: Informationen werden für die Suche vorbereitet und später gezielt abgerufen, bevor sie an das Sprachmodell gehen.
Dieser Artikel geht die Kette Schritt für Schritt durch. Entscheidend ist dabei, RAG nicht als einzelne Komponente zu verstehen, sondern als Verarbeitungs- und Retrieval-Kette.
Was Retrieval-Augmented Generation bedeutet
Der Begriff lässt sich in drei Bestandteile zerlegen. Retrieval bezeichnet das gezielte Suchen und Abrufen relevanter Informationen. Augmentation bezeichnet die Erweiterung der Modelleingabe um genau diese gefundenen Informationen. Generation bezeichnet die anschließende Erzeugung der Antwort. Vereinfacht: fragen, suchen, das Gefundene zur Frage hinzufügen, antworten.
Eine RAG-Anwendung trennt damit das im Modell repräsentierte Wissen von Informationen, die außerhalb des Modells liegen. AWS beschreibt den Ablauf so, dass Dokumente zunächst als durchsuchbare Repräsentationen abgelegt werden, ein Orchestrator bei einer Anfrage eine Ähnlichkeitssuche durchführt, die gefundenen Daten dem Prompt hinzufügt und beides gemeinsam an das Sprachmodell übergibt.
Das ist zugleich der wesentliche Unterschied zum Fine-Tuning. Neue Unternehmensinformationen müssen nicht durch erneutes Training in die Modellparameter eingebracht werden, damit sie für eine Antwort verfügbar sind. Sie können außerhalb des Modells liegen und bei Bedarf abgerufen werden.
Eine begriffliche Einordnung gehört an dieser Stelle dazu, weil sie häufig durcheinandergeht. Der Begriff stammt aus einer Arbeit von Lewis und Kollegen aus dem Jahr 2020, die parametrisches Wissen eines Sprachmodells mit einer externen, nichtparametrischen Wissensquelle verbindet. Dort war RAG allerdings ein gemeinsam trainiertes Modell aus Retriever und Generator. Was heute in Unternehmen unter RAG gebaut wird, kommt ohne dieses Training aus: Die Informationen werden zur Laufzeit in den Prompt gegeben. Das Grundprinzip ist dasselbe, die technische Umsetzung nicht.
Jede RAG-Architektur besitzt zwei getrennte Datenpfade
Für das technische Verständnis hilft es, eine RAG-Architektur nicht als eine Kette zu sehen, sondern als zwei zusammengehörende Datenpfade.
Der erste Pfad baut die Wissensbasis auf und läuft unabhängig von jeder Benutzeranfrage: von der Datenquelle über Ingestion, Extraction, Chunking und Embeddings bis in den Index. Der zweite Pfad wird ausgelöst, wenn jemand eine Frage stellt: von der Query über Query Processing, Retrieval, optionales Reranking und Context Assembly bis zur Antwort des Sprachmodells.
Diese Trennung ist auch für die Infrastruktur relevant. Die Verarbeitung großer Datenbestände beim Aufbau der Wissensbasis stellt andere Anforderungen an Rechenleistung, Storage und Netzwerk als eine interaktive Abfrage, bei der vor allem die Antwortzeit zählt.
[BILD: Zwei Datenpfade – Aufbau der Wissensbasis oben, Beantwortung einer Anfrage unten, mit dem Index als gemeinsamem Element]
Ingestion und Extraction: Daten aufnehmen und Inhalte herauslösen
Ingestion bedeutet vereinfacht, Daten in die Verarbeitung aufzunehmen. Die Originalinformationen können aus Dokumenten, Anwendungen, Datenbanken, File Storage oder Object Storage stammen. Die Aufgabe dieser Schicht besteht zunächst nur darin, die Daten für die weitere Verarbeitung verfügbar zu machen.
Wichtig ist dabei eine Unterscheidung, die später vieles erklärt: Originaldaten und Retrieval-Index sind nicht dasselbe. Die Quelldaten bleiben in ihrem ursprünglichen Storage oder in der jeweiligen Anwendung. Für das Retrieval entsteht zusätzlich eine zweite, für die Suche optimierte Datenstruktur.
Damit stellt sich sofort die Frage, was passiert, wenn sich die Originaldaten ändern. Werden Dokumente ergänzt, geändert oder gelöscht, muss definiert sein, wann und wie sich das in der Wissensbasis niederschlägt. Wir kommen darauf am Ende dieses Kapitels zurück.
Aus einer Datei wird nicht automatisch verwertbarer Text
Extraction bedeutet, den tatsächlich relevanten Inhalt aus dem Datenformat herauszulösen. Ein PDF enthält Fließtext, Überschriften, Tabellen, Bilder, Fußnoten, Seitenzahlen und Metadaten. Andere Formate haben wieder andere interne Strukturen. Parser und Extractor müssen daraus eine Repräsentation erzeugen, mit der die folgenden Schritte etwas anfangen können.
Microsoft führt für diese Phase eine konkrete Mindestanforderung auf: Textformate vereinheitlichen, Sonderzeichen behandeln, veraltete oder themenfremde Inhalte entfernen, Versionen nachverfolgen, Inhalte mit Tabulatoren, Bildern oder Tabellen verarbeiten und Metadaten extrahieren.
Diese Phase ist für die spätere Qualität fundamental. Geht beim Extrahieren einer Tabelle die Beziehung zwischen Spalten und Werten verloren, können die nachfolgenden Schritte diese Struktur nicht rekonstruieren. Die Qualität eines RAG-Systems beginnt bei der korrekten Interpretation seiner Quelldaten.
Der Index braucht einen Lebenszyklus
Eine RAG-Wissensbasis ist nach der erstmaligen Indexierung nicht dauerhaft aktuell. Ändern sich Quelldaten, muss die Änderung erkannt, der Inhalt neu extrahiert, die Chunks aktualisiert, die Embeddings neu erzeugt und der Index angepasst werden. Auch Löschungen müssen ankommen – sonst liefert das System Antworten auf Basis von Dokumenten, die es nicht mehr gibt.
Microsoft ordnet die Update-Strategie ausdrücklich der Ingestion-Phase zu und unterscheidet mehrere Ansätze: inkrementelle Aktualisierung nach festem Zeitplan oder ausgelöst durch eine Dokumentänderung, partielle Aktualisierung durch selektives Neuindexieren nur der betroffenen Teile, Versionierung über Snapshots sowie Aktualisierung in Echtzeit über Stream Processing.
NVIDIA dokumentiert eine konkrete ereignisgesteuerte Umsetzung: Dateien werden in einen Object-Storage-Bucket geschrieben, der beim Schreiben ein Ereignis erzeugt. Dieses Ereignis wird auf ein Kafka-Topic publiziert, ein Consumer holt die Datei ab, übergibt sie an die Verarbeitung, und der Inhalt landet indexiert in der Vektordatenbank.
Der zeitliche Abstand zwischen einer Änderung in der Datenquelle und ihrer Verfügbarkeit im Retrieval ist damit eine Eigenschaft der jeweiligen Architektur. Wie klein er sein muss, hängt vom Anwendungsfall ab.
[QUERVERWEIS: Object Storage als Datenplattform – Eventing und Objektänderungen als Auslöser nachgelagerter Verarbeitung]
Chunking: die Größe der Abschnitte entscheidet über die Auffindbarkeit
Chunking bedeutet, große Inhalte in kleinere, sinnvoll durchsuchbare Abschnitte aufzuteilen. Ein umfangreiches Dokument wird nicht als eine einzige Informationseinheit behandelt, sondern in eine Reihe von Chunks zerlegt. AWS beschreibt Chunking ausdrücklich als ersten Schritt des Vector-Search-Prozesses, noch vor der Erzeugung der Embeddings.
Aufgeteilt werden kann nach einer festen Anzahl Tokens, nach Sätzen, Absätzen, Überschriften und Abschnitten, nach der Dokumentstruktur oder nach inhaltlichen Einheiten. AWS unterscheidet unter anderem tokenbasiertes, hierarchisches und semantisches Chunking. Microsoft nennt zusätzlich überlappende Chunks und den Sliding-Window-Ansatz sowie ein Verfahren namens Small2Big, bei dem satzweise gesucht, dem Sprachmodell aber der umgebende größere Abschnitt übergeben wird.
Die Chunk-Größe erzeugt dabei einen Zielkonflikt, der sich nicht auflösen, sondern nur entscheiden lässt. Kleine Chunks isolieren einen sehr spezifischen Inhalt, riskieren aber, dass der notwendige Zusammenhang außerhalb liegt. Große Chunks bewahren mehr Zusammenhang, enthalten dafür zusätzliche Informationen, die für eine konkrete Frage irrelevant sind.
Chunking legt damit fest, in welcher Granularität ein RAG-System Informationen überhaupt wiederfinden kann. Das ist keine technische Randnotiz, sondern eine Architekturentscheidung.
[BILD: Ein Dokument, zerlegt in Chunks – links kleine Chunks mit abgeschnittenem Kontext, rechts große Chunks mit Beiwerk]
Embeddings und Index: Bedeutung wird zu Zahlen
Ein Embedding ist die Umwandlung eines Inhalts in eine Zahlenreihe, die ein Suchsystem mathematisch vergleichen kann. Ein Embedding-Modell bildet dazu jeden Text-Chunk auf einen Vektor ab – eine Liste von Zahlen fester Länge.
Aus einem Satz wie „NVMe over Fabrics ermöglicht NVMe-Zugriffe über ein Netzwerk" wird so eine numerische Repräsentation. Für einen Menschen ist sie nicht lesbar. Für die Retrieval-Software ermöglicht sie den Vergleich zwischen einer Frage und den gespeicherten Inhalten.
Ein Embedding ist dabei nicht der ursprüngliche Inhalt. Zusätzlich zum Vektor werden deshalb der zugehörige Text und die relevanten Metadaten benötigt.
Genau das leistet der Index. AWS beschreibt eine Vektordatenbank als Index aus den Embeddings, dem zugehörigen Text und den Metadaten, optimiert für Suche und Retrieval. Eine RAG-Architektur braucht dafür nicht zwingend ein Produkt, das sich „Vector Database" nennt. Entscheidend ist die Funktion: Die Plattform muss die verwendeten Repräsentationen speichern beziehungsweise indexieren und die erforderlichen Suchoperationen bereitstellen.
[QUERVERWEIS: AI Data Lake – Konsolidierung von Datenbeständen für KI-Anwendungen]
Query Processing: die Frage wird für die Suche umgeschrieben
Hier beginnt der zweite Datenpfad. Ein Benutzer stellt eine Frage, etwa: „Welche Daten benötigt unsere KI-Anwendung?"
Bei einer einfachen Implementierung wird diese Frage direkt für die Suche verwendet. Fortgeschrittene Architekturen verändern sie zunächst. Microsoft fasst das unter Query Translation zusammen und nennt als Verfahren die Anreicherung einer knappen oder vagen Frage, die Zerlegung in Teilfragen, das Umschreiben – etwa Auflösen von Abkürzungen oder Entfernen von Umgangssprache – sowie Hypothetical Document Embeddings, bei denen das Sprachmodell zunächst eine hypothetische Antwort erzeugt und mit deren Embedding gesucht wird.
Wozu das gut ist, wird im Dialog am deutlichsten. Ein Benutzer fragt zuerst: „Wie funktioniert Object Lock?" und anschließend: „Wie lange gilt das?" Die zweite Frage enthält für sich genommen nicht mehr genügend fachlichen Kontext, um damit zu suchen. Ein Query-Rewriter formt daraus eine eigenständige Anfrage zur Aufbewahrungsdauer bei Object Lock.
NVIDIA dokumentiert genau diesen Ablauf als optionalen Schritt: Sind Multi-Turn-Konversation und Query Rewriting aktiviert, wird die letzte Nachricht anhand der Gesprächshistorie zu einer eigenständigen, kontextreichen Anfrage umgeschrieben.
[QUERVERWEIS: Ransomware-Schutz und Unveränderlichkeit – Object Lock und Aufbewahrungsfristen]
Retrieval findet Treffer – Berechtigungen entscheiden, welche zählen
Retrieval bedeutet, aus der Wissensbasis diejenigen Informationen zu suchen, die für die aktuelle Frage relevant erscheinen. Bei Vector Search wird dazu auch für die Frage ein Embedding erzeugt und dieser Vektor mit den gespeicherten Vektoren verglichen.
Wie ähnlich zwei Vektoren sind, wird über eine Metrik bestimmt. AWS nennt Cosine Distance, Euklidische Distanz und Dot Product. Häufig ist von Cosine Similarity die Rede – das ist dieselbe Größe, nur umgekehrt gezählt: Je höher die Ähnlichkeit, desto geringer die Distanz. Der Retriever liefert anschließend die besten Kandidaten zurück, üblicherweise eine festgelegte Anzahl, in der Praxis meist als Top-k bezeichnet.
Vector Search ist dabei nicht das einzige Verfahren. Eine RAG-Architektur kann ebenso Keyword Search, Volltextsuche oder eine Kombination aus beidem einsetzen. Aktuelle Microsoft-Referenzarchitekturen berücksichtigen ausdrücklich Vektor-, Volltext- und hybride Suche. Welche Methode geeignet ist, hängt von den Daten, den Abfragen und den Anforderungen ab.
Nicht jeder passende Treffer darf verwendet werden
Semantische Ähnlichkeit beantwortet nur, welche Inhalte zur Frage passen. In einem Unternehmenssystem muss zusätzlich beantwortet werden, welche dieser Inhalte der anfragende Benutzer überhaupt sehen darf. Ein Dokument darf nicht allein deshalb in den Kontext eines Sprachmodells gelangen, weil es gut zur Anfrage passt.
Berechtigungen gehören damit zur RAG-Datenarchitektur, nicht zu ihrer Peripherie. Metadaten leisten dabei doppelte Arbeit: Sie transportieren die Zugriffsregeln, und sie können den Suchraum einschränken – nach Datenquelle, Dokumenttyp, Fachbereich, Sprache, Version oder Aktualität. Microsoft beschreibt dieses Metadata Filtering ausdrücklich als Möglichkeit, den Suchraum anhand zusätzlicher Eigenschaften zu begrenzen.
Für Unternehmensdaten heißt das: Bei der Transformation vom Originaldokument zum Retrieval-Index dürfen Metadaten und Zugriffsregeln nicht als nebensächlich behandelt werden. Was hier verloren geht, lässt sich später nicht nachrüsten.
[QUERVERWEIS: Data Intelligence und Governance – Klassifizierung und Zugriffssteuerung auf Unternehmensdaten]
Reranking und Context Assembly: mehr Kontext ist nicht besser
Reranking bedeutet, bereits gefundene Kandidaten ein zweites Mal genauer zu bewerten und neu zu sortieren. Es gehört nicht zwingend zu jeder RAG-Architektur: Eine einfache Implementierung übergibt die besten Treffer des Retrievers direkt an das Sprachmodell. Eine zweistufige Architektur lässt den ersten Retriever eine größere Kandidatenmenge liefern und einen Reranker diese kleinere Menge anschließend genauer bewerten.
NVIDIA dokumentiert genau diese Zweistufigkeit mit konfigurierbarer Kandidatenzahl im Retriever und einer eigenen, ebenfalls konfigurierbaren Anzahl an Chunks nach dem Reranker. Der Preis dafür ist zusätzlicher Rechenaufwand und zusätzliche Latenz im Antwortpfad.
Nach Retrieval, Filtern und gegebenenfalls Reranking steht fest, welche Informationen an das Sprachmodell gehen. Context Assembly bedeutet, aus Instruktionen, Benutzerfrage und gefundenen Informationen die Modelleingabe zusammenzusetzen. Hier findet die eigentliche Augmentation statt: Aus „Was bedeutet Object Lock?" wird sinngemäß „Beantworte die folgende Frage anhand dieser bereitgestellten Informationen".
Dabei ist mehr Kontext nicht automatisch besser. Ein Sprachmodell hat ein begrenztes Kontextfenster, und zusätzliche irrelevante Informationen verwässern die relevanten. Microsoft weist zudem auf einen Effekt hin, der in der Praxis oft unterschätzt wird: Sprachmodelle gewichten Anfang und Ende eines Prompts stärker als die Mitte. Genau deshalb ist Re-Ranking dort nicht nur eine Frage der Auswahl, sondern auch der Platzierung – die relevantesten Chunks gehören an den Anfang und ans Ende. Als weitere Schritte nach dem Retrieval nennt Microsoft das Filtern der Ergebnisse und Prompt Compression, bei der ein kleines, günstiges Modell die Chunks vor der Übergabe verdichtet.
Die Architekturaufgabe lautet damit nicht, möglichst viele Informationen zu finden, sondern möglichst geeignete für die konkrete Anfrage auszuwählen.
[BILD: Trichter vom breiten Retrieval über Filter und Reranking zum ausgewählten Kontext, mit Angabe der jeweils verbleibenden Trefferzahl]
Das Sprachmodell erzeugt die Antwort, nicht deren Grundlage
Erst am Ende dieser Kette kommt das Large Language Model zum Einsatz. Es erhält die Benutzerfrage, die Instruktionen und den abgerufenen Kontext und erzeugt daraus eine Antwort.
Damit wird deutlich, warum Retrieval und Generation getrennt betrachtet werden müssen. Der Retriever entscheidet, welche externen Informationen dem Modell überhaupt zur Verfügung stehen. Das Sprachmodell entscheidet anschließend, wie daraus eine Ausgabe wird. Es kann nur verwenden, was ihm vorgelegt wurde.
Das erklärt zugleich, warum die verbreitete Gleichsetzung von RAG mit einer Vektordatenbank zu kurz greift. Eine vollständige RAG-Verarbeitung benötigt Datenbereitstellung, Datenverarbeitung, Retrieval, Kontextbereitstellung und Generation. AWS führt für produktive Systeme darüber hinaus Konnektoren zu den Datenquellen, Guardrails, einen Orchestrator, die Benutzeroberfläche sowie Identitäts- und Benutzerverwaltung als eigenständige Komponenten auf. Die Vektordatenbank löst innerhalb dieser Architektur ein einzelnes Problem: Speicherung, Indexierung und Suche der Vektorrepräsentationen.
Warum RAG falsche Antworten nicht grundsätzlich verhindert
RAG stellt einem Sprachmodell relevante externe Informationen bereit. Daraus folgt nicht, dass jede Antwort korrekt ist. Die Kette enthält mehrere Stellen, an denen sie kippen kann.
Der Inhalt kann in der Quelle fehlen oder veraltet sein – dann hilft die beste Suche nichts. Er kann vorhanden, aber nicht sauber aus dem Dokument extrahiert worden sein, etwa weil eine Tabellenstruktur verloren ging. Er kann so ungünstig in Chunks zerlegt worden sein, dass der Zusammenhang zwischen Frage und Antwort auseinandergerissen wurde. Er kann korrekt im Index liegen und trotzdem für die konkrete Formulierung der Frage nicht gefunden oder zu niedrig bewertet werden. Er kann gefunden werden, aber nicht in den verfügbaren Kontext passen. Und schließlich kann das Sprachmodell den bereitgestellten Kontext falsch verarbeiten oder Aussagen erzeugen, die dieser Kontext nicht stützt.
Hinzu kommt ein Fehlerfall, der in Unternehmensumgebungen besonders schwer wiegt: Wird die Zugriffskontrolle nicht korrekt auf den Retrieval-Pfad übertragen, liefert das System Antworten, die auf Dokumenten beruhen, die der Fragende gar nicht sehen dürfte.
Gegen einen Teil dieser Fälle lassen sich Kontrollen einbauen. Microsoft sieht nach der Generierung einen Fact Check vor, der überprüfbare Tatsachenbehauptungen der Antwort gegenprüft, sowie einen Policy Check auf schädliche oder regelwidrige Inhalte. AWS führt Guardrails als eigene Komponente produktiver RAG-Systeme.
Die praktische Konsequenz: Wenn eine RAG-Anwendung falsche Antworten liefert, ist das Sprachmodell der letzte Kandidat auf der Fehlerliste, nicht der erste.
Naive, Advanced und Agentic RAG
Die einfachste Form einer RAG-Pipeline ist kurz: Frage, Vektorsuche, die besten Treffer, Sprachmodell. In der Literatur heißt das Naive RAG. Fortgeschrittene Systeme ergänzen zusätzliche Verarbeitungsschritte – Umschreiben der Frage, Zerlegung in Teilfragen, Metadatenfilter, Reranking, gezielte Kontextauswahl. Der Überblick von Gao und Kollegen unterscheidet entsprechend Naive RAG, Advanced RAG und Modular RAG.
Seit dieser Einteilung hat sich eine weitere Stufe etabliert. Bei Agentic RAG entscheidet ein Agent zur Laufzeit selbst, welche Suchen ausgeführt werden, bewertet die Zwischenergebnisse und iteriert, bis genügend Kontext vorliegt. Microsoft empfiehlt diesen Ansatz für komplexe mehrstufige Abfragen, die eine dynamische Quellenauswahl oder eine schrittweise Verfeinerung erfordern.
Die zusätzliche Komplexität ist allerdings kein Selbstzweck. Jede weitere Stufe kann Rechenleistung kosten, neue Fehlerzustände erzeugen und die Antwortzeit verlängern. Eine komplexere RAG-Architektur ist nicht automatisch eine bessere.
Was daraus für die Infrastruktur folgt
Aus dem Datenpfad wird erkennbar, dass RAG nicht nur eine Anforderung an KI-Inferenz erzeugt. Die einzelnen Phasen belasten die Infrastruktur unterschiedlich.
Der Source Storage hält die ursprünglichen Unternehmensdaten und wird vor allem über Kapazität, Zugriffsmethoden und Änderungsverhalten charakterisiert. Ingestion und Extraction lesen diese Daten und verarbeiten deren Inhalte; die Last hängt von Datenmenge, Dateianzahl, Formaten und Aktualisierungsrate ab. Die Erzeugung der Embeddings benötigt Rechenressourcen, und bei einer vollständigen Neuindexierung entstehen sehr viele solcher Operationen in kurzer Zeit. Retrieval, ein etwaiges Reranking und die Inferenz des Sprachmodells liegen dagegen im Online-Pfad der Benutzeranfrage, wo Suchzeit, Netzwerkwege und jeder zusätzliche Verarbeitungsschritt unmittelbar auf die Antwortzeit durchschlagen.
Es gibt deshalb nicht die eine Performance-Anforderung einer RAG-Anwendung. Eine Reindexierung großer Datenmengen hat ein völlig anderes I/O- und Compute-Profil als eine einzelne interaktive Abfrage. Wer nur eines von beiden dimensioniert, wird beim anderen überrascht.
Vor der Auswahl konkreter Produkte lohnt sich deshalb die Klärung einiger Grundfragen: Welche Datenquellen und Dateiformate sollen erschlossen werden, und wie zuverlässig lassen sich Inhalte daraus gewinnen? Nach welcher Logik werden Dokumente zerlegt, und welche Metadaten müssen dabei erhalten bleiben? Wie gelangen Berechtigungen in den Retrieval-Pfad? Reicht Vektorsuche, oder wird hybride Suche benötigt? Wie aktuell muss die Wissensbasis sein, und wie werden Änderungen und Löschungen erkannt? Welche Antwortzeit ist akzeptabel?
Eine Frage steht dabei über den anderen: Wie werden Retrieval-Qualität und Antwortqualität getrennt bewertet? Eine falsche Antwort beweist nicht, dass das Sprachmodell ungeeignet ist. Die Ursache kann genauso in Extraction, Chunking, Retrieval, Ranking oder Kontextauswahl liegen – und ohne getrennte Messung lässt sich das nicht auseinanderhalten.
[QUERVERWEIS: KI-Architektur – Infrastrukturanforderungen von KI-Workloads] [QUERVERWEIS: High-Performance Data Access – Latenz und Durchsatz im Datenpfad]
Fazit
Eine RAG-Architektur ist keine Vektordatenbank mit angeschlossenem Sprachmodell. Sie ist eine mehrstufige Verarbeitungs-, Retrieval- und Inferenzarchitektur mit zwei Datenpfaden: Der eine bereitet Wissen auf, der andere beantwortet damit eine Frage.
Die Qualität einer RAG-Anwendung entsteht dabei lange, bevor das Sprachmodell antwortet. Wird ein relevantes Dokument nicht aufgenommen, sein Inhalt fehlerhaft extrahiert, ungünstig aufgeteilt oder bei der Suche nicht gefunden, kann das Modell diese Information im letzten Schritt nicht mehr verwenden.
Für die Infrastrukturplanung folgt daraus eine zweite Erkenntnis. Ingestion, Indexierung, Retrieval, Reranking und Inferenz haben jeweils eigene Anforderungen an Storage, Compute, Netzwerk, Durchsatz und Latenz. Wer eine RAG-Architektur verstehen oder dimensionieren will, sollte deshalb nicht beim Sprachmodell beginnen, sondern beim vollständigen Weg der Information – von der ursprünglichen Unternehmensdatei bis zu dem Kontext, den das Modell für eine konkrete Antwort tatsächlich erhält.
Quellen
Lewis, Patrick; Perez, Ethan; Piktus, Aleksandra et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33 (NeurIPS 2020), S. 9459–9474.
Gao, Yunfan; Xiong, Yun; Gao, Xinyu et al.: Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997, Erstveröffentlichung Dezember 2023, letzte Revision März 2024.
Amazon Web Services: Understanding Retrieval Augmented Generation. In: Retrieval Augmented Generation options and architectures on AWS, AWS Prescriptive Guidance. Abruf: 2. September 2026.
Amazon Web Services: Retrievers for RAG workflows. In: Retrieval Augmented Generation options and architectures on AWS, AWS Prescriptive Guidance. Abruf: 2. September 2026.
Amazon Web Services: Data lifecycle in generative AI. In: Data considerations for generative AI strategy, AWS Prescriptive Guidance. Abruf: 2. September 2026.
Microsoft: Build advanced retrieval-augmented generation systems. Microsoft Learn, Stand 30. Januar 2026. Abruf: 2. September 2026.
Microsoft: Develop a RAG Solution on Azure – Information-Retrieval Phase. Azure Architecture Center. Abruf: 2. September 2026.
Microsoft: Develop an Agentic RAG Solution on Azure. Azure Architecture Center. Abruf: 2. September 2026.
NVIDIA: Query-to-Answer Pipeline. NVIDIA RAG Blueprint 2.5.0. Abruf: 2. September 2026.
NVIDIA: Continuous Ingestion from Object Storage. NVIDIA RAG Blueprint 2.5.0. Abruf: 2. September 2026.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
