LLM-Wiki: So baut KI deine Wissensdatenbank

Es gibt eine neue, vermeintlich bessere Alternative zu Rec, also dem klassischen Weg, wie man einem KI-Agenten eine Wissensdatenbank hinzufügt. Und die kommt von niemand geringerem als Andrej Karpathy, dem ehemaligen Mitbegründer von Open AI und AI-Direktor bei Tesla. Und selbst Google hat die Idee inzwischen aufgegriffen und weiterentwickelt. Die Rede ist von LLM Wiki. Und wir schauen uns heute an, was genau ein LLM Wiki ist, wie ihr euch ganz einfach ein eigenes LLM Wiki bauen könnt, wofür sich das Ganze eignet und ob es dann tatsächlich besser ist als ein klassisches Rec-System.

Bei einem klassischen Rec-System, also Retrieval Augmented Generation, werden deine Dokumente in kleine Abschnitte aufgeteilt, sogenannte Chunks. Jeder Chunk wird in einen Zahlencode umgerechnet, der seine Bedeutung abbildet. Diese Codes nennt man Embeddings und sie landen in einer Vektordatenbank, wo inhaltlich Ähnliches nah beieinander liegt. Stellst du eine Frage, wird auch sie in so einen Zahlencode umgerechnet und das System holt sich per Ähnlichkeitssuche die Chunks, die inhaltlich am nächsten dran liegen. Aus diesen Treffern baut die KI dann ihre Antwort. Das funktioniert auch soweit.

Karpathys Kritik ist aber, das System baut die Zusammenhänge zwischen den Chunks nicht einmalig beim Einlesen der Dokumente auf, sondern bei jeder Frage neu. Führt die KI Chunks aus drei verschiedenen Dokumenten zusammen, ist diese Verknüpfung nach der Antwort wieder weg. Das klingt erstmal nach einem reinen Effizienzproblem. Die KI macht halt jedes Mal dieselbe Arbeit. Der eigentliche Haken ist aber die Qualität. ein Abgleich stattfindet, bleiben Widersprüche unbemerkt nebeneinander stehen. Lädst du ein Dokument hoch, das einem Älteren widerspricht, wird es nicht abgeglichen, sondern einfach zusätzlich abgelegt. Beide Versionen liegen danach gleichberechtigt in der Datenbank. Und wenn die KI aus mehreren Dokumenten etwas Neues zusammenreimt, dann ist dieser Gedanke nach der Antwort wieder verschwunden. Er wird nirgendwo festgehalten. Fragst du später noch mal, musst du hoffen, dass die KI wieder die gleichen Schlüsse zieht.

Karpathys Idee dreht das Ganze um. Die eigentliche Denkarbeit, also das Lesen, Zusammenfassen, Verknüpfen und Widersprüche auflösen, passiert nur ein einziges Mal, nämlich beim Einpflegen neuer Dokumente und nicht bei jeder einzelnen Frage, die du dann an das System stellst. Konkret lässt man die KI ein strukturiertes Wiki aus Markdown-Dateien aufbauen und laufend pflegen. Kommt eine neue Quelle rein, wird sie nicht einfach abgelegt. Die KI liest sie, arbeitet die Erkenntnisse in die bestehenden Seiten ein, ergänzt Querverweise und löst Widersprüche auf oder markiert sie zumindest. Und da es sich um lesbare Markdown-Dateien handelt, kannst du nach diesem Schritt einmalig prüfen, ob die generierte Wissensdatenbank alles Wichtige enthält und deinen Vorstellungen entspricht. Dazu pflegt die KI ein Inhalts- verzeichnis mit, also ein Überblick, was wo im Wiki steht. Genau dieses Inhaltsverzeichnis soll die Vektordatenbank und Ähnlichkeitssuche wie bei einem Rex-System überflüssig machen. Hast du eine Frage, liest die KI erst das Inhaltsverzeichnis, öffnet gezielt die passenden Seiten und beantwortet daraus dann deine Frage.

