Retrieval vs. Repräsentation in Wissenssystemen

Die meisten modernen Wissenssysteme optimieren die Abrufprozesse (Retrieval), und das ist verständlich. Die Suche ist sichtbar, leicht zu demonstrieren und wirkt fast magisch, wenn sie funktioniert. Frage eingeben, Antwort erhalten.

Aber der Abruf ist nur die eine Hälfte des Problems. Die tiefere Frage lautet:

Welche Struktur hat das Wissen, bevor überhaupt versucht wird, es abzurufen?

Das ist die Repräsentation — die Struktur hinter dem Wissen:

• Notizen
• Seiten
• Schemata
• Graphen
• Entitäten
• Beziehungen
• Zusammenfassungen
• Taxonomien
• Quellenbegrenzungen
• Kanonische Versionen

Der Abruf fragt:

Kann ich etwas Relevantes finden?

Die Repräsentation fragt:

Ist das Wissen auf sinnvolle Weise organisiert?

Das sind nicht dasselbe Problem. Ein RAG-System mit schlechter Repräsentation wird zu einer schnellen Schnittstelle zu einem unübersichtlichen Archiv. Es kann Fragmente abrufen, aber es kann keine gebrochene Struktur reparieren. Es kann Dokumente zitieren, aber es kann nicht entscheiden, welches davon die kanonische Quelle ist. Es kann Kontext zusammenstellen, aber es kann nicht garantieren, dass das zugrunde liegende Wissen kohärent ist.

Aus diesem Grund sind Systeme im Stil von LLM Wiki interessant: Sie verlagern den Aufwand von der Abfragezeit auf die Ingestionszeit (Ingestionszeitpunkt). Anstatt bei einer Nutzerfrage nur Chunks abzurufen, versuchen sie, Wissen vorab in Seiten, Konzepte, Zusammenfassungen und Links zu strukturieren. Das macht RAG nicht obsolet — es bedeutet, dass Abruf und Repräsentation unterschiedliche Schichten sind und gute Wissenssysteme beide benötigen.

Die grundlegende Unterscheidung

Abruf betrifft den Zugang; Repräsentation betrifft die Bedeutung.

Ein schwaches System springt oft direkt zum Abruf; ein starkes System fragt zuerst:

1. Was sind die Kernkonzepte?
2. Was ist die kanonische Quelle?
3. Welche Beziehungen sind wichtig?
4. Was ändert sich mit der Zeit?
5. Was sollte abgerufen werden?
6. Was sollte bereits repräsentiert sein?

Das ist der Unterschied zwischen der Suche über Dokumente und einem echten Wissenssystem.

Warum der Abruf dominant wurde

Der Abruf wurde dominant, weil er gut auf den modernen AI-Stack passt. Eine typische RAG-Pipeline sieht wie folgt aus:

1. Dokumente laden
2. In Chunks aufteilen
3. Embeddings generieren
4. Vektoren speichern
5. Relevante Chunks abrufen
6. Optional reranken
7. In einen LLM-Prompt einfügen
8. Antwort generieren

Diese Pipeline ist praktisch: Sie ist relativ einfach aufzubauen, funktioniert mit unstrukturierten Dokumenten, skaliert auf große Korpora, vermeidet das Neu-Training von Modellen und gibt LLMs Zugriff auf aktuelle Informationen. Deshalb wurde RAG zum Standardmuster für „KI über Dokumenten".

Aber es gibt eine Falle:

RAG verbessert den Zugang zu Wissen. Es verbessert nicht automatisch das Wissen selbst.

Wenn Ihre Inhalte dupliziert, veraltet, widersprüchlich, schlecht chunked oder schlecht benannt sind, wird der Abruf diese Probleme aufdecken — oft mit großer Sicherheit.

Was Repräsentation bedeutet

Repräsentation ist die Art und Weise, wie Wissen geformt wird, bevor der Abruf stattfindet. Sie beantwortet Fragen wie:

• Ist dieses Wissen als Dokumente, Notizen, Entitäten oder Fakten gespeichert?
• Sind Beziehungen explizit oder implizit?
• Gibt es kanonische Seiten?
• Gibt es Zusammenfassungen?
• Sind Konzepte verknüpft?
• Ist das System nach Thema, Workflow, Zeit oder Eigentümerschaft organisiert?
• Kann ein Mensch es pflegen?
• Kann eine Maschine darauf basierend schlussfolgern?

Repräsentation ist keine Dekoration — sie bestimmt, welche Art von Operationen möglich sind.

Formen der Repräsentation

Dokumente

Dokumente sind die häufigste Form der Repräsentation. Beispiele sind:

• Artikel
• PDFs
• Handbücher
• Berichte
• README-Dateien
• Supportseiten
• Blog-Beiträge

Dokumente sind für Menschen leicht zu schreiben, aber sie sind oft schwer für Maschinen zu verwenden, da sie Fakten, Narrative, Kontext, Beispiele, Meinungen, veraltete Abschnitte und wiederholte Erklärungen in denselben Container mischen. Dokumente sind gute Container, aber sie sind nicht immer gute Wissensstrukturen.

Notizen

Notizen sind flexibler als Dokumente. Sie können sein:

• atomar
• verknüpft
• privat
• unfertig
• konzentriert auf Konzepte

Ein Notizsystem, wie ein PKM oder ein second brain, kann sich entwickelndes Wissen besser repräsentieren als ein poliertes Dokumentenarchiv. Gute Notizen erfassen Gedanken in der Entstehung; schlechte Notizen werden zu einer unsuchbaren Schublade für Unrat.

Wikis

Wikis repräsentieren Wissen als gepflegte Seiten. Ein gutes Wiki hat:

• stabile Seiten
• klare Themen
• interne Links
• Eigentümerschaft (Ownership)
• kanonische Antworten
• Aktualisierungsmuster

Ein Wiki ist stärker als ein loser Dokumentenstapel, weil es Wissen einen festen Platz gibt. „Deploy-Checkliste" lebt an einem Ort. „Incident Response" lebt an einem Ort. „RAG-Architektur" lebt an einem Ort. Das ist wichtig, weil der Abruf besser funktioniert, wenn Wissen eine stabile Struktur hat.

Wissensgraphen

Wissensgraphen repräsentieren Wissen als Entitäten und Beziehungen. Anstatt nur Text zu speichern, modellieren sie Dinge wie:

• Person arbeitet an Projekt
• Modell unterstützt ContextLength
• Seite hängt ab von Konzept
• Service verbindet sich mit Datenbank
• Tool implementiert Protokoll

Graphen sind mächtig, weil Beziehungen explizit werden, was bei Traversierung, Abhängigkeitsanalyse, Entitätsauflösung, Herkunft (Lineage), Schlussfolgerungen und Empfehlungen hilft. Aber Graphen sind teuer in der Wartung und sie sind kein Zauberstab — ein schlechter Graph ist nur strukturierte Verwirrung.

Schemata und Ontologien

Schemata definieren die erwartete Struktur; Ontologien gehen weiter und definieren Typen, Relationen und Einschränkungen. Sie beantworten:

• Welche Arten von Dingen existieren?
• Welche Eigenschaften haben sie?
• Wie können sie in Beziehung stehen?
• Welche Regeln gelten?

Das ist nützlich, wenn Korrektheit wichtig ist, wie z. B. bei medizinischem Wissen, juristischem Wissen, Enterprise-Datenkatalogen, Produkttaxonomien und Compliance-Systemen. Der Trade-off ist Steifheit: Je formeller die Repräsentation, desto teurer ist ihre Weiterentwicklung.

LLM-generierte Repräsentationen

Moderne Systeme verwenden zunehmend LLMs, um Repräsentationen zu erstellen. Beispiele sind:

• Zusammenfassungen
• extrahierte Entitäten
• Themenseiten
• Konzeptkarten
• synthetische FAQs
• Dokumentenübersichten
• Querverweise
• Glossareinträge

Hier positionieren sich Systeme im Stil von LLM Wiki. Sie verwenden das Modell nicht nur, um Abfragen zu beantworten, sondern um Wissen vor der Abfrage vorzubearbeiten und zu strukturieren. RAG sagt „rufe relevante Chunks zur Abfragezeit ab"; LLM Wiki sagt „kompiliere nützliche Wissensstrukturen zur Ingestionszeit". Beide Muster können in derselben Architektur koexistieren.

Was Abruf bedeutet

Abruf ist der Prozess des Findens relevanter Informationen. Zu den gängigen Abrufmethoden gehören:

• Stichwortsuche
• Volltextsuche
• Vektorsuche
• Hybrid-Suche
• Metadatenfilterung
• Graphentraversierung
• Reranking
• Query-Umschreibung (Query Rewriting)
• Agentische Suche

Abruf ist nicht nur eine Sache — es ist ein geschichteter Stack komplementärer Methoden.

Stichwortsuche

Stichwortsuche passt Begriffe und ist nach wie vor nützlich, da sie vorhersagbar, debugbar, schnell und gut für exakte Begriffe, IDs, Fehlermeldungen, Namen und Code ist. Ihre Schwäche ist die semantische Diskrepanz: Wenn der Benutzer nach „wie man wiederholte Antworten stoppt" sucht, das Dokument aber „presence penalty" sagt, kann die Stichwortsuche das beste Ergebnis verpassen.

Vektorsuche

Vektorsuche ruft nach semantischer Ähnlichkeit ab. Sie ist nützlich, wenn:

• die Wortwahl variiert
• Konzepte unscharf sind
• Benutzer Fragen in natürlicher Sprache stellen
• Dokumente inkonsistente Terminologie verwenden

Ihre Schwäche ist die Präzision — Vektorsuche kann Dinge abrufen, die sich ähnlich anfühlen, aber nicht tatsächlich korrekt sind, was besonders in technischen Systemen riskant ist.

Hybrid-Suche

Hybrid-Suche kombiniert Stichwort- und Vektorsuche, was oft besser ist als jede für sich allein. Stichwortsuche fängt exakte Treffer; Vektorsuche fängt konzeptionelle Treffer. Für technische Wissensdatenbanken ist hybride Retrievalüblicherweise ein starkes Standardverfahren.

Reranking

Reranking nimmt eine erste Menge abgerufener Ergebnisse und ordnet sie mit einem stärkeren Modell neu. Dies verbessert die Qualität, da der erste Abrufschritt oft breit angelegt ist. Ein typisches Muster ruft 50 Chunks auf, rerankt auf die besten 5 oder 10 und übergibt nur den besten Kontext an das LLM. Reranking ist eine der praktischsten Möglichkeiten, die RAG-Qualität zu verbessern.

Agentische Retrieval

Agentische Retrieval wandelt die Suche in einen Prozess um. Anstatt einer einzigen Abfrage kann ein Agent:

1. Eine initiale Frage stellen
2. Suchen
3. Ergebnisse inspizieren
4. Die Abfrage reformulieren
5. Erneut suchen
6. Quellen vergleichen
7. Eine Antwort synthetisieren

Das ist näher an Forschung als an Suche. Es ist nützlich für komplexe Fragen, aber es ist langsamer und schwerer zu kontrollieren.

Abruf ohne Repräsentation ist fragil

Ein Abrufsystem kann nur das abrufen, was existiert. Es kann nicht zuverlässig reparieren:

• unklare Konzepte
• doppelte Seiten
• inkonsistente Terminologie
• veraltete Dokumentation
• fehlende Quellen-Eigentümerschaft
• widersprüchliche Aussagen
• schwache interne Verlinkung
• schlechte Dokumentgrenzen

Das ist der häufigste Fehler in RAG-Projekten: Teams bauen eine Vektordatenbank und erwarten, dass sie zu einem Wissenssystem wird. Eine Vektordatenbank ist keine Wissensarchitektur — sie ist eine Zugriffsschicht.

Repräsentation ohne Abruf ist isoliert

Der umgekehrte Fehler existiert ebenfalls. Sie können eine wunderschön strukturierte Wissensdatenbank haben, die niemand finden kann. Das passiert bei:

• überdesignten Wikis
• tiefen Ordnerstrukturen
• starren Taxonomien
• schlecht indizierter Dokumentation
• privaten Notizsystemen ohne Entdeckbarkeit
• Graphen ohne nutzbare Schnittstellen

Repräsentation gibt Wissen Struktur; Abruf gibt Wissen Reichweite. Sie brauchen beides.

Die Trade-off-Karte

Geschwindigkeit vs. Kohärenz

Abruf ist schnell aufzubauen und Repräsentation braucht länger. Wenn Sie einen Prototyp benötigen, gewinnt der Abruf; wenn Sie langfristiges Vertrauen benötigen, ist Repräsentation wichtiger.

Ein reiner RAG-Prototyp kann schnell gebaut werden, aber ein zuverlässiges Wissenssystem erfordert Kuratierung.

Flexibilität vs. Konsistenz

Lockere Dokumente sind flexibel; strukturiertes Wissen ist konsistent. Flexibilität hilft, wenn:

• sich das Domänen schnell ändert
• das Wissen unvollständig ist
• Benutzer explorieren
• das System persönlich ist

Konsistenz hilft, wenn:

• mehrere Personen darauf angewiesen sind
• Antworten vertrauenswürdig sein müssen
• Workflows davon abhängen
• KI-Systeme es konsumieren

Je mehr Personen oder Agenten von Wissen abhängen, desto wichtiger wird die Repräsentation.

Recall vs. Präzision

Abrufsysteme optimieren oft zuerst den Recall, was bedeutet, alles zu finden, was möglicherweise relevant ist. Aber gute Antworten benötigen Präzision, was bedeutet, die besten Beweise zu finden, anstatt nur verwandte Beweise. Repräsentation verbessert die Präzision, indem sie Konzepte und Grenzen klarer macht — eine gut strukturierte Seite ist genauer abzurufen als ein zufälliger Absatz, der in einem langen Dokument begraben liegt.

Kosten zur Ingestionszeit vs. Kosten zur Abfragezeit

RAG schiebt die Arbeit meist zur Abfragezeit. Zur Abfragezeit:

• schreibt das System die Abfrage um
• ruft Chunks ab
• rerankt Ergebnisse
• stellt Kontext zusammen
• bittet das Modell, über Fragmente zu schlussfolgern

LLM Wiki-Systeme schieben mehr Arbeit zur Ingestionszeit. Zur Ingestionszeit:

• liest das System Quellen
• extrahiert Konzepte
• schreibt Zusammenfassungen
• erstellt Seiten
• verknüpft verwandte Ideen
• pflegt Struktur

Keines davon ist universell besser — sie optimieren unterschiedliche Kosten.

Warum LLM Wiki existiert

LLM Wiki existiert, weil Abruf allein oft Arbeit wiederholt. In einem normalen RAG-System kann jede Abfrage das Modell zwingen, rohe Fragmente erneut zu interpretieren:

1. Chunks über ein Thema abrufen
2. Das LLM bitten, das Konzept zu inferieren
3. Eine Antwort generieren
4. Die Synthese vergessen
5. Das nächste Mal wiederholen

LLM Wiki sagt:

Hören Sie auf, dieselbe Synthese immer wieder abzuleiten. Kompilieren Sie sie.

Anstatt nur rohe Dokumente zu speichern, erstellt es strukturierte Seiten, die Wissen zusammenfassen und verbinden, was Kohärenz, Wiederverwendung, Token-Effizienz, menschliche Lesbarkeit und langfristige Wartung verbessern kann. Aber es hat einen Kostenpunkt: Das System muss das Wiki pflegen, und wenn das Wiki falsch, veraltet oder halluziniert ist, wird die Struktur gefährlich.

RAG-Halluzination vs. schlechte Repräsentation

Menschen werfen dem LLM oft die Schuld, wenn ein RAG-System eine schlechte Antwort gibt, und manchmal ist das korrekt. Aber viele Fehler sind eigentlich Abruf- oder Repräsentationsfehler.

Ausfallmodus 1. Korrektes Dokument, falscher Chunk

Die Antwort existiert, aber Chunking teilt sie schlecht. Das Modell erhält:

• die Hälfte eines Absatzes
• fehlenden Kontext
• eine Tabelle ohne Erklärung
• eine Definition ohne Einschränkungen

Das LLM füllt diese Lücken, was wie Halluzination aussieht, aber das tiefere Problem ist eine gebrochene Repräsentation.

Ausfallmodus 2. Verwandter Chunk, falsche Antwort

Vektorsuche ruft etwas Semantisch Ähnliches, aber Operationell Falsches ab. Die Abfrage fragt nach der Produktionsbereitstellung; der abgerufene Chunk diskutiert die lokale Entwicklung. Die Begriffe überschneiden sich, aber die Bedeutung unterscheidet sich, also antwortet das Modell mit lokalen Setup-Anweisungen für ein Produktionsproblem. Das ist Abruf-Impräzision.

Ausfallmodus 3. Widersprüchliche Quellen

Zwei Dokumente widersprechen sich — eines alt, eines neu. Das Abrufsystem gibt beide zurück, und das LLM fusioniert sie zu einer selbstsicheren, aber ungültigen Antwort. Das ist nicht nur ein Abrufproblem, sondern ein Repräsentationsproblem, weil die Wissensdatenbank keinen kanonischen Zustand hat.

Ausfallmodus 4. Kein Konzeptmodell

Das System hat viele Dokumente, aber kein Modell der Domäne. Es weiß nicht, dass:

• „Agent Memory" sich von „RAG" unterscheidet
• „Wiki" sich von „PKM" unterscheidet
• „Embedding-Suche" sich von „Volltextsuche" unterscheidet
• „Deployment" sich von „Hosting" unterscheidet

Ohne konzeptionelle Repräsentation wird der Abruf zu einer unscharfen Übereinstimmung.

Ausfallmodus 5. Generierte Struktur wird zur falschen Autorität

LLM Wiki-Systeme haben ihren eigenen Ausfallmodus. Wenn ein LLM eine saubere Seite aus schlechten Quellen generiert, kann das Ergebnis autoritärer aussehen als das ursprüngliche Material. Das ist gefährlich: Eine polierte Halluzination ist schlimmer als ein unstrukturiertes Quelldokument. Jede generierte Repräsentation benötigt:

• Quellenlinks
• Überprüfung
• Aktualisierungsregeln
• Konfidenzmarker
• Eigentümerschaft

Designimplikationen

Optimieren Sie den Abruf, wenn das Korpus groß und dynamisch ist

Abruf sollte die Priorität sein, wenn:

• das Korpus riesig ist
• Dokumente sich häufig ändern
• Benutzer viele unvorhersehbare Fragen stellen
• Sie breite Abdeckung benötigen
• perfekte Struktur unrealistisch ist

Beispiele: Support-Wissensdatenbanken, Enterprise-Dokumentensuche, Forschungsassistenten, interner Chat über viele Dateien, Rechtsdurchsetzung und Kundenservice-Bots. In diesen Fällen investieren Sie in starken Abruf:

• Hybrid-Suche
• Metadatenfilter
• Reranking
• Query-Umschreibung
• Quellenzitation
• Evaluierungsmengen

Optimieren Sie die Repräsentation, wenn Kohärenz wichtig ist

Repräsentation sollte die Priorität sein, wenn:

• Wissen vertrauenswürdig sein muss
• Antworten konsistent sein müssen
• Konzepte oft wiederverwendet werden
• die Domäne eine klare Struktur hat
• mehrere Systeme davon abhängen

Beispiele: Architekturwissen, Produktdokumentation, Compliance-Regeln, API-Referenzen, operative Runbooks, kuratierte Forschungssammlungen und technische Blog-Cluster. In diesen Fällen investieren Sie in:

• kanonische Seiten
• Glossarbegriffe
• Diagramme
• interne Links
• Eigentümerschaft
• Versionierung
• Überprüfungsintervalle

Optimieren Sie beides, wenn KI-Systeme von Wissen abhängen

Wenn ein KI-Agent vom Wissen abhängt, reicht alleiniger Abruf normalerweise nicht aus. Agenten benötigen:

• stabilen Kontext
• klare Aufgabenregeln
• dauerhaften Speicher
• strukturierte Referenzen
• Quellenbegrenzungen
• Aktualisierungsverhalten

Für agentische Systeme wird Repräsentation Teil des Systemdesigns. Ein Coding-Agent muss nicht nur „einige Dokumente" abrufen — er muss wissen:

• Projekt-Konventionen
• Architektur-Entscheidungen
• Befehlsmuster
• verbotene Abhängigkeiten
• Test-Workflow
• Deployment-Regeln

Einige davon gehören in RAG, einige in den Speicher und einige in strukturierte Projektdokumentation.

Praktisches Entscheidungsframework

Wenn das Problem das Finden von Informationen ist

Optimieren Sie den Abruf. Beispiele:

• „Finde relevante Seiten."
• „Beantworte Fragen über Dokumente."
• „Suche über viele PDFs hinweg."
• „Finde ähnliche Support-Tickets."

Verwenden Sie:

• Volltextsuche
• Vektorsuche
• hybriden Abruf
• Reranking
• Metadatenfilterung

Wenn das Problem die Kohärenz von Wissen ist

Optimieren Sie die Repräsentation. Beispiele:

