Eine kontrollierte Evaluation von Standard-RAG, LightRAG und Microsoft GraphRAG auf dem biomedizinischen BioCDQA-Benchmark — mit der Frage, ob graphgestützte Architekturen gegenüber einer gut abgestimmten Baseline messbare Vorteile liefern.
Retrieval-Augmented Generation (RAG) hat sich als praktikabler Ansatz für Question Answering auf spezialisierten Wissensbeständen etabliert — besonders dort, wo faktische Fundierung, Nachvollziehbarkeit und kontrollierbares Systemverhalten wichtiger sind als rein parametrisches Modellwissen. Gleichzeitig hat sich der Designraum moderner RAG-Systeme deutlich über einfache Vektor-Retrieval-Pipelines hinaus erweitert.
Ansätze wie Standard-RAG, LightRAG und GraphRAG treffen unterschiedliche Annahmen über Dokumentrepräsentation, Retrieval-Strukturen, Kontextaufbau und die Nutzung expliziter Beziehungen zwischen Entitäten. In diesem Mini-Paper evaluieren wir diese Ansätze anhand des BioCDQA-Benchmarks entlang praxisrelevanter Dimensionen: Antwortkorrektheit, Grounding über Quellen, Retrieval-Relevanz, Latenz, Ingestion-Komplexität und operative Kosten.
Ziel ist eine pragmatische Aussage darüber, ob komplexere Retrieval-Architekturen ihren zusätzlichen Aufwand bei Ingestion und Laufzeit rechtfertigen — und unter welchen Bedingungen sich welche Architektur für biomedizinische und vergleichbar spezialisierte Domänen eignet.
Vorab das zentrale Ergebnis: Auf dem ersten erhobenen Split liefert LightRAG die stärkste Qualitätsbalance und die mit Abstand günstigsten Anfragekosten — erkauft durch eine ähnlich teure Indexierung wie GraphRAG. Ob sich dieser Mehraufwand rechnet, hängt entscheidend am Anfragevolumen; die abschließende Entscheidungsmatrix übersetzt die Messdaten in konkrete Empfehlungen pro Einsatzszenario.
Die betrachteten Systeme unterscheiden sich vor allem darin, wie sie Wissen aus dem Dokumentkorpus repräsentieren und zur Anfragezeit nutzbar machen. Standard-RAG behandelt Dokumente primär als Menge einzelner Text-Chunks. Graphbasierte Ansätze wie Microsoft GraphRAG und LightRAG erweitern diese flache Repräsentation um explizite Entitäten, Relationen und strukturelle Zusammenhänge. Entscheidend für die Evaluation ist, ob diese zusätzlichen Strukturen tatsächlich messbare Vorteile gegenüber einer gut konfigurierten Baseline liefern.
Ingestion → Chunking → Indexierung → Retrieval → kontextgestützte LLM-Antwort. Dokumente werden als flache Chunks behandelt und über Keyword-, Vector- oder Hybrid Search abgerufen.
Graphbasiertes Text-Indexing mit Dual-Level Retrieval. Kombiniert Entitäten/Relationen mit Vector Search und unterstützt inkrementelle Updates — ohne den Overhead schwerer GraphRAG-Verfahren.
Knowledge-Graph-Erzeugung, hierarchische Community Detection und vorberechnete Community Summaries für corpusweite Sensemaking-Fragen via Map-Reduce-Summarization.
Standard-RAG ruft zur Laufzeit relevante externe Dokumente ab und integriert sie als Kontext in den Prompt, um domänenspezifisches Wissen nutzbar zu machen und Halluzinationen zu reduzieren. Die Pipeline besteht aus zwei Phasen: Ingestion (Sammeln, Normalisieren, Chunking, Indexierung) und Query-Time Retrieval. Die relevantesten Abschnitte werden zusammen mit der Anfrage an das Sprachmodell übergeben.
Stark bei exakten Begriffen, IDs, Abkürzungen, Eigennamen und seltenen Fachtermini. Schwach bei semantischer Ähnlichkeit ohne Wortüberlappung.
Relevanz über semantische Nähe statt identischer Begriffe. Schwach bei exakten Zahlen, Codes und sehr seltenen Begriffen.
Bewertet Kandidaten nach dem initialen Retrieval präziser. Verbessert das finale Kontextfenster — auf Kosten von Latenz und Rechenaufwand.
Hypothetical Query Embeddings erweitern kurze oder unspezifische Anfragen. Erhöht Recall, erzeugt aber zusätzliche LLM-Calls und Kosten.
GraphRAG adressiert global sensemaking questions — Fragen nach zentralen Themen, Trends oder übergreifenden Zusammenhängen, die nicht durch wenige lokale Textstellen beantwortet werden können. Statt Top-k-Chunks zu retrieven, erzeugt das System aus dem Korpus einen Knowledge Graph, zerlegt ihn hierarchisch in thematische Communities und berechnet bereits zur Indexing-Zeit Community Summaries vor.
Im Map-Schritt erzeugt das LLM partielle Antworten je Community-Batch und vergibt einen Hilfreichkeits-Score; nicht hilfreiche Antworten werden verworfen. Im Reduce-Schritt werden die verbleibenden Teilantworten zu einer globalen Antwort zusammengeführt. Die Stärken liegen laut Paper bei Comprehensiveness und Diversity; die Kosten entstehen durch die aufwendige Indexing-Phase. GraphRAG lohnt sich vor allem bei großen, statischen Korpora mit vielen wiederkehrenden globalen Analysefragen.
LightRAG erweitert chunkbasierte Pipelines um eine strukturierte Wissensrepräsentation, ohne den schweren Community-Overhead von GraphRAG. Die Methodik besteht aus graphbasiertem Text-Indexing, Dual-Level Retrieval und retrieval-augmented Answer Generation. Entitäten bilden Knoten, Relationen bilden Kanten — beide angereichert mit textuellen Key-Value-Beschreibungen über LLM Profiling und dedupliziert für einen kompakten, durchsuchbaren Graph.
Fokussiert auf konkrete Entitäten, Attribute und direkte Beziehungen. Liefert Tiefe für spezifische Fragen.
Fokussiert auf breitere Themen und übergeordnete Konzepte. Liefert Breite für analytische Fragen.
Kombiniert Graphstruktur mit vektorbasiertem Retrieval — schneller und günstiger als das Traversieren großer Community-Strukturen.
Neue Dokumente werden in den bestehenden Graph integriert, statt den Index vollständig neu aufzubauen — ideal für dynamische Wissensbasen.
Für die Evaluation wird der biomedizinische QA-Datensatz thinktecture/biocdqa-rag verwendet. BioCDQA basiert auf PubMed-Volltexten und manuell annotierten Frage-Antwort-Paaren. Jede Frage ist mit konkreten PubMed-Artikeln verknüpft, die den Ground-Truth-Kontext bilden. Die durchschnittliche Dokumentgröße liegt bei ca. 53.000 Zeichen bzw. — je nach Tokenizer — etwa 21.000 Tokens (biomedizinische Volltexte tokenisieren mit ~2,5 Zeichen/Token dichter als Alltagstext); der Gesamtkorpus umfasst damit grob 1,1 M Tokens.
Alle Systeme teilen sich dieselben Modelle und Komponenten; die gemessenen Unterschiede stammen damit ausschließlich aus der Retrieval- und Kontextstrategie, nicht aus unterschiedlichen Backbones.
| Rolle | Komponente |
|---|---|
| LLM — alle Aufrufe (Antwort, Extraktion, HyQE, Map-Reduce) | gpt-oss-120b |
| Embeddings — alle Aufrufe | qwen3-embedding:8b · 4096 dim |
| Reranker (nur Standard-RAG) | Cohere Rerank 4 Pro via OpenRouter |
| Evaluation | LLM-as-a-judge (gpt-oss-120b) · Tracing über Langfuse |
Der Datensatz ist in mehrere Tiers unterteilt, die über Korpusgröße, Signal-Anteil und Evaluationsumfang skalieren. Je niedriger der Signal-Anteil (QA-Docs zu Gesamtdokumenten), desto schwieriger das Retrieval — relevante Dokumente müssen in zunehmend verrauschten Korpora gefunden werden. Der zur Ergebniserhebung genutzte XXS-Split bildet dabei den Sonderfall ohne Distraktoren ab (Signal 100 %, 0 Noise-Docs): Die bisherigen Retrieval-Metriken werden also noch völlig ohne Such-Noise gemessen — die Noise-Robustheit der Verfahren ist damit bislang ungetestet.
| Tier | Profil | Dok. gesamt | QA-Docs | Noise-Docs | QA-Paare | Signal |
|---|---|---|---|---|---|---|
| xxs | biocdqa-xxs | 52 | 52 | 0 | 50 | 100 % |
| xs | biocdqa-xs | 527 | 50 | 477 | 83 | 9,5 % |
| s | biocdqa-s | 1.132 | 149 | 983 | 183 | 13,2 % |
| m | biocdqa-m | 2.180 | 494 | 1.686 | 435 | 22,7 % |
| l | biocdqa-l | 3.368 | 1.043 | 2.325 | 737 | 31,0 % |
| xl | biocdqa-xl | 6.287 | 1.687 | 4.600 | 987 | 26,8 % |
| xxl | biocdqa-xxl | 11.205 | 2.117 | 9.088 | 1.133 | 18,9 % |
Die Observability basiert zentral auf Langfuse. Jede CLI-Ausführung erzeugt eine eigene Session mit eindeutiger ID, über die alle Spans, Modellaufrufe, Retrieval-Schritte und Evaluationsmetriken einer gemeinsamen Trace-Struktur zugeordnet werden. Das Tracing unterscheidet automatische Spans für Modellaufrufe und explizite Spans für Pipeline-Schritte; fehlerhafte Schritte werden mit Fehlerstatus erfasst statt verloren zu gehen.
Eingabe, Antwort, Modellname, Rolle und Tokenverbrauch — z. B. für Antwortgenerierung, HyQE-Generierung oder LLM-Evaluation.
Retrieval, Reranking, externe RAG-Abfragen und Evaluationslogik werden als explizite Spans sichtbar.
Latenz, Tokenverbrauch, geschätzte Kosten und Retrieval-Größe pro Query als Langfuse-Scores.
Relevance, Correctness, Faithfulness, Context Recall, Document Recall/Precision und Passage Recall auf Experimentebene.
Für Microsoft GraphRAG werden zusätzlich interne LLM-Aufrufe über LiteLLM und OpenTelemetry angebunden, sodass auch Entity Extraction, Community Report Generation und Map-Reduce-Summarization innerhalb der Trace-Struktur erscheinen. Ein Offline-Modus deaktiviert die Observability für Unit-Tests und lokale Läufe als No-op.
Zum aktuellen Zeitpunkt wurde ausschließlich der XXS-Split erhoben, da größere Splits erhebliche Kosten verursachen. Alle Systeme liefen auf der identischen Modellbasis aus der Methodik (gpt-oss-120b, qwen3-embedding:8b, Cohere Rerank 4 Pro), sodass sich Unterschiede primär auf die Retrieval- und Kontextstrategie zurückführen lassen. Wir betrachten die Ergebnisse in drei Schritten: zuerst die Antwort- und Retrieval-Qualität, dann Kosten und Latenz zur Query-Zeit und schließlich die einmaligen Ingestion-Kosten — am Ende zu einer Total-Cost-Betrachtung zusammengeführt.
Der ursprüngliche Vorbehalt gegenüber GraphRAG lautete, das Verfahren nur dann weiterzuverfolgen, wenn ein alternativer Query-Modus die Faithfulness deutlich verbessert. Genau das zeigt der Local-Search-Run: gegenüber dem globalen Map-Reduce-Modus steigt die Faithfulness von 0.106 auf 0.373 und der Context Recall von 0.095 auf 0.429 — bei gleichzeitig höchster Relevance aller vier Varianten (0.899). Die Schwäche lag also im globalen Antwortmechanismus, nicht in der Graph-Architektur an sich.
Die vollständigen Metriken des XXS-Splits. Document Recall, Document Precision und Passage Recall sind nur für die Systeme verfügbar, die explizite Quell-Signale liefern.
| Metrik | Standard-RAG | LightRAG | GR · Global | GR · Local |
|---|---|---|---|---|
| relevance | 0.806 | 0.863 | 0.857 | 0.899 |
| correctness | 0.385 | 0.492 | 0.535 | 0.483 |
| faithfulness | 0.674 | 0.986 | 0.106 | 0.373 |
| context_recall | 0.443 | 0.712 | 0.095 | 0.429 |
| document_recall | 0.747 | 0.776 | — | — |
| document_precision | 0.602 | 0.686 | — | — |
| passage_recall | 0.755 | 0.317 | 0.365 | — |
| count (n) | 50 | 50 | 50 | 50 |
Konfigurationen: Standard-RAG mit Rerank und HyQE · LightRAG Mix Mode (Default) · GraphRAG Official im fast-Modus (NLP-Extraktion) mit 3.389 Communities, Map-Reduce, minimales Granularitätslevel · GraphRAG Local Search.
Die folgenden Werte vergleichen alle drei Pipelines auf biocdqa-xxs mit gpt-oss-120b über je 50 Queries. GraphRAG entspricht dem Local-Search-Lauf (Level L2), Standard-RAG dem Setup mit Reranker. Die End-to-End-Latenz umfasst Embedding, Retrieval und Antwortgenerierung; die Token-Werte sind die provider-abrechenbaren („billable") Ströme — der Eval-Overhead der LLM-Judges ist hier bewusst ausgeklammert.
Die Latenz ist stark providerabhängig: Bei Engpässen von Compute und Verfügbarkeit — auch unter Nutzung von OpenRouter — kann sie deutlich schwanken, und um diese Faktoren lässt sich kaum bereinigen. Die folgenden Latenzwerte (Tabelle 3 sowie die Median-Balken oben) sind daher eine indikative Momentaufnahme, keine stabile Systemeigenschaft. Die Token-Mengen sind davon unberührt und bleiben die belastbarere Vergleichsgröße.
| Pipeline | Avg | Median | P95 | P99 |
|---|---|---|---|---|
| Standard-RAG | 12,44 s | 9,43 s | 31,08 s | 39,65 s |
| LightRAG | 7,86 s | 6,49 s | 17,35 s | 19,85 s |
| GraphRAG Local | 8,21 s | 7,23 s | 14,82 s | 15,57 s |
| GraphRAG Global | 18,1 s | 16,8 s | 31,3 s | 33,4 s |
| Pipeline · Strom | Avg | Median | P95 | P99 | Σ Run |
|---|---|---|---|---|---|
| LightRAG · billable total | 4.360 tok | 4.455 tok | 5.295 tok | 5.453 tok | 217.982 tok |
| GraphRAG Local · Answer (LLM) | 13.375 tok | 13.428 tok | 14.289 tok | 14.741 tok | 668.768 tok |
| ↳ davon Input | 11.596 tok | — | — | — | 579.809 tok |
| ↳ davon Output | 1.779 tok | — | — | — | 88.959 tok |
| Standard-RAG · billable total | 69.745 tok | 64.027 tok | 121.220 tok | 132.273 tok | 3.487.239 tok |
| ↳ davon Answer-LLM | 4.415 tok | 4.378 tok | 5.366 tok | 5.853 tok | 220.769 tok |
| ↳ davon Reranker-Input | 65.263 tok | 59.563 tok | 116.992 tok | 127.895 tok | 3.263.152 tok |
| ↳ davon Embedding-Input | 66 tok | 58 tok | 135 tok | 174 tok | 3.318 tok |
| GraphRAG Global · billable total | 595.705 tok | 593.385 tok | 612.884 tok | 623.154 tok | 29.785.250 tok |
| ↳ davon Prompt | 585.496 tok | 584.651 tok | 592.488 tok | 592.531 tok | 29.274.800 tok |
| ↳ davon Output | 10.208 tok | 8.704 tok | 20.406 tok | 30.623 tok | 510.400 tok |
Mit Ø 4.360 Tokens/Query ist LightRAG der günstigste Ansatz — rund 3× weniger als GraphRAG Local (13.375) und 16× weniger als Standard-RAG (69.745). Das Retrieval beruht auf Vektor- und Nachbarschafts-Lookups statt teurer Graph-Traversierung; die abrechenbaren Tokens entfallen im Wesentlichen auf die Query-Keyword-Extraktion und den kompakten Antwort-Prompt. Auch latenzseitig führt LightRAG: Median 6,49 s (Ø 7,86 s) ist die niedrigste zentrale Latenz im Feld.
GraphRAG Local liegt mit 13.375 Tokens/Query dazwischen und ist mit ~87 % Input-Anteil durch die vorberechneten Community-Reports getrieben. Sein eigentlicher Vorzug ist die Latenz-Stabilität: Bei Median 7,23 s (Ø 8,21 s) besitzt es die engste Verteilung des Feldes — P95 14,82 s und P99 15,57 s bleiben deutlich unter LightRAGs Tails (17,35 s / 19,85 s). Für harte Latenz-SLAs ist das die vorhersehbarste Wahl.
Standard-RAGs scheinbar dramatische 69.745 Tokens/Query sind kein LLM-Problem: Das Antwortmodell verbraucht nur 4.415 Tokens, während der Reranker-Input mit 65.263 Tokens rund 94 % der Rechnung ausmacht. Pro Query werden also ~65k Tokens an Kandidaten durch den Reranker geschoben — ein Konfigurations-Kostentreiber, kein architektureller Zwang. Derselbe große Kandidatenstapel schlägt zudem direkt auf die Latenz durch: Der Reranking-Schritt ist der dominante Beitrag zu Standard-RAGs schwacher Latenz — Median 9,43 s, und mit P95 31,08 s / P99 39,65 s die schlechtesten Tails der vollständig gemessenen Läufe. Ein kleineres Kandidatenfenster würde damit beides entlasten, Token-Kosten und Latenz, ohne notwendigerweise die Antwortqualität zu treffen.
GraphRAG Global sprengt diesen Rahmen vollständig. Eine einzige Global-Query kostet ~596.000 Tokens über 48 LLM-Calls — rund 45× mehr als GraphRAG Local und ~9× mehr als Standard-RAG; über den 50-Query-Lauf summiert sich das auf ~29,8 Mio. Tokens. Der Grund liegt im Map-Reduce-Mechanismus: Zur Anfragezeit werden faktisch alle vorberechneten Community-Reports batchweise durch das LLM geschoben (~98 % der Tokens sind Prompt-Input). Auch latenzseitig ist Global mit Median 16,8 s der langsamste Modus — rund doppelt so langsam wie LightRAG oder GraphRAG Local, allerdings mit einem stabileren Tail (P99 33,4 s) als das ausreißeranfällige Standard-RAG (39,65 s).
Auf Query-Ebene ordnet sich das Feld nach Token-Volumen klar: LightRAG (4.360) ≪ GraphRAG Local (13.375) ≪ Standard-RAG (69.745, reranker-dominiert) ≪ GraphRAG Global (595.705). Die Median-Latenz folgt derselben Reihung — mit der Ausnahme der Tails, wo GraphRAG Local trotz höherer Token-Last die engste Verteilung hält. Ob diese Query-Kosten den jeweiligen Indexierungsaufwand rechtfertigen, entscheidet sich erst in der Total-Cost-Betrachtung; die beiden Posten verhalten sich, wie der nächste Abschnitt zeigt, spiegelbildlich.
Die Query-Zeit ist nur die halbe Rechnung. Die einmalige Indexierung fällt je System sehr unterschiedlich aus — und entgegen der Intuition ist die leichtgewichtige Graph-Variante hier nicht günstig. Der direkte Vergleich der drei Indizes (der GraphRAG-Index dient sowohl Local als auch Global):
GraphRAGs Indexierung von biocdqa-xxs lief im fast-Modus — LLM gpt-oss-120b, Embeddings qwen3-embedding-8b, echte Provider-Token aus dem GraphRAG-Log.
| Kennzahl | Wert |
|---|---|
| Wall-Clock (gesamt) | 7.678,6 s (≈ 2 h 08 min) |
| Tokens gesamt | 25.063.330 Tok |
| LLM-Calls gesamt | 4.688 (3.389 LLM + 1.299 Embedding) |
| Dokumente | 52 |
| Modell | Rolle | Requests | Prompt-Tok | Completion-Tok | Total-Tok |
|---|---|---|---|---|---|
| gpt-oss-120b | LLM (Community-Reports) | 3.389 | 16.649.026 | 4.652.201 | 21.301.227 |
| qwen3-embedding-8b | Embeddings | 1.299 | 3.762.103 | — | 3.762.103 |
| Gesamt | 4.688 | 20.411.129 | 4.652.201 | 25.063.330 |
| Workflow | Dauer | Anteil |
|---|---|---|
| create_community_reports_text (LLM) | 4.701,4 s | 61,2 % |
| generate_text_embeddings | 2.765,9 s | 36,0 % |
| extract_graph_nlp (NLP, keine LLM-Token) | 100,4 s | 1,3 % |
| finalize_graph | 66,0 s | 0,9 % |
| create_final_text_units | 28,0 s | 0,4 % |
| create_communities | 10,0 s | 0,1 % |
| prune_graph | 4,4 s | 0,1 % |
| create_base_text_units | 2,4 s | <0,1 % |
| create_final_documents | 0,1 s | <0,1 % |
| Tabelle | Zeilen |
|---|---|
| documents | 52 |
| text_units (Chunks) | 1.828 |
| entities | 13.422 |
| relationships | 488.516 |
| communities | 3.389 |
| community_reports | 3.352 |
GraphRAGs einmalige Indexierung verbrauchte 25,06 Mio. Tokens und 2 h 08 min Wall-Clock — für gerade 52 Dokumente (~482k Indexierungs-Tokens pro Dokument, also rund das 23-Fache der reinen Dokumentgröße von ~21k Tokens). Zur Einordnung: Das entspricht rund 1.870 GraphRAG-Antworten (Ø ~13.375 Tokens). Auf dem 50-Query-Eval ist die Indexierung damit etwa 37× teurer als die gesamte Query-Last (25,06 M gegenüber 0,67 M Tokens).
Die LLM-Last (21,3 M der 25 M Tokens) geht fast vollständig in die Community-Report-Generierung: 3.389 LLM-Calls decken sich ~1:1 mit den 3.352 erzeugten Reports und machen 61 % der Laufzeit aus. Bemerkenswert ist, dass dies der fast-Modus ist, in dem die Entity/Relation-Extraktion per NLP läuft (100 s, 0 LLM-Tokens). Selbst ohne LLM-Extraktion bleibt die Indexierung also teuer — der Kostentreiber sind nicht die Entitäten, sondern die Reports. Die Embeddings (3,76 M Tokens) stellen die restlichen 36 % der Zeit.
Auffällig ist die Graphdichte: Aus 52 Dokumenten entstehen 13.422 Entitäten und 488.516 Relationen — rund 9.400 Relationen pro Dokument. Diese Explosion erklärt die 3.389 Communities und einen Großteil der Kosten und deutet auf einen sehr dichten, im fast-Modus per NLP über-generierten Graphen hin. Ob diese Dichte der Antwortqualität nützt oder primär Rauschen erzeugt, ist offen — GraphRAGs schwache Faithfulness (Tabelle 2) spricht eher für Letzteres.
Die Standard-RAG-Indexierung (HyQE-Variante) wurde post-hoc und deterministisch aus dem bestehenden Index geschätzt (Tokenizer o200k_base).
| Komponente | Pass | Token |
|---|---|---|
| Embedding (qwen3-embedding-8b) | Semantic Chunker (Sätze) | ~2.304.673 |
| Chunk-Storage (alle Chunks 1×) | 2.304.673 | |
| HyQE-Fragen | 224.099 | |
| Embedding gesamt | ~4.833.445 | |
| HyQE-LLM (gpt-oss-120b small) | Input (Prompt 68 + Chunk) | 2.458.693 |
| Output (Fragen-Token) | 224.099 | |
| HyQE-LLM gesamt | 2.682.792 | |
| Gesamt | ~7.516.237 |
Das korrigiert eine naheliegende Fehlannahme: Standard-RAGs Indexierung ist nicht LLM-frei. Das HyQE-Verfahren erzeugt pro Chunk hypothetische Fragen und verursacht damit 2,68 M LLM-Tokens — rund ein Drittel der ~7,5 M Gesamtkosten. Mit ~7,5 M bleibt Standard-RAG dennoch klar unter GraphRAGs ~25,06 M (~3,3× weniger). Der Embedding-Posten enthält dabei zwei Pässe über den Korpus. Der SemanticChunker (langchain-experimental) bettet zunächst überlappende 3-Satz-Fenster ein (buffer_size = 1: je Satz das Fenster aus Vorgänger, Satz und Nachfolger), um über die Cosinus-Distanz benachbarter Fenster die semantischen Breakpoints zu finden; jeder Token landet so in ~3 Fenstern, weshalb dieser Pass ein Mehrfaches der reinen Korpusgröße embedded. Anschließend werden die finalen Chunks für die Qdrant-Speicherung einmal eingebettet. In Summe liegen die ~4,8 M Embedding-Tokens damit bei rund dem Vierfachen des ~1,1-M-Rohkorpus — methodisch erwartbar und kein Fehler, sondern der Preis des semantischen gegenüber festem Chunking. Die 5.788 HyQE-Fragen liegen mit ~2,6/Chunk rund 15 % unter dem Ziel von 3, vermutlich durch HyQE-Failures.
Die LightRAG-Indexierung liefert als einzige der drei provider-gemessene Token (qwen3 meldet Usage); zur Vergleichbarkeit mit Tabelle 5 und 9 ist zusätzlich eine o200k-Schätzung ausgewiesen.
| Komponente | nativ (Provider) | o200k (vergleichbar) |
|---|---|---|
| LLM-Extraktion | 22.402.305 | 16.511.883 |
| Embedding | 4.543.329 | 4.274.054 |
| Σ billable | 26.945.634 | 20.785.937 |
Damit fällt die letzte Annahme: LightRAGs Indexierung ist nicht das leichtgewichtige Gegenstück, als das der Name sie nahelegt. Mit 20,79 M Tokens (o200k, vergleichbar erhoben) liegt sie nur knapp unter GraphRAGs 25,06 M und rund 2,8× über Standard-RAG (7,52 M); auf nativer Provider-Basis übertrifft sie mit 26,95 M sogar GraphRAG. Der Treiber ist dieselbe LLM-Last wie dort: Entity- und Relation-Extraktion samt Profiling kostet 22,4 M Tokens nativ (Prompt 13,03 M / Completion 9,37 M) über 2.558 Chat-Calls — die hohe Completion-Last spiegelt die generierten Beschreibungen. Konkret umfasst der einmalige Index 22,4 M LLM- und 4,5 M Embedding-Tokens (nativ) bei ~60 min Wall-Clock für die 47 sauberen Dokumente (~106 min inkl. hängendem Tail).
Daraus ergibt sich der eigentliche Total-Cost-Trade zwischen Indexierung und Query-Zeit, der die beiden günstigsten Systeme spiegelbildlich macht. Standard-RAG ist billig zu indexieren (7,52 M), aber teuer pro Query (69.745 Tok); LightRAG ist teuer zu indexieren (20,79 M), aber mit Abstand am günstigsten pro Query (4.360 Tok). Die teure Indexierung amortisiert sich also über das Anfragevolumen — die folgende Total-Cost-Betrachtung rechnet das über alle vier Varianten konkret durch.
Das schärft das Argument für LightRAGs inkrementelle Updates: Gerade weil ein vollständiger Index teuer ist (~21 M Tokens), zählt es, ihn bei neuen Dokumenten nicht komplett neu aufbauen zu müssen — anders als bei GraphRAG, dessen Community-Struktur bei nennenswerten Änderungen neu berechnet wird. GraphRAG bleibt damit das ungünstigste Gesamtprofil: ähnlich teure Indexierung wie LightRAG, aber zusätzlich die teuersten Queries (Global) bzw. nur moderate Einsparungen bei schwächerem Grounding (Local). Zur Mess-Asymmetrie: LightRAGs Ingestion ist mit measured_provider die am saubersten erhobene der drei, GraphRAG ist log-geparst, Standard-RAG geschätzt — die o200k-Spalte stellt die Vergleichsbasis her.
Erst Ingestion und Query-Zeit zusammen ergeben das wahre Kostenbild. Die folgende Tabelle führt beide Posten für alle vier Varianten zusammen und rechnet sie auf zwei Betriebspunkte hoch — 50 Queries (Eval-Größe) und 5.000 Queries (Produktivnähe).
| System | Ingestion (einmalig) | pro Query | Σ @ 50 Queries | Σ @ 5.000 Queries |
|---|---|---|---|---|
| Standard-RAG | 7,5 M | 69.745 | 11,0 M | 356 M |
| LightRAG | 20,8 M | 4.360 | 21,0 M | 42,6 M |
| GraphRAG Local | 25,1 M | 13.375 | 25,7 M | 91,9 M |
| GraphRAG Global | 25,1 M | 595.705 | 54,8 M | ~3,0 Mrd |
Alle Summen sind rohe billable Tokens und aggregieren bewusst heterogene Ströme: Reranker-Input (Standard-RAG), LLM-Prompt/Completion und Embeddings zählen hier gleich. Standard-RAGs Gesamtwert ist zu ~94 % reranker-getriebener Input — ein über die Kandidaten-Fenstergröße tunbarer Konfigurationsposten, kein architektureller Zwang. Die Rangfolge ist damit eine Volumen-Rangfolge unter der aktuellen Konfiguration; verkleinert man Standard-RAGs Fenster, sinkt dessen Query-Volumen und der Break-even verschiebt sich entsprechend. Eine streamgewichtete Betrachtung bleibt Future Work (Abschnitt 04).
Das Ergebnis ist volumenabhängig und spiegelbildlich. Bei 50 Queries führt Standard-RAG mit 11,0 M Tokens, weil seine billige Indexierung dominiert; bei 5.000 Queries ist LightRAG mit 42,6 M das günstigste System, während Standard-RAG durch den reranker-getriebenen Query-Aufwand auf 356 M steigt — der Break-even liegt bei rund 200 Queries. GraphRAG Local bleibt durchgehend teurer als LightRAG (höhere Indexierung und höhere Query-Kosten), und GraphRAG Global ist auf jedem Betriebspunkt das mit Abstand teuerste System — bei 5.000 Queries im Milliardenbereich.
Welche Architektur diese Volumenkurven in eine Empfehlung übersetzen, behandelt die Diskussion (Abschnitt 04) entlang von Qualität, Grounding und Betriebsprofil — die Entscheidungsmatrix (Abschnitt 05) führt es pro Szenario zusammen.
Die XXS-Ergebnisse sind keine abschließende Rangfolge, sondern eine erste indikative Messung unter kontrollierten Bedingungen. Dennoch zeichnen sich bereits auf dem kleinsten Split klare Systemcharakteristika ab. Die folgende Einordnung gewichtet zunächst die Antwort- und Retrieval-Qualität; Kosten und Latenz aus Abschnitt 03 fließen anschließend in die Entscheidungsmatrix ein.
Eine hohe Correctness ist das primäre Ziel aus Nutzersicht — reicht zur Bewertung eines RAG-Systems allein aber nicht aus. RAG soll richtige Antworten aus den bereitgestellten Quellen ableiten.
LightRAG zeigt die stärkste Gesamtleistung: höchste Faithfulness (0.986), bester Context Recall (0.712) und eine Correctness (0.492) deutlich über der Baseline. Das System stellt nicht nur relevante Kontexte bereit, sondern nutzt sie auch besonders konsistent. Auffällig ist der niedrige Passage Recall (0.317): LightRAG trifft seltener exakt die Gold-Passagen, erzeugt aber dennoch gut kontextgestützte Antworten — ein Hinweis auf stärkere semantische bzw. strukturierte Kontextaggregation. Bei größeren, stärker verrauschten Splits könnte die fehlende exakte Passageabdeckung jedoch zum Risiko werden.
Die Baseline liefert die stärksten expliziten Retrieval-Signale: Document Recall 0.747, Document Precision 0.602 und Passage Recall 0.755. Sie findet die richtigen Dokumente und Passagen, bleibt aber mit einer Correctness von 0.385 hinter LightRAG zurück. Die Schwäche liegt also nicht im Auffinden der Evidenz, sondern in deren Nutzung für die finale Antwortsynthese — wahrscheinliche Ursachen: Chunk-Zuschnitt, Kontextkomposition nach dem Reranking, Anzahl übergebener Passagen oder das Antwortprompting.
Im globalen Map-Reduce-Modus erzielt GraphRAG den höchsten Correctness-Wert des Feldes (0.535) — der Vorsprung gegenüber LightRAG (0.492) ist mit 0.043 Punkten etwas deutlicher, auf n = 50 aber weiterhin nicht belastbar. Gleichzeitig brechen Faithfulness (0.106) und Context Recall (0.095) regelrecht ein: Die korrekten Antworten sind kaum durch den als Kontext gewerteten Input gedeckt. Diese Divergenz — höchste Korrektheit bei zugleich schlechtestem Grounding des Feldes — lässt mindestens zwei konkurrierende Erklärungen zu, die der XXS-Split nicht trennen kann:
Das Modell antwortet überwiegend aus internem Wissen statt aus den retrievten Community-Reports. Dann wären die korrekten Antworten tatsächlich nicht gegroundet — für reguliertes QA das ungünstigste Profil.
Faithfulness/Context-Recall messen die Überlappung der Antwort mit dem bereitgestellten Kontext. Bei Global ist dieser Kontext eine stark abstrahierte Map-Reduce-Synthese vorberechneter Reports, nicht der Quelltext — eine korrekt abgeleitete Antwort kann so niedrig scoren, ohne ungegroundet zu sein.
Beide Hypothesen sind mit den Daten vereinbar; der niedrige Context Recall (0.095) allein entscheidet nicht zwischen ihnen. Erschwerend ist die Judge-Konfiguration: Bewerter und Generator sind dasselbe Modell (gpt-oss-120b), sodass Self-Preference-Bias die Correctness systematisch zugunsten der eigenen Outputs verschieben kann — und zwar gerade dort, wo H1 ein Grounding-Defizit unterstellt. Eine saubere Trennung erfordert (a) ein unabhängiges Judge-Modell und (b) eine Faithfulness-Messung gegen den Quelltext statt gegen die Report-Synthese. Bis dahin gilt unabhängig von der zutreffenden Hypothese: Eine Antwort, deren Herkunft sich nicht gegen die Quellen verifizieren lässt, ist für biomedizinische Auditierbarkeit schwer vertretbar.
Der Local-Search-Modus verschiebt dieses Bild deutlich. Faithfulness (0.373) und Context Recall (0.429) liegen rund 3,5× bzw. 4,5× über dem globalen Modus, und die Relevance (0.899) ist die höchste im gesamten Feld — bei nahezu identischer Correctness (0.483 vs. 0.535). Damit ist der ursprüngliche Vorbehalt teilweise entkräftet: GraphRAGs Grounding-Schwäche war eine Eigenschaft des globalen Antwortmechanismus, nicht der Graph-Architektur. Dennoch bleibt Local Search beim entscheidenden Grounding klar hinter LightRAG (Faithfulness 0.373 vs. 0.986; Context Recall 0.429 vs. 0.712).
Beste Qualitätsbalance, günstigste Queries und niedrigste Median-Latenz. Teure Indexierung, die sich ab ~200 Queries amortisiert. Erste Wahl für Volumen- und Dauerbetrieb.
Stärkster expliziter Retriever und billigste Indexierung, aber teuerste Queries (Reranker ~94 % der Token und dominanter Latenztreiber). Optimal für kleine, statische Korpora — Kandidatenfenster verkleinern, Antwortsynthese gezielt verbessern.
Engste Latenzverteilung im Feld, beste Relevance. Aber teure Indexierung wie GraphRAG und Grounding unter LightRAG — gerechtfertigt v. a. bei harten Latenz-SLAs.
Schwächstes Grounding und mit ~596k Tok/Query der teuerste Modus. Nur für echte corpusweite Sensemaking-Fragen, nicht für faktisches QA.
Die Aussagekraft ist durch die kleine Stichprobe (n = 50) und die Beschränkung auf den XXS-Split limitiert. Skalierungseffekte über zunehmenden Noise-Anteil, mehrere Quelldokumente pro Frage und größere Korpora sind noch offen. Insbesondere die Frage, ob LightRAGs niedriger Passage Recall bei höherem Noise zum Problem wird und ob GraphRAG Local seine Relevance-Stärke hält, lässt sich auf XXS nicht beantworten. Hinzu kommen zwei methodische Vorbehalte: Die Bewertung erfolgt per LLM-as-a-judge mit demselben Modell (gpt-oss-120b), das auch die Antworten erzeugt — ein bekanntes Bias-Risiko; und die Kostendaten der drei Systeme wurden auf leicht unterschiedlichen Mess-Basen (provider-gemessen, log-geparst, geschätzt) erhoben. Schließlich wurde LightRAG nur im Mix-Modus (Dual-Level) gemessen — die reinen Local- und Global-Modi von LightRAG sind ungetestet, obwohl gerade ein LightRAG-Global ein günstigerer Gegenspieler zu GraphRAG Global sein könnte.
Die Messdaten zeigen keinen universellen Sieger, sondern klare Eignungsprofile. Die folgende Matrix übersetzt Qualität, Kosten und Latenz in eine Empfehlung pro Einsatzszenario — gültig für das hier getestete Factoid-QA auf biomedizinischen Volltexten und unter dem Vorbehalt des kleinen XXS-Splits.
Die Kostenaussagen (Tokens, Latenz, Break-even) sind deterministisch gemessen und entscheidungsreif. Der Qualitätsteil wurde dagegen ausschließlich auf dem zero-noise XXS-Split erhoben — also genau in dem Regime, in dem graphbasierte Struktur ihren Mehrwert nicht ausspielen kann: Der Sinn von Entity-/Relation-Graphen liegt im verrauschten und mehrhopfigen Retrieval, das hier noch gar nicht vorkommt. Die GraphRAG-Qualitätszahlen sind daher hypothesen-, nicht entscheidungsreif; ein No-Go gegen die Graph-Architektur wäre auf dieser Basis verfrüht. Die Matrix ordnet ein, welche Kandidaten einen tieferen Blick auf XS–M verdient haben — sie spricht kein abschließendes Architektur-Urteil.
| Szenario / Anforderung | Empfehlung | Begründung |
|---|---|---|
| Hohes Anfragevolumen / Dauerbetrieb | LightRAG | Günstigste Query-Kosten (4.360 Tok) amortisieren die teure Indexierung — ab ~200 Queries das billigste System überhaupt. |
| Maximales Grounding & Auditierbarkeit (Pharma, Recht, Medizin) | LightRAG | Höchste Faithfulness (0.986) und Context Recall (0.712): Antworten sind am stärksten durch die Quellen gedeckt. |
| Dynamischer / wachsender Korpus | LightRAG | Inkrementelle Updates vermeiden die teure Neu-Indexierung; GraphRAG müsste die Community-Struktur neu berechnen. |
| Geringes Volumen (< ~200 Queries), stabiler Korpus | Standard-RAG | Billigste Indexierung (7,5 M) dominiert die Gesamtbilanz; Kandidatenfenster vorher verkleinern, um Query-Kosten und Latenz zu senken. |
| Stärkste explizite Quellen-/Passagentreffer (Zitatpflicht) | Standard-RAG | Bester Document Recall (0.747) und Passage Recall (0.755) — findet die exakten Belege am zuverlässigsten. |
| Harte Latenz-SLA (enge P95/P99) | GraphRAG Local | Engste Latenzverteilung (P95 14,82 s / P99 15,57 s) ohne Ausreißer-Tail — vorhersehbarste Antwortzeit. |
| Corpusweite Sensemaking-/Themenfragen (kein Factoid) | GraphRAG Global | GraphRAG Global aggregiert per Map-Reduce erschöpfend über alle Community-Reports — das auf Breitensynthese ausgelegte Verfahren. LightRAGs Global-Modus arbeitet dagegen selektiv (top-k) und wurde hier nicht gemessen. Vertretbar nur bei ~596k Tok/Query und schwachem Grounding. |
Für den praktischen Regelfall — ein wachsender Wissensbestand, anhaltendes Anfragevolumen und der Anspruch auf nachvollziehbare, quellengestützte Antworten — ist LightRAG die Standardwahl. Standard-RAG bleibt die pragmatische Option für kleine, statische Korpora mit wenigen Anfragen; GraphRAG Local ist der Spezialfall für latenzkritische Anwendungen, GraphRAG Global der Nischenfall für corpusweites Sensemaking. Die ursprüngliche Leitfrage — ob graphgestützte Architekturen ihren Mehraufwand rechtfertigen — lässt sich damit differenziert beantworten: ja, aber nur die leichtgewichtige Graph-Variante und erst ab hinreichendem Anfragevolumen.
Diese Empfehlungen gelten unter den dokumentierten Einschränkungen: n = 50, XXS-Split ohne Distraktoren, teils aus unterschiedlichen Läufen erhoben, LLM-as-a-judge mit demselben Modell wie die Generierung. Mit zunehmendem Noise und größeren Korpora kann sich insbesondere die Bewertung von LightRAGs niedrigem Passage Recall (0.317) verschieben.