Das grobe Konzept für das LLM-Wiki hat Karpathy in einer einzigen Datei zusammengefasst und über ein GitHub gist geteilt. Die ist dafür gedacht, dass du sie deinem KI-Agenten gibst und der dann zusammen mit dir dein persönliches Wiki aufsetzt. Karpathy gibt dabei bewusst nur die Idee vor und keine feste Struktur. Und weil so ein Wiki, wenn man nur eine grobe Idee reingibt, jedes Mal anders strukturiert ist, hat Google Cloud einen offenen Standard dafür entwickelt, das Open Knowledge Format, kurz OKF. Das legt mit ein paar festen Regeln fest, wie so ein Wiki bzw. die einzelnen Seiten im Wiki aufgebaut sein sollen. Das ist wie bei Karpathis LLM Wiki eigentlich nur eine einzige Datei, die man beim Erstellen des Wikis seinem KI-Agenten mitgeben muss, damit dieser weiß, wie er das Ganze strukturieren soll. Warum so ein festes Format überhaupt was bringt, kennst du vielleicht schon von Agent Skills. Die sind ja im Grunde auch nur ein festgelegtes Format, mit dem man einem KI-Agenten spezielles Wissen mitgeben kann. Und weil sich daran alle halten, kann man Skills ohne Anpassung untereinander austauschen. Bei OKF ist es ein ähnlicher Gedanke, nur eben für Wikis.

Das Einzige, was du auf jeden Fall für dein LLM Wiki brauchst, ist ein KI-Agenten zum Schreiben und Lesen von Dateien auf deinem Computer. Ich benutze Cloud Code, du kannst aber auch einen beliebigen anderen nutzen, wie z.B. Codex oder Open Code. Mehr brauchen wir theoretisch nicht, denn unser Wiki ist am Ende eigentlich nur ein Ordner mit Markdown-Dateien, die von unserem Agenten geschrieben und verwaltet werden. Ich benutze in dieser Demo außerdem Obsidian, um durch mein Wiki zu navigieren. Wer Obsidian noch nicht kennt, das ist im Kern eine kostenlose Notiz-App, mit der man sich die Zusammenhänge im Wiki gut visualisieren lassen kann. Entsprechend ist das auch Karpathys Empfehlung. Ihr könnt alternativ aber genauso gut eine IDE wie Visual Studio Code oder sogar einen ganz normalen Texteditor dafür nehmen. Obsidian kannst du kostenlos auf obsidian.md runterladen. Sobald du das gemacht hast, startest du die App und kannst dann einen neuen Vault erstellen. Vault ist in diesem Fall einfach nur eine andere Bezeichnung für einen Ordner auf deinem Computer. Du gibst einfach einen Namen deiner Wahl ein, ich nehme jetzt hier mal Foto-Wiki, dann wählst du den Ort zum Speichern aus und klickst auf Create. Jetzt landen wir direkt in unserem Vault und sehen hier eine Welcome-Datei. Die brauchen wir nicht und deswegen löschen wir sie einfach wieder. Wir können jetzt theoretisch die ganze Grundstruktur vom Wiki selbst anlegen, aber wir lassen uns das Ganze in einem nächsten Schritt komplett von unserem KI-Agenten bauen.

Und damit das Wiki jetzt auch wirklich der Idee von Karpathy und Googles Open Knowledge Format folgt, geben wir der KI zwei Textdateien an die Hand. Die verlinke ich euch in der Beschreibung. Die erste Datei ist aus Karpathys GitHub Gist zum LLM Wiki. Dort hat er, wie eben schon gesagt, grob festgehalten, wie so ein Wiki aufgebaut sein soll und welche Aktionen die KI durchführen soll. Nämlich das Hinzufügen von Quellen zum Wiki, das Abfragen von Wissen, wenn du Fragen hast, und das Überprüfen und Korrigieren des Wikis. Die zweite Datei ist die Spec MD von Google. Die Spec MD konkretisiert das Format des Wikis, also z.B. welche Metadaten oben auf einer Wiki-Seite stehen, wie das Inhaltsverzeichnis aussieht und so weiter. Beide Dateien habe ich mir jetzt einmal heruntergeladen und in meinem Foto-Wiki-Ordner gespeichert. Jetzt starte ich über das Terminal in meinem LLM-Wiki-Ordner Claude und sage ihm einfach: "Bitte lies LLM-Wiki.md, also Karpathys Idee für ein persönliches Wiki, und die Spec MD, also Googles Spezifikation für ein standardisiertes Format, im aktuellen Ordner und erstelle daraus nur die Struktur und Datei- bzw. Ordnergrundlage für ein persönliches Fotografie-Wiki. Fülle keine Inhalte aus, lege nur das Gerüst nach Karpathys Konzept an und halte dich dabei an die Google-Spezifikationen." Und jetzt warten wir mal ab, was Claude uns hier zusammenbaut.

So, Claude hat uns jetzt die Grundstruktur für unser Wiki gebaut und die entspricht genau Karpathys Idee. Erstmal haben wir hier unseren Raw-Ordner. Das ist der Ordner, in den ihr die Originaldokumente legt, deren Inhalt ins Wiki aufgenommen werden soll. Das können Bilder, Transkripte, Notizen, PDFs und so weiter sein. Claude darf diese Dateien nicht ändern, sondern nur lesen. Als Zweites haben wir den Wiki-Ordner. Hier landen die Markdown-Dateien, die die KI auf Basis eurer Originaldateien komplett selbst schreibt und pflegt. Also, das ist euer eigentliches Wiki. Claude hat das Thema Fotografie jetzt auch schon mal in Unterthemen heruntergebrochen und Unterordner erstellt, die natürlich jetzt noch leer sind. Außerdem gibt es noch zwei spezielle Dateien im Wiki-Ordner. Die erste ist die Index.md, dein Inhaltsverzeichnis. In unserem Fall hat Claude das sogar zweistufig angelegt. Die oberste Index.md verlinkt auf die einzelnen Themen-Unterordner und in jedem Unterordner liegt noch mal eine eigene Index.md, die die Seiten darin auflistet, jeweils mit kurzer Beschreibung. Der Sinn dahinter: Die KI muss nicht bei jeder Frage das komplette Wiki lesen. Sie schaut erst in den Index, findet über die Beschreibungen die relevanten Seiten und öffnet gezielt nur diese. Die zweite Datei ist die Log.md, das Änderungsprotokoll. Da wird nichts gelöscht, sondern nur ergänzt mit Zeitstempel, wann was dazu kam oder sich geändert hat. So kannst du später nachvollziehen, wie sich dein Wiki entwickelt hat. Und als drittes haben wir eine Schema-Datei. Wie die Datei genau heißt, hängt von eurem KI-Agenten ab. Bei Codex wäre es z.B. die Agents.md und in unserem Fall, weil wir Claude nutzen, ist das die Claude.md. Diese Datei ist quasi die Bedienungsanleitung für die KI. Da steht drin, wie das Wiki strukturiert ist, was passieren soll, wenn eine neue Quelle reinkommt oder ich eine Frage stelle, wie die KI bei Widersprüchen vorgeht und so weiter. Beim Schreiben der Datei hat Claude sich an Karpathys Idee zum LLM-Wiki und Googles Open Knowledge Format für die Standardisierung orientiert. Die können wir jetzt aber natürlich noch an unsere eigenen Vorstellungen anpassen. Wenn ich z.B. bei jedem Hinzufügen einer Datei erstmal einen genauen Plan von Claude haben möchte, welche Seiten er in meinem Wiki anpasst oder hinzufügt, könnte ich das hier noch konkretisieren. Ich würde die Datei jetzt aber erstmal so lassen.

Um jetzt die ersten Inhalte zu eurem Wiki hinzuzufügen, müsst ihr eigentlich nichts weiter tun, als eine Datei in den Raw-Ordner zu legen, in eurem Chat mit Claude zu wechseln und ihm zu sagen, dass er die Datei hinzufügen soll. Ich füge jetzt als Beispiel einmal den Wikipedia-Artikel zum Thema Fotografie hinzu. Um das möglichst einfach zu machen, habe ich die Obsidian Web Clipper Extension aktiviert. Mit der kann man Internetseiten direkt als Markdown in Obsidian laden. Dafür klicke ich, wenn ich auf der gewünschten Seite bin, hier oben auf das Obsidian-Symbol und danach auf Add to Obsidian. In Obsidian findet man diese Seite dann unter Clippings und die ziehe ich von dort einmal in unseren Raw-Ordner. Und jetzt wechsle ich ins Terminal und sage Claude, ich habe die erste Datei in den Raw-Ordner gelegt, bitte dem Wiki hinzufügen. Und jetzt sehen wir, dass unser Wiki sich mit Wissen gefüllt hat. Z.B. sehen wir im Ordner Concepts eine Seite zur Fotografie als Kunst, wobei wir hier oben ein paar Metadaten haben, die orientieren sich an Googles Open Knowledge Format und darunter dann den eigentlichen Inhalt, schön zusammengefasst und strukturiert und mit Verweisen zu anderen Themen. Und wenn ich jetzt in Obsidian über die seitliche Navigation in den sogenannten Graph View wechsle, sehe ich mein ganzes Wiki als grafische Darstellung. Jedes Thema ist ein Punkt und die Linien dazwischen sind die Verknüpfungen. Ich kann einzelne Punkte anklicken, sehe deren Verbindungen und kann mich von da an direkt zu den einzelnen Themen durchklicken. Man kann übrigens anpassen, was in diesem Graphen angezeigt wird. Aktuell werden alle Verbindungen zwischen allen Dateien in meinem Oberordner angezeigt, aber ich will eigentlich nur meinen Wiki-Ordner sehen. Und auch im Wiki-Ordner brauche ich z.B. die Index-Dateien nicht, die ja einfach nur auf die ganzen Unterseiten des Ordners verlinken. Anpassen kann man das Ganze über Einstellungen, Files and Links, Advanced, Excluded Files. Und da kann man dann Filter hinzufügen. Ich habe das jetzt hier über eine Regular Expression gemacht. Und ich will jetzt auch einmal wissen, ob Claude mir mit Hilfe des Wikis Antworten auf meine Fragen geben kann. Konkret frage ich jetzt mal, was kannst du mir zum entscheidenden Augenblick sagen? Und Claude geht jetzt genauso vor, wie wir uns das vorgestellt haben. Er schaut sich erstmal alles an, welche im Index steht, welche Seite relevant sein könnte, liest die durch und gibt mir die richtige Antwort.

