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

PKM, RAG, Wikis, KI-Speichersysteme und nun auch praktische, KI-gestützte Workflows werden oft so diskutiert, als lösten sie dasselbe Problem. 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 beizubehalten.

Die Verwechslung 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 geben, und PKM-Tools, die mit Automatisierungen überlastet sind, die sie nie handhaben sollten.

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, Eigentum, Evolution und Use Cases in der Praxis. Wenn Sie sehen möchten, wie diese Abstraktionen bei der konkreten täglichen Notiznahme, Dokumentation und Runbook-Wartung aussehen, führt der Begleitartikel KI für Wissensmanagement: Echte Workflows, die bestehen 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 geeignet für
PKM	Einzelperson	Entwicklung persönlichen Wissens	Denken, Lernen, Synthese
Wiki	Team oder öffentliche Gruppe	Wartung gemeinsamen Wissens	Dokumentation, Richtlinien, Referenz
RAG	Maschinensystem	Abruf von Kontext für die Generierung	KI-Antworten über externe Daten
KI-Speicher	KI-Agent	Beibehaltung 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 Agentenkontext.

Das ist das mentale Kernmodell.

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 der Absicht.

Ein PKM-System ist nicht nur ein privates 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, „Wissen" als eine Sache zu behandeln.

In der Praxis gibt es mehrere Wissensebenen:

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

Verschiedene Systeme optimieren verschiedene Stadien.

Die vier Paradigmen

1. PKM

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

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

Typische PKM-Systeme umfassen:

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

PKM wird von Menschen angetrieben.

Das Ziel ist nicht nur Speicherung. Das Ziel ist besseres Denken. Unabhängig vom Tool müssen die zugrunde liegenden Notizen noch zwischen den Geräten bewegt werden, auf denen dieses Denken stattfindet; Syncthing File Sync für selbstgehostete Wissenssysteme behandelt die private, Peer-to-Peer-Ebene, die ein Markdown-basiertes PKM-System ohne Cloud-Konto synchron hält.

Wofür PKM gut ist

PKM funktioniert gut für:

• das Erlernen eines neuen Fachgebiets
• die Entwicklung originärer 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 unvollständige Gedanken, partielle Ideen, privaten Kontext und sich entwickelnde Konzepte.

Deshalb ist PKM nicht dasselbe wie Dokumentation.

Dokumentation will Klarheit. PKM toleriert Ambiguität.

PKM-Ausfallmodi

PKM scheitert oft, wenn es zu Folgendem wird:

• eine Ablage
• ein Ordnertaxonomie-Projekt
• eine Produktivitätsästhetik
• ein Werkzeug-Optimierungs-Hobby
• ein privates 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.

Meinungsstarke Einschätzung

PKM sollte auf Wiederverwendung, nicht auf Erfassung optimieren.

Alles aufzunehmen fühlt sich produktiv an, schafft aber Schuld. 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 konzipiert ist.

Typische Wiki-Systeme umfassen:

• DokuWiki
• MediaWiki
• Confluence
• BookStack
• Git-basierte Dokumentationsseiten
• interne Unternehmenswissensdatenbanken

Ein Wiki ist in der Regel formeller als PKM.

Es sollte folgende Frage beantworten:

Was wissen wir, und wo befindet sich 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-Ausfallmodi

Wikis scheitern oft, weil sie veralten.

Häufige Probleme:

• keine Seitenverantwortlichen
• veraltete Screenshots
• duplizierte Seiten
• unklare kanonische Versionen
• zu viel Hierarchie
• kein Wartungsrhythmus

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

Meinungsstarke 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 (abfragegestützte Generierung).

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

Eine grundlegende RAG-Pipeline hat normalerweise:

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

RAG wird von Maschinen angetrieben.

Das Ziel ist nicht die Schaffung von Wissen. Das Ziel ist es, einem Modell zum Abfragezeitpunkt relevanten Kontext zu geben.

Wofür RAG gut ist

RAG funktioniert gut für:

• Frage-und-Antwort-Services über Dokumente
• interne Suchassistenten
• Support-Bots
• technische Dokumentationsassistenten
• Compliance-Nachschlage
• Forschung über große Korpora
• Verbindung von LLMs mit aktualisierten Informationen

RAG ist besonders nützlich, wenn das Modell die Informationen nicht oder nicht sollen memorieren kann.

RAG-Ausfallmodi

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 zur Oberfläche bringen.

Meinungsstarke 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 einen persistenten Kontext jenseits eines einzelnen Prompts oder einer einzelnen 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
• reflektierende Agenten

KI-Speicher wird von Agenten angetrieben.

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
• KundenSupport-Agenten
• Tutoring-Systeme
• Workflow-Automatisierung
• persistente Begleiter
• Multi-Session-Task-Ausführung

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 erinnern
• zu viel speichern
• Datenschutzrisiko
• veraltete Präferenzen
• schlechte Speicher-Rangfolge
• Memory Poisoning (Speichervergiftung)
• kein Vergessensmechanismus
• Verwechslung von Speicher mit Wahrheit

Ein Speichersystem braucht Governance.

Es sollte folgende Fragen beantworten:

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

Meinungsstarke Einschätzung

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 Konsolidierungsrichtlinie in OpenClaw, Hermes und Provider-SDKs – wird diese Aufteilung in Speichersysteme in KI-Assistenten aufgespalten.

