RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

Nous avons évalué 5 RAG frameworks : LangChain, LangGraph, LlamaIndex, Haystack et DSPy, en construisant le même flux de travail RAG agentique avec des composants standardisés : modèles identiques (GPT-4.1-mini), embeddings (BGE-small), retriever (Qdrant) et outils (recherche web Tavily). Cela isole la véritable surcharge et l'efficacité des tokens de chaque framework.

Résultats du benchmark des frameworks RAG

Le benchmark a consisté en 100 requêtes, chaque framework exécutant l'ensemble complet 100 fois pour fournir des moyennes stables.

• Moyenne des Tokens : Total des tokens consommés lors de tous les appels LLM (routeur, évaluateur de documents, évaluateur de réponse et générateur), incluant à la fois les prompts (avec le contexte récupéré) et les complétions. Plus bas = coût API inférieur.
• Surcharge du Framework : Temps pur d'orchestration (ms), traitement interne du framework (logique de routage, gestion d'état, etc.), excluant les appels LLM API et outils. Plus bas = framework plus léger.

Toutes les implémentations ont atteint 100 % de précision sur l'ensemble de test. Nous avons utilisé les mêmes modèles, températures, fournisseur de récupération, outil de recherche web et une limite de tokens de contexte partagée.

Principales constatations

1. Nous nous concentrons sur le contrôle de ce qui est contrôlable : Même famille de modèles et températures, max_tokens au niveau des nœuds, retriever (Qdrant + BGE-small, k=5, normalisation activée), fournisseur web (Tavily uniquement), politique de routage (heuristique + modèle), retour anticipé de la calculatrice, limite de tokens de contexte partagée, grille d'évaluation identique, instrumentation unifiée. Cela réduit considérablement les principaux facteurs de confusion dans nos mesures.
2. La surcharge du framework est mesurable mais faible : Nous avons observé environ 3–14 ms par requête provenant de la logique d'orchestration. Ces différences sont réelles, mais ne constituent pas la principale source des écarts de latence de >1 s ; la majeure partie du temps est consacrée aux E/S avec des modèles/outils externes.
3. La performance suit les tokens (sous ces contraintes) : DSPy présente la surcharge de framework la plus faible (~3,53 ms). Haystack (~5,9 ms) et LlamaIndex (~6 ms) suivent, tandis que LangChain (~10 ms) et LangGraph (~14 ms) sont plus élevés. L'utilisation des tokens est la plus faible pour Haystack (~1,57k), puis LlamaIndex (~1,60k) ; DSPy et LangGraph sont à ~2,03k, et LangChain à ~2,40k.
4. Le chemin de routage/outils compte : De légers changements dans le routage initial (retriever vs web vs calculatrice) et le comportement de repli affectent à la fois les tokens et le temps, même lorsque les prompts et les budgets sont alignés.

Pourquoi les différences persistent-elles ? L'« ADN du framework »

Malgré la standardisation, de petites variations dans les nombres de tokens et la latence subsistent. Celles-ci sont attribuables aux comportements inhérents et de bas niveau de chaque framework, leur « ADN ».

• Sérialisation des prompts et des messages : Chaque framework enveloppe le même contenu logique avec un formatage légèrement différent avant de l'envoyer au LLM, créant de petits mais cohérents écarts de tokens.
• Assemblage du contexte : L'ordre précis et l'inclusion des métadonnées dans le contexte concaténé peuvent différer légèrement selon le framework, affectant le nombre final de tokens.
• Tie-breaks de routage : Dans les cas limites, de subtiles différences dans la façon dont un framework analyse la sortie JSON du routeur peuvent conduire à un choix d'outil initial différent.

Dans cette configuration, l'empreinte des tokens semble être le principal moteur, plus que le temps d'exécution du framework.

L'architecture RAG agentique partagée

Pour assurer une comparaison équitable, les cinq implémentations ont été construites sur le même flux de contrôle :

