PKM vs. RAG vs. Wiki vs. Gedächtnissysteme: Klar erklärt

PKM, RAG, Wikis und KI-Speichersysteme werden oft so diskutiert, als würden sie dasselbe Problem lösen. 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 zu erhalten.

Das Verwechseln dieser Systeme führt zu schlechter Architektur.

Man erhält Wikis voller persönlicher Notizen, RAG-Systeme ohne eine Single Source of Truth, Speicherschichten, die sich als Datenbanken verkleiden, und PKM-Tools, die mit Automatisierungen überladen sind, für die sie nie entwickelt wurden.

Ein besseres Modell besteht darin, sie als verschiedene Teile eines Spektrums von Wissenssystemen zu betrachten.

Dieser Artikel vergleicht PKM, RAG, Wikis und KI-Speichersysteme nach Struktur, Abruf, Eigentum, Entwicklung und Anwendungsfällen in der Praxis.

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	Erhaltung von Kontext über die Zeit	Lang laufende Agenten und Personalisierung

Die wichtigste Unterscheidung ist diese:

PKM und Wikis strukturieren Wissen. RAG ruft Wissen ab. Speichersysteme entwickeln den Agenten-Kontext weiter.

Das ist das grundlegende mentale Modell.

Warum diese Systeme verwechselt werden

Sie überschneiden sich in ihrer sichtbaren Funktionsweise.

Alle von ihnen können:

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

Aber sie unterscheiden sich in der Absicht.

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

Die Verwirrung entsteht daraus, „Wissen“ als eine einzige Sache zu behandeln.

In der Praxis hat Wissen mehrere Ebenen:

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

Verschiedene Systeme optimieren verschiedene Stadien.

Die vier Paradigmen

1. PKM

PKM steht für Personal Knowledge Management.

Es ist die Praxis, Wissen zu erfassen, zu organisieren, zu verbinden und für die persönliche Arbeit zu nutzen.

Typische PKM-Systeme umfassen:

• Obsidian
• Logseq
• Notion
• einfache Markdown-Ordner
• Zettelkasten-Systeme
• Second-Brain-Systeme

PKM wird vom Menschen 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 Verbinden von Notizen über die Zeit
• das Schreiben von Artikeln oder Büchern
• die Verfolgung persönlicher Forschung
• den Aufbau eines Second Brain

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

Deshalb ist PKM nicht dasselbe wie Dokumentation.

Dokumentation will Klarheit. PKM toleriert Ambiguität.

PKM-Ausfallmuster

PKM scheitert oft, wenn es zu folgendem wird:

• einer Ablage
• einem Projekt zur Ordner-Taxonomie
• einem Produktivitätsästhetik-Projekt
• einem Hobby der 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.

Meinungsstützende Einschätzung

PKM sollte auf Wiederverwendung, nicht auf Erfassung optimieren.

Alles zu erfassen fühlt sich produktiv an, erstellt aber Schulden. Der echte Wert erscheint, wenn Notizen verbunden, umgeschrieben, komprimiert und in der Ausgabe verwendet werden.

2. Wiki

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

Typische Wiki-Systeme umfassen:

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

Ein Wiki ist in der Regel 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 Eigentum und Wartung kritisch.

Wiki-Ausfallmuster

Wikis scheitern oft, weil sie veralten.

Häufige Probleme:

• keine Seitenbesitzer
• 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.

Meinungsstützende Einschätzung

Ein Wiki sollte langweilig sein.

Das ist ein Kompliment.

Ein gutes Wiki ist kein 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.

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 (Aufteilung)
3. Embeddings oder Suchindex
4. Abruf
5. Optionales Reranking
6. Prompt-Zusammenstellung
7. LLM-Generierung

RAG wird von Maschinen 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:

• Fragenbeantwortung über Dokumente
• 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 memorieren sollte.

RAG-Ausfallmuster

RAG scheitert oft, wenn Teams es als magische Suche behandeln.

Häufige Probleme:

• schlechtes Chunking
• schwacher Abruf
• verrauschter Kontext
• fehlende Metadaten
• keine Single Source of Truth
• 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 an die Oberfläche bringen.

Meinungsstützende Einschätzung

RAG ist keine Wissensstrategie.

RAG ist eine Zugriffsstrategie.

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

4. KI-Speichersysteme

KI-Speichersysteme geben Agenten persistenten Kontext über einen einzelnen Prompt oder eine einzelne Konversation hinaus.

Sie können speichern:

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

Beispiele und verwandte Ideen umfassen:

• MemGPT-artige Speicherebenen
• Langzeit-Agentenspeicher
• episodischer Speicher
• semantischer Speicher
• Vektorspeicher
• Profil-Speicher
• Tool-State-Speicher
• reflektierende Agenten

KI-Speicher wird vom Agenten gesteuert.

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
• Kundenunterstützungsagenten
• Tutoren-Systeme
• Workflow-Automatisierung
• persistente Begleiter
• mehrsessionige Aufgabenausführung

Speicher ist wichtig, wenn das System so handeln muss, als ob es sich erinnert.

KI-Speicher-Ausfallmuster

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

Häufige Probleme:

• falsche Fakten erinnern
• zu viel speichern
• Datenschutzrisiko
• veraltete Präferenzen
• schlechte Speicher-Rangfolge
• Memory Poisoning (Speichervergiftung)
• kein Vergessensmechanismus
• Verwechslung von Speicher mit Wahrheit

Ein Speichersystem benötigt 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?

Meinungsstützende Einschätzung

KI-Speicher ist nicht einfach langer Kontext.

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

Das sind unterschiedliche Probleme.

Kernunterschiede-Tabelle

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 Verlinkung	Navigation und Suche	Semantischer oder hybrider Abruf	Relevanz plus Bedeutung
Eigentum	Persönlich	Seiten- oder Teambesitzer	Systembetreuer	Agenten- oder benutzerkontrolliert
Zeithorizont	Langfristig persönlich	Langfristig geteilt	Abfragezeitpunkt	Mehrsessionig
Beste Ausgabe	Erkenntnis	Zuverlässige Referenz	Fundierte Antwort	Kontinuität
Hauptrisiko	Horden	Veraltung	Schlechter Abruf	Schlechter Speicher
Gute Metrik	Wiederverwendung im Denken	Vertrauen und Frische	Antwortqualität	Hilfreiche Kontinuität

Struktur vs. Abruf vs. Entwicklung

Der einfachste Weg, diese Systeme zu verstehen, ist der Vergleich dessen, was sie optimieren. Die architektonischen Implikationen dieser Unterscheidung werden in Retrieval vs Representation in Knowledge Systems ausführlich erörtert.

PKM optimiert persönliche Entwicklung

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

Sie sammeln Material, schreiben es um, verbinden 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 Erkenntnis

PKM geht nicht primär um schnellen Lookup. Es geht um langfristiges Sinnfinden (Sensemaking).

Wikis optimieren gemeinsame Struktur

Wikis gehen um stabiles Wissen.

Sie fragen:

• Was ist die aktuelle Antwort?
• Wem gehört sie?
• Wohin sollten die Leute gehen?
• Was sollte aktualisiert werden?

Ein Wiki funktioniert, wenn die 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 sollten verwendet werden?
• Wie viel Kontext passt?
• Was sollte 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 Sessions hinweg.

Sie fragen:

• Was soll der Agent erinnern?
• Was soll vergessen werden?
• Welcher Speicher ist jetzt wichtig?
• Wie soll der Speicher das Verhalten ändern?

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

Wann man PKM verwenden sollte

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

Gute Szenarien:

• Lernen von verteilten Systemen
• Planung von Artikeln
• Recherche zu LLM-Architektur
• Sammeln von Buchnotizen
• Aufbau eines Second Brain
• Verfolgung persönlicher Experimente

Verwenden Sie PKM, wenn Sie noch denken.

Beispiel

Sie lernen über RAG-Evaluierung.

Sie sammeln:

• Artikel
• Benchmark-Notizen
• Diagramme
• Implementierungsides
• Misserfolge 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 ihn 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
• Deploymentsanweisungen
• Support-Verfahren

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

Beispiel

Ihr Team hat eine korrekte Methode, eine Hugo-Site zu S3 und CloudFront zu deployen.

Das gehört nicht nur in die privaten Notizen eines Menschen.

Es gehört in ein Wiki oder ein Dokumentationssystem mit klarem Eigentum.

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
• Entwicklerassistent ü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 technischer Artikel und möchten, dass ein Assistent Fragen unter Verwendung dieser beantwortet.

RAG ist eine gute Wahl.

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 erinnern
• persönliche Assistenten, die Präferenzen erinnern
• Forschungsagenten, die lange Untersuchungen fortsetzen
• Tutoren-Agenten, die den Fortschritt der Schüler erinnern
• Support-Agenten, die frühere Interaktionen erinnern
• autonome Agenten, die Ziele verfolgen

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

Beispiel

Ein Coding-Agent sollte sich erinnern:

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

Das ist nicht nur Abruf. Es ist persistenter Betriebskontext.

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 gemeinsames Wissen
3. RAG für maschinellen Zugriff
4. KI-Speicher für Kontinuität lang laufender Agenten

Jede Schicht hat eine Aufgabe.

Muster 1. PKM zu Wiki

Dies ist die menschliche Wissenspipeline.

Fluss:

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

So wird persönliche Forschung zu organisatorischem Wissen.

Beispiel

Sie recherchieren selbst gehostete Wissenswerkzeuge in Obsidian.

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

PKM hat die Erkenntnis geschaffen. 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. Indizieren
3. Relevante Abschnitte abrufen
4. Fundierte Antworten generieren
5. Zurück zu den Quellen verlinken

Dies ist eines der saubersten RAG-Muster.

Das Wiki bleibt die Single Source of Truth. 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 Nutzer zurück zu den kanonischen Seiten leiten.

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 Aufgabenkontext
3. Der Agent kombiniert beides
4. Zukünftiges Verhalten verbessert sich

RAG beantwortet:

Was sagt die Wissensdatenbank?

Speicher beantwortet:

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

Beispiel

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

Er verwendet Speicher, um sich zu erinnern, 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 Denkpipeline.

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 ergänzt das PKM-System, aber sie sollte 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 erstellt nicht automatisch eine kanonische Struktur. Es ruft 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, kein allgemeiner Speicher.

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. Gemeinsame Dokumentation sollte stabiles, gewartetes Wissen enthalten.

Fehler 4. Ein Wiki als Denkwerkzeug behandeln

Ein Wiki kann das Denken unterstützen, aber es ist 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 die Zeit benötigt

Verwenden Sie Speicher.

Wenn Sie alle vier benötigen

Bauen Sie ein geschichtetes System.

Zwingen Sie nicht ein Tool, 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	Erkunden und synthetisieren
Gemeinsame 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 zu gemeinsamer Struktur, wird für maschinellen Abruf indiziert und wird dann Teil des persistenten Agentenverhaltens.

Das ist der moderne Wissensstack.

Wo LLM Wiki passt

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

Sie sind kein klassisches RAG.

Statt nur zum Abfragezeitpunkt Chunks abzurufen, versuchen sie, Wissen vorab in Seiten, Zusammenfassungen, Entitäten und Links zu strukturieren.

Das macht sie näher an kompilierten Wissenssystemen.

Eine nützliche Platzierung:

System	Position
Wiki	Von Menschen gepflegtes strukturiertes Wissen
RAG	Maschineller Abruf zum Abfragezeitpunkt
LLM Wiki	Maschinell strukturiertes Wissen zur Ingest-Zeit
Speicher	Persistenter Agenten-Kontext

Deshalb gehört LLM Wiki in die Nähe der 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
• interne Verlinkung als wiki-ähnliche Struktur
• RAG später für Site-Suche
• KI-Speicher für Präferenzen des Schreib-Assistenten

Das ist eine starke Architektur.

Sie hält menschliches Urteil 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 erinnern, nicht Architekturentscheidungen ersetzen.

Beispiel 3. KI-Forschungsworkflow

Ein Forscher könnte verwenden:

• PKM für Papier-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 sollte privat bleiben?
• Was sollte veröffentlicht werden?
• Was sollte gelöscht werden?

Wiki-Governance

Fragen:

• Wem gehört 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 Nutzer Speicher inspizieren?
• Können Nutzer Speicher löschen?
• Wie werden falsche Erinnerungen korrigiert?

Speicher benötigt die strengste Governance, da 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ätsgeflecht statt eines Haufens locker 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 sollte das Modell jetzt verwenden?

KI-Speicher fragt:

Was soll dieser Agent für die Zukunft erinnern?

Sobald Sie diese Fragen trennen, wird die Architektur offensichtlich.

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

Die Zukunft ist nicht ein Wissensystem, das alle anderen ersetzt.

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

Quellen und weiterführende Literatur

• 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/