Das sind verschiedene 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 Query-Time	Persistenter Kontext
Wissenszustand	Entwickelnd	Stabilisiert	Abgerufen	Adaptiv
Struktur	Flexibel	Explizit	Indexbasiert	Erlernt oder extrahiert
Abrufstil	Menschliche Suche und Verlinkung	Navigation und Suche	Semantischer oder hybrider Abruf	Relevanz plus Salienz
Eigentum	Persönlich	Seiten- oder Teamverantwortliche	Systembetreuer	Agenten- oder benutzerkontrolliert
Zeithorizont	Langfristig persönlich	Langfristig geteilt	Query-Time	Multi-Session
Beste Ausgabe	Erkenntnis	Zuverlässige Referenz	Fundierte Antwort	Kontinuität
Hauptrisiko	Hoarding (Hortung)	Veraltung	Schlechter Abruf	Schlechter Speicher
Gutes 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 der Vergleich dessen, was sie optimieren. Die architektonischen Implikationen dieser Unterscheidung werden in Abruf vs. Repräsentation in Wissenssystemen im Detail erforscht.

PKM optimiert persönliche Evolution

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 langfristige Sinnfindung (Sensemaking).

Wikis optimieren geteilte Struktur

Wikis gehen um stabiles Wissen.

Sie fragen:

• Was ist die aktuelle Antwort?
• Wer ist dafür verantwortlich?
• 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 hinein?
• 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 sich erinnern?
• Was soll vergessen werden?
• Welche Erinnerung ist jetzt wichtig?
• Wie sollte die Erinnerung das Verhalten verändern?

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

Wann PKM verwendet werden sollte

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

Gute Szenarien:

• Lernen verteilter Systeme
• Planung von Artikeln
• Forschung zu LLM-Architekturen
• Sammlung 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
• Implementierungsideen
• Fehler aus Ihren eigenen Experimenten

Dies gehört zuerst in PKM.

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

Wann ein Wiki verwendet werden sollte

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

Gute Szenarien:

• Team-Onboarding
• API-Dokumentation
• operative Runbooks
• Architektur-Entscheidungsprotokolle (ADRs)
• Produktwissen
• Bereitstellungsanweisungen
• Support-Prozeduren

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 eines Einzelnen.

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

Wann RAG verwendet werden sollte

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

Gute Szenarien:

• Chatbot über Dokumentation
• Suchassistent über interne Docs
• Supportassistent ü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 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 abgerufen zu werden.

Wann KI-Speicher verwendet werden 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
• Tutoring-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
• Datenbankmigrationen einer Konvention folgen

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 Ebene 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 selbstgehostete 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 hat die Erkenntnis erschaffen. Das Wiki bewahrt das Ergebnis.

Muster 2. Wiki zu RAG

Dies ist die maschinelle Zugriffspipeline.

Fluss:

1. Kanonische Wiki-Seiten warten
2. Indizieren
3. Relevante Sektionen 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 Zugriffsebene.

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 routen.

Muster 3. RAG plus Speicher

Dies ist die Agenten-Kontinuitäts-Pipeline.

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 antwortet:

Was sagt die Wissensdatenbank?

Speicher antwortet:

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 erinnern, dass Ihr Projekt ORMs vermeidet, sqlc bevorzugt und strukturiertes Logging verwendet.

Das sind verschiedene 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 zu Wiki oder Veröffentlichung

Die KI augmentiert 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, keine 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.

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 zu einer polierten Seite werden muss, hören die Leute auf zu schreiben.

Verwenden Sie PKM für grobes 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 in Entwicklung 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 Werkzeug, jede Aufgabe zu erledigen.

Das Spektrum der Wissenssysteme

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

Ebene	System	Rolle
Menschlicher Gedanke	PKM	Erkunden 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 zu geteilter Struktur, wird für den maschinellen Abruf indiziert und wird dann Teil des persistenten Agentenverhaltens.

Das ist der moderne Knowledge Stack.

Wo LLM Wiki passt

LLM Wiki-Systeme befinden sich zwischen Wiki und KI-Architektur.

Sie sind kein klassisches RAG.

Anstatt Chunks nur zum Query-Time abzurufen, versuchen sie, Wissen in Seiten, Zusammenfassungen, Entitäten und Links vorab zu strukturieren.

Das macht sie näher an kompilierten Wissenssystemen.

Eine nützliche Platzierung:

System	Position
Wiki	Von Menschen gewartete strukturierte Wissensdatenbank
RAG	Maschineller Abruf zum Query-Time
LLM Wiki	Maschinell strukturiertes Wissen zum Ingest-Time
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 Sitesuche
• KI-Speicher für Schreibassistent-Präferenzen

Das ist eine starke Architektur.

Sie hält menschliches Urteil im Zentrum, ermöglicht aber gleichzeitig 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, keine Architektur-Entscheidungen 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 Ebene 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:

• 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 den Speicher inspizieren?
• Können Benutzer den Speicher löschen?
• Wie werden falsche Erinnerungen korrigiert?

Speicher braucht 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 persistierendes KI-Verhalten.
• Architektur-Seiten vergleichen und verbinden die Paradigmen.

Das gibt Ihrer Site ein sauberes Autoritätsnetz 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 sollte das Modell jetzt verwenden?

KI-Speicher fragt:

Was soll dieser Agent für die Zukunft sich 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 für Abruf. Verwenden Sie Speicher für Kontinuität.

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

Die Zukunft ist geschichtete Wissensarchitektur. Für Werkzeuge, Methoden und selbstgehostete Plattformen über das gesamte Spektrum des Wissensmanagements hinweg, kartiert die Cluster-Pillar das Terrain.

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/