Wartung der LLM-Wiki: Drift, Widersprüche und Überprüfung

Ein LLM-Wiki scheitert, wenn alte Fakten plausibel bleiben, Widersprüche geglättet werden und generierte Zusammenfassungen von ihren Quellen abweichen.

Wartung ist das eigentliche Produkt jedes kompilierten Wissenssystems. Das Erstellen von Wiki-Seiten ist im Vergleich zum Aufrechterhalten ihrer Vertrauenswürdigkeit über Monate des Dateneingangs, von Bearbeitung, Überarbeitung und neuen Quellen hinweg straightforward (geradlinig/einfach).

Dieser Artikel behandelt die operative Seite von LLM-Wiki-Systemen: Drift-Erkennung (Abweichungserkennung), Widerspruchsprüfungen, Zitiersdisziplin, Linting, Git-Review und Wartungsworkflows. Er setzt voraus, dass Sie das grundlegende Muster, das in LLM Wiki – Kompiliertes Wissen, das RAG nicht ersetzen kann beschrieben wird, bereits verstehen: Rohe Quellen werden in dauerhafte Markdown-Seiten kompiliert, die später von Menschen und Agenten abgefragt werden können. Die ruhige, aber klare Ansicht ist, dass ein LLM-Wiki ohne Wartung nur ein optisch ansprechenderer Friedhof für Wissen ist.

Was LLM-Wiki-Wartung unterscheidet

Traditionelle Wikis verrotten, weil die Leute aufhören, sie zu aktualisieren. RAG-Systeme (Retrieval-Augmented Generation) driftieren ab, weil sich der Korpus ändert, Chunks veralten, Metadaten schwach sind und die Retrieval-Funktion weiterhin plausible, aber veraltete Fragmente findet. Der tiefere Grund ist, dass Retrieval und Darstellung unterschiedliche Probleme lösen: Retrieval kann gegen frische Daten erneut ausgeführt werden, aber eine bereits kompilierte Darstellung muss aktiv ehrlich gehalten werden.

Ein LLM-Wiki hat einen anderen Fehlermodus. Es kann sauber aussehen, auch wenn es falsch ist.

Die Seiten sind möglicherweise gut formatiert. Die Links funktionieren vielleicht. Die Zusammenfassungen klingen möglicherweise ausgewogen. Aber unter dieser ordentlichen Oberfläche kann das System kritische Fakten verloren haben, inkompatible Konzepte verschmolzen, Zusammenfassungen statt Quellen zitiert oder eine alte Entscheidung so beibehalten haben, als würde sie noch gelten.

Deshalb muss die Wartung eines LLM-Wikis sowohl Struktur als auch Bedeutung überprüfen.

Das Ziel der Wartung

Das Ziel ist nicht, jede Seite perfekt zu machen. Das ist zu teuer und führt meist zu aufgegebenen Systemen.

Das Ziel ist es, das Wiki nützlich, überprüfbar und wiederherstellbar zu halten.

Ein gewartetes LLM-Wiki sollte es ermöglichen, folgende Fragen einfach zu beantworten:

• Welche Quellen stützen diese Behauptung?
• Wann wurde diese Seite zuletzt überprüft?
• Hat sich dieses Konzept geändert?
• Gibt es widersprüchliche Seiten?
• Ist diese Zusammenfassung noch aktuell?
• Hat der Agent mehr neu geschrieben, als er sollte?
• Können wir eine schlechte Aktualisierung zurückrollen?
• Kann ein Mensch verstehen, warum die Seite das sagt, was sie sagt?

Wenn die Antwort nein lautet, liegt das Problem nicht nur in der Inhaltsqualität. Es liegt im Systemdesign.

Ein einfacher Wartungszyklus

Ein nützliches LLM-Wiki benötigt einen wiederholbaren Zyklus. Der Zyklus sollte einfach genug sein, um häufig ausgeführt zu werden, und streng genug, um Drift zu erkennen, bevor er unsichtbar wird.

Dieser Zyklus ist nicht glamourös. Das ist der Punkt.

Ein Wissenssystem wird durch langweilige Wartung dauerhaft: Quellenerhaltung, explizite Überprüfung, vorhersehbare Struktur und kleine, sichere Updates. Dieselbe Intuition treibt Evergreen Notes: Eine Notiz oder eine Wiki-Seite sammelt nur Wert, wenn jemand sie ständig verfeinert, anstatt sie nach dem ersten Entwurf verrotten zu lassen.

