Frameworks RAG : LangChain vs LangGraph vs LlamaIndex

Nous avons évalué cinq frameworks RAG : LangChain, LangGraph, LlamaIndex, Haystack et DSPy, en construisant le même flux de travail RAG multi-agents avec des composants standardisés : modèles identiques (GPT-4.1-mini), plongements lexicaux (BGE-small), outil de récupération (Qdrant) et outils de recherche web (Tavily). Cela permet d’isoler la surcharge réelle et l’efficacité de chaque framework en termes de tokens.

Résultats de référence des cadres RAG

Le test de référence consistait en 100 requêtes, chaque framework exécutant l'ensemble complet 100 fois afin de fournir des moyennes stables.

• Nombre moyen de jetons : nombre total de jetons consommés par l’ensemble des appels LLM (routeur, correcteur de documents, correcteur de réponses et générateur), incluant les invites (avec contexte récupéré) et les complétions. Plus ce nombre est bas, moins le coût de l’API est élevé.
• Surcharge du framework : Temps d’orchestration pur (ms), correspondant au traitement interne du framework (logique de routage, gestion d’état, etc.), hors appels à l’API LLM et aux outils. Plus la valeur est basse, plus le framework est léger.

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

Principales conclusions

1. Nous nous concentrons sur ce qui est contrôlable : même famille de modèles et températures, nombre maximal de jetons au niveau des nœuds, récupérateur (Qdrant + BGE-small, k=5, normalisation activée), fournisseur web (Tavily uniquement), politique de routage (heuristique + modèle), retour anticipé du calculateur, limite de jetons pour le contexte partagé, grille d'évaluation identique et instrumentation unifiée. Cela réduit considérablement les principaux facteurs de confusion dans nos mesures.
2. La surcharge liée au framework est mesurable mais faible : nous avons observé une latence d'environ 3 à 14 ms par requête due à la logique d'orchestration. Ces différences sont réelles, mais ne constituent pas la principale source des écarts de latence supérieurs à 1 s ; la majeure partie du temps est consacrée aux entrées/sorties avec les modèles et outils externes.
3. Les performances en termes de jetons (sous ces contraintes) sont les suivantes : DSPy présente la plus faible surcharge du framework (environ 3,53 ms). Haystack (environ 5,9 ms) et LlamaIndex (environ 6 ms) suivent, tandis que LangChain (environ 10 ms) et LangGraph (environ 14 ms) affichent des surcharges plus élevées. L’utilisation des jetons est la plus faible pour Haystack (environ 1 570), puis pour LlamaIndex (environ 1 600) ; DSPy et LangGraph consomment environ 2 030 jetons, et LangChain environ 2 400.
4. L'acheminement/le chemin d'accès aux outils est important : de légers décalages dans l'acheminement initial (récupérateur vs. Web vs. calculatrice) et le comportement de repli affectent à la fois les jetons et le temps, même lorsque les invites et les budgets sont alignés.

Pourquoi les différences persistent-elles ? L’« ADN du cadre »

Malgré la standardisation, de légères variations subsistent au niveau du nombre de jetons et de la latence. Celles-ci sont imputables aux comportements inhérents et de bas niveau de chaque framework, à leur « ADN ».

• Sérialisation des invites et des messages : chaque framework encapsule le même contenu logique avec une mise en forme légèrement différente avant de l’envoyer au LLM, créant ainsi de petits deltas de jetons cohérents.
• 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, ce qui affecte le nombre final de jetons.
• Départage en matière 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 du jeton semble être le principal facteur déterminant, plus que le temps d'exécution du framework.

L'architecture RAG à agents partagés

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

• Routeur : Un nœud hybride, combinant modèle et heuristique, qui choisit entre récupérateur, recherche web ou calculatrice.
• Récupérer les documents : Récupère les 5 premiers documents de Qdrant en utilisant des plongements BGE-small normalisés.
• Évaluation des documents : Un juge du programme LLM évalue la pertinence des documents. Si un document est jugé non pertinent, une recherche Web est effectuée.
• Générer une réponse : Utilise un LLM de température = 0,0 avec une limite de jetons de contexte partagé pour générer une réponse préliminaire.
• Réponse concernant la note : Un deuxième juge LLM évalue le projet en fonction de sa cohérence, des contradictions (hallucinations) et de son exhaustivité.
• Solution de repli et retour anticipé : une recherche Web est déclenchée si la note de la réponse est insuffisante. En revanche, les résultats de la calculatrice sont renvoyés directement, sans passer par les étapes de génération et de notation.

Exemples de flux de travail

Scénario A — Correspondance directe avec la base de données :

Scénario B — Outil Web de déclenchement d'événements récents :

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

Scénario D — Base de données vectorielle insuffisante, recours à la recherche Web :

