llmwiki: Rohquellen zu einem zitatfähigen Wiki kompilieren
The knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.
Auf einen Blick
- Was ist das?
- llm-wiki-compiler übersetzt Papers, Notizen und Transkripte in ein verlinktes Markdown-Wiki mit Provenienz. Der interessanteste Teil ist nicht der Compiler, sondern das fail-closed Profil, das Typen, Lifecycle und Schreibpfad verbindlich macht.
- Für wen ist es gedacht?
- Wer eine dauerhafte, prüfbare Wissensbasis aus Papers, Transkripten oder Redaktionsmaterial braucht und bereit ist, ein .llmwiki/profile.json zu pflegen, findet hier einen Compiler mit echtem Schreibpfad. Wer schnelle Ad-hoc-Suche über wechselnde Rohlogs will, sollte es nicht einsetzen.
- 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 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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 der Compiler adressiert
Die Ausgangslage ist bekannt: Ein Agent bekommt bei jeder Anfrage einen Stapel loser Dateien vorgelegt und rekonstruiert Wissen, das bereits irgendwo geschrieben steht. Das README beschreibt den Gegenentwurf als Umsetzung des LLM-Wiki-Patterns von Karpathy: Wissen einmal kompilieren, statt es zur Abfragezeit neu zu entdecken. Das Ergebnis sind dauerhafte Seiten, die Struktur, Provenienz, Review-Status und Retrieval-Metadaten ansammeln.
Die Zielgruppe ist enger, als die Themenliste vermuten lässt. Genannt werden Papers, Notizen, READMEs, Transkripte, PDFs, Bilder und Webseiten als Eingangsmaterial. Der Compiler richtet sich an Teams, die dieses Material über Wochen kuratieren und dabei nachvollziehen wollen, welcher Satz aus welcher Quelldatei stammt. Das README grenzt selbst ab: kein allgemeiner Static-Site-Generator, keine schwere Ontologie-Datenbank, kein Ersatz für Ad-hoc-Suche über schnell wechselnde Rohlogs. Wer stündlich neue Logs durchsucht, ist hier falsch.
Zweiphasige Extraktion und typisierte Seiten
Der Kern ist eine zweiphasige LLM-Pipeline. Erst werden Konzepte extrahiert, dann generiert der Compiler typisierte Seiten: concept, entity, comparison und overview. Aus dem Material geht nicht hervor, welche Prompts dabei verwendet werden oder wie die Konzeptauswahl gewichtet wird. Diese Lücke ist relevant, weil die Qualität der ersten Phase die gesamte Ausgabe bestimmt.
Darüber liegt die Ebene der Configurable Lifecycle Profiles. Ein validiertes .llmwiki/profile.json deklariert typisierte Entitäten mit Feldern, gerichtete Relationen, Lifecycle-Zustände mit Übergangsbedingungen, mehrstufige Workflows, hash-gepinnte Artefakte, Connector-Bindungen, Content-Tiers und Retrieval-Policy. Das README betont, dass diese Regeln vom Runtime durchgesetzt werden und nicht als Prompt-Konvention bestehen bleiben. Ungültige Profile und Schreibvorgänge, die ein deklariertes Gate umgehen, scheitern fail-closed.
Für die Abfrage nennt das README hybride Retrieval: semantische Chunk-Suche, BM25-Reranking und Expansion über den Wikilink-Graphen. Wie diese drei Signale gewichtet kombiniert werden, steht nicht im Material. Die Ausgabe bleibt Markdown, und Absätze sowie Aussagen zitieren Quelldateien mit Zeilenbereichen. llmwiki lint prüft diese Links.
Vom Profil zum laufenden Projekt
Das README zeigt drei Wege zum Start. Der erste ist das eigene Profil, Entitätstyp für Entitätstyp:
llmwiki profile init research --entity paper
Der zweite führt über Templates. Zuerst llmwiki template list, dann llmwiki template inspect autosci, dann llmwiki template init autosci. Das autosci-Pack liefert Papers, Ideen, Experimente, Manuskripte, Evidence-Artefakte, Workflows und einen Crossref-Import. Das newsroom-Pack wendet dieselbe Mechanik auf Artikel, Desks, Bylines und redaktionelle Workflows an. Nach dem Scaffolding stehen llmwiki profile validate und llmwiki workflow list bereit.
Für den Alltag nennt das README weitere Unterbefehle: llmwiki view öffnet eine schreibgeschützte Browser-Oberfläche mit Suche, Seitenmetadaten, Graph-Exploration, Freshness-Badges und Citation-Chips. llmwiki serve stellt Ingest, Compile, Query, Lint, Read, Status, Eval, Context-Pack und OKF-Austausch als MCP-Werkzeuge bereit. llmwiki eval berichtet Health-Score, Verteilung pro Seite, Gesundheitszustand des Wikilink-Graphen, Citation-Coverage und -Precision, Korpusstatistiken und Regressionsdeltas. llmwiki refresh --stale repariert veraltete Seiten, ohne neue Quellen anzufassen. llmwiki next zeigt anstehende Arbeit.
Für TypeScript-Integrationen gibt es createWiki({ root }) mit ingest, compile, query, context, status, export, eval und OKF-Import/Export. Als Provider listet das README Anthropic, den Claude Agent SDK mit lokalem Login, die OpenAI Codex CLI mit lokalem Login, OpenAI-kompatible Server, Ollama, GitHub Copilot, Atlas Cloud, OrcaRouter und lokale OpenAI-kompatible Runtimes. Ob alle Provider dieselben Profilfunktionen unterstützen, sagt das Material nicht.
Wo das Modell an seine Grenzen stößt
Der fail-closed Schreibpfad ist die stärkste Eigenschaft und die größte Reibungsfläche zugleich. Wer ein Profil mit Lifecycle-Gates deklariert, kann nicht mehr einfach eine Seite schreiben. Jeder Übergang verlangt die deklarierte Evidenz. Das ist gewollt, kostet aber Einarbeitung, und das README liefert kein Beispiel für einen fehlgeschlagenen Schreibversuch, an dem sich das Verhalten nachvollziehen ließe.
Der zweite Vorbehalt betrifft die Abgrenzung. Das README schließt Ad-hoc-Suche über schnell wechselnde Rohlogs ausdrücklich aus. Ein Team, das einen Index über täglich neu eintreffende Logs braucht, gewinnt hier nichts: Der Compiler will kuratiertes Material, das sich zu kompilieren lohnt. Auch als allgemeiner Static-Site-Generator ist das Werkzeug nicht gedacht.
Dazu kommt die Frage der Bewertung. Das Eval-Harness liefert Health-Scores und Citation-Precision, aber diese Zahlen messen die Ausgabe gegen die eigene Struktur, nicht gegen die inhaltliche Richtigkeit. Ein Wiki kann formal gesund und trotzdem falsch sein. Wer die Qualität an einem externen Korpus messen will, muss das selbst bauen.
Wo llmwiki gegen Alternativen steht
Der naheliegende Vergleich ist ein Vektorindex über dieselben Rohdateien, etwa ein Embedding-Store plus Retriever. Der Unterschied liegt im Zeitpunkt der Arbeit. Ein Vektorindex speichert Chunks und überlässt die Struktur dem Modell zur Abfragezeit. llmwiki extrahiert einmal und schreibt typisierte Seiten mit Zitaten, Review-Status und Lifecycle. Dafür zahlt man beim Kompilieren, nicht bei jeder Abfrage.
Der zweite Vergleich ist ein klassisches Wiki oder eine Notizablage wie Obsidian. Die Themenliste nennt Obsidian ausdrücklich, und die Ausgabe ist Markdown mit Wikilinks. Der Unterschied: llmwiki erzeugt die Seiten aus Quellen und führt Provenienz mit, statt auf manuelles Schreiben zu setzen. Das hilft bei Papers und Transkripten, weniger bei kurzen eigenen Notizen, die schneller direkt getippt sind.
Der dritte Vergleich ist ein Wissensgraph mit Ontologie. Das README grenzt sich gegen eine schwere Ontologie-Datenbank ab. Die Profile erlauben typisierte Entitäten und gerichtete Relationen, aber der Austausch läuft über Markdown-nahe Formate: OKF, JSON, JSON-LD, GraphML, Marp und llms.txt. Wer SPARQL-Abfragen über eine formale Ontologie braucht, ist hier an der falschen Stelle.
Pflegeaufwand, Releases und Lizenz
Zwischen v1.0.0 im Juli und v1.2.0 im September liegen zwei Minor-Releases in zwei Monaten. Das README kennzeichnet CLP als neu in 1.0 und betont Abwärtskompatibilität: Ohne .llmwiki/profile.json greift das eingebaute Standardprofil mit concepts-and-queries, das Verhalten vor 1.0 bleibt erhalten. Wer bereits ein Projekt betreibt, muss also nicht sofort migrieren. Wer neu anfängt, sollte entscheiden, ob das Standardprofil reicht oder ob eigene Entitätstypen den Pflegeaufwand wert sind.
Dieser Aufwand ist real. Ein Profil mit Entitäten, Relationen, Lifecycle-Zuständen, Übergangsbedingungen, Workflows und Retrieval-Policy ist ein Vertrag, den jemand pflegen muss. Ändert sich das Domänenmodell, muss das Profil mitziehen, sonst scheitern Schreibvorgänge fail-closed. Das ist der Preis für Durchsetzung statt Konvention.
Lizenziert ist das Projekt unter MIT. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung des Lizenzhinweises. Templates werden laut README als Konfiguration und Beispiele ausgeliefert, nie als ausführbarer Plugin-Code. Für signierte Distributionen nennt das README llmwiki template publish mit Ed25519; der Text bricht an dieser Stelle ab, Details zur Signaturprüfung fehlen im vorliegenden Material. Das ist ein Punkt, der vor einem produktiven Einsatz gegen die Dokumentation auf llmwiki.atomicstrata.ai geprüft werden sollte.
Redaktionelles Fazit
Wer eine dauerhafte, prüfbare Wissensbasis aus Papers, Transkripten oder Redaktionsmaterial braucht und bereit ist, ein .llmwiki/profile.json zu pflegen, findet hier einen Compiler mit echtem Schreibpfad. Wer schnelle Ad-hoc-Suche über wechselnde Rohlogs will, sollte es nicht einsetzen. Vor dem ersten Commit: llmwiki profile validate laufen lassen und prüfen, ob die eigenen Entitätstypen im Profil tatsächlich als Gates abgebildet sind.
Community-Notizen