RAG von Grund auf – Teil 1: RAG verstehen
Retrieval-Augmented Generation, kurz RAG, gehört inzwischen zu den zentralen Konzepten beim Einsatz von Large Language Models mit eigenem Wissen.
Die Grundidee klingt zunächst erstaunlich einfach:
Bevor ein Sprachmodell eine Frage beantwortet, werden relevante Informationen gesucht und dem Modell als Kontext mitgegeben.
Damit ist RAG im Kern bereits beschrieben.
Die eigentliche Komplexität beginnt jedoch unmittelbar danach.
Was bedeutet „relevant“? Wie findet man die richtigen Informationen? Wie werden Dokumente überhaupt durchsuchbar gemacht? Was ist ein Embedding? Warum reicht eine klassische Volltextsuche manchmal nicht aus? Was ist der Unterschied zwischen Dense und Sparse Retrieval? Warum benötigt man Reranking? Was bedeutet Grounding? Und warum kann ein RAG-System trotz korrekter Quellen noch immer eine falsche Antwort erzeugen?
Diese Artikelserie behandelt genau diese Grundlagen.
Nicht anhand eines bestimmten Frameworks und nicht anhand einer konkreten Produktarchitektur. Ziel ist ein technisches Referenzwerk über die Begriffe und Konzepte, die man kennen muss, um RAG-Systeme, Fachartikel, Papers, Dokumentationen und technische Diskussionen verstehen und einordnen zu können.
Dieser erste Teil beginnt bewusst vor Embeddings, Vektordatenbanken und Chunking.
Zuerst muss klar sein, welches Problem RAG überhaupt löst.
1. Das Ausgangsproblem: Ein LLM ist keine Wissensdatenbank
Ein Large Language Model ist zunächst ein Modell zur Verarbeitung und Erzeugung von Sprache.
Vereinfacht betrachtet erhält es eine Folge von Tokens und berechnet, welche Tokens wahrscheinlich folgen sollten.
Aus:
Die Hauptstadt der Schweiz ist ...
kann beispielsweise:
Bern
werden.
Moderne Sprachmodelle sind natürlich wesentlich komplexer als diese vereinfachte Darstellung vermuten lässt. Dennoch ist ein Punkt entscheidend:
Das Modell führt nicht bei jeder Frage automatisch eine Suche in einer Wissensdatenbank durch.
Ein erheblicher Teil dessen, was ein LLM „weiss“, stammt aus seinem Training.
Damit kommen wir zur ersten wichtigen Unterscheidung.
2. Parametrisches Wissen
Als parametrisches Wissen bezeichnet man vereinfacht Wissen, das während des Trainings in den Parametern beziehungsweise Gewichten eines Modells repräsentiert wurde.
Das Modell hat beispielsweise während des Trainings sehr viele Texte über Programmiersprachen gesehen. Dadurch kann es Fragen über C#, Java oder Python beantworten, ohne dafür bei jeder Anfrage Dokumentationen durchsuchen zu müssen.
Das ist enorm leistungsfähig.
Es besitzt aber fundamentale Grenzen.
Aktualität
Das Trainingswissen entspricht nicht zwangsläufig dem heutigen Stand.
Neue Produkte, geänderte Gesetze, aktuelle interne Dokumentationen oder Informationen, die nach dem Training entstanden sind, können fehlen.
Unternehmensinternes Wissen
Ein öffentlich trainiertes Modell kennt normalerweise nicht:
- interne Richtlinien,
- Prozessbeschreibungen,
- Projektdokumentationen,
- Verträge,
- Sitzungsprotokolle,
- interne Wikis,
- technische Betriebsdokumentationen,
- private Wissensdatenbanken.
Nachweisbarkeit
Selbst wenn das Modell eine richtige Antwort kennt, ist zunächst nicht klar, woher diese Information stammt.
Für viele professionelle Anwendungen reicht
„Das Modell weiss das.“
nicht aus.
Man benötigt eine konkrete Quelle.
Zuverlässigkeit
Sprachmodelle können plausible Aussagen erzeugen, die faktisch falsch oder nicht belegt sind.
Damit entsteht eines der bekanntesten Probleme generativer KI.
3. Halluzination
Von einer Halluzination spricht man, wenn ein Sprachmodell Inhalte erzeugt, die plausibel erscheinen, aber nicht durch die zugrunde liegenden Fakten oder den bereitgestellten Kontext gedeckt sind.
Das Gefährliche daran ist nicht zwingend, dass eine Halluzination absurd klingt.
Das Gegenteil ist häufig das Problem.
Sie kann sprachlich vollkommen überzeugend sein.
Ein Modell könnte beispielsweise eine nicht existierende Vorschrift, eine falsche Zahl oder eine erfundene Produkteigenschaft nennen und diese in einer sprachlich perfekten Antwort präsentieren.
RAG versucht unter anderem, dieses Problem zu reduzieren.
Aber eine wichtige Einschränkung gehört bereits an diese Stelle:
RAG beseitigt Halluzinationen nicht automatisch.
Ein RAG-System kann die falschen Informationen finden.
Es kann richtige Informationen falsch interpretieren.
Das Modell kann trotz korrektem Kontext zusätzliche Behauptungen erzeugen.
Oder die Antwort kann weiter gehen, als die Quellen tatsächlich erlauben.
RAG verbessert die Voraussetzungen für faktengebundene Antworten. Es garantiert sie nicht.
4. Die zweite Wissensquelle eines LLM: Kontext
Ein Sprachmodell besitzt neben seinem parametrischen Wissen noch eine zweite entscheidende Informationsquelle:
den Kontext des aktuellen Requests.
Wenn wir dem Modell schreiben:
Das Unternehmen gewährt während der Probezeit
20 Ferientage pro Jahr.
Frage:
Wie viele Ferientage gelten während der Probezeit?
muss diese Information nicht Bestandteil des Trainings gewesen sein.
Sie befindet sich direkt im aktuellen Kontext.
Das Modell kann daraus die Antwort ableiten.
Genau diese Eigenschaft bildet die Grundlage von RAG.
Anstatt zu versuchen, jedes benötigte Wissen in die Modellgewichte zu bekommen, suchen wir die relevanten Informationen vor der Antwort und geben sie dem Modell mit.
5. Das Kontextfenster
Die Menge an Informationen, die ein Modell gleichzeitig verarbeiten kann, wird durch sein Kontextfenster begrenzt.
Dieses wird üblicherweise in Tokens angegeben.
Ein Request kann beispielsweise enthalten:
Systemanweisungen
+
bisheriger Chatverlauf
+
Benutzerfrage
+
gefundene Dokumentpassagen
+
weitere Metadaten
+
erzeugte Antwort
All diese Bestandteile benötigen Kontext.
Das führt zu einer wichtigen Erkenntnis:
Man kann einem Sprachmodell normalerweise nicht einfach unbegrenzt viele Dokumente mitgeben.
Selbst wenn ein Modell ein sehr grosses Kontextfenster unterstützt, wäre es häufig ineffizient, bei jeder Frage das gesamte verfügbare Wissen hineinzukopieren.
Ein Unternehmen könnte beispielsweise Millionen Seiten Dokumentation besitzen.
Eine Frage benötigt davon vielleicht drei Absätze.
Das eigentliche Problem lautet daher nicht:
Wie bekomme ich alle Dokumente in den Prompt?
Sondern:
Wie finde ich für diese konkrete Frage genau die Informationen, die das Modell benötigt?
Damit sind wir beim Retrieval.
6. Was bedeutet RAG?
RAG steht für:
Retrieval-Augmented Generation
Der Begriff beschreibt die Kombination von Informationssuche und generativer KI.
Er lässt sich in drei Bestandteile zerlegen:
Retrieval
↓
Augmentation
↓
Generation
Oder ausführlicher:
Benutzerfrage
↓
relevante Informationen suchen
↓
gefundene Informationen als Kontext bereitstellen
↓
LLM erzeugt daraus eine Antwort
Diese drei Schritte sollte man begrifflich sauber auseinanderhalten.
7. Retrieval
Retrieval bedeutet Informationsabruf.
Das System versucht, aus einem vorhandenen Wissensbestand diejenigen Informationen zu finden, die für die aktuelle Anfrage relevant sind.
Der Wissensbestand wird häufig als Korpus beziehungsweise Corpus bezeichnet.
Ein Korpus kann beispielsweise bestehen aus:
- PDF-Dokumenten,
- Word-Dateien,
- Webseiten,
- Wiki-Artikeln,
- Handbüchern,
- E-Mails,
- Tickets,
- Markdown-Dateien,
- Datenbankinhalten,
- JSON-Daten,
- technischen Dokumentationen.
Die zentrale Aufgabe des Retrievals lautet:
Welche Teile dieses Korpus sind für die Frage relevant?
Das klingt wie eine klassische Suchmaschine.
Und tatsächlich stammt ein erheblicher Teil der technischen Grundlagen von RAG nicht aus der LLM-Forschung, sondern aus einem wesentlich älteren Gebiet:
Information Retrieval.
8. Information Retrieval
Information Retrieval, kurz IR, beschäftigt sich mit dem Auffinden relevanter Informationen innerhalb grosser Informationsbestände.
Suchmaschinen sind das offensichtlichste Beispiel.
Begriffe wie
- Ranking,
- Relevanz,
- Recall,
- Precision,
- TF-IDF,
- BM25,
- Query Expansion,
- Reranking
existierten lange vor modernen Large Language Models.
RAG verbindet diese klassische Suchwelt mit generativer KI.
Das ist eine wichtige Perspektive, weil RAG häufig fälschlicherweise hauptsächlich als LLM- oder Prompting-Problem betrachtet wird.
In Wirklichkeit lautet eine der wichtigsten Regeln:
Eine Generation kann nur so gut auf den Quellen basieren, wie das Retrieval die richtigen Quellen findet.
Wenn der richtige Absatz nie gefunden wird, kann das Antwortmodell ihn auch nicht verwenden.
Deshalb steckt ein grosser Teil der Qualität eines RAG-Systems im Retrieval.
9. Augmentation
Nach dem Retrieval liegen relevante Informationen vor.
Diese müssen nun dem Modell zur Verfügung gestellt werden.
Dieser Schritt ist die Augmentation.
Vereinfacht:
Frage:
Welche Kündigungsfrist gilt während der Probezeit?
Gefundener Kontext:
[Passage aus Dokument A]
[Passage aus Dokument B]
Anweisung:
Beantworte die Frage anhand des bereitgestellten Kontexts.
Der ursprüngliche Prompt wird also um extern gefundenes Wissen erweitert.
Daher der Begriff:
Retrieval-Augmented Generation
Die Generation wird durch Retrieval angereichert.
Augmentation ist allerdings mehr als simples Copy-and-Paste.
Ein reales System muss entscheiden:
- welche Treffer übernommen werden,
- in welcher Reihenfolge,
- wie viel Text übernommen wird,
- wie Quellen markiert werden,
- wie viel Platz für die Antwort reserviert bleibt,
- wie Chatverlauf und Dokumentkontext kombiniert werden,
- was bei widersprüchlichen Quellen passiert.
Diese Fragen werden später in der Serie relevant.
10. Generation
Erst jetzt kommt der Teil, den man normalerweise unmittelbar mit einem LLM verbindet:
Generation.
Das Sprachmodell erhält beispielsweise:
Systemanweisung
+
Frage
+
retrievten Kontext
und erzeugt daraus die Antwort.
Schematisch:
┌────────────────────┐
│ Wissenskorpus │
└─────────┬──────────┘
│
│ Retrieval
▼
Benutzerfrage ──→ relevante Passagen
│
│ Augmentation
▼
Prompt + Kontext
│
│ Generation
▼
LLM
│
▼
Antwort
Das ist die elementare RAG-Pipeline.
Alles, was später noch hinzukommt – Hybrid Search, Reranking, Query Rewrite, Cross-Encoder, Multi-Hop, GraphRAG oder Agentic RAG – erweitert letztlich diese Grundidee.
11. Warum nicht einfach das ganze Dokument in den Prompt?
Bei kleinen Dokumenten kann genau das funktionieren.
Man gibt das komplette Dokument zusammen mit der Frage an das Modell.
Bei grösseren Wissensbeständen entstehen jedoch Probleme.
Kontextgrösse
Tausende Dokumente passen nicht sinnvoll in einen einzelnen Request.
Kosten
Mehr Input-Tokens bedeuten mehr Rechenaufwand und bei kommerziellen APIs häufig höhere Kosten.
Latenz
Sehr grosse Prompts benötigen mehr Verarbeitung.
Relevanz
Ein Modell benötigt für eine konkrete Frage häufig nur einen kleinen Ausschnitt des gesamten Korpus.
Rauschen
Mehr Kontext bedeutet nicht automatisch bessere Antworten.
Irrelevante Informationen können die eigentliche relevante Passage überlagern.
Lost in the Middle
Bei sehr langen Kontexten können relevante Informationen je nach Modell und Promptposition unterschiedlich stark berücksichtigt werden.
RAG versucht deshalb, vor der Generation eine Auswahl zu treffen.
12. RAG ist keine Datenbank
Eine weitere wichtige Abgrenzung:
RAG selbst ist keine Datenbank.
RAG bezeichnet ein Verfahren beziehungsweise ein Muster.
Ein RAG-System kann unterschiedliche Speicher verwenden:
- klassische Suchindizes,
- Vektordatenbanken,
- relationale Datenbanken,
- Graphdatenbanken,
- Dokumentenspeicher,
- Kombinationen davon.
Auch eine Vektordatenbank ist nicht gleichbedeutend mit RAG.
Sie kann Bestandteil eines RAG-Systems sein.
RAG beschreibt jedoch die grössere Kette:
Wissen
↓
Suche
↓
Kontext
↓
Generierung
13. RAG ist nicht gleich Vektorsuche
Das ist eine der häufigsten begrifflichen Verkürzungen.
Oft wird RAG ungefähr so erklärt:
Dokumente
↓
Embeddings
↓
Vector Database
↓
LLM
Das beschreibt eine verbreitete Umsetzung, aber nicht die Definition von RAG.
Retrieval kann beispielsweise erfolgen über:
- klassische Keyword-Suche,
- BM25,
- Dense Vector Search,
- Sparse Retrieval,
- Hybrid Search,
- strukturierte Datenbankabfragen,
- Graphabfragen,
- Kombinationen mehrerer Verfahren.
Ein RAG-System benötigt also nicht definitionsgemäss eine Vektordatenbank.
Es benötigt Retrieval.
Wie dieses Retrieval realisiert wird, ist eine separate Frage.
14. Was ist ein Korpus?
Die Gesamtheit des durchsuchbaren Wissens bezeichnet man häufig als Korpus.
Beispiel:
Korpus
├── Personalreglement.pdf
├── Ferienrichtlinie.docx
├── Spesenreglement.pdf
├── IT-Handbuch.md
└── Sicherheitsrichtlinie.html
Ein Korpus kann homogen sein, muss es aber nicht.
In realen Systemen treffen häufig unterschiedliche Formate, Schreibstile, Sprachen und Qualitätsstufen aufeinander.
Das ist relevant, weil Retrieval nicht auf abstraktem „Wissen“ arbeitet.
Es arbeitet auf konkreten Daten, die zunächst verarbeitet werden müssen.
15. Vom Dokument zum durchsuchbaren Wissen
Bevor gesucht werden kann, müssen Dokumente normalerweise vorbereitet werden.
Dieser Vorgang wird häufig als Ingestion bezeichnet.
Sehr vereinfacht:
Dokumente
↓
Parsing
↓
Text
↓
Chunking
↓
indexierbare Einheiten
↓
Index
Je nach Retrieval-Verfahren können zusätzlich Embeddings oder andere Repräsentationen erzeugt werden.
Wichtig ist zunächst nur die Trennung:
Ingestion bereitet Wissen für die Suche vor.
Retrieval durchsucht dieses vorbereitete Wissen.
16. Ingestion und Query sind zwei verschiedene Vorgänge
Diese Trennung ist fundamental.
Ingestion
Die Ingestion geschieht typischerweise dann, wenn Wissen aufgenommen oder verändert wird.
PDF
↓
Text extrahieren
↓
strukturieren
↓
zerlegen
↓
repräsentieren
↓
indexieren
Query
Der Query-Pfad beginnt mit einer konkreten Benutzerfrage.
Frage
↓
Suchanfrage
↓
Retrieval
↓
relevanter Kontext
↓
LLM
↓
Antwort
Zusammen:
INGESTION
Dokumente
↓
Parsing
↓
Chunking
↓
Indexierung
↓
Wissensindex
▲
│
│ Retrieval
│
Benutzerfrage
↓
Suchanfrage
↓
relevanter Kontext
↓
LLM
↓
Antwort
QUERY
Diese Unterscheidung wird in späteren Teilen entscheidend.
Ein anderes Chunking-Verfahren betrifft beispielsweise die Ingestion.
Eine andere Retrieval-Strategie betrifft zunächst den Query-Pfad.
17. Was ist ein Chunk?
Ein Chunk ist eine kleinere Texteinheit, in die ein grösseres Dokument für Verarbeitung und Retrieval zerlegt wird.
Angenommen, ein Handbuch enthält 300 Seiten.
Für die Frage:
Wie lange dauert die Probezeit?
möchte man normalerweise nicht alle 300 Seiten an das Modell übergeben.
Stattdessen wird das Dokument in kleinere Einheiten zerlegt:
Dokument
│
├── Chunk 1
├── Chunk 2
├── Chunk 3
├── Chunk 4
├── ...
└── Chunk 217
Das Retrieval sucht anschliessend nach relevanten Chunks.
Chunking ist deshalb nicht bloss eine technische Vorverarbeitung.
Es beeinflusst direkt, welche Information überhaupt als Treffer gefunden werden kann.
Ist ein Chunk zu klein, kann notwendiger Zusammenhang verloren gehen.
Ist er zu gross, enthält er möglicherweise viel irrelevanten Text.
Chunking erhält deshalb einen eigenen Teil dieser Serie.
18. Retrieval arbeitet häufig auf Chunks, nicht auf ganzen Dokumenten
Das führt zu einer wichtigen begrifflichen Unterscheidung:
Dokument und Chunk sind nicht dasselbe.
Ein Dokument kann beispielsweise sein:
Personalreglement.pdf
Daraus entstehen vielleicht:
Chunk 1: Geltungsbereich
Chunk 2: Arbeitszeit
Chunk 3: Probezeit
Chunk 4: Ferien
Chunk 5: Kündigung
...
Die Suche kann Chunk 3 und Chunk 5 finden, obwohl beide aus demselben Dokument stammen.
Damit lässt sich wesentlich gezielter Kontext bereitstellen.
Allerdings entsteht dadurch ein neues Problem:
Ein einzelner Chunk besitzt möglicherweise nicht genug Kontext, um vollständig verstanden zu werden.
Genau daraus entstanden verschiedene fortgeschrittene Chunking- und Retrieval-Verfahren wie Parent-Child Retrieval oder Small-to-Big Retrieval.
19. Grounding
Ein zentraler Begriff bei RAG ist Grounding.
Eine Antwort ist „grounded“, wenn ihre Aussagen auf den bereitgestellten Quellen beziehungsweise dem bereitgestellten Kontext beruhen.
Vereinfacht:
Quelle:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Antwort:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Die Aussage lässt sich direkt aus der Quelle ableiten.
Problematischer wäre:
Quelle:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Antwort:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Diese Regelung gilt in allen Schweizer Unternehmen.
Der erste Satz ist durch die Quelle gedeckt.
Der zweite möglicherweise nicht.
Die Antwort enthält also gleichzeitig grounded und nicht grounded Aussagen.
Das zeigt:
Eine Antwort ist nicht automatisch grounded, nur weil irgendwo eine richtige Quelle angezeigt wird.
20. Grounding und Korrektheit sind nicht dasselbe
Diese Unterscheidung ist wichtig.
Eine Aussage kann grounded, aber falsch sein, wenn die zugrunde liegende Quelle falsch oder veraltet ist.
Eine Aussage kann korrekt, aber nicht grounded sein, wenn das Modell sie aus seinem Allgemeinwissen ergänzt, obwohl sie nicht in den bereitgestellten Quellen steht.
Beispiel:
Die Quelle enthält:
Bern ist Sitz der Bundesbehörden.
Das Modell ergänzt:
Bern hat rund 145'000 Einwohner.
Die zweite Aussage könnte faktisch korrekt sein.
Sie ist aber nicht durch die gegebene Quelle belegt.
In einem streng quellengebundenen System wäre sie deshalb unerwünscht.
21. Faithfulness
Eng mit Grounding verbunden ist Faithfulness.
Der Begriff beschreibt vereinfacht, wie treu eine generierte Antwort gegenüber dem bereitgestellten Kontext ist.
Eine Antwort mit hoher Faithfulness behauptet nichts Wesentliches, das sich nicht aus den Quellen ableiten lässt.
Das ist eine andere Dimension als die reine Antwortqualität.
Man kann beispielsweise eine sprachlich hervorragende, hilfreiche und sogar faktisch richtige Antwort erzeugen, die dennoch nicht faithful gegenüber dem bereitgestellten Kontext ist.
Für RAG-Evaluation müssen solche Dimensionen deshalb getrennt betrachtet werden.
22. Citations und Quellenangaben
Viele RAG-Systeme geben zusätzlich Citations beziehungsweise Quellenreferenzen aus.
Beispielsweise:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage. [1]
mit:
[1] Personalreglement, Abschnitt 3.2, Seite 7
Eine Quellenangabe verbessert die Nachvollziehbarkeit.
Sie löst Grounding aber nicht automatisch.
Das System muss sicherstellen, dass:
- die Quelle tatsächlich existiert,
- die zitierte Passage die Aussage tatsächlich unterstützt,
- das Modell keine Quellenreferenzen erfindet,
- die Quelle zur konkreten Aussage gehört.
Deshalb sind Citation und Grounding nicht synonym.
Eine Citation ist eine Referenz.
Grounding beschreibt die inhaltliche Bindung einer Aussage an die Quelle.
23. Answerability
Ein weiterer wichtiger Begriff ist Answerability.
Die zentrale Frage lautet:
Enthält der gefundene Kontext überhaupt genügend Informationen, um die Benutzerfrage zuverlässig zu beantworten?
Das ist eine andere Frage als:
Haben wir irgendwelche Treffer gefunden?
Ein Suchsystem kann fünf Chunks zurückgeben, obwohl keiner davon die Antwort enthält.
Beispiel:
Frage:
Wie hoch ist die Kündigungsfrist während der Probezeit?
Gefundene Chunks behandeln:
Definition der Probezeit
Ferien während der Probezeit
Lohnfortzahlung während der Probezeit
Das Retrieval hat thematisch verwandte Informationen gefunden.
Die konkrete Kündigungsfrist fehlt aber.
Ein robustes RAG-System sollte deshalb nicht aus
„Ich habe Treffer.“
ableiten:
„Also kann ich antworten.“
24. Warum „kein Treffer“ ein valides Ergebnis ist
Bei klassischen Chatbots besteht eine starke Versuchung, immer eine Antwort zu erzeugen.
Bei wissensgebundenen Systemen ist das gefährlich.
Wenn die Quellen keine Antwort hergeben, kann:
Dazu enthalten die verfügbaren Quellen keine ausreichenden Informationen.
die qualitativ bessere Antwort sein.
Das führt zu einem grundlegenden Prinzip:
Nicht zu antworten ist Bestandteil eines guten RAG-Systems.
Retrieval dient nicht nur dazu, Informationen zu finden.
Es muss auch möglich sein festzustellen, dass keine ausreichend zuverlässigen Informationen gefunden wurden.
25. RAG und Aktualität
Einer der grossen Vorteile von RAG besteht darin, dass Wissen ausserhalb des Sprachmodells gehalten werden kann.
Angenommen, eine Richtlinie ändert sich:
Version 2025:
Kündigungsfrist = 7 Tage
Version 2026:
Kündigungsfrist = 14 Tage
Bei einem RAG-System muss deshalb nicht zwingend ein neues Sprachmodell trainiert werden.
Stattdessen wird der Wissensbestand aktualisiert und neu indexiert.
Das trennt:
Sprachfähigkeit
von:
Fachwissen
Das Sprachmodell liefert Sprachverständnis und Generierung.
Der Wissensbestand liefert die aktuellen Informationen.
Diese Trennung ist einer der wesentlichen Gründe, weshalb RAG für Unternehmenswissen interessant ist.
26. RAG versus Fine-Tuning
RAG und Fine-Tuning werden häufig als konkurrierende Lösungen betrachtet.
Das ist zu einfach.
Beim Fine-Tuning werden Modellparameter durch weiteres Training verändert.
Bei RAG bleibt das Wissen ausserhalb der Modellgewichte und wird zur Laufzeit abgerufen.
Vereinfacht:
Fine-Tuning
Daten
↓
Training
↓
Modellgewichte
↓
Antwort
gegen:
RAG
Daten
↓
Index
↓
Retrieval
↓
Kontext
↓
Modell
↓
Antwort
Fine-Tuning kann sinnvoll sein für:
- bestimmtes Antwortverhalten,
- Formatierung,
- Stil,
- spezialisierte Aufgaben,
- bestimmte Muster.
RAG eignet sich besonders für Wissen, das:
- häufig aktualisiert wird,
- umfangreich ist,
- quellengebunden sein soll,
- organisationsspezifisch ist.
Fine-Tuning und RAG können zudem kombiniert werden.
Sie lösen nicht exakt dasselbe Problem.
27. RAG versus Tool Calling
Auch Tool Calling ist nicht dasselbe wie RAG.
Beim Tool Calling kann ein Modell eine Funktion oder ein externes Werkzeug aufrufen.
Beispielsweise:
get_current_weather("Olten")
oder:
calculate_mortgage(...)
Das Tool liefert ein Ergebnis zurück, das das Modell weiterverarbeitet.
RAG dagegen beschäftigt sich primär mit dem Abruf relevanter Informationen für die Generierung.
Beide Konzepte können kombiniert werden.
Ein Agent könnte beispielsweise:
- eine Wissenssuche ausführen,
- eine Datenbank abfragen,
- eine Berechnung durchführen,
- daraus eine Antwort erstellen.
Dann ist RAG ein Bestandteil eines grösseren Systems.
28. RAG versus Agent
Ein Agent bezeichnet üblicherweise ein System, bei dem ein Modell Entscheidungen über weitere Aktionen oder Werkzeuge treffen kann.
Beispielsweise:
Frage
↓
LLM entscheidet
├── Dokumente durchsuchen
├── Websuche
├── Datenbank abfragen
├── Berechnung durchführen
└── erneut suchen
Ein klassisches RAG-System kann dagegen vollständig deterministisch orchestriert sein:
Frage
↓
Retrieval
↓
Kontext
↓
Generation
RAG ist deshalb nicht automatisch agentisch.
Umgekehrt kann ein Agent RAG als Werkzeug verwenden.
29. Naive RAG
Die einfachste Form wird häufig als Naive RAG bezeichnet.
Typischer Ablauf:
Dokumente
↓
Chunking
↓
Embeddings
↓
Vector Store
Frage
↓
Query Embedding
↓
Top-k ähnliche Chunks
↓
Prompt
↓
LLM
Dieses Muster ist hervorragend, um RAG zu lernen.
Für komplexe Wissensbestände treten jedoch schnell Grenzen auf.
Beispielsweise:
- falsche Chunks werden gefunden,
- exakte Begriffe werden übersehen,
- ähnliche Dokumente werden verwechselt,
- notwendiger Kontext liegt über mehrere Chunks verteilt,
- die Frage ist ohne Chatverlauf unverständlich,
- zu viele irrelevante Treffer gelangen in den Prompt.
Daraus entstanden fortgeschrittenere RAG-Verfahren.
30. Advanced und Modular RAG
Unter Begriffen wie Advanced RAG oder Modular RAG werden Erweiterungen der einfachen Pipeline zusammengefasst.
Beispielsweise:
Frage
↓
Query Rewrite
↓
Hybrid Retrieval
↓
Reranking
↓
Context Selection
↓
Generation
↓
Grounding-Prüfung
Andere Systeme führen mehrere Suchschritte durch oder lassen ein Modell entscheiden, welche Suchstrategie benötigt wird.
Wichtig ist hier zunächst nur:
RAG ist kein einzelner Algorithmus.
Es ist ein Muster, innerhalb dessen sehr unterschiedliche Retrieval- und Generierungsverfahren kombiniert werden können.
31. Die eigentliche Schwierigkeit liegt vor der Antwort
Bei einem ersten RAG-Prototyp konzentriert man sich häufig auf das Antwortmodell.
In produktiven Szenarien verschiebt sich die Aufmerksamkeit schnell.
Die schwierigen Fragen lauten:
Wurde das Dokument korrekt verarbeitet?
Wurde die relevante Information sinnvoll gechunkt?
Kann die Suchmethode die Passage finden?
Wurde die Benutzerfrage richtig interpretiert?
Ist der richtige Treffer unter den Top-k?
Wurde der beste Treffer nach oben gerankt?
Ist genügend Kontext vorhanden?
Enthält der Kontext widersprüchliche Informationen?
Darf anhand dieses Kontexts überhaupt geantwortet werden?
Erst danach kommt:
Wie formuliert das LLM die Antwort?
Das führt zu einer der wichtigsten mentalen Verschiebungen beim Verständnis von RAG:
RAG ist mindestens ebenso sehr ein Information-Retrieval-Problem wie ein LLM-Problem.
32. Eine vollständige mentale Landkarte
Ein modernes RAG-System lässt sich zunächst auf diese Landkarte reduzieren:
WISSEN
│
▼
Dokumente
│
▼
Parsing
│
▼
Chunking
│
▼
Indexierung
│
▼
Index
▲
│
Retrieval
│
│
Benutzerfrage ────────┘
│
▼
Query Processing
│
▼
Retrieval
│
▼
Reranking
│
▼
Context Selection
│
▼
Augmentation
│
▼
LLM Generation
│
▼
Grounding / Citations
│
▼
Antwort
Nicht jedes RAG-System besitzt jeden dieser Schritte.
Die Landkarte zeigt aber, wo die späteren Begriffe einzuordnen sind.
33. Die drei Qualitätsprobleme eines RAG-Systems
Für das weitere Verständnis hilft eine grobe Dreiteilung.
Problem 1: Retrieval
Haben wir die richtige Information gefunden?
Wenn nicht, liegt das Problem beispielsweise bei:
- Parsing,
- Chunking,
- Indexierung,
- Query-Verarbeitung,
- Retrieval,
- Ranking.
Problem 2: Context
Haben wir dem Modell die richtigen Informationen sinnvoll bereitgestellt?
Probleme können entstehen durch:
- zu viele Chunks,
- zu wenig Kontext,
- falsche Reihenfolge,
- abgeschnittene Passagen,
- Tokenlimits,
- widersprüchliche Quellen.
Problem 3: Generation
Hat das Modell aus dem vorhandenen Kontext die richtige Antwort erzeugt?
Hier entstehen beispielsweise:
- Halluzinationen,
- falsche Schlussfolgerungen,
- unbelegte Ergänzungen,
- falsche Zahlen,
- fehlerhafte Quellenreferenzen.
Diese Ebenen sollte man beim Debugging niemals vermischen.
Eine falsche Antwort bedeutet nicht automatisch, dass das LLM schlecht ist.
Vielleicht hat es schlicht den falschen Kontext erhalten.
34. Die wichtigste Debugging-Frage
Wenn ein RAG-System falsch antwortet, lautet die erste Frage deshalb nicht:
Warum hat das Modell das gesagt?
Sondern:
Welchen Kontext hat das Modell tatsächlich erhalten?
Danach lässt sich der Fehler eingrenzen:
Richtige Quelle nicht gefunden
↓
Retrieval-Problem
Richtige Quelle gefunden, aber nicht ausgewählt
↓
Ranking-/Context-Problem
Richtiger Kontext im Prompt, falsche Aussage
↓
Generation-/Grounding-Problem
Diese Trennung spart enorm viel Zeit.
35. RAG als Suchsystem mit Sprachinterface
Eine nützliche mentale Vereinfachung lautet:
Ein RAG-System ist ein Suchsystem, dessen Suchergebnisse von einem Sprachmodell verarbeitet werden.
Das ist absichtlich etwas reduktionistisch.
Es verhindert aber einen häufigen Denkfehler:
Das LLM ist nicht die Quelle des externen Wissens.
Der Wissensbestand ist die Quelle.
Retrieval entscheidet, welcher Teil dieses Wissens verfügbar wird.
Das LLM interpretiert und formuliert daraus eine Antwort.
Damit ergibt sich:
Korpus
↓
Retrieval
↓
Evidenz
↓
LLM
↓
sprachliche Antwort
Der Begriff Evidenz ist hier besonders hilfreich.
Die gefundenen Passagen sind nicht einfach „mehr Prompt“.
Sie sind die Belege, auf deren Grundlage das Modell antworten soll.
36. Ein vollständiges Beispiel
Angenommen, ein Wissensbestand enthält 2’000 interne Dokumente.
Ein Benutzer fragt:
Welche Kündigungsfrist gilt während der Probezeit?
Ein RAG-System könnte konzeptionell folgende Schritte durchführen.
Schritt 1: Frage entgegennehmen
Welche Kündigungsfrist gilt während der Probezeit?
Schritt 2: Retrieval
Das System sucht relevante Passagen.
Beispielsweise:
Treffer A:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Kalendertagen gekündigt werden.
Treffer B:
Die Probezeit beträgt drei Monate.
Treffer C:
Nach Ablauf der Probezeit gelten die ordentlichen
Kündigungsfristen.
Schritt 3: Auswahl
Treffer A besitzt die höchste direkte Relevanz.
Schritt 4: Augmentation
Das Modell erhält beispielsweise:
Beantworte die Frage ausschliesslich anhand
der bereitgestellten Quellen.
Quelle 1:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Kalendertagen gekündigt werden.
Frage:
Welche Kündigungsfrist gilt während der Probezeit?
Schritt 5: Generation
Während der Probezeit beträgt die Kündigungsfrist
sieben Kalendertage. [1]
Schritt 6: Grounding
Die Aussage lässt sich direkt aus Quelle 1 ableiten.
Das ist der Idealzustand.
37. Was alles schiefgehen kann
Dasselbe Beispiel zeigt die verschiedenen Fehlerklassen.
Parsing-Fehler
Die relevante PDF-Seite wurde nicht korrekt extrahiert.
Ergebnis:
Die Information existiert für das Retrieval faktisch nicht.
Chunking-Fehler
Der Satz wurde ungünstig getrennt:
Chunk A:
Während der Probezeit kann das Arbeitsverhältnis
Chunk B:
mit einer Frist von sieben Kalendertagen gekündigt werden.
Die Bedeutung wurde auseinandergerissen.
Retrieval-Fehler
Ein semantisch ähnlicher Absatz über die Dauer der Probezeit wird gefunden, der Kündigungsabsatz aber nicht.
Ranking-Fehler
Der richtige Treffer existiert, landet aber auf Rang 17, während nur die Top 5 verwendet werden.
Context-Fehler
Zu viele irrelevante Treffer verdrängen die relevante Passage.
Generation-Fehler
Der korrekte Kontext sagt sieben Tage, das Modell antwortet dennoch mit 14 Tagen.
Grounding-Fehler
Das Modell ergänzt weitere Aussagen, die in keiner Quelle stehen.
Das Beispiel zeigt, weshalb „RAG funktioniert nicht“ als Diagnose praktisch wertlos ist.
Man muss wissen, welche Stufe nicht funktioniert.
38. Die Begriffe dieses Teils
Die wichtigsten Begriffe lassen sich jetzt sauber einordnen.
| Begriff | Bedeutung |
|---|---|
| LLM | Sprachmodell zur Verarbeitung und Generierung von Sprache |
| Parametrisches Wissen | Wissen, das im Modell beziehungsweise seinen Gewichten repräsentiert ist |
| Kontext | Informationen, die dem Modell im aktuellen Request bereitgestellt werden |
| Token | Verarbeitungseinheit eines Sprachmodells |
| Kontextfenster | Maximale Menge an Kontext, die ein Modell in einem Request verarbeiten kann |
| RAG | Kombination aus Retrieval, Augmentation und Generation |
| Retrieval | Auffinden relevanter Informationen |
| Information Retrieval | Fachgebiet hinter Suche und Ranking |
| Augmentation | Ergänzung des Modellkontexts um gefundene Informationen |
| Generation | Erzeugung der Antwort durch das Sprachmodell |
| Korpus | Gesamtheit des durchsuchbaren Wissens |
| Ingestion | Aufbereitung und Indexierung des Wissens |
| Query | Such- beziehungsweise Benutzeranfrage |
| Dokument | Grössere Wissenseinheit, etwa PDF oder Webseite |
| Chunk | Kleinere indexierbare Einheit eines Dokuments |
| Index | Struktur, die effizientes Retrieval ermöglicht |
| Halluzination | Plausible, aber unbelegte oder falsche Modellgenerierung |
| Grounding | Bindung einer Aussage an bereitgestellte Evidenz |
| Faithfulness | Treue der Antwort gegenüber dem bereitgestellten Kontext |
| Citation | Referenz auf eine Quelle |
| Answerability | Frage, ob der vorhandene Kontext eine belastbare Antwort ermöglicht |
| Naive RAG | Einfache Retrieve-and-Generate-Pipeline |
| Advanced RAG | RAG mit zusätzlichen Retrieval-, Ranking- und Prüfverfahren |
| Fine-Tuning | Anpassung der Modellgewichte durch weiteres Training |
| Tool Calling | Aufruf externer Funktionen oder Werkzeuge durch ein Modell |
| Agent | System, das Aktionen beziehungsweise Werkzeuge dynamisch auswählen kann |
39. Was man nach Teil 1 verstanden haben sollte
RAG ist kein Synonym für eine Vektordatenbank.
RAG ist kein Synonym für Embeddings.
RAG ist kein Fine-Tuning.
RAG ist nicht automatisch ein Agent.
RAG garantiert keine korrekten Antworten.
RAG ist ein Muster, bei dem externe Informationen retrieved, dem Modell als Kontext bereitgestellt und anschliessend für die Generation verwendet werden.
Die elementare Pipeline lautet:
Retrieval
↓
Augmentation
↓
Generation
Für reale Wissensbestände kommt davor:
Dokumente
↓
Ingestion
↓
Index
Damit ergibt sich das Gesamtbild:
INGESTION
Dokumente
↓
Parsing
↓
Chunking
↓
Indexierung
↓
Index
│
│
└──────────────────────┐
│
▼
QUERY
Benutzerfrage
↓
Retrieval
↓
relevante Evidenz
↓
Augmentation
↓
Generation
↓
Grounding
↓
Antwort
Wer dieses Modell verstanden hat, besitzt das Grundgerüst für praktisch alle weiteren RAG-Begriffe.
Denn die späteren Techniken beantworten im Wesentlichen immer eine dieser Fragen:
Wie bereiten wir Wissen besser auf?
Wie finden wir bessere Informationen?
Wie wählen wir aus den Treffern den richtigen Kontext?
Wie verhindern wir, dass das Modell über diesen Kontext hinausgeht?
Wie messen wir, ob das Ganze tatsächlich funktioniert?
Genau dort beginnt die technische Tiefe.
RAG von Grund auf
Teil 1 – RAG verstehen
LLM, parametrisches Wissen, Kontext, Retrieval, Augmentation, Generation, Grounding und die grundlegende RAG-Pipeline.
Teil 2 – Dokumente und Chunking
Parsing, OCR, Dokumentstrukturen, Chunks, Overlap, Chunk-Grösse und die unterschiedlichen Chunking-Strategien.
Teil 3 – Embeddings und Vektorsuche
Dense Vectors, semantische Ähnlichkeit, Cosine Similarity, ANN, HNSW und Vector Stores.
Teil 4 – Information Retrieval und Hybrid Search
TF, IDF, TF-IDF, BM25, Sparse Retrieval, Dense Retrieval, Hybrid Search und Reciprocal Rank Fusion.
Teil 5 – Reranking und Retrieval-Strategien
Top-k, Bi-Encoder, Cross-Encoder, MMR, Query Rewrite, Multi-Query, HyDE und weitere Retrieval-Verfahren.
Teil 6 – Kontext, Grounding und Antworten
Kontextfenster, Token-Budget, Lost in the Middle, Answerability, Faithfulness, Citations und Grounding.
Teil 7 – Advanced RAG
Naive RAG, Advanced und Modular RAG, Multi-Hop, Self-RAG, CRAG, RAPTOR, GraphRAG, ColBERT und Agentic RAG.
Teil 8 – Evaluation, Sicherheit und Abgrenzung
Recall, Precision, Hit@k, MRR, nDCG, RAG-Evaluation, Prompt Injection, RAG Poisoning sowie RAG im Verhältnis zu Fine-Tuning, Tool Calling und Agenten.