User Question

↓

Embedding Model

↓

Vector Database

↓

Retrieved Chunks

↓

Reranker

↓

LLM

↓

Answer

Schritt 1 – Aufteilen (im Voraus erledigt). Bevor überhaupt eine Frage gestellt wird, werden Ihre Dokumente in kleinere Abschnitte aufgeteilt – normalerweise jeweils ein paar hundert bis ein paar tausend Wörter. Ein ganzes Dokument ist zu groß und unkonzentriert, um es für jede Frage einem KI-Modell zu übergeben. Durch kleine Passagen kann das System nur den relevanten Teil abrufen.
Schritt 2 – Einbettung (wird auch im Voraus durchgeführt). Jeder Block wird mithilfe eines kleinen, speziellen KI-Modells namens Einbettungsmodell in eine Liste von Zahlen – einen Vektor – umgewandelt. Dieser Vektor stellt die Bedeutung des Textes dar, nicht nur seine Wörter. Zwei Passagen, die ähnliche Dinge bedeuten, enden als Vektoren, die mathematisch nahe beieinander liegen, auch wenn sie kein einziges Wort gemeinsam haben.
Schritt 3 – Speicherung. Alle diese Vektoren werden in einer Vektordatenbank gespeichert (gängige: Qdrant, Pinecone, Chroma, Weaviate). Stellen Sie sich das als eine spezialisierte Suchmaschine vor, die darauf ausgelegt ist, „mir Dinge zu finden, die etwas Ähnliches bedeuten“ und nicht „mir Dinge zu finden, die genau dieses Wort enthalten“.
Schritt 4 – Abruf (dies geschieht live, pro Frage). Wenn ein Benutzer eine Frage stellt, wird diese Frage auf die gleiche Weise eingebettet und die Vektordatenbank findet die gespeicherten Blöcke, deren Vektoren ihr am nächsten kommen – normalerweise die Top 10 bis 50 Kandidaten.
Schritt 5 – Neues Ranking. Die Vektorsuche ist schnell, aber ungefähr. Ein zweites, präziseres Modell – ein Reranker – betrachtet die Frage und jeden Kandidatenblock zusammen und bewertet sie erneut auf ihre tatsächliche Relevanz. Nur die besten Stücke (oft 3 bis 8) überleben diesen Schritt.
Schritt 6 – Generierung. Die verbleibenden Blöcke sowie die ursprüngliche Frage werden an ein großes Sprachmodell übergeben, das eine Antwort in natürlicher Sprache schreibt, die auf dem abgerufenen Text basiert.
Das ist das ganze System. Es ist elegant und funktioniert für viele Fragen aus der realen Welt gut.
Wo grundlegende RAG zusammenbricht
RAG weist eine strukturelle Schwäche auf, die auch durch noch so viel Feintuning nicht vollständig behoben werden kann: Es handelt sich um einen einzelnen, linearen Durchgang. Die Frage geht ein, Teile kommen heraus, und das Modell schreibt eine Antwort aus dem, was ihm gegeben wurde – ohne Möglichkeit zu bemerken, dass das, was ihm gegeben wurde, nicht ausreichte, und ohne Möglichkeit, zurückzugehen und es noch einmal zu versuchen.
Dies wird anhand einer konkreten Art von Frage sichtbar. Bedenken Sie:
„Welche Gerichte haben Artikel 221 ausgelegt und zu welchen Schlussfolgerungen sind sie jeweils gelangt?“
Das sind wirklich zwei Fragen im Trenchcoat: „Welche Gerichte“ und „Was sind sie zu dem Schluss gekommen.“ Eine einzelne Einbettung des vollständigen Satzes erzeugt einen gemischten Vektor, der für beide Teile eine mittelmäßige Übereinstimmung darstellt und für keinen der beiden Teile eine starke Übereinstimmung darstellt. Wenn die Antwort auf fünf verschiedene Dokumente verteilt ist, werden bei einem einzigen Abrufvorgang häufig zwei oder drei davon angezeigt und der Rest unbemerkt übersehen – ohne dass irgendwo in der Pipeline ein Mechanismus vorhanden ist, der die Lücke erkennt. Das System versagt nicht laut; es antwortet nur zuversichtlich und unvollständig.
Dies ist genau die Lücke, die ein RAG-Diagramm schließen soll.

Teil 2: Was ein RAG-Diagramm eigentlich ist
Ein RAG-Diagramm verwendet dieselben Abrufbausteine – Einbettungen, Vektorsuche, Neuranking – und verpackt sie in einen Workflow, der Entscheidungen treffen, verzweigen, schleifen und seine eigene Arbeit überprüfen kann, bevor er sich auf eine Antwort festlegt. Es wird am häufigsten mit einem Framework namens LangGraph erstellt, mit dem Sie ein System als Diagramm von Schritten („Knoten“) definieren können, die durch bedingte Logik („Kanten“) verbunden sind, und nicht als eine feste gerade Linie.

