RAG-Frameworks: LangChain vs. LangGraph vs. LlamaIndex

Wir haben fünf RAG-Frameworks – LangChain, LangGraph, LlamaIndex, Haystack und DSPy – anhand desselben agentenbasierten RAG-Workflows mit standardisierten Komponenten verglichen: identische Modelle (GPT-4.1-mini), Einbettungen (BGE-small), Retriever (Qdrant) und Tools (Tavily-Websuche). Dadurch lassen sich der tatsächliche Overhead und die Token-Effizienz jedes Frameworks isolieren.

RAG-Frameworks-Benchmark-Ergebnisse

Der Benchmark bestand aus 100 Abfragen, wobei jedes Framework den gesamten Satz 100 Mal ausführte, um stabile Durchschnittswerte zu erhalten.

• Durchschnittliche Tokenanzahl : Die Gesamtzahl der verbrauchten Token über alle LLM-Aufrufe (Router, Dokumentenbewertung, Antwortbewertung und Generator) hinweg, einschließlich Eingabeaufforderungen (mit abgerufenem Kontext) und Vervollständigungen. Niedrigere Werte bedeuten geringere API-Kosten.
• Framework-Overhead : Reine Orchestrierungszeit (ms), die interne Verarbeitung des Frameworks (Routing-Logik, Zustandsverwaltung usw.), ohne LLM-API- und Tool-Aufrufe. Niedrigerer Wert = schlankeres Framework.

Alle Implementierungen erreichten im Testdatensatz eine Genauigkeit von 100 %. Es wurden dieselben Modelle, Temperaturen, derselbe Abrufanbieter, dasselbe Websuchtool und eine gemeinsame Obergrenze für Kontext-Token verwendet.

Wichtigste Erkenntnisse

1. Wir konzentrieren uns auf die Kontrolle der kontrollierbaren Faktoren : Gleiche Modellfamilie und Temperaturen, gleiche maximale Tokenanzahl auf Knotenebene, gleicher Retriever (Qdrant + BGE-small, k=5, Normalisierung aktiviert), gleicher Web-Provider (nur Tavily), gleiche Router-Richtlinie (Heuristik + Modell), frühzeitige Rückgabe des Rechners, gemeinsame Token-Obergrenze für den Kontext, identisches Bewertungsraster, einheitliche Instrumentierung. Dadurch werden wesentliche Störfaktoren in unseren Messungen erheblich reduziert.
2. Der Framework-Overhead ist messbar, aber gering : Wir beobachteten etwa 3–14 ms pro Abfrage durch die Orchestrierungslogik. Diese Unterschiede sind real, aber nicht die Hauptursache für die Latenzlücken von über einer Sekunde; der größte Zeitaufwand entfällt auf die Ein-/Ausgabe mit externen Modellen/Tools.
3. Die Performance-Analyse der Token-Verbrauchsrate (unter diesen Einschränkungen) zeigt, dass DSPy den geringsten Framework-Overhead aufweist (~3,53 ms). Haystack (~5,9 ms) und LlamaIndex (~6 ms) folgen, während LangChain (~10 ms) und LangGraph (~14 ms) höhere Werte aufweisen. Der Token-Verbrauch ist bei Haystack am niedrigsten (~1,57k), gefolgt von LlamaIndex (~1,60k); DSPy und LangGraph liegen bei ~2,03k und LangChain bei ~2,40k.
4. Routing/Tool-Pfad ist wichtig : Geringfügige Änderungen im anfänglichen Routing (Retriever vs. Web vs. Calculator) und im Fallback-Verhalten wirken sich sowohl auf Token als auch auf Zeit aus, selbst wenn Eingabeaufforderungen und Budgets aufeinander abgestimmt sind.

Warum bleiben Unterschiede bestehen? Die „Rahmen-DNA“

Trotz Standardisierung bestehen weiterhin geringfügige Abweichungen bei Token-Anzahlen und Latenzzeiten. Diese sind auf die inhärenten, grundlegenden Verhaltensweisen der einzelnen Frameworks, ihre „DNA“, zurückzuführen.