Arten von Drift in einem LLM-Wiki

Wissensdrift ist keine einzelne Sache. Verschiedene Drift-Arten erfordern verschiedene Checks. Ein gutes Wartungssystem sollte sie klar benennen.

Quelldrift

Quelldrift tritt auf, wenn sich das zugrunde liegende Quellmaterial ändert.

Zum Beispiel veröffentlicht ein Tool eine neue Version, eine Richtlinie wird aktualisiert, eine API ändert sich oder ein Anbieter stuft eine alte Funktion als veraltet ein. Die alte Wiki-Seite kann für die vorherige Version noch korrekt sein, aber für die aktuelle Nutzung falsch.

Quelldrift ist gefährlich, weil die alte Behauptung im historischen Kontext noch wahr sein kann. Das Problem ist nicht, dass die Behauptung falsch ist. Das Problem ist, dass sie die aktuelle Frage nicht mehr beantwortet.

Wartungsantwort:

• Quelltatsachen dokumentieren
• Letzte Überprüfungsdaten dokumentieren
• Versionsbezogene Seiten klar kennzeichnen
• Alte Seiten mit Links zu ablösenden Seiten verbinden
• Vermeiden Sie das Mischen alter und neuer Versionen ohne Kennzeichnungen

Konzeptdrift

Konzeptdrift tritt auf, wenn sich die Bedeutung eines Begriffs im Laufe der Zeit ändert.

Dies ist in KI und Softwarearchitektur üblich. Begriffe wie „Agent“, „Speicher“ (Memory), „RAG“, „Workflow“, „Tool-Nutzung“, „strukturierte Ausgabe“ und „Kontext-Engineering“ können ihre Bedeutung schnell ändern.

Ein Wiki kann versehentlich mehrere Bedeutungen desselben Begriffs bewahren, ohne den Unterschied zu erklären. Das schafft verwirrende Seiten, die kohärent klingen, aber inkompatible Ideen kombinieren.

Wartungsantwort:

• Glossar-Seiten pflegen
• Abschnitte „Bedeutung in diesem Wiki“ hinzufügen
• Überladene Konzepte in separate Seiten aufteilen
• Verwandte Bedeutungen explizit verlinken
• Vermeiden Sie, dass das Modell Begriffe stillschweigend verschmilzt

Terminologiedrift

Terminologiedrift ist kleiner als Konzeptdrift, aber dennoch schädlich.

Sie tritt auf, wenn das Wiki mehrere Namen für dieselbe Sache verwendet: „LLM-Wiki“, „kompilierte Wissensdatenbank“, „KI-gewartetes Wiki“, „Agent-gewartetes Wiki“ und „Markdown-Wissensdatenbank“.

Einige Variation ist in Ordnung. Zu viel Variation bricht Suche, Verlinkung und Überprüfung.

Wartungsantwort:

• Kanonische Seitennamen definieren
• Aliase im Frontmatter oder in Seitendaten halten
• Duplizierte Seiten umleiten
• Lint für fast doppelte Titel
• Konsistenten Anchor-Text in internen Links verwenden

Entscheidungsdrift

Entscheidungsdrift tritt auf, wenn eine vergangene Entscheidung dokumentiert bleibt, aber die aktuelle Praxis nicht mehr widerspiegelt.

Zum Beispiel könnte eine Seite sagen, dass das Projekt Vektor-RAG für die gesamte Dokumentensuche verwendet, während neuere Seiten einen LLM-Wiki-Workflow beschreiben. Beide Aussagen können historisch wahr sein, aber das Wiki muss zeigen, welche aktuell ist.

Das ist wichtig für Architekturhinweise, Ingenieursprozesse, Content-Strategie und internes Tooling. Dieselbe Disziplin gilt für Entscheidungsprotokolle in der KI-gesteuerten Entwicklung: Eine Entscheidungsseite ist nur vertrauenswürdig, wenn abgelöste Optionen als abgelöst markiert sind, anstatt stillschweigend überschrieben zu werden.

Wartungsantwort:

• Entscheidungen als vorgeschlagen, akzeptiert, abgelöst oder abgelehnt markieren
• Entscheidungsdaten aufbewahren
• Ablöste Entscheidungen mit Links zu Ersatzseiten verbinden
• Historischen Kontext bewahren
• Vermeiden Sie das Löschen alter Entscheidungen ohne Spur

Zitiersdrift

Zitiersdrift tritt auf, wenn eine Seite eine Quelle zitiert, die Behauptung aber nicht mehr mit dem übereinstimmt, was die Quelle sagt.