méthodologie des cadres 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. Il s'agissait d'une condition essentielle, garantissant que chaque framework puisse exécuter avec succès le même flux de travail RAG (Remote Agility Group) avant de mesurer les différences de performance.

1. Composants principaux et configuration

Les outils de base ont été standardisés afin d'éliminer les variables de performance à la source.

• Masters en droit :
  • Modèle : Tous les nœuds (routeur, générateur, correcteur) ont utilisé le modèle openai/gpt-4.1-mini via l'API OpenRouter.
  • Déterminisme : la température a été fixée à 0,0 pour tous les appels LLM afin de garantir une cohérence maximale dans le routage, la génération et le classement.
  • Limites de jetons : des limites strictes ont été appliquées au nombre maximal de jetons : 256 pour le routeur et les correcteurs, et 512 pour le générateur. Ceci permet d’éviter les différences de latence dues à la génération de réponses excessivement longues par un framework.
• Modèle d'intégration et récupération :
  • Modèle : Tous les frameworks utilisés BAAI/bge-small-en-v1.5 de HuggingFace.
  • Normalisation : Étape cruciale pour les performances, la propriété `normalize_embeddings` a été définie sur `True` dans les cinq frameworks. (LangChain/LangGraph via `encode_kwargs` ; LlamaIndex via `normalize=True` ; Haystack via `normalize_embeddings` ; DSPy retriever normalisé.)
  • Récupération : Le magasin de vecteurs Qdrant a été interrogé pour ak=5 (5 premiers documents) dans toutes les implémentations.
• Outillage :
  • Recherche Web : Le test de performance a été limité à Tavily uniquement (max_results=3).
  • Calculatrice : Les cinq implémentations utilisaient la bibliothèque sympy pour l’analyse et l’évaluation des expressions mathématiques, garantissant des capacités identiques.

2. Flux et politique de contrôle RAG

Le processus de « prise de décision » de l'agent était explicitement reproduit à l'identique dans tous les domaines.

• Logique de routage : Une stratégie de routage hybride a été implémentée dans les cinq scripts afin d’équilibrer l’intelligence du modèle et les règles déterministes.
  1. Une route heuristique basée sur les expressions régulières vérifie d'abord les modèles évidents de calculatrice ou de recherche Web (par exemple, les symboles mathématiques, les années comme « 2024 »).
  2. Un nœud routeur LLM prend alors sa propre décision.
  3. La décision finale privilégie l'heuristique pour les calculatrices, sinon elle s'en remet au choix du LLM.
• Gestion du contexte : Il s’agit d’une des normalisations les plus importantes. Avant l’appel au nœud `generate_answer`, tous les documents de contexte et les résultats de recherche Web récupérés sont concaténés, puis limités à 2 000 jetons grâce à l’utilitaire commun `truncate_to_token_budget`. Ceci garantit que le générateur LLM de chaque framework reçoit une entrée de taille identique, évitant ainsi qu’un framework ne soit avantagé ou désavantagé par la verbosité de son contexte récupéré.
• Politique de notation des réponses :
  • Rubrique indulgente : Le nœud grade_answer utilise une consigne identique et indulgente dans tous les cadres, demandant au juge du LLM d’accepter des réponses sémantiquement similaires et raisonnablement complètes.
  • Gestion des erreurs : La logique de gestion des erreurs d’analyse JSON du correcteur a été standardisée. Si la sortie du correcteur n’est pas un JSON valide, le système attribue par défaut une note permissive (grounded=True, complete=True), simulant ainsi un scénario réel où l’on ne souhaiterait pas qu’un analyseur syntaxique fragile invalide une réponse par ailleurs correcte. Les champs structurés DSPy ne sont pas analysés (absence d’analyse JSON) ; ce comportement est enregistré comme une différence de robustesse, et non comme un gain de performance.
• Retour anticipé de la calculatrice : comme illustré dans le code, un appel réussi au nœud `calculator_node` définit directement `final_answer` et interrompt le flux de travail prématurément. Cette optimisation importante, appliquée systématiquement, empêche le chemin de la calculatrice d'appeler inutilement les fonctions `generate` et `grade_answer`.
• Alignement avec DSPy. Afin de garantir l'équité avec les références sans CoT, DSPy utilise dspy.Predict (sans CoT) pour Router et AnswerGenerator. Les signatures sont identiques aux contrats de nœuds des autres frameworks ; le nombre de jetons est calculé à partir de l'utilisation rapportée par le modèle, sinon le nombre de jetons TikTok est utilisé.

3. Instrumentation et métriques

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