• Eingabeaufforderung & Nachrichtenserialisierung: Jedes Framework verpackt den gleichen logischen Inhalt mit einer leicht unterschiedlichen Formatierung, bevor er an den LLM gesendet wird, wodurch kleine, aber konsistente Token-Deltas entstehen.
• Kontextzusammenstellung: Die genaue Reihenfolge und Einbeziehung von Metadaten innerhalb des verketteten Kontexts kann je nach Framework leicht variieren, was sich auf die endgültige Tokenanzahl auswirkt.
• Routing-Entscheidungspunkte: In Grenzfällen können subtile Unterschiede in der Art und Weise, wie ein Framework die JSON-Ausgabe des Routers analysiert, zu einer anderen anfänglichen Werkzeugwahl führen.

In dieser Konfiguration scheint der Token-Footprint der primäre Faktor zu sein, mehr noch als die Framework-Ausführungszeit.

Die gemeinsame agentenbasierte RAG-Architektur

Um einen fairen Vergleich zu ermöglichen, basierten alle fünf Implementierungen auf demselben Kontrollfluss:

• Router: Ein hybrider Modell- und Heuristikknoten, der Retriever, Websuche oder Rechner auswählt.
• Dokumente abrufen: Ruft die Top 5 Dokumente von Qdrant mithilfe normalisierter BGE-small-Einbettungen ab.
• Dokumentenbewertung: Ein LLM-Prüfer beurteilt die Relevanz der Dokumente. Sind diese irrelevant, wird eine Websuche als Alternative ausgelöst.
• Antwort generieren: Verwendet einen LLM mit temperature=0.0 und einer gemeinsamen Kontext-Token-Obergrenze, um einen Antwortentwurf zu generieren.
• Bewertungsantwort: Ein zweiter LLM-Prüfer beurteilt den Entwurf auf Fundiertheit, Widersprüche (Halluzinationen) und Vollständigkeit.
• Ausweichlösung & Vorzeitige Rückgabe: Bei unzureichender Antwortbewertung wird eine Websuche ausgelöst. Die Ergebnisse des Taschenrechners werden hingegen direkt zurückgegeben, wodurch die Generierungs- und Bewertungsschritte übersprungen werden.

Workflow-Beispiele

Szenario A – Direkter Treffer aus der Datenbank:

Szenario B – Ein kürzlich aufgetretenes Ereignis löst das Webtool aus:

Szenario C – Der Rechner liefert eine frühe Rendite:

Szenario D – Vektordatenbank unzureichend, Rückgriff auf Websuche:

RAG-Framework-Methodik

Alle fünf Implementierungen erreichten bei unserem Testdatensatz mit 100 Anfragen eine Genauigkeit von 100 % und stimmten mit den tatsächlichen Ergebnissen überein. Dies war die grundlegende Voraussetzung, um sicherzustellen, dass jedes Framework denselben agentenbasierten RAG-Workflow erfolgreich ausführen konnte, bevor Leistungsunterschiede gemessen wurden.

1. Kernkomponenten & Konfiguration

Die grundlegenden Werkzeuge wurden standardisiert, um Leistungsvariablen an der Quelle zu eliminieren.

• LLMs:
  • Modell: Alle Knoten (Router, Generator, Grader) verwendeten das openai/gpt-4.1-mini-Modell über die OpenRouter API.
  • Determinismus: Die Temperatur wurde für alle LLM-Anrufe auf 0,0 gesetzt, um eine maximale Konsistenz bei Routing, Generierung und Bewertung zu gewährleisten.
  • Token-Limits: Es wurden strenge Limits für max_tokens durchgesetzt: 256 für Router und Grader und 512 für den Generator. Dadurch werden Latenzunterschiede vermieden, die durch übermäßig lange Antworten eines Frameworks entstehen könnten.
• Einbettungsmodell & Abruf:
  • Modell: Alle Frameworks verwendeten BAAI/bge-small-en-v1.5 von HuggingFace.
  • Normalisierung: Ein entscheidender Schritt zur Leistungsoptimierung. Daher wurde normalize_embeddings in allen fünf Frameworks auf True gesetzt. (LangChain/LangGraph über encode_kwargs; LlamaIndex über normalize=True; Haystack über normalize_embeddings; DSPy-Retriever normalisiert.)
  • Abfrage: Der Qdrant-Vektorspeicher wurde in allen Implementierungen nach ak=5 (Top 5 Dokumente) durchsucht.