• Routeur : Un nœud hybride modèle-et-heuristique qui choisit le retriever, la recherche web ou la calculatrice.
• Récupérer des documents : Récupère les 5 meilleurs documents de Qdrant en utilisant des embeddings BGE-small normalisés.
• Évaluer les documents : Un juge LLM évalue la pertinence des documents. S'ils sont non pertinents, il déclenche un repli vers la recherche web.
• Générer une réponse : Utilise un LLM avec température=0.0 et une limite de tokens de contexte partagée pour générer une réponse provisoire.
• Évaluer la réponse : Un deuxième juge LLM évalue l'ébauche pour l'ancrage, les contradictions (hallucinations) et l'exhaustivité.
• Repli et retour anticipé : Une recherche web est déclenchée si la note de réponse est insuffisante. Cependant, les résultats de la calculatrice sont renvoyés directement, sautant les étapes de génération et d'évaluation.

Exemples de flux de travail

Scénario A — Coup direct depuis la base de données :

Scénario B — Un événement récent déclenche l'outil web :

Scénario C — La calculatrice fournit un retour anticipé :

Scénario D — La base de données vectorielle est insuffisante, repli vers la recherche web :

Méthodologie des frameworks RAG

Toutes les cinq implémentations ont atteint 100 % de précision sur notre ensemble de test de 100 requêtes, correspondant aux réponses de vérité terrain. C'était l'exigence fondamentale, garantissant que chaque framework pouvait exécuter avec succès le même flux de travail RAG agentique avant de mesurer les différences de performance.

1. Composants de base et configuration

Les outils fondamentaux ont été standardisés pour éliminer les variables de performance à la source.

• LLMs :
  • Modèle : Tous les nœuds (routeur, générateur, évaluateur) ont utilisé le modèle openai/gpt-4.1-mini via l'OpenRouter API.
  • Déterminisme : la température a été fixée à 0.0 pour tous les appels LLM afin d'assurer une cohérence maximale dans le routage, la génération et l'évaluation.
  • Limites de tokens : Des limites strictes de max_tokens ont été appliquées : 256 pour le routeur et les évaluateurs, et 512 pour le générateur. Cela empêche les différences de latence causées par un framework générant des réponses excessivement longues.
• Modèle d'embedding et récupération :
  • Modèle : Tous les frameworks ont utilisé BAAI/bge-small-en-v1.5 de HuggingFace.
  • Normalisation : Une étape critique pour la performance, normalize_embeddings a été fixé à True dans les cinq frameworks. (LangChain/LangGraph via encode_kwargs ; LlamaIndex via normalize=True ; Haystack via normalize_embeddings ; retriever DSPy normalisé.)
  • Récupération : Le stockage vectoriel Qdrant a été interrogé pour un k=5 (5 meilleurs documents) dans toutes les implémentations.
• Outils :
  • Recherche web : Le benchmark était limité à Tavily-only (max_results=3).
  • Calculatrice : Les cinq implémentations ont utilisé la bibliothèque sympy pour l'analyse et l'évaluation d'expressions mathématiques, garantissant des capacités identiques.

2. RAG flux de contrôle et politique

Le processus de « prise de décision » de l'agent a été explicitement reflété partout.

• Logique de routage : Une stratégie de routage hybride a été implémentée dans les cinq scripts pour équilibrer l'intelligence du modèle avec des règles déterministes :
  1. Une heuristique_route basée sur les expressions régulières vérifie d'abord les motifs évidents de calculatrice ou de recherche web (par exemple, symboles mathématiques, années comme « 2024 »).
  2. Un routeur_node LLM prend ensuite sa propre décision.
  3. La décision finale privilégie l'heuristique pour les calculatrices, sinon elle se réfère au choix du LLM.
