Lernziele
Sie können das Grundprinzip von RAG (Retrieval-Augmented Generation) erklären und von Fine-Tuning und reinem Kontextfenster-Ansatz abgrenzen.
Sie sind in der Lage, die drei Kernkomponenten von RAG (Chunking, Vektorstore/Embedding, Retrieval) zu beschreiben und ihre jeweilige Rolle im Gesamtsystem zu erklären.
Sie können einen konkreten RAG-Anwendungsfall für eine interne Wissensbasis skizzieren, inklusive Datenquellen, Aktualisierungsrhythmus und geeignetem Tool-Stack.
Sie kennen No-Code-RAG-Werkzeuge (NotebookLM, Langdock, Zive) und können diese anhand von DSGVO-Kriterien bewerten.
Sie können die häufigsten Qualitätsprobleme in RAG-Systemen benennen und Gegenmaßnahmen formulieren.
Sie verstehen, warum RAG in der Unternehmensrealität der dominierende Ansatz für interne Wissensabfragen ist.

Abbildung: RAG-Architektur — Indexierungs- und Anfrage-Pipeline.
Auf einen Blick
| Dauer | 45 Min |
| Methodik | Input + Visualisierung + Fallbeispiel |
| Vorwissen | UE 75–76 (Agenten-Paradigmen, Tool-Use) |
| AI-Act-Kompetenz | Grundverständnis / Anwendungskompetenz |
| Querverweise | UE 76 (Tool-Use als RAG-Trigger), UE 78 (Custom GPTs mit RAG-Wissensbasis), UE 82 (Monitoring der RAG-Qualität) |
Worum geht es? — Der didaktische Einstieg
Stellen Sie sich vor, Sie sind neu in einer Organisation und sollen ein Projekt vorbereiten. Sie wissen, dass ähnliche Projekte schon durchgeführt wurden — aber wo sind die Unterlagen? In SharePoint, irgendwo, über mehrere Jahre verteilt, mit unterschiedlichen Benennungskonventionen. Selbst eine erfahrene Mitarbeiterin braucht 20–30 Minuten, um die relevanten Dokumente zu finden.
Dieses Problem ist strukturell, nicht individuell. Es betrifft jede Organisation, die über Jahre Wissen in Dokumenten angesammelt hat, aber keinen systematischen Weg hat, dieses Wissen gezielt abzurufen.
RAG — Retrieval-Augmented Generation — ist die Antwort der KI-Forschung auf dieses Problem. Statt ein Modell mit internen Dokumenten zu trainieren (teuer, langsam, veraltet schnell), werden relevante Dokumente zur Laufzeit abgerufen und dem Modell als Kontext übergeben. Das Modell antwortet auf Basis seiner allgemeinen Intelligenz plus den frisch abgerufenen, relevanten Unternehmensdokumenten.
Lerntext — Theorie und Konzepte
Das Problem, das RAG löst
Ein LLM hat zwei Klassen von Wissen: das eintrainierte allgemeine Wissen (bis zum Trainingsdatum) und den aktuellen Gesprächskontext (das Kontextfenster). Unternehmensinterne Dokumente gehören zu keiner dieser Klassen.
Zwei scheinbare Lösungen und ihre Schwächen:
Fine-Tuning: Das Modell wird mit unternehmensinternen Dokumenten weiter trainiert. Sehr teuer, statisch (veraltet sofort, wenn Dokumente aktualisiert werden), erfordert ML-Expertise, und halluziniert trotzdem bei detaillierten Faktenfragen.
Alles ins Kontextfenster laden: Bei kleinen Dokumentmengen möglich, aber eine Wissensbasis mit hunderten von Dokumenten sprengt jedes Fenster. Mehr Kontext = höhere Kosten und schlechtere Fokussierung.
RAG löst beide Probleme: Nur die relevantesten Abschnitte werden abgerufen und übergeben — sparsam, aktuell und ohne Training.
Die drei Kernkomponenten
1. Chunking — Dokumente aufteilen
Dokumente werden in semantisch sinnvolle Abschnitte (Chunks) aufgeteilt. Die Qualität des Chunkings hat enormen Einfluss auf die Retrieval-Qualität.
Chunking-Strategien: - Fixed-Size-Chunking: Jeder Chunk hat N Tokens. Einfach, aber semantisch oft unsauber. - Sentence-Splitting: Chunks enden an Satzgrenzen. Besser, aber lose Einzelsätze können kontextarm sein. - Semantic-Chunking (empfohlen): Chunks folgen semantischen Einheiten (Abschnitte, Kapitel). - Overlap: Chunks überlappen sich um N Tokens, damit Kontext über Chunkgrenzen erhalten bleibt.
Merksatz
RAG-Prinzip: Dokumente zur Laufzeit abrufen statt eintrainieren. Ein RAG-System ist so gut wie seine Datenbasis — irrelevante, veraltete oder doppelte Dokumente verschlechtern die Antwortqualität. Datenpflege ist ein laufender Betriebsprozess, kein Einmalereignis.
2. Vektorstore / Embedding — Bedeutung als Zahl
Jeder Chunk wird durch ein Embedding-Modell in einen numerischen Vektor umgewandelt. Ähnliche Bedeutungen ergeben ähnliche Vektoren, die im Vektorraum nahe beieinander liegen.
Typische Embedding-Modelle: OpenAI text-embedding-3-small / large, Cohere Embed, sentence-transformers (Open Source, lokal ausführbar — DSGVO-konform).
Typische Vektorstores: Azure AI Search, Chroma, Pinecone.

Abb. 77.1 — RAG-Pipeline: Indexierungsphase (einmalig) und Anfragephase (pro Nutzeranfrage)
3. Retrieval — Relevante Chunks finden
Wenn eine Frage gestellt wird, wird die Frage ebenfalls durch das Embedding-Modell in einen Vektor umgewandelt. Das System berechnet dann die Cosine Similarity zwischen dem Fragevektor und allen Chunk-Vektoren und gibt die Top-K ähnlichsten Chunks zurück. Diese Chunks werden dem LLM als Kontext übergeben.
Erweiterte Retrieval-Strategien: - Re-Ranking: Ein zweites Modell bewertet die abgerufenen Chunks nach Relevanz. - Hybrid Search: Kombination aus semantischer Suche und Keyword-Suche. - Self-Query: Das LLM formuliert vor dem Retrieval eine präzisere Suchanfrage.
No-Code-RAG-Werkzeuge
NotebookLM (Google): Einfachste Variante. Dokumente hochladen, direkt befragen. Kostenlos, sofort einsatzbereit. Einschränkung: US-Server, nicht DSGVO-konform für sensible Unternehmensdaten.
Langdock / Zive: Europäische Unternehmensplattformen mit RAG-Funktionalität, DSGVO-konform, EU-Server, SSO-Anbindung.
Microsoft Copilot for Microsoft 365: Integriert RAG über Microsoft Graph auf alle M365-Inhalte. Für M365-Nutzer der direkteste Weg zu einer unternehmensweiten Wissensbasis.
Häufige Qualitätsprobleme und Lösungen
| Problem | Ursache | Lösung |
| Falsche Antwort trotz korrektem Dokument | Chunking zu grob | Kleinere Chunks mit Overlap |
| Richtige Information nicht gefunden | Embedding-Modell versteht Fachbegriffe nicht | Branchenspezifisches Embedding oder Synonym-Mapping |
| KI „erfindet” Antwort trotz RAG | Retrieval schlug fehl, Modell halluziniert | Fallback-Prompt: „Wenn nicht im Kontext, sage: Ich weiß es nicht” |
| Veraltete Antwort | Dokument in Vektordatenbank nicht aktualisiert | Automatische Re-Indexierung bei Dokumentenänderung |
Merksatz
RAG ist diejenige Methode, die in der Unternehmensrealität am häufigsten zum Einsatz kommt: kein Modell-Retraining erforderlich, Wissen ist aktuell und auditierbar, datenschutzkonformer Betrieb möglich, günstig und schnell aktualisierbar. Fine-Tuning ist in der Regel nicht notwendig und nicht zu empfehlen für die meisten Unternehmensprozesse.
Vertiefung — RAG in Microsoft-Umgebungen
Für Microsoft-365-Nutzer bieten sich folgende RAG-Optionen ohne zusätzliche Infrastruktur:
Microsoft Copilot für SharePoint (mit M365 Copilot-Lizenz): Vorkonfigurierte RAG-Architektur für SharePoint-Inhalte. Keine Konfiguration nötig.
Azure AI Search + Azure OpenAI Service: Die technisch sauberste, DSGVO-konformste Lösung für große Wissensbasen. Volle Kontrolle über Chunking, Vektorspeicher und Retrieval-Konfiguration.
Copilot Studio mit SharePoint als Wissensquelle: Visueller No-Code-Ansatz für Copilot-Agents mit direkter SharePoint-Anbindung.
Branchen-Anwendungen
IT-Dienstleistung & Beratung
Ein IT-Beratungsunternehmen baut eine RAG-Wissensbasis für seine Berater. Datenquellen: SharePoint (Projektabschlussberichte, Angebote, Kundendokumentationen), Wissensbasis-Tool (interne Handbücher, Prozessdokumentationen), E-Mail-Archiv (via Microsoft Graph, E-Mail-Threads zu laufenden Projekten). Chunking-Strategie: Semantic-Chunking für alle Dokumente, Overlap 15 %. Embedding: Azure OpenAI (EU-Rechenzentrum). Interface: Teams-App. Nutzen: Onboarding neuer Beratender von 3–4 Wochen Einarbeitungszeit auf unter 2 Wochen verkürzt. Angebotsvorbereitung: „Zeige mir alle Angebote für Kunden aus der Fertigungsbranche der letzten zwei Jahre” — in 30 Sekunden statt 30 Minuten.
Industrie & Fertigung
Ein Maschinenbauunternehmen implementiert eine RAG-Wissensbasis für die Instandhaltungsabteilung. Datenquellen: Wartungshandbücher (PDF), Störungsberichte der letzten 5 Jahre, Herstellerdokumentation, Ersatzteilkataloge. Chunking: Kapitelbasiert für Handbücher, satzbasiert mit Overlap für Störungsberichte. Die RAG-Abfrage ermöglicht es Technikern, bei einer unbekannten Fehlermeldung sofort die relevanten Abschnitte aller Handbücher zu finden. DSGVO: Da keine personenbezogenen Daten in der Wissensbasis enthalten sind, ist der Betrieb unproblematisch. Jährliche Zeitersparnis in der Instandhaltungsabteilung: ca. 400 Stunden.
Finanzdienstleistung & Versicherung
Eine Versicherungsgesellschaft baut eine RAG-Wissensbasis für den Kundenservice. Datenquellen: Versicherungsbedingungen (alle Produkte), Regulierungsvorschriften (BaFin, Solvency II), interne Arbeitsanweisungen, FAQ-Dokumentation. DSGVO-kritisch: Kundendaten werden nicht in die Wissensbasis aufgenommen — nur Produkt- und Regulierungsinformationen. Retrieval findet die relevanten Vertragsklauseln und erklärt sie dem Kundenberater auf Nachfrage. Die Antwortzeit auf Kundenanfragen sinkt von durchschnittlich 8 Minuten auf unter 2 Minuten. Compliance: Alle Retrieval-Anfragen werden geloggt, um bei Haftungsfragen nachweisen zu können, welche Informationen der Berater im Gespräch zur Verfügung hatte.
Öffentliche Verwaltung
Eine Bundesbehörde implementiert eine RAG-Wissensbasis für Sachbearbeiter auf Basis aller einschlägigen Rechtsvorschriften, Erlasse und Verwaltungsvorschriften. Datenquellen: Bundesgesetzblatt (systematisch), Ministerialerlass-Datenbank, Richtlinien-Archiv, Präzedenzfall-Sammlung. Herausforderung: Rechtstexte sind hochgradig spezialisiert — Standard-Embedding-Modelle haben Schwierigkeiten mit juristischer Fachsprache. Lösung: Juristisches Embedding-Modell (spezialisiert auf deutsches Recht) + Hybrid Search (semantisch + keyword). Datenschutz: Geheimnisgrade bei bestimmten Dokumenten erfordern rollenbasierte Zugriffssteuerung auf Chunk-Ebene — nur freigegebene Inhalte sind für den jeweiligen Nutzer abrufbar.
Übung 1 — RAG vs. Fine-Tuning vs. Kontextfenster abgrenzen
Aufgabe: Für fünf Szenarien entscheiden Sie, welcher Ansatz (RAG, Fine-Tuning, Kontextfenster direkt laden) am besten geeignet ist, und begründen die Wahl.
Schritt-für-Schritt: 1. Lesen Sie jedes Szenario sorgfältig. 2. Prüfen Sie: Wie groß ist die Datenmenge? Wie häufig ändert sie sich? Sind Kosten ein Faktor? 3. Wählen Sie den Ansatz und begründen Sie in 2–3 Sätzen.
Szenarien: - S1: Einmalige Analyse eines einzelnen 30-seitigen Vertrags - S2: KI-Assistent für die gesamte Projektdokumentation (500+ Dokumente, monatlich aktualisiert) - S3: Spezialisiertes Modell für sehr spezifische Unternehmenssprache und proprietäre Fachbegriffe - S4: Tägliche Zusammenfassung der neuesten 10 Support-Tickets - S5: Wissensbank für alle internen Prozesshandbücher (50 Dokumente, quartalsweise aktualisiert)
Musterlösung: - S1 → Kontextfenster: Einmalig, überschaubare Größe, sofort verfügbar - S2 → RAG: Zu groß für Kontextfenster, häufige Aktualisierungen, Kosten-effizient - S3 → Fine-Tuning: Sprachverhalten anpassen, nicht Fakten abrufen - S4 → Kontextfenster (täglich): Kleine, frische Datenmenge, täglich neu - S5 → RAG: Moderate Größe, regelmäßige Updates, durchsuchbar statt vollständig geladen
Übung 2 — RAG-Konzept für eine interne Wissensbasis entwerfen
Aufgabe: Sie entwerfen ein vollständiges RAG-Konzept für eine interne Wissensbasis. Dabei definieren Sie Datenquellen, Chunking-Strategie, Tool-Stack und Aktualisierungsrhythmus.
Schritt-für-Schritt: 1. Identifizieren Sie alle relevanten Datenquellen in Ihrer Organisation. 2. Priorisieren Sie: Welche drei Quellen hätten den größten Nutzen für Ihre Kolleginnen und Kollegen? 3. Entscheiden Sie für jede Quelle die geeignete Chunking-Strategie. 4. Wählen Sie den Tool-Stack: Embedding-Modell, Vektorstore, RAG-Interface. 5. Definieren Sie den Aktualisierungsrhythmus (täglich, wöchentlich, bei Dokumentenänderung). 6. Identifizieren Sie DSGVO-relevante Dokumente, die nicht in die Wissensbasis aufgenommen werden dürfen.
Musterlösung:
| Datenquelle | Priorität | Chunking | Aktualisierung |
| SharePoint Projektberichte | Sehr hoch | Semantic (Abschnitte) | Wöchentlich |
| SharePoint Angebote | Sehr hoch | Semantic | Täglich |
| Interne Handbücher | Hoch | Semantic | Bei Änderung |
| E-Mail-Archiv (Projektthemen) | Mittel | Sentence + Overlap | Täglich |
Tool-Stack: Azure OpenAI Embeddings (EU) + Azure AI Search + Microsoft Copilot for M365 als Interface.
DSGVO-Ausschlüsse: Personalakten, Gehaltsunterlagen, Bewerbungsunterlagen, vertrauliche Kundenkommunikation (sofern nicht anonymisiert), Gesundheitsdaten.
Promptbaustein — RAG-Wissensbasis konzipieren und Qualität testen
Rolle: Sie sind ein RAG-Systemarchitekt mit Erfahrung in der DSGVO-konformen Wissensmanagement-Implementation für mittelständische Unternehmen.
Aufgabe: Konzipieren Sie eine RAG-Wissensbasis für den folgenden Anwendungsfall: [Anwendungsfall einfügen — z. B. „internes Wissensportal für Sachbearbeiter: Fragen zu Produktkatalog, Preislisten und internen Prozessanweisungen”].
Ziel: Ein vollständiges Konzeptdokument für die Wissensbasis, das als Grundlage für die technische Umsetzung durch ein IT-Team oder einen externen Dienstleister dient.
Kontext: Die Organisation hat ca. 50 relevante Dokumente (PDFs, Word-Dokumente, SharePoint-Seiten). Es gibt keine eigene KI-Entwicklungskapazität — No-Code- oder Low-Code-Tools sind bevorzugt.
Output: 1. Dokumentenliste mit empfohlener Chunking-Strategie je Dokumenttyp (Tabelle: Dokumenttyp / Chunking-Methode / Aktualisierungsfrequenz). 2. Tool-Empfehlung (Azure AI Search vs. Langdock vs. NotebookLM) mit Begründung anhand der DSGVO-Anforderung. 3. Qualitätstest-Plan: Formulieren Sie fünf repräsentative Testfragen für diesen Anwendungsfall, mit denen die Retrieval-Qualität regelmäßig geprüft werden kann. 4. Drei DSGVO-Ausschlussregeln: Welche Dokumentkategorien müssen aus dieser Wissensbasis ausgeschlossen bleiben — und warum?
Beginn: Starten Sie mit der Dokumentenliste und leiten Sie daraus die Chunking-Empfehlung ab.
Cheatsheet — Die wichtigsten Punkte
RAG-Prinzip: Dokumente zur Laufzeit abrufen statt eintrainieren
Chunking: Zu klein = Kontextverlust; zu groß = unspezifisch; Semantic-Chunking empfohlen
Embedding: Text → Vektor (numerische Bedeutungsrepräsentation)
Cosine Similarity: Ähnliche Vektoren = ähnliche Bedeutung = relevante Chunks
NotebookLM: Schnellster Einstieg, aber US-Server — nicht für sensible Daten
Langdock / Zive: DSGVO-konforme EU-Alternativen für Unternehmen
Azure AI Search: Beste Option für M365/Azure-Infrastruktur
RAG ≠ Fine-Tuning: RAG ruft Fakten ab; Fine-Tuning verändert das Modellverhalten
Qualitätssicherung: 20 repräsentative Testfragen regelmäßig gegen die Pipeline testen
DSGVO: Personenbezogene Daten aus der Wissensbasis ausschließen oder rollenbasiert schützen
Reflexionsfragen
Welche drei Dokumente oder Dokumentenklassen aus Ihrer Organisation hätten sofort den höchsten Mehrwert als RAG-Wissensbasis — und warum?
Was sind die Risiken, wenn DSGVO-geschützte Dokumente versehentlich in die RAG-Wissensbasis aufgenommen werden?
Wie würden Sie einer nicht-technischen Kollegin RAG in drei Sätzen erklären?
Wie unterscheidet sich die Qualität von Antworten eines RAG-Systems von einem allgemeinen LLM — und wann könnte ein allgemeines LLM trotzdem die bessere Wahl sein?
Beschreiben Sie in drei Sätzen, warum ein RAG-System nicht nur eine technische, sondern auch eine datenschutzrechtliche Entscheidung ist.
Ein Kollege fragt: „Wenn RAG so gut ist, warum nutzen nicht alle Unternehmen es?” — Was sind die drei häufigsten Gründe?
Quellen & Weiterlesen
| Quelle | Typ | URL |
| Google NotebookLM – Einstieg und Verwendung | Hersteller-Dokumentation | https://notebooklm.google.com |
| Microsoft Azure AI Search – RAG-Architektur | Hersteller-Dokumentation | https://learn.microsoft.com/azure/search/retrieval-augmented-generation-overview |
| LlamaIndex – RAG-Framework Dokumentation (technisch) | Hersteller-Dokumentation | https://docs.llamaindex.ai |
| Langdock – DSGVO-konformes RAG für Unternehmen | Hersteller-Dokumentation | https://langdock.com |
| DSGVO Art. 5 – Grundsätze der Datenverarbeitung | Primärrecht | https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679 |
Hinweise für AI Champions — So vermitteln Sie das Thema — UE 77
Timing (45 Min): 5 Min Einstieg mit konkreter Sucherfahrung (Frage: „Wie lange suchen Sie wöchentlich nach internen Dokumenten?“), 15 Min Input RAG-Prinzip + Drei-Komponenten + No-Code-Tools, 10 Min Visualisierung der RAG-Pipeline (Tafel oder Folie), 12 Min Übung 1 + 2, 3 Min Reflexion + Übergang.
Methodische Empfehlung: NotebookLM live vorführen (falls keine DSGVO-Einwände bestehen): Ein nicht-sensibles internes Dokument hochladen und eine Frage stellen. Der Wow-Effekt ist zuverlässig und motiviert für die technischere Diskussion der Komponenten. Danach die Limitierungen (US-Server, kein DSGVO) klar benennen.
Häufige Stolpersteine: (a) Teilnehmende verwechseln RAG mit Fine-Tuning — Tabelle aus Übung 1 hilft zur Abgrenzung. (b) Die Chunking-Qualität wird unterschätzt — konkretes Beispiel eines schlechten Chunks zeigen. (c) DSGVO-Anforderungen werden als bürokratisch abgetan — auf konkrete Haftungsszenarien hinweisen.
Diskussionsfragen: (1) „Welches Dokument in Ihrer Organisation würde durch RAG die meiste Suchzeit einsparen?” (2) „Unter welchen Umständen würden Sie trotz RAG auf Fine-Tuning setzen?”
Tafelbild-Vorschlag: RAG-Pipeline als zweiphasiges Diagramm: Indexierungsphase (Dokument → Chunk → Embedding → Vektorstore) und Anfragephase (Frage → Embedding → Similarity Search → Chunks → LLM → Antwort).
Differenzierung Power-User ↔ Einsteiger: - Einsteiger: NotebookLM nutzen, RAG-Konzept auf die eigene Wissensbasis übertragen (Übung 2). - Power-User: Azure AI Search Setup konzeptuell planen, Chunking-Strategien vergleichen.
Tipp zur Branchenauswahl: Für Finanzgruppen ist das Compliance-Szenario (Regulierungsvorschriften als Wissensbasis) besonders relevant. Für Industrie: Wartungshandbücher-Szenario. Für Verwaltung: Rechtsvorschriften-Szenario mit besonderer Betonung der Zugriffssteuerung.
Übergang zur nächsten UE: „In UE 77 haben Sie die Wissensbasis hinter Agenten verstanden. In UE 78 bauen Sie Ihren ersten eigenen Assistenten: Custom GPTs und Copilot Studio Agents konfigurieren — mit der 9-Komponenten-Systemprompt-Architektur als Qualitätswerkzeug.”
Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.
Zurück zur Modul-Übersicht