Pourquoi une appel à un LLM n’est pas une application : quelle est la place de LangChain dans un pipeline RAG ?
Découvrez ce que fait réellement LangChain en suivant le parcours d’une application de réponse à des questions sur des documents, depuis le téléchargement d’un PDF jusqu’à la réponse pertinente, et identifiez les moments où un framework alternatif est plus adapté.
Appeler un grand modèle de langage est simple : on envoie une instruction et on reçoit du texte en retour. Construire quelque chose d’utile à partir de cette simple appelation, en revanche, ne l’est pas. Une véritable application doit pouvoir ingérer des documents, identifier les passages importants, suivre le déroulement de la conversation, composer des instructions et présenter tout cela via une interface ; le modèle n’est qu’un des éléments qui font fonctionner ce système. Cet article explique ce qu’est LangChain en détaillant précisément tous ces composants, à l’aide d’un assistant de lecture de documents comme exemple concret. Après sa lecture, vous devriez être en mesure de décrire chaque étape d’un pipeline de récupération d’informations, de savoir quels aspects un framework comme LangChain prend en charge à votre place, et d’évaluer s’il convient ou non à votre projet.
Qu’est-ce que LangChain, en un paragraphe
LangChain est un framework open source permettant de développer des applications basées sur des LLM. Au lieu de vous fournir un modèle directement, il vous offre des blocs de construction modulaires ainsi que des outils intégrés pour tous les éléments qui entourent un modèle : modèles de prompts, analyseurs de résultats, chargeurs de documents, systèmes de récupération d’informations, mémoires, outils divers et le mécanisme qui les relie entre eux. Il fonctionne avec les principaux fournisseurs de modèles, s’intègre à un vaste catalogue d’outils tiers, est gratuit à utiliser et fait l’objet d’un développement actif. Les applications typiques que les équipes créent avec LangChain incluent des chatbots, des systèmes de réponse à des questions, des systèmes de génération améliorée par la récupération d’informations (RAG) et des agents autonomes.
Le changement de mentalité essentiel est de comprendre que LangChain n’est pas le LLM lui-même. C’est plutôt la couche qui permet au LLM de fonctionner en collaboration avec vos données, vos prompts et vos utilisateurs. Si vous n’envoyez qu’un seul prompt et que vous affichez uniquement la réponse, il n’est pas nécessaire. Dès que votre application comporte plusieurs étapes, vous devez commencer à utiliser les mécanismes qu’il offre déjà.
Une vue d’ensemble
Il est utile de voir l’ensemble du paysage avant d’approfondir. L’apprentissage de LangChain se divise généralement en trois domaines, chacun s’appuyant sur le précédent.
Fondamentaux
Ces éléments sont présents dans toute application LangChain :
- le modèle de composants global
- les modèles, c’est-à-dire les enveloppes autour des API de chat et de complétion
- les prompts et les modèles de prompts
- le parsing des résultats, afin que le texte libre devienne des données structurées
Génération améliorée par la récupération d’informations
RAG permet à un modèle de répondre en s’appuyant sur ses propres documents. Les composants clés sont :
- chargeurs de documents
- découpeurs de texte
- embeddings
- stockages vectoriels
- récupérateurs d’informations
- assemblage de tous ces éléments en une application RAG fonctionnelle
Agents
Les agents permettent au modèle de décider quelles actions entreprendre. Les sujets abordés ici sont :
- outils et kits d’outils
- appel des outils
- création d’un agent qui les utilise
Le reste de cet article se concentre sur les deux premiers domaines, car ce sont eux qui expliquent l’existence même du framework.
Le problème résolu par LangChain
Un système LLM de production ne consiste que rarement en une seule requête. Regardez ce qu’un assistant même modeste doit gérer :
- l’ingestion de documents
- la mise en œuvre d’une recherche sémantique
- la génération et le stockage d’embeddings
- la réalisation de la génération améliorée par la récupération d’informations
- la gestion du contexte et de l’état de la conversation
- l’orchestration d’une ou plusieurs appels à l’LLM
- la fourniture d’une interface de chat
Chacun de ces éléments peut être géré indépendamment. Lorsqu’ils sont reliés manuellement, ils forment un enchevêtrement de codes personnalisés où modifier le modèle, le stockage vectoriel ou le format des prompts signifie devoir toucher à plusieurs fichiers. La valeur de LangChain réside dans le fait qu’elle offre à chaque composant une interface standard ainsi qu’un ensemble d’abstractions réutilisables, permettant ainsi aux éléments de s’assembler en un pipeline et d’être échangés indépendamment.
Un exemple concret : un lecteur de livres par IA
Imaginons une application où les utilisateurs téléchargent des livres ou des PDF, les lisent dans un lecteur intégré et posent des questions à un assistant sur ce qu’ils lisent. Pensez à un manuel d’apprentissage automatique : un étudiant pourrait se demander quel est le compromis entre biais et variance, comment est structurée une architecture CNN particulière, ce que fait la rétropropagation, comment fonctionnent les mécanismes d’attention ou quel algorithme d’optimisation convient à un problème.
L’assistant ne peut répondre correctement que s’il voit les bonnes pages. Cette seule exigence entraîne toute une série de tâches : charger le fichier téléchargé, trouver les passages pertinents pour la question, maintenir une cohérence dans l’historique de la conversation, créer un prompt qui combine la question avec ces passages, puis l’envoyer au modèle.
Dans cette application, LangChain s’occuperait de :
- charger et parser les documents téléchargés
- connecter l’interface de conversation au LLM
C’est là l’illustration la plus claire du fait qu’un LLM seul ne constitue pas une application. Le modèle fournit la capacité linguistique ; tout ce qui permet d’obtenir une réponse concernant un livre en particulier provient des composants qui l’entourent.
Recherche sémantique : trouver du texte par son sens
Le cœur d’un lecteur de livres réside dans la capacité à extraire les passages appropriés à partir d’une grande collection. La recherche par mots-clés échoue dans ce cas, car la question d’un étudiant utilise rarement les mêmes mots que le manuel scolaire. La recherche sémantique résout ce problème grâce aux embeddings : des vecteurs numériques qui placent les textes ayant un sens similaire proches les uns des autres dans un espace à haute dimension. La recherche consiste alors à trouver les vecteurs stockés les plus proches du vecteur de la question.
Un exemple simple
Supposons que la requête soit « Quelle est la capitale de la France ? » Un système de recherche sémantique ne cherche pas des documents qui partagent simplement des mots-clés avec la question. Il recherche plutôt le passage dont le sens est le plus proche, c’est-à-dire un paragraphe sur Paris, plutôt que des passages sur Berlin ou Madrid, même si ceux-ci traitent également des capitales européennes et pourraient obtenir de bons scores en raison des mots communs.
C’est là la différence pratique. Un moteur basé sur les mots-clés classe selon les termes qui se recoupent ; un moteur sémantique classe en fonction de la proximité des sens. Dans la pratique, de nombreux systèmes mis en production combinent les deux approches, car des termes précis tels que des codes de produit ou des messages d’erreur tirent encore parti de la correspondance avec des mots-clés.
Pourquoi c’est important pour les applications LLM
Les modèles donnent de bien meilleures réponses lorsqu’ils disposent d’un contexte pertinent. Une bonne récupération des informations mène donc directement à :
- une meilleure récupération des documents
LangChain ne met pas en œuvre lui-même la recherche vectorielle. Il s’intègre aux composants nécessaires : modèles d’embedding, bases de données vectorielles, outils de récupération et moteurs de recherche de similarité, tous exposés via des interfaces cohérentes.
De la question à la réponse pertinente en six étapes
Lorsque les documents deviennent recherchables, répondre à une question suit une séquence prévisible :
- L’utilisateur pose la question. Une question arrive en langue naturelle.
- La question est transformée en vecteur. Elle est convertie en un vecteur afin de pouvoir être comparée par son sens plutôt que par ses mots exacts.
- Le texte pertinent est récupéré. Le système obtient les extraits ou pages dont les vecteurs sont les plus proches.
- L’entrée est assemblée. Les extraits récupérés et la question originale sont combinés pour former l’instruction destinée au modèle.
- Le modèle la traite. L’instruction complète, incluant le contexte et la question, est envoyée au LLM.
- Une réponse fondée revient. Comme le modèle raisonne à partir du texte fourni plutôt que uniquement de sa mémoire, la réponse est plus précise et il est plus facile d’en retracer l’origine.
Chaque flèche dans cette liste représente un transfert de données entre des composants, et c’est précisément ce que LangChain est conçu pour gérer. Il simplifie le processus de récupération des données, enchaîne les étapes relatives aux prompts, gère la mémoire, injecte du contexte dans les prompts et orchestre les appels au modèle. Ce flux en six étapes constitue le cœur de tout système RAG. Si vous souhaitez en savoir davantage sur la récupération des données elle-même, notre article expliquant comment RAG récupère des connaissances fraîches sur demande en traite plus en détail.
L’architecture complète RAG
Les six étapes mentionnées ci-dessus partent du principe que les documents sont déjà indexés. Un système complet dispose de deux pipelines : l’un prépare les documents à l’avance, et l’autre répond aux requêtes sur demande.
Préparation des documents pour la recherche
Au préalable de toute question posée, chaque document doit être transformé en quelque chose qui puisse être recherché :
- Téléchargement. Le PDF est stocké, par exemple dans un bucket AWS S3.
- Chargement. Un chargeur de documents lit le fichier et extrait son texte pour l’intégrer au processus.
- Découpage. Un outil de découpage du texte divise ce dernier en segments ou pages plus petites. Cela est important car intégrer un livre entier sous forme d’un seul vecteur mélangerait tous ses sujets, et parce que les modèles disposent de fenêtres de contexte limitées.
- Incarnation vectorielle. Chaque segment est passé à travers un modèle d’incarnation vectorielle pour devenir un vecteur.
- Stockage. Les vecteurs, ainsi que le texte qu’ils représentent, sont enregistrés dans une base de données vectorielle.
À la fin de cette étape, le document est prêt à être consulté. Ce processus s’exécute généralement une fois par téléchargement, et non à chaque question posée.
Réponse à une requête
Lorsqu’une question arrive, le deuxième pipeline s’exécute :
- Incorporer la requête. La question est convertie en un vecteur à l’aide du même modèle d’incorporation, de sorte qu’elle se trouve dans le même espace que les fragments stockés.
- Recherche. Une recherche de similarité identifie les fragments les plus proches de la question.
- Récupérer le contexte. Ces fragments sont extraits de la base de données vectorielle.
- Créer le prompt. Le texte récupéré et la question de l’utilisateur sont combinés pour former un prompt système.
- Appeler le modèle. Le prompt final est envoyé à l’API du LLM.
- Répondre. Le modèle retourne une réponse basée sur le matériel récupéré.
Un détail qui complique les choses pour les débutants : la requête et les documents doivent être encodés avec le même modèle. Les vecteurs provenant de deux modèles d’encodage différents ne sont pas comparables, et les mélanger sans le savoir dégrade fortement la qualité de la récupération.
Ce que vous écrieriez normalement vous-même
Sans framework, une équipe qui développerait cela devrait gérer manuellement la gestion des prompts, la logique de récupération, l’injection de contexte, les chaînes à plusieurs étapes, la mémoire, les intégrations d’outils ainsi que l’orchestration qui les relie tous. Aucun de ces éléments n’est conceptuellement difficile, mais leur accumulation rend le code fortement dépendant d’un seul modèle et d’une seule base de données. Les abstractions réutilisables de LangChain pour chacun de ces aspects vous permettent de développer plus rapidement et de modifier des composants ultérieurement avec moins de réécriture.
Ce que le framework apporte
Quatre avantages ressortent à maintes reprises.
Les chaînes en tant que modèle de composition
Une chaîne de liens relie des étapes telles qu’un modèle de prompt, une appel au modèle et un analyseur de sortie en un seul flux de travail que vous pouvez exécuter, tester et réutiliser. Dans les versions actuelles, cela s’exprime à travers Runnables et LCEL, qui vous permettent de relier les composants entre eux.
Code indépendant du modèle
Puisque LangChain prend en charge les principaux fournisseurs de LLM via une interface commune, votre application n’est pas liée à un seul fournisseur. Changer de modèle devient alors une simple modification de configuration plutôt qu’une réécriture, ce qui est utile tant pour le contrôle des coûts que pour essayer de nouveaux modèles.
Un écosystème étendu
Le framework est fourni avec un grand nombre de composants et d’intégrations, ou bien se connecte à ceux-ci : chargeurs pour de nombreux types de fichiers, divers stockages vectoriels, fournisseurs d’embeddings et outils. La plupart de ce dont vous avez besoin existe probablement déjà sous forme d’intégration.
Mémoire et état
Les applications de conversation doivent se souvenir de ce qui a été dit précédemment. LangChain propose des moyens de gérer le contexte, la mémoire et l’état de la conversation au fil des interactions. L’approche recommandée a évolué au fil des versions, les nouvelles directives privilégiant LangGraph pour les workflows à état ; veuillez donc consulter la documentation actuelle correspondant à votre version.
Que vous pouvez créer avec cela
Les types d’applications courants incluent :
- Chatbots conversationnels, où les utilisateurs communiquent avec une intelligence artificielle en langage naturel.
- Aides à la connaissance, qui aident les gens à trouver et à comprendre des informations dans leurs propres documents ou bases de connaissances.
- Agents IA, qui accomplissent des tâches en plusieurs étapes et décident quels outils utiliser au fur et à mesure.
- Automatisation de workflows, où un LLM constitue une étape au sein d’un processus automatisé plus large.
Quand envisager une alternative
LangChain est l’une des nombreuses options, et chacune d’elles met l’accent sur des aspects différents :
- LlamaIndex se concentre fortement sur la connexion des LLM aux données externes ainsi que sur la création d’applications basées sur des données et du RAG.
- Haystack vise les recherches, la réponse aux questions, le RAG et les applications agnitives.
- Semantic Kernel est un SDK open source de Microsoft qui intègre des modèles d’IA dans des logiciels existants et coordonne des workflows d’IA en plusieurs étapes.
- DSPy traite les systèmes LLM comme des programmes à optimiser, plutôt que de vous demander de concevoir manuellement chaque prompt.
- AutoGen est conçu pour des applications où plusieurs agents collaborent et communiquent entre eux.
- CrewAI vise à coordonner des équipes d’agents travaillant ensemble sur des tâches.
- PydanticAI est un framework Python destiné aux applications en production et aux agents produisant des résultats structurés et sécurisés du point de vue des types.
Règle générale : si votre application consiste principalement en des opérations de récupération de données existantes, il vaut la peine de comparer LlamaIndex et Haystack. Si vous privilégiez des résultats avec des types définis, tournez-vous vers PydanticAI. Si vous souhaitez que la collaboration entre plusieurs agents soit l’idée centrale, AutoGen ou CrewAI conviennent. La force de LangChain réside dans sa polyvalence, ce qui en fait un choix raisonnable par défaut lorsque vous n’êtes pas encore sûr de la forme que prendra votre application. Pour une comparaison directe des deux options les plus courantes, consultez notre comparaison de LangChain et LlamaIndex.
Il est également utile de savoir quand il ne faut pas recourir à un framework. Une fonctionnalité basée sur une seule demande, ou un petit script comprenant une seule appel à un modèle et une prompt écrite manuellement, est souvent plus claire sans couche d’abstraction. Les frameworks deviennent utiles lorsque le nombre d’étapes et de composants interchangeables augmente.
Les éléments de base à apprendre ensuite
Avec une vision d’ensemble en place, l’étape suivante naturelle consiste à découvrir les composants individuels dont est constituée toute application LangChain :
- Modèles, les interfaces permettant de communiquer avec différents modèles d’IA.
- Prompts, qui déterminent la manière dont un modèle répond à ses entrées.
- Chaînes, qui relient les composants en workflows.
- Index, qui connectent les applications à des connaissances externes. La documentation plus récente a tendance à décrire cette zone en termes de chargeurs, de bases de données vectorielles et de récupérateurs.
Comprendre ce pour quoi chacun d’eux est responsable facilite grandement la lecture du code LangChain et permet de déterminer quels éléments votre propre application a réellement besoin.
Points clés
- Un système RAG se compose de deux pipelines : un pipeline hors ligne qui charge, divise, incorpore et stocke les documents, et un pipeline en ligne qui incorpore la requête, récupère le contexte, construit l’instruction et appelle le modèle.
- Il faut toujours utiliser le même modèle pour incorporer les requêtes et les documents, sinon la qualité de la récupération diminue fortement.
- Les principaux avantages de LangChain sont la composition basée sur des chaînes, l’indépendance vis-à-vis des fournisseurs, un écosystème d’intégration étendu ainsi que des outils pour gérer l’état et la mémoire.
- Des alternatives telles que LlamaIndex, Haystack, Semantic Kernel, DSPy, AutoGen, CrewAI et PydanticAI mettent chacune l’accent sur des aspects différents, et une fonctionnalité très simple peut ne nécessiter aucun framework du tout.
Lectures complémentaires
- Cartographier RAG : étapes du pipeline, composants clés et paysage des variantes — Comprendre le fonctionnement complet de la génération augmentée par la récupération d’informations, quels composants nécessite un système RAG, et comment les nombreuses variantes de RAG s’intègrent dans une même représentation.
- RAG expliqué : comment les systèmes d’IA récupèrent des connaissances fraîches sur demande — Apprendre le fonctionnement de la génération augmentée par la récupération d’informations, du découpage des données et de leur encodage en vecteurs à la recherche vectorielle, afin que les modèles d’IA puissent répondre aux questions sans avoir à être réentraînés.