Das kann nach einer Überarbeitung passieren. Das Zitat bleibt an Ort und Stelle, aber der Satz darum herum ändert sich. Die Seite sieht immer noch als belegt aus, doch das Zitat stützt die Behauptung nicht mehr.

Dies ist einer der ernststen Fehlermodi eines LLM-Wikis, da er falsches Vertrauen schafft.

Wartungsantwort:

• Zitiersstützung auf Behauptungsebene überprüfen
• Vermeiden Sie das Zitieren nur von Zusammenfassungen
• Rohe Quellen aufbewahren
• Zitate für wichtige Behauptungen verlangen
• Absätze mit Quellen, aber ohne direkte Unterstützung kennzeichnen
• Zitiervariationen in Git-Diffs überprüfen

Strukturdrift

Strukturdrift tritt auf, wenn das Wiki langsam die Navigierbarkeit verliert.

Neue Seiten werden erstellt, anstatt alte zu aktualisieren. Indexseiten fallen hinterher. Duplizierte Seiten erscheinen. Waisenseiten (Orphan Pages) sammeln sich an. Verwandte Seiten verlinken nicht mehr miteinander.

Das Wiki enthält immer noch nützliches Wissen, aber das Finden und Vertrauen darin wird schwieriger.

Wartungsantwort:

• Lint für Waisenseiten
• Indexseiten pflegen
• Duplizierte Themen erkennen
• Backlinks für kanonische Seiten verlangen
• Archivieren statt zerstreuen
• Klare Ordnerrollen behalten

Die Kern-Wartungsdateien

Ein LLM-Wiki sollte sich nicht auf Gedächtnis, Vibes oder wiederholtes Prompting verlassen. Es benötigt Betriebsdateien, die Menschen und Agenten mitteilen, wie es gewartet werden soll.

Eine praktische Struktur könnte so aussehen:

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

Die genauen Namen sind nicht wichtig. Die Rollen sind es.

Das Wiki benötigt Quellenspeicher, kompilierte Seiten, Review-Artefakte und Regeln, die über Sessions hinweg überdauern.

AGENTS.md

AGENTS.md sollte erklären, wie der Agent arbeiten darf.

Es sollte Fragen beantworten wie:

• Sollte der Agent bestehende Seiten aktualisieren, bevor er neue erstellt?
• Wann sollte er nach Überprüfung fragen?
• Wie sollte er Quellen zitieren?
• Kann er Ordner neu organisieren?
• Kann er alte Seiten neu schreiben?
• Was sollte er mit Widersprüchen tun?
• Was sollte er nie löschen?

Eine nützliche Regel ist:

Bevorzugen Sie kleine, quellengestützte Updates gegenüber breiten Überarbeitungen.

Dieser eine Satz verhindert viele schlechte Wartungsgewohnheiten. Er zieht auch eine nützliche Grenze im Verhältnis zu Agent-Speicher: Speicher formt, wie ein Agent im Moment handelt, während die Regeldatei des Wikis formt, was der Agent in der gemeinsamen Wissensdatenbank ändern darf.

schema.md

schema.md sollte die Seitenstruktur definieren.

Zum Beispiel:

# Seitentitel

## Zusammenfassung
Kurze aktuelle Zusammenfassung.

## Wichtige Behauptungen
- Behauptung mit Quellenverweis.
- Behauptung mit Quellenverweis.

## Aktueller Status
Aktuell, historisch, abgelöst, Entwurf oder unsicher.

## Details
Hauptkompilierte Erklärung.

## Verwandte Seiten
Interne Links.

## Quellen
Rohe Quellenverweise.

## Review-Notizen
Letztes Überprüfungsdatum und Reviewer.

Ein Schema muss nicht starr sein. Aber ohne ein Schema wird das Wiki zu einem Haufen inkonsistenter Essays. Das Schema gibt dem Agenten etwas, das es bewahren kann.

citation-policy.md

Die Zitierpolitik sollte sagen, was eine Quelle benötigt. Verlangen Sie mindestens Zitate für:

• Technische Behauptungen
• Vergleiche
• Produktverhalten
• Versionsbezogene Aussagen
• Benchmark-Ergebnisse
• Preise
• Rechtliche oder Compliance-Behauptungen
• Behauptungen zum aktuellen Status
• Behauptungen, die aus einer Quelle kopiert oder abgeleitet wurden

