llmware : un catalogue de modèles et un pipeline RAG dans une seule API Python
Unified framework for building enterprise RAG pipelines with small, specialized models
En bref
- De quoi s’agit-il ?
- llmware assemble un catalogue de plus de 300 modèles quantifiés et une chaîne d'ingestion documentaire dans une API unique, pensée pour l'exécution locale. Le projet tient ses promesses sur le papier, mais la documentation disponible laisse plusieurs zones d'ombre qu'un adoptant doit vérifier lui-même.
- À qui s’adresse-t-il ?
- llmware convient aux équipes qui doivent faire tourner un pipeline RAG entièrement sur leur matériel, sans dépendre d'une API distante, et qui acceptent de lire le code des exemples plutôt qu'une documentation exhaustive. Il ne convient pas à qui cherche un service hébergé ou une API stable garantie par un contrat : le projet est une bibliothèque, pas une plateforme.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 122 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 que llmware adresse vraiment
Monter un pipeline RAG local oblige habituellement à recoller trois briques distinctes : un parseur de documents, un modèle d'embedding, et un moteur d'inférence. Chacune a son format de fichiers, ses dépendances, sa façon de charger un modèle. llmware part du constat inverse : proposer une seule surface d'appel pour ces trois étages. Le README résume l'objectif en une phrase, « unified framework for building knowledge-based local, private, secure LLM-based applications ».
Le public visé est précis. Ce sont des équipes qui traitent des documents internes (PDF, PPTX, DOCX, XLSX, CSV, HTML, images, audio) et qui ne peuvent pas envoyer ces fichiers à un service tiers. Le projet cible explicitement l'AI PC, le laptop, l'edge et l'auto-hébergement, sur Windows, Mac et Linux. La contrainte n'est pas la performance brute mais l'empreinte : le README parle de « the smallest possible compute footprint ».
Ce positionnement a une conséquence directe. llmware n'est pas un framework pour construire le meilleur chatbot possible avec le plus grand modèle disponible. C'est un framework pour obtenir une réponse correcte sur un corpus privé avec un modèle qui tient sur la machine qu'on a déjà.
Deux composants, une seule porte d'entrée
L'architecture repose sur deux blocs que le README présente séparément. Le premier est le catalogue de modèles. Le second est le pipeline RAG. Le point d'articulation est le ModelCatalog : tous les modèles se chargent par le même appel, quelle que soit la technologie sous-jacente.
Le catalogue revendique plus de 300 modèles dans des formats quantifiés et optimisés, avec le support de GGUF, OpenVINO, ONNXRuntime, ONNXRuntime-QNN pour Qualcomm, WindowsLocalFoundry et Pytorch. Le README mentionne aussi plus de 50 modèles affinés par llmware, répartis en familles SLIM, Bling, Dragon et Industry-Bert, ainsi que le support de modèles cloud OpenAI, Anthropic et Google. L'idée est qu'un même code peut basculer d'un backend local à un autre sans réécriture.
Le second bloc est le pipeline RAG, décrit comme couvrant « the full lifecycle of connecting knowledge sources to generative AI models ». Concrètement, cela se traduit par trois objets : Library pour l'ingestion, Query pour la recherche, Prompt pour l'inférence avec sources. La documentation ne détaille pas comment le routage par extension de fichier fonctionne en interne, ni comment les chunks sont découpés. C'est une lacune réelle : un adoptant qui doit garantir la qualité du découpage devra lire le code source des parseurs.
Ingestion : Library, add_files et les embeddings multiples
La Library est le conteneur de connaissance. Le README précise qu'une bibliothèque possède à la fois des ressources de collection texte (base de données) et des ressources fichiers, rangées sous llmware_data/accounts/{library_name}. La création tient en un appel : Library().create_new_library("my_library").
L'ingestion passe par une seule fonction, add_files, à laquelle on donne un dossier local contenant des types de fichiers mélangés. Le README indique que les fichiers sont routés par extension vers le parseur approprié, puis analysés, découpés en chunks et indexés dans la base de collection texte. Les extensions citées couvrent pdf, pptx, docx, xlsx, txt, csv, md, json/jsonl, wav, png, jpg et html.
Le point le plus intéressant du design est la possibilité d'installer plusieurs embeddings sur une même bibliothèque. Le README montre deux appels successifs : lib.install_new_embedding(embedding_model_name="mini-lm-sbert", vector_db="milvus", batch_size=500) puis un second avec industry-bert-sec et chromadb. On peut donc indexer le même corpus avec deux modèles d'embedding et deux bases vectorielles distinctes, et choisir lequel interroger au moment de la requête. C'est utile quand un modèle généraliste et un modèle spécialisé ne retrouvent pas les mêmes passages.
Le coût caché est le stockage. Deux embeddings sur un même corpus, c'est deux jeux de vecteurs à conserver et à maintenir synchronisés si les documents changent. Le README ne décrit pas de mécanisme de réindexation incrémentale.
Interrogation : cinq modes de recherche sur la même Library
Query prend une Library en argument et expose plusieurs méthodes. Le README en montre quatre : text_query, semantic_query, text_query_with_document_filter et une variante de semantic_query liée à un embedding précis.
La recherche textuelle accepte un paramètre exact_mode. À False, on obtient une recherche souple ; à True, une correspondance exacte. Le filtrage par document se fait en passant un dictionnaire, par exemple {"file_name": "selected file name"}. Cette combinaison, requête textuelle plus filtre document plus mode exact, est ce qui distingue llmware d'une simple recherche vectorielle : on peut restreindre la recherche à un sous-ensemble du corpus avant même de calculer une similarité.
Quand plusieurs embeddings sont installés, il faut préciser lequel utiliser au moment de construire l'objet Query. Le README donne l'exemple Query(lib, embedding_model_name="mini_lm_sbert", vector_db="milvus"). Si l'on omet ces paramètres alors que la bibliothèque en porte plusieurs, le comportement n'est pas documenté dans le matériel fourni. C'est un point à tester avant de bâtir une application dessus.
Le README mentionne aussi des requêtes hybrides et des filtres de métadonnées, sans en montrer la syntaxe. Là encore, les exemples du dépôt sont la vraie référence.
Prompt et sources : le raccourci qui peut masquer le pipeline
Prompt est la couche qui relie retrieval et inférence. Le README décrit le comportement ainsi : on ajoute un fichier, il est analysé, découpé, filtré par la requête, puis empaqueté comme contexte prêt pour le modèle, y compris par lots.
L'usage de base tient en deux lignes. Prompt().load_model("llmware/bling-tiny-llama-v0") charge le modèle, puis prompter.prompt_main("what is the future of AI?", context="Insert Sources of information") exécute l'inférence avec le contexte fourni. Le ModelCatalog expose aussi inference et stream directement sur l'objet modèle, avec un paramètre add_context.
Ce confort a un revers. Quand Prompt fait à la fois la récupération, le filtrage et la construction du contexte, il devient difficile de savoir quels passages ont réellement été envoyés au modèle. Pour une application où la traçabilité des sources compte, mieux vaut séparer les étapes : interroger avec Query, inspecter les résultats, puis construire le prompt soi-même. Le README ne décrit pas d'option pour journaliser le contexte assemblé.
Autre limite : le README ne donne aucune indication sur la gestion des corpus qui dépassent la fenêtre de contexte du modèle. Le découpage en chunks et la sélection des passages pertinents sont justement là où un RAG réussit ou échoue, et cette partie reste à la charge de l'utilisateur.
Installation et licence
Le projet est publié sous licence Apache-2.0. Cette licence autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de licence, et de signaler les fichiers modifiés. Elle inclut une clause de brevet. Elle n'offre aucune garantie. Rien dans le matériel fourni n'indique de restriction supplémentaire liée aux modèles du catalogue : ceux-ci proviennent de familles open source distinctes et peuvent porter leurs propres conditions, qu'il faut vérifier séparément sur Hugging Face.
Le README affiche un badge de compatibilité Python 3.10 à 3.14. Le paquet s'installe depuis PyPI, la version publiée étant référencée par le badge PyPI du dépôt. Le matériel fourni ne donne pas la commande d'installation exacte ni la liste des dépendances optionnelles, par exemple pour Milvus ou ChromaDB. Il faut donc se référer à la page PyPI ou à la documentation en ligne pour ces détails.
Le rythme de publication est irrégulier. Trois versions récentes sont listées : v0.4.4 en février 2026, v0.4.5 en février 2026, v0.4.6 en avril 2026. Le numéro de version reste en 0.x, ce qui signale un projet qui ne garantit pas encore la stabilité de son interface. Un adoptant doit prévoir de relire ses appels à chaque montée de version mineure.
Quand llmware n'est pas le bon outil
Le cas le plus clair est celui d'une équipe qui a déjà une infrastructure de recherche vectorielle en production. Si vos documents sont déjà indexés dans un moteur existant et que vous n'avez besoin que de la couche de génération, llmware ajoute une abstraction superflue. Vous devrez soit migrer votre corpus vers une Library, soit contourner le pipeline d'ingestion, ce qui annule l'intérêt du framework.
Deuxième cas : les charges de travail où la qualité de réponse prime sur l'empreinte. llmware est optimisé pour des modèles petits et spécialisés. Le README insiste sur la durabilité et le coût, pas sur la performance maximale. Si vous pouvez appeler un grand modèle cloud sans contrainte de confidentialité, la valeur ajoutée du catalogue local disparaît.
Troisième cas : un besoin de documentation contractuelle. Le matériel disponible est constitué d'un README et de releases. Les sections sur le découpage des chunks, sur la réindexation et sur le comportement de Query en cas d'embeddings multiples ne sont pas documentées. Une équipe qui a besoin de garanties écrites sur ces points devra soit lire le code, soit choisir un projet avec une spécification plus formelle.
Enfin, le support de formats comme wav, png ou jpg est annoncé, mais le README ne décrit pas la qualité de l'extraction pour ces types. Un pipeline qui dépend de l'OCR ou de la transcription audio doit être validé sur des échantillons réels avant tout engagement.
Ce qu'il faut vérifier avant de s'engager
La première vérification est matérielle. Le catalogue annonce le support de GGUF, OpenVINO, ONNXRuntime et Pytorch, mais chaque backend a ses prérequis. Un laptop sans NPU Qualcomm ne tirera aucun bénéfice de l'ONNXRuntime-QNN. Le README affirme que « virtually all of our examples and models can be run on device », ce qui reste une affirmation générale : testez le modèle précis que vous visez sur la machine précise que vous utiliserez.
La deuxième vérification porte sur le stockage vectoriel. Le README cite milvus et chromadb dans ses exemples. Ces bases ont des exigences d'exploitation différentes, et le paramètre vector_db conditionne la façon dont les embeddings sont stockés et interrogés. Vérifiez que la base choisie est installable dans votre environnement avant de créer une Library.
La troisième vérification concerne le suivi du projet. Le dépôt n'est pas archivé et la dernière poussée date de mai 2026. Trois releases en trois mois, c'est un rythme actif, mais en version 0.x. Si votre application dépend de l'API Prompt, prévoyez un test de non-régression à chaque montée de version, car rien n'indique de politique de dépréciation.
Reste une question que le matériel ne permet pas de trancher : la qualité du découpage de texte sur des documents complexes, tableaux ou PDF multi-colonnes. C'est le point où un pipeline RAG se joue, et c'est précisément celui que le README traite le plus brièvement.
Conclusion éditoriale
llmware convient aux équipes qui doivent faire tourner un pipeline RAG entièrement sur leur matériel, sans dépendre d'une API distante, et qui acceptent de lire le code des exemples plutôt qu'une documentation exhaustive. Il ne convient pas à qui cherche un service hébergé ou une API stable garantie par un contrat : le projet est une bibliothèque, pas une plateforme. Avant d'adopter, vérifiez trois choses concrètes : que le modèle visé figure bien dans le ModelCatalog, que le vector_db choisi pour install_new_embedding est disponible dans votre environnement, et que le rythme des releases depuis v0.4.4 correspond à votre tolérance aux ruptures d'interface.
Notes de la communauté