Choisissez les frameworks RAG en fonction de la charge de travail, et non en fonction de la popularité de LangChain

Le problème dans son contexte

Découvrir à 2 heures du matin qu’une dépendance LangChain transitive a introduit des changements perturbateurs, que les références fixées ont évolué, et qu’un technicien d’urgence a passé une heure à diagnostiquer le problème pour restaurer une fonctionnalité qui ne fait essentiellement que récupérer des extraits et y répondre, c’est une façon brutale d’apprendre ce qui s’est passé.

Le problème plus profond n’était pas une simple panne. L’équipe ne parvenait plus à comprendre sa propre logique de récupération des données. LangChain avait été le choix par défaut dès le début — tout le monde s’y tournait — et les abstractions se sont accumulées jusqu’à rendre le système opaque. Les systèmes opaques échouent la nuit, et ils échouent progressivement, car personne ne peut identifier la couche défaillante.

Ceci n’est pas une critique malveillante. LangChain est utile lorsque un produit a réellement besoin de fonctions d’appel d’outils, de gestion de la mémoire, de prompts et d’orchestration en plusieurs étapes. Le problème résidait dans l’utilisation d’un orchestrateur général pour des tâches qui n’étaient jamais conçues pour être automatisées de manière autonome.

Le principe

Choisissez un cadre RAG en fonction de la charge de travail, et non en fonction de la mode du moment. Les abstractions augmentent la latence, complexifient les dépendances et rendent le débogage plus difficile. Vous payez ce prix lorsque le problème correspond à ce que le cadre abstracte ; sinon, c’est un fardeau inutile.

Un seul produit peut cacher deux types de charges de travail sous une même marque. Exemple : recherche sémantique d’entreprise sur des documents internes, et vérification rapide de documents via des PDF téléchargés. Aucun de ces cas ne nécessite l’utilisation d’un agent. Payer deux fois le coût total d’orchestration pour deux tâches distinctes est vraiment inutile.

Une carte pratique des outils adaptés aux différentes tâches prend une autre apparence une fois que les étiquettes marketing ont été retirées. Haystack de Deepset convient généralement aux pipelines de récupération de données pour une production explicite. LlamaIndex est plutôt adapté au contrôle qualité rapide de documents privés, avec un parcours court allant des fichiers aux réponses. Les plateformes de dialogue telles que Rasa conviennent aux flux d’assistance axés sur les intentions. Botpress ou Dialogflow sont adaptés aux bots clients basés sur du code simplifié. Hugging Face Transformers convient aux équipes ayant besoin d’un contrôle direct sur les modèles ou de leur affinage. CrewAI, AutoGen et DSPy conviennent aux expériences d’orchestration de multiples agents.

Ces solutions axées sur les agents ont été évaluées de manière honnête et restent intéressantes lorsque le produit nécessite réellement des agents collaboratifs. Cependant, en raison de deux types de charges de travail de récupération, Haystack et LlamaIndex ont remporté la victoire sur le seul critère important pour cette migration.

Compromis

Recherche sémantique d’entreprise — nécessite des solutions explicables, testables, évolutives et auto-hébergées → Haystack (plus de composants ; nécessite une base de données vectorielle).

Vérification de qualité des documents PDF téléchargés — exige une mise en place rapide, une faible latence et peu de ressources informatiques → LlamaIndex (conçu de manière ciblée ; ce n’est pas un orchestrateur).

Agent multi-outils véritable — nécessite des outils, de la mémoire et des modèles de template → LangChain / CrewAI (latence et dépendances importantes sur le chemin principal).

Haystack vise des pipelines modulaires avec une récupération, un routage et une génération explicites, fonctionne avec des backends réels (Elasticsearch, OpenSearch, Weaviate) et peut être auto-hébergé pour des raisons de confidentialité. Les étapes du pipeline restent lisibles :

from haystack.document_stores import InMemoryDocumentStore
from haystack.nodes import DensePassageRetriever, FARMReader
from haystack.pipelines import ExtractiveQAPipeline

document_store = InMemoryDocumentStore()
retriever = DensePassageRetriever(document_store=document_store)
reader = FARMReader(model_name_or_path="deepset/roberta-base-squad2")pipeline = ExtractiveQAPipeline(reader=reader, retriever=retriever)
response = pipeline.run(query="What is Haystack used for?")

Retriever récupère les documents ; le lecteur sélectionne les meilleurs candidats. Lorsque quelque chose est lent ou incorrect, examinez un nœud. Remplacez InMemoryDocumentStore par OpenSearch sans avoir à réécrire le reste.

LlamaIndex relie les LLM aux données locales — ingestion, indexation, requêtes — et reste, par conception, plus ciblé que LangChain :

from llama_index import SimpleDirectoryReader, GPTTreeIndex

documents = SimpleDirectoryReader("<directory_path>").load_data()
index = GPTTreeIndex(documents)
response = index.query("What is the purpose of this document?")

Trois lignes suffisent pour passer d’un dossier PDF à un index consultable. Pour les fonctionnalités qui doivent répondre en quelques secondes, éliminer la surcharge liée à l’orchestration réduit directement le temps de réponse.