• „Erstelle eine kanonische Erklärung."
• „Löse doppelte Seiten auf."
• „Definiere das Domänenmodell."
• „Baue eine stabile Wissensdatenbank."

Verwenden Sie:

• Wiki-Seiten
• Konzeptkarten
• Taxonomien
• Wissensgraphen
• Zusammenfassungen
• Schemata

Wenn das Problem wiederholte Synthese ist

Verwenden Sie kompilierte Repräsentation. Beispiele:

• „Wir beantworten dieselben konzeptionellen Fragen wiederholt."
• „Das System fasst dieselben Quellen immer wieder zusammen."
• „Wir brauchen eine stabile Syntheseschicht."

Verwenden Sie:

• LLM Wiki
• kuratierte Zusammenfassungen
• Themenseiten
• von Menschen überprüfte generierte Seiten

Wenn das Problem adaptive Kontinuität ist

Verwenden Sie Speicher (Memory). Beispiele:

• „Der Agent sollte Benutzerpräferenzen merken."
• „Der Coding-Agent sollte Projekt-Konventionen merken."
• „Der Assistent sollte die Arbeit über Sitzungen hinweg fortsetzen."

Verwenden Sie:

• Agent-Memory
• Präferenzspeicher
• episodischer Speicher
• semantischer Speicher
• Projekt-Memory

Wie dies auf einen technischen Blog zutrifft

Ein technischer Blog kann mehr als eine Sequenz von Beiträgen sein — er kann zu einem repräsentierten Wissenssystem werden. Artikel sind Dokumente, Kategorien sind schwache Taxonomien, interne Links sind Graphen-Kanten, Pillar-Seiten sind kanonische Zusammenfassungen, Serien-Seiten sind kuratierte Wege und Suche ist Abruf. Wenn Sie nur isolierte Beiträge veröffentlichen, muss der Abruf härter arbeiten. Wenn Sie starke Repräsentation aufbauen, wird der Abruf einfacher.

Das bedeutet:

• klare Cluster-Grenzen
• stabile Slugs
• kanonische Seiten
• Vergleichsseiten
• Glossar-artige Erklärungen
• interne Links
• strukturierte Metadaten

Aus diesem Grund ist Site-Architektur wichtig — nicht nur für SEO, sondern weil es Wissensrepräsentation ist. Der Knowledge Management-Cluster auf dieser Site ist selbst ein Beispiel für repräsentationsorientierte Veröffentlichung.

Wie dies auf RAG zutrifft

Die RAG-Qualität hängt stark von der Repräsentation ab. Ein gut strukturierter Quellkorpus verbessert:

• Chunk-Qualität
• Abrufgenauigkeit
• Zitationsqualität
• Antwortkonsistenz
• Evaluierungsklarheit

Bevor Sie eine komplexe RAG-Pipeline bauen, fragen Sie:

1. Sind die Quelldokumente aktuell?
2. Sind Duplikate entfernt?
3. Sind wichtige Konzepte klar benannt?
4. Sind Seiten korrekt umgrenzt (scoped)?
5. Sind Tabellen und Code-Blöcke abgerufenbar?
6. Sind kanonische Antworten offensichtlich?
7. Sind Dokumentgrenzen sinnvoll?

Wenn die Antwort nein ist, werden bessere Embeddings nur so weit helfen.

Wie dies auf LLM Wiki zutrifft

LLM Wiki ist ein repräsentationsorientiertes Muster. Es ist nützlich, wenn:

• das Korpus klein oder mittelgroß ist
• das Wissen stabil genug ist, um zusammengefasst zu werden
• wiederholte Synthese teuer ist
• Menschen von lesbaren Seiten profitieren
• Sie Struktur vor dem Abruf wünschen

Es ist weniger nützlich, wenn:

• das Korpus massiv ist
• sich Inhalte ständig ändern
• Frische wichtiger ist als Kohärenz
• Governance schwach ist
• generierte Zusammenfassungen nicht überprüft werden können

LLM Wiki ist kein Ersatz für RAG, sondern eine andere Schicht, und ein starkes System kann beides verwenden:

1. LLM Wiki erstellt strukturierte Zusammenfassungen.
2. RAG ruft aus Rohquellen und Wiki-Seiten ab.
3. Menschliche Überprüfung hält die Repräsentation vertrauenswürdig.

