LLM-Wiki – Persönliche Wissensdatenbanken mit KI aufbauen

Ein Entwurfsmuster für den Aufbau persönlicher Wissensdatenbanken, bei dem ein LLM eine persistente, verlinkte Wiki-Struktur inkrementell aufbaut und pflegt – anstatt Dokumente lediglich bei jeder Anfrage neu zu durchsuchen (RAG).

Die Kernidee

Der übliche Ansatz für LLMs und Dokumente ist RAG (Retrieval-Augmented Generation): Dateien werden hochgeladen, das Modell sucht bei jeder Frage relevante Passagen heraus und antwortet. Wissen häuft sich dabei nicht an – bei jeder Frage beginnt die Synthese von vorn.

Das LLM-Wiki-Muster ist anders: Das LLM baut und pflegt kontinuierlich ein persistentes Wiki – eine strukturierte, verlinkte Sammlung von Markdown-Dateien. Wenn eine neue Quelle hinzukommt, liest das LLM sie, extrahiert die relevanten Informationen und integriert sie in das bestehende Wiki: Seiten werden aktualisiert, Querverweise gezogen, Widersprüche markiert, Synthesen verfeinert.

Das Wiki ist ein persistentes, sich anreicherndes Artefakt. Die Querverweise sind bereits vorhanden. Widersprüche wurden bereits markiert. Die Synthese spiegelt alles Gelesene wider – und wird mit jeder neuen Quelle reicher.

Das Besondere: Die Nutzerin schreibt das Wiki selbst nie (oder kaum). Das LLM übernimmt das gesamte Schreibwerk – Zusammenfassungen, Querverweise, Ablage, Buchführung. Die Nutzerin kuratiert Quellen, stellt Fragen und denkt über die Bedeutung nach.

Architektur (drei Ebenen)

1. Rohdokumente (raw/)

Die kuratierten Quelldokumente: Artikel, Paper, Bilder, Datendateien. Sie sind unveränderlich – das LLM liest sie, aber ändert sie nie. Dies ist die Quelle der Wahrheit.

2. Das Wiki

Ein Verzeichnis LLM-generierter Markdown-Dateien: Zusammenfassungen, Entity-Seiten, Konzeptseiten, Vergleiche, ein Überblick, eine Synthese. Das LLM besitzt diese Ebene vollständig. Es erstellt Seiten, aktualisiert sie bei neuen Quellen, pflegt Querverweise und hält alles konsistent.

3. Das Schema (z. B. CLAUDE.md)

Ein Konfigurationsdokument, das dem LLM erklärt, wie das Wiki aufgebaut ist, welche Konventionen gelten und welche Abläufe bei Ingest, Abfragen und Pflege zu befolgen sind. Dieses Dokument macht das LLM zu einem disziplinierten Wiki-Pfleger statt zu einem generischen Chatbot. Nutzerin und LLM entwickeln es gemeinsam weiter.

Kernoperationen

Ingest

Eine neue Quelle wird in die Rohsammlung abgelegt und das LLM angewiesen, sie zu verarbeiten. Ablauf: Das LLM liest die Quelle, bespricht die wichtigsten Erkenntnisse, schreibt eine Zusammenfassungsseite im Wiki, aktualisiert den Index, aktualisiert relevante Entity- und Konzeptseiten und hängt einen Eintrag an das Log an. Eine einzige Quelle kann 10–15 Wiki-Seiten berühren.

Query

Fragen werden gegen das Wiki gestellt. Das LLM sucht relevante Seiten, liest sie und synthetisiert eine Antwort mit Quellenangaben. Antworten können verschiedene Formen annehmen: Markdown-Seite, Vergleichstabelle, Präsentation (Marp), Diagramm. Gute Antworten können als neue Wiki-Seiten abgelegt werden – so fließen auch Erkundungen ins Wissensarchiv ein.

Lint

Periodische Gesundheitsprüfung des Wikis: Widersprüche zwischen Seiten aufdecken, veraltete Behauptungen markieren, verwaiste Seiten (ohne eingehende Links) finden, wichtige Konzepte ohne eigene Seite identifizieren, fehlende Querverweise ergänzen, Datenlücken für eine Websuche vormerken.

Navigationshilfen: Index und Log

index.md ist inhaltsorientiert: ein Katalog aller Wiki-Seiten mit Link, Ein-Zeilen-Beschreibung und optionalen Metadaten, nach Kategorien geordnet. Das LLM liest ihn vor jeder Abfrage zuerst, um relevante Seiten zu finden. Funktioniert überraschend gut bis ~100 Quellen / mehrere Hundert Seiten, ohne Embedding-Infrastruktur.

log.md ist chronologisch: ein append-only-Protokoll aller Vorgänge (Ingests, Abfragen, Lint-Durchläufe). Mit konsistentem Präfix (z. B. ## [2026-04-02] ingest | Titel) wird das Log mit einfachen Unix-Tools durchsuchbar: grep "^## \[" log.md | tail -5 liefert die letzten 5 Einträge.

Anwendungsbeispiele

Optionale Werkzeuge

• qmd: Lokale Suchmaschine für Markdown-Dateien mit hybridem BM25/Vektor-Suche und LLM-Re-Ranking. Hat eine CLI (LLM kann sie aufrufen) und einen MCP-Server. Nützlich, wenn der Index allein nicht mehr ausreicht.
• Obsidian Web Clipper: Browser-Extension, die Web-Artikel in Markdown konvertiert – schnell Quellen in die Rohsammlung bringen.
• Bilder lokal speichern: Obsidian kann Anhänge in ein festes Verzeichnis (z. B. raw/assets/) herunterladen. LLMs müssen Text zuerst lesen und Bilder danach separat betrachten.
• Obsidian Graph View: Zeigt die Struktur des Wikis – vernetzte Seiten, Hubs, verwaiste Seiten.
• Marp: Markdown-basiertes Präsentationsformat. Nützlich für die Erstellung von Folien direkt aus Wiki-Inhalten.
• Dataview: Obsidian-Plugin für Abfragen über Frontmatter-Metadaten – erzeugt dynamische Tabellen und Listen.
• Git: Das Wiki ist ein Git-Repository aus Markdown-Dateien – Versionsgeschichte, Branching und Kollaboration inklusive.

Warum das funktioniert

Der mühsame Teil einer Wissensdatenbank ist nicht das Lesen oder Denken – es ist die Buchführung. Querverweise aktualisieren, Zusammenfassungen aktuell halten, Widersprüche notieren, Konsistenz über Dutzende Seiten wahren. Menschen geben Wikis auf, weil der Pflegeaufwand schneller wächst als der Nutzen.

LLMs werden nicht müde, vergessen nicht, einen Querverweis zu aktualisieren, und können in einem Durchgang 15 Dateien anfassen. Das Wiki bleibt gepflegt, weil die Pflegekosten nahezu null sind.

Der Gedanke knüpft an Vannevar Bushs Memex (1945) an – ein persönlicher, kuratierter Wissensspeicher mit assoziativen Pfaden zwischen Dokumenten. Das, was Bush nicht lösen konnte: Wer macht die Pflege? Das LLM übernimmt das.

Quellen

• llm-wiki (Original-Gist von Andrej Karpathy) — externe Quelle
• Quelldatei ansehen — archiviertes Original