RAG-System On-Premise: Vorteile und Implementierungsstrategien

Datenschutz und Datenhoheit durch lokalen Betrieb

Ein RAG-System On-Premise hält Dokumente, Suchdaten und Modellanfragen innerhalb der eigenen IT-Umgebung. Für Unternehmen bedeutet das vor allem: Sensible Inhalte verlassen das kontrollierte Netzwerk nicht. Das senkt Abhängigkeiten von externen Diensten und schafft eine klare Grundlage für interne Datenschutzprozesse.

Bei einer lokalen Bereitstellung kann das Unternehmen selbst festlegen, wo Daten verarbeitet werden, wie lange sie gespeichert bleiben und wer technische Zugriffe erhält. Diese Kontrolle ist besonders wichtig, wenn Vertragsunterlagen, Patientendaten, Finanzinformationen oder interne Forschungsdaten verarbeitet werden.

Auch Zwischendaten verdienen Aufmerksamkeit. Protokolle, temporäre Dateien, Suchanfragen und Modellkontexte können vertrauliche Informationen enthalten. Eine belastbare Lösung muss deshalb nicht nur die fertige Antwort schützen, sondern auch Datenreste nach der Verarbeitung löschen, Diagnoseprotokolle begrenzen und administrative Zugriffe nachvollziehbar dokumentieren.

Für abgeschottete Netze oder Air-Gap-Umgebungen gelten zusätzliche Regeln. Modelle, Container und Sicherheitsupdates müssen vorab geprüft, signiert und über einen kontrollierten Transfer eingebracht werden. Andernfalls läuft die Anwendung zwar lokal, doch ein Modellpaket oder Hilfsdienst kann aus einer ungeprüften Quelle stammen.

Rechtlich bleibt der lokale Betrieb eine technische Maßnahme und ersetzt keine Datenschutzorganisation. Die Datenschutz-Grundverordnung verlangt unter anderem Zweckbindung, Datenminimierung und angemessene Schutzmaßnahmen. Bei personenbezogenen Daten sollten Unternehmen vor dem Produktivbetrieb prüfen, welche Datenklassen verarbeitet werden, ob eine Datenschutz-Folgenabschätzung nötig ist und wie Löschfristen umgesetzt werden.

Seit dem 2. August 2026 gelten zentrale Pflichten des EU AI Act für viele Anbieter und Betreiber von KI-Systemen. Die genaue Einordnung hängt vom Einsatzfall und vom Risiko ab. Ein On-Premise-Betrieb befreit daher nicht von Anforderungen an Dokumentation, Risikomanagement oder Transparenz. Bei Antworten mit generierten Inhalten kann zudem eine erkennbare Kennzeichnung erforderlich sein.

Ein praktischer Kontrollpunkt ist die Datenflusskarte. Sie sollte für jede Anfrage zeigen:

• welche Quelle den Inhalt liefert,
• welche internen Dienste ihn verarbeiten,
• welche Kopien vorübergehend entstehen,
• welche Protokolle gespeichert werden und
• wann sämtliche Daten wieder gelöscht werden.

So wird aus dem Schlagwort Datenhoheit ein prüfbarer Prozess. Der eigentliche Wert eines lokalen RAG-Systems liegt darin, dass nicht nur das Modell im eigenen Rechenzentrum steht, sondern die gesamte Verarbeitung unter der Verantwortung des Unternehmens bleibt.

Architektur mit getrennten RAG-Komponenten

Eine belastbare On-Premise-RAG-Architektur trennt Datenfluss, Suche, Modellzugriff und Benutzeroberfläche. Jede Komponente besitzt eine klar definierte Aufgabe. Dadurch lassen sich Fehler leichter eingrenzen und einzelne Teile ändern, ohne die gesamte Anwendung neu zu bauen.

Im Kern empfiehlt sich ein Diensteschnitt mit fünf Ebenen: Quellenverwaltung, Aufbereitung, Indexzugriff, Antwortorchestrierung und Präsentation. Die Ebenen kommunizieren über versionierte Schnittstellen. So bleibt nachvollziehbar, welche Daten ein Dienst erwartet und welches Ergebnis er liefert.

Die Quellenverwaltung übernimmt Import, Versionierung und Statusführung. Sie sollte nicht selbst über Suchtreffer entscheiden, sondern neue oder geänderte Dateien an die Aufbereitung übergeben. Für jedes Objekt sind eine eindeutige Kennung, eine Versionsnummer und ein Änderungszeitpunkt sinnvoll. Das verhindert, dass alte Vektoren nach einer Dokumentänderung unbemerkt weiterverwendet werden.

Die Aufbereitung erzeugt aus Rohmaterial eine stabile interne Darstellung. Textabschnitte, Seitenbezüge, Tabellenverweise und Dokumentversionen werden getrennt gespeichert. Ein Abschnitt sollte seine Herkunft bis zur Originalseite zurückverfolgen können. Diese sogenannte Provenienz erleichtert Belege, Fehleranalysen und gezielte Aktualisierungen.

Der Indexzugriff sollte zwei Sucharten zusammenführen: exakte Begriffe und semantische Nähe. Eine reine Vektorsuche übersieht manchmal Produktnummern, Gesetzesparagrafen oder interne Abkürzungen. Eine reine Stichwortsuche verfehlt dagegen sinngleiche Formulierungen. Ein hybrides Verfahren liefert meist die robustere Basis für die nachgelagerte Auswahl.