Eine gute Zitierpolitik sagt auch, was man nicht tun soll. Zitieren Sie keine kompilierte Seite, als wäre sie die ursprüngliche Quelle. Fügen Sie keine Zitate an Absätze an, die sie nicht stützen. Behalten Sie kein Zitat nach dem Neuerschreiben einer Behauptung bei, es sei denn, die Quelle stützt sie immer noch.

Zitiersdisziplin ist der Unterschied zwischen einem nützlichen LLM-Wiki und dekorativem Selbstvertrauen.

source-policy.md

Die Quellenpolitik sollte definieren, wie rohe Quellen gespeichert werden.

Zum Beispiel:

• Originaldateien wann immer möglich aufbewahren
• URLs und Zugriffsdaten bewahren
• Kopierte Notizen separat von generierten Zusammenfassungen speichern
• Quellentyp dokumentieren
• Quellen mit niedriger Zuverlässigkeit kennzeichnen
• Vermeiden Sie das Überschreiben von Rohmaterial
• Bewahren Sie abgelöste Quellen auf, wenn sie historische Entscheidungen erklären

Diese Politik schützt das Wiki vor einem häufigen Fehler: Eine Quelle zusammenfassen, das Original verwerfen und die Zusammenfassung dann als Beweis behandeln.

Das ist kein Wissensmanagement. Das ist verlustbehaftete Komprimierung.

Was ein LLM-Wiki-Linter überprüfen sollte

Ein Linter sollte zuerst die Struktur überprüfen. Strukturelle Probleme sind einfacher zu automatisieren und decken oft tiefere semantische Probleme auf.

Nützliche strukturelle Checks umfassen:

• Gebrochene interne Links
• Waisenseiten
• Duplizierte Titel
• Fehlende Quellensektionen
• Fehlende Überprüfungsdaten
• Seiten ohne Backlinks
• Leere oder Platzhalter-Sektionen
• Sehr lange Seiten ohne Sektionsstruktur
• Seiten ohne eingehende Links von einem Index
• Inkonsistente Namenskonventionen
• Ungültiges Frontmatter
• Veraltete „aktuelle“ Seiten, die älter als eine Überprüfungsschwelle sind

Diese Checks beweisen nicht, dass das Wissen wahr ist. Sie beweisen, dass das Wiki noch wartbar ist. Das ist ein notwendiger Ausgangspunkt.

Semantische Checks

Semantische Checks sind schwieriger, aber wertvoller.

Nützliche semantische Checks umfassen:

• Behauptungen ohne direkte Quellenstützung
• Zwei Seiten, die inkompatible Behauptungen aufstellen
• Alte Entscheidungen, die als aktuell dargestellt werden
• Duplizierte Konzepte mit unterschiedlichen Namen
• Eine Konzeptionseite, die mehrere Bedeutungen mischt
• Zusammenfassungen, die bekannte Einschränkungen auslassen
• „Beste“ oder „empfohlene“ Behauptungen ohne Kriterien
• Versionsbezogene Behauptungen ohne Versionskennzeichnungen
• Seiten, die neueren Quellen widersprechen

Diese Checks sollten das Wiki nicht automatisch neu schreiben. Sie sollten normalerweise einen Bericht zur Überprüfung erzeugen.

Das sicherere Muster ist:

Automatisch erkennen.
Klar erklären.
Gezielt aktualisieren.
Riskante Änderungen überprüfen.

Widerspruchserkennung

Widerspruchserkennung bedeutet nicht nur, einen LLM zu fragen, ob zwei Seiten widersprüchlich sind.

Das kann helfen, ist aber zu vage. Ein besserer Ansatz ist der Vergleich von Behauptungen.

Ein Widerspruchs-Workflow könnte so aussehen:

Das funktioniert besser, weil viele scheinbare Widersprüche keine echten Widersprüche sind.

Eine Seite kann Version 1.0 beschreiben, eine andere Version 2.0. Eine Seite kann den persönlichen Gebrauch beschreiben, eine andere den Enterprise-Einsatz. Eine Seite kann das Designziel beschreiben, eine andere die Implementierungswirklichkeit.

Der Widerspruchsbericht sollte enthalten:

• Widersprüchliche Behauptungen
• Beteiligte Seiten
• Quellenverweise
• Datums- oder Versionskontext
• Wahrscheinliche Erklärung
• Vorgeschlagene Auflösung
• Ob eine manuelle Überprüfung erforderlich ist

Lassen Sie den Agenten Widersprüche nicht stillschweigend auflösen, indem er beide Behauptungen in einen vagen Kompromiss verschmilzt. Das erzeugt glattes Unsinn.

