RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

Wir haben 5 RAG-Frameworks einem Benchmark-Test unterzogen: LangChain, LangGraph, LlamaIndex, Haystack und DSPy, indem wir denselben agentischen RAG-Workflow mit standardisierten Komponenten aufbauten: identische Modelle (GPT-4.1-mini), Embeddings (BGE-small), Retriever (Qdrant) und Tools (Tavily-Websuche). Dies isoliert den tatsächlichen Overhead und die Token-Effizienz jedes Frameworks.

Benchmark-Ergebnisse der RAG-Frameworks

Der Benchmark bestand aus 100 Abfragen, wobei jedes Framework den gesamten Satz 100 Mal durchlief, um stabile Durchschnittswerte zu liefern.

• Durchschn. Tokens: Gesamtzahl der über alle LLM-Aufrufe verbrauchten Tokens (Router, Document Grader, Answer Grader und Generator), umfasst sowohl Prompts (mit abgerufenem Kontext) als auch Completions. Niedriger = geringere API-Kosten.
• Framework-Overhead: Reine Orchestrierungszeit (ms), die interne Verarbeitung des Frameworks (Routing-Logik, State-Management usw.), ohne LLM-API- und Tool-Aufrufe. Niedriger = schlankeres Framework.

Alle Implementierungen erreichten eine Genauigkeit von 100 % im Testset. Verwendet wurden dieselben Modelle, Temperaturen, Retrieval-Provider, Websuch-Tool und eine gemeinsame Kontext-Token-Obergrenze.

Wichtigste Erkenntnisse

1. Wir konzentrieren uns darauf, zu kontrollieren, was kontrollierbar ist: Gleiche Modellfamilie und Temperaturen, max_tokens auf Knotenebene, Retriever (Qdrant + BGE-small, k=5, Normalisierung aktiviert), Web-Provider (nur Tavily), Router-Richtlinie (Heuristik + Modell), frühzeitige Rückgabe des Rechners, gemeinsame Kontext-Token-Obergrenze, identische Bewertungsrubrik, einheitliche Instrumentierung. Dies reduziert wesentliche Störfaktoren in unseren Messungen erheblich.
2. Framework-Overhead ist messbar, aber gering: Wir beobachteten ~3–14 ms pro Abfrage durch Orchestrierungslogik. Diese Unterschiede sind real, aber nicht die Hauptursache für die >1 s Latenzunterschiede; die meiste Zeit wird für I/O mit externen Modellen/Tools aufgewendet.
3. Die Leistung folgt den Tokens (unter diesen Einschränkungen): DSPy zeigt den niedrigsten Framework-Overhead (~3,53 ms). Haystack (~5,9 ms) und LlamaIndex (~6 ms) folgen, während LangChain (~10 ms) und LangGraph (~14 ms) höher liegen. Die Token-Nutzung ist am niedrigsten bei Haystack (~1,57k), dann LlamaIndex (~1,60k); DSPy und LangGraph liegen bei ~2,03k und LangChain bei ~2,40k.
4. Routing/Tool-Pfad ist entscheidend: Geringfügige Verschiebungen im anfänglichen Routing (Retriever vs. Web vs. Rechner) und im Fallback-Verhalten wirken sich sowohl auf Tokens als auch auf die Zeit aus, selbst wenn Prompts und Budgets aufeinander abgestimmt sind.

Warum bleiben Unterschiede bestehen? Die „Framework-DNA“

Trotz Standardisierung bleiben kleine Abweichungen bei Token-Anzahl und Latenz bestehen. Diese sind auf die inhärenten Low-Level-Verhaltensweisen jedes Frameworks zurückzuführen, ihre „DNA“.

• Prompt- und Nachrichten-Serialisierung: Jedes Framework verpackt denselben logischen Inhalt mit leicht unterschiedlicher Formatierung, bevor es ihn an das LLM sendet, was kleine, aber konsistente Token-Deltas erzeugt.
• Kontext-Zusammenstellung: Die genaue Anordnung und Einbeziehung von Metadaten innerhalb des verketteten Kontexts kann je nach Framework geringfügig abweichen, was sich auf die endgültige Token-Anzahl auswirkt.
• Routing-Entscheidungen bei Gleichstand: In Grenzfällen können subtile Unterschiede darin, wie ein Framework die JSON-Ausgabe des Routers parst, zu einer anderen anfänglichen Tool-Wahl führen.

In diesem Setup scheint der Token-Fußabdruck der primäre Treiber zu sein, mehr als die Framework-Ausführungszeit.

Die gemeinsame agentische RAG-Architektur

Um einen fairen Vergleich zu erreichen, wurden alle fünf Implementierungen auf demselben Kontrollfluss aufgebaut:

• Router: Ein hybrider Modell-und-Heuristik-Knoten, der retriever, web_search oder calculator wählt.
• Retrieve Documents: Ruft die Top-5-Dokumente von Qdrant unter Verwendung normalisierter BGE-small-Embeddings ab.
• Grade Documents: Ein LLM-Richter bewertet die Dokumentenrelevanz. Bei Irrelevanz wird ein Web-Suche-Fallback ausgelöst.
• Generate Answer: Verwendet ein LLM mit temperature=0,0 und einer gemeinsamen Kontext-Token-Obergrenze, um einen Antwortentwurf zu generieren.
• Grade Answer: Ein zweiter LLM-Richter bewertet den Entwurf auf Fundiertheit, Widersprüche (Halluzinationen) und Vollständigkeit.
• Fallback & Early Return: Eine Websuche wird ausgelöst, wenn die Antwortbewertung unzureichend ist. Rechnerergebnisse werden jedoch direkt zurückgegeben, wobei die Generierungs- und Bewertungsschritte übersprungen werden.

Workflow-Beispiele

Szenario A — Direkter Treffer aus der Datenbank:

Szenario B — Aktuelles Ereignis löst Web-Tool aus:

Szenario C — Rechner liefert eine frühzeitige Rückgabe:

Szenario D — Vektor-DB unzureichend, Fallback zur Websuche:

Methodik der RAG-Frameworks

Alle fünf Implementierungen erreichten eine Genauigkeit von 100 % in unserem 100-Abfragen-Testset und stimmten mit den Ground-Truth-Antworten überein. Dies war die grundlegende Anforderung, um sicherzustellen, dass jedes Framework denselben agentischen RAG-Workflow erfolgreich ausführen konnte, bevor Leistungsunterschiede gemessen wurden.

1. Kernkomponenten & Konfiguration

Die grundlegenden Tools 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-Aufrufe auf 0,0 gesetzt, um maximale Konsistenz bei Routing, Generierung und Bewertung zu gewährleisten.
  • Token-Limits: Strenge max_tokens-Limits wurden durchgesetzt: 256 für Router und Grader und 512 für den Generator. Dies verhindert Latenzunterschiede, die durch übermäßig lange Antworten eines Frameworks verursacht werden.
• Embedding-Modell & Retrieval:
  • Modell: Alle Frameworks verwendeten BAAI/bge-small-en-v1.5 von HuggingFace.
  • Normalisierung: Ein kritischer Schritt für die Leistung – normalize_embeddings wurde in allen fünf Frameworks auf True gesetzt. (LangChain/LangGraph über encode_kwargs; LlamaIndex über normalize=True; Haystack über normalize_embeddings; DSPy Retriever normalisiert.)
  • Retrieval: Der Qdrant-Vektorspeicher wurde in allen Implementierungen mit k=5 (Top-5-Dokumente) abgefragt.
• Tooling:
  • Websuche: Der Benchmark wurde auf nur Tavily beschränkt (max_results=3).
  • Rechner: Alle fünf Implementierungen verwendeten die sympy-Bibliothek für das Parsen und Auswerten mathematischer Ausdrücke, um identische Fähigkeiten zu gewährleisten.

2. RAG-Kontrollfluss & -Richtlinie

Der „Entscheidungsfindungs“-Prozess des Agenten wurde explizit in allen Bereichen gespiegelt.

• Routing-Logik: Eine hybride Routing-Strategie wurde in allen fünf Skripten implementiert, um Modellintelligenz mit deterministischen Regeln auszubalancieren:
  1. Eine regex-basierte heuristic_route prüft zunächst auf offensichtliche Rechner- oder Websuchmuster (z. B. mathematische Symbole, Jahreszahlen wie „2024“).
  2. Ein LLM-router_node trifft dann seine eigene Entscheidung.
  3. Die endgültige Entscheidung priorisiert die Heuristik für Rechner, ansonsten wird der Wahl des LLM gefolgt.
