GraphRAG- & RAG-Architektur

Die Kluft zwischen „semantisch ähnlichen Chunks“ und „korrekten, vollständigen Antworten“ ist der Punkt, an dem die meisten Enterprise-RAG-Deployments scheitern. Das AI Lab von Stanford stellte fest, dass 40% der RAG-Antworten selbst dann halluzinieren, wenn die richtigen Dokumente abgerufen werden. Das Retrieval funktionierte. Das Grounding nicht.

Warum RAG Dokumente abruft, keine Antworten

Das geschieht, weil die standardmäßige Vektorähnlichkeit nicht zwischen einer Passage unterscheiden kann, die thematisch relevant ist, und einer, die die Frage tatsächlich beantwortet. Wenn Ihr Compliance-Team fragt: „Welche Meldepflichten gelten für eine Datenschutzverletzung, die EU-Bürger unter 16 Jahren betrifft?“, und Ihr System liefert drei Chunks über DSGVO-Verletzungsmeldungen ohne die altersspezifischen Bestimmungen zurück, sieht die Antwort zwar passend aus, ist jedoch gefährlich unvollständig.

Unser Ansatz besteht darin, Retrieval-Systeme zu entwickeln, die genau diese Lücke schließen. Welche Architektur wir wählen, hängt von Ihren Dokumenten, Ihren Abfragemustern und Ihrer Fehlertoleranz ab. Manchmal ist das ein hybrides BM25- und Dense-Retrieval mit einem Cross-Encoder-Reranker. Manchmal ist es eine vollständige GraphRAG-Pipeline mit Entitätsextraktion und Community-Zusammenfassungen. Manchmal ist es eine agentische Retrieval-Schleife, die komplexe Fragen zerlegt, iterativ abruft und sich vor der Generierung selbst korrigiert. Wir wählen nicht standardmäßig die komplexeste Option – wir wählen diejenige, die Ihr Retrieval-Problem zu tragfähigen Kosten löst.

Drei Retrieval-Architekturen, abgestimmt auf Ihre Abfragemuster

Wir passen die Architektur an Ihre Abfragemuster an, anstatt standardmäßig auf Komplexität zu setzen. Die drei folgenden Muster decken die meisten Produktionsanforderungen ab.

Hybrides Retrieval mit Reranking

Hier sollten die meisten produktiven RAG-Systeme beginnen. BM25 übernimmt den exakten Keyword-Abgleich (Fehlercodes, Produkt-SKUs, behördliche Aktenzeichen), während dichte Embeddings (Dense Embeddings) die semantische Absicht erfassen. Reciprocal Rank Fusion (RRF, k=60) führt die beiden Ergebnismengen zusammen, ohne die Score-Normalisierungsprobleme, mit denen gelernte Fusionsansätze zu kämpfen haben.

Ein Cross-Encoder-Reranker bildet die darüberliegende Schicht: BGE-reranker-v2-m3 auf GPU liefert 50–100ms Latenz bei null laufenden API-Kosten, oder Cohere Rerank für Teams, die eine verwaltete Infrastruktur bevorzugen. Produktions-Benchmarks belegen, dass diese zweistufige Pipeline alle einstufigen Methoden übertrifft. Anthropics kontextuelles Retrieval wird als zusätzliche Schicht aufgesetzt und senkt Retrieval-Fehler um 49% (67% mit Reranking), indem jedem Chunk vor dem Embedding kontextbezogene Informationen auf Dokumentenebene vorangestellt werden.

Graph-unterstütztes Retrieval (GraphRAG)

Wenn Ihre Fragestellungen die Synthese von Informationen über mehrere Dokumente hinweg oder logische Schlussfolgerungen über Entitätsbeziehungen erfordern, reicht Vektorähnlichkeit allein nicht aus. Wenn eine Rechtsabteilung fragt: „Welche Tochtergesellschaften von AcquiringCo haben anhängige behördliche Verfahren in Rechtsräumen, in denen TargetCo tätig ist?“, sind Entitätsauflösung, Beziehungstraversierung und Multi-Hop-Reasoning erforderlich.

Wir erstellen Wissensgraphen aus Ihren Dokumenten mithilfe dependenzbasierter Extraktion, die 94% der LLM-basierten Leistung zu einem Bruchteil der Token-Kosten erreicht (detailliert beschrieben in unserer Forschung zu zitationsgestütztem GraphRAG). Microsofts GraphRAG – dieser Ansatz (Leiden-Clustering + Community-Zusammenfassung) eignet sich für korpusweite Sensemaking-Abfragen, doch seine Indexierungskosten betragen 4–8x Standard-RAG. Wir setzen ihn selektiv ein:

• Community-Zusammenfassungen für globale Abfragen.
• Property-Graph-Traversierung für Fragen zu Entitätsbeziehungen.
• Standardmäßiges Vektor-Retrieval für alles andere.

Für den Graph-Backing-Store: FalkorDB bewältigt leseintensive RAG-Workloads bei 6,693 QPS mit Kaltstarts im Submillisekundenbereich, während Neo4j die richtige Wahl bleibt, wenn Sie ausgereifte RBAC, Clustering und komplexe Aggregationen benötigen.

Agentisches Retrieval

Das leistungsfähigste Muster im Jahr 2026 und das am aufwendigsten korrekt umzusetzende. Eine agentische Retrieval-Schleife zerlegt komplexe Abfragen in Teilabfragen, leitet jede an die passende Retrieval-Strategie weiter (Vektor, Graph oder strukturierte Datenbank), bewertet, ob die Ergebnisse ausreichen, und iteriert, bis Konfidenzschwellenwerte erreicht sind.

Wir implementieren dies auf LangGraph, wo die Zustandsautomaten-Abstraktion bedingte Verzweigungen, Human-in-the-Loop-Unterbrechungsknoten und deterministische Auditierbarkeit bietet. Korrigierende RAG-Schichten (Corrective RAG) verursachen 100–800ms Latenz pro Abfrage, fangen Retrieval-Fehler jedoch ab, bevor sie das LLM erreichen. Dieses Muster ist produktionsreif bei Morgan Stanley, PwC und ServiceNow. Es ist noch nicht bereit für Teams ohne dedizierte MLOps-Kapazitäten zur Überwachung und Feinabstimmung der Retrieval-Schleifen.

Was vor dem Embedding geschieht: Chunking richtig aufsetzen

Beim Chunking scheitern RAG-Systeme oft im Stillen. Naives Chunking mit fester Größe liefert Faithfulness-Werte von 0.47–0.51. Semantisches Chunking erreicht 0.79–0.82, erfordert jedoch das Embedding jedes einzelnen Satzes in Ihrem Korpus. Die richtige Strategie hängt von Ihren Dokumenten ab:

• Strukturierte regulatorische Einreichungen – layoutsensitives Parsing bewahrt die Abschnittshierarchie.
• PDFs mit gemischten Inhalten (Tabellen und Diagramme) – visionsgestütztes Chunking (jede Seite wird zur Layouterkennung als Bild behandelt, bevor Textbereiche extrahiert werden) verbessert die Retrieval-Präzision gegenüber rein textbasiertem Parsing um 8–15%.
• Lange narrative Dokumente – Late Chunking leitet zunächst das gesamte Dokument durch den Transformer, sodass jedes Token-Embedding den bidirektionalen Kontext widerspiegelt, und setzt die Chunk-Grenzen erst nach dem Vorwärtsdurchlauf.

Wir testen drei bis vier Chunking-Strategien anhand Ihres tatsächlichen Abfragesets, bevor wir eine auswählen. Die Evaluations-Harness (RAGAS-Metriken für Faithfulness und Context Precision, domänenspezifische Relevanzurteile) wird als integraler Bestandteil der Pipeline ausgeliefert, nicht als nachträglicher Zusatz. 60% der neuen RAG-Bereitstellungen enthalten heute von Tag eins an eine systematische Evaluation, verglichen mit unter 30% Anfang 2025. Wir integrieren die Evaluation in Ihre CI/CD, sodass die Retrieval-Qualität bei jedem Deployment gemessen wird – und nicht erst auffällt, wenn sich Nutzer beschweren.

Was kostet der Betrieb eines Enterprise-RAG-Systems?

Ein Fertigungsunternehmen investierte $400,000 in die Bereitstellung eines RAG-Systems und stellte anschließend fest, dass der laufende Betrieb $18,000/Monat kostete – mehr als das Doppelte ihrer Prognose. Das Kostenmodell, das sie übersehen hatten: Reranking. Embedding-APIs kosten $20–120 pro Milliarde Tokens. Das Hosting von Vektordatenbanken bei 10M Vektoren kostet bei verwalteten Diensten (Pinecone, Weaviate Cloud) 1.5–3x mehr als im Self-Hosting (Qdrant, pgvector). Doch Reranking bei produktivem Abfragevolumen ist der Punkt, an dem Budgets explodieren: Cohere Rerank kostet $2 pro 1.000 Abfragen, während ein selbst gehosteter BGE-reranker-v2-m3 auf einer einzelnen GPU diese Latenz bei null Kosten pro Abfrage erreicht – wenngleich Sie für die GPU-Instanz zahlen.

GraphRAG fügt eine weitere Kostenebene hinzu. Der Aufbau des Wissensgraphen verbraucht 4–8x mehr Tokens als der Quelltext für die Entitätsextraktion und Community-Zusammenfassung. Die Wartung beansprucht 40–60% des Engineering-Budgets im ersten Jahr , weil Entitätsauflösung, Deduplizierung und Ontologie-Aktualisierungen kontinuierliche Arbeit sind und kein einmaliges Setup. Dependenzbasierte Extraktion (klassisches NLP anstelle von LLM-Aufrufen) senkt die Aufbaukosten um rund 90% , während 94% der Extraktionsqualität erhalten bleiben. Wir kalkulieren jedes Projekt mit expliziten monatlichen Run-Rate-Projektionen für Embedding, Speicherung, Retrieval, Reranking und Graph-Wartung.

Wann sich GraphRAG lohnt (und wann nicht)

Sie benötigen Graph-unterstütztes Retrieval, wenn Ihre Abfragen Multi-Hop-Reasoning über Entitäten und Beziehungen hinweg erfordern:

• M&A-Due-Diligence über Hunderte von Einreichungen von Tochtergesellschaften hinweg.
• Synthese klinischer Evidenz über Datenbanken für Arzneimittelwechselwirkungen hinweg.
• Lieferketten-Risikoanalysen, die Lieferantennetzwerke mit behördlichen Maßnahmen verknüpfen.

GraphRAG erzielt in Benchmarks seine höchste Suchpräzision bei komplexen, vielschichtigen Unternehmensanfragen (siehe eine funktionierende Demo für zitationsverifiziertes juristisches Retrieval). Sie benötigen es nicht, wenn Ihre Abfragen Einzeldokument-Lookups, FAQ-artige Antworten oder keywordbasierte Suchen sind – ein hybrides BM25- und Dense-Retrieval mit einem Reranker bewältigt dies zu einem Bruchteil der Kosten und Komplexität. Wenn Ihr Korpus unter 5 Millionen Vektoren liegt und Ihre Fragen keine Dokumentgrenzen überschreiten, ist pgvector mit HNSW-Indexierung vollkommen ausreichend. Wir prüfen dies vor jeder Architekturempfehlung und teilen Ihnen offen mit, wann die einfachere Option die richtige ist.

Auch die Frage „Brauchen wir überhaupt RAG?“ ist berechtigt. Bei Kontextfenstern von mittlerweile über 1M+ Tokens (Gemini 3 Pro bei 10M) erwägen manche Teams, ganze Korpora in den Prompt zu packen. Das Problem: Eine einzelne Abfrage mit 1M Tokens kostet $2–10, was bei unternehmensweitem Abfragevolumen untragbar ist. Zudem degradiert die Kontextqualität ab bestimmten Schwellenwerten selbst innerhalb der beworbenen Grenzen. RAG bleibt die richtige Architektur für jedes System, das wiederholte Abfragen auf großen, sich verändernden Dokumentenbeständen verarbeitet.

Welche Angriffsfläche bietet eine RAG-Pipeline?

Die PoisonedRAG-Forschung (USENIX Security 2025) zeigte, dass fünf gezielt manipulierte Dokumente, die in einen Korpus von einer Million Dokumenten eingeschleust werden, KI-Antworten mit über 90% Erfolgsquote manipulieren können. Ihre Retrieval-Pipeline ist ein Einfallstor für feindliche Inhalte. Die OWASP stuft Schwachstellen in Vektoren und Embeddings (LLM08:2025) sowie Prompt-Injection über abgerufene Dokumente (LLM01:2025) als führende Sicherheitsrisiken für LLMs ein.

Wir integrieren Nachverfolgung der Dokumentenprovenienz, Anomalieerkennung auf Embedding-Ebene und Schichten zur Eingabebereinigung in die Retrieval-Pipeline. Jede abgerufene Passage enthält Quell-Metadaten und ein Vertrauens-Scoring. Die Generierungsschicht wird darauf beschränkt, spezifische Passagen zu zitieren; Behauptungen, die sich nicht im abgerufenen Inhalt belegen lassen, werden markiert statt ungeprüft durchgereicht. Dies ist für jedes in regulierten Umgebungen eingesetzte RAG-System unverzichtbar, wie ausführlich in unserer Forschung zur Absicherung privater Unternehmens-LLMs.

Was wir liefern

Jedes Projekt umfasst:

• Eine Retrieval-Architektur, abgestimmt auf Ihre spezifischen Abfragemuster und Dokumenttypen.
• Eine Chunking- und Embedding-Strategie, gebenchmarkt anhand Ihrer realen Abfragen.
• Ein produktionsreifes Evaluations-Harness mit RAGAS-Metriken und domänenspezifischen Testfällen.
• Explizite Kostenprognosen für Embedding, Speicherung, Retrieval, Reranking und etwaige Graph-Wartung.
• Sicherheits-Hardening gegen Retrieval-basierte Angriffe.
• Einen Monitoring-Stack, der Qualitätsverluste beim Retrieval erkennt, bevor es Nutzer tun.

Wir teilen Ihnen außerdem ehrlich mit, wenn Ihr aktuelles Setup ausreicht und sich die Investition in ein komplexeres Retrieval nicht rentiert.