sage-wiki: ein von LLMs kompiliertes Wiki mit Wissensgraph

Dokumente hinein, ein Wiki mit Wissensgraph heraus

Abschnitt 1, Absatz 1: sage-wiki ist eine in Go geschriebene Graph-Speicher- und Wissensbasis. Das README beginnt mit der Beschreibung dessen, was das Projekt mit Dokumenten tut: Man legt Dateien in einen Quellordner, und ein LLM-Compiler macht daraus ein verlinktes Wiki plus einen Wissensgraph. Menschen browsen das Ergebnis als Obsidian-kompatibles Markdown; Agenten fragen über das Model Context Protocol ab, das als Server mit 19 Werkzeugen bereitgestellt wird. Das Projekt geht auf Andrej Karpathys Idee einer LLM-kompilierten persönlichen Wissensbasis zurück und ist auf dem Sage Framework aufgebaut. Das README verortet es von einer Overlay-Schicht über einen bestehenden Obsidian-Vault bis hin zu einem unternehmensweiten Wissensgraph auf PostgreSQL.

Abschnitt 1, Absatz 2: sage-wiki kompiliert Dokumente in ein verlinktes Wiki mit Wissensgraph. Das README beschreibt eine in Go geschriebene Anwendung, bei der Menschen Markdown durchsuchen und Agenten über MCP abfragen. Die zentrale Idee ist also eine Compile-Pipeline: Quellen werden verarbeitet, Entitäten und Beziehungen in eine navigierbare Struktur überführt und anschließend über mehrere Oberflächen gelesen.

Der Graph ist ein Abrufkanal, keine Nebenansicht

Abschnitt 2, Absatz 1: Vektorsuche liefert Passagen, die der Anfrage ähneln; ein Graph hält zusätzlich fest, wie Dinge zusammenhängen, sodass Fragen mit zwei oder drei Sprüngen per Traversierung beantwortet werden. sage-wiki baut diesen Graph während der Kompilierung auf, statt eine zweite Datenbank zu pflegen, die synchron gehalten werden müsste. Der Standard-Graph verbindet Konzepte, bei denen Relationsschlüsselwörter im selben Block mit einem [[wikilink]] gemeinsam auftreten. Optionale Durchläufe ergänzen Belege: Die Triple-Extraktion (ein zusätzlicher LLM-Aufruf pro Dokument) erzeugt typisierte Entitäten und Relationen mit Belegspanne, Konfidenz von 0 bis 1 und Quelldokument. Die Entitätsauflösung führt Varianten wie K8s und Kubernetes zu einem Knoten zusammen; Vorschläge sind standardmäßig review-pflichtig und werden ab einem Schwellwert von 0,85 automatisch übernommen. Die Suche fusioniert drei Kanäle: lexikalisches BM25, Vektor und Graphnähe, zusammengeführt per gewichtetem RRF. Kanten sind bi-temporal; ein Widerspruch macht die alte Kante ungültig, und as_of-Abfragen beantworten, was das Wiki zu einem früheren Zeitpunkt glaubte.

Abschnitt 2, Absatz 2: Die Datenformate und Eingangsverzeichnisse sind für das Ergebnis entscheidend. Vor einem großen Vault sollte ein kleiner Ordner mit wenigen Dokumenten kompiliert werden. Danach gehören erzeugte Markdown-Seiten, Links, Graphbeziehungen und MCP-Antworten in den Vergleich. So lässt sich feststellen, ob die eigene Dokumentstruktur von sage-wiki verstanden wird.

Die Compile-Pipeline und die unterstützten Formate

Abschnitt 3, Absatz 1: Die Pipeline verarbeitet Markdown, PDF, Word, Excel, PowerPoint, CSV (bis zu 1000 Zeilen), EPUB, E-Mail, Klartext, Untertitel, Bilder (mit Bildunterschriften durch ein Vision-LLM) und Code. Nicht gelistete Formate können über externe Parser behandelt werden: Skripte in beliebiger Sprache, die Standardeingabe lesen und Text auf Standardausgabe schreiben, nach doppeltem Opt-in als Subprozesse ausgeführt. Die Kompilierung ist gestuft: Stufe 0 indexiert mit FTS5, Stufe 1 fügt Vektor-Embeddings hinzu, Stufe 2 wendet Codeparser ohne LLM an, Stufe 3 ist eine vollständige LLM-Kompilierung mit Zusammenfassung, Konzeptextraktion und Artikel-Erstellung. Das Projektlayout im README zeigt raw/ für Quellen und wiki/ für kompiliertes Markdown mit Ordnern für summaries, concepts, under_review und archive sowie einer einzelnen SQLite-Datei, die FTS-Index, Vektoren, Ontologie und Warteschlange enthält.

Abschnitt 3, Absatz 2: Das Projekt ist vor Version 1.0 und fordert laut README, Versionen festzupinnen. Diese Einordnung ist praktisch wichtig: Ein Update kann Parser, Ausgabe oder MCP-Schema verändern. Ein reproduzierbarer Test sollte deshalb den Commit, die Go-Version, die Eingabedateien und den erzeugten Ausgabeordner aufzeichnen.

Oberflächen für Agenten und Menschen

Abschnitt 4, Absatz 1: Über denselben Daten liegen drei Oberflächen. Das Terminal-Dashboard hat vier Reiter: Browsen, Suche, Q&A und eine Live-Compile-Überwachung. Die Web-Oberfläche, gebaut mit Preact und Tailwind und über go:embed hinter einem Build-Tag eingebettet, bietet einen Artikel-Browser mit gerendertem Markdown, Hybridsuche, eine kraftbasierte Visualisierung des Wissensgraphs und Streaming-Q&A. Der MCP-Server stellt 19 Werkzeuge über stdio oder SSE bereit, darunter wiki_graph_query für mehrstufige Fragen, die nur auf serialisierten Graphkanten beruhen, und wiki_capture, um Erkenntnisse zurückzuschreiben. Eine experimentelle /v1-HTTP-API macht dieselben Werkzeuge als REST-Routen mit Bearer-Authentifizierung und asynchronen Jobs für Compile und Lint verfügbar. Typisierte Python- und TypeScript-Clients decken die /v1-Oberfläche ab; Go-Programme können HTTP ganz überspringen und pkg/sagewiki über einen In-Process-MCP-Transport einbetten.

Abschnitt 4, Absatz 2: Die drei Abfrageoberflächen richten sich an unterschiedliche Nutzer. Markdown ist für Menschen sichtbar, der Wissensgraph dient als Abrufkanal und MCP verbindet Agenten mit dem Bestand. Eine schöne Wiki-Seite beweist daher noch nicht, dass eine Agentenfrage die gewünschte Beziehung findet. Beide Wege müssen mit denselben Fragen verglichen werden.

Betrieb, Kosten und große Vaults

Abschnitt 5, Absatz 1: Der Speicher ist standardmäßig eine einzelne SQLite-Datei; für Serverbereitstellungen sind PostgreSQL mit pgvector dokumentiert. Abfrageausgaben werden unter Quarantäne gestellt, bis sie fundiert, per Konsens bestätigt oder manuell befördert sind; das README nennt diesen Arbeitsablauf output trust. Die Compile-Pipeline verfolgt Token-Verbrauch und schätzt Kosten, aktiviert standardmäßig Prompt-Caching (das README nennt 50 bis 90 Prozent Einsparung bei Eingabe-Tokens für Anthropic, Gemini und OpenAI) und unterstützt Batch-APIs, die die Kosten großer Kompilierungen halbieren. Für große Vaults indexiert die gestufte Kompilierung zuerst alles; das README nennt etwa 5,5 Stunden für einen Vault mit 100.000 Dokumenten auf Stufe 1, danach läuft die vollständige LLM-Kompilierung bedarfsgesteuert. Zugangsdaten werden, wo verfügbar, im OS-Keychain gespeichert; auth migrate verschiebt dateibasierte Zugangsdaten.

Abschnitt 5, Absatz 2: README-Benchmarks sind mit ihren genannten Einschränkungen zu lesen. Sie liefern Anhaltspunkte für Skalierung und Abruf, aber keine Garantie für die Geschwindigkeit eines fremden Vaults. Speicherbedarf, Dokumentmenge und Änderungsrate sollten mit den eigenen Dateien gemessen werden.

Packs, Benchmarks und Lizenz

Abschnitt 6, Absatz 1: Acht Offline-Beitragspacks bündeln Ontologietypen, Prompts und Skill-Trigger für Bereiche wie akademische Forschung, Softwareentwicklung und Rechtskonformität. Das README berichtet zwei Benchmark-Suiten: Speicher-Benchmarks auf veröffentlichten Datensätzen, bewertet durch ein LLM (LOCOMO 92,0 Prozent, LongMemEval 93,3 Prozent, BEAM 100K 0,691 mittleres Nugget), mit dem ausdrücklichen Hinweis, dass es sich um begrenzte Stichproben und keinen gleichartigen Vergleich mit den veröffentlichten Mem0-Platform-Zahlen handelt; und eine Qualitäts- und Leistungsauswertung mit einem Median von 87,4 Prozent über zehn Wikis. Das Projekt ist vor 1.0; das README rät wiederholt, Versionen festzupinnen. Das Repository ist unter MIT lizenziert, was Rechte zur Nutzung, Vervielfältigung, Änderung, Zusammenführung, Veröffentlichung, Verteilung, Unterlizenzierung und zum Verkauf von Kopien einräumt und erklärt, dass die Software wie besehen ohne Gewähr bereitgestellt wird. Der Lizenztext sagt nichts über Support, Sicherheitslage oder Wartungszusagen.

Abschnitt 6, Absatz 2: Packs, Konfiguration und Lizenz ergänzen den Kernbetrieb. Die Lizenzdatei muss bei einer Weitergabe beachtet werden; sie ist keine Sicherheitsprüfung. sage-wiki passt zu Teams, die Markdown-Bestände graphbasiert erschließen und MCP bewusst betreiben. Für eine sofortige Produktionswissensbasis fehlen im README belastbare Zusagen zu Sicherheit und Langzeitpflege.

Redaktionelles Fazit

sage-wiki befindet sich vor Version 1.0; das README rät wiederholt, Versionen festzupinnen. Die Repository-Unterlagen belegen die Compile-Pipeline, drei Abfrageoberflächen und Benchmark-Zahlen mit genannten Einschränkungen, nicht aber Produktionsverhalten, Sicherheitslage oder langfristige Wartungszusagen.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes