RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

Wir haben 5 RAG-Frameworks getestet: LangChain, LangGraph, LlamaIndex, Haystack und DSPy, indem wir denselben agentic RAG-Workflow mit standardisierten Komponenten erstellt haben: 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.

RAG-Framework-Benchmark-Ergebnisse

Der Benchmark bestand aus 100 Abfragen, wobei jedes Framework den gesamten Satz 100-mal ausführte, um stabile Durchschnitte zu liefern.

• Durchschn. Tokens: Gesamtzahl der verbrauchten Tokens über alle LLM-Aufrufe hinweg (Router, Dokumenten-Grader, Antwort-Grader und Generator), einschließlich 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.), ausgeschlossen LLM-API- und Tool-Aufrufe. Niedriger = schlankeres Framework.

Alle Implementierungen erreichten 100 % Genauigkeit im Testset. Es wurden dieselben Modelle, Temperaturen, Retrieval-Anbieter, Websuche-Tools und ein gemeinsamer Kontext-Token-Cap verwendet.

Wichtige Erkenntnisse

1. Wir konzentrieren uns auf die Kontrolle dessen, was kontrollierbar ist: Dieselbe Modellfamilie und Temperaturen, Node-Level-max_tokens, Retriever (Qdrant + BGE-small, k=5, Normalisierung aktiv), Web-Anbieter (nur Tavily), Router-Richtlinie (heuristisch + Modell), Calculator-Frührückgabe, gemeinsamer Kontext-Token-Cap, identische Bewertungsrichtlinie, vereinheitlichte Instrumentierung. Dies reduziert erheblich große Störfaktoren in unseren Messungen.
2. Framework-Overhead ist messbar, aber gering: Wir beobachteten ~3–14 ms pro Abfrage durch Orchestrierungslogik. Diese Unterschiede sind real, aber nicht die Hauptquelle der >1 s-Latenzlücken; 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 geringsten 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 geringsten für 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: Geringe Verschiebungen im initialen Routing (Retriever vs. Web vs. Calculator) und das Fallback-Verhalten beeinflussen sowohl Tokens als auch Zeit, selbst wenn Prompts und Budgets abgestimmt sind.

Warum bestehen Unterschiede weiter? Die „Framework-DNA"

Trotz Standardisierung bleiben kleine Abweichungen in den Token-Zahlen und der Latenz bestehen. Diese sind auf das inhärente, niedrigstufige Verhalten jedes Frameworks, ihre „DNA", zurückzuführen.

• Prompt- & Nachrichten-Serialisierung: Jedes Framework umhüllt denselben logischen Inhalt mit leicht unterschiedlicher Formatierung, bevor es an den LLM gesendet wird, was kleine, aber konsistente Token-Deltas erzeugt.
• Kontext-Zusammenstellung: Die genaue Reihenfolge und Einbeziehung von Metadaten innerhalb des verketteten Kontexts kann je nach Framework leicht variieren, was die endgültige Token-Zahl beeinflusst.
• Routing-Tie-Breaks: In Grenzfällen können subtile Unterschiede in der Art und Weise, wie ein Framework die JSON-Ausgabe des Routers analysiert, zu einer anderen initialen Tool-Wahl führen.

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

Die gemeinsame agentic RAG-Architektur

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

• Router: Ein hybrider Modell- und Heuristik-Node, der Retriever, web_search oder Calculator auswählt.
• Dokumente abrufen: Ruft die Top-5-Dokumente aus Qdrant unter Verwendung normalisierter BGE-small-Embeddings ab.
• Dokumente bewerten: Ein LLM-Richter bewertet die Relevanz der Dokumente. Wenn sie irrelevant sind, wird ein Web-Suche-Fallback ausgelöst.
• Antwort generieren: Verwendet einen temperature=0,0 LLM mit einem gemeinsamen Kontext-Token-Cap, um eine Entwurfsantwort zu generieren.
• Antwort bewerten: Ein zweiter LLM-Richter bewertet den Entwurf auf Fundiertheit, Widersprüche (Halluzinationen) und Vollständigkeit.
• Fallback & Frührückgabe: Eine Websuche wird ausgelöst, wenn die Antwortbewertung unzureichend ist. Calculator-Ergebnisse werden jedoch direkt zurückgegeben, wobei die Generierungs- und Bewertungs-Schritte übersprungen werden.

Workflow-Beispiele

Szenario A — Direkter Treffer aus der Datenbank:

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

Szenario C — Calculator liefert eine Frührückgabe:

Szenario D — Vector DB unzureichend, Fallback auf Websuche:

RAG-Framework-Methodik

