Die KI-Wissensschicht: 127 strukturierte Seiten, keine Vektordatenbank und was falsch gemacht wurde

Andrej Karpathy veröffentlichte im April 2026 einen Gist, der ein Muster für den Aufbau persönlicher Wissensbasen mit LLMs beschreibt. Innerhalb einer Woche: 99.000 Bookmarks. Mehrere Implementierungen wurden binnen Tagen Open Source. graphify erschien nach 48 Stunden und sammelte 27.000 weitere ein. Das Muster traf einen Nerv, weil es ein vertrautes Problem benennt: Die meisten Agenten verfügen über kein persistentes Gedächtnis zwischen Sitzungen. Jedes Gespräch beginnt bei null. Geschäftskontext, Ziele, Stimme und Hintergrund werden jedes Mal neu erklärt, und das Ergebnis bleibt generisch, weil der Input nichts hatte, womit er hätte arbeiten können.

Bei webvise ist eine Wissensschicht für Recherche und Projektdokumentation im Einsatz. Das sind die Erkenntnisse daraus.

Agenten vergessen zwischen Sitzungen.

Der Standard-KI-Workflow ist zustandslos. Man öffnet einen Chat, erklärt das Anliegen, erhält eine Antwort, schließt den Chat. In der nächsten Sitzung beginnt dieselbe Erklärung von vorn. Der aufgebaute Kontext ist verloren. Die meisten kompensieren das mit längeren Prompts, eingefügten Hintergrunddokumenten oder Datei-Uploads zu Beginn jeder Sitzung. Das funktioniert, skaliert aber nicht. Irgendwann füllt sich das Kontextfenster, die Qualität sinkt, und die Vorbereitung des Prompts kostet mehr Zeit als die eigentliche Arbeit.

Die Wissensschicht löst das auf Infrastrukturebene. Statt jeden Prompt mit Kontext aufzufüllen, erhält der Agent Zugang zu einer persistenten, strukturierten Wissensbasis, die er vor jeder Aktion liest. Er kennt bereits das Unternehmen, die Stimme, die Projekte, die Geschichte. Die Wiederholung entfällt, die Arbeit beginnt sofort.

Drei Schichten, keine Vektordatenbank

Die Architektur besteht aus drei Teilen:

• Rohdatenquellen. Ein Ordner unveränderlicher Dokumente: Artikel, Notizen, Transkripte, PDFs, Meeting-Aufzeichnungen, Recherchen. Der Agent liest diese, verändert sie nie. Sie sind die Quelle der Wahrheit.
• Das Wiki. Ein Verzeichnis LLM-generierter Markdown-Dateien mit Querverweisen. Entitätsseiten, Konzeptseiten, Synthesen, Vergleiche, Playbooks. Dieser Layer gehört vollständig dem Agenten: Er erstellt Seiten, aktualisiert sie bei neuen Quellen, pflegt Querverweise und hält alles konsistent. Gelesen wird von Menschen; geschrieben vom Agenten.
• Das Schema. Ein Konfigurationsdokument (CLAUDE.md, AGENTS.md oder ähnlich), das dem Agenten mitteilt, wie das Wiki strukturiert ist, welche Konventionen gelten und welche Workflows auszuführen sind. Es verwandelt einen generischen LLM in einen disziplinierten Wiki-Maintainer.

Das Wiki ist ein kompiliertes Artefakt. Der Agent leitet Wissen nicht bei jeder Anfrage neu ab. Er kompiliert einmal, setzt Querverweise und hält alles aktuell. Kommt eine neue Quelle hinzu, integriert der Agent sie in das bestehende Wiki und aktualisiert jede betroffene Seite. Bei einer Anfrage liest er vorkompilierte Seiten, anstatt Rohdokumente zu durchsuchen.

Warum dieser Ansatz RAG in den meisten Fällen übertrifft

RAG leitet Antworten zur Anfragezeit ab, indem es Dokumente in Chunks zerlegt und relevante Fragmente sucht. Der kompilierte Wiki-Ansatz überspringt das vollständig. Der graphify-Benchmark misst 71,5-mal weniger Tokens pro Anfrage im veröffentlichten Vergleich; die Ergebnisse hängen von Korpusmerkmalen und Anfrageverteilung ab. Eigene Messungen zeigen rund 1.000 Tokens an Vault-Inhalt pro Anfrage, verglichen mit 3.000 oder mehr Tokens, die eine typische RAG-Pipeline injiziert.

Einen ausführlichen technischen Vergleich von RAG und indexbasiertem Retrieval gibt es im verlinkten Artikel. Kurzfassung: In den benchmarkierten Workloads übertraf der kompilierte Wiki-Ansatz RAG bei Genauigkeit, Kosten und Betriebskomplexität. Keine Vektordatenbank, kein Embedding-Modell, keine Chunking-Strategie, kein Re-Indexing-Job. Fünf Shell-Befehle und eine gepflegte Indexdatei.

