Connect the Dots

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

Heute auf der Setlist: Wie man eine RAG-Architektur bewertet, & woran man erkennt, dass man eigentlich GraphRAG braucht.

🎚️ Soundcheck

In Ausgabe #001 von Rag'n'Roll habe ich folgende These vertreten: Das Problem moderner KI ist selten das verwendete Modell selbst, sondern die verwendeten Verfahren für das Retrieval. Wer es mit funktionierenden Enterprise-KI-Anwendungen ernst meint, landet deshalb früher oder später bei derselben Frage: Welche RAG-Architektur braucht mein Anwendungsfall eigentlich?

Die meisten Teams starten mit Naive RAG; also ausschließlich vektorbasiertem Suchen nach Textschnipseln & oft reicht das auch schon, wenn der zu durchsuchende Korpus klein ist (bis zu 50.000 Dokumente funktionieren noch ganz gut) und die Fragen an den Korpus simpel sind (gesuchte Textstellen enthalten keine kontextuellen Abhängigkeiten auf andere Textstellen).

Das geht gut, bis die ersten Fragen kommen, bei denen die Antworten der KI unvollständig oder zum großen Teil halluziniert sind. Fast immer sind das Fragen, deren Antwort nicht in einem Absatz steht, sondern sich aus Verbindungen über viele Dokumente ergibt. Genau hier kommt GraphRAG ins Spiel.

🎤 Main Set: Was GraphRAG anders macht

Vom Schnipsel zum Netz

Klassisches RAG zerlegt Dokumente in Chunks, vektorisiert sie & sucht bei einer Frage die semantisch ähnlichsten Stellen. Das ist super, wenn die Antwort lokal in einem oder wenigen, nahe beieinander liegenden Schnipseln liegt.

GraphRAG setzt in der Pipeline eine Stufe früher an. Statt nur Textschnipsel abzulegen, extrahiert es aus den Dokumenten Entitäten (Personen, Produkte, Verträge, Begriffe) inklusive deren Beziehungen und baut daraus einen Wissensgraphen. Dieser Graph macht sichtbar, was im reinen Vektorraum unsichtbar bleibt: wie Dinge faktisch zusammenhängen.

Lokal & global fragen

Auf diesem Graphen sind zwei Arten von Fragen möglich:

• Lokal: Fragen rund um eine konkrete Entität. Das System startet am passenden Knoten & folgt den Kanten zu den verbundenen Fakten.
• Global: Fragen über den gesamten Bestand hinweg. Dafür werden zusammenhängende Bereiche des Graphen (Communities) gruppiert & zusammengefasst, sodass auch übergreifende Themen beantwortet werden, ohne jedes Dokument einzeln zu lesen.

Der Kern in einem Satz: Vektorsuche findet das Ähnliche, GraphRAG findet das Verbundene.

🥁 Track 2: Woran du erkennst, dass du GraphRAG brauchst

GraphRAG ist kein einfaches Upgrade, das man pauschal einschaltet. Es kostet zusätzlichen Aufwand: Die Extraktion von Entitäten & Beziehungen läuft über ein Sprachmodell für jedes Dokument, dazu kommt: der Graph muss gebaut & gepflegt werden. Das lohnt sich nur, wenn die Fragen es verlangen.

Hier sind einige Signale, bei welchen GraphRAG nötig wird:

• Multi-Hop-Fragen: Die Antwort verknüpft mehrere Dokumente. Beispiel: „Welche Lieferanten sind betroffen, wenn Bauteil X ausfällt?“
• Übergreifende, aggregierende Fragen: „Welche Themen tauchen über alle Störungsberichte hinweg immer wieder auf?“
• Vektorbasiertes RAG liefert lokal plausible, aber im Gesamtbild unvollständige Antworten.

GraphRAG ist (noch) nicht nötig, wenn:

• Die Antworten meist in einem einzelnen Dokument oder Abschnitt stehen.
• stabile Hybride Suche & Reranking das Problem bereits zuverlässig genug löst.

Entscheiden sollte man das nicht aus dem Bauch: Es hilft, wenn man ein repräsentatives Set aus den gängigsten Fragen der Nutzer baut & diese nach lokalen & globalen bzw. Multi-Hop-Anfragen gruppiert. Damit lässt sich messen, wo vektorbasiertes RAG systematisch danebenliegt. Das Fehlermuster sagt aus, welche Architektur benötigt wird. Am häufigsten funktioniert: Vektorsuche für die Präzision, GraphRAG für den Überblick.

🎯 Encore: Der eine Gedanke für Entscheider

Die Wahl der RAG-Architektur hängt davon ab, wie groß der zu durchsuchende Korpus ist & welche Komplexität die Fragen der Nutzer haben können.

GraphRAG ist mächtig für Fragen, welche vernetzte & übergreifende Antworten verlangen. Es bringt aber Kosten in Aufbau & Pflege mit sich, inklusive des Risikos, dass ein Graph veraltet, sobald sich die Datenbasis ändert.

Die richtige Frage ist deshalb nicht „Vektor oder Graph?“, sondern: „Welche Fragen stellen unsere Nutzer wirklich & woran scheitert unser heutiges Retrieval?“

Wer das beantworten kann, trifft eine belastbare Architekturentscheidung.

💿 B-Side

Das heutige Anti-Pattern: GraphRAG einführen, bevor geprüft ist, ob hybride Suche & Reranking das Problem schon löst.

Ein Wissensgraph ist sehr nützlich, aber wenn die Fragen lokal angesiedelt sind, zahlst man für Komplexität ohne echten Gegenwert. Also: Erst messen, wo das aktuelle Retrieval bricht, dann die Architektur wählen.

Für den Einstieg lohnt ein Blick auf Microsofts offen verfügbares GraphRAG-Projekt, das Entitäts-Extraktion, Community-Erkennung & globale Zusammenfassungen praktisch zeigt.

---

Das war Rag'n'Roll #002. Nächste Ausgabe: Open Knowledge Format, was eine selbstbeschreibende Wissensschicht für RAG-Systeme leistet & wo ihre Grenzen liegen.

Weiterleiten erwünscht🤘