LLM Wiki: Wie KI-Agenten Wissen dauerhaft aufbauen – und warum es RAG schlägt

TL;DR: Ein LLM Wiki ist ein KI-Architekturmuster für Wissensdatenbanken: Ein KI-Agent liest neue Quellen, extrahiert das Wesentliche und kompiliert es in eine strukturierte, dauerhaft gepflegte Sammlung verlinkter Markdown-Seiten. Der entscheidende Unterschied zu RAG (Retrieval-Augmented Generation): Wissen wird nicht bei jeder Abfrage neu aus Rohdokumenten zusammengesucht, sondern einmalig beim Einlesen verarbeitet und dauerhaft gespeichert. Das Ergebnis ist eine Wissensbasis, die mit jeder neuen Quelle akkumuliert statt bei Null zu starten. Einzelne Praxisberichte zeigen deutlich weniger Token-Verbrauch gegenüber unoptimiertem RAG – wie stark der Unterschied ausfällt, hängt stark vom Datensatz und Setup ab. Das Konzept eignet sich vor allem für kleine bis mittelgroße, strukturierte Wissensbasen und ist kein universeller RAG-Ersatz.

Was ist ein LLM Wiki?

Ein LLM Wiki ist keine Datenbank und kein klassischer Chatbot-Upload. Es ist eine Schicht aus Markdown-Dateien, die zwischen den Rohquellen und der Anfrage sitzt – und die ein KI-Agent schreibt, pflegt und verlinkt. Das Muster wurde Anfang 2026 von Andrej Karpathy in einem Post und einem GitHub-Gist öffentlich beschrieben und in der KI-Community breit diskutiert. Die konkrete Umsetzung mit Claude Code und Obsidian beschreibt der Artikel Claude Code + Obsidian: So baut Karpathy ein KI-Second-Brain. Dieser Beitrag erklärt das zugrundeliegende Konzept – unabhängig vom konkreten Tool-Stack. Das Architekturmuster dreht die klassische RAG-Logik um: Bei RAG (Retrieval-Augmented Generation) sucht das Modell bei jeder Frage neu in den Rohdokumenten. Beim LLM Wiki passiert die Synthesearbeit beim Einlesen einer Quelle – einmalig, dauerhaft, akkumulierend. Der Kerngedanke dahinter: Klassisches RAG akkumuliert kein Wissen. Jede Anfrage beginnt ohne Erinnerung an vorherige Synthesen.

Die drei Schichten: Rohquellen, Wiki, Schema

Karpathy teilt das System in drei klar getrennte Schichten. • Rohquellen (raw/): Die unveränderliche Sammlung der Originaldokumente – Artikel, PDFs, Notizen. Die KI liest daraus, schreibt aber nie hinein. Das ist die Quelle der Wahrheit. • Das Wiki (wiki/): Eine von der KI generierte Sammlung aus Zusammenfassungen, Konzeptseiten, Entitätsseiten und Vergleichen. Der Agent besitzt diese Schicht vollständig – er erstellt Seiten, aktualisiert sie, pflegt Querverweise und hält alles konsistent. • Das Schema (CLAUDE.md oder AGENTS.md): Die Konfigurationsdatei, die der KI vorgibt, wie das Wiki strukturiert ist, welche Konventionen gelten und welche Workflows beim Ingest, Query oder Lint ausgeführt werden. Ohne Schema ist das LLM ein generischer Chatbot. Mit Schema wird es ein disziplinierter Wiki-Maintainer. Karpathy fasst das System in einer Analogie zusammen: „Obsidian ist die Entwicklungsumgebung, das LLM ist der Programmierer, das Wiki ist die Codebasis.“

Ingest, Query, Lint – die Kern-Operationen

Das System kennt drei Operationen: Ingest, Query und Lint. Jede hat einen klaren Auslöser, einen definierten Prozess und ein messbares Ergebnis.

Ingest: Wissen kompilieren

Ingest ist die wichtigste Operation. Eine neue Quelle wandert in den raw/-Ordner, der Agent verarbeitet sie. Was dann passiert, geht weit über einfaches Indexieren hinaus: 1. Der Agent liest das Dokument und bespricht die wichtigsten Erkenntnisse mit dem Nutzer. 2. Er identifiziert neue Konzepte, Entitäten und Argumente. 3. Er vergleicht den neuen Inhalt mit dem bestehenden Wiki – und markiert Widersprüche. 4. Er erstellt neue Seiten oder aktualisiert bestehende. 5. Er aktualisiert das zentrale Inhaltsverzeichnis (index.md) und schreibt einen Eintrag in das Aktivitätsprotokoll (log.md). Faustregel: Eine einzige neue Quelle kann in einem Durchgang 10 bis 15 Wiki-Seiten berühren. Das ist kein Fehler, sondern Akkumulation.

Query: Abfragen gegen das Wiki

Bei einer Frage sucht der Agent nicht in den Rohdaten. Er liest zuerst die index.md, identifiziert relevante Wiki-Seiten und generiert eine Antwort mit Zitationen. Das vermeidet bei moderaten Größen (bis ca. 100 Quellen, hunderte Seiten) den Aufbau einer Embedding-Infrastruktur vollständig. Entscheidender Unterschied zu reinen Chat-Systemen: Gute Antworten können direkt als neue Wiki-Seiten zurückgespeichert werden. Explorations-Fragen kompoundieren das Wissen genauso wie neue Quellen.

Lint: Gesundheitscheck

Periodisch prüft der Agent das Wiki auf: • Widersprüche zwischen Seiten • Veraltete Behauptungen, die neuere Quellen widerlegt haben • Verwaiste Seiten ohne eingehende Links • Konzepte, die oft erwähnt werden, aber noch keine eigene Seite haben Das Lint-Verfahren minimiert die Wartungssteuer, die klassische Wikis über Zeit verrotten lässt – weil LLMs nicht vergessen und sich nicht langweilen.

Der Tool-Stack: Obsidian, Claude Code, Git

Der von Karpathy beschriebene Stack besteht aus drei Werkzeugen mit klar getrennten Rollen. | Tool | Funktion | |---|---| | Obsidian | Wiki-IDE: Viewer, Graph-Ansicht, Web-Clipper | | Claude Code | KI-Agent: Ingest, Query, Lint per Terminal | | Git | Versionskontrolle: git diff nach jedem Ingest, git revert bei Fehlern | Obsidian eignet sich als Standard-Frontend, weil es rein auf lokalen Markdown-Dateien basiert. KI-Agenten wie Claude Code können die Dateien nativ lesen und schreiben – keine proprietäre Datenbank, keine API-Einschränkungen. Die Graph-Ansicht macht die Verlinkungsstruktur sofort als Netzwerkkarte sichtbar: Hub-Seiten (viele Verbindungen) erscheinen als große Knoten, verwaiste Seiten als isolierte Punkte. Die konkrete Einrichtung dieses Stacks – inklusive Vault-Struktur, CLAUDE.md-Template und Web-Clipper-Integration – ist im Artikel Claude Code + Obsidian: So baut Karpathy ein KI-Second-Brain dokumentiert.

LLM Wiki vs. RAG: Der direkte Vergleich

!Infografik: RAG vs. LLM Wiki im Vergleich — Kennzahlen zu Setup-Komplexität, Skalierbarkeit, Transparenz und Wissensakkumulation Infografik: RAG und LLM Wiki im direkten Vergleich nach Setup-Komplexität, Skalierbarkeit, Transparenz und Hauptvorteil – RAG punktet bei Masse, LLM Wiki bei Präzision und Architektur. Bild: KI-generiert mit NotebookLM | Dimension | Traditionelles RAG | LLM Wiki | |---|---|---| | Wissensverarbeitung | Bei jeder Anfrage neu (Query Time) | Einmalig beim Einlesen (Ingest Time) | | Querverweise | Ad-hoc pro Anfrage entdeckt | Vorgebaut und gepflegt | | Widersprüche | Werden oft nicht erkannt | Werden beim Ingest markiert | | Wissensakkumulation | Keine – startet neu bei jeder Anfrage | Kompoundiert mit jeder Quelle | | Ausgabeformat | Chat-Antworten (flüchtig) | Persistente Markdown-Dateien (dauerhaft) | | Wartung | Automatisiert (Re-Indexing) | Kontinuierlich (Lint) | | Latenz (Query) | ~100 ms+ | ~2 ms | | Transparenz | Blackbox (Embedding-Pipeline) | Vollständig lesbar und editierbar |

Berichtete Unterschiede

Konkrete Vergleichszahlen zwischen LLM Wiki und RAG sind in der Praxis schwer zu generalisieren, da sie stark vom Datensatz, Benchmark-Setup und der Qualität des jeweiligen RAG-Systems abhängen. Die folgenden Werte stammen aus Einzelmessungen und Community-Berichten – sie illustrieren mögliche Größenordnungen, sind aber keine allgemeingültigen Benchmarks. Token-Effizienz gegenüber unoptimiertem RAG: Wer bisher vollständige Dokumente in den Kontext lädt, kann durch vorab kompilierte Wiki-Seiten deutlich weniger Tokens pro Anfrage senden. Anstatt 5.000 Tokens an Rohfragmenten reicht oft eine 300-Token-Zusammenfassung. Gegenüber gut optimiertem RAG mit präzisem Chunking fällt der Unterschied geringer aus. Beispielmessung aus der Praxis: Ein Entwicklerteam berichtete nach der Migration einer 1.800-zeiligen README auf eine Wiki-Struktur in Cursor von rund 40 % weniger Token-Verbrauch pro vergleichbarer Refactoring-Aufgabe. Die Agenten produzierten weniger halluzinierte Annahmen, weil sie auf verlinkte, kuratierte Seiten zugreifen konnten. Methode und Datensatz dieser Messung sind nicht öffentlich dokumentiert – der Wert ist als Anhaltspunkt, nicht als repräsentativer Benchmark zu verstehen. Genauigkeit bei schwacher Retrieval-Qualität: In einem Szenario mit absichtlich verschlechterter Suchqualität (degraded retrieval) zeigte ein Wiki-basierter Ansatz deutlich stabilere Ergebnisse als ein RAG-System, das auf die Retrieval-Qualität angewiesen ist. Dieser Vorteil ist situationsabhängig und gilt nicht für gut konfigurierte RAG-Systeme unter normalen Bedingungen.

Wann ist ein LLM Wiki besser als RAG?

Das LLM Wiki spielt seine Stärken bei Tiefe, Synthese und Struktur aus. Es ist die richtige Wahl, wenn: • Die Wissensbasis klein bis mittelgroß ist: Unter 50.000 bis 100.000 Tokens – das entspricht rund 150 bis 200 Seiten dichtem Text – ist ein Wiki-Ansatz oft ausreichend und einfacher zu betreiben als eine vollständige RAG-Pipeline. Diese Grenze ist eine Heuristik, kein technisch harter Wert. • Fehler inakzeptabel sind: Interne Unternehmensrichtlinien, Architekturentscheidungen (ADRs), präzise Preismodelle – hier ist deterministisches Retrieval dem wahrscheinlichkeitsbasierten Embedding-Matching überlegen. • Der Inhalt strukturiert und stabil ist: Checklisten, Tabellen, Standardarbeitsanweisungen – Chunking zerstört diese Strukturen, das Wiki bewahrt sie. • Das „Warum“ wichtig ist: Architektur, Konventionen, Zusammenhänge – das ist das Wissen, das RAG am schlechtesten abbildet.

Wann ist RAG besser als ein LLM Wiki?

RAG ist überlegen, wenn Skalierung und Dynamik dominieren: • Massive Datenmengen: Tausende von Dokumenten, große Code-Repositories, Millionen von Tokens – hier skaliert RAG ohne Alternative. • Häufig wechselnde Inhalte: Newsfeeds, Live-Preise, tägliche Updates – ein Wiki ständig neu zu kompilieren ist zu aufwändig. • Unstrukturierte Daten: Rohe Chatprotokolle, Slack-Exporte, lange unstrukturierte Texte – semantische Suche ist hier im Vorteil. • Offene, unvorhersehbare Fragen: Wenn nicht absehbar ist, welche Dokumente relevant sein könnten, fängt RAG diese Unschärfe besser ab. Faustregel: In der Praxis werden beide Ansätze oft kombiniert. Das LLM Wiki übernimmt ca. 80 % der Anfragen – die vorhersehbaren, strukturierten, hochrelevanten. RAG deckt den Long Tail ab. Das erlaubt einen kleineren, hochqualitativen Vektorindex.

