DMS mit RAG verbinden: Architektur, Rechte & Versionen

Ein DMS ist keine Dateiablage. Es ist das fachliche System für Verträge, technische Dokumentation und Richtlinien – mit Identität, Versionen, Status, Metadaten und Berechtigungen.

Das DMS bleibt die Source of Truth. Ein Retrieval-Index ist eine abgeleitete Struktur, keine zweite Dokumentwahrheit.

Die schwierige Aufgabe ist daher nicht, Dokumente in einen Suchindex zu importieren. Entscheidend ist, dass Dokumentidentität, Versionen, Metadaten, Berechtigungen, Deletes und Herkunft über den gesamten Lifecycle korrekt erhalten bleiben. Sonst zitiert eine Unternehmensanwendung vielleicht einen alten Vertrag, eine zurückgezogene Richtlinie oder einen Chunk, den der aktuelle Nutzer nie hätte sehen dürfen.

Die direkte Antwort

Ein produktives DMS-RAG behandelt jeden Chunk als nachvollziehbare Ableitung eines konkreten DMS-Objekts: mit fachlicher Identität, Version, Status, Gültigkeit, ACL und Rücksprung zur Quelle. Der Index beschleunigt Retrieval. Er entscheidet aber nicht selbst, welches Dokument gültig ist oder wer es sehen darf.

Das ist besonders wichtig, wenn eine bestehende Unternehmensanwendung gleichzeitig Verträge, technische Handbücher und Richtlinien durchsucht. Ein Vertrag kann ersetzt, eine technische Anleitung aktualisiert und eine Richtlinie archiviert werden – ohne dass die Anwendung widersprüchliche Evidenz liefern darf.

Warum „exportieren und embedden“ nicht reicht

Ein einmaliger PDF-Export verliert leicht genau die Semantik, die im DMS fachlich zählt: Ein Dateiname ändert sich, ein Dokument wird verschoben, eine neue Version wird freigegeben, eine Gruppe verliert Zugriff oder ein Objekt wird gelöscht.

Wird derselbe Export erneut indexiert, entstehen ohne stabile Zuordnung Dubletten und Zombie-Versionen. Der Index enthält dann zwar Text, aber keine verlässliche Antwort darauf, welche Fassung aktuell, zulässig oder überhaupt noch vorhanden ist.

Ein Retrieval-Index darf nicht zur zweiten Dokumentwahrheit werden.

Das ist ein Datenvertrag zwischen DMS, Ingestion und Retrieval, kein Embedding-Thema. Die übergreifende Grundlage behandelt RAG-Datenquellen anbinden.

Source of Truth und Canonical Identity

URL und Dateiname sind nützliche Attribute, aber keine ausreichende Identität: Ein Vertrag kann umbenannt oder in einen anderen Bereich verschoben werden, ohne fachlich ein neues Dokument zu sein.

Zu jedem Chunk gehört außerdem Provenance: Quelle, Quelllink, Dokument- und Version-ID, Zeitstand sowie möglichst Seite oder Abschnitt. So kann die Anwendung eine Antwort bis zum Original zurückverfolgen und ein Rebuild den gleichen fachlichen Zusammenhang wiederherstellen.

Versionierung ist Retrieval-Logik

Nehmen wir eine Reisekostenrichtlinie: Version 7 ist archiviert, Version 8 ersetzt, Version 9 freigegeben und ab einem bestimmten Datum gültig. Wenn alle Fassungen parallel im Index bleiben, kann Retrieval widersprüchliche Evidenz liefern – selbst wenn Version 9 einen ähnlichen Titel hat.

Versionierung muss im Retrieval-Modell explizit sein; „neueste Datei gewinnt“ reicht nicht immer. Relevant sind mindestens Version, Status sowie gültig-ab und gültig-bis. Entwürfe, veröffentlichte Versionen, ersetzte Fassungen und Archivversionen brauchen eine definierte Retrieval-Wirkung.

Beispielsweise kann eine Anwendung nur veröffentlichte und aktuell gültige Richtlinien zitieren, während ein berechtigtes Fachteam Archivfassungen bewusst recherchieren darf. Diese Entscheidung liegt in der fachlichen Regel – nicht im Similarity Score.

Metadaten sind Retrieval-Regeln

Metadaten dienen nicht nur als Filter oder Anzeigeinformation. Sie definieren oft, welche Evidenz für eine Frage überhaupt zulässig und passend ist.

Bei Verträgen, technischen Dokumenten und Richtlinien sind typischerweise relevant:

• Dokumenttyp,
• Status,
• Mandant oder Organisation,
• Gültigkeitszeitraum,
• Sprache,
• Klassifikation,
• Quelle,
• Version,
• Zugriffsmodell.

Die Frage nach der „aktuellen technischen Richtlinie für Mandant A auf Deutsch“ ist nicht nur eine semantische Suche. Dokumenttyp, Mandant, Sprache, Status und Gültigkeit begrenzen den zulässigen Suchraum. Metadaten müssen deshalb mit Identität und Version bis in den Retrieval-Pfad erhalten bleiben.

Exakte Vertragsnummern, Produktcodes und Richtliniennamen können zusätzlich ein lexikalisches Signal brauchen. Ob Hybrid Search vs. Vector Search dafür messbar hilft, sollte gegen reale Fragen geprüft werden.

Berechtigungen: ACLs vor dem Prompt

Ein DMS bringt Benutzer-, Gruppen-, Rollen-, Ordner- oder Mandantenrechte mit. Diese ACLs müssen in den Retrieval-Pfad übernommen werden – entweder nahe an der Quelle oder als kontrolliert replizierte Sicherheitsmetadaten im eigenen Index.

Eine Berechtigungsänderung ist ein eigenes Lifecycle-Event, auch wenn sich kein Zeichen im Dokument verändert. Security Trimming muss den aktuellen Nutzerkontext anwenden, bevor Kandidaten in Context Assembly oder Prompt gelangen. Nicht autorisierte Chunks dürfen das Modell nie erreichen.

Die konkrete Gestaltung von ACL-Mapping, Revocation und Pre-Filtering vertieft RAG-Berechtigungen & Security Trimming.

Deletes, Archive und Restore brauchen unterschiedliche Folgen

„Nicht mehr im DMS sichtbar“ ist kein ausreichender technischer Zustand. Retrieval braucht eine explizite Wirkung pro Lifecycle-Ereignis:

Delete Propagation ist damit keine Aufräumarbeit. Bleibt ein gelöschter Vertrag oder eine entzogene Richtlinie im Index abrufbar, ist die Retrieval-Schicht fachlich und sicherheitlich falsch.

Parsing und Normalisierung folgen erst danach

Erst wenn Identität und Lifecycle klar sind, wird aus dem konkreten DMS-Objekt belastbarer Retrieval-Inhalt. PDFs, Office-Dokumente, Scans und Tabellen können beim Parsing Überschriften, Spaltenbeziehungen, Seitenbezüge oder Zahlen verlieren. OCR kann Produktcodes verfälschen; wiederkehrende Kopf- und Fußzeilen können jeden Chunk dominieren.

Normalisierung hält extrahierten Text, Struktur und die fachlichen Metadaten zusammen. Erst danach ist klar, welche Abschnitte sinnvoll gechunkt werden und welcher Dokumentversion sie gehören. Für die Chunking-Stufe siehe RAG Chunking Strategien.

DMS-RAG: Lifecycle vor Indexierung

1. 01

   DMS

   Verträge, technische Dokumentation und Richtlinien als fachliche Source of Truth

2. 02

   Identity / Version / ACL Mapping

   Source-native und canonical IDs, Status, Gültigkeit, Provenance sowie effektive Rechte zuordnen

3. 03

   Parsing / Normalization

   Text, Tabellen, Struktur und fachliche Metadaten kontrolliert aus dem konkreten DMS-Objekt ableiten

4. 04

   Chunking

   Eindeutige, versionierte und aktualisierbare Abschnitte erzeugen

5. 05

   Search Index

   Abgeleitete Retrieval-Struktur, die reproduzierbar aus dem DMS aufgebaut werden kann

6. 06

   ACL-aware Retrieval

   Security Trimming vor Context Assembly; nur zulässige, aktuelle Evidenz auswählen

7. 07

   Application / LLM

   Bestehende Unternehmensanwendung antwortet mit nachvollziehbarer Quelle und Version

Remote Retrieval oder replizierter Index

Remote Retrieval ist sinnvoll, wenn DMS-Suche und API die relevanten Fragen ausreichend beantworten, Rechte und Freshness nahe an der Quelle bleiben sollen und Datenreplikation minimiert werden soll. Dann übernimmt das DMS mehr Verantwortung im Query-Pfad.

Ein eigener Index ist sinnvoll, wenn mehrere Quellen zusammengeführt werden, Hybrid Search oder Reranking nötig sind, eigene Normalisierung und Chunking-Logik einen messbaren Nutzen haben oder Suchqualität aktiv optimiert werden soll. Dann übernimmt die Retrieval-Schicht aber auch die Verantwortung für Synchronisierung, ACL-Updates, Deletes und Staleness.

Die ähnliche Entscheidung für Microsoft 365 behandelt SharePoint an RAG anbinden. Ein eigener Index ist kein Default; er muss den zusätzlichen Lifecycle-Aufwand rechtfertigen.

Production Readiness: überprüfbare Invarianten

Ein DMS-RAG ist production-ready, wenn diese Aussagen im Betrieb nachweisbar gelten:

• Retrieval liefert keine veraltete oder unzulässige Version als aktuelle Evidenz.
• Deletes, Archive, Restore und Permission Changes erreichen alle betroffenen Chunks kontrolliert.
• Jede Antwortquelle lässt sich auf DMS-Objekt, Version und Abschnitt zurückführen.
• Der Index kann reproduzierbar aus dem DMS neu aufgebaut werden, ohne eine eigene Fachwahrheit zu benötigen.
• Sync-Fehler, fehlende Events und Staleness sind beobachtbar statt unsichtbar.
• Reale Testfälle prüfen Version, Rechte, gelöschte Inhalte, OCR und Quellenbezug gemeinsam.

Die Testmethodik dafür beschreibt RAG Evaluation: Metriken, Golden Dataset & Regression Tests.

Architecture View

Ich würde ein DMS nicht als Dateiablage behandeln, sondern als fachliches System mit Identität, Versionen, Status, Metadaten und Berechtigungen. Diese Semantik muss in der Retrieval-Schicht erhalten bleiben.

Wenn der Index nicht zuverlässig weiß, welche Version gültig ist, was gelöscht wurde und wer etwas sehen darf, ist das System nicht production-ready – unabhängig von der Qualität des Embedding-Modells.

Wenn DMS-Lifecycle und Retrieval für eine bestehende Anwendung konkret geplant oder umgesetzt werden sollen, ist RAG-Implementierung & KI-Integration der passende Einstieg.