• Kontext-Budgetierung: Dies ist eine der wichtigsten Standardisierungen. Bevor der generate_answer-Knoten aufgerufen wird, werden alle abgerufenen Dokumentkontexte und Websuchergebnisse verkettet und dann mit einem gemeinsamen truncate_to_token_budget-Dienstprogramm auf eine gemeinsame Obergrenze von 2000 Tokens gekürzt. Dies stellt sicher, dass das Generator-LLM in jedem Framework eine Eingabe von genau derselben Größe erhält, wodurch verhindert wird, dass ein einzelnes Framework durch die Ausführlichkeit seines abgerufenen Kontexts bevor- oder benachteiligt wird.
• Antwortbewertungsrichtlinie:
  • Nachsichtige Rubrik: Der grade_answer-Knoten verwendet einen identischen, nachsichtigen Prompt in allen Frameworks und weist den LLM-Richter an, semantisch ähnliche und hinreichend vollständige Antworten zu akzeptieren.
  • Fehlerbehandlung: Die Logik für den Umgang mit einem fehlgeschlagenen JSON-Parse des Graders wurde standardisiert. Wenn die Ausgabe des Graders kein gültiges JSON ist, verwendet das System standardmäßig eine permissive Bewertung (grounded=True, complete=True), was einem realen Szenario entspricht, in dem ein spröder Parser eine ansonsten gute Antwort nicht scheitern lassen sollte. DSPy gibt strukturierte Felder zurück (kein JSON-Parse), dies wird als Robustheitsunterschied protokolliert, nicht als Leistungsvorteil.
• Frühzeitige Rückgabe des Rechners: Wie im Code zu sehen, setzt ein erfolgreicher Aufruf des calculator_node direkt die final_answer und beendet den Workflow vorzeitig. Dies ist eine bedeutende Optimierung, die konsequent angewendet wird und verhindert, dass der Rechner-Pfad unnötig die generate- und grade_answer-LLMs aufruft.
• DSPy-Ausrichtung. Um Fairness mit Nicht-CoT-Baselines zu wahren, verwendet DSPy.Predict (kein CoT) für Router und AnswerGenerator. Signaturen spiegeln die Knotenverträge anderer Frameworks wider; wo verfügbar, verwenden Token-Zählungen die vom Modell gemeldete Nutzung, ansonsten tiktoken-Fallback.

3. Instrumentierung und Metriken

Der Messprozess war identisch und verwendete gemeinsame Dienstprogramme und Prinzipien.

• Latenz: Hochpräzises time.perf_counter() wurde für alle Zeitmessungen verwendet. Der Framework-Overhead wird konsistent als Gesamtlatenz – Latenz externer Aufrufe berechnet.
• Tokenisierung: Alle Token-Zählungen für Prompts und Completions wurden mit tiktoken, der cl100k_base-Kodierung, berechnet, um eine einzige Quelle der Wahrheit für Token-Metriken zu gewährleisten. Die in den Ergebnissen angegebene Metrik „Durchschn. Tokens“ stellt die kumulative Summe aller Eingabe- (Prompt) und Ausgabe-Tokens (Completion) für jeden LLM-Aufruf (z. B. Router, Grader, Generator) innerhalb eines einzelnen Abfrage-Workflows dar.
• State-Management: Während die Implementierungssyntax variiert (LangGraphs TypedDict, LlamaIndexs Klasse, LangChains Dictionary), ist die State-Struktur funktional identisch. Jedes Framework übergibt denselben Satz von Schlüsseln (question, documents, web_results usw.) zwischen Knoten, sodass die Kontrollflusslogik mit denselben Informationen arbeitet.

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

Interpretation der Ergebnisse:

• Sie können schlussfolgern: In diesem spezifischen, stark kontrollierten Setup ist der Orchestrierungs-Overhead tendenziell gering; Unterschiede werden hauptsächlich durch Token-Anzahl und Tool-Pfade verursacht.
  • In diesem spezifischen, stark kontrollierten Setup ist der Framework-Overhead vernachlässigbar.
  • Leistungsunterschiede wurden durch Token-Anzahl und Tool-Pfad-Variationen verursacht.
• Sie können nicht verallgemeinern: Die Ergebnisse sind spezifisch für diese Architektur, Modelle, Prompts, Retriever und Web-Provider; deren Änderung kann die Rangfolge verändern.

Entwicklererfahrung: Ein qualitativer Vergleich

Leistung ist nicht der einzige Faktor; wie sich ein Framework beim Entwickeln anfühlt, ist ebenso wichtig.

• LangGraph: Der deklarative Graph
  Verwendet ein Graph-First-Paradigma. Sie definieren Knoten und verdrahten sie mit Kanten (einschließlich add_conditional_edges), sodass der Kontrollfluss Teil der Architektur ist. Der State wird über ein TypedDict mit Reducer-artigen Aktualisierungen typisiert (Annotated[…, add]).
  • Wählen Sie LangGraph für: komplexe Workflows mit mehreren Verzweigungen, Wiederholungen und Zyklen; seine Struktur skaliert in Robustheit und Wartbarkeit, wenn Agenten wachsen.
