RAGLite : un toolkit RAG qui parie sur DuckDB et PostgreSQL plutôt que sur LangChain
🥤 RAGLite is a Python toolkit for Retrieval-Augmented Generation (RAG) with DuckDB or PostgreSQL
En bref
- De quoi s’agit-il ?
- RAGLite est un toolkit Python de Retrieval-Augmented Generation qui s'appuie sur la recherche plein texte et vectorielle native de DuckDB ou PostgreSQL. Son intérêt principal tient à ce qu'il refuse : pas de PyTorch, pas de LangChain, et un choix explicite de dépendances légères.
- À qui s’adresse-t-il ?
- RAGLite convient aux équipes Python qui veulent un pipeline RAG inspectable, avec DuckDB en local ou PostgreSQL en production, et qui acceptent de dépendre de LiteLLM pour les modèles. Il ne convient pas à qui cherche un framework agentique multi-outils ou un écosystème de connecteurs : ce n'est pas ce que le dépôt propose.
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions. MPL-2.0 est une licence à copyleft faible : vous pouvez l’intégrer à un logiciel commercial ou propriétaire, mais si vous distribuez des modifications de ses propres fichiers, vous devez les publier sous la même licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 30 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : un pipeline RAG qu'on peut lire en entier
La plupart des piles RAG empilent des couches : un framework d'orchestration, un moteur d'embeddings, une base vectorielle dédiée, un reranker. Chaque couche ajoute ses propres abstractions et ses propres dépendances. RAGLite prend le chemin inverse. Le README annonce comme contrainte de conception de n'utiliser que des dépendances légères et permissives, en citant explicitement l'exclusion de PyTorch et de LangChain. Ce n'est pas un détail cosmétique : cela détermine la taille de l'installation, la surface d'API à apprendre, et le nombre d'endroits où une régression peut se cacher.
Le public visé est donc précis. Un développeur Python qui a déjà une base DuckDB ou PostgreSQL, qui veut indexer des PDF et interroger un LLM sur leur contenu, et qui préfère lire le code de sa couche de récupération plutôt que de configurer un objet opaque. Le toolkit couvre l'ensemble de la chaîne : conversion des documents, découpage, embedding, recherche, reranking, génération, et optionnellement évaluation et interface de chat. C'est un choix de périmètre large assumé, mais avec des frontières nettes sur les dépendances.
Deux bases, deux moteurs de recherche, une seule API
Le mécanisme central est la recherche hybride déléguée à la base de données. Avec DuckDB, le README indique que la recherche combine les extensions FTS (full text search) et VSS (vector similarity search). Avec PostgreSQL, la combinaison est tsvector pour le texte et pgvector pour les vecteurs. Dans les deux cas, RAGLite ne réimplémente pas un index : il s'appuie sur ce que la base fournit déjà, et fusionne les deux classements. La référence citée dans le README pour cette fusion est l'article de Cormack sur le reciprocal rank fusion.
Ce choix a une conséquence pratique importante. La migration d'un prototype local vers un déploiement partagé ne change pas la logique applicative, seulement la configuration de la base. DuckDB tient dans un fichier, PostgreSQL suppose un serveur, et le README mentionne neon.tech comme moyen d'obtenir une base PostgreSQL en quelques clics. La contrepartie est que vous héritez des limites de la base choisie : la qualité de la recherche plein texte dépend de la tokenisation et de la langue configurées côté moteur, pas côté RAGLite.
Le découpage des documents est traité comme un problème d'optimisation, pas comme une heuristique de taille de fenêtre. Le README décrit une séparation de phrases par wtpsplit-lite et un découpage sémantique, tous deux formulés comme la résolution d'un problème de programmation linéaire en nombres entiers binaires. C'est coûteux à l'indexation et cela se voit dans le temps de traitement d'un gros corpus. L'embedding multi-vecteurs utilise le late chunking et des titres de chunk contextuels, deux techniques qui visent à éviter qu'un chunk perde son sens une fois isolé de son document.
Configurer et insérer : ce que montrent les exemples du dépôt
L'installation de base tient en une commande, pip install raglite. Les extras ajoutent des capacités : raglite[chainlit] pour l'interface de chat, raglite[pandoc] pour les formats autres que PDF, raglite[ragas] pour l'évaluation. Le traitement documentaire haut de gamme via Mistral OCR s'installe séparément avec pip install mistralai, ce qui signifie que la dépendance n'est pas tirée par défaut.
La configuration passe par un objet RAGLiteConfig, que le README montre importé depuis raglite. Les modèles sont sélectionnés par identifiant LiteLLM, ce qui couvre les fournisseurs distants. Pour un modèle local, le README donne une syntaxe précise : un identifiant de la forme llama-cpp-python/<hugging_face_repo_id>/<filename>@<n_ctx>, où n_ctx est optionnel et fixe la taille de contexte. Les modèles cités en exemple viennent de la collection Unsloth sur Hugging Face.
Le point d'installation qui mérite attention concerne llama-cpp-python. Le README recommande un binaire précompilé plutôt qu'une compilation locale, et détaille les variables à définir avant l'installation : LLAMA_CPP_PYTHON_VERSION, PYTHON_VERSION, ACCELERATOR, PLATFORM. Les valeurs d'ACCELERATOR listées sont metal, cu121, cu122, cu123 et cu124 ; celles de PLATFORM sont macosx_11_0_arm64, linux_x86_64 et win_amd64. Le README avertit lui-même que toutes les combinaisons ne sont pas disponibles. C'est la première chose à tester si vous visez l'exécution locale accélérée, avant même d'écrire une ligne de code RAG.
Adaptive retrieval, prompt caching et adaptateur de requête
Trois mécanismes du README méritent d'être distingués parce qu'ils ne jouent pas au même niveau.
L'adaptive retrieval, référencé à l'article arXiv 2403.14403, laisse le LLM décider s'il faut récupérer des documents et lesquels, à partir de la requête. Cela ajoute un appel de modèle en amont de la recherche. Pour une question de conversation courante qui ne nécessite aucun document, on économise la recherche et le contexte injecté. Pour une question factuelle, on paie une latence supplémentaire avant même de toucher à la base.
La structure du tableau de messages est conçue pour tirer parti du prompt caching, avec un renvoi à la documentation OpenAI sur ce sujet. Le bénéfice annoncé porte sur le coût et la latence. Il dépend donc entièrement du fournisseur : un modèle servi localement via llama-cpp-python n'a pas de cache de prompt facturé, et l'optimisation n'a alors plus d'objet.
L'adaptateur de requête linéaire est le composant le plus intéressant techniquement. Le README le décrit comme une solution de forme close à un problème orthogonal de Procrustes, implémentée dans src/raglite/_query_adapter.py. Autrement dit, un ajustement mathématique déterministe entre l'espace des requêtes et celui des documents, calculé à partir de données, et non un modèle entraîné. C'est le genre de détail qui justifie de lire le code source plutôt que la documentation seule, car le README ne dit pas sur quel volume de données cet adaptateur devient utile.
MCP, Chainlit et évaluation : des extras qui déplacent le centre de gravité
RAGLite embarque un serveur Model Context Protocol que des clients comme Claude desktop peuvent appeler. Il propose aussi un frontend de type ChatGPT via Chainlit, déployable sur le web, Slack ou Teams selon la documentation Chainlit. Ces deux briques changent la nature du projet : on passe d'une bibliothèque à un service.
C'est là que le périmètre devient discutable. Un serveur MCP expose vos documents à un client externe, ce qui suppose une décision de sécurité et de périmètre de données qui n'appartient pas au toolkit. Le frontend Chainlit, lui, est présenté comme personnalisable, mais toute personnalisation significative se fait dans Chainlit, pas dans RAGLite. Vous héritez donc d'un second projet avec son propre cycle de publication.
L'évaluation via Ragas suit la même logique. Elle est optionnelle et s'installe avec l'extra dédié. Le README ne donne pas de jeu de métriques ni de seuils dans l'extrait disponible, seulement la mention que l'évaluation porte sur la récupération et la génération. Pour un projet qui revendique un découpage et un adaptateur de requête optimaux, l'absence de protocole d'évaluation documenté dans le README est une lacune réelle : vous devrez construire vos propres jeux de test pour savoir si le late chunking vous apporte quelque chose sur votre corpus.
Ce que RAGLite ne fera pas pour vous
La contrainte de dépendances légères a un revers. En excluant LangChain, RAGLite exclut aussi l'écosystème de chargeurs, de tools et d'agents qui va avec. Si votre besoin est un agent capable d'appeler une API, d'écrire dans un fichier et de raisonner sur plusieurs étapes, ce toolkit n'est pas l'outil. Il fait de la récupération et de la génération sur un corpus documentaire, et le README ne revendique rien d'autre.
La qualité de la recherche dépend fortement de l'étape d'ingestion, qui est la plus lourde. La conversion PDF vers Markdown repose sur pdftext et pypdfium2. Le README positionne Mistral OCR comme l'option de traitement haut de gamme pour les PDF, images, DOCX et PPTX, avec descriptions d'images automatiques. Cette option suppose un appel à un service externe et une clé API, donc un coût par document et une sortie de vos données vers un tiers. Sur des documents sensibles, c'est un arbitrage à faire consciemment.
Enfin, le rythme de publication est irrégulier. Les trois versions visibles dans les métadonnées sont v1.1.1 en mai 2026, v1.0.0 en juin 2025 et v0.7.0 en mars 2025. Le passage de 0.7 à 1.0 a pris trois mois, puis onze mois séparent 1.0 de 1.1.1. Cela ne dit rien de la qualité du code, mais cela indique qu'il ne faut pas compter sur des correctifs fréquents entre deux versions. Épinglez une version et testez vos mises à jour vous-même.
Sur le plan juridique, la licence est MPL-2.0, une licence à copyleft faible par fichier. Les fichiers modifiés doivent rester sous MPL-2.0, mais le projet peut être combiné avec du code sous d'autres licences. Ce paragraphe n'est pas un conseil juridique : faites relire votre cas d'usage si vous redistribuez le toolkit modifié.
Face à un montage LangChain plus base vectorielle dédiée
L'alternative la plus directe est un assemblage LangChain avec une base vectorielle spécialisée comme Qdrant ou Weaviate, plus un modèle d'embedding servi séparément. La différence n'est pas dans les fonctionnalités, elle est dans la localisation de la logique.
Dans un montage LangChain, l'orchestration, le découpage et la récupération vivent dans le code Python du framework, et la base ne fait que stocker des vecteurs. Dans RAGLite, la recherche hybride est déléguée à DuckDB ou PostgreSQL, qui exécutent la recherche plein texte et la recherche vectorielle dans la même requête. Concrètement, cela veut dire moins de composants à déployer, mais aussi moins de contrôle sur la façon dont les deux classements sont fusionnés si vous voulez ajuster les poids.
Le second écart porte sur les dépendances. Un montage LangChain typique tire PyTorch pour les embeddings, soit plusieurs gigaoctets. RAGLite l'exclut explicitement. Pour un déploiement contraint en taille d'image ou en temps de construction, la différence est mesurable dès le premier build. En contrepartie, vous renoncez à la variété de modèles d'embedding disponibles dans l'écosystème PyTorch, et vous dépendez de ce que LiteLLM et les backends retenus exposent.
Un troisième écart concerne l'observabilité. Un montage maison vous laisse instrumenter chaque étape librement. RAGLite expose une API plus étroite : vous voyez les documents insérés et les résultats, moins facilement les scores intermédiaires de la fusion. Si vous devez expliquer pourquoi un document a été retenu, prévoyez d'aller lire src/raglite pour trouver où les classements sont combinés.
Conclusion éditoriale
RAGLite convient aux équipes Python qui veulent un pipeline RAG inspectable, avec DuckDB en local ou PostgreSQL en production, et qui acceptent de dépendre de LiteLLM pour les modèles. Il ne convient pas à qui cherche un framework agentique multi-outils ou un écosystème de connecteurs : ce n'est pas ce que le dépôt propose. Avant d'adopter, vérifiez trois points concrets dans le README et les notes de version : la disponibilité du binaire llama-cpp-python correspondant à votre combinaison ACCELERATOR et PLATFORM, la présence de l'extension FTS dans votre build DuckDB, et le fait que l'extra ragas soit maintenu au même rythme que le coeur du paquet.
Notes de la communauté