UltraRAG : orchestrer des pipelines RAG en YAML via MCP

Le problème visé : recâbler un RAG à chaque expérience

Un pipeline RAG qui fonctionne en démonstration devient vite un ensemble de scripts où le retriever, le reranker et le générateur sont appelés dans un ordre codé en dur. Changer une étape, ajouter une branche conditionnelle ou tester une boucle de reformulation oblige à rouvrir le code et à retoucher plusieurs fichiers. La documentation d'UltraRAG présente l'outil comme un cadre de développement RAG léger fondé sur le Model Context Protocol, où les composants (Retriever, Generation, etc.) sont standardisés en serveurs MCP indépendants et où le client MCP assure l'orchestration. Le public visé est explicite dans le README : l'exploration en recherche et le prototypage industriel. Autrement dit, des personnes qui veulent essayer plusieurs combinaisons de composants sans réécrire l'application à chaque fois, et qui acceptent en échange de décrire leur logique dans un format de configuration.

Serveurs MCP atomiques, client MCP comme chef d'orchestre

L'architecture décrite dans le README sépare deux rôles. D'un côté, chaque fonction RAG est exposée comme un serveur MCP distinct : le README prend l'exemple de Retriever et Generation, et indique que de nouvelles fonctions s'enregistrent comme des Tools au niveau fonction, ce qui les rend réutilisables d'un pipeline à l'autre. De l'autre, le client MCP porte la logique de contrôle : séquence, boucle, branchement conditionnel. Le point important est que cette logique ne vit pas dans du Python applicatif mais dans un fichier YAML. Le README affirme que des dizaines de lignes de configuration suffisent pour exprimer une logique RAG itérative. Le flux de données suit donc un chemin indirect : le client interprète le YAML, décide quel serveur appeler, transmet les entrées, récupère les sorties, puis les réinjecte dans l'étape suivante. Ce découpage a une conséquence pratique : un serveur peut être remplacé ou dupliqué sans toucher au reste, mais toute la sémantique du pipeline devient dépendante de la façon dont le client MCP interprète la configuration. Le README ne détaille pas cette couche d'interprétation, et c'est précisément là que se logent les surprises quand un branchement ne se comporte pas comme prévu.

Interface de construction : canvas, code et assistant

UltraRAG UI est présenté comme un environnement de développement visuel pour le RAG, et non comme une simple fenêtre de chat. Le README mentionne un Pipeline Builder avec synchronisation bidirectionnelle entre construction sur canvas et édition du code, ce qui signifie que l'on peut ajuster en ligne des paramètres et des prompts sans perdre la structure. Un assistant intégré intervient sur la conception du pipeline, le réglage des paramètres et la génération de prompts. Une fois la logique en place, le README indique qu'une commande suffit pour la transformer en interface conversationnelle. S'y ajoutent des composants de gestion de base de connaissances pour construire des corpus de questions-réponses. Cette partie est celle qui manque le plus de détails vérifiables dans le matériel fourni : les captures et la vidéo de démonstration ne remplacent pas une description des formats d'import ou des limites de taille. À retenir pour l'instant : l'interface vise un cycle complet, de la construction de la logique jusqu'à la démonstration, ce qui est cohérent avec la cible recherche et prototypage.

Mise en route : ce que le dépôt permet réellement de faire

Le README ne fournit pas de commande d'installation complète dans l'extrait disponible. Il renvoie vers une documentation externe et vers une vidéo d'installation pas à pas publiée en septembre 2025, ainsi que vers un tutoriel de mise en place locale d'un pipeline DeepResearch léger. Ce sont donc les points d'entrée à consulter avant de cloner le dépôt. Ce que l'on peut affirmer à partir du matériel : le projet est en Python, sous licence Apache-2.0, la branche par défaut est main, et les versions récentes publiées sont v0.3.0, v0.3.0.1 et v0.3.0.2. Le README indique aussi que le code des versions 1 et 2 reste accessible dans les branches v1 et v2, ce qui laisse une porte de sortie si la version 3 ne correspond pas au besoin. La configuration d'un pipeline se fait par YAML, et l'enregistrement d'une nouvelle brique passe par un Tool exposé côté serveur MCP. En revanche, les clés de configuration exactes, les noms de fichiers et les options de ligne de commande ne figurent pas dans l'extrait du README. Les inventer serait trompeur : il faut se référer à la documentation liée.

Évaluation unifiée : l'argument le plus solide, et le plus flou

