Meritis dévoile OpenRAG, un outil open source inédit permettant de comparer plus de vingt méthodes de Retrieval-Augmented Generation (RAG) directement sur les données métier des entreprises. Pensé comme un véritable cockpit d’aide à la décision, OpenRAG permet d’évaluer la pertinence du retrieval, les performances, les coûts en tokens et même l’impact énergétique des requêtes. Dans cet entretien, Théodore Boullier, Directeur de l’innovation, et Benoît Joly, PhD, chercheur en IA au sein de la R&D, expliquent pourquoi l’outil était devenu indispensable, comment il fonctionne concrètement et ce qu’il révèle des bonnes pratiques RAG en entreprise.
SNC : Qu’est-ce qui vous a poussés à créer OpenRAG ?
Théodore Boullier : Nous voulions travailler sur des enjeux très proches de ceux de nos clients. L’IA est un sujet majeur pour eux, mais les outils restent souvent trop généralistes. Le RAG apporte une spécialisation intéressante, et Benoît l’a beaucoup travaillé côté R&D. L’idée était de rester connectés à leurs besoins réels et à leurs usages.
Benoît Joly : Nous avons commencé à développer des méthodes de RAG en interne. En discutant avec les clients, on s’est rendu compte qu’ils avaient du mal à franchir le pas : il existe énormément de méthodes, de papiers académiques, une nouvelle approche sortait presque chaque semaine. Pour quelqu’un qui n’est pas dans le milieu, c’est très difficile de savoir où aller. Il n’existait pas non plus d’outil permettant de benchmarker des RAG sur leurs données métier, avec leurs documents. C’est ce manque qui a motivé OpenRAG.
Pourquoi est-ce si difficile de comparer les méthodes RAG aujourd’hui ?
B. J. : Les benchmarks académiques utilisent des datasets propres et standardisés. Dans une entreprise, la documentation est souvent mal organisée, hétérogène, parfois ambiguë. Le RAG se comporte très différemment selon la qualité des données. Et les GitHub associés aux papiers de recherche sont rarement pensés pour être utilisés tels quels : le code n’est pas toujours maintenu, il faut souvent le corriger. Nous voulions quelque chose d’accessible et utilisable.
T. B. : Et c’était l’occasion de produire un premier projet open source chez Meritis. Beaucoup de nos consultants sont sensibles à l’open source, mais nous n’avions encore rien publié. OpenRAG était un bon point de départ.
À qui s’adresse OpenRAG en premier lieu ?
T. B. : À des profils techniques : développeurs, data scientists, architectes, responsables R&D ou innovation. Il faut pouvoir installer l’outil et comprendre les composants d’un RAG.
B. J. : Mais pour qu’un benchmark soit pertinent, il faut impliquer les métiers. On a besoin de leurs documents, leurs questions réelles et leurs réponses attendues. Sans ces trois éléments, le benchmark est forcément biaisé.
Concrètement, comment fonctionne OpenRAG ?
B. J. : Tout commence par l’import de documents dans une base locale. Nous ne voyons jamais les données : tout reste chez l’utilisateur. Ensuite il y a deux modes :
-
Chat, pour poser des questions comme sur ChatGPT mais avec la méthode RAG de son choix ;
-
Benchmark, pour comparer plusieurs méthodes sur un ensemble de questions et de réponses métier.
Le benchmark fournit quatre analyses :
-
le coût et la consommation de tokens,
-
la qualité du retrieval,
-
la précision de la réponse par rapport à une vérité terrain,
-
le temps de réponse,
-
et des indicateurs énergétiques.
L’objectif n’est pas de dire « voici le meilleur RAG », mais de donner des éléments de décision.
Quelles différences observe-t-on entre les méthodes ?
B. J. : Cela dépend du cas d’usage. Le choix de l’embedding est crucial, la longueur des chunks, le type de splitter, la préparation du dataset… On voit aussi l’influence de la scalabilité. Une méthode peut être moyenne partout, mais excellente sur un type précis de données. Et on laisse la possibilité de brancher son propre embedder si besoin.
Certaines idées reçues tombent-elles quand on benchmarke réellement ?
B. J. : Oui. Beaucoup pensent que le re-ranking va tout régler. Mais si la phase de retrieval initiale ne récupère pas les bons passages, le meilleur re-ranker ne fera que reclasser de mauvaises informations. La phase de retrieval est la plus importante. Et la préparation des données est trop souvent négligée.
Vous intégrez également la dimension environnementale. Comment ?
B. J. : Pour les appels API (OpenAI par exemple), nous utilisons EcoLogits, qui fournit une estimation. Pour les modèles locaux (Llama), nous utilisons CodeCarbon, qui mesure l’énergie consommée par la machine. Ce sont des ordres de grandeur, car l’impact dépend aussi du datacenter, mais cela permet déjà de comparer les méthodes entre elles.
Quelle place accordez-vous à la communauté open source ?
T. B. : Nous aimerions des contributeurs externes. OpenRAG n’est pas un outil d’industrialisation, donc ce n’est pas le type de projet qui attire le plus de contributions. Mais c’est notre premier projet open source, conçu avec humilité.
L’objectif est qu’il puisse vivre et être repris par d’autres, pas seulement par Meritis.
Proposez-vous un accompagnement autour de l’outil ?
T. B. : OpenRAG n’est pas un produit commercial, mais nous prenons du temps pour aider ceux qui veulent le tester. Et ensuite, Meritis peut accompagner : la conception de la solution RAG, l’intégration, l’architecture, et le déploiement.
B. J. : Le niveau de maturité est très variable selon les entreprises. Pour beaucoup, l’IA générative est déjà un grand pas. Un RAG efficace demande de travailler avec les métiers, sur les données et les usages. C’est loin d’être magique.
Quelles sont les prochaines évolutions prévues ?
B. J. : Nous ajoutons la gestion des métadonnées, des configurations avancées, et des possibilités de tester plus facilement de nouvelles méthodes issues de la recherche. Le but est de permettre à un data lab de relancer un benchmark complet sans tout réinstaller.