• Latence : La fonction time.perf_counter() haute précision a été utilisée pour toutes les mesures de temps. La surcharge du framework est systématiquement calculée comme suit : latence totale – latence des appels externes.
• Tokenisation : Le nombre de jetons pour les invites et les complétions a été calculé à l’aide de tiktoken et de l’encodage cl100k_base, garantissant ainsi une source unique de données fiables. La métrique « Nombre moyen de jetons » affichée dans les résultats correspond à la somme cumulée de tous les jetons d’entrée (invite) et de sortie (complétion) pour chaque appel LLM (par exemple, routeur, correcteurs, générateur) au sein d’un même 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 transmet le même ensemble de clés (question, documents, web_results, etc.) entre les nœuds, garantissant ainsi que la logique de contrôle d'exécution s'applique aux mêmes informations.

En imposant ces normes strictes au niveau du code, ce benchmark vise à aller au-delà des comparaisons superficielles et à offrir une analyse reproductible des performances du framework dans le cadre d'une politique RAG fixe.

Interprétation des résultats :

• On peut en conclure que, dans cette configuration spécifique et très contrôlée, la surcharge liée à l'orchestration est généralement mineure ; les différences sont principalement dues au nombre de jetons et aux chemins d'outils.
  • Dans cette configuration spécifique et hautement contrôlée, la surcharge liée au framework est négligeable.
  • Les différences de performance étaient dues au nombre de jetons et aux variations de la trajectoire de l'outil.
• Vous ne pouvez pas généraliser : les résultats sont spécifiques à cette architecture, ces modèles, ces invites, ce récupérateur et ce fournisseur Web ; modifier ces éléments peut altérer les classements.

Expérience des développeurs : une comparaison qualitative

Les performances ne sont pas le seul facteur ; la facilité d’utilisation d’un framework est tout aussi importante.

• LangGraph : Le graphe déclaratif
  Utilise une approche graphe-first. Vous définissez les nœuds et les reliez par des arêtes (y compris add_conditional_edges), le flux de contrôle faisant ainsi partie intégrante de l'architecture. L'état est typé via un TypedDict avec des mises à jour de type reducer (Annotated[…, add]).
  • Choisissez LangGraph pour : les flux de travail complexes avec de multiples branches, tentatives et cycles ; sa structure évolue en termes de robustesse et de maintenabilité à mesure que le nombre d'agents augmente.
• LlamaIndex : Orchestration impérative
  Un script procédural où le flux de contrôle est géré par des instructions if/else standard de Python ; 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 claires (VectorStoreIndex → .as_retriever(k=5)).
  • Choisissez LlamaIndex pour : des flux de travail lisibles et composés d'un seul fichier, où vous accordez une grande importance à 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 à l'aide de 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à présentes 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 basée sur les composants. Composants typés et réutilisables (@component) avec E/S explicites, tandis que le flux de contrôle reste en Python pur (if/else). Changement aisé des backends LLM/retriever/web, et instrumentation de pointe par étape (externe vs. temps d'exécution du framework).
  • Choisissez Haystack pour : des pipelines prêts pour la production et testables, avec des contrats clairs et un contrôle précis.
• DSPy : Programmes privilégiant 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 invites et les appels LLM. Centralisez la gestion des invites et de l'utilisation et supprimez le code d'interface ; le remplacement des éléments internes (par exemple, Predict ↔ CoT ) ne modifie pas le contrat.
  • Choisissez DSPy pour : un minimum de code répétitif, des flux lisibles à fichier unique et un développement piloté par contrat (avec optimiseurs optionnels).

Échanger la performance optimale contre la comparabilité

• LangGraph pourrait exceller grâce à ses optimisations de graphes natives lorsqu'il est autorisé à utiliser l'exécution parallèle, la mise en cache de l'état et son système d'arêtes conditionnelles pour une logique de branchement complexe.
• DSPy pourrait afficher des résultats radicalement différents en utilisant ses optimiseurs de signature (comme MIPROv2) et l'invite Chain-of-Thought, ce qui peut améliorer considérablement la qualité des réponses.
• Haystack pourrait tirer parti de ses fonctionnalités de mise en cache, de traitement par lots et d'optimisations au niveau des composants, prêtes pour la production, que nous avons désactivées par souci d'équité.
• LlamaIndex pourrait tirer profit de ses stratégies d'indexation avancées, de ses moteurs de requêtes et de ses capacités multimodales qui n'ont pas été mises en œuvre dans ce test de référence.
• LangChain pourrait briller grâce à son vaste écosystème d'outils et aux optimisations LCEL (LangChain Expression Language) lorsqu'il n'est pas contraint par notre ensemble d'outils standardisé.

Le « meilleur » framework dépend de si vous privilégiez : la vitesse de développement, la maintenabilité, les performances ou des modèles architecturaux spécifiques.

Pour en savoir plus

Explorez d'autres indicateurs RAG, tels que :

• Modèles d'intégration : OpenAI vs Gemini vs Cohere
• Meilleure base de données vectorielles pour RAG : Qdrant vs Weaviate vs Pinecone
• Analyse comparative d'Agentic RAG : routage multi-bases de données et génération de requêtes
• Hybrid RAG : Amélioration de la précision RAG

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.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire