Retrieval-Augmented Generation ist nicht gleich Retrieval-Augmented Generation. Wir haben vier moderne Ansätze systematisch verglichen — mit echten akademischen Texten, messbaren Metriken und einem öffentlichen Notebook zum Nachvollziehen.
RAG-Blogposts gibt es viele. Die meisten erklären das Grundprinzip — ein Sprachmodell bekommt vor der Antwort passende Textfragmente als Kontext — und belassen es dabei. Was fehlt, ist die Frage: Welcher RAG-Ansatz ist wann sinnvoll? Denn die Landschaft hat sich in den letzten zwei Jahren erheblich weiterentwickelt.
Wir haben deshalb ein Vergleichsframework aufgebaut, das vier aktuelle Strategien auf identischen Dokumenten, mit identischen Fragen und messbaren Kriterien gegenüberstellt. Die vollständigen Ergebnisse sind als öffentliches Jupyter Notebook einsehbar.
Die vier Strategien
Standard RAG ist der Ausgangspunkt. Eine Frage wird in einen Vektor umgewandelt, die ähnlichsten Textfragmente werden aus einer FAISS-Datenbank geholt, und das Sprachmodell erhält diese als Kontext. Schnell, vorhersehbar, gut verstanden. Für direkte Faktenfragen funktioniert das überraschend gut — in unserem Benchmark erzielte Standard RAG die höchste Faithfulness-Rate aller Strategien (0.73) bei der niedrigsten Latenz unter den selbst implementierten Ansätzen.
Agentic RAG fügt einen Reflexionsschritt ein. Das Modell entscheidet nach jedem Retrieval-Schritt selbst, ob die gefundenen Informationen ausreichen oder ob eine weitere Suchanfrage notwendig ist — ein sogenannter ReAct-Loop. Theoretisch elegant für mehrstufige Fragen. In der Praxis zeigte sich jedoch: Die höhere Komplexität führt zu mehr Tokens, längerer Latenz, und — interessanterweise — niedrigerer Faithfulness (0.45). Das Modell «denkt» mehr, bleibt dabei aber weniger nah am Quelltext.
Graph RAG verlässt das Paradigma der isolierten Textfragmente. Statt Chunks zu indexieren, werden Entitäten und ihre Beziehungen als Graph modelliert. Eine Frage löst dann eine Traversierung über zwei bis drei Hops aus — ideal für Korpora mit dichten Querverweisen. Unsere Testdokumente bilden genau eine solche Kette: AlexNet → BatchNorm → ResNet → Transformer → BERT → GPT-3. Graph RAG war in diesem Setup schneller als Standard RAG (4.0s vs. 5.5s) und lieferte den höchsten BLEU-Score.
Corrective RAG (CRAG) adressiert ein anderes Problem: Was passiert, wenn die abgerufenen Dokumente die Frage gar nicht beantworten können? CRAG bewertet jeden abgerufenen Chunk, formuliert bei schlechten Ergebnissen die Suchanfrage um und greift im Zweifelsfall auf eine externe Websuche zurück. Im Benchmark erzielte CRAG den besten MRR-Wert (1.0) und eine hohe Faithfulness (0.75) — auf Kosten der Latenz (15s) durch die zusätzlichen Retrieval-Schritte.
Was die Metriken wirklich aussagen
Wir haben fünf Dimensionen gemessen: Recall@5 (werden die richtigen Chunks gefunden?), MRR (wie weit oben steht der erste relevante Treffer?), BLEU (Textüberlappung mit Referenzantworten), Faithfulness (ist die Antwort im abgerufenen Kontext verankert?) sowie Latenz und Token-Verbrauch.
Ein wichtiger Befund: Diese Metriken korrelieren nicht immer. Agentic RAG hat den höchsten Token-Verbrauch, aber nicht die beste Antwortqualität. Standard RAG ist am ressourceneffizientesten und trotzdem kompetitiv bei Faithfulness. CRAG ist langsam, aber präzise bei der Rankingqualität.
Das bedeutet: Die «beste» Strategie hängt vom Anwendungsfall ab. Für eine interne Wissensdatenbank mit sauberem Corpus und einfachen Faktenfragen ist Standard RAG oft die richtige Wahl. Für komplexe Dokumente mit Querverweisen — etwa Vertragswerke, technische Dokumentationen oder wissenschaftliche Literatur — liefert Graph RAG strukturelle Vorteile. Wenn der Corpus heterogen oder unvollständig ist, lohnt sich der Overhead von CRAG.
Was wir dabei gelernt haben
Drei Erkenntnisse, die über die Zahlen hinausgehen:
Evaluation ist schwieriger als Implementierung. Einen RAG-Prototypen zu bauen dauert Stunden. Ihn sinnvoll zu evaluieren — mit realistischen Fragen, fairen Referenzantworten und aussagekräftigen Metriken — dauert Tage. BLEU allein genügt nicht; ohne Faithfulness als LLM-basierte Bewertung sieht man nicht, ob das Modell halluziniert oder sich tatsächlich auf den Kontext stützt.
Lokale Modelle sind produktionsreif — mit den richtigen Erwartungen. Das Framework läuft wahlweise mit einem lokalen llama.cpp-Server (Qwen 3.5B auf eigener Hardware), über die HF Inference API oder im Fallback auf TinyLlama. Für datenschutzsensible Anwendungsfälle ist das relevant: Vollständig lokal betriebenes RAG ist heute möglich, aber die Antwortqualität hängt stark von der Modellgrösse ab.
Komplexität hat Kosten. Agentic und Corrective RAG sind nicht pauschal besser als Standard RAG. In unserem Benchmark schnitten sie in wichtigen Dimensionen schlechter ab. Das bedeutet nicht, dass sie keinen Platz haben — aber der Einsatz sollte begründet sein, nicht reflexartig.
Das vollständige Notebook mit Code, Metriken und Visualisierungen ist hier einsehbar:
https://nbviewer.org/github/alexchilton/rag-comparison-framework/blob/master/rag_comparison.ipynb
Haben Sie konkrete Anforderungen an ein RAG-System — ob intern oder kundengerichtet? Wir helfen gerne bei der Auswahl der richtigen Strategie und der technischen Umsetzung.