SAG : une base de connaissances locale où la recherche s'appuie sur des hyperarêtes créées à la requête
A new SOTA for RAG — an original retrieval architecture and an open-source knowledge base for humans and agents.
En bref
- De quoi s’agit-il ?
- SAG remplace la similarité dense et le graphe préconstruit par un index événement-entité et des hyperarêtes formées au moment de la requête. Le dépôt livre surtout une application de base de connaissances local-first, pas seulement une architecture de retrieval.
- À qui s’adresse-t-il ?
- SAG convient à un usage individuel ou à un agent qui a besoin de retrouver la provenance exacte d'un chunk, avec SQLite et LanceDB en local et sans base externe. À éviter si vous cherchez un service multi-utilisateur : le README décrit le produit comme délibérément local-first et mono-utilisateur.
- Puis-je l’utiliser commercialement ?
- Oui. MIT 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 1 jour.
- 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é : deux systèmes de retrieval à maintenir en parallèle
Le README pose la question en termes de coût d'exploitation. La RAG dense classique retrouve des chunks par similarité sémantique. GraphRAG ajoute une construction de graphe hors ligne, mais cette construction se paie en extraction de triplets, fusion d'entités, normalisation des relations, maintenance globale et mises à jour incrémentales difficiles. SAG se présente comme une troisième voie : ni une fusion des deux, ni un service RAG accompagné d'un service GraphRAG qui tournent côte à côte. La cible est explicite dans le dépôt : des particuliers et des agents. Le produit est décrit comme local-first et mono-utilisateur, démarre avec SQLite et LanceDB, et ne demande aucune base externe. C'est un choix de périmètre, pas un détail d'implémentation. Une équipe qui veut une base partagée entre plusieurs utilisateurs ne trouvera pas ici la couche de concurrence ou de droits correspondante, et le README ne la promet pas.
Le chunk devient un événement, l'entité devient un point d'indexation
Le modèle de données tient en trois lignes dans le README : un chunk donne un événement sémantiquement complet, le même chunk donne plusieurs entités d'indexation, et l'ensemble forme une hyperarête latente. La distinction entre événement et entité porte tout le reste. L'événement conserve le sens du chunk et n'est pas découpé en triplets indépendants. L'entité sert d'index léger et de point d'expansion, sans remplacer le sens de l'événement. Conséquence directe : SAG ne normalise pas les relations à l'indexation, donc il n'a pas de phase de fusion d'entités à maintenir. La contrepartie est assumée : la structure relationnelle n'existe pas avant la requête. Si votre besoin est d'interroger un graphe figé, exporté et versionné indépendamment du moteur de recherche, ce modèle ne le fournit pas tel quel.
Indexation hors ligne et hyperarêtes formées à la requête
L'indexation hors ligne se déroule en quatre étapes selon le README : parse du document en chunks sémantiquement cohérents, extraction en parallèle d'un événement et de plusieurs entités par chunk, persistance des chunks, événements, entités et associations dans un stockage relationnel, puis persistance des représentations de chunks, d'événements et d'entités dans des index vectoriels et plein texte. Le moment intéressant est en ligne. L'hyperarête dynamique est créée localement quand des jointures SQL rassemblent des événements qui partagent des entités autour de la requête courante. SAG ne préconstruit pas ces hyperarêtes et ne les maintient pas globalement. C'est ce qui évite la maintenance d'un graphe, et c'est aussi ce qui rend le comportement dépendant de la requête : la structure n'est pas un artefact consultable en dehors d'une exécution. Le README précise enfin que la frontière de sortie reste la preuve d'origine : les événements sélectionnés sont toujours ramenés aux chunks sources pour la génération et la citation. La traçabilité n'est donc pas un ajout, elle est la sortie du pipeline.
Deux modes de recherche, et une différence de coût qui n'est pas chiffrée
Le README distingue deux modes. Fast s'appuie sur vector, Precise sur multi. La recherche peut être globale ou restreinte à une source. Le dépôt ne donne pas de latence ni de coût par requête pour ces deux modes, et je ne peux pas en inventer. Ce que l'on peut dire est structurel : le mode multi implique davantage de travail au moment de la requête, puisque c'est précisément là que SAG construit ses hyperarêtes. Le choix entre les deux n'est donc pas seulement un curseur de qualité, c'est un curseur de charge sur la base relationnelle. Sur un poste unique avec SQLite, cette charge se ressent d'autant plus que la base grossit. Le README ne documente pas de seuil à partir duquel basculer vers PostgreSQL et pgvector ; il indique seulement qu'un chemin clair existe vers ces backends. Traitez ce chemin comme une direction annoncée, pas comme une procédure décrite.
Installation, CLI et raccordement à un agent
Le paquet Python s'appelle zleap-sag sur PyPI, et le dépôt exige Python 3.11 ou plus récent ainsi que Node 20 ou plus récent. Le client en ligne de commande officiel est @zleap-ai/sag-cli, publié le 31 juillet 2026. Le README donne une commande unique pour monter le MCP de connaissances SAG dans Codex ou Claude Code : sag agent connect codex | claude-code. L'argument avancé est concret : plus de copier-coller de JWT, plus de fichier de configuration édité à la main. Un connecteur local DeepSeek Harness, @zleap-ai/dsh-sag, expose la même base à des agents DSH pour la recherche, la lecture de sources et la gestion des sources et documents. Les surfaces d'intégration listées sont REST/OpenAPI auto-hébergé, un chat compatible OpenAI, MCP et le paquet Python. Notez que le README renvoie à docs/sag-cli.en.md pour la CLI : le détail des options n'est pas dans le texte fourni.
OCTX, migration entre instances et réutilisation des vecteurs
La note du 13 août 2026 décrit l'import et l'export de sources OCTX avec validation d'intégrité, gestion des conflits, reprise après échec et réutilisation compatible des vecteurs, pour la migration et la sauvegarde d'une base entre instances. C'est la partie qui répond au problème le plus ennuyeux d'une base locale : comment la déplacer sans tout réindexer. La même note mentionne l'amélioration de la recherche continue de termes chinois et des contrôles de cycle de vie des documents. Un point de méthode : le dépôt affirme une réutilisation compatible des vecteurs, mais ne détaille pas dans le texte fourni les conditions exactes de cette compatibilité. Si votre migration dépend de ce point, lisez le code avant de compter sur l'export OCTX. Le versionnement est actif : v1.8.6 le 3 septembre 2026, v1.8.5 la veille, v1.8.4 le 30 août 2026. Trois publications en cinq jours indiquent un rythme soutenu, ce qui a un coût de suivi pour quiconque épingle une version.
Ce que SAG n'est pas, et à quoi le comparer
L'alternative la plus directe est GraphRAG tel que le README le décrit : construction de graphe hors ligne, extraction de triplets, fusion d'entités, normalisation des relations. La différence d'approche est nette. GraphRAG paie la structure à l'indexation et la garde disponible en permanence ; SAG paie la structure à la requête et n'a rien à maintenir entre deux requêtes. Pour un corpus qui change rarement et que l'on veut explorer comme un graphe persistant, GraphRAG correspond mieux au besoin. Pour un corpus qui bouge et où l'on veut éviter une phase de maintenance, l'arbitrage inverse s'entend. Une seconde alternative est la RAG dense pure : moins de mécanismes, mais aucune expansion relationnelle et une traçabilité qui dépend de ce que vous ajoutez vous-même. Le README revendique le meilleur retrieval et le meilleur QA de bout en bout sur HotpotQA, 2WikiMultiHopQA et MuSiQue, avec un papier arXiv:2606.15971 et un dépôt de reproduction SAG-Benchmark. Ces résultats viennent des auteurs. Ce n'est pas un motif de rejet, c'est une raison de reproduire avant de s'engager.
Licence MIT et coût de maintenance
Le dépôt est sous licence MIT, ce qui autorise la modification et la redistribution avec conservation de l'avis de licence et sans garantie. Je ne donne pas d'avis juridique : si vous redistribuez SAG dans un produit, faites relire les termes par qui de droit, en particulier sur le contenu que vous indexez, qui relève de vos propres droits. Côté maintenance, l'ancienne version est archivée dans la branche v1 et n'est plus maintenue, ce qui signifie qu'un déploiement basé dessus n'a pas de correctifs à attendre. La version actuelle repose sur le paquet zleap-sag et une interface entièrement redessinée depuis le 14 juillet 2026. Le coût réel d'adoption tient à trois dépendances de version : Python 3.11+, Node 20+, et le rythme des publications. Un utilisateur individuel qui met à jour quand il le souhaite absorbe ce coût. Une équipe qui doit garantir la stabilité d'une base partagée le ressentira davantage, d'autant que la cible annoncée reste mono-utilisateur.
Conclusion éditoriale
SAG convient à un usage individuel ou à un agent qui a besoin de retrouver la provenance exacte d'un chunk, avec SQLite et LanceDB en local et sans base externe. À éviter si vous cherchez un service multi-utilisateur : le README décrit le produit comme délibérément local-first et mono-utilisateur. Avant d'adopter, vérifiez deux points précis dans le dépôt : le format OCTX pour migrer une base entre instances, et la commande sag agent connect codex | claude-code, qui conditionne l'intégration à un agent.
Notes de la communauté