Frameworks RAG: LangChain vs LangGraph vs LlamaIndex

Nous avons évalué 5 frameworks RAG : 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). Cela isole le véritable surcoût et l'efficacité en tokens de chaque framework.

Résultats du benchmark des frameworks RAG

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

• Tokens moyens : 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. Moins élevé = coût d'API réduit.
• Surcoût du framework : Temps d'orchestration pur (ms), le traitement interne du framework (logique de routage, gestion d'état, etc.), excluant les appels LLM API et aux outils. Moins élevé = framework plus léger.

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

Principaux enseignements

1. 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é du calculateur, plafond de tokens de contexte partagé, grille d'évaluation identique, instrumentation unifiée. Cela réduit considérablement les principaux facteurs de confusion dans nos mesures.
2. Le surcoût 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 source principale des écarts de latence >1 s ; la majeure partie du temps est consacrée aux E/S avec les modèles/outils externes.
3. La performance suit les tokens (dans ces contraintes) : DSPy affiche le surcoût de framework le 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. La consommation de tokens est la plus faible pour Haystack (~1,57k), puis LlamaIndex (~1,60k) ; DSPy et LangGraph sont à environ 2,03k, et LangChain à environ 2,40k.
4. Le routage/chemin d'outil est important : De légers décalages dans le routage initial (retriever vs web vs calculateur) 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 variances dans le nombre de tokens et la latence subsistent. Celles-ci sont attribuables aux comportements inhérents de bas niveau de chaque framework, leur « ADN ».

• Sérialisation des prompts et 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 deltas de tokens faibles mais constants.
• Assemblage du contexte : L'ordonnancement 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.
• Départage en cas d'égalité de routage : Dans les cas limites, des différences subtiles dans la façon dont un framework parse 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 moteur, 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 retriever, web_search ou calculateur.
• 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 LLM avec température=0,0 et un plafond de tokens de contexte partagé pour générer une ébauche de réponse.
• Évaluer la réponse : Un second juge LLM évalue l'ébauche pour la fondation, les contradictions (hallucinations) et la complétude.
• Repli et retour anticipé : Une recherche web est déclenchée si la note de la réponse est insuffisante. Les résultats du calculateur, en revanche, sont renvoyés directement, en contournant les étapes de génération et d'évaluation.

Exemples de workflow

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

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

Scénario C — Le calculateur fournit un retour anticipé :

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

Méthodologie des frameworks RAG

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

1. Composants principaux et configuration

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

• LLM :
  • Modèle : Tous les nœuds (routeur, générateur, évaluateur) ont utilisé le modèle openai/gpt-4.1-mini via l'API OpenRouter.
  • Déterminisme : La température a été réglée sur 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é réglé sur 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 store vectoriel Qdrant a été interrogé pour un k=5 (top 5 documents) dans toutes les implémentations.
• Outillage :
  • Recherche web : Le benchmark a été limité à Tavily uniquement (max_results=3).
  • Calculateur : Les cinq implémentations ont utilisé la bibliothèque sympy pour l'analyse et l'évaluation des expressions mathématiques, garantissant des capacités identiques.

2. Flux de contrôle et politique RAG

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

• 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 heuristic_route basée sur les regex vérifie d'abord les motifs évidents de calculateur ou de recherche web (par exemple, symboles mathématiques, années comme « 2024 »).
  2. Un nœud routeur LLM prend ensuite sa propre décision.
  3. La décision finale priorise l'heuristique pour les calculateurs, sinon s'en remet au choix du LLM.
• Budgétisation du contexte : C'est l'une des standardisations les plus critiques. Avant que le nœud generate_answer ne soit appelé, 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 en utilisant un utilitaire commun truncate_to_token_budget. Cela garantit que le LLM générateur de chaque framework reçoit une entrée de taille exactement identique, empêchant qu'un framework soit avantagé ou désavantagé par la verbosité de son contexte récupéré.
• Politique d'évaluation des réponses :
  • Grille d'évaluation indulgente : Le nœud grade_answer utilise un prompt indulgent identique dans tous les frameworks, demandant au juge LLM d'accepter les réponses sémantiquement similaires et raisonnablement complètes.
  • Gestion des échecs : La logique de gestion d'un échec de parsing JSON de l'évaluateur a été standardisée. Si la sortie de l'évaluateur n'est pas du JSON valide, le système revient par défaut à une évaluation permissive (grounded=True, complete=True), imitant un scénario réel où l'on ne voudrait pas qu'un parser fragile rejette une réponse par ailleurs bonne. DSPy renvoie des champs structurés (pas de parsing JSON), ceci est consigné comme une différence de robustesse, pas un avantage de performance.
