LLM-Wiki vs. RAG-Wissensdatenbank

LLM Wiki vs. RAG

Anfang April 2026 stellte Andrej Karpathy ein neues Design-Pattern vor — LLM Wiki [1]. Dabei handelt es sich um ein Schema zum Aufbau persönlicher Wissensdatenbanken unter Nutzung von Sprachmodellen. Die Idee erscheint vielversprechend, da sie versucht, wesentliche Schwachstellen von LLM+RAG-Systemen zu adressieren. Sie führt neue Mechanismen ein und ergänzt das System um eine Wissensbasis, deren Ausbau und Pflege vollständig autonom (durch das LLM gesteuert) erfolgen kann, während sie gleichzeitig für den Menschen prüfbar bleibt. Das Konzept löst das Problem der fehlenden Wissenskumulation und verbessert die Fähigkeit zur Synthese von Informationen aus mehreren Quellen.

„Die Idee ist hier eine andere. Anstatt nur Daten aus Rohdokumenten zum Zeitpunkt der Fragestellung abzurufen, baut das LLM schrittweise ein dauerhaftes Wiki auf und pflegt es – eine geordnete, miteinander verknüpfte Sammlung von Markdown-Dateien, die zwischen Ihnen und den Rohquellen steht.“

LLM Wiki ist ein RAG-System vom Typ „Wiki-First“. Es nutzt den RAG-Mechanismus, um eine Wissensdatenbank zu durchsuchen, die laufend vom Modell selbst erstellt und aktualisiert wird. Dadurch „lernt“ das System und baut mit der Zeit einen immer umfassenderen Kontext auf, anstatt bei jeder neuen Anfrage bei Null anzufangen.

Dieses Konzept stellt einen Paradigmenwechsel dar:

Der Übergang vom bloßen Suchen (RAG) hin zur Kompilation von Rohdokumenten in eine konsistente, ständig aktualisierte Wissensbasis.

Wissen wird hierbei nicht als statische Bibliothek zum Durchsuchen betrachtet, sondern als „lebendiger Quellcode“, den die KI aktiv umbaut und instand hält.

Die wichtigsten Unterschiede auf einen Blick

Da LLM Wiki noch eine Neuheit ist, habe ich mich in diesem Vergleich hauptsächlich auf die konzeptionelle Ebene konzentriert. Natürlich ist RAG nicht gleich RAG, und auch LLM Wiki selbst wird sich mit der Zeit weiterentwickeln. Bestimmte fundamentale Unterschiede liegen jedoch schon jetzt klar auf der Hand. Erst wenn wir diese erkennen und ihren tatsächlichen Einfluss sowie die damit verbundenen Grenzen verstehen, können wir mit vollem Bewusstsein Lösungen der Spitzenklasse entwickeln.

Hier ist eine interessante Gegenüberstellung der Unterschiede zwischen LLM Wiki und RAG, basierend auf Artikel [2] von Emily Winks. Laut der Autorin:

„Die deutlichsten Unterschiede zeigen sich in drei Bereichen: Skalierung, Infrastruktur und Governance. LLM-Wikis punkten bei Einfachheit und Token-Effizienz unterhalb der Schwelle von 50.000 bis 100.000 Token. RAG überzeugt bei Skalierung, Dynamik und Mehrbenutzerzugriff. Keines von beiden gewinnt in Bezug auf Enterprise-Data-Governance – dies erfordert eine völlig separate Ebene.“

Zusammenfassung der wichtigsten Punkte:

• Architektur: LLM Wiki lädt den gesamten, strukturierten Index in den Kontext. RAG funktioniert anders – im Moment der Fragestellung werden dynamisch spezifische Wissensfragmente aus einer Vektordatenbank „gezogen“.
• Skalierung: LLM Wiki schlägt sich hervorragend im Bereich von 50.000–100.000 Token. RAG hingegen kennt beim Aufbau der Vektordatenbank kein „Limit“ – es bewältigt Millionen von Dokumenten.
• Infrastruktur: LLM Wiki ist eine nahezu wartungsfreie Lösung – es wird kein zusätzliches Backend benötigt. RAG erfordert einen kompletten technischen Apparat: Vektordatenbank, Embedding-Mechanismen und eine Retrieval-Ebene.
• Datenmanagement: Keiner dieser Ansätze löst für sich allein die Frage der Datensicherheit im Unternehmen. Dafür ist ein separates System erforderlich, etwa ein professioneller Datenkatalog mit fortgeschrittener Zugriffskontrolle.

Das RAG-Paradoxon: Warum das Rad neu erfinden?

Derzeit ist RAG (Retrieval-Augmented Generation) der Standard. Man füttert Dokumente ein, stellt eine Frage und die KI durchsucht die Basis. Klingt gut? Nur oberflächlich. RAG bringt dutzende Herausforderungen mit sich – es erfordert einen soliden Engineering-Ansatz und starke architektonische Fundamente. Bei jeder Anfrage durchsucht das System den gesamten Dokumentenbestand (bzw. Fragmente davon), wählt die wichtigsten Informationen aus und beginnt die gesamte Arbeit der Synthese wieder bei Null. Natürlich können identische Abfragen vom Cache bedient werden. Fragt man jedoch morgen nach etwas sehr Ähnlichem, wird das Basis-RAG wieder dieselben Textausschnitte (oft einen beträchtlichen Stapel) ausgeben, sie neu ordnen und muss wieder mühsam den Sinn aus diesem Durcheinander zusammensetzen.

Erschwerend kommt hinzu, dass die Verarbeitung auf einer begrenzten Anzahl von Textfragmenten basiert, was bedeutet, dass der Großteil der Inhalte bei der Erstellung der Antwort gar nicht analysiert wird. Obwohl dies bis zu einem gewissen Grad gewollt ist – man möchte schließlich keine irrelevanten Inhalte berücksichtigen – hat es Nebenwirkungen. Oft passiert es nämlich, dass schwächer verknüpfte Fragmente, die im jeweiligen Kontext dennoch wichtig wären, schlichtweg übergangen werden.

LLM Wiki kehrt diesen Prozess um. Anstatt Informationen erst zum Zeitpunkt der Anfrage (Query-Time) zu suchen, kompilieren wir das Wissen bereits beim Hinzufügen (Ingest-Time). Die KI wird zu Ihrem persönlichen Redakteur, der Fakten laufend umschreibt und zu einem stimmigen Ganzen verbindet. Dadurch müssen wir bei einer Anfrage nicht alle Dokumente von vorne durchsuchen. Es genügt, das bereits kompilierte Wissen in den Kontext einzufügen (sofern es in das Kontextfenster passt) oder einen ausgewählten, geordneten Teil davon (falls die Basis zu umfangreich oder die Limits des LLM zu restriktiv sind). Beim LLM-Wiki-Ansatz ist die Wissensbasis deutlich stabiler. Selbst wenn sich die Abfrage ändert, arbeitet die KI jedes Mal mit dem vollständigen Informationsstand, was eine wesentlich höhere Konsistenz der Antworten garantiert.

LLM Wiki: Revolution oder nur der „Hype“-Effekt von Andrej Karpathy?

Die Meinungen gehen auseinander. Skeptiker kritisieren, dass dies nichts Neues sei, die Lösung keine Zukunft habe und nicht skaliere. Optimisten loben die Elemente, die besser funktionieren, und entwerfen freudige Visionen über die Zukunft von LLM Wiki. Ich denke, es ist noch zu früh für ein abschließendes Urteil. Stattdessen schlage ich vor, die Vor- und Nachteile dieser Lösung genauer zu betrachten.

Systemisch betrachtet sehe ich einen großen Wert darin, die Wissensbasis (oder den Knowledge Graph) vom LLM und dem RAG-Mechanismus selbst zu trennen. Ich habe jedoch Zweifel, ob sich ein Wiki als Datenorganisationsmodell bei großer Skalierung bewährt oder ob wir hier eine andere Abstraktion benötigen. Sicherlich ist das Wiki-Format extrem nützlich, wenn ein Mensch den Inhalt prüft oder wenn wir Wissen in den Kontext eines Prompts übertragen.

Das gesammelte Wissen könnte jedoch in dedizierten Strukturen liegen, während eine separate Werkzeugebene (Tool-Layer) für die Prüfung und die Speisung des Modells verantwortlich ist.

Solche Werkzeuge könnten die Daten einfach extrahieren und erst in dem Moment in ein lesbares Markdown-Format konvertieren, wenn es tatsächlich benötigt wird.

Obwohl das Thema relativ frisch ist, gibt es bereits Versuche, LLM Wiki in Kombination mit einem Knowledge Graph einzusetzen – siehe dazu beispielsweise das Video [3] von Nodus Labs.