rag knowledge-graph llm-evaluation graphrag microservices benchmarking

RAG oder Wissensgraphen? 2.160 bewertete Antworten und der Einfluss des Modells

RAG gegen Wissensgraph, gemessen an: 2.160 bewerteten Antworten aus drei Modellfamilien und 120 Fragen. Der Gewinner wechselt je nach Modell, und das Modell ist am wichtigsten.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20269 Min. Lesezeit2008 Wörter

Quellen: RAG ou grafo de conhecimento? Medi em 2.160 respostas e a resposta é desconfortável

Warum überhaupt messen?

Die Debatten über einen technischen Unternehmensassistenten stecken meist an derselben Stelle fest. Eine Seite plädiert für RAG, die andere für ein Wissensgraph, beide haben gute Argumente, doch keiner liefert Zahlen. Ein kontrolliertes Experiment kann solche liefern: Zwei Ansätze, drei Modellfamilien, drei Wiederholungen sowie 120 Fragen mit Referenzantworten, was insgesamt 2.160 bewertete Antworten ergibt. Jede Antwort wurde mit einer deterministischen Metrik sowie von einem Gremium aus drei Jurymitgliedern bewertet.

Die These ist weniger zufriedenstellend, als man sich wünschen würde. Es gibt keinen absoluten Gewinner, das Vorzeichen des Effekts ändert sich je nach Modell, und die Variable mit dem größten Effekt ist weder eine Strategie noch das andere. Es geht vielmehr darum, welches Modell hinter dem System steht.

Zum schnellen Lesen:

Das Graph übertraf RAG mit statistischer Signifikanz nur bei einem der drei Modelle.
Das Richtergremium wählte in allen drei Fällen RAG.
Der Wechsel des Modells verbesserte die Qualität stärker als der Wechsel der Strategie.
Das Datensatz ist synthetisch und die Lösungsschlüssel wurden vom Experimentator erstellt, was die Übertragbarkeit der Ergebnisse einschränkt.

Zuerst kommen die Einschränkungen, denn sie bestimmen, ob der Rest der Lektüre lohnenswert ist.

Was die Studie abdeckt und was nicht

Sie misst, welche Abrufstrategie zu korrekteren, vollständigeren und nachvollziehbareren Antworten zu einem Microservices-Ökosystem führt, wobei das Generierungsmodell in jeder Vergleichsgruppe konstant bleibt.

Es werden keine praktischen Anwendbarkeit bei echten Entwicklern, keine Wartungskosten im Laufe der Zeit, keine Qualität aus Sicht von Fachleuten oder kein Verhalten bei echter Dokumentation mit ihren Inkonsistenzen und Lücken gemessen.

Es misst außerdem nicht die Grenzen des grafbasierten Ansatzes. Das hier dargestellte Graph ist absichtlich einfach, mit Nachbarn auf einer Ebene und einer ungenauen Entitätsvergleichung. Ein Graph, der Mehrschritt-Anfragen sowie globale Aggregationen unterstützt, könnte Fragen beantworten, die dieser Graph nicht beantworten kann; daher liegt ein Teil der Nachteile des Graphen in den Tabellen in der Implementierung und nicht im Paradigma selbst.

Das Problem

Ein Unternehmen ist auf Microservices umgestiegen. Wo einst eine einzige Codebasis ausreichte, gibt es nun Dutzende von Diensten, Verträgen, Ereignissen und Datenbanken. Das Wissen ist verstreut – in READMEs, einem internen Katalog, einer Operations-Plattform sowie bei drei Personen, die es auswendig kennen. Alltägliche Fragen sind banal und kostspielig: Welche Anwendung speichert personenbezogene Daten, worauf setzt Dienst X ab, existiert das bereits und kann es wiederverwendet werden? Die Antwort besteht heute darin, jemanden zu fragen oder veraltete Dokumentation zu lesen; der eigentliche Kostenfaktor ist nicht die Suchzeit, sondern eine auf alten Informationen basierende technische Entscheidung.

Ein konversationaler Assistent könnte den Zugriff bereinigen, sofern er auf diesem Gebiet spezialisiert ist, und die Literatur nennt zwei mögliche Ansätze.

Unstrukturierte Suche (RAG) teilt die Dokumentation in Abschnitte auf, indiziert diese in einem Vektorlagern, holt die dem Fragestellung am ähnlichstenen Abschnitte ab und fügt sie in die Anfrage ein. Der Begriff stammt von Lewis und Kollegen aus dem Jahr 2020, wobei Gao und Kollegen aktuelle Entwicklungen zusammenfassen. Sie ist kostengünstig in der Wartung und kann Veränderungen ohne Neutraining aufnehmen, zeigt jedoch Schwächen, wenn eine Antwort logisches Denken bezüglich expliziter Beziehungen erfordert.