• Retour anticipé du calculateur : Comme on le voit dans le code, un appel réussi au nœud calculateur définit directement la final_answer et termine le workflow de manière anticipée. C'est une optimisation significative qui est appliquée de manière cohérente, empêchant le chemin du calculateur d'invoquer inutilement les LLM de génération et d'évaluation.
• Alignement DSPy. Pour maintenir l'équité avec les références non-CoT, DSPy utilise dspy.Predict (pas de CoT) pour le routeur et le générateur de réponses. Les signatures reflètent les contrats de nœuds des autres frameworks ; lorsque disponible, le nombre de tokens utilise l'utilisation rapportée par le modèle, sinon recours à tiktoken.

3. Instrumentation et métriques

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

• Latence : time.perf_counter() de haute précision a été utilisé pour tous les chronométrages. Le surcoût du framework est systématiquement calculé comme Latence totale – Latence des appels externes.
• Tokenisation : Tous les comptages 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 « 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 exemple, routeur, évaluateurs, générateur) au sein d'un seul workflow 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 transmet le même ensemble de clés (question, documents, web_results, etc.) entre les nœuds, garantissant que la logique du 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, le surcoût d'orchestration tend à être mineur ; les différences sont principalement déterminées par le nombre de tokens et les chemins d'outils.
  • Dans cette configuration spécifique et hautement contrôlée, le surcoût du framework est négligeable.
  • Les différences de performance étaient déterminées par le nombre de tokens et les variations de chemin d'outil.
• 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 ; les modifier peut altérer les classements.

Expérience développeur : une comparaison qualitative

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

• LangGraph : Le graphe déclaratif
  Utilise un paradigme orienté graphe. Vous définissez des nœuds et les reliez 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 : les workflows complexes avec de multiples branches, reprises et cycles ; sa structure gagne en robustesse et maintenabilité à mesure que les agents se complexifient.
• LlamaIndex : Orchestration impérative
  Un script procédural où le flux de contrôle est du Python standard if/else ; 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 : les workflows 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 dict 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 des composants, orchestration manuelle Composants typés et réutilisables (@component) avec E/S explicites, tandis que le flux de contrôle reste en Python standard (if/else). Facile d'échanger les backends LLM/retriever/web, plus une instrumentation par étape de première classe (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 orientés signatures (moins de lignes de code)
  Définit une tâche via une signature (entrées/sorties + intention), puis l'implémente avec des Modules qui encapsulent le prompting et les appels LLM. Centralise la gestion des prompts/de l'utilisation et supprime le code de liaison ; changer les éléments internes (par exemple, Predict ↔ CoT) ne modifie pas le contrat.
  • Choisissez DSPy pour : un code boilerplate minimal, des flux lisibles en un seul fichier, un développement piloté par contrat (avec optimiseurs optionnels).

Échanger la performance optimale contre 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 prompting Chain-of-Thought, ce qui peut améliorer significativement la qualité des réponses.
• Haystack pourrait tirer parti de ses fonctionnalités de mise en cache et de traitement par lots prêtes pour la production, ainsi que des 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é exercées 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 boîte à outils standardisée.

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

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 le 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éliorer la précision du 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  = {{Frameworks RAG: LangChain vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Consulté le 4 Août 2026}
}

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe des centaines de milliers d'entreprises (selon SimilarWeb) dont 60 % du Fortune 500 chaque mois.

Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes, Washington Post, des entreprises mondiales comme Deloitte, HPE et des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne.

Tout au long de sa carrière, Cem a exercé en tant que consultant tech, acheteur tech et entrepreneur tech. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus d'une décennie. 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 tout en rendant compte au PDG. Il a également mené la croissance commerciale de l'entreprise deep tech Hypatos qui a atteint un chiffre d'affaires récurrent annuel à 7 chiffres et une valorisation à 9 chiffres à partir de 0 en 2 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 la Bogazici University en tant qu'ingénieur informatique et détient 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 analyste de 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