Die Entwicklung verlief in drei Phasen: One-Shot-RAG von 2020 bis 2023, agentisches RAG mit Multi-Hop-Retrieval von 2023 bis 2024, und ab 2025 Context Engineering, bei dem der Agent seinen eigenen Kontext aus mehreren Quellen aufbaut. Die Wissensschicht ist die Infrastruktur für diese dritte Phase. Die meisten Teams bauen noch für Phase eins.

Erkenntnisse aus dem produktiven Einsatz

Das interne Wiki umfasst derzeit 127 strukturierte Seiten in sieben Kategorien: Personen, Unternehmen, Konzepte, Playbooks, Sammlungen, Synthesen und Tools. Jede Seite folgt einer Standardvorlage mit YAML-Frontmatter, Querverweisen über Obsidian-Wikilinks und Quellenangaben. Der Agent führt sechs definierte Operationen aus: Ingest, konversationelles Update, Abfrage, Lint, Anreicherung und Reorganisation.

• Die Schemadatei ist entscheidend. Alles andere ergibt sich daraus. Ein gut geschriebenes Schema erzeugt ein diszipliniertes Wiki mit konsistenten Konventionen. Ein vages Schema erzeugt Halluzinationen und Wildwuchs. Die aktuelle Version umfasst rund 200 Zeilen und deckt Verzeichnisstruktur, Seitenformat, alle sechs Operationen, Namenskonventionen und den Umgang mit Widersprüchen ab. Mehrere Iterationen waren nötig, um es zu verfeinern.
• Dedup-first verhindert Seiten-Wildwuchs. Die Regel: Bevor eine neue Seite angelegt wird, wird das bestehende Wiki auf überlappende Inhalte durchsucht. Deckt eine vorhandene Seite 60 Prozent oder mehr desselben Inhalts ab, wird diese Seite angereichert statt eine neue angelegt. Ohne diese Regel füllt sich das Wiki mit redundanten Seiten, die Wissen in unbrauchbare Fragmente zersplittern.
• Anfragen verdichten sich zur Wissensbasis. Liefert eine gute Frage eine nützliche Antwort, wird diese als neue Wiki-Seite abgelegt. Bei der nächsten verwandten Frage steht dem Agenten bereits eine vorkompilierte Synthese zur Verfügung. Das ist der Compounding-Effekt, der das System über die Zeit besser statt nur größer macht.
• Ingest-Qualität hängt von Disziplin ab. Eine rohe Quelle mit dem Befehl "ingest this" einzuspielen liefert eine dünne Zusammenfassung. Den Agenten durch die Quelle zu führen, Erkenntnisse zu besprechen und Schwerpunkte zu setzen, erzeugt Seiten, die im wachsenden Wiki nützlich bleiben. Ein strikter Workflow gilt: Rohdatei bereinigen, Kernpunkte besprechen, Freigabe abwarten, dann vollständig extrahieren.
• Die Indexdatei ist das Retrieval-System. Der Root-Index hat 22 Zeilen. Jedes Unterverzeichnis hat einen eigenen Index, der jede Seite mit einer einzeiligen Beschreibung auflistet. Der Agent liest den Root-Index bei rund 400 Tokens, identifiziert das richtige Unterverzeichnis, liest dessen Index und ruft dann die spezifischen Seiten ab. Die meisten Anfragen sind mit drei Lesevorgängen und rund 1.000 Tokens an Vault-Inhalt abgeschlossen.

Das Schema ist die wichtigste Datei, die Sie schreiben werden

Karpathy nennt es das Schema. Bei webvise heißt es CLAUDE.md. Manche Frameworks teilen es in einen Knowledge Base Layer und eine Brand Foundation auf. Der Name ist zweitrangig. Die operationale Tatsache ist: Diese eine Datei steuert, wie der Agent sich in jeder Sitzung verhält.

Ein gutes Schema definiert:

• Verzeichnisstruktur. Wo Rohdatenquellen abgelegt werden, wo Wiki-Seiten liegen, wie sie in Kategorien organisiert sind.
• Seitenformat. Frontmatter-Felder, Abschnittsstruktur, Quellenangabe-Regeln, Querverweiskonventionen.
• Operationen. Schritt-für-Schritt-Workflows für das Ingestieren von Quellen, das Beantworten von Anfragen, das Ausführen von Health Checks und die Pflege des Wikis über die Zeit.
• Qualitätssicherung. Was eine Seite vollständig macht. Wann Unsicherheit zu markieren ist. Wie mit widersprüchlichen Quellen umzugehen ist. Die Regel, dass jede Aussage auf eine Quelle zurückführbar sein muss.

Ohne diese Vorgaben improvisiert der Agent. Er legt Seiten an zufälligen Stellen an, verwendet inkonsistente Formate, dupliziert Inhalte über Seiten hinweg und weicht mit jeder Sitzung von bestehenden Konventionen ab. Das Schema verhindert Drift. Es wird wie Produktionscode behandelt: Jede Änderung ist bewusst und wird an echten Ingest-Szenarien getestet.