• LlamaIndex: Imperative Orchestrierung
  Ein prozedurales Skript, bei dem der Kontrollfluss standardmäßiges Python if/else ist; der „Graph“ lebt in Ihrem Code. Der State ist eine dedizierte PipelineState-Klasse, und das Framework bietet saubere Retrieval-Primitive (VectorStoreIndex → .as_retriever(k=5)).
  • Wählen Sie LlamaIndex für: lesbare Single-File-Workflows, bei denen Sie klare prozedurale Logik und einfaches Debugging schätzen.
• LangChain: Imperativ mit deklarativen Komponenten
  Die Orchestrierung bleibt ein Python-Skript, aber einzelne Aufgaben sind kleine, zusammensetzbare Chains mit dem |-Operator (z. B. prompt | llm | parser). Der State ist ein flexibles, untypisiertes Python-dict.
  • Wählen Sie LangChain für: Rapid Prototyping oder Teams, die bereits im LangChain-Ökosystem sind und es bevorzugen, kleine deklarative Einheiten innerhalb eines größeren imperativen Treibers zusammenzustellen.
• Haystack: Komponentenbasiert, manuelle Orchestrierung Typisierte, wiederverwendbare Komponenten (@component) mit expliziten I/O, während der Kontrollfluss einfaches Python (if/else) bleibt. Einfacher Austausch von LLM-/Retriever-/Web-Backends, plus erstklassige schrittweise Instrumentierung (externe vs. Framework-Zeit).
  • Wählen Sie Haystack für: produktionsreife, testbare Pipelines mit klaren Verträgen und feingranularer Kontrolle.
• DSPy: Signature-First-Programme (weniger Codezeilen)
  Definieren Sie eine Aufgabe über eine Signatur (Eingaben/Ausgaben + Absicht) und implementieren Sie dann mit Modulen, die Prompting und LLM-Aufrufe kapseln. Zentralisiert die Prompt-/Nutzungsverwaltung und entfernt Glue-Code; das Austauschen interner Komponenten (z. B. Predict ↔ CoT) ändert den Vertrag nicht.
  • Wählen Sie DSPy für: minimalen Boilerplate, lesbare Single-File-Abläufe, vertragsgesteuerte Entwicklung (mit optionalen Optimierern).

Optimale Leistung gegen Vergleichbarkeit eintauschen

• LangGraph könnte mit seinen nativen Graph-Optimierungen hervorragend abschneiden, wenn parallele Ausführung, State-Caching und sein bedingtes Kantensystem für komplexe Verzweigungslogik erlaubt sind.
• DSPy könnte dramatisch andere Ergebnisse zeigen, wenn seine Signatur-Optimierer (wie MIPROv2) und Chain-of-Thought-Prompting verwendet werden, die Antwortqualität erheblich verbessern können.
• Haystack könnte seine produktionsreifen Caching-, Batching-Funktionen und Optimierungen auf Komponentenebene nutzen, die wir aus Fairnessgründen deaktiviert haben.
• LlamaIndex könnte von seinen fortschrittlichen Indizierungsstrategien, Query-Engines und multimodalen Fähigkeiten profitieren, die in diesem Benchmark nicht genutzt wurden.
• LangChain könnte mit seinem umfangreichen Tool-Ökosystem und LCEL (LangChain Expression Language)-Optimierungen glänzen, wenn es nicht auf unser standardisiertes Toolset beschränkt ist.

Das „beste“ Framework hängt davon ab, ob Sie für Entwicklungsgeschwindigkeit, Wartbarkeit, Leistung oder spezifische Architekturmuster optimieren.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Weiterführende Literatur

Entdecken Sie andere RAG-Benchmarks, wie zum Beispiel:

• Embedding-Modelle: OpenAI vs Gemini vs Cohere
• Top-Vektordatenbank für RAG: Qdrant vs Weaviate vs Pinecone
• Agentischer RAG-Benchmark: Multi-Datenbank-Routing und Abfragegenerierung
• Hybrides RAG: Steigerung der RAG-Genauigkeit

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{RAG Frameworks: LangChain vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Abgerufen am 4. August 2026}
}

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 60% der Fortune 500.

Cems Arbeit wurde von führenden globalen Publikationen zitiert, darunter Business Insider, Forbes, Washington Post, globalen Unternehmen wie Deloitte, HPE und NGOs wie dem World Economic Forum sowie supranationalen Organisationen wie der European Commission.

Während seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen über ein Jahrzehnt lang bei McKinsey & Company und Altman Solon in Technologieentscheidungen. Er veröffentlichte auch einen McKinsey-Bericht zur Digitalisierung.

Er leitete die Technologiestrategie und Beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Zudem führte er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos an, das innerhalb von 2 Jahren von null auf einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung anwuchs. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.

Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er schloss sein Studium an der Bogazici University als Computer-Ingenieur ab und hat einen MBA von der Columbia Business School.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenanalyst bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten