Post vom 28. Mai 2026
Was ist RAG?
Retrieval-Augmented Generation für IT-Entscheider
Generative KI beeindruckt mit Antworten auf allgemeine Fragen. Bei unternehmensinternen Themen enttäuscht sie systematisch: Sie kennt weder Ihren aktuellen Vertrag mit Lieferant X noch das Protokoll der letzten Risikokommission. Sie erfindet Details, die klingen wie interne Fakten, aber keine sind.
RAG löst genau dieses Problem. Nicht durch teures Training eines eigenen Modells, sondern durch einen eleganten Umweg: Das bekommt im Moment der Anfrage die relevanten Inhalte aus Ihren eigenen Daten mitgeliefert, und antwortet auf Basis dieser Quellen.
Lesezeit: ca. 8 Minuten | Zuletzt aktualisiert: Mai 2026
LLM (Large Language Model)
Ein LLM ist ein KI-Modell, das auf großen Textmengen trainiert wurde und natürlichsprachige Anfragen versteht und beantwortet — Grundlage aller modernen KI-Assistenten, von ChatGPT bis zu lokal betriebenen Open-Source-Modellen.
Was RAG bedeutet #
RAG steht für Retrieval-Augmented Generation. Das Konzept wurde 2020 von Patrick Lewis und Kollegen bei Facebook AI Research veröffentlicht und ist heute der Architektur-Standard für jedes ernstzunehmende Enterprise-KI-System.
Drei Begriffe im Namen, drei Schritte in der Praxis:
Retrieval (Suche). Bevor das Sprachmodell antwortet, sucht das System in einem Datenbestand nach Dokumenten, die zur Frage passen. Diese Suche ist semantisch, kein Stichwortabgleich, sondern eine Bedeutungssuche. Eine Frage nach „Aufbewahrungsfristen für Personalakten” findet auch Dokumente, die das Wort „Aufbewahrungsfrist” nicht enthalten, aber den Sachverhalt behandeln.
Augmentation (Anreicherung). Die gefundenen Textabschnitte werden zusammen mit der ursprünglichen Frage an das Sprachmodell übergeben. Das Modell sieht also nicht nur die Frage, sondern auch die relevanten Inhalte aus Ihren Dokumenten.
Generation (Antwort). Das Sprachmodell formuliert eine Antwort, die sich auf die übergebenen Inhalte stützt. Weil die Quellen mitgeliefert werden, können sie direkt zitiert und verlinkt werden. Das Modell erfindet keine Paragraphen, keine Vertragsklauseln, keine Studienergebnisse, es greift auf das zurück, was tatsächlich vorhanden ist.
Warum RAG nicht Fine-Tuning ist #
Der häufigste Irrtum: RAG und Fine-Tuning werden verwechselt. Sie sind grundlegend verschieden.
Fine-Tuning bedeutet, ein vorhandenes Sprachmodell auf eigenen Daten weiterzutrainieren. Das Wissen wird fest ins Modell eingebrannt. Sobald sich Daten ändern, muss das Modell neu trainiert werden. Für die meisten Unternehmen ist das wirtschaftlich nicht sinnvoll: Die Datenbestände ändern sich kontinuierlich, neue Dokumente entstehen täglich, ein Training dauert Stunden bis Tage, und ein eigenes ML-Team ist nötig.
RAG trainiert gar nicht. Stattdessen wird das Modell im Moment der Anfrage mit den aktuellen Inhalten aus dem Datenbestand versorgt. Ein neues Dokument ist sofort nach der Indexierung recherchierbar. Ein zurückgezogenes Dokument ist sofort aus dem Index entfernt. Das Modell selbst bleibt unverändert, es wird nur besser informiert.
| Eigenschaft | RAG | Fine-Tuning |
|---|---|---|
| Neue Daten sofort verfügbar | ✓ | ✗ (neues Training nötig) |
| Eigenes ML-Team erforderlich | ✗ | ✓ |
| Quellnachweis möglich | ✓ | ✗ |
| Modell austauschbar | ✓ | ✗ (modellgebunden) |
| Geeignet für wandelnde Datenbestände | ✓ | Bedingt |
| Einstiegsinvestition | Mittel | Hoch |
Die zwei technischen Bausteine #
RAG braucht zwei Komponenten, die viele IT-Verantwortliche noch nicht kennen:
Embeddings #
Jeder Textabschnitt (ein Absatz aus einem Vertrag, eine Seite aus einem Wiki, ein E‑Mail-Auszug) wird in einen mathematischen Vektor übersetzt. Dieser Vektor repräsentiert die Bedeutung des Textes. Inhaltlich ähnliche Texte erhalten ähnliche Vektoren, inhaltlich verschiedene erhalten verschiedene.
Das ist die Grundlage der semantischen Suche: Das System vergleicht nicht Wörter, sondern Bedeutungen. Eine Frage nach „Kündigungsfristen” findet auch ein Dokument, das nur von „Beendigungsregelungen im Arbeitsverhältnis” spricht.
Vektor-Datenbank #
Die Embeddings werden in einer Vektor-Datenbank gespeichert. Sie ist spezialisiert darauf, bei einer Suchanfrage sehr schnell die ähnlichsten Vektoren zu finden, auch über Millionen von Dokumenten. Eine gewöhnliche SQL-Datenbank kann das nicht leisten.
In einem produktionsreifen Enterprise-System sind Vektor-Datenbank und Sprachmodell zwei separate Komponenten. Das ist wichtig: Wer eine fertige Lösung bewertet, sollte fragen, wo die Vektor-Datenbank läuft. Liegt sie bei einem externen Dienstleister, verlassen die Embeddings Ihres Datenbestands das Unternehmen, auch wenn das eigentliche Sprachmodell lokal läuft.
Was RAG für Enterprise-Umgebungen leistet #
Für Unternehmen mit sensiblen Daten und Compliance-Anforderungen bringt RAG drei konkrete Vorteile:
Quellnachweis statt Halluzination. Jede KI-Antwort ist auf Dokumente zurückführbar, die tatsächlich existieren und die der anfragende Nutzer lesen darf. Mitarbeiter können die Quelle öffnen und prüfen. Das reduziert das Halluzinationsproblem strukturell, nicht durch Versprechungen eines Anbieters, sondern durch Architektur.
Daten bleiben aktuell (ohne Aufwand). Ein internes Regelwerk, das heute aktualisiert wird, ist morgen über die KI recherchierbar. Keine manuelle Pflege, kein Neu-Training, kein Content-Export in ein separates System.
Rechtemanagement bleibt wirksam. RAG-Systeme können die Suchergebnisse vor der Antwortgenerierung filtern: Nur Inhalte, auf die der anfragende Nutzer Leserechte besitzt, fließen in den Kontext. Damit bleibt das bestehende AD/LDAP-Rechtemanagement auch im KI-Kontext wirksam, sofern die Lösung das unterstützt.
RAG und Datensouveränität: Was im Enterprise-Kontext gilt #
RAG schützt Daten nicht automatisch. Das Schutzversprechen gilt nur, wenn alle Komponenten des Systems lokal betrieben werden:
- Das Sprachmodell läuft lokal → Prompts verlassen das Netzwerk nicht
- Die Vektor-Datenbank läuft lokal → Embeddings bleiben im Unternehmen
- Die Konnektoren laufen lokal → Keine Datenkopie bei Drittanbietern
Viele Cloud-KI-Dienste bieten RAG-ähnliche Funktionen an: Microsoft Copilot, Google NotebookLM, OpenAI Custom GPTs. Der grundlegende Unterschied: Die Indexierung und der Inferencing-Schritt finden auf Servern statt, die dem US CLOUD Act und FISA 702 unterliegen. US-Behörden können auf Daten bei US-Unternehmen weltweit zugreifen, unabhängig vom Serverstandort. Für regulierte Daten ist das ein strukturelles Problem, das keine vertragliche Zusicherung beseitigt.
Eine lokale RAG-Appliance wie Silent AI führt alle Schritte (Indexierung, Embedding, Inferencing) auf eigener On-Premises-Hardware durch. Kein Datenpunkt verlässt das Netzwerk.
→ Lokales KI-Wissensmanagement mit Silent AI → Was ist ?
Grenzen von RAG #
RAG ist kein Allheilmittel. Drei Grenzen sollten IT-Verantwortliche kennen:
Qualität der Quellen entscheidet. RAG kann nur so gut sein wie der indizierte Datenbestand. Wer veraltete, widersprüchliche oder schlecht strukturierte Dokumente indiziert, erhält veraltete, widersprüchliche oder schlecht strukturierte Antworten. Eine Daten-Hygiene vor dem Rollout ist keine Option, sondern Voraussetzung.
Rechte müssen sauber sein. Wenn bestehende Berechtigungen zu weit gefasst sind (SharePoint-Sites mit „Anyone in the organization”, Fileserver-Shares ohne rollenbasierte Zugriffskontrolle) macht RAG diese Fehlkonfiguration sichtbar. Ein Rechte-Audit gehört zum Rollout.
Kein Ersatz für generative Aufgaben. RAG optimiert den Zugriff auf vorhandenes Wissen. Für kreative Aufgaben, Übersetzungen oder allgemeine Recherché außerhalb des eigenen Datenbestands ist Cloud-KI weiterhin das bessere Werkzeug. RAG und Cloud-KI schließen sich nicht aus, sie ergänzen sich nach Datenklasse.
Häufige Fragen zu RAG #
Brauche ich für RAG eine eigene GPU? Für die Indexierung (Embedding-Erstellung) reicht eine CPU. Für das eigentliche Inferencing (das Generieren der Antwort) ist eine GPU notwendig, sobald die Antwortzeiten im Produktivbetrieb unter fünf Sekunden liegen sollen. Fertige Appliances wie Silent AI bringen die GPU mit.
Wie viele Dokumente kann RAG verarbeiten? Das hängt von der Vektor-Datenbank und der Hardware ab, nicht von RAG als Konzept. Produktionsreife Systeme verarbeiten Millionen von Dokumenten ohne Qualitätsverlust bei der Suche.
Kann RAG strukturierte Daten aus SQL-Datenbanken nutzen? Ja, mit entsprechenden Konnektoren. Die strukturierten Daten werden in Text umgewandelt und wie Dokumente indiziert. Der Ansatz funktioniert, erfordert aber einen spezialisierten Konnektor pro Datenbankschema.
Wie aktuell sind die Antworten? Antworten sind so aktuell wie die letzte Indexierung der Quellen. Produktive Systeme synchronisieren kontinuierlich oder in kurzen Intervallen, neue Dokumente sind typischerweise innerhalb von Minuten bis einer Stunde recherchierbar.
Zusammenfassung #
RAG ist die Architektur, die Sprachmodelle für Enterprise-Anwendungen auf sensiblen Daten erst nutzbar macht. Kein Training, kein Datenleck durch Prompts, kein Halluzinationsproblem ohne Quellbasis. Die Qualität einer RAG-Lösung entscheidet sich nicht am Sprachmodell, sondern an drei Fragen: Wo läuft die Vektor-Datenbank? Wie wird das Rechtemanagement durchgesetzt? Wie sauber sind die indizierten Datenquellen?
→ KI-Wissensmanagement: Der vollständige Leitfaden → Silent AI: Lokale RAG-Appliance für sensible Daten
Datensouveränität
Datensouveränität beschreibt die vollständige Kontrolle einer Organisation über ihre Daten: wo sie gespeichert werden, wer darauf zugreifen kann, welchem Rechtsrahmen sie unterliegen und ob sie jederzeit ohne Abhängigkeit von einem einzelnen Anbieter verfügbar sind.