• Werkzeug:
  • Websuche: Der Benchmark wurde auf Tavily beschränkt (max_results=3).
  • Taschenrechner: Alle fünf Implementierungen nutzten die SymPy-Bibliothek zum Parsen und Auswerten mathematischer Ausdrücke, wodurch identische Fähigkeiten gewährleistet wurden.

2. Ampelsteuerung und -richtlinie

Der „Entscheidungsprozess“ des Agenten wurde durchweg explizit nachgebildet.

• Routing-Logik: In allen fünf Skripten wurde eine hybride Routing-Strategie implementiert, um die Modellintelligenz mit deterministischen Regeln in Einklang zu bringen:
  1. Eine auf regulären Ausdrücken basierende heuristische Route prüft zunächst auf offensichtliche Taschenrechner- oder Websuchmuster (z. B. mathematische Symbole, Jahreszahlen wie „2024“).
  2. Ein LLM-Router-Knoten trifft dann seine eigene Entscheidung.
  3. Bei der endgültigen Entscheidung wird der Heuristik für Taschenrechner der Vorrang eingeräumt, ansonsten wird die Wahl des LLM übernommen.
• Kontextbudgetierung: Dies ist eine der wichtigsten Standardisierungen. Bevor der Knoten `generate_answer` aufgerufen wird, werden alle abgerufenen Dokumentkontexte und Websuchergebnisse verkettet und anschließend mithilfe der gemeinsamen Funktion `truncate_to_token_budget` auf ein gemeinsames Limit von 2000 Token gekürzt . Dadurch wird sichergestellt, dass der Generator-LLM in jedem Framework eine Eingabe von exakt derselben Größe erhält und kein Framework durch die Ausführlichkeit des abgerufenen Kontexts benachteiligt oder bevorzugt wird.
• Richtlinien zur Bewertung der Antworten:
  • Nachsichtige Bewertungskriterien: Der Knoten grade_answer verwendet in allen Frameworks eine identische, nachsichtige Aufforderung, die den LLM-Richter anweist, semantisch ähnliche und hinreichend vollständige Antworten zu akzeptieren.
  • Fehlerbehandlung: Die Logik für den Umgang mit einem fehlgeschlagenen JSON-Parsing durch den Grader wurde standardisiert. Wenn die Ausgabe des Graders kein gültiges JSON ist, vergibt das System standardmäßig eine positive Bewertung (grounded=True, complete=True). Dies entspricht einem realen Szenario, in dem ein fehleranfälliger Parser eine ansonsten korrekte Antwort nicht fälschlicherweise als falsch bewerten würde. Bei DSPy-Rückgaben strukturierter Felder (kein JSON-Parsing) wird dies als Unterschied in der Robustheit und nicht als Leistungsvorteil protokolliert.
• Vorzeitige Rückgabe des Taschenrechners: Wie im Code ersichtlich, setzt ein erfolgreicher Aufruf des `calculator_node` direkt das Ergebnis (`final_answer`) und beendet den Workflow vorzeitig. Dies ist eine wichtige Optimierung, die konsequent angewendet wird und verhindert, dass der Taschenrechnerpfad die LLMs `generate` und `grade_answer` unnötigerweise aufruft.
• DSPy-Ausrichtung. Um Fairness gegenüber Nicht-CoT-Baselines zu gewährleisten, verwendet DSPy dspy.Predict (ohne CoT) für Router und AnswerGenerator. Signaturen spiegeln die Node-Verträge anderer Frameworks wider; Token-Zählungen basieren, sofern verfügbar, auf der modellbasierten Nutzung, andernfalls auf dem TikToken-Fallback.

3. Instrumentierung und Messtechnik

Der Messprozess war identisch und basierte auf denselben Messinstrumenten und -prinzipien.

