RAG-Architekturdiagramm: So fügt sich eine Retrieval-Augmented-Generation-App zusammen

Die meisten RAG-Architekturdiagramme haben drei Boxen: einen Nutzer, eine Vektordatenbank und ein LLM. Das reicht, um die Idee in einem Meeting zu erklären. Beim Betrieb des Systems hilft das Bild niemandem, weil die Entscheidungen fehlen, die über Antwortqualität und Sicherheit entscheiden: wie Dokumente gechunkt werden, welches Embedding-Modell zum Einsatz kommt, wer welchen Chunk sehen darf, wie Ergebnisse gerankt werden und woran jemand erkennt, dass die Antworten gut sind.

Dieser Guide zeichnet das vollständige Bild einer Retrieval-Augmented-Generation-App als zwei Pfade um gemeinsame Modelle und Speicher und behandelt dann, was du beschriften solltest und welche Fehler am häufigsten vorkommen.

Zwei Pfade, nicht einer

Der Begriff stammt von Lewis et al. (2020), die ein Sprachmodell mit einem dichten Vektorindex der Wikipedia kombinierten, den ein Retriever während der Generierung durchsuchte. Die meisten RAG-Apps in Produktion übernehmen die Idee, ohne die Teile gemeinsam zu trainieren: relevante Passagen abrufen, in den Prompt legen und das Modell bitten, daraus zu antworten.

Damit hat jede RAG-App zwei Pfade:

• Ingestion läuft fortlaufend im Hintergrund. Sie macht aus Dokumenten Chunks, Vektoren und Metadaten.
• Query läuft einmal pro Frage. Sie macht aus einer Frage eine Antwort mit Quellen.

Beide treffen sich an den gemeinsamen Teilen: dem Embedding-Modell, das auf beiden Pfaden in derselben Version laufen muss, dem Vektorindex und dem Metadatenspeicher. Ein Diagramm, das nur den Query-Pfad zeigt, versteckt die Hälfte des Systems und die meisten Bugs.

Der Ingestion-Pfad

1. Quellen und Änderungserkennung. Konnektoren, Webhooks oder ein Crawler bemerken neue, geänderte und gelöschte Dokumente und legen Jobs in eine Queue. Löschungen und Berechtigungsänderungen sind ebenfalls Jobs.
2. Parsing. Extrahiere den Text und erhalte dabei die Struktur: Überschriften, Listen, Tabellen und Metadaten wie Titel, URL, Owner, letzte Aktualisierung und Zugriffssteuerungsliste.
3. Chunking. Teile zuerst entlang der Dokumentstruktur, dann nach Größe. Chunk-Größe und Überlappung sind Parameter, die du mit deinen eigenen Fragen abstimmst, keine allgemeingültigen Zahlen. Halte den Überschriftenpfad in jedem Chunk fest, damit ein Absatz auch für sich allein verständlich bleibt.
4. Embedding. Ruf ein einziges Embedding-Modell auf und pinne seine Version. Speichere Modellname und Version mit jedem Vektor. Vektoren aus verschiedenen Modellen sind nicht vergleichbar; ein Modellwechsel heißt also, den ganzen Korpus neu einzubetten.
5. Indexierung. Führe für jeden Chunk ein Upsert mit Vektor, Dokument-ID, Chunk-Nummer, Version und Zugriffs-Tags aus. Wenn du hybride Suche planst, halte neben dem Vektorindex einen Keyword-Index vor.
6. Aktualisierung und Löschung. Mach Upserts idempotent, lösche die Chunks entfernter Dokumente und verfolge die Aktualität: wie lange eine Änderung in der Quelle braucht, bis sie im Index ist.

Der Query-Pfad

1. Nutzer identifizieren. Löse die Gruppen des Nutzers auf, bevor das Retrieval beginnt.
2. Frage umformulieren (optional). Eine Folgefrage wie „Und für externe Mitarbeiter?“ muss mithilfe des Gesprächs zu einer eigenständigen Anfrage werden.
3. Abrufen. Die Vektorsuche findet Passagen mit ähnlicher Bedeutung; die Keyword-Suche findet exakte Begriffe wie Fehlercodes und Produktnamen. Hybride Suche führt beide aus und führt die Listen zusammen, oft mit Reciprocal Rank Fusion, die jedes Dokument mit 1/(k + Rang) bewertet, summiert über die Listen. Das ursprüngliche RRF-Paper legte k auf 60 fest.
4. Innerhalb der Abfrage nach Berechtigung filtern. Übergib die Gruppen des Nutzers als Filter auf die Zugriffs-Tags, damit Chunks, die der Nutzer nicht sehen darf, nie den Prompt erreichen. Prüf, wie dein Speicher Filter anwendet. Die Dokumentation von pgvector weist darauf hin, dass der Filter bei approximativen Indexen nach dem Index-Scan läuft: Mit dem HNSW-Standardwert ef_search von 40 liefert ein Filter, der auf 10 % der Zeilen passt, im Schnitt etwa 4 Zeilen. Iterative Scans, partielle Indexe oder Partitionierung beheben das.
5. Reranking. Ruf großzügig ab, zum Beispiel 50 Kandidaten, und lass ein Reranking-Modell sie gegen die Frage bewerten. Behalte die besten wenigen, zum Beispiel 8.
6. Prompt aufbauen. Anweisungen, die ausgewählten Chunks mit IDs und Titeln und die Frage, innerhalb eines Token-Budgets. Bitte um Quellenangaben per Chunk-ID.
7. Generieren und zitieren. Ruf das LLM auf, streame die Antwort und mach aus Chunk-IDs Links, die der Nutzer prüfen kann.

Rund um beide Pfade

• Behandle abgerufenen Text als nicht vertrauenswürdige Eingabe. Ein Dokument kann Anweisungen an das Modell enthalten. OWASP führt das als indirekte Prompt-Injection. Halte die Tools und Daten, die das Modell erreichen kann, so eng wie den Zugriff des Nutzers selbst.
• Trace jeden Request. Logge die umformulierte Anfrage, die abgerufenen und gererankten Chunk-IDs mit Scores, die Prompt-Version, die Modellversionen und die Latenz jedes Schritts.
• Evaluiere mit einem festen Fragenkatalog. Führ ihn bei jeder Änderung an Chunking, Modellen, Retrieval oder Prompt aus. Das RAGAS-Paper nennt drei nützliche Dimensionen: Treue zum abgerufenen Kontext, Relevanz der Antwort und Relevanz des Kontexts. Prüf außerdem, ob die erwartete Quelle unter den ersten Ergebnissen ist.
• Cache mit Bedacht. Query-Embeddings zu cachen ist meist unbedenklich. Antworten zu cachen ist nur pro Berechtigungsmenge sicher.

Das Diagramm

So liest du es:

• Links, Ingestion. Änderungen in den Quellen werden zu Jobs in einer Queue. Der Ingestion-Worker parst und chunkt jedes Dokument, ruft das Embedding-Modell auf, führt Upserts von Chunks und Vektoren mit Zugriffs-Tags in den Vektorindex aus und schreibt Dokument-Metadaten nach Postgres.
• Mitte, gemeinsame Modelle und Speicher. Dasselbe gepinnte Embedding-Modell bedient beide Pfade. Auch das LLM liegt hier und wird nur vom Query-Pfad aufgerufen.
• Rechts, Query. Die RAG-API ermittelt die Gruppen des Nutzers, bettet die Frage ein, führt die hybride Suche mit Berechtigungsfilter aus, schickt 50 Kandidaten an den Reranker und ruft das LLM mit den besten 8 Chunks auf.
• Unten links. Ein beispielhaftes Latenzbudget pro Schritt, damit sich eine langsame Antwort bis zu dem Schritt zurückverfolgen lässt, der sein Budget überschritten hat.

Was du beschriften solltest

• Modellversionen an jedem Modell-Node, auch am Embedding-Modell.
• Chunking-Parameter am Ingestion-Worker oder in einer Notiz.
• Wo Berechtigungen durchgesetzt werden, an der Retrieval-Kante, nicht in einer Fußnote.
• Wie viele Ergebnisse fließen zwischen den Schritten: 50 abgerufen, 8 im Prompt.
• Aktualitäts- und Latenzziele: wie schnell eine Änderung in der Quelle durchsuchbar ist und welches Budget jeder Query-Schritt hat.

Typische Fehler