Comparé à un monolithe LangChain, une architecture Haystack + LlamaIndex présente des avantages tels qu’une latence p95 plus faible, environ la moitié des dépendances sur le chemin RAG, une identification claire des pannes au niveau des nœuds, moins d’incidents liés au changement de framework, une meilleure adaptation à l’hébergement autonome, ainsi qu’un temps d’intégration de quelques heures plutôt que de jours.

Comment l’adopter

Évitez une réécriture complète d’un coup. Mettez en place des étapes progressives et mesurez les résultats :

1. Mode ombre — mêmes requêtes vers les anciennes et nouvelles routes ; comparaison des réponses et de la latence sans impact sur l’utilisateur.
2. Passage progressif via des flags fonctionnels — redirection progressive du trafic en pourcentage dès que la qualité de l’évaluation est égale ou supérieure à celle de la solution actuelle.
3. Séparation des charges de travail indépendantes — migration séparée du contrôle qualité des PDF si celui-ci ne partage aucun état avec la recherche.
4. Suppression en dernier — suppression de l’ancienne dépendance uniquement après que les deux routes aient fonctionné correctement pendant une version.

outil d’évaluation (questions fixes avec des réponses connues et fiables) permet de transformer la question « La nouvelle route est-elle bonne ? » en un chiffre. Le mode ombre révèle souvent des résultats mixtes : de meilleures performances pour certaines requêtes, des réponses trop courtes pour d’autres ; il convient donc d’orienter les requêtes longues vers un lecteur génératif et de conserver le mode extractif pour des recherches précises. Un changement de framework sans mesure n’est qu’un pari.

Règle d’or : ne cultivez pas de façon excessive cette séparation stricte (les bots d’assistance peuvent préférer Rasa ; le travail avec des modèles bruts peut nécessiter Transformers). Ne bannissez pas LangChain définitivement — conservez-le en attendant l’apparition d’un véritable agent polyvalent.

Où cela mène-t-il ?

Les travaux à court terme restent mesurés : réclassement dans Haystack, lecteurs génératifs pour des réponses longues, éventuellement une expérience avec les intentions de Rasa — l’outil est choisi en fonction de la charge de travail à chaque fois. Les frameworks évolueront à nouveau (CrewAI, AutoGen, DSPy, RAGFlow, Flowise, …). Les équipes qui se laissent guider par l’effervescence reviennent discuter de toute la stack chaque saison. Celles qui définissent clairement les charges de travail et choisissent en fonction d’elles ne revisitent que la partie qui a changé. Si LangChain semble entrer en conflit avec la production, la solution réside souvent dans le bon framework pour le travail concret — et non davantage de LangChain.

Quelles modifications liées à la priorité donnée aux charges de travail dans les processus organisationnels ?

La revue d’architecture cesse de se demander « Sommes-nous standardisés sur LangChain ? » pour commencer à se demander « Quels sont les travaux spécifiques existants, et quel outil correspond à chacun d’eux ? » Cela peut sembler bureaucratique, mais c’est ainsi que les équipes évitent de créer un autre monolithe opaque. Écrivez la liste des travaux : recherche dans la wiki interne, vérification des PDF téléchargés, agent multi-outils futur, éventuellement un bot pour les demandes de support. Attribuez des responsables et des objectifs de performance par travail. Le choix du framework devient alors un détail d’implémentation pour chaque ligne.

Les revues relatives aux achats et à la sécurité deviennent également plus simples. Haystack auto-hébergé associé à OpenSearch implique des considérations différentes concernant les limites des données par rapport à un outil de création de bots SaaS. LlamaIndex utilisé avec des stockages temporaires pour les téléchargements présente à son tour des particularités distinctes. Regrouper ces trois éléments sous une seule demande de « plateforme IA » masque ces différences.

Les guides d’intervention en temps réel devraient mentionner les nœuds, et non les frameworks. « Latence élevée du récupérateur » est une information utile pour agir. « LangChain est lent » ne l’est pas. Après la séparation, les pages indiquent désormais le temps de requête d’OpenSearch ou la saturation du GPU du lecteur, plutôt que des problèmes liés aux dépendances.

La formation des nouveaux ingénieurs change également. Au lieu d’une semaine consacrée aux particularités de LangChain, l’onboarding peut se faire ainsi : voici le diagramme du pipeline Haystack ; voici le script en trois étapes de LlamaIndex ; voici l’ensemble d’évaluation ; voici comment activer le mode shadow. Le temps nécessaire pour soumettre la première PR utile diminue, car le chemin à suivre est plus court.

Rien de tout cela n’interdit LangChain. Ce qui est interdit, c’est de prétendre qu’un seul outil d’orchestration est le choix unique valable, alors que la moitié du produit n’est même pas un agent. Lorsqu’un véritable assistant polyvalent figurera enfin sur le plan de développement, LangChain ou CrewAI pourront être proposés avec une description claire des tâches à accomplir — ainsi qu’un ensemble d’évaluation déjà prêt.

Continuez à mesurer. Continuez à nommer les charges de travail. Gardez le chemin critique suffisamment court pour qu’un ingénieur en service fatigué puisse encore l’expliquer à 2 heures du matin.