• Latenz: Für alle Zeitmessungen wurde die hochpräzise Methode `time.perf_counter()` verwendet. Der Framework-Overhead wird einheitlich als Gesamtlatenz abzüglich der Latenz externer Aufrufe berechnet.
• Tokenisierung: Alle Token-Zählungen für Eingabeaufforderungen und Vervollständigungen wurden mithilfe von tiktoken und der cl100k_base-Kodierung berechnet, um eine einheitliche Datenbasis für die Token-Metriken zu gewährleisten. Die in den Ergebnissen angegebene Metrik „Durchschnittliche Token“ stellt die kumulative Summe aller Eingabe- (Eingabeaufforderung) und Ausgabetoken (Vervollständigung) für jeden LLM-Aufruf (z. B. Router, Grader, Generator) innerhalb eines einzelnen Abfrage-Workflows dar.
• Zustandsverwaltung: Obwohl sich die Implementierungssyntax unterscheidet (LangGraphs TypedDict, LlamaIndex' Klasse, LangChain's Wörterbuch), ist die Zustandsstruktur funktional identisch. Jedes Framework übergibt denselben Satz von Schlüsseln (Frage, Dokumente, Webergebnisse usw.) zwischen den Knoten, wodurch sichergestellt wird, dass die Kontrollflusslogik mit denselben Informationen arbeitet.

Durch die Durchsetzung dieser strengen Standardisierungen auf Codeebene zielt dieser Benchmark darauf ab, über oberflächliche Vergleiche hinauszugehen und eine reproduzierbare Analyse der Framework-Performance unter einer festen RAG-Richtlinie zu bieten.

Interpretation der Ergebnisse:

• Daraus lässt sich schließen: In dieser spezifischen, streng kontrollierten Umgebung ist der Orchestrierungsaufwand tendenziell gering; Unterschiede werden hauptsächlich durch die Anzahl der Token und die Pfade der Werkzeuge verursacht.
  • In dieser spezifischen, streng kontrollierten Konfiguration ist der Framework-Overhead vernachlässigbar.
  • Die Leistungsunterschiede waren auf Variationen der Tokenanzahl und der Werkzeugwege zurückzuführen.
• Verallgemeinerungen sind nicht möglich: Die Ergebnisse sind spezifisch für diese Architektur, Modelle, Eingabeaufforderungen, Abrufer und Webanbieter; Änderungen daran können die Rangfolge verändern.

Entwicklererfahrung: Ein qualitativer Vergleich

Die Leistungsfähigkeit ist nicht der einzige Faktor; ebenso wichtig ist, wie sich die Arbeit mit einem Framework anfühlt.

• LangGraph: Der deklarative Graph
  Verwendet ein Graph-First-Paradigma. Sie definieren Knoten und verbinden diese mit Kanten (einschließlich add_conditional_edges), sodass der Kontrollfluss Teil der Architektur ist. Der Zustand wird über ein TypedDict mit Reducer-ähnlichen Aktualisierungen (Annotated[…, add]) typisiert.
  • Wählen Sie LangGraph für: komplexe Arbeitsabläufe mit mehreren Verzweigungen, Wiederholungsversuchen und Zyklen; seine Struktur skaliert hinsichtlich Robustheit und Wartbarkeit mit der Anzahl der Agenten.
• LlamaIndex: Imperative Orchestrierung
  Ein prozedurales Skript, dessen Kontrollfluss dem Standard-Python-if/else-Code entspricht; der „Graph“ befindet sich in Ihrem Code. Der Zustand ist eine dedizierte PipelineState-Klasse, und das Framework bietet übersichtliche Abrufprimitive (VectorStoreIndex → .as_retriever(k=5)).
  • Wählen Sie LlamaIndex für: übersichtliche Workflows mit nur einer Datei, bei denen Sie Wert auf klare Verfahrenslogik und einfaches Debugging legen.
• LangChain: Imperativ mit deklarativen Komponenten
  Die Orchestrierung bleibt ein Python-Skript, aber die einzelnen Aufgaben sind kleine, miteinander verknüpfbare Ketten, die mit dem Operator | verknüpft werden (z. B. prompt | llm | parser). Der Zustand ist ein flexibles, untypisiertes Python-Dictionary.
  • Wählen Sie LangChain für: Schnelles Prototyping oder Teams, die bereits im LangChain-Ökosystem sind und es vorziehen, kleine deklarative Einheiten innerhalb eines größeren imperativen Treibers zu komponieren.