Neben dem Hinzufügen und dem Abfragen von Wissen gibt's noch eine dritte die von Camparty vorgesehen und auch in unserer Claude MD beschrieben ist. Und das ist die Überprüfung des Wikis. Es können sich natürlich mit der Zeit und mit dem Wachsen des Wikis Fehler einschleichen und genau das wollen wir natürlich vermeiden, damit das Wiki langfristig brauchbar bleibt. Entsprechend bitte ich Claude jetzt einmal das ganze Wiki zu überprüfen, auch wenn das jetzt natürlich noch nicht so viel Sinn ergibt. Das ganze mache ich mit dem Prompt, bitte überprüfe das gesamte Wiki. Und er hat auch tatsächlich ein paar Kleinigkeiten gefunden, obwohl wir nur eine einzige Quelle bisher hinzugefügt haben. Unter anderem habe ich mich scheinbar in der Zwischenzeit einmal verklickt und aus Versehen einen neuen Ordner Concepts angelegt, den es eigentlich schon gibt. Da wartet er auf meine Erlaubnis, den zu löschen, was ich ihm jetzt einmal erlaube, damit unser Wiki wieder sauber ist. [musik]

Jetzt, wo ihr das Wiki in Aktion gesehen habt, stellt ihr euch vielleicht die Frage, wann so ein LLM Wiki überhaupt Sinn ergibt. Camparty hat in seinem GitHub Gist ein paar Anwendungsfälle aufgelistet, z.B. die Recherche zu einem bestimmten Thema oder auch zu einem persönlichen Hobby wie Fotografie. Für solche Anwendungsfälle finde ich so einen sehr pragmatischen und einfachen Ansatz valide. Ihr wollt euch wahrscheinlich nicht lange mit dem Setup rumschlagen und der Aufwand ist mit so einem Wiki recht überschaubar. Außerdem habt ihr auch, wenn ihr nicht die KI benutzt, um euch Fragen beantworten zu lassen, ein übersichtliches und für euch verständliches Nachschlagewerk, in das ihr jederzeit reinschauen könnt. Bei einem klassischen Rex-System mit einer Vektordatenbank ist das Ganze natürlich deutlich abstrakter und weniger einfach nachzuvollziehen.

