LLM Wiki = Aktualisierbare RAG

Endlich habe ich Karpathys LLM Wiki Gist gelesen (ja, ich bin spät zum Hype-Zug aufgesprungen XD).

Und ehrlich gesagt, läuft die ganze Idee auf etwas ziemlich Einfaches hinaus: „aktualisierbares RAG".

1. Das Problem

Wenn LLMs mit Dokumenten arbeiten, sammelt sich nichts an. Bei jeder Abfrage ruft das Modell Textabschnitte ab, synthetisiert von Grund auf neu, vergisst. Wissen wird nie kompiliert. Und meiner Meinung nach noch wichtiger: Aus den Dialogen selbst wird fast keine nützliche Information extrahiert.

RAG hilft teilweise (im weiteren Sinne – ein Ordner mit .md-Dateien ist auch RAG), aber die Standard-Pipeline (die jeder verwendet) hat keine eingebaute Aktualisierung, Destillation oder Selbstbereinigung. Wissen landet einmal im Index und liegt dann einfach ungenutzt herum. Diese Lücke schließt LLM Wiki genau.

Karpathys Umkehrung: Zwischen den Rohquellen und dir liegt ein Markdown-Wiki, das der Agent schrittweise schreibt und pflegt. Einmal kompilieren, aktuell halten.

2. Architektur: 3 Schichten

• raw/ – Quellen, unveränderlich. Der Agent schreibt hier nicht hinein.
• wiki/ – das Herz des Systems; Markdown-Seiten (Entitäten, Konzepte), die das LLM selbst schreibt und verlinkt. Im Grunde graphförmiges Wissen.
• CLAUDE.md – nur das Handbuch, wie LLM Wiki ausgeführt wird. Enthält: Seitenformat, Link-Konventionen, Ingest-Ablauf, Lint-Regeln. Das Ding, das Claude von einem Chatbot zu einem disziplinierten Wiki-Verwalter macht.

Ausreichend für Hunderte von Seiten ohne zusätzliches Feintuning:

3. Operationen

Drei Operationen – man möchte sie sofort als API-Funktionen darstellen:

• Ingest -> add(source: file | list[file]). Eine Quelle ablegen -> Agent liest -> diskutiert mit dir -> schreibt Zusammenfassung -> aktualisiert Index -> bearbeitet verwandte Entitätsseiten -> hängt an Log an. Eine Quelle berührt 10–15 Seiten.
• Query -> search(prompt: str). Die wichtigste Operation. Beantwortet deine Frage + (DER ENTSCHEIDENDE PUNKT) speichert die Synthese automatisch wieder im Wiki als neue Seiten. Exploration summiert sich, statt in der Chat-Historie zu sterben. Im Grunde ist es add(source=dialogue) unter der Haube.
• Lint -> lint(). Keine Argumente. Durchläuft regelmäßig das Wiki: Widersprüche, verwaiste Seiten, veraltete Fakten, fehlende Querverweise. Auslöser – alle N Benutzernachrichten oder ein Zähler für geänderte Zeilen. Einfach per /schedule anzuhängen.

Erinnert stark an Claude Dreaming – ich denke, Dreaming ist teilweise von diesem Pattern inspiriert (obwohl der Funktionsumfang etwas anders ist).

4. Indizierung

Zwei spezielle Dateien machen das Wiki navigierbar:

• index.md – aktueller Zustand. Katalog jeder Seite mit einem Einzeiler. Der Agent liest ihn bei jeder Abfrage zuerst – das ist der minimale Kontext „Was gibt es überhaupt in diesem Wiki?".
• log.md – Log aller Ereignisse, freiformatig. Nur-Anhängen-Zeitleiste. Wenn die Zeilen eine konsistente Form haben (z.B. \## [YYYY-MM-DD] ingest | titel\), lässt sich das Log sauber mit einfachen Unix-Tools durchsuchen – praktisch für Audits.

index.md kann weiter skaliert werden (Vektorindex, BM25, GraphDB, ...) – das behandle ich in einem separaten Beitrag.

5. Zusammenfassung

So würde ich es einordnen: Es ist keine Wahl zwischen RAG und LLM Wiki – sie sind zwei Punkte auf derselben Achse des „sich akkumulierenden Gedächtnisses".

RAG muss keine Vektordatenbank sein – ein Ordner mit Markdown-Dateien ist auch RAG.

Man kann LLM Wiki also als RAG mit drei zusätzlichen Komponenten umformulieren:

1. Eine Zusammenfassungsschicht.
2. (Nahezu) freies Verfassen der Struktur auf dieser Zusammenfassungsebene.
3. Regelmäßige strukturelle Überprüfung + Selbstverbesserung (CRON).