• Haystack: Komponentenbasierte, manuelle Orchestrierung. Typisierte, wiederverwendbare Komponenten (@component) mit expliziter Ein-/Ausgabe, während der Kontrollfluss in reinem Python (if/else) erfolgt. Einfacher Austausch von LLM-/Retriever-/Web-Backends sowie erstklassige Instrumentierung pro Schritt (extern vs. Framework-Zeit).
  • Entscheiden Sie sich für Haystack, wenn Sie produktionsreife, testbare Pipelines mit klaren Verträgen und feingranularer Kontrolle benötigen.
• DSPy: Signaturbasierte Programme (weniger Codezeilen)
  Eine Aufgabe wird über eine Signatur (Ein-/Ausgaben + Absicht) definiert und anschließend mit Modulen implementiert, die Eingabeaufforderungen und LLM-Aufrufe kapseln. Dadurch wird die Eingabeaufforderungs-/Nutzungsbehandlung zentralisiert und zusätzlicher Code entfernt; der Austausch interner Komponenten (z. B. Predict ↔ CoT ) ändert den Vertrag nicht.
  • Wählen Sie DSPy für: minimalen Boilerplate-Code, lesbare Single-File-Flows, vertragsgetriebene Entwicklung (mit optionalen Optimierern).

Optimale Performance gegen Vergleichbarkeit abwägen

• LangGraph könnte seine Stärken bei der Nutzung seiner nativen Graphoptimierungen ausspielen, wenn ihm die parallele Ausführung, das Zustands-Caching und sein bedingtes Kantensystem für komplexe Verzweigungslogik zur Verfügung stehen.
• DSPy könnte dramatisch andere Ergebnisse liefern, wenn seine Signaturoptimierer (wie MIPROv2) und Chain-of-Thought-Prompts verwendet werden, was die Antwortqualität deutlich verbessern kann.
• Haystack könnte seine produktionsreifen Caching- und Batching-Funktionen sowie die von uns aus Gründen der Fairness deaktivierten Optimierungen auf Komponentenebene nutzen.
• LlamaIndex könnte von seinen fortschrittlichen Indexierungsstrategien, Abfrage-Engines und multimodalen Fähigkeiten profitieren, die in diesem Benchmark nicht zum Einsatz kamen.
• LangChain könnte mit seinem umfangreichen Werkzeugökosystem und den LCEL-Optimierungen (LangChain Expression Language) glänzen, wenn es nicht auf unseren standardisierten Werkzeugsatz beschränkt ist.

Das „beste“ Framework hängt davon ab, ob Sie auf Folgendes optimieren: Entwicklungsgeschwindigkeit, Wartbarkeit, Leistung oder bestimmte Architekturmuster.

Weiterführende Literatur

Erkunden Sie weitere RAG-Benchmarks, wie zum Beispiel:

• Einbettungsmodelle: OpenAI vs Gemini vs Cohere
• Top-Vektordatenbank für RAG: Qdrant vs Weaviate vs Pinecone
• Agentic RAG Benchmark: Multi-Datenbank-Routing und Abfragegenerierung
• Hybrid RAG: Steigerung der RAG-Genauigkeit

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 55 % der Fortune 500. Cems Arbeit wurde von führenden globalen Publikationen wie Business Insider, Forbes und der Washington Post, von globalen Unternehmen wie Deloitte und HPE sowie von NGOs wie dem Weltwirtschaftsforum und supranationalen Organisationen wie der Europäischen Kommission zitiert. Weitere namhafte Unternehmen und Ressourcen, die AIMultiple referenziert haben, finden Sie hier. Im Laufe seiner Karriere war Cem als Technologieberater, Technologieeinkäufer und Technologieunternehmer tätig. Über ein Jahrzehnt lang beriet er Unternehmen bei McKinsey & Company und Altman Solon in ihren Technologieentscheidungen. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung. Bei einem Telekommunikationsunternehmen leitete er die Technologiestrategie und -beschaffung und berichtete direkt an den CEO. Darüber hinaus verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von null auf einen siebenstelligen jährlichen wiederkehrenden Umsatz und eine neunstellige Unternehmensbewertung kam. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider gewürdigt. Er ist ein gefragter Redner auf internationalen Technologiekonferenzen. Cem absolvierte sein Studium der Informatik an der Bogazici-Universität und besitzt einen MBA der Columbia Business School.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten