PKM vs. RAG vs. Wiki vs. Memory-Systeme klar erklärt

PKM, RAG, Wikis, KI-Speichersysteme und nun praktische, KI-gestützte Workflows werden oft so diskutiert, als lösten sie dasselbe Problem. Das tun sie nicht. Sie alle befassen sich mit Wissen, arbeiten aber auf unterschiedlichen Ebenen:

• PKM hilft Menschen beim Denken.
• Wikis helfen Gruppen, gemeinsames Wissen zu bewahren.
• RAG hilft Maschinen, externes Wissen abzurufen.
• Speichersysteme helfen KI-Agenten, Kontext über die Zeit hinweg persistenzfähig zu machen.

Diese Systeme zu vermischen führt zu schlechter Architektur.

Man erhält Wikis voller persönlicher Notizen, RAG-Systeme ohne eine einzige Wahrheit, Schichtenspeicher, die sich als Datenbanken tarnen, und PKM-Tools, die mit Automatisierungen überladen sind, für die sie nie entworfen wurden.

Ein besseres Modell ist es, sie als verschiedene Teile eines Spektrums von Wissenssystemen zu betrachten.

Dieser Artikel vergleicht PKM, RAG, Wikis und KI-Speichersysteme nach Struktur, Abruf, Eigentümerschaft, Evolution und realen Anwendungsfällen. Wenn Sie sehen möchten, wie diese Abstraktionen bei der konkreten täglichen Notizenerfassung, Dokumentation und Wartung von Runbooks aussehen, führt das Begleitstück KI für das Wissensmanagement: Echte Workflows, die standhalten durch Zusammenfassungs-, Extraktions- und Verknüpfungspipelines, die auf PKM- und Wiki-Grundlagen aufbauen, anstatt sie zu ersetzen.

Die Kurzversion

System	Primärer Nutzer	Hauptzweck	Am besten für
PKM	Einzelperson	Entwicklung persönlichen Wissens	Denken, Lernen, Synthese
Wiki	Team oder öffentliche Gruppe	Pflege gemeinsamen Wissens	Dokumentation, Richtlinien, Referenz
RAG	Maschinensystem	Abruf von Kontext für die Generierung	KI-Antworten über externe Daten
KI-Speicher	KI-Agent	Persistenz von Kontext über Zeit	Lang laufende Agenten und Personalisierung

Die wichtigste Unterscheidung ist diese:

PKM und Wikis strukturieren Wissen. RAG ruft Wissen ab. Speichersysteme entwickeln den Agentenkontext weiter.

Das ist das grundlegende mentale Modell.

Warum diese Systeme verwechselt werden

Sie überschneiden sich in ihrem sichtbaren Verhalten.

Alle können:

• Notizen speichern
• Informationen abrufen
• Fragen beantworten
• Referenzen organisieren
• Ideen verbinden

Aber sie unterscheiden sich in ihrer Absicht.

Ein PKM-System ist nicht nur ein privater Wiki. Ein Wiki ist nicht nur eine RAG-Datenbank. Eine RAG-Pipeline ist kein KI-Speicher. Ein KI-Speichersystem ist kein Ersatz für strukturierte Dokumentation.

Die Verwirrung entsteht daraus, dass „Wissen“ als eine einzige Sache behandelt wird.

In der Praxis hat Wissen mehrere Schichten:

1. Erfassung
2. Strukturierung
3. Abruf
4. Interpretation
5. Wiederverwendung
6. Evolution

Unterschiedliche Systeme optimieren unterschiedliche Stufen.

Die vier Paradigmen

1. PKM

PKM steht für Personal Knowledge Management (persönliches Wissensmanagement).

Es ist die Praxis des Erfassens, Organisierens, Verknüpfens und Nutzens von Wissen für die persönliche Arbeit.

Typische PKM-Systeme umfassen:

• Obsidian
• Logseq
• Notion
• reine Markdown-Ordner
• Zettelkasten-Systeme
• Second-Brain-Systeme (zweites Gehirn)

PKM ist menschlich gesteuert.

Das Ziel ist nicht nur Speicherung. Das Ziel ist besseres Denken.

Wofür PKM gut ist

PKM funktioniert gut für:

• das Erlernen eines neuen Fachgebiets
• die Entwicklung origineller Ideen
• das Verknüpfen von Notizen über die Zeit
• das Schreiben von Artikeln oder Büchern
• das Tracking persönlicher Forschung
• den Aufbau eines zweiten Gehirns