Wie man Widersprüche auflöst

Es gibt mehrere gültige Möglichkeiten, einen Widerspruch aufzulösen.

• Wenn eine Behauptung veraltet ist, markieren Sie sie als abgelöst und verlinken Sie auf die neuere Seite.
• Wenn beide Behauptungen in unterschiedlichen Kontexten wahr sind, trennen Sie den Kontext klar.
• Wenn die Quellen uneins sind, bewahren Sie die Uneinigkeit auf und erklären Sie sie.
• Wenn die Wiki-Seite eine Behauptung erfunden oder übergeneralisiert hat, entfernen oder verengen Sie die Behauptung.
• Wenn der Widerspruch eine echte, ungelöste Entscheidung widerspiegelt, erstellen oder aktualisieren Sie eine Entscheidungsseite.

Das Ziel ist nicht, alle Spannung zu entfernen. Einige Spannung ist nützlich. Ein gutes Wiki zeigt, wo Wissen geklärt ist und wo es immer noch unsicher ist.

Überprüfung veralteter Seiten

Jede kompilierte Seite sollte einen Überprüfungsstatus haben.

Ein einfacher Metadatenblock kann ausreichen:

status: current
last_reviewed: 10.07.2026
review_after: 10.10.2026
source_confidence: medium

Verwenden Sie für schnelllebige Themen kurze Überprüfungszeiträume. Für stabile Konzepte verwenden Sie längere Zeiträume.

Das Intervall ist weniger wichtig als die Gewohnheit. Eine Seite ohne Überprüfungsdatum ist eine Seite, die mit der Zeit stillschweigend lügen wird.

Quellbewusste Updates

Wenn eine neue Quelle eintrifft, sollte der Agent nicht einfach eine neue Zusammenfassungsseite schreiben.

Er sollte fragen:

• Aktualisiert dies ein bestehendes Konzept?
• Ersetzt es eine vorherige Quelle?
• Widerspricht es einer bestehenden Seite?
• Fügt es eine neue Entität oder einen neuen Begriff hinzu?
• Ändert es eine Empfehlung?
• Erfordert es eine Indexaktualisierung?
• Beeinflusst es Entscheidungsseiten?

Ein guter Ingest-Workflow aktualisiert das Wiki als Graphen, nicht als Stapel isolierter Zusammenfassungen.

Deshalb kann eine Quelle viele Seiten berühren. Das ist normal. Die Wartungsherausforderung besteht darin, diese Updates klein, überprüfbar und nachverfolgbar zu machen.

Review mit Git-Diffs

Git ist eines der besten Wartungswerkzeuge für ein LLM-Wiki.

Nicht, weil Git modisch ist, sondern weil generiertes Wissen eine überprüfbare Änderungshistorie benötigt. Ein Git-Diff zeigt, was der Agent geändert, gelöscht, verschoben oder umformuliert hat.

Verwenden Sie Git zur Überprüfung von:

• Neuen Seiten
• Gelöschten Sektionen
• Geänderten Behauptungen
• Geänderten Zitaten
• Umbenannten Seiten
• Indexaktualisierungen
• Linkänderungen
• Statusänderungen
• Breiten Überarbeitungen

Das wichtigste Review-Gewohnheitsmuster ist die Überprüfung von Löschungen. LLMs entfernen oft Details, während sie den Text glätten.

Glatter Text ist nicht immer besseres Wissen.

Sichere Commit-Strategie

Vermeiden Sie riesige Commits wie:

Wiki aktualisieren

Verwenden Sie Commits, die die Operation erklären:

ingest: Quellnotizen für Qwen-Embedding-Release hinzufügen
maint: Alten Vektorspeicher-Vergleich als abgelöst markieren
lint: Gebrochene interne Links in RAG-Seiten reparieren
review: Zitate in LLM-Wiki-Seiten aktualisieren
refactor: Agent-Speicher-Konzept von Langzeitspeicher trennen

Dies gibt zukünftigen Menschen und Agenten eine nützliche Historie.

Commit-Nachrichten sind Teil des Wissenssystems. Sie erklären, warum sich das Wiki geändert hat.

Review-Ebenen

Nicht jede Seite benötigt dieselbe Review-Ebene. Verwenden Sie risikobasierte Review.

Niedriges Risiko:

• Reparatur gebrochener Links
• Formatierungsaufräumung
• Hinzufügen von Backlinks
• Hinzufügen von Indexeinträgen
• Korrigieren von Tippfehlern
• Hinzufügen von Aliases

