agentic-rag-for-dummies : un RAG agentique modulaire en LangGraph, pensé comme support d'apprentissage
A modular Agentic RAG built with LangGraph — learn Retrieval-Augmented Generation Agents in minutes.
En bref
- De quoi s’agit-il ?
- Le dépôt de GiovanniPasq propose deux parcours dans un même projet : un notebook Colab pour comprendre les concepts, et une application modulaire Ollama-first avec indexation hiérarchique, clarification de requête et agents parallèles. Voici ce que la documentation décrit, et où elle reste muette.
- À qui s’adresse-t-il ?
- Ce dépôt convient à un développeur qui veut lire puis modifier un pipeline RAG agentique complet plutôt qu'assembler des briques depuis des tutoriels dispersés. Il ne convient pas si vous cherchez un service de recherche documentaire prêt pour la production : la documentation ne décrit ni stratégie de sauvegarde Qdrant, ni gestion des secrets, ni procédure de migration d'index.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 17 jours.
- En quel langage est-il écrit ?
- Principalement Jupyter Notebook, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le manque que le dépôt prétend combler
La plupart des tutoriels RAG s'arrêtent au schéma classique : découper, vectoriser, rechercher, générer. Le README formule le problème ainsi : ces tutoriels montrent les concepts de base mais ne guident pas vers des systèmes modulaires pilotés par un agent. Le public visé est donc précis. D'un côté un développeur qui a déjà bricolé un pipeline naïf et bute sur les questions de contexte, de reformulation et de correction automatique. De l'autre un lecteur qui veut comprendre LangGraph sur un cas concret plutôt que sur un exemple jouet. Le dépôt assume cette double cible avec deux parcours explicites : un notebook interactif pour l'apprentissage, un projet modulaire pour la construction. C'est un choix éditorial qui a un coût, car maintenir deux chemins cohérents dans un même dépôt demande plus de discipline qu'un seul exemple linéaire.
Indexation hiérarchique : deux découpages pour deux usages
Le mécanisme central côté préparation documentaire est un découpage en deux niveaux. Les Parent Chunks sont de grandes sections délimitées par les en-têtes Markdown H1, H2 et H3. Les Child Chunks sont de petits fragments de taille fixe dérivés de ces parents. La recherche s'effectue sur les enfants, ce qui donne la précision ; la génération reçoit les parents, ce qui restitue le contexte. Cette séparation répond à une tension réelle : un fragment court améliore le rappel vectoriel mais prive le modèle de l'information environnante. Le README mentionne Chunky, un outil distinct du même auteur, pour convertir des PDF en Markdown, nettoyer les documents et inspecter les découpages. Ce point mérite attention : la chaîne d'ingestion repose sur du Markdown structuré. Un corpus de PDF scannés ou de pages HTML mal balisées produira des parents mal délimités, et donc une perte de contexte que le modèle ne pourra pas compenser.
Le flux de requête en quatre étages
Le README décrit une séquence explicite : requête utilisateur, résumé de conversation, réécriture, clarification, raisonnement d'agents parallèles, agrégation, réponse finale. Le premier étage maintient un résumé glissant et un historique récent, ce qui évite que le contexte croisse indéfiniment au fil des échanges. Le deuxième résout les références implicites (le README donne l'exemple de « Comment le mettre à jour ? » devenant « Comment mettre à jour SQL ? »), découpe les questions composées et détecte les entrées ambiguës. C'est ici qu'intervient le human-in-the-loop : le système met la pause et demande une précision. Le troisième étage lance un sous-graphe d'agent par sous-requête, en parallèle. Chaque agent cherche dans les fragments enfants, récupère les parents correspondants, se corrige si les résultats sont insuffisants, compresse le contexte et abandonne proprement lorsque le budget de recherche est épuisé. Le quatrième agrège le tout. L'exemple du README est parlant : « Qu'est-ce que JavaScript ? Qu'est-ce que Python ? » déclenche deux agents simultanés. Le pattern map-reduce est donc appliqué à la décomposition de requête, pas à un traitement de corpus.
Choix du modèle : la contrainte la plus dure du projet
L'application exécutable est Ollama-first. La commande d'installation du modèle est donnée telle quelle : ollama pull granite4.1:8b, avec une initialisation ChatOllama(model="granite4.1:8b", temperature=0, seed=42). Le README avertit sans détour : pour un appel d'outil et un suivi d'instruction fiables, préférez des modèles de 8B et plus ; les plus petits peuvent ignorer les instructions de récupération ou halluciner. Cette mise en garde est la contrainte opérationnelle dominante du dépôt. Un système agentique qui doit décider quand chercher, quand reformuler et quand s'arrêter dépend entièrement de la capacité du modèle à produire des appels structurés. Le projet est annoncé comme agnostique du fournisseur, avec des exemples pour Anthropic, OpenAI et Google via les intégrations LangChain, mais la documentation fournie ne va pas au-delà de l'amorce d'initialisation. Le README note d'ailleurs que les noms de modèles changent souvent et renvoie à la documentation officielle de chaque fournisseur.
Ce que la documentation ne dit pas
Plusieurs zones restent floues à la lecture du matériel fourni. La persistance n'est pas traitée : le dépôt s'appuie sur Qdrant comme base vectorielle, mais rien n'indique comment l'index est sauvegardé, versionné ou reconstruit après un changement de modèle d'embedding. Or un changement d'embedding invalide l'index entier, et c'est le type de migration que l'on découvre trop tard. La gestion des secrets n'est pas documentée non plus : l'exemple OpenAI du README s'arrête sur une ligne tronquée autour de os.environ["OPENAI_API_KEY"], sans montrer de fichier .env ni de configuration centralisée. Le coût d'un passage en cloud n'est pas chiffré, ce qui est compréhensible mais laisse l'utilisateur seul face à l'arbitrage entre latence locale et qualité de raisonnement. Enfin, le dépôt est majoritairement composé de notebooks Jupyter. Les notebooks se lisent bien et se testent mal : pas de suite de tests visible dans le matériel fourni, donc toute modification de l'orchestration LangGraph repose sur une vérification manuelle.
Alternatives et différence d'approche
L'alternative la plus directe est d'écrire soi-même le graphe avec LangGraph, en suivant la documentation officielle de la bibliothèque. La différence n'est pas la technologie employée, c'est ce que le dépôt apporte en plus : une décomposition déjà arbitrée en quatre étages, un découpage parent/enfant opérationnel, et un jeu de fonctionnalités listées dans le README (mémoire conversationnelle, clarification de requête, map-reduce multi-agents, auto-correction, compression de contexte, observabilité Langfuse, évaluation RAGAS). Reproduire cet ensemble depuis zéro demande de trancher chaque question de conception avant d'écrire la première ligne. À l'inverse, un cadre plus intégré comme LlamaIndex propose une abstraction de plus haut niveau sur l'indexation et les moteurs de requête, avec moins de contrôle visible sur le graphe d'exécution. Le choix se joue là : agentic-rag-for-dummies expose le graphe, ce qui est formateur et modifiable, mais vous laisse responsable de la robustesse de chaque nœud.
Maintenance, versionnage et licence
Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un produit commercial, à condition de conserver l'avis de copyright et le texte de licence. Ce n'est pas un avis juridique : vérifiez les implications pour votre contexte, notamment si vous redistribuez le code sous forme de bibliothèque. Côté rythme, les versions fournies montrent v2.1 en avril 2026, v2.2 en juin, v2.3 en juin également, et un dernier push en août 2026. Le projet n'est pas archivé. Le README signale lui-même que LangGraph est attendu en version 1.2 ou supérieure et Python en 3.11 ou plus, ce qui signifie que suivre les mises à jour de LangGraph fait partie du coût d'usage : les API de graphe et de points de contrôle évoluent, et un notebook pédagogique qui prend du retard perd sa valeur d'exemple. Prévoir de relire les notebooks à chaque montée de version majeure est plus réaliste que de supposer une compatibilité ascendante sans friction.
Conclusion éditoriale
Ce dépôt convient à un développeur qui veut lire puis modifier un pipeline RAG agentique complet plutôt qu'assembler des briques depuis des tutoriels dispersés. Il ne convient pas si vous cherchez un service de recherche documentaire prêt pour la production : la documentation ne décrit ni stratégie de sauvegarde Qdrant, ni gestion des secrets, ni procédure de migration d'index. Avant d'adopter, vérifiez trois choses concrètes : la version de LangGraph réellement résolue par pip, le comportement de votre modèle Ollama sur l'appel d'outil, et la façon dont le script d'ingestion découpe vos propres documents Markdown, puisque l'indexation parent dépend des en-têtes H1, H2 et H3.
Notes de la communauté