Vorgeschlagene Architekturmuster

Muster 1. Abruf zuerst

Verwenden, wenn Geschwindigkeit wichtig ist.

dokumente
  -> chunks
  -> embeddings
  -> retrieval
  -> LLM antwort

Gut für:

• Prototypen
• breite Suche
• große Korpora
• frühe Experimente

Schwäche: Kohärenz hängt von der Quellqualität ab.

Muster 2. Repräsentation zuerst

Verwenden, wenn Vertrauen wichtig ist.

quellen
  -> kuratierte seiten
  -> interne links
  -> gepflegte wissensdatenbank
  -> suche oder rag

Gut für:

• Dokumentation
• technisches Wissen
• langfristige Inhalte
• Teamwissen

Schwäche: erfordert Wartung.

Muster 3. Kompiliertes Wissen

Verwenden, wenn wiederholte Synthese wichtig ist.

rohe quellen
  -> llm-extraktion
  -> generierte zusammenfassungen
  -> themenseiten
  -> überprüfte wissensdatenbank
  -> retrieval

Gut für:

• LLM Wiki-Systeme
• Forschungssammlungen
• persönliche Wissensdatenbanken
• stabile Domänen

Schwäche: generierte Struktur muss auditiert werden.

Muster 4. Hybride Wissensarchitektur

Verwenden, wenn Sie ernsthafte Systeme bauen.

rohe dokumente
  -> strukturierte wissensschicht
  -> suchindex
  -> retrieval und reranking
  -> ki-antwort
  -> feedback und wartung

Gut für:

• Produktions-RAG
• interne Wissenssysteme
• KI-Assistenten
• technische Publikationssysteme

Schwäche: mehr bewegliche Teile.

Evaluierungsfragen

Um den Abruf zu evaluieren, fragen Sie:

• Hat das System die richtige Quelle gefunden?
• Hat es die richtige Quelle hoch gerankt?
• Hat es genug Kontext abgerufen?
• Hat es irrelevanten Kontext vermieden?
• Hat die Antwort die korrekte Quelle zitiert?

Um die Repräsentation zu evaluieren, fragen Sie:

• Ist das Wissen klar strukturiert?
• Gibt es eine kanonische Seite?
• Sind Konzepte konsistent benannt?
• Sind Beziehungen explizit?
• Ist der Inhalt gepflegt?
• Können sowohl Menschen als auch Maschinen es verwenden?

Evaluieren Sie ein Wissenssystem nicht nur nach der Antwortqualität — eine gute Antwort kann eine schlechte Struktur verstecken.

Die opinionierte Regel

Wenn Ihr System gelegentlich fehlschlägt, verbessern Sie den Abruf. Wenn es wiederholt im selben konzeptionellen Bereich fehlschlägt, verbessern Sie die Repräsentation.

Schlechter Abruf verpasst die richtige Information. Schlechte Repräsentation bedeutet, dass die richtige Information nicht wirklich in einer nutzbaren Form existiert.

Fazit

Abruf und Repräsentation lösen unterschiedliche Probleme: Abruf gibt Zugang, Repräsentation gibt Struktur. RAG ist mächtig, weil es externes Wissen LLMs zur Abfragezeit verfügbar macht, aber RAG macht Wissen nicht automatisch kohärent, kanonisch oder gepflegt. Aus diesem Grund sind Wikis, PKM-Systeme, Wissensgraphen und Systeme im Stil von LLM Wiki nach wie vor wichtig.

Die Zukunft ist nicht Abruf gegen Repräsentation, sondern geschichtete Wissenssysteme:

• Repräsentation für Struktur
• Abruf für Zugang
• Speicher für Kontinuität
• Reasoning für Synthese

Wenn Sie ein ernsthaftes Wissenssystem bauen, beginnen Sie nicht mit der Vektordatenbank. Beginnen Sie mit der Form des Wissens, und entscheiden Sie dann, wie es abgerufen werden soll.

Quellen und weiterführende Literatur

• Google Cloud — Retrieval Augmented Generation
• AWS — What Is Retrieval Augmented Generation?
• IBM — Retrieval Augmented Generation
• IBM — Knowledge Management
• Atlan — LLM Wiki vs RAG Knowledge Base
• Dev.to — RAG vs Agent Memory vs LLM Wiki
• Starmorph — Karpathy LLM Wiki Knowledge Base Guide