Karpathys LLM-Wiki: Das Ende von RAG für persönliches Wissen?

Warum RAG bei persönlichem Wissen an Grenzen stößt

Die meisten Nutzer erleben Large Language Models heute so: Sie laden Dokumente hoch, das Modell sucht passende Textstellen und generiert eine Antwort. Dieses Retrieval-Augmented-Generation-Pattern funktioniert. Es hat aber ein strukturelles Problem. Das Modell findet bei jeder Anfrage von neuem die relevanten Fragmente. Es akkumuliert nichts. Eine Frage, die fünf Dokumente synthetisieren muss, zwingt das LLM jedes Mal zur Null-Anfang-Suche. Nichts wird aufgebaut.

Tools wie NotebookLM oder ChatGPT-Dateiuploads arbeiten nach diesem Prinzip. Sie sind nützlich für einmalige Anfragen. Sie bilden aber kein wachsendes Wissensfundament. Genau hier setzt Andrej Karpathys Vorschlag an. Der ehemalige Tesla- und OpenAI-Forscher hat im April 2026 ein Muster veröffentlicht, das innerhalb weniger Tage fünftausend Sterne auf GitHub erhielt.

Das Kernprinzip: Wiki statt Retrieval

Karpathys Idee dreht die übliche Logik um. Statt bei jeder Frage Rohdokumente zu durchsuchen, pflegt das LLM ein persistentes Wiki. Dieses Wiki besteht aus strukturierten Markdown-Dateien. Es liegt zwischen dem Nutzer und den Quellendokumenten. Jedes neue Dokument liest das Modell. Es extrahiert Kernaussagen. Es aktualisiert bestehende Seiten. Es verweist auf Widersprüche. Es verdichtet Synthesen.

Das Wissen wird einmal kompiliert und bleibt aktuell. Es muss nicht bei jeder Anfrage neu abgeleitet werden. Die Querverweise existieren bereits. Widersprüche sind markiert. Die Synthese spiegelt alle gelesenen Quellen wider. Das Wiki wächst mit jeder Quelle und jeder Frage.

Der Nutzer schreibt dieses Wiki nicht selbst. Das LLM übernimmt die gesamte Pflege. Der Mensch kuratiert Quellen. Er stellt die richtigen Fragen. Er lenkt die Analyse. Das Modell übernimmt Zusammenfassung, Kreuzreferenzierung, Ablage und Buchhaltung. Karpathy beschreibt das so: Obsidian ist die IDE. Das LLM ist der Programmierer. Das Wiki ist die Codebasis.

Drei Schichten bilden die Architektur

Das System ruht auf drei klar getrennten Ebenen.

Rohquellen bilden die erste Schicht. Artikel, Papers, Bilder, Datensätze. Diese Dateien sind unveränderlich. Das LLM liest daraus. Es modifiziert sie niemals. Sie sind die Quelle der Wahrheit.

Das Wiki ist die zweite Schicht. Ein Verzeichnis aus Markdown-Dateien. Zusammenfassungen, Entity-Seiten, Konzeptseiten, Vergleiche, Übersichten. Das LLM besitzt diese Schicht vollständig. Es erstellt Seiten. Es aktualisiert sie bei neuen Quellen. Es pflegt Querverweise. Es sorgt für Konsistenz. Der Mensch liest. Das LLM schreibt.

Das Schema ist die dritte Schicht. Eine Konfigurationsdatei. Sie definiert Struktur, Konventionen und Workflows. Bei Claude Code wäre das eine CLAUDE.md. Bei OpenAI Codex eine AGENTS.md. Dieses Schema macht das LLM zum disziplinierten Wiki-Kurator statt zum generellen Chatbot. Mensch und Modell entwickeln es gemeinsam weiter.

Drei Operationen treiben das System

Der Alltag mit dem Wiki folgt drei wiederkehrenden Mustern.

Ingest startet den Prozess. Eine neue Quelle landet im Rohquellen-Ordner. Das LLM liest sie. Es diskutiert Kernpunkte mit dem Nutzer. Es schreibt eine Zusammenfassungsseite. Es aktualisiert den Index. Es berührt Entity- und Konzeptseiten. Ein einzelnes Dokument kann zehn bis fünfzehn Wiki-Seiten verändern. Karpathy bevorzugt die Einzelverarbeitung mit menschlicher Begleitung. Batch-Verarbeitung ist aber ebenfalls möglich.