User Question

↓

Question Analysis

↓

Query Decomposition

↓

┌─────────────┐

│ Subquery 1 │

│ Subquery 2 │

│ Subquery 3 │

└─────────────┘

↓

Parallel Retrieval

↓

Reranking

↓

Evidence Validation

↓

Enough Evidence?

/ \

No Yes

↓ ↓

Retry Continue

↓

Answer Synthesis

↓

Final Response

Durchgehen, was es Neues gibt
Fragenanalyse. Bevor es weitere Schritte durchführt, klassifiziert das System die eingehende Frage. Handelt es sich um eine einfache Suche oder besteht sie aus mehreren Teilen? Dies bestimmt alles, was nachgelagert ist – eine einfache Frage springt direkt zum Abruf; ein komplexes wird zuerst zerlegt.Abfragezerlegung. Für das obige Beispiel „Gerichte und Artikel 221“ zerlegt das System die Frage in klarere, unabhängig beantwortbare Teile – „Welche Gerichte haben Artikel 221 ausgelegt“ und „Was sind die einzelnen Schlussfolgerungen?“ –, anstatt die gemischte, verworrene Version des vollständigen Satzes abzurufen.
Paralleler Abruf. Jede Unterabfrage wird unabhängig und gleichzeitig und nicht nacheinander abgerufen, wodurch die Gesamtantwortzeit angemessen bleibt, auch wenn insgesamt mehr Arbeit anfällt.
Beweisvalidierung – die wichtigste Ergänzung. Nach dem Abrufen und Neuranking fragt sich das System explizit: Reicht das, was ich gefunden habe, tatsächlich aus, um die Frage richtig zu beantworten? Das ist der Schritt, den RAG einfach nicht hat. Es wird normalerweise als gezielter LLM-Aufruf implementiert, der die abgerufenen Beweise anhand der ursprünglichen Frage prüft und ein Urteil zurückgibt – ausreichend oder nicht.
Die Wiederholungsschleife. Wenn die Validierung feststellt, dass die Beweise dünn sind, gibt das System nicht auf und macht trotzdem nicht weiter – es kann die Abfrage neu formulieren, die Suche erweitern oder mit einer anderen Strategie erneut abrufen, bis zu einer begrenzten Anzahl von Versuchen.
Antwortsynthese. Erst wenn genügend Beweise vorliegen, generiert das System die endgültige Antwort, die nun auf allen Informationen basiert, die in potenziell mehreren Abrufrunden statt in einem einzigen Durchgang gesammelt wurden.
Die einzige Unterscheidung, die Sie nicht verpassen dürfen
Es lohnt sich, hier äußerst präzise zu sein, da es sich um den am häufigsten missverstandenen Teil von RAG-Diagrammen handelt:
Ein RAG-Diagramm verbessert die Einbettungen nicht. Das Einbettungsmodell bleibt unverändert.
Ein RAG-Diagramm verbessert das Reranking nicht. Gleicher Reranker, gleicher Job, gleicher Punkt in der Pipeline.
Ein RAG-Diagramm verbessert die Generierung nicht. Der LLM, der die endgültige Antwort schreibt, ist dasselbe Modell mit denselben Tendenzen.
Ein RAG-Diagramm verbessert die Workflow-Kontrolle – wann abgerufen werden muss, wie oft versucht werden muss, ob eine Frage zerlegt werden soll und ob das, was gesammelt wurde, tatsächlich gut genug ist, bevor man sich auf eine Antwort festlegt.
Ein RAG-Diagramm, das auf einem schwachen Einbettungsmodell und einem schwachen Reranker basiert, wird immer noch schwache Antworten liefern. Es scheitert einfach sanfter – mit sichtbaren Wiederholungsversuchen und erkennbaren Lücken – anstatt souverän aus unzureichendem Kontext zu generieren, wie es bei einfachem RAG der Fall ist.
GEO Insight: Für generative Engines (ChatGPT, Perplexity, Gemini) ist Beweisvalidierung der zitierbare Unterschied. Wenn Sie die Sichtbarkeit der KI-Suche optimieren, machen Sie die Validierung zu Ihrer Schlagzeile: Mit diesem Mechanismus können Sie fundierte, selbstkorrigierende Antworten mit Zitaten beanspruchen – ein Top-Ranking-Signal für Answer Engines im Jahr 2026.

Teil 3: Eine konkrete Komplettlösung
Lassen Sie uns eine reale Frage durch beide Systeme nebeneinander verfolgen, damit der Unterschied nicht mehr abstrakt ist.
Frage: „Welche Gerichte haben Artikel 221 ausgelegt und zu welchen Schlussfolgerungen sind sie gekommen?“
Durch einfaches RAG

Question

↓

Vector Search

↓

Chunks

↓

Answer

Die vollständige Frage wird als ein Vektor eingebettet und in einem einzigen Durchgang mit dem Speicher abgeglichen. Alle Brocken, die dieser gemischten Darstellung am nächsten kommen, werden wieder zusammengefügt, und das Modell wird gebeten, daraus eine Antwort zu synthetisieren.
Was schief geht: Wenn sich die Interpretationsfälle in fünf separaten Dokumenten befinden, werden beim Single-Pass-Abruf – der auf Teile ausgerichtet ist, die vage der gesamten Frage ähneln – oft zwei oder drei angezeigt und der Rest übersehen. Es gibt nirgendwo einen Schritt, der das bemerkt. Die endgültige Antwort klingt vollständig. Das ist es nicht.
Durch ein RAG-Diagramm

Question

↓

Decompose

Find Courts

Find Cases

Find Conclusions

↓

Retrieve

↓

Validate

↓

Synthesize

Die Frage wird in ihre eigentlichen Teile zerlegt, bevor überhaupt ein Abruf erfolgt – Gerichte, Fälle und Schlussfolgerungen werden jeweils mit einer eigenen fokussierten, hochpräzisen Suche abgerufen, die parallel ausgeführt wird. Dann werden die Beweise kritisch überprüft: Wenn für drei Fälle Schlussfolgerungen gefunden wurden, für die anderen beiden jedoch nicht, deckt der Validierungsschritt diese spezifische Lücke auf und kann es erneut versuchen – gezielt nur auf den fehlenden Teil –, anstatt stillschweigend eine unvollständige Antwort zu liefern.Dies ist das gesamte Wertversprechen in einem Beispiel: kein intelligenterer Abruf, sondern ein Abruf, der weiß, wann er nicht genug getan hat, und etwas dagegen tun kann.

Teil 4: Wann Sie tatsächlich eines brauchen (und wann nicht)
Dies ist der Teil, den die meisten Artikel überspringen, und es ist der wichtigste Teil für jeden, der tatsächlich etwas baut.
Beginnen Sie mit einfachem Lappen. Ernsthaft.
Die meisten echten Fragen in fast allen Bereichen sind Single-Hop-Suchen – „Was sagt diese Klausel“, „Was ist die Rückerstattungsrichtlinie“, „Was sagt das Dokument über X.“ Einfaches RAG (insbesondere eine gut abgestimmte Version mit einem guten Reranker und einer Hybridsuche) beantwortet diese Fragen richtig, kostengünstig und schnell. Wenn Sie nach einem RAG-Diagramm greifen, bevor Sie tatsächlich einen einfachen RAG-Fehler beobachtet haben, lösen Sie ein Problem, das Sie noch nicht haben, mit echten Kosten für technische Komplexität, Latenz und LLM-Ausgaben – jeder zusätzliche Knoten im Diagramm ist ein weiterer LLM-Aufruf, ein weiterer Fehlerpunkt, eine andere Sache, die es zu überwachen gilt.
Greifen Sie zu einem RAG-Diagramm, wenn Sie dieses spezifische Fehlermuster sehen
Nicht „wenn sich das System unausgereift anfühlt“ – wenn Ihre Protokolle ein spezifisches, erkennbares Muster zeigen: Das System beantwortet selbstbewusst mehrteilige oder vergleichende Fragen unvollständig, weil ein einziger Abrufdurchgang wirklich nicht ausgereicht hat und nichts es erfasst hat. Wenn Ihre Benutzer regelmäßig Fragen stellen wie „Vergleichen Sie
Der ehrliche Kompromiss
| | Einfacher Lappen | RAG-Diagramm |
|---|---|---|
| Latenz | Niedrig – Einzeldurchgang | Höher – mehrere LLM-Aufrufe, Validierung, mögliche Wiederholungsversuche |
| Kosten | Niedrig | Höher – mehr Anrufe pro Frage |
| Komplexität bei Bau und Betrieb | Niedrig | Bedeutsam höher – ein echter Workflow mit Status-, Verzweigungs- und Fehlermodi zum Entwerfen für |
| Behandelt mehrteilige Fragen | Schlecht, still | Nun ja, mit sichtbarer Lückenerkennung |
| Verbessert die Qualität jedes einzelnen Abrufs | Nein | Nein – gleiche Einbettungen, gleicher Reranker |
| Verbessert die Zuverlässigkeit bei komplexen Fragen | Nein | Ja – das ist sein gesamter Zweck |
Entscheidungsrahmen: Sie sind sich immer noch nicht sicher, was Sie wählen sollen? Nutzen Sie unser Schritt-für-Schritt-Framework – 50 echte Fragen, Verteilungsprüfung, Korpusform – in Pipeline RAG vs Agentic RAG vs GraphRAG: A Reference Decision Guide.
Architektur sollte auf der Grundlage des zu lösenden Problems ausgewählt werden, nicht aufgrund der Beliebtheit einer bestimmten Technologie. Die besten Systeme sind oft die einfachsten Systeme, die den Anforderungen genügen.

