RAG offline betreiben: So funktioniert ein lokales Retrieval‑System sicher

Viele Organisationen möchten Hilfestellung durch KI‑Modelle nutzen, aber sensible Referenzdaten nicht in die Cloud geben. Ein lokal betriebenes RAG‑System verbindet eine Suchschicht, die passende Dokumente aus einer eigenen Sammlung findet, mit einem Sprachmodell, das auf diesen Referenzen Antworten formuliert. So lassen sich Antworten mit Quellenbelegen versehen und sensible Inhalte kontrolliert halten.

Im Alltag bedeutet das: Wenn ein Mitarbeiter eine Frage zu einer internen Richtlinie stellt, sucht der Retriever in der eigenen Dokumentensammlung und liefert kurze Textpassagen an das Generativmodell. Die Ausgabe kann dann auf diese Chunks verweisen, was Nachvollziehbarkeit und Korrekturmöglichkeiten erhöht. Damit dieser Ablauf zuverlässig und datenschutzkonform läuft, sind Architekturentscheidungen nötig — von der Wahl der Vektordatenbank bis hin zu Löschprozessen für Chunks.

Ein RAG‑System besteht aus vier Kernkomponenten: dem Embedding‑Modul, der Vektordatenbank, dem Retriever und dem Generator (dem Sprachmodell). Embeddings sind Zahlenräume, in denen kurze Textstücke als Vektoren dargestellt werden; ähnlich formulierte Texte liegen dort nahe beieinander. Eine Vektordatenbank (zum Beispiel FAISS) sucht dann schnell nach nächsten Nachbarn, also den relevantesten Textpassagen.

Ein lokales RAG trennt die Referenzdaten physisch oder logisch vom Modell‑Service und erlaubt so gezielte Kontrolle über Speicherung, Zugriff und Löschung.

Wichtig ist die Trennung zwischen referenziellen Daten (Ihre Dokumente) und dem generativen Modell. Das Modell selbst enthält sein Trainingswissen; die Retrieval‑Schicht liefert aktuelle Fakten. In der Praxis kombiniert man häufig eine lokale Vektordatenbank (FAISS, HNSW‑Indizes) mit einem LLM, das entweder lokal läuft oder in einer vertragsgebundenen Umgebung ohne Transfer sensibler Chunks eingesetzt wird.

Die Tabelle fasst typische Index‑Optionen und Kerneigenschaften vereinfacht zusammen.

Für einen On‑Premise‑Aufbau ist es üblich, frühzeitig zwei Varianten im Proof‑of‑Concept gegeneinander zu testen: HNSW für hohe Recall‑Ansprüche bei moderatem Speicherbedarf und IVF+PQ, wenn extreme Skalierung mit geringem RAM‑Footprint nötig ist. Parameter wie M, ef_construction (HNSW) oder nprobe (IVF) sind Projektschlüsselwerte und müssen mit Real‑Daten getuned werden.

Ein pragmatischer Reihenplan für ein erstes lokales RAG‑Projekt sieht so aus:

Zuerst: Corpus vorbereiten. Dokumente werden in kleine, in sich sinnvolle Chunks zerlegt (z. B. Absätze). Jeder Chunk erhält Metadaten (Quelle, Datum, Zugriffsebene). Dann werden Embeddings erzeugt. Embeddings sind Vektoren mit typischer Dimensionalität zwischen 384 und 1536 — sie kodieren Text in einer Form, die Vektorsuchen erlaubt.

Zweiter Schritt: Index und Retrieval. Mit den Embeddings baut man den Index (FAISS/HNSW). Testläufe messen Recall@1/5/10, Latenz und QPS (Queries per Second). Übliche Startwerte für HNSW sind M≈16 und ef_construction≈200; diese Werte sind jedoch datenabhängig und sollten mit einem Datensatz‑PoC validiert werden.

Drittens: Integration mit dem Modell. Das System liefert die besten Chunks an das LLM; das Modell erzeugt eine Antwort, idealerweise mit Quellenangaben oder einem kurzen Belegtext. In einer datenschutzsensiblen Umgebung läuft das LLM lokal oder in einer kontrollierten Umgebung, sodass keine Chunks an Dritte gesendet werden.