Query nutzt das vorhandene Wissen. Der Nutzer stellt Fragen. Das LLM sucht relevante Seiten. Es liest sie. Es synthetisiert eine Antwort mit Quellenangaben. Antworten können verschiedene Formen annehmen. Eine Markdown-Seite. Eine Vergleichstabelle. Eine Präsentation im Marp-Format. Ein Diagramm. Wichtige Antworten speichert das System als neue Wiki-Seiten. Explorationen verdichten sich so im Wissensbestand.

Lint erhält die Gesundheit des Wikis. Regelmäßige Checks suchen Widersprüche zwischen Seiten. Sie finden veraltete Aussagen. Sie entdecken verwaiste Seiten ohne eingehende Links. Sie identifizieren Konzepte ohne eigene Seite. Das LLM schlägt neue Quellen vor. Es erkennt Lücken. Dieser Prozess hält das Wiki konsistent.

Index und Log navigieren das Wachstum

Zwei Spezialdateien helfen bei der Orientierung.

Die index.md ist inhaltlich organisiert. Sie katalogisiert jede Seite mit Link, Zusammenfassung und Metadaten. Gegliedert nach Kategorien. Das LLM aktualisiert sie bei jedem Ingest. Bei Anfragen liest das Modell zuerst den Index. Dann drillt es in die relevanten Seiten. Dieser Ansatz funktioniert bis etwa hundert Quellen und hunderten Seiten überraschend gut. Embedding-basierte RAG-Infrastruktur ist nicht nötig.

Die log.md ist chronologisch. Sie führt ein append-only Protokoll. Jeder Eintrag beginnt mit einem konsistenten Prefix. Das macht das Log mit Unix-Tools durchsuchbar. Grep nach dem Datums-Prefix liefert die letzten Einträge. Das Log zeigt die Evolution des Wikis. Es hilft dem LLM, kürzliche Aktivitäten zu verstehen.

Warum dieser Ansatz funktioniert

Die mühsame Arbeit bei Wissensdatenbanken ist nicht das Lesen oder Denken. Es ist die Buchhaltung. Querverweise aktualisieren. Zusammenfassungen aktuell halten. Widersprüche zwischen neuen und alten Daten notieren. Konsistenz über Dutzende Seiten wahren. Menschen geben Wikis auf. Der Wartungsaufwand wächst schneller als der Nutzen.

LLMs langweilen sich nicht. Sie vergessen Querverweise nicht. Sie bearbeiten fünfzehn Dateien in einem Durchgang. Das Wiki bleibt gepflegt. Die Wartungskosten liegen nahe null. Die menschliche Arbeit verschiebt sich. Quellen kuratieren. Analyse lenken. Gute Fragen stellen. Über Bedeutung nachdenken. Das LLM übernimmt den Rest.

Karpathy zieht eine Verbindung zu Vannevar Bushs Memex-Konzept von 1945. Bush envisioned einen persönlichen Wissensspeicher mit assoziativen Pfaden zwischen Dokumenten. Bushs Vision war privater und aktiver kuratiert als das spätere Web. Die offene Frage war immer: Wer macht die Wartung? Das LLM beantwortet sie.

RAG oder Kontext: Eine Frage der Größenordnung

Die Community-Diskussion zu Karpathys Gist brachte eine wichtige Einordnung hervor. Die Wahl zwischen RAG und reinem Kontext ist primär eine Frage der Token-Menge.

Unter fünfzigtausend bis hunderttausend Token gewinnt der Kontext-Ansatz. Das entspricht etwa hundertfünfzig bis zweihundert dichten Seiten. Die Zuverlässigkeit liegt bei hundert Prozent. Keine Chunking-bedingten Semantikbrüche. Keine Vektor-Datenbank. Keine Embedding-Pipeline. Globale Reasoning über das gesamte Korpus ist möglich.

Ab Millionen Token ist RAG die einzige Option. Die Daten passen nicht in den Kontext. Retrieval wird notwendig. Der hybride Ansatz nutzt beides. Stabiles Kernwissen liegt im Kontext. Dynamische Massendaten bedienen sich an RAG.

Eine persönliche Wissensbasis umfasst nach Konsolidierung meist nur wenige tausend bis zwanzigtausend Token. Das liegt weit unter der Schwelle. RAG wäre hier Overhead und würde die Zuverlässigkeit senken. Moderne Kontextfenster von zweihunderttausend bis über einer Million Token heben diese Grenze stetig an.

Anwendungsfälle über Forschung hinaus

Das Muster ist nicht auf akademische Arbeit beschränkt.

Im persönlichen Bereich trackt das Wiki Ziele, Gesundheit und Selbstentwicklung. Journal-Einträge, Podcast-Notizen und Artikel verdichten sich zu einem strukturierten Selbstporträt über Zeit.

Im Unternehmen pflegen LLMs ein internes Wiki. Gefüttert mit Slack-Threads, Meeting-Transkripten, Projektdokumenten und Kundenanrufen. Das Wiki bleibt aktuell. Das LLM übernimmt die Wartung, die niemand im Team machen möchte.

Beim Lesen eines Buches entsteht eine Companion-Wiki. Charakterseiten, Themen, Plot-Stränge und ihre Verbindungen. Tolkien Gateway zeigt, was Communities über Jahre aufbauen. Das LLM ermöglicht diese Tiefe im persönlichen Maßstab.

Wettbewerbsanalysen, Due Diligence, Reiseplanung und Kursnotizen profitieren ebenfalls. Immer dann, wenn Wissen über Zeit akkumuliert und organisiert statt verstreut sein soll.

Werkzeuge und praktische Hinweise

Der Obsidian Web Clipper wandelt Webartikel in Markdown um. Er ist der schnellste Weg in die Rohquellen-Sammlung. Bilder lassen sich lokal speichern. Das ermöglicht dem LLM, Bilder direkt zu referenzieren.

Obsidians Graph-View visualisiert die Struktur des Wikis. Welche Seiten sind Hubs? Welche sind verwaist? Welche Verbindungen existieren? Diese Ansicht ist unersetzlich für die Navigation.

Marp konvertiert Markdown in Präsentationen. Das Dataview-Plugin läuft Queries über YAML-Frontmatter. Dynamische Tabellen und Listen entstehen automatisch. Das Wiki ist ein Git-Repository. Versionierung, Branching und Kollaboration sind gratis dabei.

Für größere Wikis wird eine Suchengine sinnvoll. qmd bietet hybride BM25- und Vektor-Suche mit LLM-Re-Ranking. Alles lokal. Als CLI und MCP-Server verfügbar. Das LLM kann es direkt als Tool nutzen.

Grenzen und offene Fragen

Der Ansatz ist nicht ohne Herausforderungen. Die Schema-Datei erfordert Disziplin. Sie muss mitwachsen und gepflegt werden. Bei schlechten Konventionen driftet das Wiki. Die Qualität der Synthesen hängt vom eingesetzten Modell ab. Schwächere Modelle produzieren oberflächliche Zusammenfassungen.

Ein weiteres Thema ist die Sicherheit. Ein autonom ingestierendes Wiki ist eine Angriffsfläche für Prompt-Injection. Eine manipulierte Quelle kann Instruktionen ins Wiki pflanzen. Diese persistieren und vergiften spätere Sessions. Der Lint-Schritt prüft Korrektheit. Er prüft aber keine Adversarialität. Hier braucht es zusätzliche Sicherheitsmechanismen.

Die Community arbeitet an Lösungen. Nonce-delimierte Quellen. Vier-Augen-Reviews durch unabhängige Modelle. Git-basierte Provenienz pro Claim. Trust-Tiering nach Host. Diese Ansätze sind vielversprechend. Sie sind aber noch nicht Standard.

Ein Muster mit Potenzial

Karpathys LLM-Wiki ist kein fertiges Produkt. Es ist ein Muster. Eine Architektur-Idee. Sie kommuniziert ein Prinzip: Wissen sollte sich verdichten. Es sollte persistent sein. Es sollte mit jeder Quelle reicher werden. Die Wartung sollte das LLM übernehmen. Der Mensch sollte sich auf das Wesentliche konzentrieren.

Ob dieser Ansatz RAG ersetzt oder ergänzt, hängt von der Aufgabe ab. Für persönliches Wissen bei moderatem Umfang ist das Wiki der überlegene Ansatz. Für massive Datenmengen bleibt RAG notwendig. Die meisten privaten Anwendungsfälle liegen im Wiki-Bereich.

Das Muster verdient Aufmerksamkeit. Es verschiebt die Rolle des LLM vom Antwort-Generator zum Wissens-Kurator. Es macht Wissen zu einem kompoundierenden Asset. Nicht zu einer jedes Mal neu abgerufenen Ressource.