FAQ: Häufig gestellte Fragen zu LLM Wiki

Was ist der Unterschied zwischen LLM Wiki und RAG? Bei RAG sucht das Modell bei jeder Anfrage neu in Rohdokumenten – Wissen akkumuliert sich nicht. Beim LLM Wiki wird Wissen einmalig beim Einlesen einer Quelle kompiliert und als verlinkte Markdown-Datei gespeichert. Jede neue Quelle baut auf dem bestehenden Wissensnetzwerk auf. Welche Tools brauche ich für ein LLM Wiki? Der empfohlene Stack: Obsidian als Frontend und Graph-Viewer, Claude Code als Terminal-Agent für Ingest und Query, Git für Versionskontrolle. Alles basiert auf lokalen Markdown-Dateien – keine Datenbank, kein Embedding-Server, keine Cloud-Infrastruktur erforderlich. Für welche Wissensbasengröße eignet sich LLM Wiki? Optimal bis ca. 50.000 bis 100.000 Tokens. Das entspricht etwa 150 bis 200 Seiten dichtem Text. Darüber hinaus braucht man entweder ein hybrides Modell oder wechselt zu RAG. Kann ein LLM Wiki mit einer Vektordatenbank kombiniert werden? Ja. Das häufigste Produktionsmuster: Das LLM Wiki übernimmt strukturiertes Kernwissen (Richtlinien, Architektur, Konzepte), RAG verwaltet den unstrukturierten Long Tail (historische Tickets, rohe Logs). Eine Routing-Schicht entscheidet, welches System angefragt wird. Wie verhindert man, dass das Wiki veraltet? Durch den Lint-Workflow: Periodisch überprüft der KI-Agent das Wiki auf Widersprüche, veraltete Behauptungen und verwaiste Seiten. Git sorgt dafür, dass jede Änderung nachvollziehbar bleibt und bei Fehlern rückgängig gemacht werden kann. Kann ich ein LLM Wiki auch im Team nutzen? Ja. Da das Wiki ein Git-Repository aus Markdown-Dateien ist, funktioniert die Teamkollaboration über Standard-Git-Workflows: Pull Requests, Branching, Code-Reviews. Jede Wiki-Änderung ist versioniert und nachvollziehbar. Was ist das Schema und warum ist es so wichtig? Das Schema ist eine Konfigurationsdatei (z. B. CLAUDE.md), die der KI erklärt, wie das Wiki strukturiert ist, welche Konventionen gelten und welche Workflows es bei Ingest, Query und Lint ausführen soll. Ohne Schema ist das LLM ein generischer Chatbot. Mit Schema wird es ein konsistenter Wiki-Maintainer – auch über mehrere Sessions hinweg. Brauche ich zwingend Obsidian und Claude Code für ein LLM Wiki? Nein. Obsidian und Claude Code sind der von Karpathy beschriebene Stack, aber das Muster ist tool-agnostisch. Entscheidend sind drei Dinge: ein Ordner für unveränderliche Rohquellen, ein Ordner für KI-generierte Markdown-Seiten und eine Konfigurationsdatei, die dem Agenten die Struktur vorgibt. Welcher Agent und welcher Editor genutzt werden, ist zweitrangig.

Fazit

Das LLM Wiki ist kein Hype-Konzept, sondern eine pragmatische Architekturentscheidung: Wer Wissen dauerhaft akkumulieren, Querverweise automatisch pflegen und mit minimalem Infrastrukturaufwand arbeiten will, findet im Wiki-Pattern einen validen Ansatz. RAG bleibt die richtige Wahl für große, dynamische Datenmengen. Für strukturiertes, kuratiertes Wissen in kleinen bis mittleren Größen kann das LLM Wiki in Effizienz und Wartbarkeit vorteilhafter sein – abhängig vom konkreten Anwendungsfall. Wie Karpathy selbst weitere KI-Agenten-Konzepte entwickelt, zeigt AutoResearch: Karpathys KI-Tool lässt Agenten autonom forschen.