RAG für Unternehmen: eine eigene KI auf euren Daten

17. März 2026 #RAG#KI-Integration#DSGVO#LLM#Vektor-Datenbank

Retrieval Augmented Generation (RAG) verbindet ein Sprachmodell mit eurer eigenen Wissensbasis: Statt nur aus dem Trainingswissen zu antworten, sucht das System bei jeder Frage zuerst die relevanten Stellen in euren Dokumenten und gibt sie dem Modell als Kontext mit. Das Modell formuliert die Antwort dann auf Basis genau dieser Belege. Ergebnis: weniger Halluzinationen, nachvollziehbare Quellen und die Möglichkeit, eure Daten im eigenen Haus zu behalten.

TL;DR

RAG = Suche in euren Daten + Sprachmodell, das auf Basis der Treffer antwortet.
Halluzinationen sinken, weil das Modell aus belegtem Kontext statt aus Erinnerung schreibt — mit Quellenangabe.
DSGVO-freundlich machbar: Embeddings und Vektor-Datenbank können on-premise oder in der EU laufen, das LLM lässt sich austauschen.
Kein Fine-Tuning nötig, kein Neutraining bei jeder Dokumentänderung — neue Inhalte sind nach dem Indexieren sofort abfragbar.

Was RAG eigentlich ist — ohne Buzzword-Nebel

Ein Sprachmodell wie GPT, Claude oder ein Open-Source-Modell wie Llama kennt nur, was beim Training drinstand. Eure Preisliste vom letzten Quartal? Eure interne Wartungsdokumentation? Die Vertragsklauseln, die ihr mit genau einem Lieferanten ausgehandelt habt? Davon weiß das Modell nichts. Und wenn man es trotzdem fragt, passiert das Schlimmste, was passieren kann: Es rät selbstbewusst. Klingt plausibel, ist aber erfunden.

RAG dreht den Spieß um. Bei jeder Anfrage läuft erst eine Suche über eure eigenen Daten. Die relevantesten Textstellen werden gefunden und dem Modell zusammen mit der Frage übergeben — ungefähr so: “Hier sind fünf Auszüge aus unseren Unterlagen. Beantworte die Frage des Nutzers ausschließlich auf dieser Grundlage und nenne die Quelle.” Das Modell wird damit vom Alleswisser zum Sachbearbeiter, der vor dem Antworten in die Akte schaut.

Der Trick steckt im Wort “Retrieval”, also Abruf. Das “Augmented” heißt: Wir reichern den Prompt mit echtem Kontext an. “Generation” ist der bekannte Teil — das Formulieren der Antwort. Das Elegante daran: Das Modell selbst bleibt unverändert. Ihr trainiert nichts um. Ihr legt eine Wissensschicht davor.

Warum nicht einfach Fine-Tuning?

Eine häufige Verwechslung. Fine-Tuning verändert die Gewichte des Modells, damit es einen Stil, ein Format oder ein eng umrissenes Verhalten lernt. Es ist schlecht darin, Fakten zuverlässig nachschlagbar zu machen — und noch schlechter darin, aktuell zu bleiben. Ändert sich euer Dokument, müsstet ihr neu trainieren. Teuer, langsam, und das Modell “weiß” trotzdem nicht, woher eine Aussage stammt.

RAG ist die Antwort, wenn es um Wissen geht, das sich ändert und das belegbar sein muss. Fine-Tuning ist die Antwort, wenn es um Verhalten geht (“antworte immer im Ticketformat”). In der Praxis kombiniert man beides selten — meistens reicht gutes RAG mit einem ordentlichen System-Prompt.

Warum RAG Halluzinationen reduziert (und warum nicht ganz)

Ein Sprachmodell halluziniert, weil es darauf optimiert ist, das nächste wahrscheinliche Wort zu erzeugen — nicht, die Wahrheit zu sagen. Fehlt der Kontext, füllt es die Lücke mit dem statistisch Naheliegenden. Genau dort setzt RAG an: Wenn die richtige Information im Prompt steht, muss das Modell nichts mehr erfinden. Es zitiert quasi ab.

Wir bauen in unsere RAG-Systeme fast immer eine Quellenpflicht ein. Jede Aussage bekommt einen Verweis auf das Dokument und die Stelle, aus der sie stammt. Das hat zwei Effekte. Erstens kann der Nutzer nachprüfen. Zweitens — und das ist der unterschätzte Teil — diszipliniert die Anweisung “antworte nur, wenn der Kontext es hergibt” das Modell sichtbar. Findet die Suche nichts Passendes, soll es sagen: “Dazu habe ich in den vorliegenden Unterlagen nichts gefunden.” Das ist eine ehrliche Antwort und in einem Unternehmenskontext oft wertvoller als jede geratene.

Ehrlich bleiben muss man trotzdem: RAG eliminiert Halluzinationen nicht vollständig. Wenn die Suche die falschen Passagen liefert, oder wenn ein Dokument selbst veraltet oder widersprüchlich ist, kann das Modell aus schlechtem Kontext eine schlechte Antwort bauen. Garbage in, garbage out gilt hier eins zu eins. Die Qualität eines RAG-Systems steht und fällt mit der Qualität des Abrufs — nicht mit der Eloquenz des Modells.

Wie eure Daten im Haus bleiben — der DSGVO-Teil

Das ist für die meisten Unternehmen, mit denen wir sprechen, der entscheidende Punkt. Niemand will die HR-Dokumente, Verträge oder die Kundenkorrespondenz in ein US-Cloud-Modell schieben, ohne zu wissen, was dort damit passiert.

Die gute Nachricht: RAG ist modular, und die sensiblen Teile lassen sich vom LLM trennen. Schauen wir, welche Komponenten überhaupt Daten sehen:

Embedding-Modell — wandelt eure Texte in Zahlenvektoren um. Das kann lokal laufen (z. B. ein Open-Source-Modell wie bge oder e5). Eure Texte verlassen damit nie das Haus.
Vektor-Datenbank — speichert diese Vektoren. Liegt auf eurem Server oder in einer EU-Cloud. Hier liegen eure Inhalte.
Sprachmodell (LLM) — bekommt pro Anfrage nur die wenigen relevanten Auszüge, nicht den gesamten Datenbestand.

Daraus ergeben sich verschiedene Stufen. Wer maximale Kontrolle braucht, betreibt alles selbst, inklusive eines Open-Source-LLM auf eigener Hardware. Dann verlässt kein Byte das Unternehmen. Wer Komfort und Spitzenqualität will, nutzt ein gehostetes Modell — dann achtet man auf einen Vertrag zur Auftragsverarbeitung (AVV), EU-Hosting und vor allem eine vertragliche Zusage, dass die übermittelten Daten nicht fürs Training verwendet werden. Bei den Enterprise-Angeboten der großen Anbieter ist Letzteres üblich, aber man muss es schwarz auf weiß haben.

Wir empfehlen oft einen Mittelweg: Embeddings und Vektor-DB on-premise oder in der EU, und ein leistungsstarkes gehostetes Modell für die reine Formulierung, das pro Antwort nur kleine, kontextrelevante Schnipsel sieht. So bleibt der Datenbestand im Haus, und nur ein winziger, jeweils anderer Ausschnitt geht für Sekunden raus. Für viele Anwendungsfälle ist das die pragmatische Linie zwischen Datenschutz und Antwortqualität.

Die Architektur in einem Durchlauf

Ein RAG-System hat zwei Phasen. Die erste passiert einmalig (und bei Updates), die zweite bei jeder Frage.

Phase 1 — Indexierung (einmal, im Hintergrund):

Dokumente einsammeln (PDF, Word, Confluence, SharePoint, Datenbanken, Tickets).
In sinnvolle Häppchen schneiden (“Chunking”) — nicht zu klein, nicht zu groß.
Jedes Häppchen mit dem Embedding-Modell in einen Vektor übersetzen.
Vektoren plus Originaltext und Metadaten in die Vektor-DB schreiben.

Phase 2 — Abfrage (bei jeder Frage, in Millisekunden bis Sekunden):

Frage des Nutzers ebenfalls in einen Vektor umwandeln.
In der Vektor-DB die ähnlichsten Häppchen suchen (semantische Suche).
Die besten Treffer zusammen mit der Frage in den Prompt packen.
LLM antworten lassen — mit Quellenangabe.

Vereinfacht sieht der Kern in Code so aus:

frage = "Welche Kündigungsfrist gilt im Rahmenvertrag mit Lieferant X?"

# 1. Frage in Vektor umwandeln und ähnliche Stellen holen
treffer = vektor_db.suche(embed(frage), top_k=5)

# 2. Kontext bauen
kontext = "\n\n".join(f"[{t.quelle}] {t.text}" for t in treffer)

# 3. Modell strikt auf den Kontext verpflichten
antwort = llm.frage(
    system="Antworte nur anhand des Kontexts. "
           "Fehlt die Info, sage das. Nenne immer die Quelle.",
    user=f"Kontext:\n{kontext}\n\nFrage: {frage}"
)

Klingt simpel, und der Prototyp ist es auch. Den Unterschied zwischen “funktioniert in der Demo” und “funktioniert im Betrieb” machen die Details: Wie schneidet ihr die Dokumente? Wie geht ihr mit Tabellen und Bildern um? Reicht reine Vektor-Suche, oder braucht ihr zusätzlich eine klassische Stichwortsuche (Hybrid Search), damit Produktnummern und Eigennamen sicher gefunden werden? Lohnt ein Re-Ranking-Schritt, der die Treffer nochmal sortiert? Das sind die Stellschrauben, an denen wir die meiste Zeit verbringen — nicht beim Modell.

Wo RAG im Alltag wirklich zieht

Nicht jedes KI-Projekt braucht RAG. Aber dort, wo Wissen verstreut, umfangreich und änderungsanfällig ist, spielt es seine Stärke aus. Typische Felder, die wir immer wieder sehen:

Einsatzgebiet	Was RAG hier leistet
Interner Support / Wissens-Bot	Mitarbeitende fragen in natürlicher Sprache statt im Wiki zu wühlen
Kunden-Support	Antworten aus Handbüchern, FAQ und Tickets — mit Beleg
Recht & Compliance	Schnelles Auffinden von Klauseln über hunderte Verträge
Technische Doku	Service-Techniker bekommen die richtige Wartungsanleitung
Vertrieb	Angebote und Produktdetails auf Zuruf, immer auf aktuellem Stand

Der gemeinsame Nenner: Es gibt eine Antwort in euren Unterlagen, aber sie zu finden kostet Menschen Zeit. Ein gutes RAG-System verkürzt diese Suche von Minuten auf Sekunden — und gibt die Fundstelle gleich mit, damit niemand blind vertrauen muss.

Die Grenzen — damit ihr nicht enttäuscht werdet

Wir sind keine Fans davon, KI als Allheilmittel zu verkaufen. Also Klartext.

RAG ist nur so gut wie eure Daten. Liegt euer Wissen in den Köpfen statt in Dokumenten, gibt es nichts zu indexieren. Sind eure PDFs gescannte Bilder ohne Texterkennung, müsst ihr erst durch OCR. Widersprechen sich drei Versionen desselben Handbuchs, wird auch das System verwirrt antworten — bis ihr aufgeräumt habt. Oft ist das ehrliche Ergebnis eines RAG-Projekts zunächst: “Eure Dokumentation ist ein Chaos.” Das aufzudecken hat schon eigenen Wert.

Weiter: Komplexe Schlussfolgerungen über viele Dokumente hinweg (“Vergleiche alle Verträge mit Kündigungsfrist über drei Monaten und summiere das Volumen”) sind kein klassischer RAG-Job. Da braucht es zusätzliche Logik, manchmal eine Anbindung an strukturierte Datenbanken oder einen Agenten-Ansatz, der mehrere Schritte plant. RAG findet und zitiert hervorragend. Es rechnet und plant nicht von allein.

Und ein Wort zu Zahlen: Wir nennen hier bewusst keine Prozent-Versprechen. Wie stark Halluzinationen sinken oder Zeit gespart wird, hängt zu sehr von eurem Datenbestand, euren Fragen und der Sorgfalt beim Bau ab. Wer euch pauschal “minus 90 Prozent Halluzinationen” garantiert, verkauft eine Folie, kein System.

Wie wir an so ein Projekt rangehen

Wir starten klein und ehrlich. Ein klar umrissener Anwendungsfall, eine überschaubare, saubere Dokumentenmenge, ein Prototyp, an dem ihr selbst spürt, ob die Antworten taugen. Erst wenn der Abruf stimmt, skalieren wir auf mehr Quellen, bauen Rechte und Zugriffsschutz ein (nicht jeder soll alles fragen dürfen) und entscheiden gemeinsam, wie viel davon on-premise laufen muss.

Wenn ihr eine Wissensbasis habt, die eure Leute täglich durchsuchen — Handbücher, Verträge, Tickets, ein wucherndes Wiki — dann ist RAG vermutlich genau das Werkzeug, das diese Suche abkürzt, ohne dass ihr eure Daten aus der Hand gebt. Schreibt uns unter info@rocket-monkeys.com, schildert kurz, wo bei euch das Wissen klemmt, und wir schauen in einem Erstgespräch gemeinsam, ob und wie sich das mit RAG lösen lässt. Ohne Buzzword-Bingo, versprochen.