Die Antwortorchestrierung übernimmt eine zentrale Kontrollfunktion. Sie entscheidet, wie viele Treffer an das Sprachmodell weitergegeben werden, entfernt doppelte Passagen und begrenzt den Kontext auf ein vorher festgelegtes Budget. Außerdem kann sie Antworten ohne ausreichende Beleglage ablehnen. Das ist oft besser als eine elegant formulierte Vermutung.

Für die Kommunikation eignen sich klar versionierte API-Verträge. Ein Suchdienst sollte zum Beispiel neben dem Text auch Dokument-ID, Seitenangabe, Relevanzwert und Aktualitätsstand liefern. Fehlen diese Felder, wird die spätere Quellenanzeige unnötig mühsam.

• Jeder Dienst besitzt ein eigenes Verantwortungsgebiet.
• Datenobjekte erhalten stabile IDs und Versionsnummern.
• Fehler werden über Statuswerte und wiederholbare Aufträge sichtbar.
• Schnittstellen bleiben unabhängig von internen Modellwechseln.
• Antworten behalten den Bezug zu ihren Quellpassagen.

Ein solcher Zuschnitt schafft Austauschbarkeit. Ein neues Sprachmodell muss nicht den Suchdienst verändern. Ein anderer Index kann erprobt werden, während die Benutzeroberfläche gleich bleibt. Diese Entkopplung schützt langfristige Investitionen und verhindert, dass ein einzelner Anbieter oder ein einzelnes Modell zum technischen Flaschenhals wird.

Vorteile und zentrale Umsetzungsaspekte eines lokalen RAG-Systems

Dokumentenaufnahme als zentrale Leistungsstufe

Die Dokumentenaufnahme entscheidet oft darüber, ob ein RAG-System später verlässlich arbeitet. Fehler in dieser frühen Stufe wandern weiter: Ein falsch erkannter Tabellenwert, eine fehlende Fußnote oder eine verdrehte Seitenfolge kann die spätere Antwort verfälschen. Darum sollte die Aufnahme nicht als simples Hochladen von Dateien behandelt werden.

Am Anfang steht eine Bestandsprüfung. Das System erkennt Dateityp, Zeichencodierung, Seitenzahl, Sprache und mögliche Duplikate. Auch beschädigte Dateien müssen einen klaren Status erhalten. Eine Datei, die nur teilweise gelesen wurde, darf nicht stillschweigend als vollständig verarbeitet gelten.

Bei PDF-Dateien ist die Unterscheidung zwischen Text-PDF und Scan besonders wichtig. Text-PDFs lassen sich meist direkt auslesen. Scans benötigen dagegen OCR. Für gute Ergebnisse müssen Erkennungsfehler, gedrehte Seiten, mehrspaltige Layouts und handschriftliche Ergänzungen berücksichtigt werden. Eine reine Textextraktion reicht hier nicht aus.

Tabellen erfordern eine eigene Behandlung. Werden Zeilen und Spalten einfach in Fließtext umgewandelt, geht ihre Bedeutung schnell verloren. Besser ist eine strukturierte Darstellung, die Überschriften, Zellbeziehungen und Seitenpositionen bewahrt. Auch Kopf- und Fußzeilen sollten erkannt werden, damit sie nicht als falscher Inhalt in jedem Abschnitt auftauchen.

Beim Segmentieren zählt nicht nur die Zeichenanzahl. Ein Abschnitt sollte inhaltlich geschlossen bleiben. Überschrift, Definition und zugehörige Einschränkung gehören möglichst zusammen. Zu kleine Einheiten verlieren den Zusammenhang; zu große Einheiten erschweren später die Auswahl. Überlappungen von etwa 10 bis 20 Prozent können helfen, Übergänge zwischen Abschnitten zu erhalten.

Jeder erzeugte Abschnitt braucht eine nachvollziehbare Herkunft. Sinnvolle Felder sind beispielsweise:

• Dokumentkennung und Dokumentversion
• Seiten- oder Abschnittsnummer
• erkannter Dateityp und Sprache
• Extraktionsmethode
• Zeitpunkt der Verarbeitung
• Qualitätsstatus der Erkennung

Eine robuste Aufnahme verarbeitet Änderungen zudem inkrementell. Wird nur eine Datei ersetzt, sollten nicht automatisch alle Dokumente erneut bearbeitet werden. Dafür vergleicht das System Prüfsummen oder Versionskennungen. Unveränderte Inhalte bleiben bestehen, während betroffene Abschnitte gezielt aktualisiert werden.

Besonders praktisch ist ein Fehlerkanal für problematische Dateien. Dokumente mit niedriger OCR-Qualität, fehlenden Seiten oder widersprüchlichen Metadaten landen dort zur Nachbearbeitung. So verhindert die Pipeline, dass zweifelhafte Inhalte unbemerkt in den Wissensbestand gelangen.

Für die Planung sollten Unternehmen eigene Aufnahmeprofile definieren. Ein Profil für Verträge braucht andere Regeln als eines für technische Zeichnungen oder gescannte Akten. Diese Spezialisierung erhöht die Genauigkeit und macht die Ergebnisse messbarer, weil jede Dokumentklasse nach passenden Kriterien bewertet wird.

Asynchrone Microservices für große Datenmengen

Asynchrone Microservices verhindern, dass ein langsamer Verarbeitungsschritt die gesamte Dokumentaufnahme blockiert. Jeder Auftrag wird in eine Warteschlange gestellt und erst dann bearbeitet, wenn ein passender Worker verfügbar ist. Das schafft einen gleichmäßigen Datenfluss, auch wenn viele Dateien gleichzeitig eintreffen.

Für große Bestände eignet sich eine Pipeline mit klaren Statuswechseln: eingegangen, in Bearbeitung, wartet, erfolgreich oder fehlgeschlagen. Ein Auftrag bleibt dadurch nachvollziehbar. Bricht ein Worker ab, muss nicht der komplette Lauf neu beginnen. Nur der betroffene Schritt wird wiederholt.

Wichtig ist eine dauerhaft speichernde Warteschlange. Flüchtige Nachrichten gehen bei einem Neustart verloren und führen zu Lücken im Datenbestand. Jede Aufgabe sollte außerdem eine eindeutige Kennung, eine maximale Wiederholungszahl und eine Fehlerursache besitzen. Nach mehreren Fehlversuchen wandert sie in einen separaten Prüfbereich.

Die Verarbeitung lässt sich nach Aufwand priorisieren. Kleine Textdateien können sofort laufen, während umfangreiche Scans im Hintergrund bleiben. Dringende Aktualisierungen erhalten eine höhere Priorität als eine komplette Bestandsaufnahme. Damit reagiert das System im Alltag schneller, ohne die große Verarbeitung abzubrechen.

Ein weiterer Hebel ist die Stapelbildung. Embedding- oder Analyseaufträge können mehrere Abschnitte gemeinsam verarbeiten. Das senkt den Verwaltungsaufwand und verbessert bei geeigneter Hardware den Durchsatz. Die Stapelgröße darf jedoch nicht starr sein: Kurze Texte vertragen größere Gruppen, lange Inhalte benötigen kleinere Pakete.

• Warteschlangen trennen Auftragseingang und Verarbeitung.
• Worker können unabhängig voneinander gestartet oder beendet werden.
• Wiederholungen müssen sicher sein, damit keine doppelten Einträge entstehen.
• Prioritäten schützen zeitkritische Aktualisierungen vor langen Hintergrundläufen.
• Stapelverarbeitung nutzt Rechenzeit effizienter.

Für die Auslegung zählt nicht nur der maximale Durchsatz. Entscheidend sind auch Wartezeit, Fehlerrate und die Dauer bis zur vollständigen Aktualisierung eines Dokuments. Ein System, das viele Dateien verarbeitet, aber veraltete Inhalte ausliefert, ist praktisch wenig wert.

Deshalb sollten Betriebskennzahlen je Dienst getrennt erfasst werden. Dazu gehören die Länge der Warteschlange, die Bearbeitungsdauer pro Auftrag, Wiederholungen und die Zahl dauerhaft fehlgeschlagener Aufgaben. Solche Werte zeigen früh, ob ein Worker knapp bemessen ist oder eine bestimmte Dokumentklasse Probleme verursacht.

Bei sehr großen Mengen kann eine Vorhersage des Arbeitsaufkommens helfen. Dateigröße, Seitenzahl und Dokumenttyp liefern bereits vor der Verarbeitung brauchbare Hinweise auf den erwarteten Aufwand. Worker lassen sich dadurch früher bereitstellen.

Embeddings, Vektorsuche und semantisches Ranking

Embeddings bilden Text als Zahlenvektor ab. Ähnliche Inhalte liegen dabei im Vektorraum näher zusammen, auch wenn sie unterschiedliche Wörter verwenden. Für ein On-Premise-RAG ist deshalb nicht nur die Modellqualität wichtig. Entscheidend ist, ob das Embedding-Modell zur Sprache, zu den Fachbegriffen und zur Suchabsicht der Nutzer passt.

Ein englisch geprägtes Modell kann bei deutschen Vertragsklauseln, medizinischen Abkürzungen oder technischen Produktnamen deutlich schwächer arbeiten. Vor der Auswahl sollten Unternehmen daher reale Suchfragen aus dem späteren Einsatz sammeln. Ein kleiner Testsatz mit 100 bis 300 Fragen zeigt oft schneller die Eignung als allgemeine Ranglisten.

Die Vektordimension beeinflusst Speicherbedarf und Suchaufwand. Bei 10 Millionen Abschnitten und 1.024 Dimensionen entstehen allein für 32-Bit-Fliesskommazahlen rund 41 Gigabyte Rohdaten, noch ohne Index und Metadaten. Quantisierung kann diesen Bedarf stark senken. Sie darf aber nicht blind eingesetzt werden, weil eine geringere Genauigkeit seltene Fachbegriffe aus dem Trefferfeld drängen kann.

Für die erste Suche kommen Verfahren wie HNSW oder IVF infrage. HNSW liefert oft eine gute Antwortzeit bei hohen Trefferquoten und benötigt dafür zusätzlichen Arbeitsspeicher. IVF teilt den Vektorraum in Bereiche und prüft nur ausgewählte Cluster. Das spart Rechenzeit, verlangt aber eine passende Parametrierung. Die richtige Wahl hängt von Datenmenge, Aktualisierungsrate und verfügbarem Speicher ab.

Die Suchqualität steigt meist durch eine Kombination aus mehreren Stufen. Zuerst ruft eine schnelle Kandidatensuche beispielsweise 50 bis 200 Abschnitte ab. Danach bewertet ein Cross-Encoder die Beziehung zwischen Frage und Abschnitt genauer. Dieses semantische Ranking prüft beide Texte gemeinsam und erkennt dadurch oft bessere Treffer als ein reiner Vektorvergleich.

Bei deutschen Fachtexten sollten auch sprachliche Details einfließen. Zahlen, Einheiten, Gesetzesstellen und interne Kennungen brauchen eine exakte Suche. Synonyme und Umschreibungen profitieren dagegen vom Embedding. Eine hybride Abfrage verbindet beide Signale und gewichtet sie je nach Fragetyp unterschiedlich.

• Fachbegriffe und Eigennamen mit exakter Suche absichern.
• Semantische Treffer zunächst großzügig sammeln.
• Mit einem Re-Ranker auf wenige, belastbare Passagen reduzieren.
• Ähnliche Treffer aus demselben Abschnitt zusammenfassen.
• Den Rang nicht mit der inhaltlichen Wahrheit verwechseln.

Für die Bewertung reichen allgemeine Antwortnoten nicht aus. Sinnvoll sind Messgrößen wie Recall@k, Precision@k und nDCG@k. Recall zeigt, ob ein relevanter Abschnitt überhaupt gefunden wird. Precision prüft, wie viele der oberen Treffer brauchbar sind. nDCG berücksichtigt zusätzlich die Reihenfolge. So wird sichtbar, ob ein Problem beim Modell, beim Index oder beim Ranking liegt.

Ein häufiger Fehler ist der Wechsel des Embedding-Modells ohne Neuindizierung. Vektoren verschiedener Modelle liegen nicht im selben Raum und dürfen nicht einfach gemischt werden. Jede Indexversion braucht deshalb die Modellkennung, die Dimension und die verwendete Vorverarbeitung. Sonst liefert die Suche zwar Ergebnisse, aber ihre Grundlage bleibt unklar.

Lokale Sprachmodelle effizient bereitstellen

Die Modellwahl bestimmt, wie viel Speicher, Arbeitsspeicher und Rechenzeit ein lokales RAG-System benötigt. Für viele interne Anwendungen reicht ein Modell mit 7 bis 14 Milliarden Parametern. Größere Modelle liefern nicht automatisch bessere Antworten. Entscheidend sind Fachsprache, Kontextlänge und die gewünschte Antwortzeit.

Vor dem Einsatz sollte das Modellformat festgelegt werden. Formate wie GGUF eignen sich für quantisierte Ausführung auf CPU oder gemischten Systemen. Safetensors ist praktisch für GPU-basierte Bereitstellung. Eine 4-Bit-Quantisierung senkt den Speicherbedarf deutlich, kann aber bei Zahlen, Code und juristischen Formulierungen an Genauigkeit verlieren. Deshalb gehört ein Vergleich mit unveränderter Präzision in den Abnahmetest.

Die Modellgröße lässt sich grob abschätzen. Ein Modell mit 8 Milliarden Parametern benötigt bei 16-Bit-Gewichten rund 16 Gigabyte Speicher, zusätzlich zu Laufzeitpuffern und dem Kontextspeicher. Bei 4 Bit sinkt der reine Gewichtsspeicher auf ungefähr 4 Gigabyte. Für produktive Nutzung braucht die Hardware trotzdem Reserven, besonders bei langen Eingaben oder mehreren parallelen Sitzungen.

Für den Betrieb ist die Wahl des Inferenzservers ebenso wichtig wie das Modell selbst. Ein Server sollte kontinuierliche Stapelverarbeitung, Token-Streaming und mehrere Modellinstanzen unterstützen. Continuous Batching nutzt freie Rechenfenster, wenn Anfragen mit unterschiedlicher Länge eintreffen. Dadurch steigt der Durchsatz, ohne dass jede Anfrage auf das Ende einer anderen warten muss.

Die Kontextlänge muss begrenzt werden. Ein Fenster von 32.000 Token klingt großzügig, erhöht aber Speicherbedarf und Antwortzeit. Für viele Unternehmensdialoge reichen 4.000 bis 16.000 Token, wenn der abgerufene Kontext vorher sauber gekürzt wird. Lange Dokumente sollten nicht pauschal vollständig an das Modell gehen.

Auch die Ausgabe braucht feste Leitplanken. Maximale Tokenzahl, Temperatur und Stop-Sequenzen lassen sich je nach Anwendungsfall definieren. Für sachliche Auskünfte ist eine niedrige Temperatur meist sinnvoll. Bei der Antwort sollte das System außerdem zwischen belegter Aussage, Schlussfolgerung und fehlender Information unterscheiden können.

• Modellversion und Gewichtsformat unveränderlich dokumentieren.
• Quantisierung mit fachlichen Testfragen prüfen.
• Kontextlänge und Ausgabelänge getrennt begrenzen.
• Streaming nur dort aktivieren, wo es den Arbeitsablauf verbessert.
• Modellinstanzen nach Speicherbedarf und Lastprofil planen.

Ein produktiver Modellserver braucht einen kontrollierten Lebenszyklus. Neue Gewichte werden zunächst isoliert geprüft, danach mit derselben Testsuite wie die bisherige Version verglichen. Erst wenn Antwortqualität, Fehlerrate und Antwortzeit akzeptabel bleiben, erfolgt der Wechsel. Die alte Version sollte für eine begrenzte Rückfallzeit verfügbar bleiben.

Schließlich muss das Modell seine Grenzen kennen. Eine klare Regel wie „Keine belastbare Quelle, keine sichere Behauptung“ wirkt oft besser als ein besonders kreativer Prompt. Das Sprachmodell ist dann nicht der allwissende Mittelpunkt, sondern ein präzise begrenzter Dienst innerhalb der RAG-Anwendung.

Hardware, Inferenz und GPU-Ressourcen planen

Die Hardwareplanung sollte sich an drei Messwerten orientieren: gewünschte Antwortzeit, Zahl gleichzeitiger Anfragen und Modellgröße. Eine einzelne starke Grafikkarte kann für einen Pilotbetrieb genügen. Im Alltag zählen jedoch auch Spitzenlasten, Wartungsfenster und ein möglicher Ausfall.

Für die Inferenz ist der Speicherbedarf der Gewichte nur der Anfang. Zusätzlich benötigen Laufzeit, Aktivierungen und der KV-Cache Speicher. Dieser wächst mit Kontextlänge und Zahl paralleler Sitzungen. Ein Modell mit 14 Milliarden Parametern kann deshalb trotz quantisierter Gewichte deutlich mehr Grafikspeicher benötigen, sobald mehrere lange Dialoge gleichzeitig laufen.

Die folgende Näherung hilft bei einer ersten Kalkulation:

• Gewichtsspeicher = Parameterzahl × Bits pro Parameter ÷ 8
• Zusatzbedarf = Laufzeit, Aktivierungen, KV-Cache und Sicherheitsreserve
• Gesamtbedarf = Gewichtsspeicher + Zusatzbedarf

Für produktive Systeme sollte die Reserve nicht knapp ausfallen. Rund 20 bis 30 Prozent freier Grafikspeicher sind ein brauchbarer Startpunkt, wenn Modellgröße und Kontextlänge noch schwanken. Bei stark wechselnden Anfragen ist mehr Luft sinnvoll.

Auch die Verbindung zwischen Hauptspeicher und Grafikkarte beeinflusst die Leistung. PCIe-Übertragungen können zum Flaschenhals werden, wenn Daten ständig zwischen CPU und GPU wandern. Ein Modell sollte daher möglichst vollständig auf dem vorgesehenen Beschleuniger bleiben. Bei mehreren Karten müssen Speicheraufteilung, Interconnect und Parallelisierungsverfahren zusammenpassen.

Für die Beschaffung sind drei Betriebsprofile nützlich:

• Entwicklung: eine GPU, geringe Parallelität und kurze Kontexte
• Produktivbetrieb: mehrere Sitzungen, definierte Antwortzeit und Ersatzkapazität
• Stapelverarbeitung: hohe Auslastung für Embeddings, Re-Ranking oder Modellläufe

Diese Profile sollten nicht zwingend auf derselben Hardware laufen. Interaktive Antworten brauchen niedrige Latenz. Stapelaufträge vertragen dagegen längere Wartezeiten und können freie Rechenfenster nutzen. Eine getrennte Kapazitätsplanung verhindert, dass ein nächtlicher Lauf den Dialogbetrieb ausbremst.

Bei der GPU-Auswahl zählen nicht nur Rechenleistung und Speichergröße. Relevant sind außerdem Energieverbrauch, Kühlung, Treiberstabilität, Ersatzteilversorgung und die Unterstützung des gewählten Präzisionsformats. Eine Karte mit höherem theoretischem Durchsatz ist nicht automatisch die bessere Wahl, wenn sie im vorhandenen Server thermisch gedrosselt wird.

Die Inferenz sollte mit realistischen Lastprofilen getestet werden. Dazu gehören kurze Fragen, lange Kontexte, parallele Sitzungen und ungleichmäßige Ankunftszeiten. Gemessen werden sollten mindestens Zeit bis zum ersten Token, Tokenrate, Gesamtlatenz und Abbruchquote. Ein Mittelwert allein verschleiert langsame Ausreißer.

Für die Kapazitätsplanung lohnt eine einfache Formel:

benötigte Kapazität = Spitzenanfragen pro Sekunde × mittlere Rechenzeit pro Anfrage

Das Ergebnis ist kein exakter Einkaufswert, sondern ein Planungsrahmen. Sicherheitsreserve, Wartung und Lastspitzen kommen hinzu. Zudem sollten Embedding- und Generierungsmodelle nicht ungeprüft um dieselben Speicherbereiche konkurrieren.

Bei voller GPU-Kapazität kann das System neue Anfragen begrenzen, eine verständliche Warteposition anzeigen oder auf ein kleineres Modell wechseln. Eine kurze, ehrliche Verzögerung ist besser als ein Dienst, der unter Last scheinbar zufällig ausfällt.

Zugriffsrechte bereits auf Chunk-Ebene sichern

Ein Chunk darf nicht mehr Rechte besitzen als das Dokument, aus dem er stammt. Dafür erhält jeder Abschnitt eine maschinenlesbare Zugriffspolitik, die beim Import aus dem Quellsystem übernommen wird. Freitext wie „vertraulich“ reicht nicht aus. Benötigt werden eindeutige Attribute, etwa Mandant, Abteilung, Schutzklasse und Gültigkeitszeitraum.

Die Berechtigung sollte als unveränderliche Entscheidungsgrundlage neben dem Chunk liegen. Änderungen an Rollen oder Gruppen erfolgen über eine zentrale Regelquelle. So müssen nicht sämtliche Textabschnitte umgeschrieben werden, wenn sich eine Organisationsstruktur ändert. Zugleich bleibt erkennbar, welche Regel eine Freigabe oder Sperre ausgelöst hat.

Wichtig ist die Reihenfolge der Prüfung. Die Identität des Nutzers wird zunächst bestätigt, danach werden seine aktuellen Rollen und Anwendungsrechte geladen. Erst dann darf die Suchabfrage den Index erreichen. Ein Filter, der erst nach der Trefferermittlung greift, ist riskant: Der verbotene Inhalt könnte bereits in Zwischenspeichern, Ranglisten oder Diagnoseprotokollen auftauchen.

Für komplexe Organisationen bietet sich ein Standardmodell mit Allow- und Deny-Regeln an. Eine explizite Sperre sollte Vorrang vor einer allgemeinen Freigabe haben. Zusätzlich müssen Vererbung und Ausnahmen klar definiert sein.

• Die Identität wird nicht allein über einen frei übertragbaren Benutzernamen bestimmt.
• Rollen und Gruppen werden zum Anfragezeitpunkt aktualisiert.
• Mandanten werden logisch strikt voneinander getrennt.
• Temporäre Freigaben besitzen ein Ablaufdatum.
• Jede Zugriffsentscheidung erhält eine nachvollziehbare Prüfspur.

Bei zusammengesetzten Treffern muss jeder einzelne Abschnitt zugelassen sein. Ein erlaubter Chunk darf keinen benachbarten, gesperrten Abschnitt automatisch mitliefern. Auch Zusammenfassungen brauchen dieselbe Prüfung, denn sie können geschützte Fakten indirekt offenlegen.

Die Rechteprüfung sollte zudem fail closed arbeiten. Ist die Berechtigungsinformation unvollständig, veraltet oder technisch nicht erreichbar, wird der Chunk nicht verwendet. Für Notfallzugriffe braucht es einen getrennten Prozess mit zeitlicher Begrenzung und nachträglicher Kontrolle.

Tests sollten nicht nur erlaubte Zugriffe abbilden. Besonders wertvoll sind Negativtests: Ein Nutzer aus Abteilung A fragt gezielt nach einem Dokument aus Abteilung B, eine abgelaufene Freigabe wird verwendet oder ein Suchbegriff verrät bereits den Namen eines gesperrten Projekts.

Für die Umsetzung helfen drei getrennte Datenbereiche: der Inhalt selbst, die Zugriffsattribute und das unveränderliche Prüfprotokoll. Diese Trennung erleichtert Auskünfte, Revisionen und die spätere Löschung.

Deployment in abgeschotteten oder Air-Gap-Umgebungen

Eine Air-Gap-Umgebung besitzt keine direkte Verbindung zu öffentlichen Netzen. Das erhöht die Abschottung, verändert aber den gesamten Bereitstellungsprozess. Software, Modelle, Lizenzdateien und Sicherheitsinformationen gelangen nur über kontrollierte Übergaben in das Zielnetz. Ein funktionsfähiger Betrieb braucht deshalb eine eigene Lieferkette für digitale Komponenten.

Bewährt hat sich eine getrennte Transferzone. Dort werden Pakete zunächst empfangen, auf Schadsoftware geprüft und gegen freigegebene Prüfsummen validiert. Erst danach gelangen sie auf ein Wechseldatenträger- oder Transfermedium. Für jedes Paket sollten Herkunft, Version, Prüfsumme, Freigabestatus und verantwortliche Person dokumentiert werden.

Container-Images verdienen besondere Aufmerksamkeit. Ein Image kann neben der Anwendung auch Bibliotheken, Betriebssystempakete und Skripte enthalten. Vor dem Transfer sollte ein reproduzierbarer Scan stattfinden. Veraltete oder nicht benötigte Bestandteile gehören nicht in das Zielsystem. Bei sicherheitskritischen Installationen empfiehlt sich eine signierte interne Registry statt loser Archivdateien.

Dasselbe gilt für Sprach- und Embedding-Modelle. Neben den Gewichten müssen Tokenizer, Konfigurationsdateien und passende Laufzeitversionen übertragen werden. Fehlt nur eine dieser Komponenten, startet der Dienst vielleicht, liefert aber unzuverlässige Ergebnisse. Ein vollständiges Modellmanifest verhindert solche Überraschungen.

Updates brauchen einen festen Takt. Sicherheitsmeldungen werden außerhalb des Zielnetzes beobachtet, bewertet und in ein genehmigtes Updatepaket überführt. Kritische Korrekturen erhalten eine beschleunigte Prüfung; funktionale Neuerungen können in einen regulären Wartungslauf wandern.

• Transfermedien werden inventarisiert und nach der Nutzung gesperrt oder sicher gelöscht.
• Pakete erhalten digitale Signaturen und unveränderliche Prüfsummen.
• Abhängigkeiten werden vorab vollständig erfasst.
• Eine getestete Rückfallversion bleibt verfügbar.
• Änderungen werden mit Auftrag, Freigabe und Zeitpunkt protokolliert.

Die Identitäts- und Zeitversorgung darf ebenfalls nicht übersehen werden. Ohne erreichbaren Verzeichnisdienst oder zuverlässige Uhr können Zertifikate, Sitzungen und Prüfprotokolle ausfallen. Für isolierte Netze braucht es daher interne Zeitquellen, lokale Namensauflösung und einen abgestimmten Betrieb der Authentifizierungsdienste.

Ein Air-Gap-System sollte außerdem ohne externe Telemetrie funktionieren. Diagnosefunktionen müssen so eingestellt sein, dass keine Verbindungsversuche nach außen entstehen. Für die Fehleranalyse werden geprüfte Exportdateien genutzt, die vor dem Verlassen des Zielnetzes auf geheime Schlüssel, Tokens und vertrauliche Inhalte untersucht werden.

Vor der Freigabe empfiehlt sich eine Wiederanlaufprobe ohne externe Verbindung. Dabei wird geprüft, ob die Anwendung nach einem Neustart, dem Austausch eines Rechners und dem Einspielen eines signierten Updates weiterhin funktioniert. Erst dieser Test zeigt, ob die Abschottung technisch durchgehalten wird.

Die zentrale Betriebsfrage lautet nicht nur: „Ist das System offline?“ Entscheidend ist, ob Softwareversorgung, Identität, Zeit, Diagnose und Wiederherstellung auch ohne Internet nachvollziehbar und sicher funktionieren.

Skalierung anhand von Dokumentvolumen und Nutzerlast

Die Kapazitätsplanung muss zwei sehr unterschiedliche Lastarten trennen: Dokumentlast durch neue oder geänderte Bestände und Nutzerlast durch gleichzeitige Fragen. Beide Lasten teilen sich oft Speicher, Netzwerk und Rechenzeit, haben aber andere Spitzen. Ein monatlicher Import kann die Infrastruktur stärker fordern als mehrere Stunden normaler Dialogbetrieb.

Für die Dokumentlast zählt nicht nur die Dateianzahl. Aussagekräftiger sind Seiten, erkannte Textmenge und die Zahl erzeugter Abschnitte. Ein Bestand mit 100.000 kurzen Textdateien kann weniger Aufwand verursachen als 10.000 gescannte Seiten mit Tabellen. Als Planungsgröße eignet sich daher die erwartete Zahl verarbeiteter Seiten pro Stunde.

Die Nutzerlast lässt sich mit drei Werten beschreiben:

• gleichzeitige Sitzungen,
• Anfragen pro Minute und
• erwartete Antwortzeit je Anfrage.

Zusätzlich sollte das System zwischen interaktiven Fragen und Hintergrundaufträgen unterscheiden. Interaktive Anfragen brauchen eine feste Antwortzeit. Hintergrundläufe können dagegen in ein Zeitfenster verschoben werden. Eine solche Lastklasse verhindert, dass ein großer Import den Dialogbetrieb verdrängt.

Für den Speicherbedarf ist die Entwicklung des Bestands entscheidend. Neben den aktuellen Inhalten müssen ältere Versionen, Suchindizes, Sicherungen und temporäre Arbeitsdaten berücksichtigt werden. Sinnvoll ist eine Prognose für mindestens 24 bis 36 Monate, ergänzt um einen Wachstumsaufschlag.

Auch die Datenbank sollte nicht bis zur technischen Obergrenze gefüllt werden. Freier Speicher wird für Indexumbauten, Reorganisationen und Wiederherstellungen benötigt. Bei stark wachsenden Beständen können Zeit- oder Fachbereichssegmente die Verwaltung erleichtern. Alte, selten genutzte Daten lassen sich dann auf langsamere Speicherebenen verschieben.

Ein praktisches Kapazitätsmodell trennt vier Größen:

• Grundlast: dauerhaft benötigte Ressourcen für Dienste und Speicher
• Dialoglast: Kapazität für gleichzeitige Nutzeranfragen
• Aufnahmelast: zusätzliche Leistung bei neuen Dokumenten
• Reserve: Spielraum für Wachstum, Ausfälle und Spitzen

Die Werte sollten mit einem Belastungstest überprüft werden. Dabei wird ein realistischer Mix erzeugt: kurze und lange Fragen, mehrere Nutzer, parallele Bestandsänderungen sowie Suchanfragen auf unterschiedlich großen Teilbeständen. Entscheidend ist nicht nur der höchste Durchsatz. Auch die Antwortverteilung zählt. Wenn 95 Prozent der Anfragen schnell sind, die langsamsten fünf Prozent aber minutenlang warten, wirkt das System trotzdem instabil.

Bei wachsendem Volumen helfen Schwellenwerte. Erreicht der Speicher beispielsweise 70 Prozent, beginnt eine Erweiterungsplanung. Steigt die durchschnittliche Wartezeit über das vereinbarte Ziel, wird die Nutzerlast begrenzt oder zusätzliche Kapazität aktiviert. Solche Regeln machen den Betrieb berechenbarer.

Eine tragfähige Skalierungsstrategie ordnet Lastklassen, Speicherstufen und Wachstumspfade passend zu. Erst in dieser Kombination lässt sich zuverlässig beurteilen, ob ein On-Premise-RAG auch beim nächsten großen Dokumentenpaket stabil arbeitet.

Qualität mit messbaren RAG-Tests prüfen

Ein RAG-System ist erst dann belastbar, wenn seine Qualität mit einem festen Prüfkatalog messbar wird. Einzelne Testfragen reichen nicht aus. Ein valider Testbestand enthält typische, mehrdeutige und bewusst schwierige Anfragen aus dem späteren Arbeitsalltag.

Jede Testfrage sollte mit einer Referenz versehen werden. Dazu gehören die erwartete Antwort, die maßgeblichen Quellstellen und die Information, ob eine Antwort überhaupt möglich ist. Auch unbeantwortbare Fragen sind wichtig. Ein gutes System muss in diesem Fall eine Wissenslücke erkennen, statt eine plausible Behauptung zu erfinden.

Für die Bewertung empfiehlt sich eine getrennte Betrachtung von Suche und Antwort:

• Trefferabdeckung: Wird die relevante Quelle gefunden?
• Quellenrang: Steht sie weit genug oben?
• Belegtreue: Stützt der Kontext die Aussage wirklich?
• Vollständigkeit: Werden alle wichtigen Teilaspekte genannt?
• Widerspruchsfreiheit: Bleibt die Antwort innerhalb des belegten Materials?
• Enthaltung: Erkennt das System fehlende Grundlagen?

Für Suchtests eignen sich Kennzahlen wie Recall@5 oder Precision@10. Bei generierten Antworten sollten zusätzlich menschliche Bewertungen mit klaren Rubriken erfolgen. Eine Skala von eins bis fünf ist nur dann brauchbar, wenn jede Stufe beschrieben ist.