Aufbau in 20 Minuten

17 Dateien, ein Content-Skill-Graph oder eine eigene Embedding-Pipeline sind nicht nötig. Vier Dinge reichen:

• Ein Obsidian-Vault mit zwei Ordnern. `raw/` für Quelldokumente und `wiki/` für agentengenerierte Seiten. In Obsidian geöffnet, stehen Graph-Ansicht und Navigation zur Verfügung.
• Eine Schemadatei. Ausgangspunkt ist Karpathys Gist. Verzeichnisstruktur und Seitenformat auf die eigene Domäne anpassen. Zum Start unter 200 Zeilen halten.
• Ein LLM-Agent mit Dateizugriff. Claude Code, OpenAI Codex oder jeder Agent, der Markdown-Dateien lesen und schreiben kann. Auf den Vault ausrichten, den er beim Start liest.
• Die erste Quelle. Einen Artikel, Notizen oder ein Dokument in `raw/` ablegen. Den Agenten anweisen, ihn zu ingestieren. Er erstellt Wiki-Seiten, baut Querverweise auf und aktualisiert den Index.

Das ist der vollständige Kreislauf. Das System verbessert sich täglich, weil jede neue Quelle und jede gestellte Frage das Wiki anreichert. Der erste Ingest erfordert 10 Minuten aktive Aufmerksamkeit. Beim zwanzigsten kennt der Agent die Domäne gut genug, um mit minimaler Führung zu extrahieren und Querverweise zu setzen.

Optionale Werkzeuge beim Skalieren: qmd von Tobi Lutke für lokale Hybridsuche mit BM25 und Vektorretrieval ab 300 Seiten. Die Obsidian Web Clipper-Erweiterung, um Web-Artikel schnell in den Raw-Ordner zu bringen. Dataview für Abfragen über Seiten-Frontmatter. Git für Versionshistorie. Nichts davon ist zum Start erforderlich.

Was keine Rolle spielt

Der Großteil der Komplexität, den Menschen mit KI-Wissenssystemen verbinden, ist Aufwand für Probleme, die noch gar nicht existieren. Eine Vektordatenbank für 200 Dokumente, ein eigenes Embedding-Modell, wenn ein gepflegter Index das Retrieval übernimmt, eine Re-Indexing-Pipeline, wenn das Hinzufügen eines Dokuments das Schreiben einer Datei bedeutet, eine Chunking-Strategie, wenn die Seite die Einheit ist. Nichts davon ist in der Größenordnung, in der die meisten Unternehmen operieren, notwendig.

Das Muster funktioniert, weil Markdown einfach ist und LLMs es gut lesen und schreiben können. Die Infrastrukturkosten sind null. Die Wartungskosten sind gering, weil der LLM Index-Updates übernimmt; eine periodische menschliche Überprüfung der Genauigkeit bleibt empfehlenswert. Der einzige echte Aufwand liegt in der Disziplin, das Schema präzise zu halten und die Ingest-Qualität hochzuhalten. Das ist ein menschliches Problem, kein technologisches.

Anwendungsfälle im Unternehmen

Dieselbe Architektur funktioniert im Unternehmensmaßstab. Persönliche Notizen werden durch Kundendokumentation, Sales-Playbooks, Onboarding-Leitfäden und interne SOPs ersetzt. Den Agenten einer Einzelperson ersetzen die Agenten aller Teammitglieder, die aus einer gemeinsamen Wissensbasis lesen.

Das Muster ist identisch: Rohdatenquellen gehen ein, der Agent kompiliert strukturierte Seiten, Querverweise entstehen automatisch, Menschen validieren. Der Unterschied liegt darin, dass neue Teammitglieder dank einer gemeinsamen Wissensschicht sofort produktiv sind. Ihr Agent kennt bereits die Kundenhistorie, die internen Konventionen und den Projektkontext. Kein sechswöchiges Einarbeiten. Kein Stammwissen, das im Kopf einer einzelnen Person gesperrt bleibt.

Karpathy nennt es ein LLM-Wiki. Eric Osiu nennt es ein Shared Brain. Cody Schneider nennt es ein Data Warehouse. Die Bezeichnung wechselt; das Muster bleibt: Agenten benötigen kompiliertes, strukturiertes Wissen, um nützliche Arbeit zu leisten. Ohne persistenten Kontext arbeiten Prompts ohne das institutionelle Wissen, das sie brauchen.

webvise baut Wissensschichten für Unternehmen, die möchten, dass ihre KI-Agenten tatsächlich wissen, wovon sie reden. Wer mehr Zeit damit verbringt, seinen Tools Kontext zu erklären, als Nutzen aus ihnen zu ziehen, findet hier die Lösung. Kontakt aufnehmen.