RAG (Retrieval Augmented Generation)

Einfach erklärt

RAG (Retrieval-Augmented Generation) ist das wichtigste Architekturmuster für KI-Anwendungen, die auf aktuellem oder domänenspezifischem Wissen basieren sollen. LLMs haben ein fundamentales Problem: Ihr Wissen ist auf den Trainingszeitpunkt eingefroren. RAG löst das, indem relevante Informationen zur Laufzeit aus einer Wissensdatenbank abgerufen und dem Modell als Kontext übergeben werden. Das Modell generiert dann eine Antwort basierend auf diesen abgerufenen Informationen – nicht nur aus dem Trainings-Gedächtnis.

RAG (Retrieval Augmented Generation) ist eine Methode, die das Problem löst, dass Large Language Models nur auf Wissen zugreifen können, mit dem sie trainiert wurden. Statt ein LLM komplett neu zu trainieren, verbindet RAG das Modell mit einer Wissensdatenbank.

So funktioniert es in der Praxis:

1. Deine Frage wird gestellt: “Was sind die neuesten Features in unserem Produkt?”
2. Relevante Dokumente werden aus einer Datenbank abgerufen (z.B. aktuelle Release Notes)
3. Das LLM erhält sowohl deine Frage als auch die gefundenen Dokumente als Kontext
4. Die Antwort basiert nun auf aktuellen, verifizierbaren Informationen

Der große Vorteil: Das System kann auf aktuelle Informationen zugreifen, die nach dem Training des LLMs entstanden sind, ohne das Modell neu trainieren zu müssen.

Technischer Deep Dive

RAG kombiniert zwei Komponenten: einen Retriever (Abrufsystem) und einen Generator (LLM). Der Prozess läuft in mehreren Schritten ab:

Abgrenzung zu anderen Ansätzen:

Ansatz	Kontext	Skalierung	Aktualität
Prompt Engineering	Statisch, manuell eingefügt	Begrenzt durch Kontextfenster	Manuelles Update nötig
RAG	Dynamisch, semantisch abgerufen	Skaliert auf Millionen Dokumente	Automatisch aktuell
Fine-Tuning	Im Modell gespeichert	Teuer bei großen Datenmengen	Erfordert Retraining

RAG ist besonders wertvoll, wenn du:

• Eine große, sich ändernde Wissensbasis hast
• Nicht im Voraus weißt, welche Informationen relevant sind
• Quellenangaben für Antworten brauchst

1. Indexierung (Vorbereitung)

• Dokumente werden in kleinere Chunks aufgeteilt (z.B. 500 Tokens)
• Jeder Chunk wird mit einem Embedding-Modell in einen hochdimensionalen Vektor umgewandelt
• Diese Vektoren werden in einer Vektordatenbank gespeichert

2. Retrieval (Abruf)

• Die Nutzeranfrage wird ebenfalls in einen Embedding-Vektor umgewandelt
• Über Similarity Search (meist Cosine Similarity oder Dot Product) werden die k-nächsten Nachbarn gefunden
• Die relevantesten Dokument-Chunks werden zurückgegeben

3. Augmentation (Anreicherung)

• Die gefundenen Chunks werden mit der ursprünglichen Anfrage kombiniert
• Ein strukturierter Prompt wird erstellt: “Kontext: [Dokumente] \n\n Frage: [User Query]“

4. Generation (Antwort)

• Das LLM erhält den angereicherten Prompt
• Die Antwort basiert auf dem bereitgestellten Kontext
• Optional: Quellenangaben werden zurückgegeben

Wichtige Optimierungen:

• Chunk-Größe: Balance zwischen Kontext und Präzision (typisch 200-1000 Tokens)
• Overlap: Chunks überlappen sich um 10-20% für besseren Kontext
• Reranking: Ein zweites Modell bewertet die Relevanz der abgerufenen Chunks neu
• Hybrid Search: Kombination aus semantischer Suche (Embeddings) und Keyword-Suche (BM25)

Herausforderungen:

• Kontext-Fenster: Begrenzte Anzahl an Chunks, die ins LLM passen
• Retrieval-Qualität: Schlechte Suche führt zu irrelevanten Antworten
• Latenz: Zusätzliche Datenbankabfragen erhöhen die Antwortzeit
• Kosten: Jede Anfrage benötigt Embedding-Generierung und LLM-Call

Production Considerations

Für produktive RAG-Systeme sind zusätzliche Aspekte entscheidend:

Caching-Strategien:

• Embedding-Cache: Häufige Queries werden vorberechnet und gecacht
• Result-Cache: Identische Anfragen liefern gecachte Antworten
• Chunk-Cache: Oft abgerufene Dokumente werden im Memory gehalten
• Typische Cache-Hit-Rate: 30-60% je nach Use Case

Monitoring & Evaluation:

• Recall@k: Wie viele relevante Dokumente sind in den Top-k Ergebnissen?
• MRR (Mean Reciprocal Rank): Durchschnittliche Position des ersten relevanten Dokuments
• Latency-Tracking: P50, P95, P99 für Retrieval und Generation getrennt
• Relevance Scoring: Nutzer-Feedback zur Antwortqualität

Evaluationsmetriken:

Recall@5 = Relevante Docs in Top-5 / Alle relevanten Docs
MRR = 1/N * Σ(1/rank_i)
Latency = t_embedding + t_retrieval + t_generation

Security & Guardrails:

• Prompt Injection Prevention: Sanitierung von User-Input vor Embedding
• Content Filtering: Blacklists für sensible Dokumente
• Access Control: User-spezifische Dokumenten-Berechtigungen
• Output Validation: Prüfung auf Halluzinationen durch Fact-Checking
• Rate Limiting: Schutz vor Missbrauch und Kostenkontrolle

Best Practices:

• A/B-Testing verschiedener Chunk-Größen und Retrieval-Strategien
• Logging aller Queries für kontinuierliche Verbesserung
• Fallback auf größere Kontexte bei schlechter Retrieval-Qualität
• Regelmäßige Re-Indexierung bei sich ändernden Daten