bRAG-langchain : cinq notebooks pour comprendre la RAG par la pratique

Un support pédagogique, pas une dépendance

Le dépôt se présente comme une exploration de la génération augmentée par récupération, répartie sur plusieurs notebooks. Le fichier full_basic_rag.ipynb est décrit comme un code de départ pour un chatbot RAG entièrement personnalisable. C'est le point d'entrée que le README recommande si l'on veut aller droit au but. Le reste, sous le répertoire notebooks/, déroule cinq étapes numérotées. Le public visé est donc un développeur Python qui veut manipuler les composants d'un pipeline RAG et voir ce que chaque variante change, plutôt qu'une équipe qui cherche une bibliothèque à ajouter à un requirements.txt. Cette distinction compte : rien dans le matériel fourni n'indique une API publiée, une version sémantique ou des tests automatisés. Vous lisez du code, vous l'exécutez, vous l'adaptez.

Ce que chaque notebook construit réellement

Le premier notebook, [1]_rag_setup_overview.ipynb, pose la fondation : configuration de l'environnement, chargement de documents, génération d'embeddings (dont ceux d'OpenAI), stockage vectoriel via ChromaDB ou Pinecone, puis un pipeline de récupération et de génération servant de référence. Le deuxième, [2]_rag_with_multi_query.ipynb, introduit la reformulation en plusieurs requêtes pour diversifier la récupération, avec plusieurs modèles d'embeddings et une comparaison face au pipeline mono-requête. Le troisième, [3]_rag_routing_and_query_construction.ipynb, ajoute deux formes de routage : logique, par fonctions qui classent la requête selon le langage de programmation, et sémantique, par similarité cosinus qui oriente vers un prompt de mathématiques ou de physique. Il construit aussi un schéma de recherche structuré pour des métadonnées de tutoriels YouTube, avec filtrage par nombre de vues ou date de publication. Le quatrième, [4]_rag_indexing_and_advanced_retrieval.ipynb, monte en finesse : indexation multi-représentation, stockage des résumés dans un InMemoryByteStore aux côtés des documents parents, MultiVectorRetriever, implémentation de RAPTOR, puis ColBERT avec un exemple consacré à Hayao Miyazaki. Le cinquième, [5]_rag_retrieval_and_reranking.ipynb, referme la boucle avec RAG-Fusion, la fusion de rangs réciproque (RRF), le re-classement Cohere, et des liens vers CRAG et Self-RAG.

Le fil conducteur : récupérer, fusionner, re-classer

La progression n'est pas une simple liste de sujets. Elle suit une logique de qualité de récupération. On part d'une recherche par similarité sur un index unique, on diversifie les requêtes, on route vers la bonne source, on indexe plusieurs représentations d'un même document, puis on fusionne et re-classe les listes de résultats. La RRF, telle que le notebook 5 la décrit, sert à combiner plusieurs listes de rangs en une seule. Le re-classement Cohere intervient après, pour affiner et compresser le contexte transmis au modèle. Le notebook 4 montre l'inverse en amont : au lieu d'améliorer le classement, on enrichit l'index, par exemple en stockant un résumé à côté du document parent et en interrogeant les deux. Ce sont deux réponses différentes au même problème, et le dépôt ne tranche pas à votre place. Il expose les mécanismes et renvoie à des ressources externes pour RAPTOR, CRAG et Self-RAG, ce qui signifie que ces trois-là ne sont pas implémentés de bout en bout dans le matériel fourni.

Mise en route : Python 3.11.11 et environnement virtuel

Le README insiste sur Python 3.11.11, présenté comme la version préférée. Sur macOS, il passe par Homebrew avec brew install python@3.11, puis python3.11 --version pour vérifier. Sur Linux, sudo apt install python3.11 python3.11-venv. Sur Windows, l'installateur de python.org avec la case Add Python to PATH cochée. Ensuite : git clone https://github.com/bRAGAI/bRAG-langchain.git, cd bRAG-langchain, puis python3.11 -m venv venv et l'activation via source venv/bin/activate ou venv\Scripts\activate. Le README prévoit un cas gênant : si l'environnement virtuel bascule sur une autre version, par exemple Python 3.13, il propose de créer un lien symbolique avec ln -sf $(which python3.11) $(dirname $(which python))/python. Ce contournement est un signe que la contrainte de version n'est pas anodine. Le matériel ne détaille pas de fichier de dépendances ni de commande d'installation unique, donc prévoyez de repérer vous-même les imports dans chaque notebook.

Ce que le dépôt ne fournit pas

La licence est enregistrée comme NOASSERTION. Concrètement, GitHub n'a pas pu la classer dans une catégorie reconnue, et le matériel transmis ne contient pas de texte de licence. Avant toute réutilisation de code dans un projet distribué, il faut lire le fichier LICENSE du dépôt et, en cas d'ambiguïté, demander un avis juridique. Ce n'est pas un détail : une licence non standard peut restreindre la redistribution ou l'usage commercial. Autre limite, plus structurelle : un notebook n'est pas un artefact versionné. Il n'y a aucune release récupérée, donc pas de point de comparaison entre deux états du code. Si vous copiez le pipeline du notebook 5 dans une application, vous emportez aussi les appels à des services externes (embeddings OpenAI, re-classement Cohere, Pinecone en option) et leurs coûts. Le dépôt ne documente pas de stratégie de repli si l'un de ces services change d'API.

Face à un framework RAG packagé

L'alternative évidente est un framework qui expose la RAG comme une abstraction installable, avec des classes stables et une documentation de référence, plutôt qu'une suite de notebooks. LlamaIndex en est un exemple courant : il fournit des objets réutilisables pour l'indexation et la requête, là où bRAG-langchain vous fait écrire et lire chaque étape. La différence n'est pas la couverture fonctionnelle, elle est dans le contrat. Avec un framework, vous dépendez d'une API qui évolue selon un calendrier de versions. Avec ces notebooks, vous dépendez de votre propre copie du code, que vous pouvez figer et modifier librement, mais que personne ne maintiendra pour vous. Le choix dépend de ce que vous voulez apprendre : le fonctionnement interne d'un pipeline, ou la vitesse de mise en production d'un service.

Coût de maintenance et de mise à jour

Le dernier push enregistré date du 3 août 2026 et le dépôt n'est pas archivé. Le README mentionne un site, bragai.dev, annoncé comme « launching soon », ce qui suggère un projet encore en mouvement. Aucune release n'a été récupérée, donc vous ne pouvez pas épingler une version et suivre un journal de changements. En pratique, cela veut dire que la mise à jour se fait par git pull et par réexécution des notebooks, avec le risque que des cellules cassent si une bibliothèque change de signature. La contrainte Python 3.11.11 ajoute une couche : tant que vous restez sur cette version, vous êtes aligné avec ce que le README décrit. Au-delà, rien n'est garanti par le matériel fourni.

Conclusion éditoriale

À adopter si vous voulez comprendre la RAG en lisant et modifiant du code exécutable, notebook après notebook, avec LangChain comme fil conducteur. À éviter si vous cherchez une brique à installer dans un service : il n'y a ni paquet, ni API stable, ni tests. Avant de vous engager, ouvrez full_basic_rag.ipynb, vérifiez quelles clés d'API et quels magasins de vecteurs y sont référencés, et confirmez que votre environnement est bien en Python 3.11.11, car tout le reste du parcours en dépend.

Sources officielles

1. bragai/bRAG-langchain on GitHub
2. Issues
3. Project website
4. README