Alle fünf Implementierungen erreichten 100 % Genauigkeit auf unserem 100-Abfragen-Testset und stimmten mit den Ground-Truth-Antworten überein. Dies war die grundlegende Anforderung, um sicherzustellen, dass jedes Framework denselben agentic 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 Nodes (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 beim Routing, der Generierung und der Bewertung sicherzustellen.
  • Token-Limits: Strenge max_tokens-Limits wurden durchgesetzt: 256 für den Router und die Grader, und 512 für den Generator. Dies verhindert Latenzunterschiede, die durch eine übermäßig lange Antwort 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 via encode_kwargs; LlamaIndex via normalize=True; Haystack via normalize_embeddings; DSPy-Retriever normalisiert.)
  • Retrieval: Der Qdrant-Vektorspeicher wurde in allen Implementierungen für k=5 (Top-5-Dokumente) abgefragt.
• Tooling:
  • Websuche: Der Benchmark war auf nur Tavily beschränkt (max_results=3).
  • Calculator: Alle fünf Implementierungen verwendeten die sympy-Bibliothek zum Parsen und Auswerten mathematischer Ausdrücke, um identische Fähigkeiten sicherzustellen.

2. RAG-Kontrollfluss & Richtlinie

Der „Entscheidungsfindungs"-Prozess des Agents wurde durchgängig explizit gespiegelt.

