RAG für Unternehmenswissen: Firmen-KI mit eigenem Know-how

Was ChatGPT nicht weiß — und warum das ein Problem ist

Ein neuer Mitarbeiter fragt, wie er seine Urlaubstage beantragen kann. Ein Außendienstler will wissen, ob Produkt XY mit System AB kompatibel ist. Ein Vertriebsmitarbeiter sucht den letzten Rahmenvertrag mit Kunde C.

ChatGPT gibt in allen drei Fällen eine generische Antwort — oder keine. Denn große Sprachmodelle (LLMs) wie Claude oder GPT-4 wurden auf öffentlich zugänglichem Text aus dem Internet trainiert. Ihr Unternehmen kommt darin nicht vor. Ihre Prozesse nicht. Ihre Produkte nicht. Ihre Kunden nicht.

Das ist kein Fehler. Es ist die grundlegende Architektur: Wissen ist eingebacken in Modellgewichte, die beim Training festgelegt wurden und sich seitdem nicht verändert haben. Was Ihr Unternehmen nach dem Trainings-Cutoff erlebt hat — neue Produkte, geänderte Prozesse, neue Verträge — ist dem Modell schlicht unbekannt.

Die Konsequenz: Reine LLM-Integration ohne Firmenwissen erzeugt einen Assistenten, der gut klingt, aber nicht hilft. Er formuliert beeindruckend. Er weiß aber nicht, was in Ihrer Servicegarantie steht.

RAG: Das Prinzip dahinter

Retrieval-Augmented Generation (RAG) löst dieses Problem, ohne das Sprachmodell auszutauschen oder neu zu trainieren. Die Idee ist verblüffend einfach: Bevor das Modell antwortet, holt das System aus einer Wissensbasis die relevanten Informationen und legt sie dem Modell als Kontext vor.

Statt zu fragen: „Was weißt du über unsere Urlaubsregelung?" — fragt das System: „Hier ist die aktuelle Betriebsvereinbarung zu Urlaubsregelungen. Beantworte diese Frage auf dieser Grundlage."

Das Sprachmodell bleibt, was es ist: ein leistungsfähiges Werkzeug zum Verstehen und Formulieren. Der Unterschied liegt im Kontext, den es bekommt. RAG gibt dem Modell genau das Wissen, das für die aktuelle Frage relevant ist — nicht alles, nur das Richtige.

Der Unterschied zu Fine-Tuning

Fine-Tuning ist die Alternative, die viele Unternehmen zuerst in Betracht ziehen. Dabei wird das Modell auf firmeneigenen Daten weitertrainiert — das Wissen wird buchstäblich in die Gewichte eingebacken. Das klingt gründlicher, hat aber entscheidende Nachteile:

• Kosten: Ein Fine-Tuning-Lauf auf GPT-4-Niveau kostet fünfstellige Beträge.
• Statik: Ändert sich die Preisliste, muss neu trainiert werden.
• Keine Quellen: Das Modell kann nicht belegen, woher eine Aussage stammt.
• Halluzinationen bleiben: Fine-Tuning reduziert Halluzinationen nicht grundsätzlich.

RAG ist günstiger, aktueller und transparenter. Die Wissensbasis lässt sich täglich aktualisieren. Jede Antwort kann mit Quellenangaben belegt werden. Und das Sprachmodell bleibt durch Anbieter-Updates stets auf aktuellem Stand.

Die drei Komponenten einer RAG-Architektur

Eine produktionstaugliche RAG-Implementierung besteht aus drei Kernkomponenten, die zusammenarbeiten.

1. Embeddings — Text als Zahlenvektor

Embeddings sind die Grundlage von RAG. Ein Embedding-Modell wandelt Text in einen numerischen Vektor um — eine Liste von hunderten bis tausenden Zahlen, die die semantische Bedeutung des Textes kodieren.

Der entscheidende Effekt: Texte mit ähnlicher Bedeutung erhalten ähnliche Vektoren, auch wenn sie unterschiedliche Wörter verwenden. „Wie beantrage ich Urlaub?" und „Urlaubsantrag einreichen" liegen im Vektorraum nah beieinander — klassische Schlüsselwortsuche würde das nicht erkennen.

Jedes Dokument im Firmenwissen wird in Chunks (Abschnitte) aufgeteilt und als Vektor gespeichert. Bei der Suchanfrage wird die Frage ebenfalls eingebettet und mit den gespeicherten Vektoren verglichen. Gute Embedding-Modelle für deutsche Texte sind OpenAIs text-embedding-3-large oder das Open-Source-Modell multilingual-e5-large — letzteres kann on-premise betrieben werden, was für DSGVO-sensitive Daten relevant ist.

2. Vektordatenbank — Wissen dauerhaft speichern

Die eingebetteten Dokumente landen in einer Vektordatenbank. Diese ist auf eine spezielle Aufgabe optimiert: Ähnlichkeitssuche über Millionen von Vektoren in Millisekunden.

Eine Vektordatenbank beantwortet die Frage: „Welche gespeicherten Dokumente sind der aktuellen Anfrage am ähnlichsten?" — und gibt die Top-k Ergebnisse zurück. Das Einspielen neuer Dokumente ist unkompliziert: Chunken, einbetten, in die Datenbank schreiben. Keine Neutrainierung, kein Systemstopp.

3. Retrieval-Pipeline — das Richtige zur richtigen Zeit

Die Retrieval-Pipeline verbindet alle Komponenten:

1. Nutzerfrage einbetten
2. Ähnlichste Dokument-Chunks aus der Vektordatenbank abrufen
3. Relevante Chunks als Kontext in den LLM-Prompt einfügen
4. LLM antwortet ausschließlich auf Grundlage dieses Kontexts

Für viele Anwendungsfälle lohnt es sich, Hybrid-Retrieval einzusetzen: klassische Volltextsuche und Vektorsuche kombiniert, mit einem Re-Ranking-Schritt, der die besten Ergebnisse aus beiden Methoden zusammenführt.

Praxisbeispiel 1: HR-Assistent

Ein mittelständisches Produktionsunternehmen mit 200 Mitarbeitern hat drei Vollzeit-HR-Mitarbeiter. Ein erheblicher Teil ihrer Zeit geht für Standardanfragen drauf: Wie viel Urlaub habe ich noch? Was sind die Regelungen für Homeoffice? Wie melde ich mich krank?

Die Dokumente existieren — Betriebsvereinbarungen, Arbeitsanweisungen, das Mitarbeiterhandbuch. Sie liegen als PDFs im SharePoint. Aber niemand liest SharePoint.

Nach der RAG-Implementierung werden alle relevanten Dokumente eingebettet. Mitarbeiter stellen ihre Fragen in einem internen Chat. Das System sucht in der Wissensbasis und gibt eine strukturierte Antwort mit Quellenangabe — „laut Betriebsvereinbarung §4.2".

Ergebnis: HR bearbeitet 60 Prozent weniger Standardanfragen. Mitarbeiter bekommen Antworten sofort — auch nachts oder am Wochenende. Die HR-Mitarbeiter konzentrieren sich auf die Aufgaben, für die menschliches Urteilsvermögen tatsächlich nötig ist.

Ein ähnliches System lässt sich für den Onboarding-Prozess aufbauen. Neue Mitarbeiter haben hundert Fragen in den ersten Wochen. Ein gut eingerichteter RAG-Assistent beantwortet den Großteil davon — und lernt dabei aus den häufigsten Folgefragen.

Praxisbeispiel 2: Produkt-Support

Ein Maschinenbauer vertreibt komplexe Produktionsanlagen an Industriekunden. Die Serviceabteilung nimmt täglich Dutzende Anrufe entgegen. Die Kernfragen: Welches Ersatzteil passt zu Anlage XY, Baujahr 2019? Wie ist Fehlercode F-447 zu interpretieren? Welches Schmiermittel ist für dieses Lager vorgeschrieben?

Die Antworten stecken in tausenden Seiten technischer Dokumentation — Handbücher, Ersatzteilkataloge, Service-Bulletins. Erfahrene Techniker wissen, wo sie suchen müssen. Neue Mitarbeiter verbringen Stunden damit.

RAG macht dieses Wissen zugänglich: Alle technischen Dokumente werden indiziert. Techniker stellen ihre Fragen in natürlicher Sprache. Das System findet die relevante Passage im richtigen Handbuch und gibt die Antwort mit Seitenangabe aus.

Die erfahrenen Techniker sparen täglich ein bis zwei Stunden. Neue Mitarbeiter werden schneller produktiv. Kunden warten kürzer auf eine Antwort. Eine Erweiterung ist Kundenselbstservice: Ein Teil der Supportanfragen kann der Kunde über ein Webportal direkt klären — das entlastet den Telefonsupport erheblich.

Tool-Überblick: Pinecone, Weaviate und pgvector

Die Wahl der Vektordatenbank hängt von Anforderungen an Skalierung, Infrastruktur und Budget ab.