Ein gutes PKM-System ist auf nützliche Weise unordentlich. Es unterstützt unvollständige Gedanken, partielle Ideen, privaten Kontext und sich entwickelnde Konzepte.

Deshalb ist PKM nicht dasselbe wie Dokumentation.

Dokumentation möchte Klarheit. PKM toleriert Ambiguität.

PKM-Ausfallmodi

PKM schlägt oft fehl, wenn es zu Folgendem wird:

• einer Ablage für alles Mögliche
• einem Projekt zur Ordner-Taxonomie
• einer Produktivitätsästhetik
• einem Hobby zur Tool-Optimierung
• einem privaten Archiv, das niemand nutzt

Das Hauptrisiko ist Sammlung ohne Synthese.

Wenn Sie nur Informationen speichern, haben Sie kein Wissenssystem. Sie haben eine persönliche Deponie.

Meinungsgeprägte Ansicht

PKM sollte auf Wiederverwendung, nicht auf Erfassung optimieren.

Alles zu erfassen fühlt sich produktiv an, erzeugt aber Schulden. Der echte Wert entsteht, wenn Notizen verknüpft, umgeschrieben, komprimiert und in der Ausgabe verwendet werden.

2. Wiki

Ein Wiki ist eine strukturierte Wissensdatenbank, die für gemeinsame Referenz entwickelt wurde.

Typische Wiki-Systeme umfassen:

• DokuWiki
• MediaWiki
• Confluence
• BookStack
• Git-basierte Dokumentationsseiten
• interne Unternehmens-Wissensdatenbanken

Ein Wiki ist normalerweise formeller als PKM.

Es sollte beantworten:

Was wissen wir, und wo ist die aktuelle Version?

Wofür Wikis gut sind

Wikis funktionieren gut für:

• Teamdokumentation
• operative Runbooks
• Produktwissen
• Richtlinien-Dokumente
• technische Referenz
• Onboarding-Material
• stabiles Domänenwissen

Ein Wiki ist ein sozialer Vertrag.

Es sagt:

Diese Seite ist der Ort, an dem dieses Wissen lebt.

Das macht Eigentümerschaft und Wartung kritisch.

Wiki-Ausfallmodi

Wikis schlagen oft fehl, weil sie veralten.

Häufige Probleme:

• keine Seiteneigentümer
• veraltete Screenshots
• doppelte Seiten
• unklare kanonische Versionen
• zu viel Hierarchie
• kein Wartungsrhythmus

Ein Wiki mit alten Informationen ist schlimmer als kein Wiki, weil es falsches Vertrauen schafft.

Meinungsgeprägte Ansicht

Ein Wiki sollte langweilig sein.

Das ist ein Kompliment.

Ein gutes Wiki ist nicht der Ort, an dem Ideen geboren werden. Es ist der Ort, an dem stabiles Wissen bewahrt wird, nachdem es für andere nützlich geworden ist.

3. RAG

RAG steht für Retrieval Augmented Generation (abrufgestützte Generierung).

Es ist eine KI-Architektur, bei der ein System relevante externe Informationen abruft, bevor es ein Sprachmodell bittet, eine Antwort zu generieren.

Eine grundlegende RAG-Pipeline hat normalerweise:

1. Dokumente
2. Chunking (Zerteilung)
3. Embeddings oder Suchindex
4. Abruf
5. Optionales Neurangieren (Reranking)
6. Prompt-Zusammenstellung
7. LLM-Generierung

RAG ist maschinell gesteuert.

Das Ziel ist nicht, Wissen zu schaffen. Das Ziel ist, einem Modell zum Abfragezeitpunkt relevanten Kontext zu geben.

Wofür RAG gut ist

RAG funktioniert gut für:

• Frage-und-Antwort-Systeme über Dokumenten
• interne Suchassistenten
• Support-Bots
• technische Dokumentationsassistenten
• Compliance-Lookup
• Forschung über große Korpora
• das Verbinden von LLMs mit aktualisierten Informationen

RAG ist besonders nützlich, wenn das Modell die Informationen nicht oder nicht sollte merken.

RAG-Ausfallmodi

RAG schlägt oft fehl, wenn Teams es als magische Suche behandeln.

Häufige Probleme:

• schlechtes Chunking
• schwacher Abruf
• verrauschter Kontext
• fehlende Metadaten
• keine Quelle der Wahrheit
• veraltete Dokumente
• schwache Evaluierung
• kein menschlicher Feedback-Loop

RAG behebt kein schlechtes Wissensmanagement.

Wenn der zugrunde liegende Inhalt fragmentiert, veraltet oder widersprüchlich ist, wird das RAG-System dieses Chaos mit Sicherheit zur Oberfläche bringen.

Meinungsgeprägte Ansicht

RAG ist keine Wissensstrategie.

RAG ist eine Zugriffsstrategie.

Es hilft Maschinen, auf Wissen zuzugreifen, entscheidet aber nicht, welches Wissen gültig, gewartet, kanonisch oder nützlich ist.

4. KI-Speichersysteme

KI-Speichersysteme geben Agenten einen persistenten Kontext jenseits eines einzigen Prompts oder einer einzigen Konversation.

Sie können speichern:

• Benutzerpräferenzen
• vergangene Entscheidungen
• langfristige Fakten
• Task-Historie
• Zusammenfassungen
• Reflexionen
• extrahierte Entitäten
• episodische Erinnerungen
• semantische Erinnerungen

Beispiele und verwandte Ideen umfassen:

• MemGPT-ähnliche Speicherebenen
• langfristige Agenten-Erinnerung
• episodische Erinnerung
• semantische Erinnerung
• Vektorspeicher
• Profil-Speicher
• Tool-Zustandsspeicher
• reflexive Agenten

KI-Speicher ist agentengesteuert.

Das Ziel ist Kontinuität.

Wofür KI-Speicher gut ist

KI-Speichersysteme funktionieren gut für:

• persönliche Assistenten
• lang laufende Coding-Agenten
• Forschungsagenten
• Support-Agenten
• Tutoring-Systeme
• Workflow-Automatisierung
• persistente Begleiter
• Ausführung von Tasks über mehrere Sitzungen hinweg

Speicher ist wichtig, wenn das System so handeln muss, als würde es sich erinnern.

KI-Speicher-Ausfallmodi

Speichersysteme sind gefährlich, wenn sie nicht verwaltet werden.

Häufige Probleme:

• falsche Fakten merken
• zu viel speichern
• Privatsphärenrisiko
• veraltete Präferenzen
• schlechte Speicher-Rangfolge
• Speicher-Verdauung (Poisoning)
• kein Vergessensmechanismus
• Verwechslung von Speicher mit Wahrheit

Ein Speichersystem necesita Governance.

Es sollte beantworten:

• Was soll erinnert werden?
• Wer hat es genehmigt?
• Wie lange soll es leben?
• Wann soll es vergessen werden?
• Wie wird es korrigiert?

Meinungsgeprägte Ansicht

KI-Speicher ist nicht nur langer Kontext.

Langer Kontext lässt ein Modell mehr auf einmal sehen. Speicher entscheidet, was über die Zeit überlebt.

Auf der Engineering-Ebene – Arbeitsspeicher, strukturierter Zustand, Abrufspeicher und Konsolidierungspolitik in OpenClaw, Hermes und Provider-SDKs – wird diese Aufteilung in Speichersysteme in KI-Assistenten aufgeschlüsselt.

Das sind unterschiedliche Probleme.

Tabelle der Kernunterschiede

Dimension	PKM	Wiki	RAG	KI-Speicher
Primärer Nutzer	Einzelperson	Team oder öffentliche Gruppe	KI-System	KI-Agent
Hauptfunktion	Denken	Gemeinsame Referenz	Abruf zum Abfragezeitpunkt	Persistenter Kontext
Wissenszustand	Sich entwickelnd	Stabilisiert	Abgerufen	Adaptiv
Struktur	Flexibel	Explizit	Indexbasiert	Gelernt oder extrahiert
Abrufstil	Menschliche Suche und Verknüpfung	Navigation und Suche	Semantischer oder hybrider Abruf	Relevanz plus Bedeutung
Eigentümerschaft	Persönlich	Seiten- oder Team-Eigentümer	Systembetreuer	Von Agent oder Benutzer gesteuert
Zeithorizont	Langfristig persönlich	Langfristig geteilt	Abfragezeitpunkt	Multi-Sitzung
Beste Ausgabe	Einsicht	Zuverlässige Referenz	Grundierte Antwort	Kontinuität
Hauptrisiko	Horten	Verfall	Schlechter Abruf	Schlechter Speicher
Guter Metrik	Wiederverwendung im Denken	Vertrauen und Frische	Antwortqualität	Hilfreiche Kontinuität

Struktur vs. Abruf vs. Evolution

Der einfachste Weg, diese Systeme zu verstehen, ist zu vergleichen, was sie optimieren. Die architektonischen Implikationen dieser Unterscheidung werden in Abruf vs. Repräsentation in Wissenssystemen ausführlich erörtert.

PKM optimiert persönliche Evolution

PKM geht darum, wie sich Ihr Verständnis verändert.

Sie sammeln Material, schreiben es um, verknüpfen es und verwandeln es in etwas Nützliches.

Die Ausgabe ist oft:

• ein besseres mentales Modell
• ein geschriebener Artikel
• eine Entscheidung
• eine Forschungsrichtung
• eine wiederverwendbare Einsicht

PKM ist nicht primär auf schnelle Lookup ausgelegt. Es geht um langfristiges Sinnfinden.

Wikis optimieren geteilte Struktur

Wikis gehen um stabiles Wissen.

Sie fragen:

• Was ist die aktuelle Antwort?
• Wer besitzt sie?
• Wohin sollten Leute gehen?
• Was sollte aktualisiert werden?

Ein Wiki funktioniert, wenn Leute ihm vertrauen.

RAG optimiert maschinellen Abruf

RAG geht darum, den richtigen Kontext zur richtigen Zeit abzurufen.

Es fragt:

• Welche Dokumente sind relevant?
• Welche Chunks sollen verwendet werden?
• Wie viel Kontext passt?
• Was soll das Modell zitieren?

RAG funktioniert, wenn die Abrufqualität hoch ist und das Quellkorpus vertrauenswürdig ist.

KI-Speicher optimiert Kontinuität

Speichersysteme gehen um Persistenz über Sitzungen hinweg.

Sie fragen:

• Was soll der Agent sich merken?
• Was soll vergessen werden?
• Welche Erinnerung ist jetzt wichtig?
• Wie soll Speicher das Verhalten ändern?

Speicher funktioniert, wenn er das zukünftige Verhalten verbessert, ohne den Agenten mit veraltetem oder falschem Kontext zu verschmutzen.

Wann man PKM verwenden sollte

Verwenden Sie PKM, wenn das Wissen persönlich, unvollendet oder explorativ ist.

Gute Szenarien:

• Erlernen verteilter Systeme
• Planen von Artikeln
• Erforschen von LLM-Architektur
• Sammeln von Buchnotizen
• Aufbau eines zweiten Gehirns
• Tracking persönlicher Experimente

Verwenden Sie PKM, wenn Sie noch denken.

Beispiel

Sie lernen über RAG-Evaluierung.

Sie sammeln:

• Artikel
• Benchmark-Notizen
• Diagramme
• Implementierungsideen
• Fehler aus Ihren eigenen Experimenten

Dies gehört zuerst in PKM.

Später, sobald das Wissen stabilisiert ist, können Sie einen Artikel veröffentlichen oder es in Dokumentation verwandeln.

Wann man ein Wiki verwenden sollte

Verwenden Sie ein Wiki, wenn Wissen geteilt und gewartet werden muss.

Gute Szenarien:

• Team-Onboarding
• API-Dokumentation
• operative Runbooks
• Architektur-Entscheidungsprotokolle
• Produktwissen
• Bereitstellungsanweisungen
• Support-Verfahren

Verwenden Sie ein Wiki, wenn andere eine zuverlässige Antwort benötigen.

Beispiel

Ihr Team hat einen korrekten Weg, eine Hugo-Site zu S3 und CloudFront zu deployen.

Das gehört nicht nur in die privaten Notizen von jemandem.

Es gehört in ein Wiki oder Dokumentationsystem mit klarer Eigentümerschaft.

Wann man RAG verwenden sollte

Verwenden Sie RAG, wenn ein KI-System zum Abfragezeitpunkt Zugriff auf externes Wissen benötigt.

Gute Szenarien:

• Chatbot über Dokumentation
• Suchassistent über interne Docs
• Support-Assistent über Hilfeartikel
• Rechts- oder Compliance-Assistent
• Forschung über große Dokumentensätze
• Entwickler-Assistent über Code-Docs

Verwenden Sie RAG, wenn das Problem ist:

Das Modell benötigt Informationen, die außerhalb seiner Gewichte leben.

Beispiel

Sie haben hunderte technische Artikel und möchten, dass ein Assistent Fragen unter Verwendung dieser beantwortet.

RAG ist eine gute Passform.

Aber nur, wenn die Dokumente sauber genug sind, um daraus abzurufen.

Wann man KI-Speicher verwenden sollte

Verwenden Sie KI-Speicher, wenn ein Agent Kontinuität benötigt.

Gute Szenarien:

• Coding-Agenten, die Projekt-Konventionen merken
• persönliche Assistenten, die Präferenzen merken
• Forschungsagenten, die lange Untersuchungen fortsetzen
• Tutoring-Agenten, die den Fortschritt der Schüler merken
• Support-Agenten, die frühere Interaktionen merken
• autonome Agenten, die Ziele verfolgen

Verwenden Sie Speicher, wenn das System über die Zeit hinweg verbessern muss.

Beispiel

Ein Coding-Agent sollte sich merken:

• das Projekt verwendet Go
• Tests laufen mit einem bestimmten Befehl
• der Benutzer bevorzugt minimale Abhängigkeiten
• Datenbank-Migrationen folgen einer Konvention

Das ist nicht nur Abruf. Es ist persistenter Betriebskontext – die Unterscheidung, die dieser Artikel zwischen RAG und Agenten-Speicher zieht, mit Implementierungsdetails in Speichersysteme in KI-Assistenten.

Wie diese Systeme kombiniert werden

Die nützlichsten Systeme sind Hybride.

Eine reife Wissensarchitektur könnte so aussehen:

1. PKM für persönliche Exploration
2. Wiki für stabiles, geteiltes Wissen
3. RAG für maschinellen Zugriff
4. KI-Speicher für lang laufende Agenten-Kontinuität

Jede Schicht hat eine Aufgabe.

Muster 1. PKM zu Wiki

Dies ist die menschliche Wissenspipeline.

Fluss:

1. Notizen privat erfassen
2. Ideen verbinden
3. Einsichten destillieren
4. Stabiles Wissen veröffentlichen
5. Als gemeinsame Referenz warten

So wird persönliche Forschung zu organisatorischem Wissen.

Beispiel

Sie erforschen selbst gehostete Wissenswerkzeuge in Obsidian.

Nach dem Testen von DokuWiki, Nextcloud und statischen Markdown-Systemen schreiben Sie einen stabilen Leitfaden in Ihrer Site oder Team-Wiki.

PKM schuf die Einsicht. Das Wiki bewahrt das Ergebnis.

Muster 2. Wiki zu RAG

Dies ist die Pipeline für maschinellen Zugriff.

Fluss:

1. Kanonische Wiki-Seiten warten
2. Sie indizieren
3. Relevante Sektionen abrufen
4. Grundierte Antworten generieren
5. Zurück zu Quellen verlinken

Dies ist eines der saubersten RAG-Muster.

Das Wiki bleibt die Quelle der Wahrheit. RAG wird zur Zugriffsschicht.

Beispiel

Ein Support-Bot beantwortet Fragen unter Verwendung eines Produkt-Wikis.

Der Bot sollte das Wiki nicht ersetzen. Er sollte zitieren und Benutzer zurück zu den kanonischen Seiten routen.

Muster 3. RAG plus Speicher

Dies ist die Pipeline für Agenten-Kontinuität.

Fluss:

1. RAG ruft externe Fakten ab
2. Speicher speichert Benutzer- oder Task-Kontext
3. Der Agent kombiniert beide
4. Zukünftiges Verhalten verbessert sich

RAG beantwortet:

Was sagt die Wissensdatenbank?

Speicher beantwortet:

Was ist wichtig für diesen Benutzer, dieses Projekt oder diese Aufgabe?

Beispiel

Ein Coding-Agent verwendet RAG, um Framework-Docs abzurufen.

Er verwendet Speicher, um sich zu merken, dass Ihr Projekt ORMs vermeidet, sqlc bevorzugt und strukturiertes Logging verwendet.

Das sind unterschiedliche Wissensebenen.

Muster 4. PKM plus KI-Assistent

Dies ist die hybride Denk-Pipeline.

Fluss:

1. Mensch erfasst Notizen
2. KI fasst zusammen und schlägt Links vor
3. Mensch bearbeitet und validiert
4. Wissen wird strukturierter
5. Einige Seiten reifen zum Wiki oder zur Veröffentlichung

Die KI augmentiert das PKM-System, sollte aber nicht die Wahrheit besitzen.

Beispiel

Ein KI-Assistent kann Verbindungen zwischen Notizen über RAG, Speichersysteme und LLM Wiki vorschlagen.

Aber der Mensch entscheidet, welche Verbindungen sinnvoll sind.

Häufige Architekturfehler

Fehler 1. RAG als Wiki behandeln

RAG ist keine Wissensdatenbank.

Es schafft nicht automatisch eine kanonische Struktur. Es ruft von allem ab, was existiert.

Wenn die Quelldokumente schlecht sind, wird RAG zu einer selbstbewussten Schnittstelle zu schlechtem Wissen.

Fehler 2. Speicher als Datenbank behandeln

KI-Speicher ist selektiver Kontext, nicht allgemeine Speicherung.

Eine Datenbank speichert Datensätze. Speicher verändert Verhalten.

Wenn Sie exakte Fakten benötigen, verwenden Sie eine Datenbank oder Wissensdatenbank. Wenn Sie Kontinuität benötigen, verwenden Sie Speicher.

Fehler 3. PKM als Dokumentation behandeln

PKM kann unordentlich sein.

Dokumentation sollte es nicht sein.

Private Notizen können halbfertige Ideen enthalten. Geteilte Dokumentation sollte stabiles, gewartetes Wissen enthalten.

Fehler 4. Ein Wiki als Denkwerkzeug behandeln

Ein Wiki kann Denken unterstützen, ist aber nicht ideal für frühe Exploration.

Wenn jeder frühe Gedanke eine polierte Seite werden muss, hören die Leute auf zu schreiben.

Verwenden Sie PKM für rohes Denken. Verwenden Sie Wikis für dauerhaftes Wissen.

Fehler 5. Langer Kontext als Speicher behandeln

Langer Kontext ist kein Speicher.

Er hilft nur, solange der Kontext vorhanden ist.

Speicher persistiert, selektiert, aktualisiert und vergisst manchmal.

Entscheidungsleitfaden

Verwenden Sie dieses einfache Entscheidungsmodell.

Wenn das Wissen privat und sich entwickelnd ist

Verwenden Sie PKM.

Wenn das Wissen geteilt und stabil ist

Verwenden Sie ein Wiki.

Wenn eine KI Antworten aus externen Dokumenten geben muss

Verwenden Sie RAG.

Wenn ein Agent Kontinuität über Zeit benötigt

Verwenden Sie Speicher.

Wenn Sie alle vier benötigen

Bauen Sie ein geschichtetes System.

Zwingen Sie nicht ein Werkzeug, jede Aufgabe zu erledigen.

Das Spektrum der Wissenssysteme

Diese Systeme bilden ein Spektrum vom menschlichen Denken zur KI-Kontinuität.

Schicht	System	Rolle
Menschliches Denken	PKM	Erforschen und synthetisieren
Geteilte Struktur	Wiki	Bewahren und warten
Maschineller Zugriff	RAG	Abrufen und generieren
Agenten-Kontinuität	Speicher	Persistieren und adaptieren

Die Richtung ist wichtig.

Wissen beginnt oft als persönlicher Gedanke, wird zur geteilten Struktur, wird für den maschinellen Abruf indiziert und wird dann Teil des persistenten Agentenverhaltens.

Das ist der moderne Wissensstack.

Wo LLM Wiki passt

LLM Wiki-Systeme sitzen zwischen Wiki und KI-Architektur.

Sie sind kein klassisches RAG.

Anstatt Chunks nur zum Abfragezeitpunkt abzurufen, versuchen sie, Wissen in Seiten, Zusammenfassungen, Entitäten und Links vorzustukturieren.

Das macht sie näher an kompilierte Wissenssysteme.

Eine nützliche Platzierung:

System	Position
Wiki	Von Menschen gewartetes strukturiertes Wissen
RAG	Maschineller Abruf zum Abfragezeitpunkt
LLM Wiki	Maschinell strukturiertes Wissen zum Ingest-Zeitpunkt
Speicher	Persistenter Agentenkontext

Deshalb gehört LLM Wiki in die Nähe von Wissenssystemarchitektur, nicht in gewöhnliches RAG.

Praktische Beispiele

Beispiel 1. Persönlicher technischer Blog

Ein technischer Blogger könnte verwenden:

