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

Eine Landkarte moderner Wissenssysteme

Inhaltsverzeichnis

PKM, RAG, Wikis und KI-Speichersysteme werden oft so diskutiert, als lösten sie dasselbe Problem. Tun sie nicht. Sie beschäftigen sich alle mit Wissen, aber sie agieren 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 aufrechtzuerhalten.

Wenn man diese Systeme verwechselt, führt das zu schlechter Architektur.

Man erhält Wikis voller privater Notizen, RAG-Systeme ohne eine Quelle der Wahrheit, Schichtspeicher, die sich als Datenbanken tarnen, 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.

pkm vs rag vs wiki infographic

Dieser Artikel vergleicht PKM, RAG, Wikis und KI-Speichersysteme hinsichtlich Struktur, Abruf, Eigentum, Entwicklung und Verwendung in der Praxis.

Die Kurzfassung

System Primärer Nutzer Hauptzweck Am besten geeignet 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 basierend auf externen Daten
KI-Speicher KI-Agent Aufrechterhaltung 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 weiter.

Das ist das grundlegende mentale Modell.

Warum diese Systeme verwechselt werden

Sie überschneiden sich in ihrem sichtbaren Verhalten.

Alle von ihnen können:

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

Aber sie unterscheiden sich in ihrer Absicht.

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

Die Verwirrung entsteht dadurch, 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. 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:

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 Verbinden von Notizen über die Zeit
  • das Schreiben von Artikeln oder Büchern
  • die Verfolgung persönlicher Forschung
  • den Aufbau eines zweiten Gehirns

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

Deshalb ist PKM nicht dasselbe wie Dokumentation.

Dokumentation verlangt Klarheit. PKM toleriert Ambiguität.

PKM-Ausfallmodi

PKM scheitert oft, wenn es sich entwickelt zu:

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

Meinungsbild

PKM sollte auf Wiederverwendung optimieren, nicht auf Erfassung.

Alles aufzunehmen fühlt sich produktiv an, schafft 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 gemeinsame Referenz entwickelt wurde.

Typische Wiki-Systeme umfassen:

  • DokuWiki
  • MediaWiki
  • Confluence
  • BookStack
  • Dokumentationssysteme auf Git-Basis
  • interne Unternehmenswissensdatenbanken

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
  • 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 entscheidend.

Wiki-Ausfallmodi

Wikis scheitern oft, weil sie veralten.

Häufige Probleme:

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

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

Meinungsbild

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.

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 in der Regel:

  1. Dokumente
  2. Chunking (Zerteilung)
  3. Embeddings oder Suchindex
  4. Abruf
  5. Optionales 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:

  • Fragenbeantwortung über Dokumente hinweg
  • interne Suchassistenten
  • Support-Bots
  • Assistenten für technische Dokumentation
  • Compliance-Suche
  • Forschung über große Korpora hinweg
  • Verbindung von LLMs mit aktualisierten Informationen

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

RAG-Ausfallmodi

RAG scheitert oft, 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 Evaluation
  • 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 Schau stellen.

Meinungsbild

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 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 Speicherschichten
  • Langzeitspeicher für Agenten
  • episodische Erinnerung
  • semantische Erinnerung
  • Vektorspeicher
  • Profilspeicher
  • 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
  • mehrsessionige 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
  • Speicher-Vergiftung
  • kein Vergessen-Mechanismus
  • Verwechslung von Speicher mit Wahrheit

Ein Speichersystem braucht 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?

Meinungsbild

KI-Speicher ist nicht einfach nur langer Kontext.

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

Das sind unterschiedliche Probleme.

Kerntabelle der Unterschiede

Dimension PKM Wiki RAG KI-Speicher
Primärer Nutzer Einzelperson Team oder öffentliche Gruppe KI-System KI-Agent
Hauptfunktion Denken Gemeinsame Referenz Abruf zur Abfragezeit 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 Salienz
Eigentum Persönlich Seiten- oder Teamverantwortliche Systembetreuer Agenten- oder benutzergesteuert
Zeithorizont Langfristig persönlich Langfristig geteilt Abfragezeit Mehrsessionig
Beste Ausgabe Einsicht Zuverlässige Referenz Fundierte Antwort Kontinuität
Hauptrisiko Horten Veraltung Schlechter Abruf Schlechter Speicher
Guter 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 Einsicht

PKM geht nicht primär um schnellen Lookup. Es geht um langfristige Sinnfindung.

Wikis optimieren geteilte Struktur

Wikis gehen um stabiles Wissen.

Sie fragen:

  • Was ist die aktuelle Antwort?
  • Wer besitzt 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 sollen verwendet werden?
  • Wie viel Kontext passt hinein?
  • Was soll das Modell zitieren?

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

KI-Speicher optimiert Kontinuität

Speichersysteme gehen um Persistenz über Sessions hinweg.

Sie fragen:

  • Was soll der Agent sich merken?
  • Was soll vergessen werden?
  • Welche Erinnerung ist jetzt relevant?
  • Wie soll 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 man PKM verwenden sollte

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

Gute Szenarien:

  • Lernen von verteilten Systemen
  • Planen von Artikeln
  • Erforschen von LLM-Architekturen
  • Sammeln von Buchnotizen
  • Aufbau eines zweiten Gehirns
  • Verfolgen persönlicher Experimente

Verwenden Sie PKM, wenn Sie noch denken.

Beispiel

Sie lernen über RAG-Evaluation.

Sie sammeln:

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

Dies gehört zuerst in PKM.

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

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 auf S3 und CloudFront bereitzustellen.

Das gehört nicht nur in die privaten Notizen einer Person.

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 Dokumente
  • Support-Assistent über Hilfeartikel
  • Rechts- oder Compliance-Assistent
  • Forschung über große Dokumentensätze
  • Entwickler-Assistent über Code-Dokumente

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 mit ihnen beantwortet.

RAG ist eine gute Wahl.

Aber nur, wenn die Dokumente sauber genug sind, um daraus abgerufen zu werden.

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 besser werden muss.

Beispiel

Ein Coding-Agent sollte sich merken:

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

Das ist nicht nur Abruf. Das 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, 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 forschen in Obsidian über selbst gehostete Wissenswerkzeuge.

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

PKM hat die Einsicht geschaffen. Das Wiki bewahrt das Ergebnis.

Muster 2. Wiki zu RAG

Dies ist die Pipeline für maschinellen Zugriff.

Fluss:

  1. Kanonische Wiki-Seiten pflegen
  2. Sie 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 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 Nutzer 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 antwortet:

Was sagt die Wissensdatenbank?

Speicher antwortet:

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

Beispiel

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

Er verwendet Speicher, um sich zu merken, dass Ihr Projekt ORMs vermeidet, sqlc bevorzugt und strukturierte Protokollierung 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 erweitert 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 zu behandeln

RAG ist keine Wissensdatenbank.

Sie erstellt automatisch keine kanonische Struktur. Sie ruft von dem ab, was existiert.

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

Fehler 2. Speicher als Datenbank zu 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 zu behandeln

PKM kann chaotisch 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 zu behandeln

Ein Wiki kann das 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 grobes Denken. Verwenden Sie Wikis für dauerhaftes Wissen.

Fehler 5. Langer Kontext als Speicher zu behandeln

Langer Kontext ist kein Speicher.

Er hilft nur, solange der Kontext vorhanden ist.

Speicher persistiert, selektiert, aktualisiert und vergisst manchmal.

Entscheidungshilfe

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 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 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 Wissens-Stack.

Wo LLM Wiki passt

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

Sie sind kein klassisches RAG.

Anstatt Chunks nur zur Abfragezeit abzurufen, versuchen sie, Wissen vorab in Seiten, Zusammenfassungen, Entitäten und Links zu strukturieren.

Das macht sie näher an kompilierte Wissenssystemen.

Eine nützliche Platzierung:

System Position
Wiki Von Menschen gepflegtes strukturiertes Wissen
RAG Maschineller Abruf zur Abfragezeit
LLM Wiki Maschinell strukturiertes Wissen zur Ingest-Zeit
Speicher Persistenter Agentenkontext

Deshalb gehört LLM Wiki in die Nähe der Wissenssystem-Architektur, 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 die Seitensuche
  • KI-Speicher für Präferenzen des Schreibassistenten

Das ist eine starke Architektur.

Sie hält menschliche Urteilskraft 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 Dokumente
  • 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 Architekturentscheidungen ersetzen.

Beispiel 3. KI-Forschungsworkflow

Ein Forscher könnte verwenden:

  • PKM für Papiernotizen
  • 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:

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

RAG-Governance

Fragen:

  • Welche Quellen sind indiziert?
  • Werden 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, 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ätsnetzwerk statt eines Haufens lose zusammenhängender KI-Artikel.

Fazit

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

Sie sind unterschiedliche Antworten auf unterschiedliche Fragen.

PKM fragt:

Wie denke ich im Laufe der Zeit besser?

Ein Wiki fragt:

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

RAG fragt:

Welchen externen Kontext soll das Modell 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 gemeinsame Wahrheit. Verwenden Sie RAG zum Abrufen. Verwenden Sie Speicher für Kontinuität.

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

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

Quellen und weiterführende Literatur

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.