Strukturierte Suche (ein Wissensgraph) modelliert das Ökosystem als typisierte Knoten und Kanten: Dienst, Team, Ereignis, Datenbank, Abhängigkeit. Abfragen sind deterministisch und nachvollziehbar, doch das Modellieren und Verwalten des Graphen ist aufwändig. Die Übersicht über Wissensgraphen von Hogan und Kollegen gilt als Standardreferenz.

Beide Ansätze treffen sich in GraphRAG, und dorthin deuten die Ergebnisse dieses Experiments.

Design

Die wichtigste Entscheidung fiel bereits vor dem Schreiben des Codes: Nur die Wissensschicht darf variieren. Ohne diese Regel werden zwei Implementierungen verglichen und nicht zwei Strategien. Jede Abweichung im Prompt- oder Ausgabeformat verfälscht das Ergebnis auf eine Weise, die später nicht mehr getrennt werden kann – deshalb messen viele informelle RAG-Benchmarks letztendlich nur die Fähigkeiten dessen, der den Prompt verfasst hat.

Sowohl Ansätze liefern genau denselben Antwortaufbau: Frage, Vorgehensweise, Antwort, Quellen, abgerufener Kontext, Latenzzeit und geschätzte Kosten. Dadurch bleibt der Bewertungscodex, die API sowie die Schnittstelle unabhängig vom verwendeten Ansatz.

Der Test benötigte ein realistisches, veröffentlichbares und reproduzierbares Ökosystem – die Verwendung des echten Ökosystems eines Arbeitgebers kam daher nicht in Frage. Deshalb wurde CreditXPTO erfunden, ein nicht existierendes Fintech-Unternehmen für persönliche Kredite:

Das Synthetische bringt drei Vorteile mit sich. Der Inhalt ist kontrolliert, die richtige Antwort auf jede Frage ist bekannt, und jeder kann die Arbeit erneut durchführen, ohne auf interne Systeme zugreifen zu müssen. Der Preis dafür ist die externe Gültigkeit – die Hauptbeschränkung, die am Ende erörtert wird.

Dieselben Kenntnisse sind in beiden Darstellungen vorhanden, und die Äquivalenz wird durch in der kontinuierlichen Integration laufende Validierungsregeln gewährleistet: Eine fehlerhafte Referenz macht das Datensatz ungültig. Andernfalls könnte eine Seite heimlich mehr wissen als die andere. Die 120 Fragen sind nach Kategorie (Fakten, Erklärungen, Auswirkungen, Beziehungen, Entdeckungen, unklar), Schwierigkeitsgrad und Wissensart gekennzeichnet, und jede hat eine erwartete Antwort sowie Quellen.

Die RAG-Seite verwendet Fragmente mit 512 Tokenen und einer Überlappung von 50 Tokenen sowie ein Top-k von 5. Die Embeddings stammen von BAAI/bge-small-en-v1.5, das lokal ausgeführt wird, wobei Qdrant als Vektorlager dient. Die dichte Suche folgt dem von Karpukhin und Kollegen popularisierten Schema (DPR), die Satz-Embeddings basieren auf Sentence-BERT, und die BGE-Familie wird in C-Pack beschrieben.

Die Graph-Seite nutzt NetworkX im Speicher, das direkt aus den Quelldateien erstellt wird, sodass es stets mit den Daten übereinstimmt. Die Entitätsvergleiche erfolgen auf faseriger Basis mit einem Schwellenwert von 70/100, und die Suche bezieht sich auf die Nachbarschaft in einem Schritt.

Bewertung

Die Bewertung erfolgt auf zwei Ebenen. Die erste Ebene ist heuristisch: lexikalische Ähnlichkeit, Vorhandensein von Schlüsselentitäten und Quellenabdeckung. Sie ist kostengünstig, deterministisch und reproduzierbar, aber auch oberflächlich, da Paraphrasen bestraft werden. Das ist der bekannte Mangel von n-gramm-basierten Überschneidungsmetriken und der Grund für semantische Alternativen wie BERTScore.

Die zweite Ebene umfasst ein Gremium aus drei LLM-Bewertern, jeweils einem aus jeder Modellfamilie, die Korrektheit, Vollständigkeit, Fundiertheit und Klarheit mit 0 bis 3 bewerten. Das Konzept des LLM als Richter wurde von Zheng und Kollegen mit MT-Bench weiterentwickelt.

Ein Detail ist entscheidend: die wichtigste Kennzahl ist familienübergreifend. Für jede Antwort wird der Bewertungsrichter aus der eigenen Familie des Generators aus der Berechnung ausgeschlossen. Modelle erkennen ihren eigenen Text und bewerten ihn höher, und Panickssery sowie Kollegen (2024) verknüpfen diese Selbstpräferenz mit dieser Selbsterkennung. Der einzige Weg, dies zu neutralisieren, ist strukturell – niemals durch die Forderung nach Unparteilichkeit im Prompt.

Die Bedeutung ergibt sich aus einem gepaarten McNemar-Test, da beide Strategien dieselben Fragen beantworten. Für die Intervalle wird Bootstrap mit 5.000 Nachuntersuchungen verwendet, und die Übereinstimmung der Bewertungsrichter wird mit Cohens Kappa gemessen.

Ergebnisse

Die erste Tabelle zeigt die strenge Genauigkeit, bei der nur vollständig korrekte Antworten zählen, wobei pro Zelle n = 360 gilt:

Zwei Werte sind wichtig.

Zunächst ändert sich das Ergebnis je nach Modell. RAG ist mit zwei Generatoren vorteilhaft, der Graph mit dem dritten, und nur dieser letzte Unterschied ist signifikant. Ein Experiment mit einem einzigen Modell, wie es die meisten Benchmarks tun, hätte zu einem zuversichtlichen, falschen Ergebnis geführt – inklusive eines Konfidenzintervalls. In den Ergebnissen selbst wäre nichts darauf hingewiesen worden.

Zweitens übertrifft die Kluft zwischen den Modellen die Kluft zwischen den Ansätzen. Der Wechsel von claude-sonnet-4-6 zu gpt-5.5 bringt mehr Vorteile als ein Strategiewechsel innerhalb eines Modells. Dadurch rückt die Frage „RAG oder Graph?“ in den Hintergrund und wird zu einer Entscheidung zweiter Ordnung – das ist die zentrale Erkenntnis der Studie.

Wenn man den Test mit der weiten Definition durchführt, bei der volle sowie teilweise Punkte vergeben werden und nur offensichtliche Fehler bestraft werden, ändert sich die Situation. RAG gewinnt nun deutlich gegenüber den ersten beiden Modellen, und der Vorteil des Graphen beim dritten Modell ist nicht mehr signifikant. Genauer gesagt liegt RAGs Stärke nicht darin, häufiger richtig zu liegen, sondern darin, seltener gravierend falsch zu liegen. Wenn die Informationsabrufung unvollständig ist, gibt es unvollständige Antworten. Wenn die Entity-Matching-Funktion versagt, gibt der Graph falsche und selbstsichere Antworten ab. Für einen internen Assistenten ist dieser Unterschied entscheidend: Ein Entwickler kann eine unvollständige Antwort ergänzen, doch eine falsche Antwort mit zitiertem Quellenverweis wird in einem Meeting weiterverwendet.

Die Ergebnisse der Jury werden gleich folgen:

Das Gremium bevorzugt RAG bei allen drei Modellen, einschließlich demjenigen, in dem die Heuristik dem Graphen einen deutlichen Vorteil gab. Das ist ein Instrumenteneffekt und keine Widersprüchlichkeit. In einem konkreten Fall erhielt eine Frage eine lexikalische Ähnlichkeit von 0,25 und wurde von der Heuristik als falsch eingestuft, doch das Gremium vergab 2,88 von 3 Punkten. Die Antwort war richtig, nur in anderen Worten formuliert. N-gramm-Metriken messen das Vokabular, während die LLM-Bewerter die wahrgenommene Richtigkeit mit Voreingenommenheit beurteilen. Keines von beidem beantwortet die Frage für sich allein, und wenn sie unterschiedlicher Ansicht sind, zeigt dieser Unterschied an, wo man suchen muss.

Das Gremium verdient eine ehrliche Einschränkung: Die Übereinstimmung zwischen den Bewertern war nur mäßig, mit einem Cohen’schen Kappa zwischen 0,09 und 0,56. Ein Gremium aus LLM-Bewertern ist kein Präzisionsmaß. Es handelt sich um eine strukturierte zweite Meinung, und Frameworks wie RAGAS existieren genau deshalb, weil die Bewertung der retrieval-augmented Generation weiterhin ein offenes Problem bleibt.

