all-in-rag : un cursus RAG en dix chapitres, pas une bibliothèque

Un cours, pas un paquet

La confusion la plus fréquente devant ce dépôt vient de son nom. all-in-rag ne s'installe pas comme une dépendance et n'expose pas d'API à appeler depuis votre code. Le README le présente comme un tutoriel technique destiné aux développeurs d'applications à base de grands modèles, avec un parcours d'apprentissage et des projets pratiques. Le langage principal déclaré est Python, mais le livrable réel est un ensemble de fichiers Markdown organisés en chapitres, publiés en ligne sur une page GitHub Pages.

Le problème visé est explicite dans le README : les tutoriels RAG existants seraient dispersés et manqueraient de systématicité, ce qui empêche un débutant de se construire une vision complète. Le public annoncé est précis : développeurs avec des bases en Python, ingénieurs IA, développeurs produit voulant construire un système de questions-réponses, chercheurs. Les prérequis listés sont Python, une utilisation simple de docker, une connaissance basique des LLM présentée comme recommandée mais non obligatoire, et des bases en ligne de commande Linux.

Cette définition du public est cohérente avec le format. Un lecteur qui sait déjà écrire une chaîne de récupération en production n'y trouvera pas de quoi optimiser son système. Un lecteur qui n'a jamais touché à Python sera bloqué dès le premier chapitre. La zone utile est intermédiaire.

Ce que le plan couvre chapitre par chapitre

La table des matières du README est le document le plus informatif du dépôt. Elle se découpe en cinq parties.

La première partie pose les bases : introduction au RAG, préparation de l'environnement, puis une construction en quatre étapes, avec un complément sur le déploiement d'un environnement virtuel Python. Le chapitre 2 traite le chargement de données multi-formats et le découpage de texte.

La deuxième partie construit l'index : embeddings de texte, embeddings multimodaux pour le couple image-texte, bases de données vectorielles, puis une pratique dédiée à Milvus et un chapitre d'optimisation d'index. La troisième partie monte d'un cran sur la récupération : recherche hybride combinant dense et sparse, construction de requêtes, Text2SQL pour convertir une question en requête SQL, réécriture et distribution de requêtes, et techniques de récupération avancées.

La quatrième partie couvre la génération formatée et l'évaluation, avec une introduction méthodologique puis un chapitre sur les outils et métriques courants. La cinquième partie contient les projets : un chapitre sur le RAG fondé sur un graphe de connaissances, un projet complet en quatre étapes (environnement et architecture, préparation des données, index et récupération, intégration de la génération), puis un chapitre d'optimisation orienté Graph RAG avec conception d'architecture, modélisation des données de graphe, construction d'index Milvus et routage intelligent des requêtes.

Le chapitre 10 est marqué comme en cours de planification. Deux contributions externes figurent dans un dossier Extra-chapter : une application simple de Neo4J et une pratique d'embedding multimodal Omni avec Jina v5-omni, cette dernière indiquée comme en cours d'optimisation.

La pile technique citée, et ce qu'elle implique

