RAGHub : un annuaire communautaire pour choisir une brique RAG

Un annuaire, pas une bibliothèque

RAGHub ne s'installe pas. Le dépôt se présente comme une collection de frameworks, projets et ressources liés au Retrieval-Augmented Generation, organisée pour le subreddit r/RAG. Le README annonce l'intention : cataloguer la croissance rapide des outils RAG, parce que, selon ses auteurs, chaque jour semble apporter un nouveau framework et que le choix devient plus un art qu'une science.

Le public visé est donc l'ingénieur ou l'architecte qui doit trancher entre plusieurs options et veut une vue d'ensemble avant d'engager du temps. Le README pose la question qui motive le projet : le framework d'il y a trois mois est-il encore pertinent, ou était-ce de l'enthousiasme autour de concepts anciens rhabillés ? C'est une question de veille, pas d'implémentation. Le dépôt y répond par des listes, pas par du code.

Ce que contiennent réellement les tableaux

Le README expose une table des matières qui découpe le contenu en sections : RAG Frameworks, RAG Evaluation and Optimization Frameworks, RAG Engines, FAQ, RAG Resources and Sites, Model LeaderBoards, License, Join the Conversation. Chaque section prend la forme d'un tableau Markdown dont les colonnes observables sont Name, Description, Website, Github, Stars et Activity.

La colonne Stars contient un badge shields.io pointant vers le dépôt GitHub de l'outil listé, et Activity affiche une fraîcheur relative, par exemple 1h ago, 9h ago ou 1d ago. Deux entrées visibles dans l'extrait illustrent l'éventail : LangChain, décrit comme servant à construire des applications avec des LLM, et Scout, orienté applications avec LLM, bases vectorielles et scraping web. La FAQ joue un rôle de guide : elle distingue les frameworks, bibliothèques que l'on intègre dans son code, des moteurs, plateformes autonomes prêtes à l'emploi, et cite RAGFlow et Dify comme exemples de moteurs.

La FAQ comme grille de décision

La partie la plus opérationnelle du dépôt n'est pas l'annuaire mais la FAQ. Elle propose un tableau de critères de sélection : cas d'usage (chatbot, moteur de recherche, questions-réponses documentaire), échelle (entreprise contre prototypage), complexité (LangChain et LlamaIndex présentés comme complets, LightRAG comme simple), intégration (prise en charge de la base vectorielle et du fournisseur de LLM) et langage (Python, TypeScript, Rust).

Elle traite aussi deux points souvent mal anticipés. Sur les bases vectorielles, elle affirme qu'elles sont nécessaires pour stocker les embeddings et distingue ChromaDB pour le prototypage, Qdrant pour la production, Pinecone comme service managé et Weaviate pour la recherche hybride. Sur les modèles locaux, elle liste Ollama, vLLM, LM Studio et LocalAI. Enfin, elle associe des problèmes courants à des pistes : qualité de récupération faible, limites de fenêtre de contexte, hallucinations, latence. Ces tableaux restent des résumés, sans chiffres ni protocole.

Contribuer : fork, tableau, pull request

La procédure décrite est volontairement minimale. Le README indique de forker le dépôt, d'ajouter l'entrée dans la section pertinente, de respecter le format de tableau existant, puis de soumettre une pull request, avec CONTRIBUTING.md comme référence détaillée. Aucune commande d'installation, aucun script de génération, aucun fichier de configuration n'est mentionné dans le matériel fourni.

Ce choix a une conséquence directe : la qualité de l'annuaire dépend entièrement de la discipline des contributeurs et des relecteurs. Rien dans le matériel ne décrit de validation automatique des liens, de schéma de données ni de test qui échouerait si une colonne manquait. Le format Markdown est le seul contrat, et il est vérifié à l'œil.

Limites : listes, badges et fraîcheur

La première limite est structurelle. Un tableau Markdown avec des colonnes Name, Description, Website, Github et Activity n'est pas une base de données interrogeable. Il n'existe pas, d'après le matériel, de champ normalisé pour la licence de chaque outil listé, la version minimale de Python, le fournisseur de LLM supporté ou la base vectorielle compatible. Ces informations restent dans la prose des descriptions, quand elles y sont.

La deuxième limite tient à la preuve d'activité. La colonne Activity affiche des durées relatives comme 1h ago ou 1d ago, et la colonne Stars un badge dynamique. Ces deux indicateurs mesurent la popularité et la récence, pas la qualité ni la compatibilité avec votre cas. Un projet très étoilé peut être inadapté à un besoin de recherche hybride, et un projet actif peut avoir une API instable. Le dépôt ne fournit ni benchmark exécutable ni jeu de données de comparaison, ce que le README reconnaît indirectement en parlant d'un choix qui relève de l'art.

Troisième limite : le rythme de mise à jour du dépôt lui-même. La date de dernier push figure dans les métadonnées, mais rien ne garantit que chaque ligne d'un tableau a été revue à cette date. Une entrée peut pointer vers un dépôt archivé sans que l'annuaire le signale.

Alternatives : annuaire contre framework

La comparaison pertinente n'est pas RAGHub contre un autre annuaire, mais RAGHub contre un framework comme LangChain ou LlamaIndex, tous deux listés dans le dépôt. La différence de nature est nette : LangChain et LlamaIndex sont des bibliothèques que l'on installe et que l'on appelle depuis son code pour construire un pipeline ; RAGHub est un fichier README que l'on lit. L'un produit des embeddings et des appels de modèle, l'autre produit des liens.

Si votre besoin est de savoir quelle base vectorielle convient au prototypage, la FAQ de RAGHub oriente vers ChromaDB. Si votre besoin est de construire la chaîne de récupération, il faut ouvrir la documentation de la bibliothèque choisie, pas l'annuaire. Utiliser RAGHub comme substitut à une documentation d'API mène à une impasse : aucun exemple de code n'y figure, et le matériel ne montre aucune commande d'installation pour le dépôt lui-même.

Licence, maintenance et coût de suivi

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution du contenu textuel, sous réserve de conserver la notice de licence. Cette licence couvre le dépôt RAGHub, pas les projets qu'il référence : chacun a la sienne, et l'annuaire n'expose pas, dans le matériel fourni, de colonne dédiée à ce sujet. Vérifier la licence d'un outil listé demande donc d'ouvrir son propre dépôt.

Le coût de maintenance se lit à deux niveaux. Pour les mainteneurs, chaque nouvelle entrée est une pull request à relire, et chaque lien mort une correction manuelle. Pour l'utilisateur, le coût est celui de la vérification : un tableau ne se périme pas tout seul, mais ses lignes vieillissent à des rythmes différents. Il n'existe pas, d'après le matériel, de flux de publication ni de version taguée qui permettrait de figer un état de l'annuaire à une date donnée. La seule référence temporelle disponible est la date de dernier push du dépôt et la colonne Activity, ligne par ligne. Ce n'est pas un mécanisme de versionnage.

Conclusion éditoriale

RAGHub convient à qui doit cadrer un paysage d'outils RAG avant de coder, et à qui veut proposer une entrée via une pull request suivant le format des tableaux existants. Il ne convient pas à qui cherche une bibliothèque à installer, un benchmark reproductible ou une garantie de maintenance par un éditeur. Avant de s'appuyer dessus, vérifier la date du dernier commit sur l'entrée visée, ouvrir le lien GitHub correspondant et confirmer que le projet est encore actif, puis lire CONTRIBUTING.md pour connaître le format attendu si vous comptez contribuer.

Sources officielles

1. Andrew-Jang/RAGHub on GitHub
2. Issues
3. License: MIT
4. README