LLM-Wiki 2026: Wie Karpathys Pattern die persönliche Wissensdatenbank revolutioniert

📷 "Los desafíos de la sustentabilidad - NAR, UASLP, México, 2007" by Lucy Nieto is licensed under CC BY-ND 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nd/2.0/.

Andrej Karpathy, Mitgründer von OpenAI und ehemaliger KI-Direktor bei Tesla, veröffentlichte im April 2026 ein unscheinbares GitHub Gist mit dem Titel „llm-wiki". Es war kein Produkt-Launch und keine wissenschaftliche Publikation – lediglich eine Idee, die er als Kopiervorlage für KI-Agenten wie Claude Code oder Codex gedacht hatte. Die Resonanz war überwältigend: Innerhalb weniger Tage verzeichnete das Gist über 5.000 Sterne, Tausende Forks und Dutzende Neuimplementierungen auf GitHub. VentureBeat, DataCamp und zahlreiche Tech-Blogs griffen das Konzept auf. Was steckt hinter dem Hype, und warum könnte der LLM-Wiki-Ansatz die Art und Weise verändern, wie wir Wissen mit KI verwalten?

Das Problem: Warum Wissensdatenbanken scheitern

Jeder Wissensarbeiter kennt das Phänomen: Ein neues Notion-Projekt oder Obsidian-Vault startet voller Enthusiasmus – nach wenigen Monaten liegen hunderte Seiten brach, Querverweise sind veraltet, Zusammenfassungen existieren nicht. Der Grund ist einfach: Das Sammeln von Quellen ist leicht, das Organisieren ist schwer, und das dauerhafte Pflegen ist bei steigender Menge praktisch unmöglich. Das manuelle Aktualisieren von Querverweisen, das Erkennen von Widersprüchen und das Erstellen von Zusammenfassungen kostet mehr Zeit, als die meisten bereit sind zu investieren.

Karpathys Beobachtung: LLMs sind für genau diese Buchhaltungsarbeit prädestiniert. Sie lesen Dokumente, identifizieren Schlüsselkonzepte, erstellen Zusammenfassungen, generieren Querverweise und erkennen Widersprüche – mühelos, konsistent und zu vernachlässigbaren Kosten. Der Mensch kuratiert, was hineinkommt; das LLM erledigt den Rest.

Die Drei-Schichten-Architektur

Das LLM-Wiki-Pattern definiert drei klar getrennte Schichten:

1. Rohquellen (raw/): Eine Sammlung unveränderlicher Quelldokumente – Artikel, Papers, Code-Repos, Daten. Das LLM liest aus diesem Ordner, verändert ihn aber nie. Jede Behauptung im Wiki lässt sich auf eine Quelldatei zurückverfolgen.

2. Das Wiki (wiki/): Ein Verzeichnis LLM-generierter Markdown-Dateien – Konzeptseiten, Entitätsseiten, Quellenzusammenfassungen, Vergleichstabellen. Das LLM besitzt diese Schicht vollständig: Es legt Seiten an, aktualisiert sie bei neuen Quellen, pflegt Querverweise und erkennt Widersprüche. Zwei Spezialdateien helfen bei der Navigation: index.md (Inhaltsverzeichnis, aktualisiert bei jedem Ingest) und log.md (anhangendes Operationslog).

3. Das Schema (CLAUDE.md oder AGENTS.md): Die wichtigste Datei des gesamten Systems. Sie definiert die Wiki-Struktur, Namenskonventionen, Seitenvorlagen und Arbeitsabläufe. Sie verwandelt ein generisches LLM in einen disziplinierten Wissensarbeiter.

Die drei Operationen: Ingest, Query, Lint

Das Pattern definiert drei Kernoperationen:

Ingest: Der Nutzer legt eine neue Quelle im raw/-Ordner ab und fordert das LLM auf, sie zu verarbeiten. Der Agent liest das Dokument, diskutiert die Kernaussagen, schreibt eine Zusammenfassungsseite, aktualisiert das Inhaltsverzeichnis und überarbeitet alle betroffenen Konzept- und Entitätsseiten – typischerweise zehn bis fünfzehn Dateien pro Quelle.

Query: Der Nutzer stellt eine Frage gegen das Wiki. Der Agent durchsucht das Inhaltsverzeichnis, liest die relevanten Seiten und synthetisiert eine Antwort mit Quellenangaben. Wichtige Erkenntnis: Gute Antworten können als neue Seiten ins Wiki zurückfließen und so den Wissensschatz weiter anreichern.

Lint: In regelmäßigen Abständen prüft der Agent die Gesundheit des Wikis: Widersprüche zwischen Seiten, veraltete Behauptungen, verwaiste Seiten ohne eingehende Links, fehlende Querverweise und Datenlücken, die sich durch eine Websuche schließen ließen.

LLM Wiki vs. RAG: Ein fundamentaler Unterschied

Der entscheidende Unterschied zwischen klassischem RAG und einem LLM Wiki liegt im Zeitpunkt der Wissensarbeit. RAG-Systeme rufen bei jeder Anfrage relevante Textfragmente aus einem Vektorindex ab und synthetisieren daraus eine Antwort – bei jeder Frage neu, ohne dass etwas akkumuliert. Das LLM Wiki hingegen kompiliert das Wissen bereits beim Hinzufügen einer Quelle. Die Synthesearbeit geschieht einmalig und persistent; die Abfrage liest dann aus einem bereits durchdachten Fundament.

Beide Ansätze haben ihre Berechtigung. RAG eignet sich besser für hochdynamische Daten (z. B. aktuelle Support-Tickets) und Szenarien, in denen niedrige Latenz wichtiger ist als tiefes Verständnis. Das LLM Wiki brilliert bei langlebigem, sich akkumulierendem Wissen – Forschungsthemen, Produktdokumentation, strategische Analysen – und ist in der Praxis oft eine Ergänzung: Sobald das Wiki über eine bestimmte Größe hinauswächst, kann RAG über die Wiki-Seiten selbst gelegt werden.

Karpathy selbst berichtete, dass sein Wiki zu einem einzelnen Forschungsthema auf etwa 100 Artikel und 400.000 Wörter angewachsen war – länger als die meisten Dissertationen –, ohne dass er selbst auch nur einen Satz direkt geschrieben hatte.

Fazit

Das LLM-Wiki-Pattern ist mehr als ein weiterer KI-Hype. Es adressiert ein fundamentales Problem der Wissensarbeit: die Wartungslast, an der fast alle persönlichen Wissensdatenbanken scheitern. Indem es LLMs die lästige Buchhaltungsarbeit erledigen lässt und dem Menschen die Rolle des Kurators und Entdeckers zuweist, schafft es ein Modell für Wissen, das mit jeder neuen Quelle reicher wird, statt bei jeder Anfrage von null zu beginnen.

Die Open-Source-Community hat das Konzept begeistert aufgenommen: Innerhalb weniger Wochen entstanden Dutzende Implementierungen für Claude Code, OpenAI Codex und Gemini CLI. Die Integration mit Obsidian als Frontend ist ein wiederkehrendes Muster. Wer sein persönliches Wissensmanagement auf eine neue Stufe heben möchte, findet im LLM Wiki einen praktikablen, lokal betreibbaren Ansatz – jenseits von Cloud-Abhängigkeiten und proprietären RAG-Plattformen.