Wissensarchitektur für Agenten – warum RAG keine Architektur ist

Anbinden ist nicht bereitstellen

Der übliche Weg, einem Agenten Firmenwissen zu geben, ist die Anbindung des Dokumentenspeichers: SharePoint oder Drive verbinden, Suche darüber, fertig. Anbinden ist aber nicht bereitstellen. In der Demo funktioniert dieser Aufbau zuverlässig, im Betrieb liefert dasselbe System falsche Antworten aus veralteten Dokumenten, und die Quellenangabe stimmt trotzdem, weil die zitierte Datei wirklich existiert.

Die Erklärung liegt im Testaufbau. Eine Demo testet ein anderes System als der Betrieb: Sie beweist, dass das Modell ein passend ausgewähltes Dokument lesen kann. Im Betrieb hängt die Antwort davon ab, was ein Retrieval-System aus tausenden Dokumenten auswählt.

Die drei Fragen einer Wissensarchitektur

RAG beantwortet also nur einen Teil des Problems. Eine Wissensarchitektur beantwortet drei Fragen, und RAG ist eine mögliche Antwort auf die dritte:

Für wen diese Lesson ist: Du baust oder planst ein System, in dem ein Agent mit eurem Wissen arbeiten soll. Ein Assistent auf der Wissensbasis, ein Second Brain, ein interner Chatbot. Danach kannst du die drei Ebenen auseinanderhalten, die Begriffe dahinter einordnen (von Vektordatenbank bis Knowledge Graph) und für jede Wissensart den passenden Zugriffsweg wählen.

Dateien sind die Quelle, der Index ist eine Ableitung

Die erste Architektur-Entscheidung ist die Ablageform. Die robusteste Antwort sind Dateien: Markdown oder Klartext, menschenlesbar, versionierbar und unabhängig von jedem Datenbanksystem. Diese Dateiablage ist die Source of Truth, der eine Ort, an dem der gültige Stand steht.

Die Vektordatenbank ist etwas anderes. Sie ist ein Suchindex, der aus deinen Dateien abgeleitet wird: Texte werden in Abschnitte zerlegt, über ein KI-Modell in Zahlenreihen übersetzt (Embeddings) und nach Ähnlichkeit durchsuchbar gemacht. Das ist schnell und mächtig. Aber es bleibt eine Ableitung, keine Quelle. Wer den Index zur Quelle erklärt, bekommt mit der Zeit mehrere konkurrierende Stände desselben Wissens, ohne dass einer davon als gültig markiert ist.

Geschnitten wird immer

Kein Kontextfenster fasst das gesamte Wissen einer Organisation. Irgendetwas zerlegt es also in Stücke. Die Frage ist nur, wer schneidet: ein Autor mit Verstand oder ein Algorithmus mit Zeichenzähler. Der Standard-Chunker schneidet nach Zeichenzahl, typischerweise um 500 Zeichen, ohne den Inhalt zu verstehen. Dadurch landen Regel und Ausnahme in getrennten Fetzen, und Sätze enden mittendrin.

Die Alternative heißt Wissenseinheit: ein Thema, eine Frage, allein verständlich. Sie ist klein genug, um ganz ins Kontextfenster zu passen, und groß genug, um die Frage vollständig zu beantworten. Damit ist die Einheit selbst der Chunk, und der Zeichenzähler hat nichts mehr zu schneiden. Der beste Chunker ist der Autor.

Was das bringt, ist messbar. In derselben Demo rankte die richtige Antwort auf eine Messe-Frage vorher auf Platz 8 von 9 und kam nie im Kontext an. Nach dem Neuschnitt stand sie auf Platz 2, sicher im Kontext, mit Regel und Ausnahme in einer Einheit, und die Antwort war korrekt. Geändert wurde dabei nur der Schnitt der Wissensbasis, nicht das Retrieval-System.

Metadaten: fünf Fragen, keine Ordnungsliebe

Bei Metadaten scheitern zwei Extreme regelmäßig. Die Notiz ohne Frontmatter zwingt den Agenten, alles zu lesen und zu raten, weil nichts filterbar ist. Der Metadaten-Friedhof mit 13 halb redundanten, halb ungepflegten Feldern beantwortet trotzdem nicht die Fragen, die im Betrieb tatsächlich gestellt werden. Das Prinzip dazwischen: Ein Feld gehört ins Frontmatter, wenn Agent oder Retrieval-Schicht seine Frage im Betrieb wirklich stellen.

Die Obergrenze setzen drei Tests. Pflegetest: Wird das Feld bei Änderungen zuverlässig aktualisiert? Nutzungstest: Filtert, routet oder priorisiert irgendetwas danach? Redundanztest: Steht die Information ohnehin im Inhalt? Fällt ein Feld durch, wird es gestrichen. Erweitert wird das Schema erst, wenn ein echter Retrieval-Fehler ein fehlendes Feld nachweist. Metadaten wachsen also aus beobachteten Fehlern, nicht aus Brainstormings.

Von der Hierarchie zum Netz

Metadaten beschreiben einzelne Einheiten. Für die Ordnung dazwischen gibt es zwei Denkmodelle. Das erste kennst du aus jedem Dateisystem: die Taxonomie, eine baumartige Hierarchie. IT, darunter Software, darunter KI, darunter LLM. Taxonomien sind vertraut und schnell aufgebaut, haben aber eine strukturelle Grenze: Wissen ist meist polyhierarchisch, ein Konzept gehört also in mehrere Kategorien zugleich. Bei komplexen Domänen wird der Baum dadurch starr.

Das zweite Modell geht weiter. Eine Ontologie erlaubt jede Art von Beziehung zwischen Konzepten, nicht nur über- und untergeordnet. Aus ihren Regeln entsteht ein Knowledge Graph: Knoten (Einheiten, Entitäten) und Kanten (Beziehungen wie „schreibt in“ oder „liest aus“). Der Agent kann dann Zusammenhängen folgen, statt nur Wörter abzugleichen.

Ein Knowledge Graph muss dabei kein Großprojekt sein. In der Praxis tragen vier Beziehungstypen im Frontmatter fast alles:

Der zweite Drive-Irrtum

Neben dem Drive-Irrtum aus dem Einstieg gibt es einen zweiten verbreiteten Fehler: alles Wissen über denselben Kanal. Glossar, Richtlinie, Preisliste und Organigramm werden gleichermaßen zerlegt, indexiert und durchsucht, obwohl sie unterschiedliche Zugriffsmuster brauchen. Die meisten RAG-Probleme sind in Wahrheit Wissen auf dem falschen Weg.

Weg 1 kommt ohne Retrieval aus: Glossar, Grundsätze und harte Verbote stehen dauerhaft im Kontext, etwa im Systemprompt. Jede Anfrage zahlt diese Tokens, dafür gibt es kein Retrieval-Risiko. Als Faustregel eignet sich für diesen Weg, was auf zwei Seiten passt und ein Jahr hält. Lange Dokumente vorsorglich mitzugeben verwässert dagegen nur die Aufmerksamkeit des Modells.

Finden lassen: was in RAG wirklich steckt

Hinter dem Sammelbegriff RAG stecken verschiedene Suchverfahren, und der Unterschied ist im Betrieb spürbar:

• Dense Retrieval (Vektorsuche): sucht nach semantischer Ähnlichkeit. Findet „Hund“, auch wenn im Text „Vierbeiner“ steht.
• Sparse Retrieval (Stichwortsuche, z.B. BM25): zählt exakte Worttreffer. Unverzichtbar für Eigennamen, IDs und Produktcodes, die die Vektorsuche verwischt.
• Hybrid Search mit Reranking: der heutige Standard. Beide Suchen laufen parallel, ein spezialisiertes Modell sortiert die Treffer neu, bevor sie ins Kontextfenster gehen.

Die Qualität entscheidet sich aber nicht im Suchverfahren, sondern in den Ebenen darunter. Erst filtern, dann ranken: Metadaten grenzen den Suchraum ein (status: final, gilt_bis nicht abgelaufen), so wird eine abgelaufene Fassung aussortiert, bevor das Ranking überhaupt beginnt. Einheiten statt Fetzen: Gefunden wird eine vollständige Antwort-Einheit, in der Regel und Ausnahme zusammen ankommen.

Navigieren lassen: Graph-RAG und der Agent als Leser

Manche Fragen sind keine Suchfragen. „Welche Projekte sind vom Ausfall von Server X betroffen?“ beantwortet kein Ähnlichkeits-Ranking. Graph-RAG folgt stattdessen den Kanten des Knowledge Graphs: Server X hostet Datenbank Y, die wird genutzt von Projekt Z. Geliefert wird exakt dieser Pfad. Diese Form ist stark, wenn die Verbindung selbst die Antwort ist, etwa bei Abhängigkeiten und Prozessketten.

Die zweite Spielart, Agentic RAG, braucht nicht einmal einen Graphen. Der Agent bekommt Werkzeuge (etwa über MCP) und arbeitet wie ein neuer Mitarbeiter, der sich einliest: Er öffnet Verzeichnisse, überfliegt Dateinamen und Frontmatter, liest gezielt und entscheidet dann, ob die Information reicht oder ob er weitersucht. Die Struktur der Wissensbasis dient ihm dabei als Karte. Der Unterschied zur Suche ist Vollständigkeit statt Top-k: Die Suche liefert die zehn ähnlichsten Stücke, ob sie reichen, bleibt offen. Die Navigation liefert alle verbundenen Einheiten und ist beendet, wenn keine Links mehr offen sind. Der Preis dafür sind längere Antwortzeiten und höherer Token-Verbrauch.

Nachschlagen lassen: exakt statt ähnlich

Eine Zahl, die sich ändert, hat in einem Chunk nichts verloren. Bei Preisen, Kilometersätzen, Lagerbeständen oder Ansprechpartnern veraltet der indexierte Stand schnell, wird aber weiter gefunden und mit korrekter Quellenangabe ausgeliefert. Der passende Weg führt über ein Tool: Der Agent holt den aktuellen Wert zur Antwortzeit aus der Datenbank oder per API, bei strukturierten Beständen auch als generierte Abfrage (Text-to-SQL). Das Ergebnis ist exakt statt ähnlich und zudem prüfbar, weil die Abfrage im Log steht. Die Wissensbasis verweist deshalb auf das Tool, statt die Zahl zu kopieren.

Wie die Ebenen ineinandergreifen

Jede Ebene arbeitet für die darüber. Der Schnitt entscheidet, ob eine vollständige Antwort überhaupt ankommen kann. Die Metadaten machen aus der Suche einen Filter und aus der Ablage ein begehbares Netz. Der Zugriff wählt pro Wissensart den Weg. Deshalb rettet kein Werkzeugkauf eine kaputte Ebene darunter: Ein Reranker repariert keinen blinden Schnitt, und Graph-RAG läuft ohne gepflegte Beziehungen ins Leere.

Gute Systeme kombinieren die Wege innerhalb einer einzigen Antwort. Die Frage nach den Gesamtkosten einer Messe-Reise etwa nutzt alle vier: Die Grundsätze waren mitgegeben, die Übernachtungsregel wird gefunden, die zugehörige Buchungs-Einheit über ihre Verweise navigiert und der aktuelle Kilometersatz nachgeschlagen.

Zwei Architekturen aus der Praxis

Mein eigenes Setup: Ein Obsidian-Vault aus Markdown-Dateien ist die Quelle, Frontmatter und Übersichtsnotizen (MOCs) sind die Ordnung. Der Zugriff läuft über MCP: Der Agent navigiert, überfliegt Frontmatter und folgt Links. Ein Vektor-Index kommt nicht vor, und das trägt, weil die Anforderungen dazu passen: ein einzelner Nutzer, explorative Fragen, stark vernetztes Wissen. Ich arbeite täglich in diesem Setup, und diese Lesson ist darin entstanden, aus neun verlinkten Wissenseinheiten.

Der Kundenservice-Chatbot: tausende Fragen am Tag, große Textbestände und Antwortzeiten unter einer Sekunde. Diese Anforderungen erfüllt nur ein Index: Hybrid-Suche mit Reranking über sauber geschnittene, per Metadaten gefilterte Einheiten. Die beiden unteren Ebenen bleiben dieselben wie im ersten Beispiel, nur der Zugriff darüber ändert sich.

Gebaut ist nicht fertig

Eine Wissensbasis ist kein Projekt mit Enddatum, sie ist Betrieb. gilt_bis ist kein Feld, sondern ein Wecker: Eine Abfrage über die Basis erzeugt die Prüfliste des Monats. Gescheiterte Fragen des Agenten sind keine Fehler, sondern die Einkaufsliste für neue Einheiten. Und ein Set aus 20 bis 50 echten Testfragen läuft vor jeder Änderung, wie Unit-Tests für Code. Ohne diese Routinen veraltet ein Teil der Basis unbemerkt und wird trotzdem weiter als gültige Quelle ausgeliefert. Eine ungepflegte Wissensbasis ist deshalb gefährlicher als keine. Wie du den Betrieb organisierst und wer Owner wird, vertieft die Lesson „Unternehmenswissen KI-ready machen“.

Das Modell auf einen Blick

Die vier Regeln

Sätze zum Mitnehmen

• Anbinden ist nicht bereitstellen.
• RAG stoppt Halluzinationen nicht. Es gibt ihnen Quellenangaben.
• Ähnlichkeit kennt keine Gültigkeit.
• Falsche Metadaten sind Lügen mit Autorität.
• Eine ungepflegte Wissensbasis ist gefährlicher als keine.

Wie es weitergeht