Les sujets associés au dépôt nomment les briques attendues : langchain, llama-index, milvus, neo4j, embedding, multimodal, deepseek, kimi-k2. Le README confirme plusieurs de ces choix par le plan lui-même : Milvus apparaît deux fois (chapitre 3 pour la pratique multimodale, chapitre 9 pour la construction d'index dans le cadre Graph RAG), Neo4j apparaît via le chapitre sur le RAG à base de graphe de connaissances et via l'Extra-chapter dédié.

Le point notable est la présence de deux frameworks concurrents, LangChain et LlamaIndex, dans les sujets déclarés. Le README ne tranche pas explicitement en faveur de l'un ou de l'autre dans les extraits fournis, et il faut lire les chapitres concernés pour savoir lequel est utilisé à quel endroit. Cette double présence peut être un atout pédagogique, puisque le lecteur voit deux approches, ou une source de confusion si les mêmes concepts sont réimplémentés deux fois avec des abstractions différentes.

Autre signal : l'ouverture au multimodal n'est pas décorative. Un chapitre entier traite des embeddings image-texte, et une contribution externe porte sur un modèle d'embedding Omni. Cela place le dépôt au-delà du RAG strictement textuel, ce qui reste plus rare dans les supports d'introduction.

En revanche, le README ne fournit pas de fichier de dépendances dans l'extrait disponible, ni de version épinglée pour Milvus ou Neo4j. Le badge indique Python 3.12.7, ce qui est une version précise, mais on ne peut pas en déduire que tous les chapitres fonctionnent sur cette seule version.

Mise en route : ce que le dépôt demande réellement

Le README ne donne pas de commande d'installation unique. Il renvoie vers des chapitres dédiés : 02_preparation.md pour la configuration de l'environnement, virtualenv.md pour le déploiement d'un environnement virtuel Python, puis 03_get_start_rag.md pour la construction en quatre étapes. C'est une différence pratique importante avec un projet bibliothèque, où l'on attend un pip install reproductible en une ligne.

Concrètement, le lecteur doit donc ouvrir la documentation en ligne ou cloner le dépôt pour lire les fichiers Markdown, puis suivre les instructions chapitre par chapitre. Les prérequis annoncés incluent une utilisation simple de docker, ce qui suggère que certains chapitres reposent sur des services conteneurisés, vraisemblablement pour Milvus et Neo4j, mais le README ne détaille pas les images ni les commandes correspondantes dans l'extrait fourni.

Deux points restent à vérifier dans les chapitres eux-mêmes. D'abord les clés d'API : le plan mentionne des modèles nommés (deepseek, kimi-k2 dans les sujets), et un chapitre sur la génération formatée suppose un accès à un modèle. Le dépôt ne documente pas, dans les éléments disponibles, de mécanisme de configuration unifié pour ces accès. Ensuite la version de Python : le badge pointe 3.12.7, mais l'absence de fichier de dépendances visible empêche de savoir si chaque chapitre est testé sur cette version ou si certains sont plus anciens.

Le projet fil rouge et le chapitre qui n'existe pas encore

Le chapitre 8 est la pièce centrale pour un lecteur qui veut construire quelque chose plutôt que lire. Il est découpé en quatre fichiers : 01_env_architecture.md, 02_data_preparation.md, 03_index_retrieval.md, 04_generation_sys.md. Cette progression reproduit exactement le pipeline RAG, de l'architecture au système de génération en passant par les données et l'index. C'est le seul endroit du plan où l'on voit un projet assemblé de bout en bout, et c'est probablement là qu'un lecteur jugera si le support tient ses promesses.

Le chapitre 9 est présenté comme une optimisation du projet précédent, en option. Il introduit une architecture Graph RAG, avec modélisation des données de graphe, index Milvus et routage de requêtes. Le README renvoie vers un projet externe hébergé sur un autre dépôt GitHub comme démonstration. Cela signifie que le code de démonstration n'est pas dans all-in-rag lui-même, ce qui complique la vérification de la cohérence entre le texte et l'implémentation.

Le chapitre 10, projet pratique numéro deux, est explicitement marqué comme en cours de planification. Un lecteur qui parcourt le plan du début à la fin et s'attend à un second projet complet doit donc savoir qu'il n'est pas encore disponible. C'est une limite de complétude, pas un défaut de conception, mais elle mérite d'être connue avant de planifier un parcours d'apprentissage fondé sur ce dépôt.

Comparer avec autre chose qu'un cours

La comparaison la plus utile n'est pas entre all-in-rag et un autre dépôt de cours, mais entre all-in-rag et une documentation de référence d'outil. Prenons Milvus, que le dépôt utilise et documente. La documentation officielle de Milvus décrit l'API, les types d'index, les paramètres de recherche et les limites de la base elle-même. all-in-rag décrit quand et pourquoi utiliser tel type d'index dans un pipeline RAG, avec un exemple de recherche multimodale. Les deux sont complémentaires, mais ils ne répondent pas à la même question.

Le même écart existe face à LangChain ou LlamaIndex. Ces projets fournissent des abstractions exécutables : on importe un module, on appelle une fonction, on obtient un résultat. all-in-rag fournit une explication de ce que ces abstractions font et de la façon de les assembler. Un ingénieur qui doit déboguer un retrieval qui renvoie de mauvais passages n'a pas besoin d'un chapitre sur la recherche hybride : il a besoin de la référence de l'API du magasin vectoriel qu'il utilise. Inversement, quelqu'un qui ne comprend pas pourquoi la recherche hybride existe lira le chapitre 4 avec profit.

Cette distinction compte parce qu'elle détermine la façon d'utiliser le dépôt. On ne l'ajoute pas à un fichier de dépendances. On le lit, on prend des notes, on adapte les extraits de code à son propre contexte.

Licence, maintenance et coût de suivi

La licence n'est pas indiquée dans les métadonnées fournies, et le README ne comporte pas de section licence dans l'extrait disponible. C'est un point à éclaircir avant toute réutilisation de code ou de texte, en particulier pour un usage en entreprise. Sans identifiant de licence explicite, on ne peut pas affirmer que le contenu est réutilisable, ni sous quelles conditions. Je ne peux que constater l'absence d'information, pas la qualifier.

Sur la maintenance, le dépôt n'est pas archivé et le dernier push date du 4 septembre 2026. Le plan montre un chapitre 10 en planification et une contribution externe en cours d'optimisation, ce qui indique une activité éditoriale continue. Aucune release n'a été récupérée, ce qui est cohérent avec un projet de documentation : il n'y a pas de version publiée à épingler, donc pas de point de référence stable pour dire « ce chapitre correspond à cette version ».

Le coût d'usage est ailleurs. Suivre ce cursus implique de faire tourner Milvus et probablement Neo4j, donc des conteneurs, et d'appeler des modèles de génération et d'embedding, donc des clés d'API et une facturation à l'usage. Le README mentionne docker dans les prérequis mais ne chiffre rien. Pour un lecteur qui veut seulement comprendre les concepts, la lecture de la documentation en ligne suffit et ne coûte rien. Pour un lecteur qui veut exécuter le projet du chapitre 8, il faut prévoir l'infrastructure correspondante.

Conclusion éditoriale

À adopter si vous cherchez un parcours ordonné pour apprendre le RAG en Python et que vous acceptez de lire du contenu majoritairement chinois : le plan couvre le découpage, les embeddings, Milvus, la recherche hybride et l'évaluation, avec un projet fil rouge. À éviter si vous cherchez une bibliothèque à importer, un paquet publiable ou une base de code à maintenir en production : ce dépôt est un support pédagogique, et le README ne présente aucune API stable. Avant de vous engager, vérifiez trois points concrets : la licence du dépôt, qui n'est pas indiquée dans les métadonnées fournies ; la version de Python réellement requise par les fichiers de dépendances, le badge annonçant 3.12.7 ; et l'état du chapitre 10, marqué comme en cours de planification dans le README.

Sources officielles

1. datawhalechina/all-in-rag on GitHub
2. Issues
3. Project website
4. README