Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

LLM-Wiki-Pattern (Karpathy-Muster)¶

Das LLM-Wiki-Pattern ist ein von Andrej Karpathy (Mitgründer OpenAI, ehem. AI-Direktor bei Tesla) im April 2026 als GitHub-Gist veröffentlichtes Architekturmuster: Statt bei jeder Anfrage Rohdokumente per RAG (Retrieval-Augmented Generation) neu zu durchsuchen, lässt man ein LLM einmalig eine persistente, strukturierte Wiki aus den Quellen aufbauen — und fragt danach nur noch gegen dieses kompilierte Wissen ab. Diese Seite erklärt das Muster selbst; die konkrete Open-Source-Umsetzung davon ist OpenWiki (LangChain).

Hinweis: Primärquelle

Das Pattern ist als Prosa-Text (Prompt/Idee zum Einfügen in einen Agenten) veröffentlicht, nicht als fertiges Produkt: gist.github.com/karpathy/442a6bf555914893e9891c11519de94f.

Kernidee: Kompilieren statt Retrieval¶

Karpathys Analogie stammt aus der Softwareentwicklung: Ein Compiler übersetzt Quellcode einmalig in ein optimiertes Binary — man führt nicht bei jedem Programmstart den Quellcode erneut aus, sondern kompiliert einmal und nutzt danach das Artefakt.

Auf Wissensarbeit übertragen: RAG durchsucht bei jeder Anfrage erneut die Rohquellen und muss Zusammenhänge jedes Mal neu rekonstruieren. Das LLM-Wiki-Pattern dreht die Reihenfolge um — „compile deine Quellen zuerst":

Ein LLM liest die Rohquellen einmalig (oder inkrementell bei neuen Quellen).
Es synthetisiert die Inhalte in strukturierte, untereinander verlinkte Wiki-Seiten.
Alle folgenden Anfragen laufen gegen dieses kompilierte Artefakt — nicht mehr gegen die Rohquellen.

Tipp: Kein Ersatz für RAG, sondern eine Vorstufe

Das Pattern schließt klassisches RAG nicht aus — es reduziert nur, was zur Anfragezeit neu erschlossen werden muss. Für sehr große, sich schnell ändernde Quellenmengen bleibt eine Kombination aus beidem sinnvoll (siehe RAG- & KI-Zentrierte Wissensdatenbanken).

Architektur: Drei Schichten¶

graph TD
    Raw["raw/ — unveraenderliche Rohquellen<br/>(Artikel, PDFs, Notizen, Code)"] --> Agent["LLM-Agent"]
    Schema["CLAUDE.md / AGENTS.md — Schema<br/>(Konventionen, Workflows)"] --> Agent
    Agent -->|"Ingest"| Wiki["wiki/ — generierte Markdown-Seiten<br/>(Entitaeten, Konzepte, Querverweise)"]
    Wiki --> Index["index.md — Inhaltsverzeichnis"]
    Wiki --> Log["log.md — chronologisches Logbuch"]
    Query["Nutzerfrage"] -->|"liest gegen"| Wiki

Schicht	Ordner/Datei	Rolle
Rohquellen	`raw/`	Unveränderliche Datenbasis (Artikel, PDFs, Notizen). Der Agent liest sie, modifiziert sie aber nie.
Das Wiki	`wiki/`	LLM-generierte Markdown-Dateien mit Querverweisen — je eine strukturierte, Wikipedia-artige Seite pro Konzept/Entität, verlinkt über `[[wiki-links]]`.
Schema	`CLAUDE.md` / `AGENTS.md`	Dokumentiert Struktur und Konventionen des Wikis und definiert die Workflows für Ingestion, Abfragen und Wartung — die Instruktionsdatei, die der Agent bei jedem Lauf befolgt.

Kernoperationen¶

IngestQueryLint

Neue Quelle wird zu raw/ hinzugefügt. Der Agent liest sie, ordnet die Erkenntnisse ein, erstellt neue Wiki-Seiten oder aktualisiert bestehende — typischerweise werden pro Ingest-Lauf 10–15 Seiten berührt (neue Querverweise, aktualisierte Zusammenfassungen).

Eine Frage wird gegen das Wiki gestellt (nicht gegen die Rohquellen). Der Agent sucht die relevanten Wiki-Seiten und synthetisiert eine Antwort mit Zitaten/Links auf die jeweiligen Seiten.

Periodische Gesundheitsprüfung: Widersprüche zwischen Seiten, verwaiste Seiten (keine eingehenden Links), fehlende Querverweise. Entspricht im Prinzip dem, was check_orphaned_files.py in diesem Repository für die Nav-Struktur übernimmt (siehe Verwandte Themen).

Indexierung & Logbuch¶

index.md — Inhaltsverzeichnis mit Links, Einzeilern und Metadaten pro Kategorie. Entspricht funktional den index.md-Übersichtsseiten in diesem Repository (z. B. Dokumentenerstellung, Wikis & Notebooks).
log.md — chronologisches, append-only Logbuch mit konsistenten Präfixen, damit es maschinell parsebar bleibt (welche Quelle wann welche Seiten verändert hat).

Optional: Such-Tools¶

Bei kleiner Skalierung (bis grob 100 Quellen, einige hundert Seiten) reicht index.md als Sucheinstieg. Wächst das Wiki darüber hinaus, empfiehlt Karpathy qmd — eine lokale Suchmaschine für Markdown-Dateien mit hybrider BM25/Vektor-Suche und LLM-Reranking, vollständig on-device. Sie bringt sowohl eine CLI (für den Agenten) als auch einen MCP-Server (als natives Tool) mit. Alternativ lässt sich ein einfaches Suchskript passend zur eigenen Struktur per Vibe-Coding vom Agenten selbst erstellen.

Tipps & Tricks aus der Praxis¶

Karpathys Original-Gist beschreibt seinen persönlichen Workflow mit Obsidian als Wiki-Oberfläche. Die Tipps sind Obsidian-spezifisch, das zugrunde liegende Prinzip überträgt sich aber auf jedes Markdown-basierte Wiki (auch auf dieses Repository):

Obsidian Web Clipper — Browser-Erweiterung, die Webartikel direkt als Markdown in die Rohsammlung (raw/) überführt.
Bilder lokal speichern — in Obsidian unter „Dateien & Links" einen festen Anhang-Ordner setzen (z. B. raw/assets/) und „Anhänge für aktuelle Datei herunterladen" auf ein Tastenkürzel legen. Wichtig, weil LLMs eingebettete Bilder in Markdown nicht in einem Durchgang mitlesen — der Agent liest zuerst den Text und betrachtet referenzierte Bilder danach separat.
Graph-Ansicht — der schnellste Weg, die Form eines Wikis zu erfassen: welche Seiten Knotenpunkte (Hubs) sind, welche verwaist sind.
Marp — Markdown-basiertes Folienformat mit Obsidian-Plugin, um Präsentationen direkt aus Wiki-Inhalten zu generieren.
Dataview — Obsidian-Plugin für Abfragen über Frontmatter (Tags, Daten, Quellenzahl); erzeugt dynamische Tabellen/Listen, sofern der Agent konsistentes YAML-Frontmatter pflegt.
Git-Versionierung — das Wiki ist einfach ein Git-Repository aus Markdown-Dateien; Versionsverlauf, Branching und Zusammenarbeit gibt es dadurch „geschenkt".

Warum das Muster funktioniert¶

Karpathys zentrale These: „Die mühsame Arbeit bei Wissensbasen ist nicht das Lesen oder Denken — es ist die Buchhaltung." Menschen geben Wikis typischerweise auf, weil der Pflegeaufwand (Querverweise aktuell halten, Redundanzen vermeiden, Struktur konsistent halten) schneller wächst als der Nutzen. Ein LLM-Agent:

vergisst keine Querverweise und aktualisiert sie zuverlässig bei jeder Änderung,
bearbeitet mehrere betroffene Seiten in einem einzigen Durchlauf,
ermüdet nicht an der reinen „Buchhaltungsarbeit", die Menschen von der Wiki-Pflege abhält.

Die Rollenteilung bleibt dabei klar: der Mensch kuratiert Quellen und stellt Fragen — der Agent übernimmt Synthese und Pflege.

Konkrete Implementierung: OpenWiki (LangChain)¶

Das bekannteste Open-Source-Werkzeug, das dieses Pattern konkret umsetzt, ist OpenWiki von LangChain — ursprünglich für Code-Repositories gebaut (raw/ = Codebase, wiki/ = generierte Repo-Dokumentation), inzwischen auch im „Personal-Modus" für persönliche Wissensbasen mit externen Connectoren (Notion, Gmail, Git-Repos, Websuche) nutzbar.

Karpathy-Muster (allgemein)	OpenWiki-Umsetzung
`raw/` — Rohquellen	Codebase (Code-Modus) bzw. angebundene Connectoren (Personal-Modus)
`wiki/` — generiertes Wiki	`openwiki/*.md` bzw. `~/.openwiki/wiki/`
Schema-Instruktionsdatei	`INSTRUCTIONS.md`, plus Referenzen in `AGENTS.md`/`CLAUDE.md`
Ingest	`openwiki --init` / `openwiki code --update`
Query	interaktive CLI (`openwiki "Prompt"`)
Lint	Diff-Analyse bei `--update` prüft betroffene Seiten

Details zu Installation, CLI-Befehlen und CI-Integration siehe die eigene Seite OpenWiki: Repo-Dokumentations-Agent (LangChain).

Achtung: Muster ≠ Produkt

Das Karpathy-Muster selbst ist keine Software, sondern eine Idee/ein Prompt-Template. Wer es ohne OpenWiki oder ein vergleichbares Werkzeug nachbauen will, benötigt einen eigenen Agenten (z. B. Claude Code, Antigravity CLI) mit einer Instruktionsdatei, die die drei Schichten (raw/, wiki/, Schema) sowie Ingest/Query/Lint als Workflows definiert.

Bezug zu diesem Repository¶

Dieses Repository setzt bereits Teile des Musters ein, ohne es explizit so zu benennen:

Schema-Schicht: CLAUDE.md übernimmt die Rolle der Instruktionsdatei — sie dokumentiert Struktur (docs/<bereich>/), Konventionen und Workflows.
Lint-Operation: .gemini/scripts/check_orphaned_files.py prüft auf verwaiste Seiten, der doc-checker-Subagent erweitert das um Build-, Link- und Mermaid-Prüfung.
Fehlender Teil: Es gibt hier bewusst keine automatische Ingest-Operation, die eigenständig neue Wiki-Seiten aus Rohquellen generiert — Inhalte werden weiterhin kuratiert von Hand angelegt (siehe zensical-docs-Skill, Abschnitt „Neue Seite anlegen"). Das entspricht dem Human-in-the-Loop-Prinzip, das auch für autonome Wiki-Pflege-Agenten in diesem Repo gilt.