Besonders hilfreich ist ein Fehlerkatalog. Typische Kategorien sind falsche Quelle, veraltete Quelle, ausgelassene Ausnahme, vermischte Dokumentversion und unbelegte Schlussfolgerung. Jede neue Modell- oder Pipeline-Version wird gegen diesen Katalog geprüft. So entsteht eine Regressionstestsuite, die reale Schwachstellen abbildet.

Die Tests sollten außerdem sprachlich und fachlich vielfältig sein. Dazu gehören:

• Synonyme und unterschiedliche Satzformen
• Fragen mit Tippfehlern oder Abkürzungen
• mehrteilige Aufgaben
• Fragen mit widersprüchlichen Quellen
• Grenzfälle bei Zahlen, Datumsangaben und Einheiten
• Fragen ohne passende Dokumentgrundlage

Eine wichtige Metrik ist die Antwortstabilität. Wird dieselbe Frage mehrfach gestellt, sollte sich der Kern der Antwort nicht zufällig verändern. Kleine sprachliche Unterschiede sind normal. Wechselnde Fakten oder Quellen weisen dagegen auf ein Problem bei Einstellungen, Kontextauswahl oder Modellverhalten hin.

Qualität lässt sich auch als Freigaberegel formulieren. Beispielsweise darf eine neue Version nur produktiv gehen, wenn die Trefferabdeckung über einem festgelegten Schwellenwert liegt, keine kritischen Sicherheitsfälle offen sind und die Antwortlatenz im vereinbarten Bereich bleibt. Bei medizinischen oder rechtlichen Inhalten gelten strengere Maßstäbe als bei einer internen Dokumentensuche.

Alle Testergebnisse brauchen eine Version, einen Zeitpunkt und die verwendete Konfiguration. Dazu gehören Modell, Suchparameter, Prompt und Datensatzstand. Nur so lässt sich später erklären, warum sich ein Ergebnis verändert hat. Der Abnahmetest läuft nach Änderungen erneut, wird um reale Fehler ergänzt und bleibt getrennt von den Trainings- oder Entwicklungsdaten.

Fazit: Modular starten und Sicherheit von Anfang an einplanen

Ein On-Premise-RAG sollte nicht mit maximaler Komplexität beginnen, sondern mit einem klar begrenzten Anwendungsfall. Wählen Sie eine Dokumentklasse, eine Nutzergruppe und ein überprüfbares Ziel. So lässt sich erkennen, ob der praktische Nutzen die zusätzlichen Betriebsaufwände rechtfertigt.

Für die Einführung empfiehlt sich ein verbindlicher Entscheidungsrahmen:

• Nutzen: Welche Arbeitszeit oder Fehlerquelle soll das System konkret reduzieren?
• Risiko: Welche Folgen hätte eine falsche, unvollständige oder veraltete Antwort?
• Betrieb: Wer übernimmt Modellwechsel, Störungen, Freigaben und Wiederherstellung?
• Nachweis: Welche Kennzahlen entscheiden über Ausbau oder Kurswechsel?

Der modulare Aufbau schafft eine wichtige Zukunftsoption: Komponenten können ersetzt werden, ohne den gesamten Dienst neu zu entwickeln. Diese Austauschbarkeit sollte bereits in Verträgen, Schnittstellen und Datenformaten festgehalten werden. Offene Exportformate sind besonders wertvoll, wenn ein späterer Wechsel der Such- oder Modellkomponente absehbar ist.

Sicherheit gehört nicht in eine spätere Projektphase. Sie muss bereits bei der Festlegung des Schutzbedarfs, der Verantwortlichkeiten und der Betriebsprozesse berücksichtigt werden. Dazu zählt auch ein klarer Notfallplan: Was geschieht bei einem kompromittierten Modell, einem beschädigten Index oder einer fehlerhaften Antwortserie?

Ebenso wichtig ist die organisatorische Seite. Ein RAG-System braucht neben Entwicklern auch fachliche Verantwortliche für Inhalte und Regeln. Diese Personen entscheiden, welche Quellen gültig sind, wann ein Bestand abgelöst wird und welche Antworten als kritisch gelten. Technik allein kann diese Entscheidungen nicht ersetzen.

Die wirtschaftliche Bewertung sollte nicht nur Anschaffungskosten betrachten. Strom, Kühlung, Ersatzhardware, Wartung, Modellpflege und interne Betriebszeit gehören ebenfalls in die Rechnung. On-Premise kann bei hoher Auslastung und strengen Schutzvorgaben sinnvoll sein; bei kleinen, seltenen Aufgaben ist der eigene Betrieb dagegen nicht automatisch günstiger.

Als Abschluss jeder Einführungsstufe sollte eine schriftliche Entscheidung stehen: erweitern, ändern oder stoppen. Diese Nüchternheit schützt vor dem sogenannten Funktionshunger, bei dem immer neue Modelle und Schnittstellen hinzukommen, ohne den eigentlichen Geschäftsnutzen zu erhöhen.

Die tragfähige Strategie lautet deshalb: klein beginnen, sauber trennen, Risiken früh festlegen und den Ausbau an messbaren Ergebnissen ausrichten. Dann wird das lokale RAG-System nicht zum isolierten KI-Experiment, sondern zu einem kontrollierbaren Unternehmensdienst, der mit den Anforderungen wachsen kann.

FAQ zur lokalen RAG-Architektur und ihrer Umsetzung