Zleap-AI/SAG: Ereignis-Entity-Indizierung statt Chunk-Ähnlichkeit
A new SOTA for RAG — an original retrieval architecture and an open-source knowledge base for humans and agents.
Auf einen Blick
- Was ist das?
- SAG ersetzt die Kombination aus Dense-RAG und GraphRAG durch ein eigenes Datenmodell aus Ereignissen, Index-Entities und zur Abfragezeit erzeugten Hyperkanten. Das Repository liefert dazu eine lokale Wissensdatenbank für Einzelnutzer und Agenten. Eine Einordnung dessen, was die Unterlagen hergeben, und wo sie dünn bleiben.
- Für wen ist es gedacht?
- SAG passt zu einzelnen Entwicklern und kleinen Teams, die eine lokale, zitierfähige Wissensbasis für sich und einen Agenten betreiben wollen und die SQLite sowie LanceDB als Ablage akzeptieren. Wer eine mandantenfähige Mehrbenutzerlösung mit verteilter Indexpflege braucht, sollte zuerst die Backend-Frage klären, denn das Projekt startet ausdrücklich single-user.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem SAG adressiert und für wen es gedacht ist
Die Ausgangslage beschreibt das README selbst: dichte Vektor-Retrieval-Systeme holen Chunks über semantische Ähnlichkeit, GraphRAG baut zusätzlich offline einen Graphen auf und zahlt dafür mit Triple-Extraktion, Entity-Merging, Relationsnormalisierung, globaler Pflege und erschwerten inkrementellen Updates. Wer beides braucht, betreibt in der Regel zwei Systeme und führt zwei Retrieval-Pfade zusammen. SAG setzt an genau dieser Doppelung an und behauptet, keine Fusion zu sein, sondern eine dritte Architektur, die beide ersetzt.
Die Zielgruppe ist im README benannt: das Projekt sei bewusst local-first und single-user, starte mit SQLite und LanceDB, benötige keine externe Datenbank und halte einen Pfad zu PostgreSQL/pgvector offen. Dazu kommt die Agenten-Schiene. Über den Changelog vom 30. August 2026 ist ein Connector für DeepSeek Harness dokumentiert, über den SAG-Wissen für DSH-Agenten durchsuchbar und lesbar wird. Wer also eine persönliche Wissensbasis sucht, die sowohl im Browser als auch über MCP in einem Coding-Agenten auftaucht, ist der adressierte Fall. Wer Mandantentrennung, verteilte Indexpflege oder Hochverfügbarkeit erwartet, ist es nicht.
Ereignis, Entity, Hyperedge: das Datenmodell hinter der Abfrage
Das README fasst den Kern in drei Zeilen zusammen: chunk zu einem semantisch vollständigen Ereignis, chunk zu mehreren indizierenden Entities, Ereignis zu Entities als eine latente Hyperedge. Entscheidend ist die Rollenverteilung. Das Ereignis trägt die vollständige Bedeutung eines Chunks und wird nicht in unabhängige Triples zerlegt. Die Entity ist ausdrücklich nur Indexpunkt und Expansionsanker, kein Ersatz für die Bedeutung des Ereignisses. Die Hyperedge existiert nicht als persistiertes Objekt, sondern entsteht lokal zur Abfragezeit, wenn SQL Ereignisse über gemeinsame Entities verbindet. Genau hier liegt der Unterschied zu GraphRAG: dort wird der Graph offline gebaut und global gepflegt, bei SAG fällt diese Pflege weg, weil die Verbindung erst im Moment der Anfrage berechnet wird.
Der Ausgabegrenze kommt dabei eine eigene Rolle zu. Ausgewählte Ereignisse werden laut README immer auf die Quell-Chunks zurückgeführt, und diese Chunks bleiben die Grundlage für Generierung und Zitat. Das ist die eigentliche Designentscheidung des Projekts: Die Struktur dient dem Auffinden, nicht dem Belegen. Ein Zitat zeigt auf den Originaltext, nicht auf einen extrahierten Fakt. Für Anwendungen, in denen Nachvollziehbarkeit wichtiger ist als Abdeckung, ist das die richtige Wahl. Ob die Ereignis-Extraktion bei sehr kurzen oder tabellarischen Chunks überhaupt sinnvolle Ereignisse liefert, sagt das README nicht.
Offline-Indizierung und der Abbruch in der Online-Beschreibung
Der Indexierungspfad ist in vier Schritten dokumentiert. Erst wird ein Dokument in semantisch kohärente Chunks zerlegt. Dann werden aus jedem Chunk parallel ein Ereignis und mehrere Entities extrahiert. Anschließend landen Chunks, Ereignisse, Entities und die Zuordnungen zwischen Ereignis und Entity in relationaler Ablage. Zuletzt werden Repräsentationen von Chunk, Ereignis und Entity in Vektor- und Volltextindizes geschrieben. Bemerkenswert ist, dass Vektorindex und Volltextindex parallel geführt werden. Das erklärt die beiden Suchmodi, die die Fähigkeitentabelle nennt: Fast über vector und Precise über multi.
An dieser Stelle endet das vorliegende Material. Der Abschnitt How retrieval works beginnt mit dem Unterpunkt Online retrieval, der Inhalt fehlt im Auszug. Damit ist der Ablauf zur Abfragezeit, also das Zusammenspiel von SQL-Join, Entity-Expansion und Ereignisauswahl, nur über die Kurzbeschreibung oben belegt und nicht im Detail. Wer die Architektur wirklich bewerten will, muss das Paper unter arXiv:2606.15971 heranziehen. Für eine Adoption ist das ein realer Aufwandsposten: Die zentrale Mechanik des Systems ist in der Repository-Dokumentation nicht vollständig ausgeführt.
Installation und Betrieb über CLI, MCP und REST
Die technischen Voraussetzungen stehen in den Badges: Python 3.11 oder neuer, Node 20 oder neuer. Die Python-Seite kommt als Paket zleap-sag über PyPI. Der Changelog vom 31. Juli 2026 verweist auf den offiziellen Kommandozeilen-Client @zleap-ai/sag-cli, dessen Dokumentation unter docs/sag-cli.en.md liegt. Der dort genannte Befehl lautet sag agent connect codex | claude-code. Laut Changelog mountet er das SAG Knowledge MCP in Codex oder Claude Code, ohne dass ein JWT kopiert oder eine Konfigurationsdatei von Hand bearbeitet werden muss. Das ist der konkreteste Einstiegspunkt, den das Material hergibt.
Für die Anbindung an eigene Software nennt die Fähigkeitentabelle vier Wege: selbst gehostetes REST mit OpenAPI, einen OpenAI-kompatiblen Chat-Endpunkt, MCP und das Python-Paket zleap-sag. Der OpenAI-kompatible Endpunkt ist praktisch, weil bestehende Clients ohne Anpassung dagegen laufen können. Der Changelog vom 13. August 2026 ergänzt den Import und Export von OCTX-Quellen mit Integritätsprüfung, Konfliktbehandlung, Fehlerwiederherstellung und kompatibler Vektorwiederverwendung, gedacht für Migration und Backup zwischen Instanzen. Wer eine Wissensbasis umziehen will, hat damit einen vorgesehenen Pfad. Konkrete Konfigurationsschlüssel nennt der vorliegende Auszug nicht, die stehen in der jeweiligen Dokumentationsdatei.
Wo SAG die falsche Wahl ist
Die deutlichste Einschränkung steht im README selbst und ist keine Nebenbemerkung: single-user. SQLite und LanceDB als Startkonfiguration bedeuten, dass die Ablage an eine Instanz gebunden ist. Der Hinweis auf einen Pfad zu PostgreSQL und pgvector ist eine Absichtserklärung, kein dokumentierter Migrationsweg in diesem Auszug. Wer heute mehrere Nutzer mit getrennten Rechten bedienen muss, plant entweder eine Instanz pro Nutzer oder arbeitet gegen die ausdrückliche Ausrichtung des Projekts.
Der zweite Bruch ist die Versionsgeschichte. Am 14. Juli 2026 erschien laut Changelog eine vollständig neue Version auf Basis des Pakets zleap-sag mit neu gestalteter Oberfläche. Die vorherige Version wurde in den Branch v1 archiviert und wird nicht mehr gepflegt. Wer ältere Installationen betreibt, steht vor einer Migration ohne im Auszug dokumentierten Pfad. Drittens ist der Extraktionsschritt selbst ein Risiko: Jeder Chunk durchläuft eine Ereignis- und Entity-Extraktion. Bei Textsorten, in denen keine Ereignisse stecken, etwa reinen Zahlenreihen oder Konfigurationsdateien, trägt das Modell nichts, während die Kosten für Extraktion und Indizierung trotzdem anfallen. Für solche Korpora ist ein reiner Vektorindex die einfachere und billigere Lösung.
Der Unterschied zu GraphRAG in der Praxis
GraphRAG und SAG lösen beide das Problem, dass Ähnlichkeitssuche allein mehrstufige Fragen nicht trägt. Der Unterschied liegt im Zeitpunkt der Strukturbildung. GraphRAG extrahiert Triples, merged Entities, normalisiert Relationen und pflegt den Graphen global. Diesen Aufwand nennt das README ausdrücklich als Preis, zusammen mit den Schwierigkeiten bei inkrementellen Updates. SAG verlagert die Strukturbildung in die Abfrage: Die Hyperedge entsteht lokal, wenn SQL Ereignisse über gemeinsame Entities verbindet, und wird nicht vorab gebaut oder global gepflegt.
Das ist ein Tausch, kein Freifahrtschein. Entlastet wird die Pflege, belastet wird die Abfrage, weil die Verbindungsarbeit bei jeder Anfrage anfällt. Ob dieser Tausch bei großem Korpus und hoher Abfragelast aufgeht, lässt sich aus dem Repository nicht beantworten. Das README verweist auf Experimente mit HotpotQA, 2WikiMultiHopQA und MuSiQue und auf ein separates Repository Zleap-AI/SAG-Benchmark zur Reproduktion. Diese Zahlen sind nicht Teil des vorliegenden Materials und werden hier nicht wiedergegeben. Wer den Vergleich braucht, muss die Benchmark selbst nachfahren. Ein zweiter Unterschied betrifft die Ausgabe: SAG bindet Ergebnisse an Quell-Chunks zurück, GraphRAG-Antworten stützen sich typischerweise auf Graphbeziehungen und Community-Zusammenfassungen. Für Zitatpflicht ist der Chunk-Rückgriff der solidere Weg.
Wartung, Release-Takt und Lizenz
Der Release-Takt ist eng. Zwischen v1.8.4 am 30. August 2026 und v1.8.6 am 3. September 2026 liegen drei Veröffentlichungen in fünf Tagen, der letzte Push ins Repository stammt vom 9. September 2026. Für Nutzer heißt das: häufige Updates und damit ein wiederkehrender Upgrade-Aufwand. Wer die Desktop-Anwendung einsetzt, muss zusätzlich zur Python-Seite die Release-Artefakte pflegen, die das README über ein eigenes Badge ausweist. Ein stabiles Trägheitsmoment gibt es nicht.
Die Lizenz ist MIT, angegeben über ein Badge und die Datei LICENSE. Das ist permissiv und erlaubt kommerzielle Nutzung, Änderung und Weitergabe, sofern Lizenztext und Urheberrechtshinweis erhalten bleiben. Das ist keine Rechtsberatung, und wer SAG in ein Produkt einbettet, sollte die konkreten Pflichten selbst prüfen. Ein Punkt, der bei MIT-Projekten mit externen Modellen häufig übersehen wird: Die Lizenz deckt den Code, nicht die Modelle, die für Embedding und Extraktion aufgerufen werden. Deren Bedingungen hängen davon ab, welchen Anbieter man konfiguriert, und dazu macht der vorliegende Auszug keine Angabe. Auch der Umfang der Dokumentation ist ein Wartungsposten: Die CLI-Dokumentation liegt als eigene Datei unter docs/sag-cli.en.md, die chinesische Fassung als README-CN.md. Beide laufen neben dem Code her und können auseinanderdriften.
Redaktionelles Fazit
SAG passt zu einzelnen Entwicklern und kleinen Teams, die eine lokale, zitierfähige Wissensbasis für sich und einen Agenten betreiben wollen und die SQLite sowie LanceDB als Ablage akzeptieren. Wer eine mandantenfähige Mehrbenutzerlösung mit verteilter Indexpflege braucht, sollte zuerst die Backend-Frage klären, denn das Projekt startet ausdrücklich single-user. Vor dem Einsatz zu prüfen sind der Zustand der v1-Migration, die Vollständigkeit der Online-Retrieval-Dokumentation und ob der eigene Korpus die Ereignis-Entity-Extraktion überhaupt trägt. Erst danach lohnt der Blick in die Benchmark-Reproduktion unter Zleap-AI/SAG-Benchmark.
Community-Notizen