Tag 3 - Retrieval-Augmented Generation (RAG)

Generative AI for Managers - TUHH Institute of Entrepreneurship · Teil meines Technology-Management-MBA · Lernnotizen zur Wiederholung.

An Tag 1 habe ich gelernt, was ein Large Language Model (LLM) eigentlich ist, und an Tag 2, wie man gut mit ihm spricht - durch Prompting. Doch eine Frage stand immer im Raum: Das Modell weiß nur, was es während des Trainings gesehen hat. Es hat nie das Handbuch meines Unternehmens gelesen, nie die Umsätze des letzten Quartals gesehen und keine Ahnung, was gestern in den Nachrichten passiert ist. An Tag 3 geht es genau darum, das zu beheben - dem Modell die richtigen Informationen in dem Moment zu geben, in dem ich frage, damit seine Antworten in echten Daten verankert sind statt auf Vermutungen zu beruhen. Diese Technik heißt Retrieval-Augmented Generation, kurz RAG.

1. Warum es RAG gibt - die Wissenslücke

Ein LLM wird einmalig auf einer riesigen Momentaufnahme von Text trainiert und dann eingefroren. Daraus ergeben sich drei Probleme, die kein noch so cleveres Prompting lösen kann:

Problem	Was es bedeutet	Beispielfrage, die scheitert
Trainings-Stichtag	Das Wissen des Modells endet an einem festen Datum	„Wer ist der aktuelle CEO dieses Unternehmens?” (kann sich geändert haben)
Privates Wissen	Es hat Ihre internen Daten nie gesehen	„Wie hoch waren unsere Umsätze in Q4 2025?”
Halluzination	Wenn es etwas nicht weiß, erfindet es eine selbstbewusste, falsche Antwort	„Was sagt unser Handbuch zum Thema Homeoffice?”

Das letzte Problem - Halluzination (das Modell produziert plausibel klingende, aber falsche Aussagen) - ist das gefährliche für Unternehmen. Das Modell sagt nicht „Ich weiß es nicht”; es füllt die Lücke mit etwas, das sich perfekt liest und schlicht erfunden ist.

Ein einfacher Vergleich: eine Prüfung ohne Hilfsmittel gegenüber einer Prüfung mit erlaubten Unterlagen. Ein einfaches LLM schreibt eine Prüfung ohne Hilfsmittel - es antwortet aus dem Gedächtnis, und wenn das Gedächtnis versagt, bluffed es. RAG macht daraus eine Prüfung mit Unterlagen: Bevor es antwortet, schlägt es genau die richtigen Seiten Ihres Lehrbuchs auf und liest daraus vor. Derselbe Prüfling, weit zuverlässigere Antworten.

2. Von der Stichwortsuche zur bedeutungsbasierten Suche

Die erste Aufgabe von RAG ist das Finden der richtigen Seiten. Um zu verstehen, wie das geht, hilft es, sich zunächst den alten Weg anzuschauen.

Der alte Weg: Stichwortsuche

Klassische Suche (man denke an ein herkömmliches Suchfeld oder an Algorithmen mit Namen wie TF-IDF und BM25) behandelt jedes Dokument als Bag of Words - buchstäblich eine Strichliste, welche Wörter wie oft vorkommen, ohne die Wortreihenfolge zu beachten. Häufige Wörter wie „der” zählen wenig; seltene, unterscheidende Wörter zählen viel. Um eine Anfrage zu beantworten, findet sie Dokumente, die exakt dieselben Wörter enthalten.

Die fatale Schwäche ist das Vokabular-Mismatch-Problem: Es findet nur wörtliche Übereinstimmungen. Fragen Sie nach „Homeoffice”, und es übersieht ein Dokument, das von „von zu Hause arbeiten” oder „Telearbeit” spricht, weil die Buchstaben nicht zusammenpassen - obwohl die Bedeutung identisch ist.

Der neue Weg: Semantic Search

Semantic Search (bedeutungsbasierte Suche) findet Treffer über die Bedeutung statt über die Schreibweise. So sieht der Unterschied in der Praxis aus:

Ich suche nach…	Stichwortsuche findet	Semantic Search findet zusätzlich
„Produktivität im Homeoffice”	nur Seiten mit genau diesen Wörtern	Seiten über Telearbeit, mobiles Arbeiten, verteilte Teams
„wie man Kosten senkt”	nur „Kosten senken” wortwörtlich	Effizienz, Budgetoptimierung, schlanke Abläufe
„Kundenbeschwerden”	nur „Kundenbeschwerden”	negative Bewertungen, Support-Tickets, verärgertes Feedback

3. Embeddings - Bedeutung in Zahlen verwandeln

Wie kann Software überhaupt Bedeutung vergleichen? Durch Embeddings - die Idee, die uns schon an Tag 1 begegnet ist.

Ein Embedding ist eine Liste von Zahlen (ein Vektor), die ein Stück Text als Punkt in einem riesigen, mehrdimensionalen Raum darstellt. Der Trick, der das nützlich macht: Texte mit ähnlicher Bedeutung landen in diesem Raum nahe beieinander, unverwandte Texte landen weit auseinander. „Auto” und „Kraftfahrzeug” werden zu Nachbarn; „Auto” und „Banane” liegen weit auseinander. Diese Anordnung hat das Modell durch das Lesen enormer Textmengen gelernt.

An Tag 1 sahen wir das für einzelne Wörter. Für RAG brauchen wir es für ganze Passagen - Sätze, Absätze, Chunks - jeweils zu einem Vektor verdichtet:

Ebene	Was es erfasst	Typische Nutzung
Wort-Embedding	ein einzelnes Wort	Analogien, Wortähnlichkeit
Satz-Embedding	ein Satz	Semantic Search, Clustering
Passage-Embedding	ein Absatz / Chunk	RAG-Retrieval
Dokument-Embedding	ein ganzes Dokument	Dokumentklassifikation

Ein modernes Embedding-Modell (der Kurs verwendet Googles gemini-embedding-001) liest eine Passage und gibt einen einzigen langen Vektor zurück - in diesem Fall 3.072 Zahlen -, der für die Bedeutung dieser gesamten Passage steht.

„Nähe” messen: Cosine Similarity

Sobald zwei Texte Vektoren sind, brauchen wir eine einzige Zahl dafür, wie ähnlich sie sind. Das Standardmaß ist die Cosine Similarity (Kosinus-Ähnlichkeit) - sie betrachtet den Winkel zwischen zwei Vektoren statt ihre Länge. Gleiche Richtung bedeutet gleiche Bedeutung.

Kosinus-Wert	Was er bedeutet
`1.0`	identische Bedeutung
`0.7` - `0.9`	sehr ähnlich
`0.3` - `0.6`	lose verwandt
unter `0.3`	unverwandt

import numpy as np

def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

sim = cosine_similarity(embedding_1, embedding_2)
print(f"Similarity: {sim:.3f}")

Embeddings mit der Gemini-API erstellen

Das aktuelle google-genai-SDK macht das zu einer Sache von wenigen Zeilen. (Fügen Sie niemals einen echten Schlüssel in den Code ein - bewahren Sie ihn in den Colab-Secrets auf, wie die Setup-Notizen zeigen.)

from google import genai
from google.genai import types

client = genai.Client()  # reads the key from the environment / Colab Secrets

response = client.models.embed_content(
    model="gemini-embedding-001",
    contents="How does remote work affect team productivity?",
)
embedding = response.embeddings[0].values
print(len(embedding))   # 3072

response = client.models.embed_content(
    model="gemini-embedding-001",
    contents=["Remote work increases flexibility but needs clear communication.",
              "Office environments foster spontaneous collaboration."],
    config=types.EmbedContentConfig(task_type="RETRIEVAL_DOCUMENT"),
)
for i, emb in enumerate(response.embeddings):
    print(f"Document {i}: {len(emb.values)} dimensions")

4. Chunking - Dokumente in mundgerechte Stücke schneiden

Echte Dokumente sind lang - ein 100-seitiges Handbuch, ein Finanzbericht, ein Produkthandbuch. Wir können nicht einfach das Ganze als einen Vektor embedden, und zwar aus vier Gründen:

Problem	Warum es weh tut
Eingabegrenzen	Embedding-Modelle nehmen nur ~8.000 Token auf einmal an
Verwässerte Bedeutung	ein Vektor für 100 Seiten erfasst nichts scharf
Begrenzter Kontext	wir bekommen später nur begrenzt viel Text in den Prompt des LLM
Präzision	wir wollen den einen Absatz, der die Frage beantwortet, nicht das ganze Buch

Also chunken wir: Wir teilen jedes Dokument in kleinere Stücke, embedden jedes Stück einzeln und rufen später nur die wenigen Chunks ab, auf die es ankommt. (Ein Token ist grob ein Wortfragment; ~750 Wörter ≈ 1.000 Token.)

Chunking-Strategien

Strategie	Wie sie teilt	Kompromiss
Feste Größe	alle N Zeichen/Token	einfach, kann aber mitten im Satz schneiden
Satzbasiert	an Satzgrenzen	erhält die Bedeutung; Sätze sind unterschiedlich lang
Absatzbasiert	an Absatzumbrüchen	natürliche Einheiten; manche Absätze sind riesig
Rekursiv	erst große Chunks, kleiner teilen falls zu lang	gut ausgewogen; etwas komplexer
Semantisch	überall dort, wo das Thema wechselt	beste Relevanz; teuerste Berechnung

Größe und Überlappung

Die Chunk-Größe ist eine der folgenreichsten Design-Entscheidungen in einem RAG-System. Kleine Chunks (~100 Token) sind messerscharf präzise, können aber umgebenden Kontext verpassen; große Chunks (~500 Token) tragen mehr Kontext, verwässern aber die Bedeutung und sind teurer zu durchsuchen.

Warum Überlappung? Ohne sie wird ein Fakt, der auf einer Chunk-Grenze sitzt, in zwei Hälften geschnitten und möglicherweise nie abgerufen. Stellen Sie sich einen Satz vor - „Der Umsatz in Q3 wuchs um 12 %, getrieben von der neuen Produktlinie, die im Juli gestartet wurde” -, der so geschnitten wird, dass „die neue Produktlinie” in Chunk 1 und „die im Juli gestartet wurde” in Chunk 2 landet. Keiner der beiden Chunks enthält nun den ganzen Fakt. Lässt man die Chunks sich um ein paar Sätze überlappen, trägt jeder den vollständigen Gedanken über die Nahtstelle hinweg.

Metadaten - das Etikett auf jedem Chunk

Clevere Systeme heften jedem Chunk einen kleinen Datensatz an Metadaten an: aus welchem Dokument er stammt, die Seite, den Abschnitt, das Datum. Genau das ermöglicht es Ihnen später, Quellen zu zitieren, zu filtern („nur HR-Dokumente durchsuchen”) und Fehler zu suchen („welcher Chunk hat diese falsche Antwort erzeugt?“).

chunk = {
    "text": "Remote work policy allows up to 3 days per week...",
    "source": "employee_handbook_v4.pdf",
    "page": 23,
    "section": "HR Policies",
    "last_updated": "2025-09-01",
}

5. Die RAG-Pipeline von Anfang bis Ende

Jetzt fügt sich das Ganze zusammen. Ein RAG-System läuft in zwei Phasen: einer Indexing-Phase, die man einmal, offline durchführt, um das Wissen vorzubereiten, und einer Querying-Phase, die jedes Mal läuft, wenn jemand eine Frage stellt.

DokumentePDFs, Wikis, DBs

→

Chunkteilen + überlappen

→

EmbedChunk → Vektor

→

Vector StoreVektoren speichern

Phase 1 - Indexing (offline, einmalig): Verwandeln Sie Ihre Dokumente in eine durchsuchbare Bibliothek von Vektoren.

Fragevom Nutzer

→

Query embedden

→

ÄhnlichkeitssucheTop-k Chunks

→

Prompt augmentierenChunks einfügen

→

Verankerte Antwort

Phase 2 - Querying (online, pro Frage): die relevantesten Chunks finden und das LLM daraus antworten lassen.

Beide Phasen als eine Komponententabelle gelesen:

