RAG-Systeme im Unternehmen: Von Theorie zu Produktion

RAG-Systeme im Unternehmenseinsatz: Von der Theorie zur Produktion

Large Language Models wissen viel -- aber nicht alles. Vor allem wissen sie nichts über Ihre internen Dokumente, Ihre Produktdatenbank oder die Notizen Ihres letzten Strategie-Meetings. Retrieval-Augmented Generation (RAG) schliesst diese Lücke: Das System durchsucht Ihre Datenquellen und liefert dem LLM genau den Kontext, den es für eine fundierte Antwort braucht.

Klingt einfach. Ist es in der Theorie auch. In der Praxis scheitern die meisten RAG-Implementierungen nicht am Konzept, sondern an der Umsetzung: falsche Chunking-Strategien, unpassende Embedding-Modelle, fehlende Evaluation. Dieser Artikel ist ein technischer Leitfaden für Unternehmen, die ein RAG-System nicht als Demo, sondern als produktives System bauen wollen.

Was ist Retrieval-Augmented Generation?

RAG kombiniert zwei Fähigkeiten: Information Retrieval (Suche in einer Wissensbasis) und Text Generation (Antwortgenerierung durch ein LLM). Das Konzept wurde erstmals im ursprünglichen RAG-Paper von Lewis et al. beschrieben. Statt das Modell mit allen Unternehmensdaten zu finetunen, wird relevanter Kontext zur Laufzeit abgerufen und in den Prompt injiziert.

Warum RAG und nicht Finetuning?

Finetuning hat seinen Platz -- etwa für domänenspezifische Sprachstile oder spezialisierte Aufgaben. Für den Zugriff auf aktuelle, unternehmensinterne Wissensbestände ist RAG die pragmatischere und kosteneffizientere Lösung.

Architektur eines RAG-Systems

Ein produktives RAG-System besteht aus zwei Pipelines: der Indexierungspipeline (Daten vorbereiten) und der Retrieval-Pipeline (Daten abrufen und Antwort generieren).

Indexierungspipeline

Die Indexierungspipeline bereitet Ihre Unternehmensdaten für die semantische Suche vor:

1. Datenquellen anbinden: Dokumente, Datenbanken, Confluence-Seiten, E-Mails, CRM-Einträge -- alles, was relevantes Wissen enthält.
2. Parsing und Extraktion: PDFs, DOCX, HTML, Markdown in reinen Text umwandeln. Tabellen, Bilder und strukturierte Daten gesondert behandeln.
3. Chunking: Den Text in semantisch sinnvolle Abschnitte zerlegen (mehr dazu im nächsten Abschnitt).
4. Embedding: Jeden Chunk in einen Vektor umwandeln, der seine semantische Bedeutung kodiert.
5. Speicherung: Vektoren und Metadaten in einer Vektordatenbank ablegen.

Retrieval-Pipeline

Wenn ein Nutzer eine Frage stellt, arbeitet die Retrieval-Pipeline:

1. Query-Verarbeitung: Die Nutzerfrage wird in einen Vektor umgewandelt (mit demselben Embedding-Modell wie bei der Indexierung).
2. Semantische Suche: Die Vektordatenbank findet die ähnlichsten Chunks zur Anfrage.
3. Re-Ranking: Optional werden die Ergebnisse durch ein Cross-Encoder-Modell neu sortiert, um die Relevanz zu erhöhen.
4. Prompt-Assembly: Die gefundenen Chunks werden zusammen mit der Nutzerfrage in einen Prompt verpackt.
5. LLM-Inferenz: Das LLM generiert die Antwort basierend auf dem bereitgestellten Kontext.
6. Quellenangabe: Die Antwort enthält Referenzen zu den Quelldokumenten.

Chunking-Strategien: Der unterschätzte Erfolgsfaktor

Die Art, wie Sie Ihre Dokumente in Chunks zerlegen, bestimmt massgeblich die Qualität Ihres RAG-Systems. Ein Chunk, der zu gross ist, verwässert die Relevanz. Ein Chunk, der zu klein ist, verliert den Kontext.

Naive vs. fortgeschrittene Chunking-Strategien

Unsere Empfehlung

Für die meisten Unternehmensanwendungen ist Recursive Character Splitting mit Overlap der beste Einstieg. Konfigurieren Sie:

• Chunk-Size: 512--1024 Token (abhängig vom Embedding-Modell)
• Overlap: 10--20% (verhindert, dass Kontext an Chunk-Grenzen verloren geht)
• Trennzeichen-Hierarchie: \n\n (Absatz) dann \n (Zeile) dann . (Satz) dann (Wort)

Für technische Dokumentation oder stark strukturierte Inhalte lohnt sich der Umstieg auf Document-Structure Chunking, das Überschriften und Abschnittsgrenzen respektiert.

Embedding-Modelle: Den richtigen Vektor-Raum wählen

Das Embedding-Modell übersetzt Text in Vektoren. Die Wahl des Modells beeinflusst direkt, wie gut Ihr System relevante Dokumente findet.

Auswahlkriterien

• Dimensionalität: Mehr Dimensionen erfassen feinere Nuancen, brauchen aber mehr Speicher. 768--1536 Dimensionen sind typisch.
• Mehrsprachigkeit: Für deutsche Unternehmen unverzichtbar. Modelle wie multilingual-e5-large oder text-embedding-3-large (OpenAI) unterstützen Deutsch nativ.
• Max Token-Länge: Bestimmt die maximale Chunk-Grösse. Die meisten Modelle unterstützen 512 Token, neuere bis 8192.
• Retrieval-Benchmarks: Prüfen Sie die Performance auf MTEB (Massive Text Embedding Benchmark) für Ihren Use Case.

Modell-Vergleich

Für DSGVO-sensible Anwendungen ist Self-Hosting entscheidend. Modelle wie multilingual-e5-large oder BGE-M3 laufen problemlos auf einer einzelnen GPU und liefern exzellente Ergebnisse für deutschsprachige Inhalte. Mehr zum Thema DSGVO-konforme KI-Infrastruktur finden Sie in unserem Artikel zu On-Premise-LLMs und DSGVO.

Vektordatenbanken: Wo Ihre Embeddings leben

Die Vektordatenbank speichert Ihre Embeddings und ermöglicht schnelle Ähnlichkeitssuchen. Die Auswahl hängt von Ihren Anforderungen an Skalierung, Hosting und bestehende Infrastruktur ab.

Vergleich der gängigen Optionen

Unsere Einschätzung

Wenn Sie bereits PostgreSQL einsetzen, starten Sie mit pgvector. Es ist kein separater Service, integriert sich nahtlos und reicht für die meisten Unternehmensanwendungen. Sobald Sie Millionen von Vektoren verwalten oder Sub-Millisekunden-Latenz brauchen, lohnt der Wechsel zu Qdrant oder Milvus.

Die Daten-Infrastruktur ist das Fundament jedes RAG-Systems. Ohne saubere Pipelines, die Ihre Datenquellen zuverlässig in die Vektordatenbank speisen, wird auch die beste Retrieval-Strategie scheitern.

Retrieval-Strategien: Über naive Suche hinaus

Die einfachste Retrieval-Strategie ist "Top-K Similarity Search": Die k ähnlichsten Vektoren zur Anfrage abrufen. In der Praxis reicht das selten aus. Fortgeschrittene Strategien verbessern die Qualität erheblich.

Naive RAG vs. Advanced RAG

Schlüsseltechniken im Detail

Query Rewriting: Die Nutzerfrage wird vom LLM umformuliert, um bessere Suchergebnisse zu erzielen. Beispiel: "Wie war der Umsatz?" wird zu "Umsatzentwicklung Q4 2025 im Vergleich zum Vorjahr".

HyDE (Hypothetical Document Embeddings): Das LLM generiert ein hypothetisches Antwortdokument, dessen Embedding für die Suche verwendet wird. Funktioniert besonders gut bei abstrakten Fragen.

Hybrid-Suche: Kombination aus semantischer Vektor-Suche und keyword-basierter BM25-Suche. Fängt Fälle ab, in denen exakte Begriffe (Produktnamen, Artikelnummern) gefragt sind.

Cross-Encoder Re-Ranking: Nach der initialen Suche bewertet ein Cross-Encoder-Modell jedes Dokument-Query-Paar einzeln. Deutlich genauer als Bi-Encoder-Ähnlichkeit, aber langsamer. Wird typischerweise auf die Top-20-Ergebnisse angewendet.

Contextual Compression: Irrelevante Teile der abgerufenen Chunks werden entfernt, bevor sie an das LLM übergeben werden. Spart Token und reduziert Rauschen.

Evaluation: Messen, was zählt

Ein RAG-System ohne Evaluation ist wie ein Auto ohne Tacho. Sie fahren, wissen aber nicht wie schnell oder ob Sie in die richtige Richtung unterwegs sind.

Die drei Dimensionen der RAG-Evaluation

1. Retrieval-Qualität: Findet das System die richtigen Dokumente?

• Precision@K: Wie viele der abgerufenen Dokumente sind relevant?
• Recall@K: Wie viele der relevanten Dokumente werden gefunden?
• MRR (Mean Reciprocal Rank): Auf welcher Position erscheint das erste relevante Dokument?

2. Generierungsqualität: Ist die Antwort korrekt und nützlich?

• Faithfulness: Basiert die Antwort auf den bereitgestellten Quellen? (Keine Halluzinationen)
• Answer Relevance: Beantwortet die Antwort tatsächlich die gestellte Frage?
• Completeness: Enthält die Antwort alle wichtigen Informationen aus den Quellen?

3. End-to-End-Qualität: Wie gut ist das Gesamterlebnis?

• Correctness: Stimmt die Antwort faktisch? (Verglichen mit einem Ground-Truth-Datensatz)
• Latency: Wie lange dauert es von der Frage bis zur Antwort?
• Cost per Query: Was kostet eine einzelne Abfrage (Embedding + Retrieval + LLM)?

Evaluation-Framework aufbauen

Bauen Sie ein Testset mit 50--100 Frage-Antwort-Paaren auf, die reale Nutzeranfragen abbilden. Für jede Frage dokumentieren Sie:

• Die erwartete Antwort
• Die relevanten Quelldokumente
• Die Schwierigkeitskategorie (einfach, mittel, komplex)

Automatisieren Sie die Evaluation mit Tools wie RAGAS, LangSmith oder Langfuse. Führen Sie die Tests bei jeder Änderung an der Pipeline durch -- neue Chunking-Strategie, anderes Embedding-Modell, veränderte Prompts.

Produktion: RAG-Systeme zuverlässig betreiben

Ein RAG-System in der Produktion muss mehr leisten als korrekte Antworten zu liefern. Es muss stabil, überwacht und wartbar sein.

Architektur für den Produktivbetrieb

Caching: Häufig gestellte Fragen und ihre Antworten cachen. Semantisches Caching (ähnliche Fragen erkennen) spart LLM-Kosten und reduziert Latenz.

Monitoring: Überwachen Sie:

• Retrieval-Metriken (Latenz, Ergebnis-Anzahl, Ähnlichkeits-Scores)
• LLM-Metriken (Latenz, Token-Verbrauch, Kosten)
• Nutzerfeedback (Daumen hoch/runter, Eskalationsrate)
• Systemmetriken (CPU, RAM, GPU-Auslastung der Embedding-Server)

Datenaktualität: Definieren Sie, wie oft Ihre Datenquellen re-indexiert werden. Für Dokumenten-basierte Systeme reicht oft ein täglicher Batch-Job. Für Echtzeit-Anforderungen brauchen Sie Change-Data-Capture und inkrementelle Indexierung.

Sicherheit: Implementieren Sie rollenbasierte Zugriffssteuerung (RBAC) auf Dokumentenebene. Ein Nutzer darf nur Antworten erhalten, die auf Dokumenten basieren, für die er Leseberechtigung hat. Das erfordert Metadaten-Filter in der Vektordatenbank.

Skalierung

Für den Einstieg reicht eine einzige Instanz Ihrer Vektordatenbank und ein Embedding-Server. Bei wachsendem Volumen:

• Horizontales Skalieren: Mehrere Embedding-Server hinter einem Load Balancer
• Sharding: Vektordatenbank über mehrere Nodes verteilen
• Async-Processing: Indexierungsjobs asynchron über eine Message Queue (z.B. Redis, RabbitMQ)
• Read Replicas: Für Leseoperationen separate Replikas der Vektordatenbank

Häufige Fehler und wie Sie sie vermeiden

Aus unserer Projektarbeit bei IJONIS kennen wir die typischen Stolpersteine:

1. Chunking ignorieren. Die Standard-Einstellungen des Frameworks verwenden und sich wundern, dass die Retrieval-Qualität schlecht ist. Investieren Sie Zeit in die Chunking-Strategie -- sie hat mehr Einfluss auf das Ergebnis als die Wahl des LLMs.

2. Kein Re-Ranking. Die Top-K-Ergebnisse einer Vektor-Suche sind oft "thematisch richtig, inhaltlich daneben". Ein Cross-Encoder Re-Ranker verbessert die Precision typischerweise um 15--30%.

3. Zu grosse Chunks. Mehr Kontext ist nicht immer besser. Chunks über 1024 Token verwässern die Relevanz und kosten mehr Token beim LLM.

4. Fehlende Metadaten. Ohne Metadaten (Quelle, Datum, Abteilung, Dokumenttyp) können Sie nicht filtern, nicht priorisieren und nicht nachvollziehen, woher eine Antwort kommt.

5. Evaluation als Nachgedanke. Ohne Evaluation vor dem Go-Live wissen Sie nicht, ob Ihr System in der Praxis funktioniert. Bauen Sie das Evaluation-Framework parallel zur ersten Pipeline auf.

6. One-Shot-Indexierung. Daten einmal indexieren und vergessen. Unternehmenswissen ändert sich. Planen Sie automatische Re-Indexierung und Datenqualitäts-Checks ein. Warum die Daten-Infrastruktur das Fundament jeder KI-Initiative ist, haben wir in einem separaten Artikel beschrieben -- lesen Sie dazu auch unseren Beitrag zur Dateninfrastruktur für KI.

FAQ: RAG-Systeme im Unternehmenseinsatz

Was kostet ein RAG-System im Betrieb?

Die Betriebskosten hängen vom Volumen ab. Für ein mittelständisches Unternehmen mit 10.000--50.000 Dokumenten und 500--1.000 Anfragen pro Tag rechnen Sie mit: Embedding-API (50--200 EUR/Monat), Vektordatenbank-Hosting (100--500 EUR/Monat), LLM-API für Antwortgenerierung (200--1.000 EUR/Monat). Gesamt: 350--1.700 EUR/Monat. Self-Hosted-Setups mit eigenen GPUs reduzieren die variablen Kosten, erhöhen aber den initialen Investitionsbedarf.

Wie viele Dokumente kann ein RAG-System verarbeiten?

Technisch gibt es keine feste Obergrenze. Moderne Vektordatenbanken wie Milvus oder Qdrant skalieren auf Milliarden von Vektoren. Praktisch wird die Herausforderung bei Millionen von Dokumenten die Datenqualität und die Indexierungsgeschwindigkeit. Wichtiger als die Menge ist die Qualität: 1.000 gut gepflegte, aktuelle Dokumente liefern bessere Ergebnisse als 100.000 veraltete.

Brauche ich ein RAG-System oder reicht ein Chatbot mit langem Kontext?

LLMs mit grossen Kontextfenstern (128K--1M Token) können tatsächlich viele Dokumente gleichzeitig verarbeiten. Für kleine, statische Dokumentensets kann das reichen. RAG wird überlegen, wenn: die Datenmenge das Kontextfenster übersteigt, Daten regelmässig aktualisiert werden, Sie nachvollziehen müssen, welche Quelle die Antwort stützt, oder die Kosten pro Anfrage relevant sind (weniger Token = günstiger).

Wie gehe ich mit mehrsprachigen Inhalten um?

Verwenden Sie ein mehrsprachiges Embedding-Modell (z.B. multilingual-e5-large oder BGE-M3). Diese Modelle bilden semantisch ähnliche Texte in verschiedenen Sprachen nah beieinander im Vektor-Raum ab. Eine deutsche Frage findet so auch relevante englische Dokumente. Für die Antwortgenerierung instruieren Sie das LLM, in der Sprache des Nutzers zu antworten. Bei IJONIS implementieren wir dies als Standard für unsere deutschsprachigen Kunden, die auch englischsprachige Fachliteratur nutzen.

Kann ich ein RAG-System mit bestehenden KI-Agenten kombinieren?

Absolut -- RAG ist eine der wichtigsten Fähigkeiten, die ein KI-Agent haben kann. Der Agent nutzt RAG als Tool: Er formuliert die Suchanfrage, interpretiert die Ergebnisse und entscheidet, ob er weitere Informationen braucht oder die Antwort ausreichend ist. Diese Kombination aus autonomem Handeln und kontextbasiertem Wissen macht Agenten mit RAG-Zugang besonders leistungsfähig.

Fazit: RAG ist kein Feature, sondern Architektur

Ein RAG-System ist mehr als ein Plugin für Ihr LLM. Es ist eine Architekturentscheidung, die Daten-Pipelines, Infrastruktur, Sicherheit und Evaluation umfasst. Der Unterschied zwischen einer Demo und einem produktiven System liegt in den Details: der Chunking-Strategie, dem Embedding-Modell, dem Re-Ranking, dem Monitoring.

Die gute Nachricht: Sie müssen nicht alles auf einmal bauen. Starten Sie mit einem klar definierten Use Case, einer überschaubaren Dokumentenmenge und einer soliden Evaluation. Dann iterieren Sie.

Bereit, Ihr Unternehmenswissen für KI zugänglich zu machen? Lassen Sie uns gemeinsam Ihre Daten-Infrastruktur analysieren -- wir identifizieren die richtigen Datenquellen, wählen die passende Architektur und bauen ein RAG-System, das in der Produktion besteht.