← Blog

Wissensmanagement für KI ist keine Zauberei, sondern Strukturarbeit

KnowledgeOS-Grundlagen · Teil 3

Wenn ein KI-Agent scheinbar mühelos durch einen großen Wissensbestand navigiert, wirkt das schnell wie eine besondere Fähigkeit des Modells. In der Praxis entsteht ein großer Teil dieser Leistung früher: bei der Strukturierung der Dateien, Ordner und Zuständigkeiten.

Ein Modell kann gute Zusammenfassungen schreiben und Verbindungen erkennen. Es kann aber nicht zuverlässig erraten, welche von drei ähnlich benannten Dateien gilt, ob ein Status noch aktuell ist oder ob eine alte Entscheidung inzwischen ersetzt wurde. Ein unklarer Wissensbestand wird durch KI nicht geordnet. Er wird nur schneller verarbeitet — einschließlich seiner Fehler.

Wissensmanagement für KI beginnt deshalb nicht mit einem Chatbot oder einer Vektordatenbank. Es beginnt mit grundlegender Strukturarbeit.

Ein Ordner ist noch kein Wissenssystem

Ein sauber benannter Ordner hilft beim Wiederfinden. Ein Wissenssystem muss mehr leisten. Es sollte beantworten können:

  • Welche Art von Inhalt liegt hier?
  • Welche Datei ist der Einstieg?
  • Welche Aussage ist aktuell und verbindlich?
  • Woher stammt sie?
  • Welche Entscheidung oder Aufgabe hängt daran?
  • Wann gilt ein Inhalt als veraltet oder abgeschlossen?

Solange diese Antworten nur im Kopf der Person existieren, die das System aufgebaut hat, bleibt der Bestand personengebunden. Für andere Menschen und für Agenten sieht er wie eine Sammlung plausibler Dateien aus.

Die Struktur muss deshalb einen Teil dieses stillen Wissens ausdrücklich machen.

Schemas geben Inhalten eine erkennbare Form

Ein Schema legt fest, welche Merkmale ein bestimmter Inhalt besitzt. Eine Recherche braucht beispielsweise ein Datum, ein Thema, Quellen und eine Kennzeichnung ihrer Belastbarkeit. Eine Entscheidung braucht einen Status, eine Begründung und den Hinweis, was sie ersetzt. Eine Aufgabe braucht ein Ziel, Prüfkriterien und gegebenenfalls Abhängigkeiten.

Das muss keine komplizierte Datenbank sein. Schon ein kleiner standardisierter Kopf in einer Klartextdatei kann dafür sorgen, dass Menschen und Maschinen denselben Inhalt gleich einordnen.

Schemas bringen drei entscheidende Vorteile:

  1. Erkennbarkeit: Ein Agent weiß, ob er gerade eine Quelle, eine Synthese, eine Entscheidung oder eine Aufgabe vor sich hat.
  2. Prüfbarkeit: Fehlende Pflichtangaben und ungültige Werte lassen sich automatisch erkennen.
  3. Verknüpfbarkeit: Inhalte können gezielt nach Status, Thema, Herkunft oder Beziehung zusammengeführt werden.

Das Schema beurteilt nicht, ob eine Aussage wahr ist. Es sorgt aber dafür, dass klar ist, welchen Anspruch sie besitzt und welche Belege geprüft werden müssen.

Eine Einstiegsdatei ist ein Vertrag

Viele Ordner enthalten eine README-Datei, die irgendwann einmal beschreibt, was dort liegt. Für agentengestützte Arbeit sollte sie mehr sein: ein stabiler Einstiegspunkt und ein kleiner Arbeitsvertrag.

Eine gute Einstiegsdatei erklärt nicht jede Einzelheit. Sie verweist auf die zuständigen Quellen:

  • Zweck und Grenzen des Bereichs,
  • aktuelle Statusquelle,
  • gültige Regeln und Entscheidungen,
  • Heimat von Research und Aufgaben,
  • mögliche Unterbereiche,
  • erlaubte Schreibziele.

Damit muss ein Agent nicht durch Dateinamen raten. Er beginnt an einem bekannten Ort und folgt ausdrücklichen Verweisen. Ändert sich die interne Struktur, wird dieser Vertrag aktualisiert; der Einstieg bleibt stabil.

Standards machen Ordner übertragbar

Ein einzelner gut strukturierter Projektordner ist hilfreich. Richtig wirksam wird das Prinzip, wenn verschiedene Bereiche dieselbe Grundgrammatik teilen.

Wenn Research, Entscheidungen, Planung und Archiv überall etwas Vergleichbares bedeuten, muss ein Agent nicht für jedes Projekt eine völlig neue Logik lernen. Gemeinsame Dateinamen, Inhaltstypen, Statuswerte und Lebenszyklen machen Navigation vorhersehbar.

Standardisierung bedeutet dabei nicht, dass jeder Bereich dieselben Ordner haben muss. Ein Produkt, ein persönlicher Wissensbereich und ein Research-System haben unterschiedliche Bedürfnisse. Der Standard sollte den gemeinsamen Kern festlegen und Erweiterungen erlauben, statt überall eine leere Einheitsstruktur zu erzwingen.

Die hilfreiche Frage lautet nicht: „Sind alle Ordner gleich?“ Sondern: „Kann dieselbe Navigationslogik zuverlässig erkennen, was hier gilt?“

Die Context Ladder: vom Groben zum relevanten Detail

Selbst ein gut strukturierter Wissensbestand kann zu groß sein, um ihn für jede Aufgabe vollständig zu laden. Deshalb braucht es eine Reihenfolge, in der Kontext erschlossen wird. Ich nenne sie Context Ladder — eine Leiter vom groben Systemrahmen bis zur konkreten Quelle.

Ein typischer Ablauf sieht so aus:

  1. Den zuständigen Bereich bestimmen.
  2. Seine Einstiegsdatei und grundlegenden Regeln lesen.
  3. Den Verweisen auf Status, Planung oder Wissensquellen folgen, soweit sie für die Aufgabe relevant sind.
  4. Bei einem Unterbereich denselben Ablauf eine Ebene tiefer wiederholen.
  5. Erst dann die konkreten Dokumente laden, die für die Arbeit benötigt werden.

Das verhindert zwei gegensätzliche Fehler. Der Agent startet weder mit zu wenig Kontext noch lädt er wahllos den gesamten Bestand. Die Architektur entscheidet, welche Schicht als Nächstes relevant ist.

Wichtig ist: Eine automatische Bereichserkennung darf nur ein Signal sein. Die tatsächliche Gültigkeit kommt aus den benannten Quellen und Verweisen, nicht aus der Vermutung eines Modells.

Automatische Prüfungen schützen die Struktur

Eine Konvention, die nur in einem Dokument beschrieben ist, wird im Alltag irgendwann verletzt. Deshalb sollten Regeln, die sich eindeutig prüfen lassen, auch technisch geprüft werden.

Beispiele sind:

  • Pflichtfelder fehlen,
  • ein Statuswert ist nicht erlaubt,
  • ein Link zeigt auf eine nicht mehr vorhandene Datei,
  • ein Unterbereich besitzt keinen gültigen Einstiegspunkt,
  • eine Übersicht widerspricht ihrer zuständigen Quelle,
  • ein archiviertes Dokument wird noch als aktives Ziel verwendet.

Solche Prüfungen machen das System nicht intelligent. Gerade darin liegt ihre Stärke: Für dieselbe Eingabe liefern sie dasselbe Ergebnis. KI bleibt für Aufgaben zuständig, die Urteil erfordern — Recherche, Synthese, Widerspruchsanalyse und Entwurf. Code übernimmt die festen Regeln.

Suche ersetzt keine Architektur

Volltextsuche, semantische Suche und Vektordatenbanken sind nützliche Zugänge. Sie beantworten die Frage: „Was könnte zu diesem Thema passen?“ Sie beantworten nicht automatisch: „Welche Quelle gilt?“

Ein Suchtreffer kann alt, widerlegt oder nur ein Zwischenschritt sein. Ohne Status, Herkunft und Zuständigkeit wird Relevanz leicht mit Gültigkeit verwechselt.

Deshalb sollte eine Suchschicht auf der Wissensarchitektur aufbauen, nicht sie ersetzen. Sie findet Kandidaten. Die Struktur erklärt ihren Anspruch.

Ein brauchbarer Start braucht nicht viel

Für ein neues Projekt reicht zunächst ein kleiner Kern:

  1. eine Einstiegsdatei mit Zweck, Grenzen und Verweisen,
  2. eine einzige Quelle für den aktuellen Status,
  3. getrennte Orte für Quellen, Entscheidungen und Aufgaben,
  4. wenige einheitliche Inhaltstypen mit Pflichtangaben,
  5. ein Archiv, das nicht mehr als aktiver Arbeitsraum gilt,
  6. eine einfache Prüfung für Links und Pflichtfelder.

Erst wenn echte Nutzung zusätzliche Unterschiede sichtbar macht, sollte die Struktur wachsen. Zu viele Inhaltstypen und Regeln am Anfang erzeugen nur eine zweite Form von Unordnung.

Das Ergebnis ist kein magisches KI-Gedächtnis. Es ist etwas Nützlicheres: ein nachvollziehbarer Wissensbestand, in dem Menschen und unterschiedliche KI-Werkzeuge dieselben gültigen Quellen finden, bearbeiten und prüfen können.

Der vorherige Teil der Reihe erklärt, warum dafür eine benannte Single Source of Truth nötig ist. Die praktische Systemseite zeigt das Zusammenspiel im KnowledgeOS.

Weiterlesen

Methoden, Entscheidungen und Sackgassen.

Das Labor zeigt Systeme im Querschnitt. Im Blog stehen die einzelnen Bauentscheidungen; unter Analysen zeigt der Unternehmenskompass, was daraus für Unternehmen folgt.