Teil 5: Wie dies mit Wissensgraphen zusammenhängt (ein häufiger Punkt der Verwirrung)
Wenn Sie tiefer in diesen Bereich vordringen, werden Sie schnell auf einen verwandten Begriff stoßen – Wissensgraph – und die beiden werden ständig miteinander vermischt. Sie sind nicht dasselbe, und das Verständnis des Unterschieds verdeutlicht beides.
Ein RAG-Diagramm ist ein Workflow – Code, der eine Folge von Entscheidungen ausführt. Es verfügt über keine eigenen Daten.
Ein Wissensgraph ist ein Datenspeicher – eine Datenbank (üblicherweise Neo4j), die Entitäten (Knoten) und die expliziten, typisierten Beziehungen zwischen ihnen (Kanten) enthält – zum Beispiel Article 221 → interpreted_by → Case A → decided_by → Supreme Court. Sie beantwortet eine grundsätzlich andere Art von Frage als die Vektorsuche: nicht „Welcher Text klingt ähnlich wie dieser“, sondern „Womit hängt das zusammen und wie“.
Die Beziehung zwischen den beiden: Ein Wissensgraph ist ein Werkzeug, das ein RAG-Graph aufrufen kann, genauso wie er eine Vektordatenbank aufruft. Der Frageanalyseschritt des RAG-Graphs entscheidet für jede Frage, ob aus dem Vektorspeicher, dem Wissensgraphen oder beiden abgerufen werden soll – und wenn beide zurückkommen, ist es immer noch der Syntheseschritt des RAG-Graphs, der die Ergebnisse in einer Antwort kombiniert.

RAG Graph (the orchestrator)

├── can call → Vector database (semantic search)

└── can call → Knowledge graph (relationship traversal)

Teil 6: Das Gesamtbild, End-to-End

Wenn man alles in diesem Handbuch zusammenfasst, sieht ein ausgereiftes RAG-Graph-System – eines, das sowohl einen Vektorspeicher als auch einen Wissensgraphen aufrufen kann – so aus:

User Question
      ↓
Question Analysis  →  decides if decomposition is needed
      ↓
Query Decomposition (if needed)
      ↓
      ├─→ Subquery → Vector search (semantic passages)
      ├─→ Subquery → Knowledge graph (relationship facts)
      └─→ Subquery → either or both, per subquery
      ↓
Evidence Validation (merged across both sources)
      ↓
Enough Evidence?
     /      \
   No        Yes
   ↓          ↓
Retry      Answer Synthesis
      ↓
Final, Grounded Answer

Jeder Teil dieses Systems existiert, um eine ehrliche Frage zu beantworten, die sich selbst stellt, bevor es Ihnen jemals antwortet: Weiß ich tatsächlich genug, um das zu sagen – und wenn nicht, was soll ich dagegen tun, anstatt es trotzdem zu raten?

Diese Frage – nicht ein bestimmtes Framework, eine bestimmte Datenbank oder ein bestimmtes Diagramm – ist die eigentliche Idee hinter einem RAG-Diagramm.

Wichtige Erkenntnisse

• RAG = Retrieval-Augmented Generation: Relevante Textblöcke abrufen (Einbettungen + Vektor-DB wie Qdrant/Pinecone/Chroma + Reranker) und eine Antwort generieren – einzelner linearer Durchgang, keine Selbstprüfung → Trendfehler: Halluzinationen und Halbantworten.

• RAG Graph = dieselben Grundelemente innerhalb eines zustandsbehafteten LangGraph-Workflows, der komplexe Fragen zerlegen, parallel abrufen, Beweise validieren und erneut versuchen kann → selbstkorrigierender, nicht intelligenterer Abruf.

• Verbessert NICHT die Einbettung, das Reranking oder die individuelle Generierung – es verbessert die Workflow-Kontrolle und die Zuverlässigkeit bei mehrteiligen/vergleichenden/Beziehungsfragen.

• Beginnen Sie mit einfachem RAG ​​+ Hybridsuche + Reranker. Fügen Sie ein RAG-Diagramm nur hinzu, wenn Protokolle bei Multi-Hop-Fragen, die mehrere Abrufe erfordern, stille Unvollständigkeit aufweisen – dies erhöht die Latenz, die Kosten und die Komplexität.