Ein Punkt, der aber außerdem auftaucht und den auch Google als Anwendungsfall nennt, ist der Unternehmenskontext. Und den finde ich ehrlich gesagt etwas problematisch, denn es gibt ein paar echte Probleme beim LLM-Wiki, die aus meiner Sicht nicht vernachlässigbar sind, wenn man sich in einem professionellen Kontext befindet, in dem das Wiki zuverlässig funktionieren muss. Eine Schwäche des Wikis ist verlustbehaftete Kompression. Das Wiki ist ja nicht die Originalquelle, sondern eine Umformulierung davon. Wenn in einer Quelle wichtige Einschränkungen stehen, also z.B. "Dieses Ergebnis gilt nur unter Bedingung X", dann kann es passieren, dass die KI diese Einschränkung in der Wiki-Zusammenfassung weglässt. Wenn ihr dann später nur noch das Wiki lest, ist diese Einschränkung effektiv aus eurer Wissensbasis verschwunden. Und jedes Mal, wenn dieses komprimierte Wissen erneut aktualisiert wird, kann sich der Fehler weiter verstärken. Dazu kommt das Problem der sauberen Aktualisierung. Wenn eine neue Quelle zwölf bestehende Seiten betrifft, wie stellt man sicher, dass Konflikte sauber aufgelöst und alle wichtigen Stellen angepasst werden? Kapathys Antwort ist "Human in the Loop", also, dass ihr jede Quelle einzeln einarbeiten lasst und die Updates überprüft. Das ist natürlich etwas Arbeit, fängt aber offensichtliche Fehler ab. Was es nicht abfängt, sind Sachen, die weggelassen werden, weil ihr ja nur das seht, was die KI geschrieben hat. Wenn ihr euch jetzt dagegen absichern wollt, indem ihr jede Quelle vollständig selbst lest, dann ist ein großer Teil des Effizienzgewinns davon, dass die KI das Wiki schreibt, wieder weg. Das Nächste, was problematisch werden könnte, ist das gleichzeitige Bearbeiten durch mehrere Personen. Wie stellt man sicher, dass man sich nicht gegenseitig beim Updaten in die Quere kommt? Dafür gibt es aktuell keine Lösung. Die letzte Schwäche, die ich nennen möchte, ist die Skalierung. Kaparthy sagt selbst, dass sein Wiki bei rund 100 Quellen und mehreren hundert Seiten ganz gut funktioniert. Darüber hinaus kann es aber schwieriger werden. Sobald der Index samt der relevanten gelesenen Seiten nicht mehr komplett in den Kontext passt, braucht ihr wieder eine echte Suche mit Ranking über die Wiki-Seiten. Also ein Teil genau der Infrastruktur, die man mit dem reinen Index eigentlich vermeiden wollte. Und auch das saubere Aktualisieren und Überprüfen wird mit wachsendem Wiki für die KI immer schwieriger. [musik]

Kaparthy hat Recht damit, dass klassische RAG-Systeme echte Schwächen haben. Das LLM-Wiki ist eine sehr einfache Antwort darauf und klingt fast zu gut, um wahr zu sein. Ihr habt es in kurzer Zeit stehen, braucht keine Datenbank und kein großes technisches Wissen. Was in der ganzen RAG-Diskussion aber fast immer untergeht: Das Wiki ist nicht der einzige Weg, diese Schwäche anzugehen. Auch in der RAG-Welt gibt es schon länger fortgeschrittenere Ansätze, die die von Kaparthy geschilderten Probleme adressieren. Nur haben die ihren Preis. Während ihr das Wiki in wenigen Minuten aufsetzt, braucht ihr dafür deutlich mehr Zeit und auch echtes Fachwissen. Was außerdem fehlt, sind belastbare Tests beider Ansätze gegeneinander. Wir wissen überhaupt nicht, wie gut ein LLM-Wiki im Vergleich zu einem RAG-System abschneidet. Was wir aber wissen: Beide sind komplett unterschiedliche Ansätze mit unterschiedlichen Stärken und Schwächen und deswegen würde ich sowieso keine der beiden Lösungen als Ersatz für die andere sehen. Wenn ihr eine kleine Wissensdatenbank für euch selbst aufbauen wollt und euch ist wichtig, dass das Ergebnis für euch lesbar und der Ansatz einfach ist, würde ich euch eher kein RAG-System mit einer Vektordatenbank empfehlen. Wenn ihr im Unternehmenskontext seid und einen internen Chatbot bauen wollt, der auch Zugang zu einer Datenbank hat und dort Live-Daten auslesen kann, wäre ein Agentic Rec System passender als ein LLM Wiki. Welcher Weg für euch der richtige ist, hängt davon ab, was ihr genau braucht und wie viel Aufwand ihr bereit seid zu investieren. Mein Rat daher zum Schluss, probiert das Wiki Pattern aus, wenn euer Use Case dazu passt und ihr möglichst schnell ohne viel Fachwissen starten wollt. Ein pauschaler Ersatz für Rec ist es aber nicht.

Ich hoffe, euch hat das Video gefallen und vor allem geholfen, LLM Wiki zu verstehen und vielleicht auch euer eigenes aufzubauen. Sollte dem so sein, lasst gerne ein Like da. Solltet ihr noch Fragen haben, schreibt sie gerne in die Kommentare und wenn ihr keine Videos dieser und ähnlicher Art mehr verpassen wollt, abonniert auch gerne den Kanal. Und wenn ihr tiefer in das Thema KI und Automation einsteigen wollt, dann schaut auch gerne in der Community vorbei. Den Link findet ihr unten in der Beschreibung. In diesem Sinne, bis zum nächsten [musik] Mal. [musik]