Mittleres Risiko:

• Hinzufügen von Quellenzusammenfassungen
• Erstellen neuer Konzeptionseiten
• Aktualisieren von Empfehlungen
• Zusammenführen duplizierter Seiten
• Ändern des Seitenstatus

Hohes Risiko:

• Löschen von Behauptungen
• Neuerschreiben kanonischer Seiten
• Ändern von Entscheidungsprotokollen
• Aktualisieren von Sicherheits-, Rechts-, Preis- oder Benchmark-Behauptungen
• Auflösen von Widersprüchen
• Markieren von Inhalten als aktuell oder abgelöst

Änderungen mit hohem Risiko sollten eine manuelle Überprüfung erhalten. Das können Sie, ein Maintainer oder ein Domänenverantwortlicher sein.

Der Agent kann die Änderung vorbereiten, sollte aber nicht immer die letzte Autorität sein.

Ein Wartungs-Dashboard

Ein einfaches Wartungs-Dashboard kann in Markdown leben.

Beispiel:

# LLM-Wiki-Wartungs-Dashboard

## Benötigt Überprüfung
- wiki/concepts/agent-memory.md - Überprüfung überfällig
- wiki/projects/search-index.md - Widersprüchliche Behauptungen gefunden

## Veraltete Seiten
- wiki/tools/ollama.md - Letztmalig vor 120 Tagen überprüft
- wiki/concepts/rag.md - Schnelllebiges Thema, Überprüfung fällig

## Gebrochene Links
- wiki/index.md -> wiki/concepts/old-page.md

## Waisenseiten
- wiki/entities/vendor-x.md

## Widerspruchsberichte
- reports/contradictions/2026-07-10-agent-memory.md

## Kürzlich eingelesene Quellen
- raw/sources/2026-07-09-new-paper.md

Das ist kein fancy Admin-Panel. Es ist eine Arbeitsfläche.

Für viele Solo- oder Small-Team-Systeme reicht ein Markdown-Dashboard aus.

Metriken für ein gesundes LLM-Wiki

Sie können die Wiki-Gesundheit verfolgen, ohne sie zu überingenieurieren.

Nützliche Metriken umfassen:

• Anzahl der Seiten
• Seiten ohne Quellen
• Seiten ohne Überprüfungsdaten
• Seiten, die das Überprüfungsdatum überschritten haben
• Gebrochene interne Links
• Waisenseiten
• Duplizierte Titel oder Aliases
• Offene Widerspruchsberichte
• Geschlossene Widerspruchsberichte
• Durchschnittliches Seitenalter nach Cluster
• Noch nicht eingelesene Rohe Quellen
• Seiten, die ohne menschliche Überprüfung geändert wurden
• Kanonische Seiten, die in den letzten 30 Tagen geändert wurden

Diese Metriken sind keine Vanitätszahlen. Sie sagen Ihnen, ob das System einfacher oder schwerer zu vertrauen wird.

Ein wachsendes Wiki mit steigenden Waisenseiten und veralteten Überprüfungen sammelt kein Wissen an. Es sammelt Wartungsschulden an.

Wartungs-Prompts

Wartungs-Prompts sollten eng sein. Breite Prompts erzeugen breite Überarbeitungen.

Struktureller Lint-Prompt

Überprüfen Sie die Wiki-Struktur.

Prüfen Sie auf:
- gebrochene interne Links
- Waisenseiten
- duplizierte oder fast duplizierte Seitentitel
- Seiten mit fehlenden Quellensektionen
- Seiten mit fehlendem last_reviewed-Metadatum
- Indexseiten, die nicht auf neue Seiten verlinken

Schreiben Sie den Inhalt nicht neu.
Erzeugen Sie einen Markdown-Bericht mit Befunden und vorgeschlagenen Reparaturen.

Zitiers-Review-Prompt

Überprüfen Sie die Zitate für die ausgewählte Seite.

Für jede wichtige Behauptung:
- Identifizieren Sie die stützende Quelle
- Prüfen Sie, ob die Quelle die Behauptung direkt stützt
- Kennzeichnen Sie Behauptungen mit schwacher, fehlender oder nicht passender Unterstützung
- Schreiben Sie die Seite noch nicht neu

Geben Sie eine Tabelle zurück mit:
Behauptung, aktuelles Zitat, Unterstützungslevel, Problem, vorgeschlagene Aktion.

Widerspruchs-Check-Prompt

Prüfen Sie diese Seite auf Widersprüche gegenüber verwandten Seiten.

Schritte:
1. Extrahieren Sie die Hauptbehauptungen von der Seite.
2. Finden Sie verwandte Seiten durch Links, Backlinks, Aliases und Suche.
3. Extrahieren Sie potenziell widersprüchliche Behauptungen.
4. Klassifizieren Sie jeden Konflikt als:
   - echten Widerspruch
   - Versionsunterschied
   - Umfangsunterschied
   - Terminologieunterschied
   - ungelöste Unsicherheit
5. Empfehlen Sie eine Auflösung.

Bearbeiten Sie keine Dateien, bis der Widerspruchsbericht überprüft wurde.

Prompt zur Überprüfung veralteter Seiten

Überprüfen Sie diese Seite auf Verfall.

Prüfen Sie:
- Daten
- versionsbezogene Behauptungen
- Tool-Verhalten
- Empfehlungen
- Links zu abgelösten Seiten
- Quellen, die neuer sind als das Seiten-Überprüfungsdatum
- Behauptungen, die als aktuell markiert sind, ohne aktuelle Unterstützung

Geben Sie zurück:
- als aktuell behalten
- Aktualisierung erforderlich
- als historisch markieren
- als abgelöst markieren
- in versionsierte Seiten aufteilen

Sicheres Update-Prompt

Aktualisieren Sie die ausgewählte Wiki-Seite unter Verwendung der bereitgestellten Quelle.

Regeln:
- Bewahren Sie bestehende nützliche Struktur auf
- Entfernen Sie quellengestützte Behauptungen nicht, es sei denn, die Quelle ist abgelöst
- Fügen Sie Zitate für neue Behauptungen hinzu
- Kennzeichnen Sie Unsicherheit explizit
- Aktualisieren Sie verwandte Seiten nur, wenn notwendig
- Fügen Sie eine Review-Notiz hinzu, die erklärt, was sich geändert hat
- Halten Sie den Diff klein

Diese Prompts sind keine Magie. Sie sind Geländer. Der echte Wert kommt davon, die Wartungsaktion explizit zu machen.

Häufige Wartungsfehler

Der erste Fehler ist, den Agenten zu viel neu schreiben zu lassen.

Große Überarbeitungen fühlen sich produktiv an, weil sie Seiten glätten. Sie machen es auch schwieriger zu sehen, was sich geändert hat, und einfacher, scharfe Details zu verlieren.

Der zweite Fehler ist die Behandlung generierter Zusammenfassungen als Quellen.

Eine Zusammenfassung kann nützlich sein, ist aber nicht der Beweis. Bewahren Sie Rohe Quellen auf und zitieren Sie sie, wenn Behauptungen wichtig sind.

Der dritte Fehler ist das Erstellen neuer Seiten anstatt das Aktualisieren alter.

Dies produziert duplizierte Konzepte, widersprüchliche Empfehlungen und Suchverwirrung. Der Agent sollte zuerst suchen, zweitens aktualisieren und neue Seiten nur erstellen, wenn das Konzept wirklich neu ist.

Der vierte Fehler ist das Löschen von historischem Kontext.

Alte Entscheidungen, gescheiterte Experimente und abgelöste Empfehlungen können wertvoll sein. Kennzeichnen Sie sie klar, anstatt sie zu löschen.

Der fünfte Fehler ist das Vergessen der Indizes.

Eine Seite, die nicht vom richtigen Ort verlinkt ist, ist halb verloren. Indexwartung ist keine Bürokratie. Es ist Navigationsarchitektur.

Der sechste Fehler ist die Verwendung derselben Review-Politik für jede Seite.

Eine stabile Konzeptionseite und ein schnelllebiger Tool-Vergleich sollten nicht denselben Überprüfungsplan haben.

Archivieren, Ablösen oder Löschen

Die meisten veralteten Seiten sollten nicht sofort gelöscht werden.

Eine abgelöste Seite sollte auf den Ersatz verlinken.

Zum Beispiel:

Status: abgelöst
Ablöst durch: wiki/concepts/agent-memory-architecture.md
Grund: Diese Seite verwendete eine ältere Definition von Agent-Speicher, bevor das Projekt Session-Speicher, User-Speicher und kompiliertes Wissen trennte.

Dies bewahrt den Kontext und reduziert Verwirrung.

Löschen sollte selten und überprüfbar sein. Wissenssysteme brauchen Beschneiden, aber unsichtbare Beschneiden sind gefährlich.