• Budget de contexte : C'est l'une des standardisations les plus critiques. Avant l'appel au nœud generate_answer, tout le contexte des documents récupérés et les résultats de recherche web sont concaténés puis tronqués à une limite partagée de 2000 tokens en utilisant un utilitaire truncate_to_token_budget commun. Cela garantit que le générateur LLM dans chaque framework reçoit une entrée de la même taille exacte, empêchant tout framework unique d'être avantagé ou désavantagé par la verbosité de son contexte récupéré.
• Politique d'évaluation des réponses :
  • Grille tolérante : Le nœud grade_answer utilise un prompt identique et tolérant dans tous les frameworks, instruisant le juge LLM d'accepter des réponses sémantiquement similaires et raisonnablement complètes.
  • Gestion des échecs : La logique de gestion d'un échec d'analyse JSON de la part de l'évaluateur a été standardisée. Si la sortie de l'évaluateur n'est pas un JSON valide, le système revient par défaut à une note permissive (grounded=True, complete=True), imitant un scénario réel où vous ne voudriez pas qu'un analyseur fragile fasse échouer une réponse par ailleurs bonne. Les champs structurés DSPy retournent (pas d'analyse JSON), cela est enregistré comme une différence de robustesse, pas un avantage de performance.
• Retour anticipé de la calculatrice : Comme vu dans le code, un appel réussi au calculator_node définit directement final_answer et termine le flux de travail de manière anticipée. C'est une optimisation significative qui est appliquée de manière cohérente, empêchant le chemin de la calculatrice d'invoquer inutilement les LLM generate et grade_answer.
• Alignement DSPy. Pour maintenir l'équité avec les bases non-CoT, DSPy utilise dspy.Predict (pas de CoT) pour Router et AnswerGenerator. Les signatures reflètent les contrats de nœuds des autres frameworks ; là où disponible, les nombres de tokens utilisent l'utilisation rapportée par le modèle, sinon le fallback tiktoken.

3. Instrumentation et métriques

Le processus de mesure était identique, utilisant des utilitaires et des principes partagés.

• Latence : time.perf_counter() haute précision a été utilisé pour tous les chronométrages. La surcharge du framework est calculée de manière cohérente comme Latence Totale – Latence des Appels Externes.
• Tokenisation : Tous les nombres de tokens pour les prompts et les complétions ont été calculés en utilisant tiktoken, l'encodage cl100k_base, garantissant une source unique de vérité pour les métriques de tokens. La métrique « Moyenne des Tokens » rapportée dans les résultats représente la somme cumulative de tous les tokens d'entrée (prompt) et de sortie (complétion) pour chaque appel LLM (par exemple, routeur, évaluateurs, générateur) au sein d'un seul flux de travail de requête.
• Gestion d'état : Bien que la syntaxe d'implémentation varie (TypedDict de LangGraph, classe de LlamaIndex, dictionnaire de LangChain), la structure d'état est fonctionnellement identique. Chaque framework passe le même ensemble de clés (question, documents, web_results, etc.) entre les nœuds, garantissant que la logique de flux de contrôle opère sur les mêmes informations.

En imposant ces standardisations strictes au niveau du code, ce benchmark vise à aller au-delà des comparaisons superficielles et à offrir une analyse reproductible de la performance des frameworks sous une politique RAG fixe.

Interprétation des résultats :

• Vous pouvez conclure : Dans cette configuration spécifique et hautement contrôlée, la surcharge d'orchestration tend à être mineure ; les différences sont principalement dues aux nombres de tokens et aux chemins d'outils.
  • Dans cette configuration spécifique et hautement contrôlée, la surcharge du framework est négligeable.
  • Les différences de performance étaient dues aux variations de nombre de tokens et de chemin d'outils.
• Vous ne pouvez pas généraliser : Les résultats sont spécifiques à cette architecture, ces modèles, ces prompts, ce retriever et ce fournisseur web ; modifier ces éléments peut altérer les classements.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

Expérience développeur : une comparaison qualitative

La performance n'est pas le seul facteur ; la sensation de construction avec un framework est tout aussi importante.

• LangGraph : Le graphe déclaratif
  Utilise un paradigme centré sur le graphe. Vous définissez des nœuds et les connectez avec des arêtes (y compris add_conditional_edges), de sorte que le flux de contrôle fait partie de l'architecture. L'état est typé via un TypedDict avec des mises à jour de style réducteur (Annotated[…, add]).
  • Choisissez LangGraph pour : des flux de travail complexes avec plusieurs branches, des nouvelles tentatives et des cycles ; sa structure évolue en robustesse et maintenabilité à mesure que les agents grandissent.
• LlamaIndex : Orchestration impérative
  Un script procédural où le flux de contrôle est un if/else Python standard ; le « graphe » réside dans votre code. L'état est une classe PipelineState dédiée, et le framework fournit des primitives de récupération propres (VectorStoreIndex → .as_retriever(k=5)).
  • Choisissez LlamaIndex pour : des flux de travail lisibles en un seul fichier où vous valorisez une logique procédurale claire et un débogage facile.
• LangChain : Impératif avec composants déclaratifs
  L'orchestration reste un script Python, mais les tâches individuelles sont de petites chaînes composables utilisant l'opérateur | (par exemple, prompt | llm | parser). L'état est un dictionnaire Python flexible et non typé.
  • Choisissez LangChain pour : le prototypage rapide ou les équipes déjà dans l'écosystème LangChain qui préfèrent composer de petites unités déclaratives au sein d'un pilote impératif plus large.
• Haystack : Basé sur les composants, orchestration manuelle Composants typés et réutilisables (@component) avec E/S explicites, tandis que le flux de contrôle reste un Python simple (if/else). Facile à remplacer les backends LLM/retriever/web, plus une instrumentation de premier plan par étape (temps externe vs framework).
  • Choisissez Haystack pour : des pipelines prêts pour la production, testables avec des contrats clairs et un contrôle fin.
• DSPy : Programmes centrés sur la signature (moins de lignes de code)
  Définissez une tâche via une signature (entrées/sorties + intention), puis implémentez-la avec des Modules qui encapsulent les prompts et les appels LLM. Centralise la gestion des prompts/utilisation et supprime le code de liaison ; remplacer les internes (par exemple, Predict ↔ CoT) ne change pas le contrat.
  • Choisissez DSPy pour : un boilerplate minimal, des flux lisibles en un seul fichier, un développement piloté par les contrats (avec des optimiseurs optionnels).

Échanger la performance optimale contre la comparabilité

• LangGraph pourrait exceller avec ses optimisations natives de graphe lorsqu'il est autorisé à utiliser l'exécution parallèle, la mise en cache d'état et son système d'arêtes conditionnelles pour une logique de branchement complexe.
• DSPy pourrait montrer des résultats radicalement différents lors de l'utilisation de ses optimiseurs de signature (comme MIPROv2) et du prompting Chain-of-Thought, ce qui peut améliorer considérablement la qualité des réponses.
• Haystack pourrait exploiter sa mise en cache prête pour la production, ses fonctionnalités de regroupement et ses optimisations au niveau des composants que nous avons désactivées pour l'équité.
• LlamaIndex pourrait bénéficier de ses stratégies d'indexation avancées, de ses moteurs de requête et de ses capacités multimodales qui n'ont pas été exercées dans ce benchmark.
• LangChain pourrait briller avec son vaste écosystème d'outils et les optimisations LCEL (LangChain Expression Language) lorsqu'il n'est pas contraint à notre ensemble d'outils standardisé.

Le « meilleur » framework dépend de ce que vous optimisez : vitesse de développement, maintenabilité, performance ou modèles architecturaux spécifiques.

Pour aller plus loin

Explorez d'autres benchmarks RAG, tels que :

• Modèles d'embedding : OpenAI vs Gemini vs Cohere
• Meilleure base de données vectorielle pour RAG : Qdrant vs Weaviate vs Pinecone
• Benchmark RAG agentique : routage multi-bases de données et génération de requêtes
• RAG hybride : Amélioration de la précision RAG

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@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. Consulté le 3 Juin 2026}
}

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Recherche effectuée par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire