RAG erklärt: Wie KI mit Ihren eigenen Firmendaten arbeitet

Viele Unternehmen testen KI-Tools und stoßen schnell auf dasselbe Problem: Das Modell kennt keine internen Dokumente, keine aktuellen Preislisten, keine Unternehmensrichtlinien. Retrieval Augmented Generation, kurz RAG, löst genau dieses Problem. Dieser Artikel erklärt, wie RAG funktioniert, wo es in der Praxis sinnvoll ist und was Sie bei der Einführung beachten müssen.

Was RAG Ist Und Warum Klassische KI Hier An Ihre Grenzen Stösst

Ein Large Language Model wie GPT-4 oder Claude wurde auf öffentlich verfügbaren Daten trainiert. Es kennt allgemeines Weltwissen, Programmiersprachen, Fachliteratur. Es kennt nicht Ihren Lieferantenvertrag vom März, Ihre internen Prozesshandbücher oder die aktuelle Version Ihrer Produktdokumentation. Das ist kein Fehler des Modells, sondern ein strukturelles Merkmal aller vortrainierten Sprachmodelle.

Das Ergebnis in der Praxis: Wenn Mitarbeitende solche Modelle mit unternehmensinternen Fragen konfrontieren, improvisiert die KI. Sie generiert plausibel klingende, aber faktisch falsche Antworten. In der Forschung nennt man das Halluzination. Für Unternehmen ist das ein ernstes Problem, besonders wenn Antworten in Kundenkommunikation, Vertragsprüfung oder Compliance-Fragen einfließen.

RAG ist ein Architekturprinzip, das dieses Problem strukturell behebt. Statt die KI mit mehr Trainingsdaten zu versorgen, verbindet RAG das Modell dynamisch mit einer externen Wissensbasis. Die KI „lernt“ die Firmendaten also nicht dauerhaft, sondern ruft sie zum Zeitpunkt der Anfrage gezielt ab. Das Ergebnis sind Antworten, die auf echten, aktuellen Dokumenten basieren und sich im besten Fall auch belegen lassen.

Für KI-Integration im Unternehmen ist RAG heute eine der meistgenutzten Architekturen, weil sie einen guten Mittelweg zwischen Leistung, Aktualität und Kontrollierbarkeit bietet.

Wie RAG Technisch Funktioniert

flowchart LR
    A[Nutzeranfrage] --> B[Anfrage analysieren]
    B --> C[Vektordatenbank durchsuchen]
    C --> D[Relevante Chunks abrufen]
    D --> E[Kontext an LLM übergeben]
    E --> F[Antwort generieren]
    F --> G[Antwort mit Quellenangabe]

RAG läuft in drei klar trennbaren Phasen ab. Das Verständnis dieser Phasen ist wichtig, um spätere Entscheidungen bei der Implementierung zu treffen.

In der ersten Phase, dem Retrieval, analysiert das System die eingehende Nutzerfrage und durchsucht eine vorbereitete Wissensbasis nach relevanten Textpassagen. Diese Suche funktioniert nicht wie eine klassische Stichwortsuche. Stattdessen wird die Anfrage in einen mathematischen Vektor umgewandelt, einen numerischen Repräsentationsraum, in dem semantisch ähnliche Aussagen nah beieinanderliegen. Die Datenbank enthält ebenfalls vektorisierte Textabschnitte, sogenannte Chunks, aus Ihren Dokumenten. Das System findet dann die Chunks, die der Anfrage semantisch am nächsten liegen, also inhaltlich am relevantesten sind, auch wenn die genauen Wörter nicht übereinstimmen.

In der zweiten Phase, der Augmentation, werden diese abgerufenen Textpassagen als zusätzlicher Kontext an das Sprachmodell übergeben. Das Modell erhält also nicht nur die Frage des Nutzers, sondern auch die passenden Dokumentausschnitte aus Ihrer eigenen Wissensbasis.

In der dritten Phase generiert das Modell eine Antwort. Es fasst die gefundenen Informationen zusammen, beantwortet die Frage und kann dabei auf die Quelldokumente verweisen. Der entscheidende Unterschied zu einer Standard-KI: Das Modell „erfindet“ keine Antwort, sondern stützt sich auf konkret vorliegende Textinhalte.

Damit das System gut funktioniert, müssen die Ausgangsdokumente vor der Indexierung aufbereitet werden. Schlecht strukturierte PDFs, eingescannte Dokumente ohne Texterkennung oder Dokumente ohne sinnvolle Gliederung führen zu schlechten Retrieval-Ergebnissen. Das ist einer der häufigsten Stolpersteine in der Praxis, auf den wir weiter unten eingehen.

Welche Datenquellen RAG Verarbeiten Kann

flowchart TD
    A[Firmenwissen] --> B[Strukturierte Daten]
    A --> C[Unstrukturierte Dokumente]
    A --> D[Systeme & Datenbanken]
    B --> E[ERP-Daten]
    B --> F[CRM-Einträge]
    B --> G[Tabellen & Excel]
    C --> H[PDFs & Word-Dokumente]
    C --> I[Wikis & Confluence]
    C --> J[E-Mails & Berichte]
    D --> K[SharePoint]
    D --> L[Google Drive]
    D --> M[Interne APIs]

Eine der häufigsten Fragen in Beratungsgesprächen lautet: Welche unserer Daten kann RAG überhaupt verarbeiten? Die Antwort ist breiter als die meisten erwarten.

RAG kann mit nahezu jeder Textquelle arbeiten, die sich in digitale, lesbare Form bringen lässt. In der Praxis sind das häufig interne Wikis auf Confluence oder SharePoint, PDF-Dokumente wie Handbücher, Verträge oder Prozessbeschreibungen, Word- und Excel-Dateien, Intranet-Seiten, E-Mail-Archive oder Wissensdatenbanken im Kundendienst. Darüber hinaus lassen sich strukturierte Daten aus ERP- oder CRM-Systemen einbinden, wenn sie über Schnittstellen zugänglich sind.

Entscheidend ist nicht, in welchem Format die Daten vorliegen, sondern wie gut sie strukturiert sind. Ein PDF mit eingescannten handschriftlichen Notizen ist für RAG zunächst unbrauchbar, weil kein maschinenlesbarer Text vorhanden ist. Hier ist eine vorgelagerte Texterkennung notwendig. Ein gut gepflegtes Confluence-Wiki dagegen lässt sich direkt und zuverlässig indexieren.

In der Beratungspraxis sehen wir häufig, dass Unternehmen ihren Wissensstand unterschätzen. Sie haben hunderte von Dokumenten, die intern als „Chaos“ wahrgenommen werden, in denen aber tatsächlich wertvolles, strukturiertes Wissen steckt. Für RAG ist Vollständigkeit weniger wichtig als Qualität. Zehn präzise und aktuelle Dokumente liefern bessere Ergebnisse als zweihundert veraltete oder widersprüchliche Dateien.

Konkrete Anwendungsfälle Für KMUs

Es hilft, RAG nicht als technisches Konzept zu betrachten, sondern als Antwort auf konkrete Alltagsprobleme. Ein typisches Muster bei KMUs ist folgendes: Der Wissenszugang ist personenabhängig. Wenn die erfahrene Mitarbeiterin im Urlaub ist, weiß niemand, wie ein bestimmtes Kundenanliegen zu behandeln ist. RAG kann dieses Wissen zugänglich machen, vorausgesetzt, es wurde dokumentiert und indexiert.

Im Kundendienst kann ein RAG-System eingehende Anfragen automatisch gegen Produktdokumentation, FAQ-Datenbanken und frühere Ticketlösungen abgleichen und dem Mitarbeitenden einen Antwortentwurf liefern. Das reduziert die Bearbeitungszeit und verbessert die Konsistenz der Antworten, weil sich alle auf dieselbe Wissensquelle stützen.

Im HR-Bereich kann ein RAG-System Mitarbeitenden Fragen zu Urlaubsregelungen, Onboarding-Prozessen oder Vergütungsstrukturen beantworten, ohne dass jedes Mal die Personalabteilung kontaktiert werden muss. Das System antwortet auf Basis der aktuell geltenden Betriebsvereinbarungen und Richtlinien.

Im Vertrieb können Außendienstmitarbeitende in Echtzeit auf aktuelle Produktspezifikationen, Preislisten oder Wettbewerbsvergleiche zugreifen, auch unterwegs per Mobilgerät. Statt in E-Mails zu suchen oder auf einen Rückruf zu warten, stellt das RAG-System die Information zusammen.

In der Qualitätssicherung und im Compliance-Bereich kann RAG dabei helfen, interne Prozessdokumente schnell gegen aktuelle Normen oder regulatorische Anforderungen abzugleichen. Wer wissen möchte, welche Anforderungen der EU AI Act an seine KI-Systeme stellt, findet in unserem Artikel zum EU AI Act 2026 einen guten Überblick über die regulatorischen Rahmenbedingungen.

So Implementieren Sie RAG In Der Praxis

Eine erfolgreiche RAG-Implementierung folgt keinem starren Schema, aber es gibt eine bewährte Abfolge, die in der Beratungspraxis gut funktioniert.

Der erste Schritt ist die Bestandsaufnahme der Datenquellen. Sie müssen wissen, wo Ihr Firmenwissen tatsächlich liegt. In vielen KMUs ist das eine Mischung aus SharePoint, lokalen Laufwerken, E-Mail-Postfächern und dem Kopfwissen einzelner Mitarbeitender. Für RAG können Sie nur das nutzen, was dokumentiert und digital zugänglich ist. Das macht diesen Schritt manchmal auch zu einem Impuls, Dokumentationslücken zu schließen, bevor das technische System gebaut wird.

Der zweite Schritt ist die Datenvorbereitung. Dokumente werden bereinigt, in sinnvolle Textabschnitte zerlegt und mit Metadaten versehen, etwa Erstellungsdatum, Dokumenttyp oder Abteilung. Diese Metadaten helfen später beim Filtern der Suchergebnisse. Ein Chunk aus einem veralteten Prozesshandbuch von 2019 sollte weniger Gewicht bekommen als die aktuelle Version von 2024. Diese Vorverarbeitung ist technisch aufwendig, aber entscheidend für die Qualität des Gesamtsystems.

Der dritte Schritt ist der Aufbau der Vektordatenbank. Hier werden die Chunks vektorisiert und gespeichert. Gängige Open-Source-Lösungen sind Chroma, Weaviate oder Qdrant. Kommerzielle Anbieter wie Pinecone bieten verwaltete Lösungen mit einfacherer Infrastruktur, aber höheren laufenden Kosten. Für den Einstieg in kleineren Umgebungen ist Chroma eine pragmatische Wahl, weil es lokal betrieben werden kann und keine Cloud-Abhängigkeit entsteht.

Der vierte Schritt ist die Anbindung des Sprachmodells. Hier entscheiden Sie, welches LLM Sie nutzen möchten und ob es lokal, in einer privaten Cloud oder über einen externen API-Anbieter betrieben wird. Für datensensible Umgebungen empfehlen wir lokale Modelle oder Private-Cloud-Setups, weil Firmendaten nicht über externe API-Verbindungen verarbeitet werden sollten. Modelle wie Llama 3 von Meta oder Mistral können auf eigener Infrastruktur betrieben werden und liefern für viele RAG-Anwendungen ausreichend gute Ergebnisse.

Der fünfte Schritt ist der Aufbau der Governance-Strukturen. Das bedeutet: Wer darf welche Daten abfragen? Ein Mitarbeitender aus dem Vertrieb sollte keinen Zugriff auf vertrauliche Gehaltsdaten aus dem HR-Bereich haben, auch wenn beide Datensätze im selben RAG-System liegen. Zugriffskontrollen müssen auf Dokumentebene implementiert werden, nicht nur auf Systemebene. Außerdem brauchen Sie einen Prozess, der sicherstellt, dass die Wissensbasis regelmäßig aktualisiert wird. Veraltete Dokumente in der Wissensbasis führen zu veralteten Antworten, manchmal ohne dass der Nutzer das bemerkt.

Der sechste Schritt ist der Pilotbetrieb. Starten Sie mit einem eng definierten Anwendungsfall und einer überschaubaren Dokumentenbasis. Messen Sie die Qualität der Antworten systematisch. Gute Metriken dafür sind Retrieval-Präzision (Wie relevant sind die gefundenen Chunks?), Antwortgenauigkeit (Stimmt die Antwort mit dem Quelldokument überein?) und Nutzerakzeptanz. Erst wenn der Pilot stabile Ergebnisse liefert, skalieren Sie auf weitere Datenquellen und Anwendungsfälle.

Häufige Fehler Und Wie Sie Diese Vermeiden

Schlechte Datenqualität ist der häufigste Grund, warum RAG-Projekte nicht die erwarteten Ergebnisse liefern. Wenn die Dokumente in der Wissensbasis unvollständig, widersprüchlich oder schlecht strukturiert sind, spiegelt das die Antwortqualität wider. RAG kann kein schlechtes Dokumentenmanagement kompensieren, es macht es nur sichtbarer.

Ein zweiter Fehler ist die fehlende Governance nach dem Go-live. Viele Teams bauen das System, spielen die initialen Dokumente ein und lassen das System dann laufen. Dokumente veralten, neue Richtlinien entstehen, Produkte ändern sich. Ohne automatisierte Synchronisation zwischen der Ursprungsdatenquelle und der RAG-Wissensbasis driften System und Realität auseinander. In der Praxis zeigt sich, dass automatisierte Sync-Prozesse, die beispielsweise täglich oder wöchentlich laufen, dieses Problem deutlich reduzieren.

Ein dritter Fehler ist die Überladung des Systems mit zu vielen Dokumenten ohne Relevanzfilter. Wenn das System bei jeder Anfrage tausende von Chunks durchsucht, leidet die Qualität des Retrievals. Besser ist es, die Wissensbasis thematisch zu segmentieren und Nutzeranfragen gezielt in den richtigen Bereich zu lenken, bevor die Suche startet.

Ein vierter Fehler betrifft den Datenschutz. Wer Firmendaten über externe APIs an kommerzielle LLM-Anbieter sendet, muss genau prüfen, ob das mit der DSGVO und internen Datenschutzrichtlinien vereinbar ist. Das gilt besonders für personenbezogene Daten, Geschäftsgeheimnisse oder vertrauliche Vertragsinhalte. Unser Artikel zur DSGVO-konformen KI-Automatisierung behandelt diese Fragen ausführlicher.

Die sicherste Lösung für datensensible Umgebungen ist ein vollständig on-premise Betrieb, bei dem weder die Vektordatenbank noch das Sprachmodell externe Verbindungen benötigen. Das ist technisch aufwendiger und teurer, aber in regulierten Branchen wie Finanzdienstleistung, Gesundheitswesen oder öffentlicher Verwaltung häufig die einzige akzeptable Option.

RAG Im Vergleich Zu Alternativen Ansätzen

Es ist sinnvoll, RAG in Relation zu anderen Methoden zu verstehen, die dasselbe Ziel verfolgen: KI mit Firmenwissen auszustatten.

Fine-Tuning ist eine Alternative, bei der ein Sprachmodell auf Basis eigener Daten nachtrainiert wird. Das bedeutet, das Modell lernt unternehmenssspezifisches Vokabular, Schreibstil oder Domänenwissen dauerhaft. Fine-Tuning ist aufwendig, teuer und erfordert regelmäßige Wiederholung, wenn sich die Datenlage ändert. Es eignet sich gut für stilistische Anpassungen oder sehr spezifische Domänen, aber schlecht für häufig wechselnde oder aktuelle Informationen. RAG ist in den meisten Unternehmenskontexten flexibler und kostengünstiger.

Reines Prompt Engineering, also das Einfügen von Firmendaten direkt in den Prompt, funktioniert für kleine Datenmengen. Wenn Sie dem Modell zehn Seiten Kontext mitgeben, kann es damit arbeiten. Aber Sprachmodelle haben begrenzte Kontextfenster, und selbst große Fenster von 100.000 oder mehr Token sind bei umfangreichen Wissensdatenbanken schnell ausgeschöpft. Außerdem skaliert dieser Ansatz nicht: Bei tausend Dokumenten können Sie nicht alle gleichzeitig in den Prompt laden.

RAG kombiniert das Beste aus beiden Welten. Es nutzt ein unmodifiziertes oder leicht angepasstes Basismodell und ergänzt es dynamisch mit relevantem Kontext. Das hält die Infrastruktur überschaubar und ermöglicht es, die Wissensbasis unabhängig vom Modell zu aktualisieren.

Wer einen strukturierten Einstieg in das Thema KI-Strategie sucht, findet in unserem Artikel zum 90-Tage-Fahrplan für die KI-Strategie einen guten Rahmen, um RAG in eine breitere Digitalstrategie einzubetten.

Tools Und Technologien Im Überblick

Der Markt für RAG-Infrastruktur entwickelt sich schnell. Für Einsteiger empfiehlt sich LangChain als Framework-Schicht, die Vektordatenbank, LLM-Anbindung und Retrieval-Logik in einem strukturierten Rahmen verbindet. LlamaIndex ist eine Alternative mit stärkerem Fokus auf Dokumentenverarbeitung und eignet sich gut, wenn die Datenquellen besonders heterogen sind.

Für die Vektordatenbank sind Chroma (kostenlos, lokal betreibbar), Weaviate (Open Source, auch als verwalteter Service verfügbar) und Qdrant (Open Source, performant bei großen Datenmengen) die meistgenutzten Optionen im KMU-Umfeld. Pinecone ist eine vollständig verwaltete Cloud-Lösung mit einfachem Einstieg, kostet aber ab etwa 70 US-Dollar pro Monat für produktionsreife Setups und kann bei hohem Datendurchsatz deutlich teurer werden.

Für das LLM haben Sie grundsätzlich zwei Wege. Externe API-Anbieter wie OpenAI (GPT-4o, ca. 2,50 US-Dollar pro Million Input-Token, Stand 2025), Anthropic (Claude 3.5 Sonnet) oder Google (Gemini 1.5 Pro) bieten einfachen Einstieg und gute Qualität, erfordern aber sorgfältige Datenschutzprüfung. Lokale Modelle wie Llama 3.1 (Meta, kostenlos nutzbar) oder Mistral 7B laufen auf eigener Hardware und schicken keine Daten nach außen. Die Hardwarekosten für einen leistungsfähigen Server mit ausreichend VRAM liegen im fünfstelligen Bereich, sind aber eine einmalige Investition.

Für einfachere Anwendungsfälle ohne eigene Entwicklungskapazitäten gibt es inzwischen auch schlüsselfertige Lösungen wie Microsoft Copilot for Microsoft 365, das RAG über SharePoint und OneDrive ermöglicht. Der Preis liegt bei etwa 30 US-Dollar pro Nutzer und Monat zusätzlich zu den bestehenden Microsoft-365-Lizenzen. Das ist ein pragmatischer Einstieg für Unternehmen, die bereits tief in der Microsoft-Welt verankert sind, bietet aber weniger Flexibilität als eine individuelle RAG-Architektur.

Was RAG Kann Und Was Nicht

Ein ehrliches Bild von RAG gehört zu einer soliden Beratung. RAG ist kein Allheilmittel und hat eigene Grenzen.

RAG ist so gut wie seine Wissensbasis. Wenn ein Dokument falsch, veraltet oder unvollständig ist, liefert das System eine falsch, veraltete oder unvollständige Antwort. Das klingt trivial, wird aber in der Praxis häufig unterschätzt. Der Aufwand für Datenvorbereitung und laufende Pflege ist erheblich und wird in vielen Projekten zu niedrig angesetzt.

RAG funktioniert gut bei faktenorientierten Fragen, die sich auf vorhandene Dokumente beziehen. Es funktioniert schlechter bei komplexen Schlussfolgerungsaufgaben, die über den abgerufenen Kontext hinausgehen, oder bei Aufgaben, die kreatives Denken erfordern. Wenn ein Nutzer das System fragt, welche strategische Entscheidung das Unternehmen in einer bestimmten Situation treffen sollte, gibt es dafür vermutlich kein geeignetes Quelldokument. Das Modell wird trotzdem eine Antwort generieren, aber diese Antwort basiert dann wieder mehr auf Trainingswissen als auf Firmendaten.

Außerdem ist RAG kein Ersatz für strukturiertes Wissensmanagement. Wer heute kein gepflegtes Dokumentensystem hat, kann RAG nicht als Abkürzung nutzen. Das System zwingt Unternehmen dazu, zuerst in Ordnung zu bringen, was sie wissen und wie sie es dokumentieren. Das ist oft ein größerer organisatorischer als technischer Aufwand.

Fazit

RAG ist heute die praktischste Methode, um Sprachmodelle mit echtem Firmenwissen zu verbinden. Es reduziert Halluzinationen, ermöglicht Quellenangaben und lässt sich aktuell halten, ohne das Modell neu zu trainieren. Für KMUs mit gewachsenen Dokumentenlandschaften bietet RAG einen realistischen Einstieg in produktive KI-Nutzung, vorausgesetzt, die Datenbasis ist gepflegt und die Governance stimmt. Der technische Aufwand ist überschaubar, wenn man mit einem klar eingegrenzten Pilotprojekt startet. Der organisatorische Aufwand für Datenvorbereitung und laufende Pflege wird dagegen häufig unterschätzt. Wer beides realistisch einplant, kann RAG zu einem echten Arbeitswerkzeug machen, das tatsächlich im Alltag genutzt wird. Vereinbaren Sie ein kostenloses Erstgespräch mit uns, um zu klären, welche Ihrer Datenquellen sich für einen RAG-Piloten eignen und wie ein realistischer Fahrplan aussieht.

Sven Kasek ist KI-Berater in Berlin und unterstützt KMUs und mittelständische Unternehmen dabei, KI-Technologien wie RAG strukturiert und datenschutzkonform einzuführen.