1
Quellen und Admin-Ebene
Die Architektur startet bei PDFs, Bildern, Textdateien, Markdown und kontrollierten Upload- oder Bucket-Sync-Prozessen. Entscheidend ist, dass Quellen eindeutig identifizierbar bleiben.
Enterprise RAG
RAG Architektur für sichere Enterprise Wissenssysteme
Diese Referenzarchitektur zeigt, wie Retrieval Augmented Generation in Unternehmen belastbar umgesetzt wird: Dokumente werden deterministisch verarbeitet, versioniert gespeichert und für Agenten ausschließlich read-only über Retrieval-APIs und MCP bereitgestellt.
Was ist eine RAG Architektur?
Eine RAG Architektur beschreibt den technischen Aufbau, mit dem ein KI-System Antworten aus geprüften Unternehmensquellen ableitet, statt ausschließlich aus Modellwissen zu generieren.
Im Kern verbindet Retrieval Augmented Generation eine kontrollierte Dokumentenaufnahme, einen zentralen Knowledge Store, einen semantischen Suchindex und eine Retrieval-Schicht für Anwendungen, Chatbots oder Agenten. Für Enterprise-Anwendungen reicht eine Vektordatenbank allein nicht aus: Versionierung, Quellenangaben, Berechtigungen, Reindex-Jobs und ein read-only Zugriffspfad müssen als Architekturentscheidungen geplant werden.
- Primäre Suchintention
- RAG Architektur für Unternehmen verstehen
- Zielsystem
- sichere KI Wissenssysteme mit Quellen und Berechtigungen
- Kernprinzip
- Ingestion schreibt, Retrieval liest, Agenten ändern keine Wissensbasis
Agenten haben keinen direkten Schreibzugriff auf Datenbank oder Objektspeicher.
Diagramm in neuem Tab öffnenKomponenten einer Enterprise RAG Architektur
Das Diagramm verdichtet die Architektur visuell. Für Entscheider, Fachbereiche und technische Teams ist die gleiche Struktur hier zusätzlich als klarer Architekturüberblick beschrieben.
2
Ingestion Worker
Der Worker extrahiert Text und Seitenbilder, normalisiert Inhalte, bildet Chunks, erzeugt Hashes, erstellt Embeddings und stößt kontrollierte Reindex-Jobs an.
3
Knowledge Store
Objektspeicher und PostgreSQL mit pgvector halten Originaldateien, Previews, Metadaten, Dokumentversionen, Chunks, Embeddings und Zugriffsinformationen zusammen.
4
Retrieval Layer
Eine RAG API und ein MCP Server stellen semantische Suche, Dokument-Lookups, Chunk-Kontext, Quellenangaben, Filter und Berechtigungen bereit.
5
Agent Clients und Modellruntime
Clients wie Codex, Claude oder Open Harness greifen nur auf read-only Tools zu. Modelle können self-hosted oder als Cloud LLM betrieben werden, ohne direkten Datenbankzugriff zu erhalten.
6
Betrieb und Compliance
Kubernetes, starkAI Cloud, DSGVO-Konformität, EU AI Act Readiness und ISO-27001-nahe Kontrollen gehören zum Betriebsmodell, nicht zu einer späteren Zusatzschicht.
Warum diese Struktur trägt
Die Architektur trennt Aufnahme, Speicherung, Retrieval und Modellnutzung bewusst. Dadurch bleiben Quellen nachvollziehbar, Berechtigungen prüfbar und Agenten im produktiven Betrieb kontrollierbar.
Deterministische Ingestion
PDFs, Bilder und Markdown werden normalisiert, gehasht, versioniert und wiederholbar indexiert. Reindex-Jobs sind kontrolliert statt implizit.
Zentraler Knowledge Store
Originaldateien, Previews, Metadaten, Dokumentversionen, Chunks und Embeddings bleiben in einer klaren Speicher- und Indexschicht zusammengeführt.
Read-only Retrieval
Agenten greifen über RAG API und MCP Tools zu. Direkte Schreibrechte auf Datenbank oder Storage sind nicht Teil des Client-Pfads.
Wann lohnt sich diese RAG Architektur?
Eine Enterprise RAG Architektur lohnt sich, wenn Wissen nicht nur durchsucht, sondern prüfbar, wiederholbar und mit klaren Verantwortlichkeiten genutzt werden soll.
Interne Wissenssysteme
Mitarbeitende sollen Richtlinien, Projektdokumente, Handbücher oder Prozesswissen per Suche und Chat finden, ohne die Quelle aus den Augen zu verlieren.
Dokumentenintensive Prozesse
Verträge, Rechnungen, Frachtpapiere, technische Spezifikationen oder Angebotsunterlagen sollen strukturiert aufgenommen und wiederverwendbar gemacht werden.
Agenten mit kontrolliertem Zugriff
KI-Agenten sollen Wissen nutzen, aber keine Datenbank- oder Storage-Schreibrechte besitzen. Retrieval wird zur kontrollierten Schnittstelle zwischen Agent und Wissen.
Regulierte Organisationen
Wenn Datenschutz, Auditierbarkeit, Mandantenfähigkeit, Quellenbelege und Versionshistorie relevant sind, muss die RAG Architektur diese Anforderungen von Beginn an tragen.
Verwandte Themen und nächste Vertiefung
Eine Pillar Page sollte nicht isoliert stehen. Diese Seiten vertiefen die wichtigsten Suchintentionen rund um Unternehmenswissen, Dokumentenverarbeitung und KI-Befähigung.
AI WissenssystemWie die RAG Architektur als Such- und Chat-Oberfläche für internes Unternehmenswissen produktiv wird.AI DokumentenanalyseWie unstrukturierte Dokumente vor der Indexierung extrahiert, klassifiziert und validiert werden.AI AcademyWie Teams lernen, mit Retrieval, Quellen, Prompts und KI-Wissenssystemen zuverlässig zu arbeiten.
Häufige Fragen zur RAG Architektur
Diese Antworten decken typische Fragen ab, die vor dem Aufbau eines Enterprise RAG Systems geklärt werden sollten.
Was ist der Unterschied zwischen RAG und einer Vektordatenbank?
Eine Vektordatenbank ist nur ein Baustein. Eine RAG Architektur umfasst zusätzlich Ingestion, Chunking, Metadaten, Berechtigungen, Quellenangaben, Retrieval-APIs, MCP Tools, Modellzugriff und Betriebsprozesse.
Warum ist deterministische Ingestion wichtig?
Deterministische Ingestion sorgt dafür, dass Dokumente bei wiederholter Verarbeitung nachvollziehbar versioniert, gehasht und indexiert werden. Das ist entscheidend für Audits, Fehlersuche und verlässliche Aktualisierungen.
Welche Rolle spielt MCP in einer RAG Architektur?
MCP stellt agentenfähige Tools bereit, zum Beispiel semantische Suche, Dokument-Lookup oder Chunk-Kontext. Dadurch können Agent Clients Wissen nutzen, ohne direkten Zugriff auf Datenbank oder Objektspeicher zu erhalten.
Welche Daten gehören in den Knowledge Store?
Neben den Embeddings sollten Originaldateien, Seitenvorschauen, extrahierte Assets, Dokumentversionen, Metadaten, Zugriffsinformationen und die erzeugten Chunks gespeichert werden.
Kann die Architektur mit Cloud LLMs und self-hosted Modellen arbeiten?
Ja. Die Retrieval-Schicht entkoppelt Wissenszugriff und Modellruntime. Dadurch können self-hosted Modelle, Cloud LLMs oder hybride Setups genutzt werden, ohne den Zugriffspfad auf Unternehmensdaten zu verändern.
RAG Architektur für Ihr Wissenssystem planen
stark AI übersetzt verteilte Dokumente, Berechtigungen und operative Anforderungen in eine belastbare RAG Zielarchitektur mit Ingestion, Knowledge Store, Retrieval und Betriebsmodell.