Kanonische Seiten benötigen besondere Sorgfalt

Jedes LLM-Wiki entwickelt schließlich kanonische Seiten.

Das sind Seiten, die Kernkonzepte, Architekturentscheidungen, Workflows oder Projektvokabular definieren. Sie sind wichtiger als gewöhnliche Notizen, weil viele andere Seiten von ihnen abhängen.

Beispiele:

• Was ist LLM-Wiki
• RAG vs. kompiliertes Wissen
• Agent-Speicher
• Quellenpolitik
• Review-Workflow
• Projektarchitektur
• Glossar
• Index

Änderungen an kanonischen Seiten sollten strengere Review erfordern.

Ein kleiner Fehler auf einer obskuren Seite ist lokal. Ein kleiner Fehler auf einer kanonischen Seite kann das gesamte Wiki verzerren.

Wie oft sollten Sie Wartung ausführen

Für ein aktives LLM-Wiki führen Sie kleine Wartungen häufig und tiefe Wartungen gelegentlich aus.

Der Plan sollte dem Risiko entsprechen. Ein persönliches Forschungs-Wiki kann lockerer sein. Ein Wiki, das für technische Veröffentlichungen, Kunden Support oder Ingenieursentscheidungen verwendet wird, benötigt mehr Disziplin.

Verwendung eines LLM-Wikis für technische Veröffentlichungen

Für einen technischen Blog oder eine Dokumentationsseite kann das LLM-Wiki die Wissensschicht hinter der Artikelplanung werden.

Es kann verfolgen:

• Kanonische Erklärungen
• Wiederholte Definitionen
• Möglichkeiten für interne Links
• Veraltete Vergleiche
• Artikel-Lücken
• Themen-Cluster
• Quellennotizen
• Entscheidungen zur Struktur
• Behauptungen, die Verifizierung benötigen

Das ist nützlich, aber es erhöht die Wartungshürde.

Wenn das Wiki veröffentlichte Artikel speist, können veraltete Wiki-Seiten zu veralteten öffentlichen Inhalten werden. Wenn das Wiki Widersprüche enthält, können diese Widersprüche in Artikel lecken. Wenn Zitate schwach sind, werden generierte Entwürfe diese Schwäche erben. Die im Artikel KI für Wissensmanagement: Echte Workflows, die standhalten beschriebenen scoped Zusammenfassungen, schema-basierte Extraktion und menschliche Review-Schleifen sind eine gute Vorlage, um diese redaktionelle Pipeline ehrlich zu halten.

Behandeln Sie das LLM-Wiki für Veröffentlichungsworkflows als Redaktionssystem, nicht nur als privates Notizbuch. Ein Digitaler Garten macht dies explizit, indem er Lesern zeigt, welche Seiten noch wachsen und welche reif sind, was genau die Art von Statussignal ist, das ein gut gewartetes LLM-Wiki auch aussetzen sollte.

Wartung ist keine Option

Ein LLM-Wiki ist attraktiv, weil es sich nach anwachsendem Wissen anhört.

Aber Anwachsen funktioniert nur, wenn altes Wissen nützlich bleibt. Andernfalls sammelt das System Rauschen an, nicht Einsicht.

Die Wartungsbelastung verschwindet nicht, weil ein Agent beteiligt ist. Sie ändert ihre Form.

Menschen müssen nicht jede langweilige Aufgabe erledigen. Agenten können Links überprüfen, veraltete Seiten finden, Behauptungen vergleichen, Berichte entwerfen und Updates vorschlagen. Aber Menschen müssen immer noch Politik setzen, riskante Änderungen überprüfen und entscheiden, was das Wiki bedeuten darf.

Das ist der echte Deal.

Fazit

LLM-Wiki-Wartung geht darum, kompiliertes Wissen ehrlich zu halten.

Die wichtigen Praktiken sind nicht kompliziert: Quellen bewahren, Behauptungen zitieren, Indizes aktuell halten, Widersprüche erkennen, Git-Diffs überprüfen, veraltete Seiten markieren und breite, nicht überprüfte Überarbeitungen vermeiden.

Ein gutes LLM-Wiki gibt nicht vor, magisch selbstdurchkorrigierend zu sein. Es macht Korrektur einfacher.

Das ist der Standard, auf den man zielen sollte: nicht perfektes Wissen, sondern überprüfbares Wissen, das im Laufe der Zeit überprüft, repariert und vertraut werden kann.