Le README met en avant des workflows d'évaluation standardisés, des benchmarks de recherche prêts à l'emploi, une gestion unifiée des métriques et une intégration de baselines, avec pour objectif d'améliorer la reproductibilité des expériences. C'est l'argument qui distingue le plus UltraRAG d'un simple assembleur de composants : dans un contexte de recherche, comparer deux variantes de pipeline n'a de sens que si les métriques et les jeux de données sont identiques d'une exécution à l'autre. Le dépôt renvoie d'ailleurs vers un jeu de données de benchmark hébergé sur ModelScope. Mais le matériel fourni ne précise ni la liste des benchmarks couverts, ni le format des métriques, ni la manière dont les baselines sont intégrées. Il faut donc considérer cette promesse comme à vérifier dans la documentation avant de bâtir un protocole expérimental dessus. Un système d'évaluation mal documenté peut donner une fausse impression de comparabilité, surtout quand les pipelines testés n'utilisent pas les mêmes modèles sous-jacents.

Quand UltraRAG n'est pas le bon outil

Trois cas de figure posent problème. D'abord, si votre pipeline est stable et déployé, l'indirection introduite par MCP et par l'interprétation du YAML ajoute une couche que vous devrez diagnostiquer en production, sans gain fonctionnel immédiat. Ensuite, si vous avez besoin d'un contrôle fin sur l'ordonnancement, la parallélisation ou la gestion des erreurs au niveau de chaque appel, un cadre qui place la logique dans un fichier de configuration risque de vous bloquer : le README ne décrit pas de mécanisme d'extension du client MCP lui-même, seulement l'ajout de Tools côté serveur. Enfin, si votre environnement interdit ou complique l'usage de serveurs MCP, l'architecture centrale du projet devient un obstacle plutôt qu'un atout. Le README ne mentionne pas non plus de garanties de compatibilité entre versions au-delà de la conservation des branches v1 et v2, ce qui compte si vous prévoyez de suivre les mises à jour.

Face à LangChain et LlamaIndex : configuration contre code

Les alternatives les plus directes restent les cadres Python où l'on écrit le pipeline en code, comme LangChain ou LlamaIndex. La différence d'approche est nette. Dans ces bibliothèques, une boucle de reformulation s'écrit en Python, avec les outils habituels : points d'arrêt, journalisation, tests unitaires sur chaque étape. UltraRAG déplace cette logique dans un YAML interprété par un client MCP, ce qui la rend lisible par des non-développeurs et facile à versionner, mais retire les points d'appui classiques du débogage. L'échange n'est pas gratuit dans l'autre sens non plus : avec LangChain ou LlamaIndex, réutiliser un composant entre deux projets demande souvent de l'adapter au passage, alors que le modèle de serveurs MCP d'UltraRAG vise explicitement la réutilisation au niveau fonction. Le choix dépend donc de qui doit modifier le pipeline : un chercheur qui veut changer l'ordre des étapes sans toucher au code, ou un ingénieur qui veut instrumenter chaque appel.

Maintenance, licence et coût de mise à jour

Le dépôt est actif : dernier push en septembre 2026, et trois versions publiées entre janvier et avril 2026 (v0.3.0, v0.3.0.1, v0.3.0.2). Le rythme de publication est rapide, ce qui est cohérent avec un projet de recherche, mais implique de relire les notes de version avant chaque montée, d'autant que le passage de la version 2 à la version 3 a conduit à conserver les anciennes branches plutôt qu'à maintenir une compatibilité ascendante. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et d'avis, et l'absence de garantie. Ce paragraphe ne constitue pas un avis juridique : pour un usage en produit, faites vérifier les obligations de la Apache-2.0 par votre équipe juridique, en particulier si vous redistribuez le logiciel modifié.

Conclusion éditoriale

UltraRAG convient aux équipes de recherche et aux prototypages industriels qui veulent comparer des variantes de RAG avec des briques MCP réutilisables et un YAML versionnable. Il ne convient pas à qui a besoin d'un contrôle fin du scheduling, d'un débogage pas à pas de chaque appel, ou d'une architecture figée en production sans MCP. Avant d'adopter, vérifiez deux points : la présence du fichier de configuration YAML de pipeline dans le dépôt et la compatibilité de votre version de Python avec les dépendances listées dans le projet.

Sources officielles

1. License: Apache-2.0
2. OpenBMB/UltraRAG on GitHub
3. Project website
4. README
5. Releases