• Eine Box namens „KI“. Retrieval, Reranking und Generierung scheitern auf verschiedene Weise und brauchen eigene Boxen.
• Kein Ingestion-Pfad. Veraltete oder fehlende Antworten beginnen oft dort.
• Keine Berechtigungen. Enthält der Index Dokumente für verschiedene Zielgruppen, beschreibt ein Diagramm ohne Zugriffs-Tags ein Datenleck.
• Keine Evaluierung. Ohne Fragenkatalog ist jede Änderung an Prompt oder Chunk-Größe geraten.
• Gemischte Embedding-Versionen. Den halben Korpus mit einem neuen Modell neu einzubetten, macht die Suche still und leise kaputt.

Wann RAG nicht die Antwort ist

• Die Antwort steckt in strukturierten Daten. Frag die Datenbank oder eine API ab, statt Tabellenzeilen einzubetten.
• Die Aufgabe braucht ein ganzes Dokument. Einen einzelnen Vertrag zusammenzufassen, klappt besser mit dem ganzen Vertrag im Prompt, sofern er hineinpasst.
• Der Korpus ist winzig. Ein paar Seiten können direkt in den Prompt.
• Du brauchst anderes Verhalten, nicht mehr Wissen. Das ist ein Prompt- oder Fine-Tuning-Problem.

Für ereignisgesteuerte Ingestion mit Queues siehe den Guide ereignisgesteuerte Architektur als Diagramm.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge zwei Rahmen aus dem Basis-Pack hinzu: „Ingestion path“ links und „Query path“ rechts.
3. Füge im Ingestion-Rahmen eine Objektablage aus dem Daten-Pack für die Quelldokumente hinzu, eine Warteschlange aus dem Daten-Pack für die Ingestion-Jobs und einen Container aus dem C4-Modell-Pack für den Ingestion-Worker.
4. Füge in der Mitte ein Modell aus dem ML-Pack für das Embedding-Modell hinzu, einen Vektorindex aus dem ML-Pack, Postgres aus dem Daten-Pack für Metadaten und Berechtigungen und ein zweites Modell für das LLM.
5. Füge im Query-Rahmen eine Person aus dem C4-Modell-Pack für den Nutzer hinzu, einen Container für die RAG-API und ein Modell aus dem ML-Pack für den Reranker.
6. Beschrifte jede Kante mit dem, was über sie fließt, einschließlich „top 50“ und „top 8“, und leg das Latenzbudget in einen Markdown-Block aus dem Basis-Pack.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan. Wenn du mit einem KI-Agenten arbeitest, kann er dir anhand einer Beschreibung beider Pfade über MCP eine erste Version zeichnen; siehe So erstellst du Architekturdiagramme mit KI-Agenten. Die allgemeine Methode findest du unter Wie du ein Softwarearchitektur-Diagramm zeichnest.

FAQ

Brauche ich für RAG eine eigene Vektordatenbank? Nein. Eine Vektor-Erweiterung in einer Datenbank, die du ohnehin betreibst, etwa pgvector in PostgreSQL, oder eine Suchmaschine mit Vektorunterstützung reicht für viele Apps. Wähle nach Korpusgröße, Filteranforderungen und dem, was dein Team gut betreiben kann.

Welche Chunk-Größe sollte ich nehmen? Es gibt keine allgemeingültige Zahl. Teile entlang von Überschriften und Absätzen und vergleiche dann ein paar Größen und Überlappungen mit deinem eigenen Fragenkatalog.

Wo sollten Berechtigungsprüfungen stattfinden? Bei der Ingestion, indem du die Zugriffsliste jedes Dokuments in seine Chunks kopierst, und beim Retrieval, indem du danach filterst. Verlass dich nie darauf, dass der Prompt Inhalte verbirgt.

Wie evaluiere ich eine RAG-App? Pflege einen festen Satz echter Fragen mit erwarteten Quellen. Miss, ob das Retrieval diese Quellen findet und ob die Antworten dem abgerufenen Kontext treu und für die Frage relevant sind.

Sollte das LLM Tools aufrufen statt RAG zu nutzen? Für Live- oder strukturierte Daten ja: Ein Tool, das das führende System abfragt, schlägt einen Index aus Kopien. Viele Apps nutzen beides.

Kostenlos starten — ein Seat, keine Kreditkarte.