• PKM für Forschungsnotizen
• Hugo-Site als veröffentlichtes Wissen
• internes Linking als wiki-ähnliche Struktur
• RAG später für Site-Suche
• KI-Speicher für Schreibassistent-Präferenzen

Das ist eine starke Architektur.

Sie hält menschliches Urteilsvermögen im Zentrum, ermöglicht gleichzeitig aber KI-Unterstützung.

Beispiel 2. Engineering-Team

Ein Engineering-Team könnte verwenden:

• PKM für individuelles Lernen
• Wiki für Standards und Runbooks
• RAG-Assistent für interne Docs
• Speicher für Coding-Agenten, die in Repositories arbeiten

Das Wiki sollte kanonisch bleiben.

Der RAG-Assistent sollte keine Prozesse erfinden. Die Speicherschicht sollte Projektpräferenzen merken, keine Architektur-Entscheidungen ersetzen.

Beispiel 3. KI-Forschungsworkflow

Ein Forscher könnte verwenden:

• PKM für Paper-Notizen
• Wiki für stabile Zusammenfassungen
• RAG für Literaturrecherche
• Speicher für lang laufende Forschungsagenten

Das funktioniert, weil jede Schicht eine andere Zeitskala handhabt.

Sicherheit und Governance

Wissenssysteme werden riskant, wenn sie sensible oder veraltete Informationen speichern.

PKM-Governance

Fragen:

• Was soll privat bleiben?
• Was soll veröffentlicht werden?
• Was soll gelöscht werden?

Wiki-Governance

Fragen:

• Wer besitzt jede Seite?
• Wann wurde sie zuletzt überprüft?
• Was ist kanonisch?

RAG-Governance

Fragen:

• Welche Quellen sind indiziert?
• Sind Antworten zitiert?
• Wie wird der Abruf evaluiert?
• Welcher Inhalt ist ausgeschlossen?

Speicher-Governance

Fragen:

• Was wird erinnert?
• Können Benutzer Speicher inspizieren?
• Können Benutzer Speicher löschen?
• Wie werden falsche Erinnerungen korrigiert?

Speicher benötigt die strengste Governance, weil er zukünftiges Verhalten stillschweigend beeinflussen kann.

Hinweis zu SEO und Content-Strategie

Wenn Sie eine technische Site betreiben, ist diese Unterscheidung nicht nur architektonisch. Sie ist auch redaktionell.

Sie können Inhalte so abbilden:

• PKM-Seiten erklären menschliche Wissenspraktiken.
• Wiki-Seiten erklären strukturierte Wissenssysteme.
• RAG-Seiten erklären Abruf-Engineering.
• Speicher-Seiten erklären persistentes KI-Verhalten.
• Architektur-Seiten vergleichen und verbinden die Paradigmen.

Das gibt Ihrer Site ein sauberes Autoritätsnetzwerk statt eines Haufens lose verwandter KI-Artikel.

Fazit

PKM, RAG, Wikis und KI-Speichersysteme sind keine Konkurrenten.

Sie sind unterschiedliche Antworten auf unterschiedliche Fragen.

PKM fragt:

Wie denke ich über die Zeit hinweg besser?

Ein Wiki fragt:

Was wissen wir, und wo ist die vertrauenswürdige Version?

RAG fragt:

Welchen externen Kontext soll das Modell gerade jetzt verwenden?

KI-Speicher fragt:

Was soll dieser Agent für die Zukunft sich merken?

Sobald Sie diese Fragen trennen, wird die Architektur offensichtlich.

Verwenden Sie PKM zum Denken. Verwenden Sie Wikis für geteilte Wahrheit. Verwenden Sie RAG zum Abrufen. Verwenden Sie Speicher für Kontinuität.

Die Zukunft ist kein einziges Wissenssystem, das alle anderen ersetzt.

Die Zukunft ist geschichtete Wissensarchitektur. Für Werkzeuge, Methoden und selbst gehostete Plattformen über das gesamte Wissensmanagement-Spektrum hinweg, kartiert die Cluster-Pillar die Landschaft.

Quellen und weiteres Lesen

• https://cloud.google.com/use-cases/retrieval-augmented-generation
• https://aws.amazon.com/what-is/retrieval-augmented-generation/
• https://www.ibm.com/think/topics/retrieval-augmented-generation
• https://www.ibm.com/think/topics/knowledge-management
• https://arxiv.org/abs/2310.08560
• https://research.memgpt.ai/
• https://zettelkasten.de/posts/building-a-second-brain-and-zettelkasten/