Schritt	Phase	Was passiert
1. Einlesen	Indexing	Dokumente laden (PDFs, Webseiten, Datenbanken, E-Mails)
2. Chunk	Indexing	in richtig dimensionierte Stücke mit Überlappung teilen
3. Embed	Indexing	jeden Chunk in einen Vektor umwandeln
4. Speichern	Indexing	Vektoren + Originaltext + Metadaten sichern
5. Query embedden	Querying	die Nutzerfrage in einen Vektor umwandeln
6. Retrieve	Querying	die k ähnlichsten Chunks finden
7. Augmentieren	Querying	diese Chunks als Kontext in den Prompt einfügen
8. Generieren	Querying	das LLM schreibt eine in diesem Kontext verankerte Antwort

Der Schritt, der die k nächstgelegenen Chunks abruft, heißt Nearest-Neighbour-Suche (k ist einfach „wie viele Chunks man greift” - oft 3 bis 5).

Der augmentierte Prompt - wo RAG auf Tag 2 trifft

Das Herz von RAG ist, wie die abgerufenen Chunks in den Prompt eingebaut werden. Und das ist reines Prompting aus Tag 2: die Trennung von System und User, Delimiter (Trennzeichen), um den Kontext abzugrenzen, und eine explizite Grounding-Anweisung, die dem Modell sagt, es solle nur aus dem antworten, was ihm gegeben wurde.

System: You answer questions using ONLY the provided context.
        If the answer isn't in the context, say
        "I don't have enough information to answer this."

User: Answer the question based ONLY on the context below.

      <context>
      [Retrieved chunk 1]
      [Retrieved chunk 2]
      [Retrieved chunk 3]
      </context>

      Question: What is our remote work policy?

Citations - aus einer Blackbox einen Rechercheassistenten machen

Für den Unternehmenseinsatz reicht eine korrekte Antwort nicht - Menschen müssen wissen, woher sie stammt, um sie überprüfen zu können. Sie weisen das Modell an, jede Aussage mit ihrer Quelle zu kennzeichnen:

Rules:
- Cite sources as [Source N] after each claim.
- If the answer isn't in the sources, say so.
- If sources conflict, surface the conflict and prefer the most recent/authoritative.

Das Modell antwortet dann etwa so: „Die aktuelle Regelung erlaubt bis zu 3 Tage pro Woche [Source 1], doch eine neuere Aktualisierung erhöht dies ab Q4 2025 auf 4 Tage [Source 2].” In regulierten Bereichen - Recht, Gesundheitswesen, Finanzen - ist diese Nachvollziehbarkeit der Unterschied zwischen Spielzeug und Werkzeug. Wenn Dokumente sich tatsächlich widersprechen, definiert ein guter Grounding-Prompt eine Autoritätshierarchie (offizielle Richtlinie > Standardverfahren > FAQ > informelles Wiki) und bevorzugt innerhalb einer Ebene das neueste Dokument - und macht den Widerspruch immer sichtbar, statt still zu raten.

6. Ein minimales RAG-System in ~40 Zeilen

Das Lab baut ein vollständiges, funktionierendes RAG-System mit nichts weiter als Python-Listen und der Gemini-API - keine Datenbank nötig. So sieht es im Groben aus:

Dokumente vorbereiten - eine kleine „Wissensbasis” aus kurzen Textausschnitten, die für echte Unternehmensfakten stehen (Gründungsgeschichte, Homeoffice-Regelung, Q3-Umsatz, Urlaubsregelung, Produktdetails).
Alles embedden - ein gebündelter Aufruf embeddet alle Dokumente auf einmal mit task_type="RETRIEVAL_DOCUMENT", und wir behalten die Vektoren als NumPy-Arrays.
Nach Bedeutung suchen - die eingehende Frage mit RETRIEVAL_QUERY embedden, sie per Cosine Similarity mit jedem gespeicherten Vektor vergleichen und die Top-k zurückgeben.
Eine verankerte Antwort generieren - diese Top-k-Chunks in den augmentierten Prompt einfügen und das Chat-Modell aufrufen.

def ask(question, top_k=3):
    # A. retrieve the most relevant chunks
    results = search(question, top_k=top_k)
    context = "\n\n".join(documents[i] for i, _ in results)

    # B. build the augmented prompt
    prompt = f"""Answer based ONLY on the context. If it's not there,
say "I don't have enough information."

<context>
{context}
</context>

Question: {question}"""

    # C. generate
    response = client.models.generate_content(
        model="gemini-2.5-flash-lite",
        contents=prompt,
    )
    return response.text

7. Vektordatenbanken - wenn Listen nicht mehr skalieren

Der Ansatz mit Python-Listen ist ideal zum Lernen, aber er durchsucht jeden Vektor bei jeder Anfrage und vergisst beim Neustart alles. Echte Deployments nutzen eine Vektordatenbank - Speicher, der eigens für Embeddings gebaut ist.

Herausforderung	Listen im Arbeitsspeicher	Vektordatenbank
100.000+ Dokumente	langsam (prüft jedes einzelne)	schnell (indiziert)
Persistenz	beim Neustart verloren	auf Festplatte gesichert
Gleichzeitige Nutzer	nicht unterstützt	eingebaut
Metadaten-Filterung	manuell	native Abfragen
Aktualisierungen	alles neu aufbauen	einzeln hinzufügen/entfernen

Die Geschwindigkeit kommt von der indizierten Suche: Statt die Anfrage mit jedem Vektor zu vergleichen, organisieren Algorithmen (mit Namen wie HNSW oder IVF) die Vektoren vorab in Cluster oder Graphen, sodass eine Anfrage nur eine kleine, vielversprechende Teilmenge prüft. Es ist der Vektorraum-Cousin des alten Stichwort-„Inverted Index”. Beliebte Optionen reichen von ChromaDB (am einfachsten zum Einstieg) über FAISS und pgvector (Open Source, selbst gehostet) bis zu Pinecone, Weaviate und Qdrant (managed / mit vollem Funktionsumfang). Ein sinnvoller Weg: mit ChromaDB prototypen, zu einem Managed-Dienst wechseln, wenn Sie Skalierung brauchen.

8. RAG vs. Fine-tuning - warum RAG bei Unternehmens-Q&A gewinnt

Eine naheliegende Frage: Wenn das Modell meine Daten nicht kennt, warum es nicht einfach fine-tunen - es so lange auf Unternehmensdokumenten nachtrainieren, bis es sie „kennt”? Für Unternehmens-Fragen-und-Antworten gewinnt RAG fast immer. Hier der ehrliche Vergleich:

Dimension	RAG (Abruf zur Anfragezeit)	Fine-tuning (Nachtraining auf Ihren Daten)
Wissen aktualisieren	Dokument hinzufügen/ersetzen - sofort	Modell neu trainieren - langsam, teuer
Quellen-Citations	ja - verweist auf den exakten Chunk	nein - Wissen ist eingebacken, nicht nachvollziehbar
Halluzinationskontrolle	stark - Antworten sind im abgerufenen Text verankert	schwächer - generiert weiterhin aus dem Gedächtnis
Kosten & Können	gering - keine Trainings-Pipeline nötig	hoch - GPUs, ML-Expertise, Datenaufbereitung
Zugriffskontrolle	Chunks nach Nutzerrechten filtern	schwer - alle bekommen dasselbe eingebackene Modell
Am besten für	das Einspeisen von Fakten/Wissen	das Vermitteln von Stil, Format oder Ton

Die zentrale Erkenntnis: Fine-tuning ändert, wie sich das Modell verhält; RAG ändert, was das Modell gerade jetzt weiß. Unternehmens-Q&A ist ein Wissensproblem - die Fakten ändern sich wöchentlich, müssen zitierbar sein und müssen respektieren, wer was sehen darf. Das ist RAGs Heimspiel. (Die beiden sind eigentlich keine Rivalen: Fine-tunen Sie, um den Ton zu korrigieren, und nutzen Sie RAG, um Fakten zu liefern.)

9. RAG besser machen - fortgeschrittene Techniken

Einfaches RAG (embed → retrieve → generate) funktioniert beeindruckend gut. Produktionssysteme setzen dann Verfeinerungen obendrauf - es lohnt sich, sie zu kennen, auch wenn die Labs bei den Grundlagen bleiben:

Technik	Welches Problem sie löst
Reranking	schnelles Retrieval greift grob relevante Chunks; ein langsameres, schärferes Zweitmodell bewertet die Top ~20 neu und dampft sie auf die besten 3 ein
Hybrid Search	reine Semantic Search kann exakte Begriffe verpassen (ein Akronym, „ISO 27001”); kombinieren Sie sie mit Stichwort-/BM25-Suche, um beides zu erwischen
Query-Transformation	eine vage Frage vor der Suche umschreiben - Begriffe erweitern oder zuerst eine allgemeinere „Step-back”-Frage stellen
Multi-Hop-RAG	mehrere Retrievals verketten für Fragen, die sich über Dokumente erstrecken („welcher unserer Top-3-Kunden hat den längsten Vertrag?”)
Query-Routing	das LLM entscheiden lassen, welche Quelle durchsucht wird - Wissensbasis vs. CRM vs. Kalender
Agentic RAG	das LLM entscheiden lassen, ob, was, wo und wann abgerufen wird - die Tür zu Tag 4

10. Evaluation - ist mein RAG eigentlich gut?

Ein RAG-System kann an zwei verschiedenen Stellen scheitern: beim Retrieval (die falschen Chunks geholt) oder bei der Generation (die richtigen Chunks gehabt, aber schlecht geantwortet). Man muss beides messen. Der Rahmen des Kurses ist die RAG-Triade - drei sich ergänzende Bewertungen:

Context RelevanceGroundednessAnswer Relevance

Metrik	Die Frage, die sie beantwortet	Wie man prüft
Context Relevance	Haben wir die richtigen Chunks abgerufen?	jeden abgerufenen Chunk gegen die Anfrage bewerten
Groundedness	Wird die Antwort von diesen Chunks gestützt?	jede Aussage zu einem Chunk zurückverfolgen
Answer Relevance	Geht die Antwort tatsächlich auf die Frage ein?	die Antwort gegen die ursprüngliche Frage bewerten

Sie brauchen alle drei, weil jede einen anderen Fehler abfängt: Perfekte Chunks können trotzdem eine falsche Antwort erzeugen (niedrige Groundedness), und eine wunderschön geschriebene Antwort kann die Frage völlig verfehlen (niedrige Answer Relevance). Um im großen Maßstab zu bewerten, nutzen die Labs LLM-as-Judge - ein zweites LLM bewertet jede Dimension mit 1-5 und gibt JSON zurück. Speziell fürs Retrieval helfen auch klassische Metriken: Precision@k (welcher Anteil der abgerufenen Chunks relevant war) und Recall@k (welchen Anteil der relevanten Chunks wir gefunden haben) - beide brauchen einen Golden Test Set aus echten Fragen mit bekannten korrekten Antworten.

Häufige Fallstricke, auf die man achten sollte

Fallstrick	Symptom	Behebung
Chunks zu klein	abgerufenem Text fehlt Kontext	größere Chunks oder mehr Überlappung
Chunks zu groß	abgerufener Text ist mit Rauschen aufgebläht	kleinere Chunks, rekursives Teilen
Keine Grounding-Regel	Modell ignoriert Kontext, halluziniert	explizites „antworte NUR aus dem Kontext” ergänzen
Falsches k	Antwort unvollständig oder Prompt überflutet	justieren, wie viele Chunks Sie abrufen
Veraltete Daten	Wissensbasis nicht aktuell	regelmäßiges Re-Indexing einplanen
Zugriffskontroll-Leck	Nutzer sieht eingeschränkte Antworten	vor dem Retrieval nach Rechten filtern

11. Wo RAG geschäftlichen Wert schafft

RAG glänzt überall dort, wo wertvolles Wissen in schwer durchsuchbaren Dokumenten gefangen ist:

Anwendungsfall	Wissensquelle	Geschäftlicher Nutzen
Interne Wissensbasis	Wikis, Handbücher, SOPs	Antworten in Sekunden statt Stunden
Kundensupport	Produktdokumente, FAQs, Tickets	schnellere, konsistentere Antworten
Recht & Compliance	Verträge, Vorschriften	sofortiges Nachschlagen von Klauseln, weniger Risiko
Forschung & Analyse	Berichte, Papers, Marktdaten	über hunderte Dokumente hinweg synthetisieren
Sales Enablement	Fallstudien, Preise	Vertrieb findet das richtige Material sofort

Wann man zu RAG greifen sollte (und wann nicht): Nutzen Sie es, wenn sich Wissen oft ändert, sich über viele Dokumente erstreckt, unvorhersehbar abgefragt wird und Genauigkeit mit Citations verlangt. Verzichten Sie darauf, wenn die Daten winzig und statisch sind (nehmen Sie einfach das Context Window), die Anfragen hochgradig vorhersehbar sind (nutzen Sie Vorlagen) oder allgemeines Wissen bereits ausreicht.

Praxis: Labs & Aufgabe

Die Praxis von Tag 3 führt die Theorie den ganzen Weg bis zu einem dokumentierten, evaluierten RAG-System.

Eine RAG-Pipeline bauen (dozentengeführt, ~60-75 Min). Schritt für Schritt: Embeddings mit der Gemini-API erstellen, Cosine Similarity und Nearest-Neighbour-Suche implementieren, ein Dokument chunken (feste Größe vs. satzbasiert, mit Überlappung und Metadaten), die vollständige retrieve → augment → generate-Pipeline zusammensetzen und sie dann evaluieren - die RAG-Triade, LLM-as-Judge-Bewertung und Precision@k / Recall@k. Enthält die aufschlussreiche „mit vs. ohne Kontext”-Halluzinations-Demo und einen Verweigerungstest bei themenfremden Fragen.

Notebooks herunterladen (in Google Colab öffnen):

Meine eingereichte Lösung: Aufgabe 3 - mein gelöstes Notebook (.ipynb) - meine eigene Arbeit aus dem Kurs.

Wiederholungs-Zusammenfassung

Kernpunkt	Kurz gemerkt
Warum es RAG gibt	LLMs sind zum Trainingszeitpunkt eingefroren - ihnen fehlen private, aktuelle und Nischen-Fakten, und sie halluzinieren, um die Lücke zu füllen
Was RAG tut	die relevanten Chunks aus Ihren Daten abrufen und das LLM damit antworten lassen (Prüfung mit Unterlagen)
Embeddings	Text in Vektoren verwandelt, in denen ähnliche Bedeutung nah beieinander sitzt
Cosine Similarity	eine Zahl dafür, wie ähnlich zwei Vektoren sind; ~1,0 identisch, unter 0,3 unverwandt
Task Types	`RETRIEVAL_DOCUMENT` für gespeicherte Dokumente, `RETRIEVAL_QUERY` für Fragen - sie abzustimmen steigert die Genauigkeit
Chunking	lange Dokumente in 200-500-Token-Stücke mit 50-100-Token-Überlappung teilen, damit kein Fakt zerschnitten wird
Metadaten	jeden Chunk kennzeichnen (Quelle, Seite, Datum), um Citations, Filterung und Debugging zu ermöglichen
Die Pipeline	Indexing offline (chunk → embed → store) + Querying online (embed → retrieve → augment → generate)
Augmentierter Prompt	abgerufene Chunks in Delimiter einfassen und „antworte NUR aus dem Kontext” anweisen - reines Prompting aus Tag 2
Citations	das Modell `[Source N]` zitieren lassen, damit Antworten überprüfbar sind; eine Autoritätshierarchie für Widersprüche festlegen
Vektordatenbank	im großen Maßstab nötig für Geschwindigkeit, Persistenz, Filterung und einfache Aktualisierungen (ChromaDB → Pinecone)
RAG vs. Fine-tuning	RAG speist Fakten ein (günstig, sofort, zitierbar, rechtebewusst); Fine-tuning vermittelt Stil
RAG-Triade	Context Relevance + Groundedness + Answer Relevance - alle drei messen, um jeden Fehler zu erwischen
Größter Fehler	nicht mit echten, chaotischen, themenfremden Nutzerfragen zu testen