Vierter Punkt: Operations und Governance. Implementiere RBAC (rollenbasierte Zugriffskontrolle), verschlüsselte Speicherung der Index‑Dateien und Audit‑Logging für Queries und gelieferte Chunks. Definiere Lösch‑ und Aufbewahrungsfristen; teste Löschpfade technisch, damit gelöschte Dokumente nicht mehr wiederherstellbar im Index bleiben.

Der lokal betriebene Ansatz bringt klare Vorteile: bessere Kontrolle über personenbezogene Referenzdaten, geringere Abhängigkeit von Drittanbietern und die Möglichkeit, firmenspezifische Dokumente sofort in den Suchindex aufzunehmen. Außerdem lässt sich die Nachvollziehbarkeit verbessern, weil jede Antwort auf konkrete Chunks verwiesen werden kann.

Gleichzeitig bleiben Risiken bestehen. Ein zentraler Punkt ist das Training des LLM: Selbst wenn Referenzdaten lokal bleiben, kann das verwendete Modell intern Wissen aus vielfältigen Trainingsdaten enthalten, dessen rechtliche Bewertung nötig ist. Die datenschutzrechtliche Orientierungshilfe von Aufsichtsbehörden betont daher, dass RAG keine generelle Entlastung von Prüfpflichten am Training des Modells bedeutet.

Technische Risiken umfassen Data‑Poisoning (bösartige Einfügungen in die Referenzdaten), Membership‑Inference‑Angriffe gegen Embeddings und die Schwierigkeit, Löschungen vollständig nachzuweisen. Operational ist die Aufrechterhaltung von Index‑Qualität eine Aufgabe: Dokumente ändern sich, Metadaten werden aktualisiert — regelmäßiges Re‑Embedding ist notwendig, um Drift zu vermeiden.

Ein weiterer Spannungsfeld ist die Erklärungspflicht. Embeddings sind mathematisch schwer direkt erklärbar; daher muss die Nachvollziehbarkeit über Metadaten, gespeicherte Chunks und Protokolle sichergestellt werden, nicht durch eine vollständige Modell‑Transparenz.

Für den langfristigen Betrieb empfiehlt sich ein Zyklus aus Monitoring, Tests und dokumentierter Governance. Monitoring umfasst Leistungskennzahlen (Recall, Latenz, QPS), aber auch Qualitätstests gegen eine Test‑Suite, die Halluzinationsraten und Quellenangaben prüft. Solche Tests sollten automatisiert und regelmäßig laufen.

Wartung heißt: Re‑Embedding nach größeren Dokumentänderungen, Nachtraining oder Austausch des Embedding‑Modells und periodische Neubewertung von Index‑Parametern. Für größere Korpora kann ein zweistufiges Setup sinnvoll sein: Ein Hot‑Index mit HNSW für aktuelle, oft abgefragte Dokumente und ein Cold‑Index mit IVF+PQ für Archivdaten.

Aus Compliance‑Sicht sind drei Elemente zentral: lückenloses Audit‑Logging, definierte Löschprozesse und eine datenschutzrechtliche Risikoprüfung (DSFA). Bei der DSFA wird geprüft, ob Art und Umfang der Datenverarbeitung verhältnismäßig sind und welche technischen Maßnahmen Risiken mindern. Behördenratschläge empfehlen On‑Premise‑Lösungen, mandantentrennte Indizes und dokumentierte Löschpfade als Best Practices.

Schließlich ist die Frage nach Verantwortlichkeiten wichtig: Wer ist für Quellenqualität, für das Embedding‑Modell oder für die Freigabe neuer Dokumentklassen verantwortlich? Klare Zuständigkeiten verhindern Fehler in der Praxis.

RAG offline betreiben ist eine praktikable und datenschutzfreundlichere Option für Organisationen, die eigene Referenzdaten kontrolliert nutzen wollen. Technisch erfordert das Entscheidungen zu Index‑Typ, Embedding‑Modell und zur Frage, ob das LLM lokal ausgeführt wird. Operativ sind Governance, Audit‑Logging und getestete Löschprozesse zentrale Elemente. Die Methode verbessert oft die Nachvollziehbarkeit von Antworten, ersetzt aber nicht die juristische Prüfung des eingesetzten Modells oder die Notwendigkeit regelmäßiger Qualitätstests.