Was die Latenz angeht, war RAG bei allen drei Modellen 12 bis 20 Prozent schneller. Der Kontext des Graphen ist kompakter, doch die Abfrage erfordert einen zusätzlichen Schritt. Die Kosten variieren je nach Modell: Der Graph ist bei zwei Generatoren günstiger und bei einem teurer. Die Mischung aus Eingabetoken und Ausgabetoken unterscheidet sich bei den Anbietern stark genug, um das Ergebnis zu verändern. Das ist eine Beobachtung, keine Schlussfolgerung, da die Tokenzusammensetzung nicht formal getestet wurde.

Warum jeder Ansatz versagt

Das ist der nützlichste Teil – er kommt in keiner Tabelle vor.

Das Diagramm versagt strukturell. Bei der Frage, welche Datenbank ein Service verwendet, gab es den Knotenidentifikator anstelle des Engines zurück, weil das Attribut nicht modelliert wurde. Bei der Frage, wie viele Teams eine bestimmte Technologie nutzen, lieferte die Nachbarschaft in einem Schritt zwei Services an und antwortete zuversichtlich mit „zwei“. Wenn die ungenaue Abgleichsmethode die falsche Entität auswählt, ist der gesamte Kontext fehlerhaft, ohne dass etwas darauf hindeutet.

RAG versagt aufgrund von Unvollständigkeit. Es erkennt zwar richtig, dass ein Service Redis verwendet, beschränkt die Antwort jedoch auf den abgerufenen Service, obwohl die Frage nach dem Gesamtbild verlangte.

Sowohl Ansätze sind auf unterschiedliche Weise falsch. Die Mängel ergänzen sich gegenseitig, genau deshalb ist die offensichtliche Richtung ein Hybridansatz mit Routing nach Frageart.

Empfehlungen

Wählen Sie zunächst das Modell aus. Es ist die Variable mit dem größten Einfluss. Wenn man es als Implementierungsdetail behandelt und dabei Wochen damit verbringt, die Größe der Fragmente zu optimieren, optimiert man lediglich einen Parameter zweiter Ordnung.
Beginnen Sie mit RAG. Es bietet eine bessere Grundlage sowie geringere Betriebskosten, und sein Ausfallmuster ist akzeptabel.
Fügen Sie Struktur gezielt hinzu, für Abhängigkeiten, Eigentumsverhältnisse und Ereigniskonsum. Versuchen Sie nicht, das gesamte Ökosystem vor der Bereitstellung von Ergebnissen zu modellieren.
Verlassen Sie sich nicht auf eine einzige Metrik. Verwenden Sie eine deterministische Heuristik sowie Methoden aus verschiedenen Kategorien. Wenn diese unterschiedliche Ergebnisse liefern, deutet das auf einen interessanten Fall hin – nicht auf einen Fehler.
Verwenden Sie einen Paartest. Beide Strategien beantworten dieselben Fragen, und der Vergleich der Mittelwerte ohne McNemar liefert ein Vertrauensniveau, das von den Daten nicht gestützt wird.

Einschränkungen

Das Datensatz ist synthetisch und die Lösungsschlüssel stammen vom Experimentator selbst. Kein echter Benutzer hat ihn überprüft. Dadurch wird Kontrolle und Reproduzierbarkeit gewährleistet, doch die externe Validität leidet darunter.
Die Implementierung des Graphen ist absichtlich einfach gehalten, wodurch einige Schwächen bei der Aggregation möglicherweise auf die Implementierung und nicht auf das zugrunde liegende Paradigma zurückzuführen sind.
Praktische Nützlichkeit und Wartbarkeit wurden nicht gemessen. Sie gehörten zu den Zielen und blieben daher qualitativ beschrieben.
Die Heuristik wurde nicht gegen menschliches Urteilsvermögen überprüft. Das Gremium verringert dieses Problem, löst es jedoch nicht.
Elf der 2.160 Antworten (0,51 %) waren Netzwerkfehler des Anbieters und keine Systemfehler.

Die Schlussfolgerung

Es wurde gehofft, mit „Verwenden Sie ein Diagramm“ oder „Verwenden Sie RAG“ zu enden. Tatsächlich stellte sich heraus, dass keines dieser Antworten vor der Entscheidung bezüglich des verwendeten Modells existiert, und dass die als Hintergrundvariable betrachtete Variable am meisten Gewicht hatte. Das ist weniger zufriedenstellend, aber nützlicher. Zudem lässt sich das auf andere Fälle übertragen: Ein Benchmark mit einer versteckten Variable macht keinen lauten Fehler, sondern weist einen Konfidenzintervall auf. Bevor man aus einer Reihe von Optionen eine Architektur wählt, sollte man fragen, was im Experiment konstant gehalten wurde – und ob das tatsächlich konstant bleiben sollte.