The Missing Edge

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Warum Knowledge Graphs an Ausnahmen scheitern, & was einen echten Wissens-Graph vom bloßen Entitäten-Graph unterscheidet.

🎚️ Soundcheck

In Ausgabe #002 hieß es: Vektorsuche findet das Ähnliche, GraphRAG findet das Verbundene. Es gibt aber einen Haken, den viele Teams, welche mit der Implementierung einer RAG-Pipeline betraut sind, schmerzhaft lernen: Sie bauen einen aufwändigen Knowledge Graph, & er liefert nicht bessere Ergebnisse als „normales“ Naive RAG.

Ein Beispiel aus dem Jura-Bereich macht es greifbar. Regel A: Diebstahl ist illegal. Regel B: Diebstahl von Nahrung im Notfall ist erlaubt. Die lexikalische Suche findet oftmals nur eine der beiden Regeln, denn es gibt hier keinen gemeinsamen Suchbegriff. Die semantische Suche könnte beide sehen, aber die entscheidende Ausnahme fällt leicht aus dem Kandidaten-Fenster der Suche. Ein Knowledge Graph sollte genau das lösen, oft tut er es aber nicht. Diese Ausgabe zeigt, warum.

🎤 Main Set: Warum der Graph nicht liefert

Der Flaschenhals ist das Schema des „Wissens“-Graphen, nicht das semantische Embedding der Begriffe

Die meisten GraphRAG-Pipelines extrahieren generische Tripel: Person, Organisation, Ereignis, „ist ein“, „Teil von“. In diesem Schema gibt es keinen Platz für die Logik von Ausnahmen: Bedingung, überschreibt, ersetzt, gilt nur wenn. Wenn die Extraktions-Anweisung bzw. die Ontologie diesen Beziehungstyp nicht verlangt, bringt das Modell ihn beim Indexieren nicht zuverlässig hervor, selbst wenn die Ausnahme klar im Text steht. Es extrahiert „Regel A: Diebstahl illegal“ & „Regel B: Diebstahl aus Not erlaubt“ als zwei getrennte Fakten ohne verbindende Kante, weil nichts im Schema gesagt hat, dass es nach dieser Verbindung suchen soll. Das ist der Klassiker: Du hast so einen Entitäten-Graph, keinen Wissens-Graph.

Und selbst mit der richtigen Kante: Wie läuft die Traversierung des Graphen?

Angenommen, die „überschreibt“-Kante wurde korrekt extrahiert. Dann kommt das nächste Problem: Die meisten GraphRAG-Abfragen sind single-hop & entitätszentriert. Die Frage „Ist Diebstahl illegal?“ trifft Regel A, zieht deren direkte Nachbarn in den Kontext & hört dann auf, beziehungsweise antwortet auf Basis des gegebenen Kontext-Scopes. Um die Ausnahme sichtbar zu machen, müsste der Traversierungs-Schritt gezielt die „überschreibt/qualifiziert“-Kanten vom Treffer aus weiterverfolgen. Verbreitete Implementierungen, Microsofts GraphRAG eingeschlossen, sind auf thematische Gesamt-Zusammenfassungen optimiert, nicht auf das Auflösen von Ausnahmen. Es ist also auch ein Design-Problem beim Retrieval, nicht nur beim Indexieren.

🥁 Track 2: Der Embedding-Irrtum, & was wirklich hilft

Embeddings können keine Ausnahme

Ein häufiger Reflex ist, das Problem beim Embedding-Modell zu suchen. Aber Embeddings sind schlecht darin, Verneinung, Ausnahme & bedingte Überschreibung als Abstand abzubilden. „Diebstahl ist illegal“ & „Diebstahl aus Not ist erlaubt“ liegen im Vektorraum nah beieinander, weil sie thematisch verwandt sind. Die Kosinus-Ähnlichkeit unterscheidet aber nicht zwischen „stützt“, „überschreibt“ & „widerspricht“. Wer seine Graph-Knoten über Embedding-Ähnlichkeit verbindet statt über getypte Kanten, hat die semantische Lücke nur in den Graph verschoben, nicht geschlossen.

Was es wirklich löst: eine Logik-Schicht

Das Beispiel löst erst eine Logik-Schicht: allgemeine Regel-Knoten, Ausnahme-Knoten & eine getypte „qualifiziert/überschreibt“-Kante mit expliziter Bedingung. In Recht, Compliance oder Medizin kommt fast immer eine Zeitdimension dazu: Ausnahmen werden aufgehoben, Gesetze geändert, & man muss wissen, welche Fassung einer Regel zum Abfragezeitpunkt galt.

🎯 Encore: Der eine Gedanke für Entscheider

Ein Knowledge Graph ist nur so gut wie das Schema, mit dem du ihn baust. „Kippt eure Dokumente in ein generisches GraphRAG“ ist derselbe Fehler wie „ladet einfach alle PDFs hoch“, nur eine Ebene höher. Der Wert entsteht nicht dadurch, dass irgendwo ein Graph steht, sondern dadurch, dass er genau die Beziehungstypen abbildet, von denen eure Antworten abhängen: Ausnahmen, Bedingungen, Gültigkeitszeiträume.

Man merkt: Umsonst gibt es hier nichts. Die Frage für Entscheider ist deshalb: „Welche Beziehungstypen entscheiden über unsere Antworten, & bildet unser Graph sie überhaupt ab?“

💿 B-Side

Anti-Pattern: Ein generisches Out-of-the-box-GraphRAG auf eine Domäne loslassen, in der Ausnahmen & Gültigkeiten die eigentliche Antwort tragen (Recht, Compliance, Medizin, Verträge). Ohne „überschreibt“-Kanten & ohne Zeitdimension bekommst du selbstbewusste, aber falsche Antworten aus deiner Pipeline. Erst die Fragen & die entscheidenden Beziehungstypen modellieren, dann den Graph bauen.

---

Das war Rag'n'Roll #006. Nächste Ausgabe: RAG von der Stange? Ein kritischer Blick auf fertige RAG-Plattformen & Blueprint-Architekturen, & warum auch ein gekauftes System noch jede Menge Konfiguration (und Budget) braucht.

Weiterleiten erwünscht🤘