RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

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

RAG frameworks : résultats du benchmark

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

• Tokens moyens : Total de 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 contexte récupéré) et les complétions. Plus faible = coût API réduit.
• Surcharge du framework : Temps d’orchestration pur (ms), traitement interne du framework (logique de routage, gestion d’état, etc.), hors appels LLM API et appels d’outils. Plus faible = framework plus léger.

Toutes les implémentations ont atteint une précision de 100 % sur l’ensemble de test. Elles utilisaient les mêmes modèles, températures, fournisseur de retrieval, outil de recherche web et un plafond de tokens de contexte partagé.

Constatations clés

1. Nous concentrons sur le contrôle de ce qui est contrôlable : Même famille de modèles et mêmes températures, max_tokens au niveau des nœuds, retriever (Qdrant + BGE-small, k=5, normalisation activée), fournisseur web (Tavily uniquement), politique du routeur (heuristique + modèle), retour anticipé de la calculatrice, plafond de tokens de contexte partagé, grille d’évaluation identique, instrumentation unifiée. Cela réduit considérablement les principaux facteurs de confusion de nos mesures.
2. La surcharge de framework est mesurable mais faible : Nous avons observé ~3–14 ms par requête provenant de la logique d’orchestration. Ces différences sont réelles, mais ne constituent pas la source principale des écarts de latence >1 s ; l’essentiel du temps est consacré aux I/O avec les modèles/outils externes.
3. La performance suit les tokens (sous ces contraintes) : DSPy affiche 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ées. La consommation de 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 routage/chemin d’outil a son importance : 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 de comptage de tokens et de latence subsistent. Elles sont attribuables aux comportements inhérents de bas niveau de chaque framework, leur « ADN ».

• Sérialisation des prompts & 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 des écarts de tokens faibles mais constants.
• Assemblage du contexte : L’ordre précis et l’inclusion des métadonnées dans le contexte concaténé peuvent légèrement différer selon le framework, affectant le nombre final de tokens.
• Départage du 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 en tokens semble être le principal facteur, plus que le temps d’exécution du framework.

L’architecture RAG agentique partagée

Pour obtenir 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 entre retriever, web_search ou calculatrice.
• Récupérer les documents : Récupère les 5 meilleurs documents depuis Qdrant en utilisant des embeddings BGE-small normalisés.
• Évaluer les documents : Un juge LLM évalue la pertinence des documents. S’ils ne sont pas pertinents, il déclenche un repli vers la recherche web.
• Générer la réponse : Utilise un paramètre temperature=0.0 pour un LLM avec un plafond de tokens de contexte partagé pour générer une réponse provisoire.
• Évaluer la réponse : Un second juge LLM évalue le brouillon pour son ancrage factuel, les contradictions (hallucinations) et l’exhaustivité.
• Repli & retour anticipé : Une recherche web est déclenchée si la note de la réponse est insuffisante. Les résultats de la calculatrice sont toutefois renvoyés directement, en sautant les étapes de génération et d’évaluation.

Exemples de workflow

Scénario A — Réponse directe de 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 — Base de données vectorielle insuffisante, repli vers la recherche web :

RAG frameworks : méthodologie

Les cinq implémentations ont atteint une précision de 100 % sur notre ensemble de test de 100 requêtes, en correspondant aux réponses de référence. C’était l’exigence fondamentale, garantissant que chaque framework puisse exécuter avec succès le même workflow RAG agentique avant de mesurer les différences de performance.

1. Composants de base & 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) utilisaient le modèle openai/gpt-4.1-mini via le service OpenRouter API.
  • Déterminisme : la température a été réglé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 max_tokens ont été appliquées : 256 pour le routeur et les évaluateurs, et 512 pour le générateur. Cela évite des différences de latence causées par un framework générant des réponses excessivement longues.
• Modèle d’embedding & retrieval :
  • Modèle : Tous les frameworks utilisaient BAAI/bge-small-en-v1.5 de HuggingFace.
  • Normalisation : Étape critique pour la performance, normalize_embeddings a été réglé sur True dans les cinq frameworks. (LangChain/LangGraph via encode_kwargs ; LlamaIndex via normalize=True ; Haystack via normalize_embeddings ; retriever DSPy normalisé.)
  • Retrieval : Le vector store Qdrant a été interrogé pour un k=5 (top 5 documents) dans toutes les implémentations.
• Outillage :
  • Recherche web : Le benchmark a été restreint à Tavily uniquement (max_results=3).
  • Calculatrice : Les cinq implémentations utilisaient la bibliothèque sympy pour l’analyse et l’évaluation d’expressions mathématiques, garantissant des capacités identiques.

2. Flux de contrôle RAG & politique

Le processus de « prise de décision » de l’agent a été explicitement reproduit dans tous les cas.

• 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 et les règles déterministes :
  1. Un heuristic_route basé sur regex vérifie d’abord les motifs évidents de calculatrice ou de recherche web (par exemple, symboles mathématiques, années comme « 2024 »).
  2. Un router_node LLM prend ensuite sa propre décision.
  3. La décision finale donne la priorité à l’heuristique pour les calculatrices, sinon elle s’en remet au choix du LLM.
• Budgetisation du contexte : C’est l’une des standardisations les plus critiques. Avant l’appel du 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 à un plafond partagé de 2000 tokens à l’aide d’un utilitaire commun truncate_to_token_budget. Cela garantit que le LLM générateur de chaque framework reçoit une entrée exactement de la même taille, évitant qu’un framework soit avantagé ou désavantagé par la verbosité de son contexte récupéré.
• Politique d’évaluation des réponses :
  • Grille indulgente : Le nœud grade_answer utilise un prompt identique et indulgent dans tous les frameworks, demandant au 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 l’évaluateur a été standardisée. Si la sortie de l’évaluateur n’est pas un JSON valide, le système adopte par défaut une note permissive (grounded=True, complete=True), imitant un scénario réel où l’on ne voudrait pas qu’un analyseur fragile fasse échouer une réponse autrement correcte. Les champs structurés DSPy sont renvoyés (pas d’analyse JSON) ; ceci est consigné comme une différence de robustesse, et non comme un avantage de performance.
• Retour anticipé de la calculatrice : Comme vu dans le code, un appel réussi à calculator_node définit directement final_answer et termine le workflow de manière anticipée. C’est une optimisation significative appliquée de manière cohérente, empêchant le chemin de la calculatrice d’invoquer inutilement les LLMs de génération et d’évaluation (generate et grade_answer).
• Alignement DSPy. Pour maintenir l’équité avec les références 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 ; lorsqu’elles sont disponibles, les quantités de tokens utilisent l’utilisation rapportée par le modèle, sinon un repli tiktoken.

3. Instrumentation et métriques

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

• Latence : La fonction time.perf_counter() de haute précision a été utilisée pour toutes les mesures de temps. La surcharge du framework est systématiquement calculée comme Latence totale – Latence des appels externes.
• Tokenisation : Tous les comptages de tokens pour les prompts et les complétions ont été calculés à l’aide de tiktoken, l’encodage cl100k_base, garantissant une source unique de vérité pour les métriques de tokens. La métrique « Tokens moyens » rapportée dans les résultats représente la somme cumulée de tous les tokens d’entrée (prompt) et de sortie (complétion) pour chaque appel LLM (par ex., routeur, évaluateurs, générateur) au sein d’un workflow de requête unique.
• Gestion de l’état : Bien que la syntaxe d’implémentation varie (TypedDict de LangGraph, classe de LlamaIndex, dictionnaire de LangChain), la structure de l’état est fonctionnellement identique. Chaque framework transmet 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 appliquant ces standardisations strictes au niveau du code, ce benchmark vise à dépasser les comparaisons superficielles et à offrir une analyse reproductible des performances 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 comptages 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 du nombre de tokens et des chemins d’outils.
• Vous ne pouvez pas généraliser : Les résultats sont spécifiques à cette architecture, à ces modèles, prompts, retriever et fournisseur web ; les modifier peut changer les classements.

Expérience développeur : une comparaison qualitative

