Wenn Unternehmen heute über KI und ihr eigenes Firmenwissen sprechen, meinen fast alle dasselbe: RAG. Zu Recht — der Ansatz ist der De-facto-Standard, und für die überwiegende Mehrheit der Fragen ist er auch die richtige Wahl. Er macht aus einem Sprachmodell, das nur allgemeines Wissen kennt, ein System, das auf eure Verträge, Protokolle und Handbücher antwortet.
Und trotzdem gibt es eine Kategorie von Fragen, an der dieser Standard verlässlich scheitert. Nicht gelegentlich, nicht bei schlechter Datenqualität — sondern strukturell, by design. Ausgerechnet diese Kategorie ist im Geschäftsalltag die wertvollste: die Frage nach dem Zusammenhang. „Welcher Bestandskunde wurde von dem Ansprechpartner betreut, der gerade zum Wettbewerber gewechselt ist?" Die Antwort steht in keinem einzelnen Dokument. Sie ergibt sich erst aus der Verbindung mehrerer.
RAG steht für „Retrieval-Augmented Generation" — eine Antwort, die durch vorheriges Nachschlagen angereichert wird. Der Ablauf hat zwei Takte. Zuerst das Retrieval: Bevor die KI überhaupt ein Wort formuliert, durchsucht sie euer Archiv nach den Textstellen, die am besten zur Frage passen. Dann die Generation: Das Sprachmodell schreibt seine Antwort ausschließlich aus dem, was es gefunden hat — nicht aus vagem Trainingswissen.
Genau das ist der Grund für den Erfolg: Die KI erfindet weniger, sie belegt mehr, und sie bleibt auf dem Stand eurer echten Unterlagen. Für die Frage „Was steht in unserer aktuellen Reisekostenrichtlinie?" ist das exakt richtig. Die Antwort lebt in einem Dokument, RAG findet dieses Dokument, fertig.
Das Problem beginnt bei dem Wort „passend". Die einfachste und am weitesten verbreitete Variante — oft naives RAG genannt — sucht nach inhaltlicher Ähnlichkeit. Sie holt Textstellen, die sich anfühlen wie die Frage, nicht solche, die sachlich mit ihr zusammenhängen.
Bei einer Einzelfaktfrage fällt das nicht auf, weil Ähnlichkeit und Zusammenhang dort dasselbe sind. Bei einer Verbindungsfrage fallen sie auseinander. Wer fragt „Welche Projekte hängen an dieser einen Lieferantin?", braucht keine Textstellen, die ähnlich klingen — er braucht die Kette: Lieferantin → Vertrag → Projekt → Verantwortlicher. Ähnlichkeit findet diese Kette nicht.
Und hier kommt der gefährliche Teil: Die KI meldet keinen Fehler. Sie sagt nicht „diese Verbindung kann ich nicht herstellen". Sie nimmt die halben Treffer aus der Ähnlichkeitssuche und formuliert daraus eine flüssige, selbstsichere Antwort — mit geratenen Lücken an genau den Stellen, wo die Verbindung stehen müsste. Das Ergebnis liest sich richtig. Es ist es nur nicht.
An dieser Stelle fällt oft das Wort „Graph", und viele denken sofort an das hübsche Netz aus Punkten und Linien, das Tools wie Obsidian anzeigen. Der Vergleich hilft — aber nur, um den Unterschied zu sehen.
In einem Obsidian-Netz steht ein Punkt für eine Datei. Eine Linie zwischen zwei Punkten bedeutet nichts weiter als „diese beiden Dateien sind verlinkt". Womit? Warum? Das weiß das Netz nicht. Es ist eine Landkarte der Verlinkungen, keine Landkarte der Bedeutung.
Ein echter Knowledge Graph ist etwas grundlegend anderes. Hier steht ein Punkt nicht für eine Datei, sondern für ein reales Ding: eine Person, eine Firma, ein Angebot, ein Vertrag. Und eine Linie hat eine benannte Bedeutung — „ist Geschäftsführer von", „beliefert", „ersetzt" — die man gezielt abfragen kann.
Ein Beispiel. Thomas Berger taucht in einer E-Mail auf, im CRM und in einem Meeting-Protokoll. In einem dateibasierten System sind das drei lose Fundstellen, die nichts voneinander wissen. Im Knowledge Graph ist Thomas Berger ein einziger Knoten, an dem alle drei Quellen hängen — verbunden mit seiner Firma, seinen Projekten, seinen Ansprechpartnern. Genau dieser eine Knoten macht die Verbindungsfrage beantwortbar.
Die naheliegende Sorge: So ein Graph klingt nach monatelanger Handarbeit. Muss er nicht sein. Denselben Job, den ein Sprachmodell in RAG beim Antworten macht, kann es auch beim Bauen des Graphen übernehmen: reale Dinge und ihre Beziehungen automatisch aus euren Texten herauslesen. Genau dieser Ansatz steckt hinter GraphRAG, einem Verfahren aus der Microsoft-Forschung.
Zwei Begriffe entscheiden dabei über Erfolg oder Chaos. Der erste ist die Ontologie — der Bauplan des Graphen. Sie legt fest, welche Arten von Dingen es überhaupt gibt (Person, Firma, Vertrag) und welche Arten von Beziehungen erlaubt sind. Ohne Bauplan baut das Modell für jeden Text ein eigenes Vokabular, und am Ende passt nichts zusammen.
Der zweite — und das ist die häufigste Fehlerquelle überhaupt — ist die Entity Resolution: das Zusammenführen von Schreibweisen, die dasselbe meinen. „T. Berger", „Thomas Berger" und „Thomas" müssen zu einem einzigen Knoten verschmelzen. Gelingt das nicht, zerfällt derselbe Mensch in drei Personen, die Verbindung reißt genau dort, wo sie zählt — und der teure Graph ist wieder so blind wie die Ähnlichkeitssuche, die er ersetzen sollte.
RAG bedeutet: erst abrufen, dann antworten — für Einzelfakten die richtige Lösung. Naives RAG scheitert an Verbindungsfragen, weil es nach Ähnlichkeit sucht, nicht nach Zusammenhang, und die Lücke lautlos mit geratenen Antworten füllt. Ein echter Knowledge Graph denkt stattdessen in realen Dingen und benannten Beziehungen: RAG findet Einzelfakten — der Graph findet Verbindungen.
📺 Lieber als Video? Hier ansehen:
In Teil 3 der Serie geht es weiter: Wie RAG und Knowledge Graph in GraphRAG zusammenfinden — und wie ein System selbst entscheidet, welche Methode eine Frage braucht.
