Wie funktioniert RAG? Retrieval Augmented Generation für Unternehmensdaten

Was ist RAG und warum braucht man das?

Large Language Models können Texte zusammenfassen, Fragen beantworten und Code schreiben, aber sie haben ein fundamentales Problem: Sie wissen nichts über deine Daten. Ein LLM wurde auf öffentlich verfügbaren Texten trainiert und kennt Wikipedia, Stack Overflow und tausende Bücher. Was es nicht kennt, sind die internen Prozessdokumente deines Unternehmens, die Verträge aus dem letzten Quartal oder die E-Mail-Korrespondenz mit einem bestimmten Kunden.

Fine-Tuning löst das Problem nicht wirklich. Selbst wenn du ein Modell auf deinen Daten nachtrainierst, bleibt das Wissen statisch und jedes neue Dokument erfordert ein erneutes Training, was in der Praxis nicht skaliert.

Retrieval Augmented Generation löst das anders. Statt das Wissen ins Modell zu pressen, holen wir die relevanten Informationen zur Laufzeit aus einer externen Datenquelle und geben sie dem LLM als Kontext mit.

Das Prinzip ist simpel:

1. Der Nutzer stellt eine Frage

2. Wir suchen die relevantesten Dokumente oder Textabschnitte

3. Wir packen diese als Kontext in den Prompt

4. Das LLM generiert eine Antwort basierend auf dem mitgelieferten Kontext

Klingt einfach. Ist es aber nicht. Denn die Qualität der Antwort steht und fällt mit der Qualität des Retrievals. Wenn du die falschen Dokumente findest oder relevante Passagen übersiehst, kann das beste LLM der Welt keine korrekte Antwort liefern.

In diesem Artikel gehen wir durch die gesamte Pipeline: vom Rohformat eines PDFs bis zur fertigen Antwort mit Quellenangabe.

Die Indexing Pipeline

Bevor du eine einzige Frage stellen kannst, müssen deine Dokumente aufbereitet und indexiert werden. Die Indexing Pipeline ist der Teil, der einmal pro Dokument läuft und alles vorbereitet, was die Suche später braucht.

┌─────────────┐    ┌───────────┐    ┌───────────┐    ┌───────────┐    ┌──────────────────┐
│  Documents  │───▶│  Parsing  │───▶│ Chunking  │───▶│ Embedding │───▶│  Vector Store    │
│             │    │           │    │           │    │           │    │  + BM25 Index    │
│ PDF, DOCX,  │    │ Text +    │    │ Semantic  │    │ Dense     │    │                  │
│ Excel, HTML │    │ Metadata  │    │ oder Fixed│    │ Vectors   │    │  Hybrid Search   │
│ E-Mail, ... │    │ Extrakt.  │    │ Size      │    │ (768-dim) │    │  Ready           │
└─────────────┘    └───────────┘    └───────────┘    └───────────┘    └──────────────────┘

Step 1: Parsing

Unternehmensdaten liegen selten als sauberer Plaintext vor. Du hast PDFs (teils gescannt, teils digital), Word-Dokumente mit komplexen Formatierungen, Excel-Sheets mit Tabellendaten, HTML-Seiten und E-Mails mit Anhängen.

Der Parser muss aus all diesen Formaten strukturierten Text extrahieren. Das klingt trivial, ist es aber nicht:

• PDF-Dateien können Text als Vektorgrafik rendern. Dann brauchst du OCR.
• Tabellen in Word oder Excel verlieren ihre Struktur, wenn du sie naiv als Fließtext extrahierst.
• E-Mails enthalten Metadaten (Absender, Datum, Betreff), die für die Suche hochrelevant sind.
• Bilder und Diagramme in Dokumenten enthalten oft kritische Informationen, die ohne Vision-Modelle oder OCR verloren gehen.

Ein guter Parser extrahiert nicht nur den Text, sondern auch Metadaten: Dateiname, Erstellungsdatum, Autor, Seitenzahl, Dokumenttyp. Diese Metadaten werden später für Filterung und Ranking gebraucht.

Step 2: Chunking

Ein typisches Unternehmensdokument hat 10, 50 oder 200 Seiten. Du kannst nicht das gesamte Dokument in den Kontext eines LLMs packen. Selbst bei Modellen mit großem Context Window wäre das ineffizient und würde die Antwortqualität verschlechtern, weil das Modell in einer Masse an irrelevantem Text nach der Nadel im Heuhaufen suchen muss.

Also zerlegen wir Dokumente in Chunks: kleinere, semantisch sinnvolle Textabschnitte. Das ist einer der kritischsten Schritte der gesamten Pipeline, und wir gehen im nächsten Abschnitt im Detail darauf ein.

Step 3: Embedding

Jeder Chunk wird durch ein Embedding Model in einen hochdimensionalen Vektor mit typischerweise 768 oder 1024 Dimensionen überführt, der die semantische Bedeutung des Textes repräsentiert. Zwei Texte die inhaltlich ähnlich sind liegen im Vektorraum nahe beieinander, selbst wenn sie völlig unterschiedliche Wörter verwenden. „Mitarbeiterkündigung" und „Beendigung des Arbeitsverhältnisses" haben kaum Wortüberlappung, aber ihre Embedding-Vektoren sind fast identisch.

Für deutsche Unternehmensdaten ist die Wahl des Embedding Models entscheidend, weil nicht jedes Modell Deutsch gleich gut versteht und multilinguale Modelle oft Schwächen bei Fachsprache haben. SOTA Open Source Modelle liefern hier inzwischen sehr gute Ergebnisse.

Step 4: Indexierung

Die generierten Vektoren landen in einem Vector Store, einer spezialisierten Datenbank für Ähnlichkeitssuchen. Gleichzeitig bauen wir einen BM25-Index über die Rohtexte der Chunks auf. Warum beides? Das erklären wir im Abschnitt zu Hybrid Search.

Chunking Strategies im Detail

Chunking klingt nach einem gelösten Problem. Text in Stücke schneiden, fertig. In der Praxis ist es einer der größten Hebel für die Qualität deines RAG-Systems.

Warum Chunk Size wichtig ist

Zu kleine Chunks verlieren den Kontext. Wenn ein Absatz in der Mitte durchgeschnitten wird, fehlt dem LLM die Information, worauf sich „diese Regelung" oder „der oben genannte Paragraph" bezieht.

Zu große Chunks verwässern die Relevanz. Wenn ein Chunk drei verschiedene Themen abdeckt, matched er auf viele Queries, ist aber für keine wirklich präzise.

Die gängigen Strategien

Fixed Size Chunking

Die einfachste Variante. Du definierst eine maximale Token-Anzahl pro Chunk und schneidest den Text entsprechend.

Dokument: "Lorem ipsum dolor sit amet, consectetur adipiscing elit.
           Sed do eiusmod tempor incididunt ut labore..."

Fixed Size (10 Tokens):
  Chunk 1: "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do"
  Chunk 2: "eiusmod tempor incididunt ut labore..."

Fixed Size + Overlap (10 Tokens, 3 Overlap):
  Chunk 1: "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do"
  Chunk 2: "elit. Sed do eiusmod tempor incididunt ut labore..."

Overlap ist fast immer eine gute Idee. Es stellt sicher, dass Informationen an Chunk-Grenzen nicht verloren gehen. Ein Overlap von 10-20% der Chunk-Größe ist ein guter Ausgangspunkt.

Semantic Chunking

Hier wird es interessanter. Statt nach fester Größe zu splitten, berechnen wir die semantische Ähnlichkeit zwischen aufeinanderfolgenden Sätzen. Wenn die Ähnlichkeit unter einen Schwellenwert fällt, setzen wir einen Split-Punkt.

Satz 1: "Das Unternehmen wurde 2019 gegründet."          ─┐
Satz 2: "Der Hauptsitz befindet sich in München."          │ Ähnlichkeit: 0.82 → kein Split
Satz 3: "Aktuell beschäftigt die Firma 250 Mitarbeiter."  ─┘
                                                           ← Ähnlichkeit: 0.31 → SPLIT
Satz 4: "Die Gewinnmarge lag im Q3 bei 12.4%."            ─┐
Satz 5: "Im Vergleich zum Vorjahr stieg der Umsatz um 8%." │ Ähnlichkeit: 0.89 → kein Split
Satz 6: "Die EBITDA-Marge verbesserte sich leicht."       ─┘

Der Vorteil: Chunks sind semantisch kohärent. Der Nachteil: Die Chunk-Größe variiert stark, und du brauchst ein Embedding Model schon im Chunking-Schritt.

Recursive Character Splitting

Ein pragmatischer Mittelweg, der in der Praxis oft die besten Ergebnisse liefert. Der Algorithmus versucht, an natürlichen Grenzen zu splitten, und arbeitet sich dabei hierarchisch durch eine Liste von Trennzeichen:

1. Zuerst an Doppelzeilenumbrüchen (\n\n) splitten, also an Absatzgrenzen

2. Wenn Chunks zu groß sind, an einfachen Zeilenumbrüchen (\n) splitten

3. Wenn immer noch zu groß, an Satzenden (. ) splitten

4. Als Fallback an Wortgrenzen splitten

So respektierst du die natürliche Struktur des Dokuments, behältst aber die Kontrolle über die maximale Chunk-Größe.

Welche Strategie wählen?

Unsere Empfehlung für Unternehmensdaten: Recursive Character Splitting als solide Baseline, kombiniert mit Document-aware Chunking für strukturierte Formate wie Word oder HTML. Semantic Chunking ist ein Experiment wert, wenn du bereits eine funktionierende Pipeline hast und die Qualität weiter optimieren willst.

Query Flow: Vom Input zur Antwort

Die Indexing Pipeline läuft offline. Jetzt schauen wir uns an, was passiert, wenn ein Nutzer eine Frage stellt. Die Query Pipeline muss in wenigen Sekunden die relevantesten Chunks finden und eine Antwort generieren.

┌────────────┐    ┌────────────┐    ┌──────────────────┐    ┌───────────┐
│ User Query │───▶│   Query    │───▶│   Hybrid Search  │───▶│ Reranking │
│            │    │ Embedding  │    │                  │    │           │
│ "Wie hoch  │    │            │    │ ┌──────────────┐ │    │ Cross-    │
│  war der   │    │ Query ──▶  │    │ │Dense Retriev.│ │    │ Encoder   │
│  Umsatz    │    │ Vektor     │    │ │(Embedding    │ │    │ Scoring   │
│  in Q3?"   │    │ (768-dim)  │    │ │ Similarity)  │ │    │           │
│            │    │            │    │ ├──────────────┤ │    │           │
└────────────┘    └────────────┘    │ │Sparse Retriev│ │    └─────┬─────┘
                                    │ │(BM25 Keyword │ │          │
                                    │ │ Matching)    │ │          ▼
                                    │ └──────────────┘ │    ┌───────────┐
                                    └──────────────────┘    │  Top-K    │
                                                            │  Chunks   │
                                                            └─────┬─────┘
                                                                  │
                                    ┌──────────────┐              ▼
                                    │   Response   │◀───── ┌───────────┐
                                    │   + Sources  │       │   LLM     │
                                    │              │       │  Prompt   │
                                    │ "Der Umsatz  │       │ Assembly  │
                                    │  in Q3 lag   │       │           │
                                    │  bei 4.2M €" │       │ System +  │
                                    │              │       │ Context + │
                                    │ [Quelle: Q3  │       │ Query     │
                                    │  Report S.12]│       └───────────┘
                                    └──────────────┘

Step 1: Query Embedding

Die Frage des Nutzers wird mit dem gleichen Embedding Model vektorisiert, das auch für die Chunks verwendet wurde. Das ist wichtig: Query und Chunks müssen im selben Vektorraum liegen, sonst funktioniert die Ähnlichkeitssuche nicht.

Step 2: Hybrid Search

Jetzt suchen wir parallel mit zwei Methoden:

• Dense Retrieval: Cosine Similarity zwischen Query-Vektor und allen Chunk-Vektoren im Vector Store. Findet semantisch ähnliche Chunks, auch wenn die Wortwahl unterschiedlich ist.
• Sparse Retrieval (BM25): Klassisches Keyword-Matching mit TF-IDF-Gewichtung. Findet exakte Begriffe, Produktnamen, Akronyme und Fachbegriffe.

Die Ergebnisse beider Methoden werden fusioniert. Dafür gibt es verschiedene Ansätze, zum Beispiel Reciprocal Rank Fusion (RRF), bei dem die Rangposition eines Chunks in beiden Ergebnislisten kombiniert wird.

Step 3: Reranking

Die fusionierten Ergebnisse sind gut, aber nicht perfekt. Ein Cross-Encoder Reranker nimmt die Top-N Kandidaten (z.B. die besten 20-50 Chunks) und bewertet jedes Paar aus Query und Chunk noch einmal mit einem deutlich aufwändigeren Modell.

Der Unterschied: Beim Embedding werden Query und Chunk unabhängig voneinander kodiert (Bi-Encoder). Beim Reranking fließen beide gleichzeitig durch das Modell (Cross-Encoder), was eine viel feinere Relevanzbewertung erlaubt. Das ist zu teuer für den gesamten Index, aber perfekt für die Re-Evaluation einer kleinen Kandidatenmenge.

Step 4: Prompt Assembly

Die Top-K Chunks (typischerweise 3-8, je nach Chunk-Größe und Context Window) werden in den Prompt eingebaut. Ein typischer Aufbau:

System: Du bist ein Assistent, der Fragen basierend auf den bereitgestellten
        Dokumenten beantwortet. Antworte nur basierend auf den gegebenen
        Informationen. Wenn die Antwort nicht in den Dokumenten steht,
        sage das explizit.

Kontext:
[Chunk 1 - Quelle: Q3 Report 2025, Seite 12]
Der Umsatz im dritten Quartal belief sich auf 4.2 Millionen Euro...

[Chunk 2 - Quelle: Q3 Report 2025, Seite 14]
Im Vergleich zum Vorjahresquartal entspricht dies einem Wachstum von...

[Chunk 3 - Quelle: Jahresbericht 2024, Seite 8]
Die Umsatzprognose für das Geschäftsjahr...

Frage: Wie hoch war der Umsatz in Q3?

Step 5: Response mit Quellenangaben

Das LLM generiert die Antwort und referenziert die Quellen. Die Quellenangaben sind kein Bonus, sondern essenziell: Sie erlauben dem Nutzer, die Antwort zu verifizieren, und schaffen Vertrauen in das System.

Hybrid Search: Warum wir beides brauchen

Wenn du nur Dense Retrieval oder nur Sparse Retrieval nutzt, wirst du in bestimmten Szenarien scheitern. Hier ist der Grund.

Dense Retrieval (Embedding-basiert)

Dense Retrieval berechnet die semantische Ähnlichkeit zwischen Query und Chunks über deren Embedding-Vektoren. Es versteht Bedeutung, nicht Wortlaut.

Stärken:

• Findet relevante Chunks, selbst wenn kein einziges Wort der Query im Chunk vorkommt
• Versteht Synonyme, Paraphrasen und implizite Zusammenhänge
• Funktioniert sprachübergreifend (eine deutsche Frage findet einen englischen Chunk)

Schwächen:

• Versagt bei exakten Begriffen: Suche nach AZ-2024-0847 findet den Chunk nicht zuverlässig, weil Aktenzeichen keine semantische Repräsentation im Embedding-Raum haben
• Kann bei sehr kurzen, spezifischen Queries halluzinieren und irrelevante, aber semantisch vage ähnliche Chunks zurückgeben
• Eigennamen, Produktcodes und Fachkürzel werden oft schlecht embedded

Sparse Retrieval (BM25)

BM25 ist ein bewährter Algorithmus aus der Information Retrieval Forschung. Er gewichtet Wörter nach ihrer Term Frequency (wie oft kommt das Wort im Chunk vor) und Inverse Document Frequency (wie selten ist das Wort im gesamten Korpus).

Stärken:

• Exakte Matches: AZ-2024-0847 wird zuverlässig gefunden
• Eigennamen, Produktbezeichnungen und Codes funktionieren perfekt
• Schnell, gut verstanden und einfach zu debuggen
• Keine GPU nötig

Schwächen:

• Keine semantische Verständnis: „Kündigung" und „Beendigung des Arbeitsverhältnisses" haben null Überlappung
• Leidet unter Vocabulary Mismatch, wenn Nutzer andere Begriffe verwenden als die Dokumente
• Kann nicht über Sprachgrenzen hinweg suchen

Wo jede Methode allein scheitert

Fusion der Ergebnisse

In der Praxis nutzen wir Reciprocal Rank Fusion (RRF). Der Score eines Chunks berechnet sich aus seiner Position in beiden Ranglisten:

RRF_Score(chunk) =    1              +        1
                  ─────────────          ─────────────
                  k + rank_dense         k + rank_sparse

wobei k ein Konstante ist (typischerweise k = 60)

Ein Chunk, der in beiden Listen weit oben steht, bekommt einen hohen kombinierten Score. Ein Chunk, der nur in einer Liste auftaucht, wird trotzdem berücksichtigt, aber mit geringerem Gewicht.

Was bei Unternehmensdaten anders ist

Die meisten RAG-Tutorials zeigen dir, wie du eine Handvoll PDFs indexierst und Fragen dazu stellst. In der Realität bringt die Arbeit mit echten Unternehmensdaten eine Reihe zusätzlicher Herausforderungen mit sich, die in Tutorials selten behandelt werden.

Rechtemanagement und Access Control

Das ist vermutlich der am meisten unterschätzte Aspekt. In einem Unternehmen darf nicht jeder Nutzer alle Dokumente sehen. HR-Unterlagen, Vorstandsprotokolle, Gehaltsdaten oder vertrauliche Verträge haben Zugriffsrechte.

Dein RAG-System muss diese Rechte respektieren. Das bedeutet:

• Beim Indexieren werden die Zugriffsrechte als Metadaten am Chunk gespeichert
• Beim Retrieval wird ein Metadata-Filter angewendet, der nur Chunks zurückgibt, die der anfragende Nutzer sehen darf
• Die Rechte müssen live synchronisiert werden: Wenn ein Dokument in SharePoint die Freigabe verliert, darf es auch im RAG-System nicht mehr erscheinen

Wenn du das nicht korrekt implementierst, hast du ein Sicherheitsproblem. Ein Praktikant, der über den KI-Chat Zugriff auf Vorstandsprotokolle bekommt, ist ein reales Risiko.

Multi-Format Parsing

Unternehmensumgebungen sind heterogen. Du hast es nicht mit einer sauberen Markdown-Dateisammlung zu tun, sondern mit einem Mix aus:

Jedes Format braucht einen spezialisierten Parser. Ein universeller „Text-Extraktor" reicht nicht.

OCR für gescannte Dokumente

Viele Unternehmen haben Archive mit gescannten Verträgen, unterschriebenen Dokumenten oder Faxkopien. Diese PDFs enthalten keinen Text, sondern nur Bilder.

Moderne OCR-Engines liefern gute Ergebnisse, aber du musst mit Fehlern rechnen. Ein Vertrag, in dem „50.000 €" als „5O.OOO €" erkannt wird, kann zu falschen Antworten führen. Post-Processing und Validierung der OCR-Ergebnisse sind Pflicht.

Metadata Filtering

Metadaten sind der Schlüssel zur Präzision bei großen Dokumentensammlungen. Statt nur semantisch zu suchen, kannst du die Suche eingrenzen:

• Zeitraum: „Nur Dokumente aus 2025"
• Dokumenttyp: „Nur Verträge"
• Abteilung: „Nur HR-Dokumente"
• Status: „Nur freigegebene Dokumente"

Ein gut designtes Metadaten-Schema reduziert den Suchraum und verbessert die Precision massiv. Die Herausforderung liegt darin, die Metadaten automatisch und korrekt aus den Quelldokumenten zu extrahieren.

Inkrementelle Updates

Unternehmensdaten sind nicht statisch. Jeden Tag kommen neue Dokumente hinzu, bestehende werden geändert oder gelöscht. Deine Indexing Pipeline muss das effizient handhaben:

• Neue Dokumente werden indexiert, ohne den gesamten Index neu aufzubauen
• Geänderte Dokumente werden re-indexiert, und die alten Chunks werden ersetzt
• Gelöschte Dokumente werden aus dem Index entfernt
• Change Detection erkennt, ob sich ein Dokument tatsächlich inhaltlich geändert hat oder nur Metadaten aktualisiert wurden

Wenn du bei jedem neuen Dokument den gesamten Index neu aufbaust, dauert das bei zehntausenden Dokumenten Stunden statt Minuten.

Evaluation: Woher weißt du, ob dein RAG funktioniert?

Ein RAG-System ohne Evaluation ist Blindflug. Du brauchst Metriken, um zu messen, ob Änderungen an der Pipeline die Qualität verbessern oder verschlechtern.

Retrieval-Metriken

Bevor du die LLM-Antwort bewertest, musst du das Retrieval selbst evaluieren:

• Recall@K: Wie viele der relevanten Chunks sind in den Top-K Ergebnissen enthalten?
• Precision@K: Wie viele der Top-K Ergebnisse sind tatsächlich relevant?
• MRR (Mean Reciprocal Rank): An welcher Position steht der erste relevante Chunk im Durchschnitt?
• nDCG (normalized Discounted Cumulative Gain): Wie gut ist die Reihenfolge der Ergebnisse insgesamt?

End-to-End-Metriken

Für die Gesamtqualität der Antworten:

• Faithfulness: Ist die Antwort durch die bereitgestellten Chunks belegt? Oder halluziniert das LLM?
• Answer Relevance: Beantwortet die Antwort tatsächlich die gestellte Frage?
• Context Relevance: Sind die abgerufenen Chunks wirklich relevant für die Frage?

Golden Test Sets

Baue dir ein Set aus 50-100 Fragen mit erwarteten Antworten und den Dokumenten, die zur Beantwortung nötig sind. Dieses Golden Test Set ist deine Regressionssuite. Jede Änderung an der Pipeline (neues Embedding Model, andere Chunk Size, anderer Reranker) wird gegen dieses Set evaluiert.

┌──────────────────────────────────────────────────────────┐
│                    Golden Test Set                        │
├─────────────────────┬──────────────┬─────────────────────┤
│ Query               │ Expected     │ Required Source      │
│                     │ Answer       │ Chunks               │
├─────────────────────┼──────────────┼─────────────────────┤
│ Umsatz Q3 2025?     │ 4.2M €       │ Q3 Report, S.12     │
│ Kündigungsfrist      │ 3 Monate     │ Arbeitsvertrag §7   │
│ Wer ist CEO?         │ Max Müller   │ Organigramm 2025    │
└─────────────────────┴──────────────┴─────────────────────┘

Fazit

RAG ist kein einzelnes Feature, das du aktivierst. Es ist eine Pipeline, und jeder einzelne Schritt beeinflusst die Qualität der Antworten.

Das Parsing bestimmt, ob relevante Informationen überhaupt im System ankommen. Das Chunking bestimmt, in welcher Granularität Wissen abgefragt werden kann. Das Embedding bestimmt, ob semantische Suche funktioniert. Die Retrieval-Strategie bestimmt, ob die richtigen Chunks gefunden werden. Und das Prompt Assembly bestimmt, ob das LLM eine nützliche Antwort generieren kann.

Wenn die Antwort deines RAG-Systems falsch ist, liegt das Problem fast nie am LLM selbst. Es liegt an einem der vorgelagerten Schritte:

1. Das Dokument wurde nicht korrekt geparst

2. Der relevante Absatz wurde durch schlechtes Chunking zerstört

3. Die Embedding-Suche hat den richtigen Chunk nicht gefunden

4. Der Chunk wurde gefunden, aber vom Reranker zu weit nach unten sortiert

5. Zu viele irrelevante Chunks haben den Kontext verwässert

Die Kunst liegt darin, jeden Schritt einzeln zu messen und zu optimieren, anstatt die gesamte Pipeline als Black Box zu behandeln.

Wenn du ein RAG-System für dein Unternehmen aufbauen willst, fang mit den Basics an: Recursive Character Splitting, ein solides multilinguales Embedding Model, Hybrid Search mit BM25 und Dense Retrieval, und ein Cross-Encoder Reranker. Das bringt dich zu 80% der erreichbaren Qualität. Die restlichen 20% sind dann iterative Optimierung basierend auf echten Nutzerfragen und einem Golden Test Set.