• Routing-Logik: Eine hybride Routing-Strategie wurde in allen fünf Skripten implementiert, um Modellintelligenz mit deterministischen Regeln auszugleichen:
  1. Ein regex-basierter heuristic_route prüft zunächst auf offensichtliche Calculator- oder Websuchmuster (z. B. mathematische Symbole, Jahre wie „2024").
  2. Ein LLM-router_node trifft dann seine eigene Entscheidung.
  3. Die endgültige Entscheidung priorisiert den Heuristik für Calculator, andernfalls wird auf die Wahl des LLM verwiesen.
• Kontext-Budgetierung: Dies ist eine der wichtigsten Standardisierungen. Bevor der generate_answer-Node aufgerufen wird, werden alle abgerufenen Dokumentenkontexte und Websuchergebnisse verkettet und dann auf ein gemeinsames 2000-Token-Limit gekürzt, unter Verwendung eines gemeinsamen truncate_to_token_budget-Utility. Dies stellt sicher, dass der Generator-LLM in jedem Framework eine Eingabe exakt derselben Größe erhält, wodurch verhindert wird, dass ein einzelnes Framework durch die Ausführlichkeit seines abgerufenen Kontexts begünstigt oder benachteiligt wird.
• Antwort-Bewertungsrichtlinie:
  • Leniente Richtlinie: Der grade_answer-Node verwendet in allen Frameworks einen identischen, lenienten Prompt, der den LLM-Richter anweist, semantisch ähnliche und angemessen vollständige Antworten zu akzeptieren.
  • Fehlerbehandlung: Die Logik zur Behandlung eines fehlgeschlagenen JSON-Parsings vom Grader wurde standardisiert. Wenn die Ausgabe des Graders kein gültiges JSON ist, geht das System standardmäßig auf eine permissive Bewertung über (grounded=True, complete=True), was ein reales Szenario nachahmt, in dem man nicht möchte, dass ein spröder Parser eine ansonsten gute Antwort scheitern lässt. DSPy strukturierte Felder geben zurück (kein JSON-Parsing), dies wird als Robustheitsunterschied protokolliert, nicht als Leistungsvorteil.
• Calculator-Frührückgabe: Wie im Code zu sehen, setzt ein erfolgreicher Aufruf des calculator_node direkt die final_answer und beendet den Workflow frühzeitig. Dies ist eine signifikante Optimierung, die konsistent angewendet wird und verhindert, dass der Calculator-Pfad unnötig die generate- und grade_answer-LLMs aufruft.
• DSPy-Ausrichtung. Um Fairness mit Nicht-CoT-Baselines zu gewährleisten, verwendet DSPy dspy.Predict (kein CoT) für Router und AnswerGenerator. Signaturen spiegeln die Node-Verträge anderer Frameworks wider; wo verfügbar, verwenden Token-Zahlen die vom Modell gemeldete Nutzung, andernfalls tiktoken-Fallback.

3. Instrumentierung und Metriken

Der Messprozess war identisch und verwendete gemeinsame Utilities und Prinzipien.

• Latenz: time.perf_counter() mit hoher Präzision wurde für alle Zeitmessungen verwendet. Der Framework-Overhead wird konsistent als Gesamtlatenz – Latenz externer Aufrufe berechnet.
• Tokenisierung: Alle Token-Zahlen für Prompts und Completions wurden mit tiktoken, der cl100k_base-Codierung, berechnet, um eine einzige Quelle der Wahrheit für Token-Metriken sicherzustellen. Die in den Ergebnissen berichtete Metrik „Durchschn. Tokens" stellt die kumulative Summe aller Eingabe- (Prompt) und Ausgabe- (Completion) Tokens für jeden LLM-Aufruf (z. B. Router, Grader, Generator) innerhalb eines einzelnen Abfrage-Workflows dar.
• State-Management: Obwohl die Implementierungssyntax variiert (LangGraphs TypedDict, LlamaIndex-Klasse, LangChain-Dictionary), ist die State-Struktur funktional identisch. Jedes Framework übergibt denselben Satz von Schlüsseln (question, documents, web_results usw.) zwischen den Nodes, wodurch sichergestellt wird, dass die Kontrollflusslogik mit denselben Informationen arbeitet.

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

Interpretation der Ergebnisse:

• Sie können folgern: In diesem spezifischen, hochkontrollierten Setup ist der Orchestrierungs-Overhead tendenziell gering; Unterschiede werden hauptsächlich durch Token-Zahlen und Tool-Pfade getrieben.
  • In diesem spezifischen, hochkontrollierten Setup ist der Framework-Overhead vernachlässigbar.
  • Leistungsunterschiede wurden durch Token-Zahlen und Tool-Pfad-Variationen getrieben.
• Sie können nicht verallgemeinern: Die Ergebnisse sind spezifisch für diese Architektur, Modelle, Prompts, Retriever und Web-Anbieter; Änderungen daran können die Rangfolge verändern.

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

Developer Experience: Ein qualitativer Vergleich

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

• LangGraph: Das deklarativer Graph
  Verwendet ein graph-first-Paradigma. Sie definieren Nodes und verdrahten sie mit Kanten (einschließlich add_conditional_edges), sodass der Kontrollfluss Teil der Architektur ist. Der State ist über ein TypedDict mit Reducer-Style-Updates (Annotated[…, add]) typisiert.
  • Wählen Sie LangGraph für: komplexe Workflows mit mehreren Verzweigungen, Wiederholungen und Zyklen; seine Struktur skaliert in Robustheit und Wartbarkeit, wenn Agents wachsen.
• LlamaIndex: Imperative Orchestrierung
  Ein prozedurales Skript, bei dem der Kontrollfluss ein Standard-Python-if/else ist; der „Graph" lebt in Ihrem Code. Der State ist eine dedizierte PipelineState-Klasse, und das Framework bietet saubere Retrieval-Primitiven (VectorStoreIndex → .as_retriever(k=5)).
  • Wählen Sie LlamaIndex für: lesbare, ein-Datei-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, komponierbare Chains unter Verwendung des | Operators (z. B. prompt | llm | parser). Der State ist ein flexibles, untypisiertes Python-Dictionary.
  • Wählen Sie LangChain für: schnelles Prototyping oder Teams, die bereits im LangChain-Ökosystem sind und das Komponieren kleiner deklarativer Einheiten innerhalb eines größeren imperativen Treibers bevorzugen.
• Haystack: Komponentenbasiert, manuelle Orchestrierung Typisierte, wiederverwendbare Komponenten (@component) mit explizitem I/O, während der Kontrollfluss reines Python (if/else) bleibt. Einfach, LLM/Retriever/Web-Backends zu tauschen, plus erstklassige Instrumentierung pro Schritt (extern vs. Framework-Zeit).
  • Wählen Sie Haystack für: produktionsbereite, 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 sie dann mit Modulen, die Prompting und LLM-Aufrufe kapseln. Zentralisiert Prompt/Usage-Handling und entfernt Glue-Code; das Austauschen von Internals (z. B. Predict ↔ CoT) ändert den Vertrag nicht.
  • Wählen Sie DSPy für: minimalen Boilerplate, lesbare ein-Datei-Flows, vertragsgetriebene Entwicklung (mit optionalen Optimierern).

Optimale Leistung für Vergleichbarkeit eintauschen

• LangGraph könnte mit seinen nativen Graph-Optimierungen glänzen, wenn es erlaubt ist, parallele Ausführung, State-Caching und sein bedingtes Kanten-System für komplexe Verzweigungslogik zu nutzen.
• DSPy könnte dramatisch unterschiedliche Ergebnisse zeigen, wenn es seine Signatur-Optimierer (wie MIPROv2) und Chain-of-Thought-Prompting verwendet, was die Antwortqualität erheblich verbessern kann.
• Haystack könnte seine produktionsbereiten Caching-, Batching-Funktionen und komponentenbasierten Optimierungen nutzen, die wir der Fairness halber deaktiviert haben.
• LlamaIndex könnte von seinen fortschrittlichen Indexierungsstrategien, Query-Engines und Multi-Modal-Fähigkeiten profitieren, die in diesem Benchmark nicht getestet wurden.
• LangChain könnte mit seinem umfangreichen Tool-Ökosystem und LCEL (LangChain Expression Language)-Optimierungen glänzen, wenn es nicht auf unseren standardisierten Toolset beschränkt ist.

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

Weiterführende Literatur

Entdecken Sie weitere RAG-Benchmarks, wie:

• Embedding-Modelle: 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

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  = jun,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Abgerufen am 3. Juni 2026}
}

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. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten