LLM Knowledge Bases: Warum alle beim selben Stack landen

Wesentliche Insights

1 — Convergent Evolution: Dasselbe Pattern, verschiedene Leute

Karpathy beschreibt seinen Workflow für LLM-gestützte Knowledge Bases: Quelldokumente in einem raw/-Verzeichnis sammeln, ein LLM das daraus ein Markdown-Wiki kompiliert, Obsidian als Frontend, Q&A gegen die eigene Wissensbasis, Linting und Health Checks über die Daten.

Was auffällt: Dieses Setup taucht gerade überall gleichzeitig auf. Simon Willison baut seit Jahren auf Markdown und SQLite. Practitioner in der Claude-Code-Community strukturieren git-versionierte Vaults mit geschichteter Kontextarchitektur. Tiago Fortes PARA-Methode wird mit LLM-Agenten kombiniert. Niemand hat das koordiniert — und trotzdem konvergiert alles auf denselben Stack.

In der Biologie heißt das konvergente Evolution: Verschiedene Spezies entwickeln unabhängig voneinander dieselben Lösungen für dasselbe Problem. Hier ist das Problem: Wie organisiert ein Mensch Wissen so, dass ein LLM es operativ nutzen kann?

2 — Die vier Bausteine des konvergenten Stacks

Unter der Oberfläche verschiedener Implementierungen steckt immer dieselbe Architektur. Vier Schichten, die sich bei jedem Practitioner wiederfinden — in unterschiedlicher Ausprägung, aber mit derselben Logik:

Data Ingest — Wissen ins System bringen. Karpathy nutzt Web Clipper und einen raw/-Ordner. Andere arbeiten mit Readwise, Obsidian Clipper oder manueller Kuratierung. Das Ergebnis ist immer: Quelldokumente als lokale Dateien, vorzugsweise Markdown.

Knowledge Structure — Wissen organisieren. Karpathy lässt das LLM ein Wiki kompilieren mit Kategorien, Backlinks und Zusammenfassungen. Andere arbeiten mit expliziten Konventionen, Index-Dateien und geschichteten Kontextsystemen. Das Prinzip ist dasselbe: Struktur, die sowohl für Menschen als auch für LLMs navigierbar ist.

Agent Operation — LLM als Operator, nicht als Orakel. Q&A gegen die Wissensbasis, Health Checks, Konsistenzprüfungen, inkrementelle Verbesserung. Das LLM liest nicht nur — es arbeitet im System.

Output Rendering — Ergebnisse sichtbar machen. Markdown-Dateien, Slides (Marp), Visualisierungen (matplotlib), Suchinterfaces. Outputs fließen zurück ins System und reichern es an.

3 — Warum Markdown und Git gewinnen

Karpathy hätte jedes Format wählen können. Notion, Roam, eine Datenbank. Stattdessen: Markdown-Dateien in einem Verzeichnis. Das ist kein Zufall — es ist das Ergebnis eines stillen Selektionsprozesses.

Markdown ist das Format, das LLMs nativ verstehen. Kein Parsing nötig, keine API, kein Vendor Lock-in. Git liefert Versionierung, Branching und Kollaboration — kostenlos, robust, seit Jahrzehnten bewährt. Obsidian ist ein Viewer auf dem Dateisystem, kein proprietäres System. Die Daten gehören dir, nicht dem Tool.

Die Konsequenz: Ein Knowledge-System auf diesem Stack überlebt jeden einzelnen seiner Bestandteile. Claude Code wird ersetzt? Die Markdown-Dateien bleiben. Obsidian verschwindet? Die Verzeichnisstruktur funktioniert mit jedem Editor. Das ist keine theoretische Überlegung — es ist eine Designentscheidung mit realen Konsequenzen für die Haltbarkeit von Wissensarbeit.

4 — Der entscheidende Split: Wiki vs. Arbeitssystem

Hier wird es interessant. Karpathy beschreibt ein System, in dem das LLM ein Wiki pflegt und auf Anfrage Fragen beantwortet. Das ist read-heavy — Wissen wird gesammelt, strukturiert, abgefragt. Der Mensch stellt Fragen, das LLM recherchiert.

Aber das Pattern kann auch write-heavy sein. Wenn der LLM nicht nur Zusammenfassungen schreibt, sondern aktiv im System arbeitet — Änderungen propagiert, Konsistenz prüft, Aufgaben strukturiert, Outputs für verschiedene Kanäle generiert — dann ist es kein Wiki mehr. Es ist ein operatives Arbeitssystem.

Der Unterschied ist nicht graduell, sondern qualitativ. Ein Wiki ist ein Wissensarchiv mit intelligentem Zugang. Ein Knowledge OS ist eine Arbeitsumgebung, in der Mensch und LLM gemeinsam operieren. Beide nutzen denselben Stack — aber die Ambition ist eine andere.

Karpathy deutet diese Richtung an, wenn er schreibt: “Often, I end up ‘filing’ the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always ‘add up’ in the knowledge base.” Das ist der Anfang einer Feedbackschleife, die über reines Q&A hinausgeht.

5 — Was fehlt: Team-Scale und Standards

Karpathys Setup ist — wie die meisten dieser Systeme — ein Solo-Projekt. Das funktioniert, solange eine Person den Kontext kontrolliert. Die offene Frage: Was passiert, wenn mehrere Personen im selben System arbeiten?

Kollaborative Kontextarchitekturen sind weitgehend ungelöst. Wie teilt man Konventionen? Wie verhindert man Kontextdrift bei mehreren Agenten? Wie skaliert man Wartung? Karpathy selbst sagt: “I think there is room here for an incredible new product instead of a hacky collection of scripts.”

Vielleicht. Aber vielleicht ist das Produkt nicht eine App, sondern ein Set von Konventionen — ein Standard für die Architektur von LLM-gestützten Wissenssystemen. Nicht das Tool, sondern die Praxis.

Einordnung

Dieser Text kommt von jemandem, der selbst seit Monaten ein System betreibt, das dem beschriebenen Pattern entspricht — die Beobachtung der Konvergenz ist auch eine Selbstverortung. Das erlaubt eine differenzierte Bewertung der praktischen Tragfähigkeit, birgt aber das Risiko, Bestätigung für die eigene Architektur zu finden, wo auch Zufall oder soziale Imitation wirken könnten. Ein Informationswissenschaftler würde die Genealogie dieser Patterns stärker historisch einordnen; ein Produktmanager würde fragen, ob die Konvergenz einen Markt signalisiert oder nur eine Nische.

Kritische Einordnung

Was hält stand

• Die Konvergenz ist real und empirisch beobachtbar — verschiedene Communities landen unabhängig bei denselben Grundentscheidungen
• Markdown + Git als Basis für LLM-Interaktion hat sich in der Praxis als robust erwiesen
• Die Vier-Schichten-Architektur (Ingest → Structure → Operation → Output) ist ein brauchbares Modell, auch wenn die Grenzen fließend sind
• Karpathys Beobachtung, dass RAG bei moderater Skalierung oft unnötig ist, deckt sich mit Praxiserfahrungen

Was man einordnen muss

• Survivorship Bias: Wir sehen die erfolgreichen Setups — nicht die, die mit Notion, Roam oder proprietären Tools gescheitert sind und aufgegeben haben
• Karpathys Perspektive ist die eines ML-Forschers mit hoher technischer Kompetenz — Zugänglichkeit für Nicht-Techniker ist eine offene Frage
• “Convergent Evolution” ist eine starke Metapher, aber die Stichprobe ist klein und selbstselektiert (tech-affine Early Adopters)
• Die Skalierungsfrage (Team, Enterprise) ist nicht nur offen, sondern möglicherweise ein fundamental anderes Problem als das Solo-Setup

Diskussionsfragen

01 Konvergenz oder Echokammer: Landen Practitioner wirklich unabhängig beim selben Stack — oder beeinflusst die Sichtbarkeit bestimmter Setups (Karpathy, Willison) die Entscheidungen anderer? Wie viel davon ist echte Konvergenz, wie viel soziale Imitation?

02 Wiki vs. OS: Wo genau verläuft die Grenze zwischen einem LLM-gepflegten Wissensarchiv und einem operativen Knowledge OS? Ist der Übergang fließend — oder gibt es einen qualitativen Sprung, ab dem sich die Anforderungen fundamental ändern?

03 Standards vs. Produkte: Karpathy sieht Raum für “an incredible new product”. Ist die Antwort tatsächlich ein Produkt — oder eher ein Set von Konventionen und Patterns, die verschiedene Tools implementieren können? Was wäre das “HTTP für Knowledge OS”?

04 Zugänglichkeit: Diese Systeme setzen Markdown-Kompetenz, Git-Verständnis und LLM-Erfahrung voraus. Wie demokratisiert man das — ohne die Vorteile des einfachen Stacks zu verlieren?

Quellen

• Original: Andrej Karpathy — LLM Knowledge Bases (X/Twitter, April 2026)
• Simon Willison — Personal Data Warehouses
• Context Engineering: Ein Knowledge OS mit Claude aufbauen — David Latz
• Agent Memory: Why Your AI Has Amnesia — David Latz (Kuratiert)

Glossar

Convergent Evolution (hier: technologisch) Unabhängige Akteure entwickeln dieselbe Lösung für dasselbe Problem — nicht durch Koordination, sondern durch identische Selektionsdrücke. In der Biologie: Flügel bei Vögeln und Fledermäusen. Hier: Markdown + Git + LLM bei verschiedenen Practitionern.

Knowledge OS Ein strukturiertes, git-versioniertes Wissens-Repository, das über ein Archiv hinausgeht — der LLM arbeitet aktiv im System (Konsistenzprüfung, Aufgabenstrukturierung, Output-Generierung), statt nur Fragen zu beantworten.

Context Engineering Gestaltung der persistenten Informationsumgebung, in der ein LLM arbeitet — jenseits einzelner Prompts. Umfasst Dateistrukturen, Konventionen, Abhängigkeitssysteme und geschichtete Kontextarchitekturen.

Compiled Wiki (Karpathy) Ein Markdown-Wiki, das ein LLM aus Rohdaten generiert und inkrementell pflegt — mit Zusammenfassungen, Kategorien und Backlinks. Read-heavy, mit dem LLM als Maintainer.