La performance n’est pas le seul facteur ; la sensation d’un framework lors du développement est tout aussi importante.

• LangGraph : le graphe déclaratif
  Utilise un paradigme orienté graphe. Vous définissez des nœuds et les reliez par 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]).
  • Choisir LangGraph pour : des workflows complexes avec de multiples branches, tentatives et cycles ; sa structure gagne en robustesse et en maintenabilité à mesure que les agents se développent.
• LlamaIndex : orchestration impérative
  Un script procédural où le flux de contrôle est du Python if/else standard ; le « graphe » vit dans votre code. L’état est une classe dédiée PipelineState, et le framework fournit des primitives de retrieval propres (VectorStoreIndex → .as_retriever(k=5)).
  • Choisir LlamaIndex pour : des workflows lisibles à fichier unique où vous appréciez une logique procédurale claire et un débogage facile.
• LangChain : impératif avec des 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 ex., prompt | llm | parser). L’état est un dict Python flexible et non typé.
  • Choisir 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 : orchestration manuelle à base de composants Des composants typés et réutilisables (@component) avec des I/O explicites, tandis que le flux de contrôle reste du Python simple (if/else). Facilité d’échanger les backends LLM/retriever/web, plus une instrumentation de premier ordre à chaque étape (temps externe vs temps framework).
  • Choisir Haystack pour : des pipelines prêts pour la production, testables, avec des contrats clairs et un contrôle fin.
• DSPy : programmes signature-first (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 et de l’utilisation et élimine le code de liaison ; remplacer les éléments internes (par ex., Predict ↔ CoT) ne change pas le contrat.
  • Choisir DSPy pour : un boilerplate minimal, des flux lisibles à fichier unique, un développement piloté par contrat (avec des optimiseurs optionnels).

Sacrifier la performance optimale au profit de la comparabilité

• LangGraph pourrait exceller avec ses optimisations de graphe natives 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 en utilisant ses optimiseurs de signature (comme MIPROv2) et le prompt Chain-of-Thought, ce qui peut améliorer considérablement la qualité des réponses.
• Haystack pourrait tirer parti de sa mise en cache prête pour la production, de ses fonctions de traitement par lots et de ses optimisations au niveau des composants que nous avons désactivées par souci d’é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é mises à l’épreuve dans ce benchmark.
• LangChain pourrait briller avec son vaste écosystème d’outils et ses 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 motifs architecturaux spécifiques.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Lectures complémentaires

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

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  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Consulté le 31 Août 2026}
}

Journal des modifications

7 mises à jour

Toutes7Général5Méthodologie2

1. 202629 Jan

   Ajout du nombre de requêtes et d'exécutions à la méthodologie de benchmark.

2. 27 Jan

   Mise à jour des résultats et de la méthodologie du benchmark des frameworks RAG.

3. 202510 Nov

   Ajout de la définition des jetons moyens et de la surcharge du framework aux résultats du benchmark des frameworks RAG.

4. 1 Nov

   Données de performance remplacées dans la section Résultats Clés.

5. 1 Nov

   Remplacement de la description de la méthodologie dans la section des frameworks RAG.

6. 31 Oct

   Ajout de Haystack et DSPy à la comparaison des frameworks RAG.

7. 31 Oct

   Mise à jour du nombre d'implémentations dans la section méthodologie.

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017.

Le travail de Cem chez AIMultiple a été cité par des publications mondiales de premier plan, notamment Business Insider, Forbes, Morning Brew et Washington Post, par des entreprises mondiales comme Deloitte et HPE, par des ONG comme World Economic Forum et par des organisations supranationales comme European Commission. [1], [2], [3], [4], [5]

Tout au long de sa carrière, Cem a été consultant en technologies, acheteur de technologies et entrepreneur technologique. 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 digitalisation.

Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité du PDG. Il a également dirigé la croissance commerciale de l'entreprise de technologie profonde Hypatos, qui a atteint un revenu récurrent annuel à 7 chiffres et une valorisation à 9 chiffres, passant de 0 à ce résultat en deux ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.

Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de Bogazici University en tant qu'ingénieur informatique et 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 et scientifique des données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

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