Für die meisten mittelständischen Anwendungsfälle reicht pgvector aus — wenn bereits PostgreSQL im Einsatz ist, wird kein zusätzliches System benötigt. Weaviate ist die stärkste Open-Source-Option für Hybrid-Retrieval. Pinecone spart Betriebsaufwand, ist aber für DSGVO-sensitive Daten nur mit entsprechenden Auftragsverarbeitungsverträgen einsetzbar.

Framework-seitig hat sich LangChain als Standard für RAG-Anwendungen etabliert, mit umfangreicher Unterstützung für alle gängigen Vektordatenbanken und Embedding-Modelle. LlamaIndex ist eine Alternative mit Fokus auf strukturierte Datenquellen.

Kosten: Was RAG im Mittelstand realistisch kostet

RAG ist kein Millionenprojekt. Ein realistischer Kostenrahmen für ein abgegrenztes Pilotprojekt — ein Anwendungsfall, eine klar definierte Wissensbasis:

Laufende Betriebskosten: Embedding-API 20–100 EUR/Monat, LLM-API 100–500 EUR/Monat, Vektordatenbank 0–200 EUR/Monat. Wer pgvector und Open-Source-Embedding-Modelle kombiniert, kann den Stack on-premise betreiben — zu deutlich niedrigeren Kosten.

Beide Wege qualifizieren für den Digitalbonus Bayern: 50 Prozent der Investition werden gefördert, bis zu 7.500 EUR. Bei einem 12.000-EUR-Projekt bedeutet das eine reale Kostenobergrenze von 6.000 EUR — vorausgesetzt, Sie beantragen die Förderung rechtzeitig vor Projektstart.

DSGVO: Firmenwissen schützen

RAG verarbeitet Firmenwissen — und oft personenbezogene Daten. Die Frage, welche Daten in die Wissensbasis aufgenommen werden, muss vor der Implementierung geklärt sein. Nicht alles, was technisch indizierbar ist, sollte indiziert werden.

Personalakten, Gehaltsdaten und Gesundheitsinformationen gehören in keinen RAG-Index — nicht weil es technisch unmöglich wäre, sondern weil die Rechtsgrundlage fehlt und das Risiko einer unbefugten Weitergabe zu hoch ist. Ausführliche Anforderungen an DSGVO-konforme KI-Systeme finden Sie in unserem Datenschutz-Artikel.

• Zugriffssteuerung: Nicht jeder Nutzer darf jedes Dokument sehen. RAG-Systeme müssen Nutzerrechte auf Retrieval-Ebene durchsetzen — das Modell darf nur Dokumente zurückgeben, auf die der anfragende Nutzer Zugriffsrecht hat.
• Datenhoheit: On-premise oder in einer deutschen Cloud ist cloud-only vorzuziehen, wenn interne Dokumente verarbeitet werden.
• Transparenz: Quellenangaben sind nicht nur für Korrektheit wichtig — sie ermöglichen die Überprüfung und schaffen Vertrauen.
• Datenminimierung: Nur die Dokumente indizieren, die für den Anwendungsfall notwendig sind. Ein HR-Assistent braucht keine technische Dokumentation.
• Löschpflichten: Wenn ein Dokument aus dem Quellsystem gelöscht wird, muss das entsprechende Embedding aus der Vektordatenbank entfernt werden.

Praxistipp: Starten Sie mit einem Anwendungsfall, der ausschließlich nicht-personenbezogene Daten enthält — technische Dokumentation, Produktinformationen, öffentliche Betriebsanweisungen. Das ermöglicht einen schnellen Start ohne umfangreiche Datenschutz-Prüfung.

Fazit: Firmenwissen als KI-Vorteil

LLMs sind mächtige Werkzeuge — aber ohne Zugang zu Firmenwissen bleiben sie Generalisten. RAG schließt die Lücke: schnell, kosteneffizient und ohne Neutraining.

Die Kombination macht den Unterschied: Das Sprachmodell bringt Sprachverständnis und Formulierungsfähigkeit mit. Die Wissensbasis bringt das spezifische Know-how Ihres Unternehmens. Was entsteht, ist ein Assistent, der sowohl versteht als auch weiß — und damit tatsächlich nützlich ist.

Der entscheidende erste Schritt ist nicht die Technologieauswahl, sondern die Anwendungsfalldefinition: Wo in Ihrem Unternehmen steckt wertvolles Wissen in Dokumenten, auf das zu häufig zu langsam zugegriffen wird? Das ist Ihr Pilotprojekt.

Wissen Sie noch nicht, ob Ihre Infrastruktur und Datenbasis für RAG bereit sind? Der KI-Readiness-Check gibt Ihnen eine konkrete Einschätzung — in 10 Minuten.