Ein normales RAG zerlegt deine Dokumente in Textbrocken und findet den, der eine Frage beantwortet. Für „was steht in unseren Garantiebedingungen zu Punkt X” ist das perfekt. Für „welche unserer Lieferanten sind betroffen, wenn Bauteil X einen Defekt hat” versagt es — denn diese Antwort steht in keinem einzelnen Absatz. Sie verteilt sich über Stücklisten, Produktdaten und Lieferantenverträge, und sie steckt in den Verbindungen zwischen ihnen, nicht in einer Textstelle.
Graph-RAG ist die Antwort auf genau diese Sorte Frage: Es verwandelt dein Wissen in einen Graphen aus Dingen und ihren Beziehungen. Das ist mächtig für Beziehungsfragen — und ein erheblicher Aufbau, den die meisten Fragen gar nicht rechtfertigen. Beides gehört auf den Tisch, bevor jemand „wir bauen einen Wissensgraphen” sagt.
Wo Textbrocken an ihre Grenze stoßen
Es gibt drei Fragetypen, an denen die Textbrocken-Suche scheitert. Beziehungsfragen — „was hängt an was”, „wer liefert das Teil, das in diesem Produkt steckt”. Mehrstufige Fragen, deren Antwort sich über mehrere verbundene Stellen aufbaut. Und Übersichtsfragen über den ganzen Bestand — „welche Themen ziehen sich durch all unsere Störungsberichte”. In allen dreien gibt es keinen einzelnen Brocken, der die Antwort enthält.
Ein Brocken-RAG holt immer die ähnlichste Stelle. Aber Ähnlichkeit findet keine Beziehung. Du bekommst eine Stelle, die vom Lieferanten redet, und eine, die vom Bauteil redet — aber nicht die Verbindung dazwischen, die deine eigentliche Frage war.
Wissen als Graph
Statt nur Textbrocken baust du ein Netz: Dinge als Knoten — Produkte, Lieferanten, Teile, Klauseln, Personen — und ihre Beziehungen als Kanten dazwischen. Diese Knoten und Kanten zieht meist ein Modell aus deinen Dokumenten heraus. Aus „Lieferant A liefert Teil B, das in Produkt C steckt” werden drei Knoten und zwei Kanten, die man verfolgen kann.
Bei einer Frage wandert das System dann nicht zur ähnlichsten Stelle, sondern entlang der Verbindungen: von Bauteil X zu allen Produkten, die es enthalten, zu deren Lieferanten. Für Übersichtsfragen kommen vorab verdichtete Zusammenfassungen ganzer Bereiche des Graphen dazu. So wird beantwortbar, was zwischen den Dokumenten liegt.
Der Aufbau ist das eigentliche Projekt
Hier sitzt die Arbeit, und sie ist groß. Einen guten Graphen aus unordentlichen Dokumenten zu ziehen, ist ein umfangreicher, modellgetriebener Vorverarbeitungsschritt — und seine Qualität entscheidet über alles. Werden Dinge und Beziehungen falsch oder lückenhaft extrahiert, ist der ganze Graph schief, und jede Antwort darauf ist selbstbewusst falsch.
Eine falsch gezogene Beziehung ist gefährlicher als eine fehlende Textstelle, weil sie wie ein echter Zusammenhang aussieht. Deshalb gehört die Extraktion geprüft, nicht blind übernommen — dieselbe Mess-Disziplin wie bei der Bewertung eines Archivs. Wer den Graphen einmal hinwirft und ihm dann vertraut, baut auf Vermutungen, die niemand kontrolliert hat.
Wie ich das angehe
Beziehungs-, Mehrschritt-, Übersichtsfragen rechtfertigen ihn. Reine Nachschlage-Fragen nicht. Diese Sortierung steht vor allem anderen.
Aus den Dokumenten Knoten und Kanten ziehen — und die Extraktion an Stichproben prüfen, statt ihr zu trauen.
Die geprüften Beziehungen zu einem durchsuchbaren Netz verbinden, für Übersichtsfragen mit verdichteten Bereichs-Zusammenfassungen.
Entlang der Kanten von Knoten zu Knoten gehen, statt nur die ähnlichste Stelle zu holen. Das ist der eigentliche Mehrwert.
Nicht alles über den Graphen. Lokale Treffer holt das einfache RAG schneller und billiger — nach Fragetyp aufteilen.
Wo es in der Praxis kippt
Überengineering. Der größte Fehler. Die meisten Fragen im Mittelstand sind Nachschlage-Fragen, die ein gutes RAG mit Re-Ranking bestens bedient. Einen Graphen über alles zu legen, weil es anspruchsvoll klingt, ist teurer Aufwand für ein Problem, das du nicht hast.
Extraktionsfehler pflanzen sich fort. Eine falsch gezogene Beziehung wird zur selbstbewussten Falschantwort. Die Extraktion ist die kritische Stelle und gehört geprüft.
Pflege und Veralten. Ändern sich Dokumente, muss der Graph nachgezogen werden. Ein veralteter Graph führt nicht in die Irre wie eine fehlende Stelle — er behauptet Zusammenhänge, die nicht mehr stimmen.
Kein Ersatz. Graph-RAG löst einen Fragetyp, nicht alle. Wer es als Nachfolger des normalen RAG verkauft, hat den Unterschied nicht verstanden. Die guten Systeme leiten je nach Fragetyp.
Was es kostet — und woran
Der Aufbau und die Pflege sind hier ernsthaft — die Extraktion über einen großen Bestand ist ein modellgetriebener Vorlauf, und die Aktualisierung läuft weiter. Das rechtfertigst du über die Fragetypen, die du wirklich hast. Sitzt dein Wert in Zusammenhängen — Abhängigkeitsketten in der Compliance, Liefernetze, verknüpfte Vorgänge, komplexe Produktstrukturen —, lohnt sich der Graph. Sind deine Fragen im Kern Nachschlage-Fragen, ist er teurer Overkill.
Wer dir Graph-RAG verkauft, ohne vorher zu fragen, welche Fragen du überhaupt stellst, verkauft dir Komplexität, nicht Nutzen. Die ehrliche erste Frage lautet nicht „wie bauen wir den Graphen”, sondern „brauchen wir ihn”.
Wie ein ehrlicher Einstieg aussieht
Fang nicht mit dem Graphen an, sondern mit deinen echten Fragen. Sortiere sie: Wie viele sind Nachschlage-Fragen, wie viele Beziehungs- oder Übersichtsfragen? Ist der Großteil lokal, bau ein gutes RAG mit Re-Ranking und lass den Graphen weg. Sitzt der Wert wirklich in den Verbindungen, prototype den Graphen auf einem kleinen, beziehungsreichen Ausschnitt und prüf zuerst die Extraktionsqualität, bevor du skalierst. Die Sortierung der Fragen spart dir womöglich das ganze Projekt.
Worauf du achtest, wenn dir das jemand baut
- Fragt der Anbieter zuerst, welche Fragen du hast — oder verkauft er den Graphen als Standard? Letzteres ist das Warnsignal.
- Wird die Extraktion der Beziehungen geprüft, oder blind übernommen? Falsche Kanten sind das K.-o.-Kriterium.
- Gibt es einen Plan für die Pflege, wenn Dokumente sich ändern?
- Wird nach Fragetyp geleitet — Graph für Verbindungen, normales RAG für Nachschlage-Fragen?
- Ist der Aufwand durch deine echten Fragetypen gerechtfertigt?
Bevor irgendjemand einen Graphen baut, sortier deine Fragen. Dieser Prompt sagt dir, ob sich der Aufwand überhaupt lohnt:
Du sortierst meine Fragen danach, ob sie einen Wissensgraphen brauchen oder ein normales RAG genügt.
Ich gebe dir eine Liste echter Fragen.
Ordne jede Frage einer Klasse zu:
- LOKAL: Die Antwort steht voraussichtlich in EINER Stelle/einem Dokument (normales RAG genügt).
- VERBINDUNG: Die Antwort braucht Beziehungen über mehrere Dokumente ("welche X hängen an Y",
"wie hängen A und B zusammen") -> Graph sinnvoll.
- ÜBERSICHT: Eine Frage über den GANZEN Bestand (Themen, Muster, Zusammenfassung) -> Graph sinnvoll.
Gib je Frage die Klasse mit kurzer Begründung aus. Am Ende: Lohnt sich ein Graph überhaupt — wie groß
ist der Anteil VERBINDUNG/ÜBERSICHT gegenüber LOKAL?Bei dir sitzt der Wert im Zusammenhang — welche Teile an welchem Lieferanten hängen, wie Vorgänge zusammenspielen — und ein normales Archiv findet das nicht? Dann reden wir darüber, ob deine Fragen wirklich einen Graphen brauchen oder ob ein gutes RAG mit Re-Ranking schon reicht.