RAG ist seit 2023 das dominante Pattern wenn du LLMs mit eigenen Daten arbeiten lassen willst, ohne fine-tuning. Trotz neuer Long-Context-Modelle bleibt es 2026 das verbreitetste Architecture-Pattern in Produktion. Hier knapp erklärt was es ist, wie es funktioniert, und wo die ehrlichen Grenzen liegen.
In einem Satz
RAG ist ein Pattern bei dem ein LLM vor der Antwort relevante Dokumente aus einer eigenen Wissensbasis sucht (typisch via Vector-Search), diese in den Context lädt und dann antwortet.
In drei Absätzen
Konzeptionell ist RAG eine Antwort auf zwei Limits klassischer LLMs: das Modell weiss nichts über deine spezifischen Dokumente (Vertraege, Produktdoku, interne Wikis), und sein Wissen ist auf den Training-Cutoff begrenzt. RAG umgeht beide Limits, indem es zur Laufzeit relevante Dokumente sucht und dem Modell als Context-Material gibt. Du fragst “Was sind unsere Garantiezeiten für Produkt X”, das System sucht in deiner Doku, lädt die drei relevanten Absätze in den Prompt, und das Modell antwortet basierend darauf.
Mechanisch hat RAG drei Komponenten. Ingestion zerlegt deine Quell-Dokumente in Chunks (typisch 300-800 Tokens), berechnet pro Chunk ein Embedding-Vektor mit einem Embedding-Modell (OpenAI Ada, Cohere, Voyage, oder lokale Modelle wie bge-m3), und speichert das in einer Vector-DB (Qdrant, Weaviate, Chroma, pgvector, etc.). Retrieval nimmt die User-Frage, berechnet ihr Embedding, sucht die K nächsten Nachbarn in der Vector-DB (typisch 5-20 Chunks). Generation baut einen Prompt zusammen aus User-Frage plus gefundenen Chunks und lässt das LLM antworten.
Relevant wird RAG wenn deine Datenmenge gross ist (>100k Tokens, also nicht in einen einzelnen Context-Window passt), wenn Daten sich häufig ändern (Vertraege, Preise, News), und wenn du Audit-Trail brauchst (welcher Chunk hat zur Antwort beigetragen). Die Trade-offs: Retrieval-Quality ist limitiert durch Embedding-Quality (semantisches Matching ist nicht perfekt), Chunking-Strategy ist tricky (zu klein = verlorener Kontext, zu gross = verwässerte Embeddings), und Latency steigt um 50-200ms pro Anfrage.
Tief, wenn du willst
Chunking-Pattern in der Praxis: das einfachste ist Fixed-Size-Chunking (z.B. 500 Tokens pro Chunk mit 50 Tokens Overlap). Funktioniert oft erstaunlich gut, ist aber blind für Dokument-Struktur. Besser ist Semantic-Chunking, das Section-Grenzen respektiert (H2-H3 in Markdown, Pagination in PDFs), und für strukturierte Daten Document-spezifisches Chunking (pro Vertrags-Klausel, pro JIRA-Ticket, pro Code-Funktion). Anthropic hat 2025 “Contextual Retrieval” released, das pro Chunk eine LLM-generierte Beschreibung dazupackt was den Recall um 30-50% verbessert.
Embedding-Wahl: Trade-off zwischen Quality, Dimensionalität, Cost und Self-Hosting-Möglichkeit. OpenAI text-embedding-3-large ist der Default für viele, aber HuggingFace MTEB Leaderboard zeigt dass Voyage und Cohere oft besser sind, und für deutsche Texte sind bge-m3 oder e5-multilingual-large kompetitiv und lokal hostbar. Wichtiger Hinweis: wenn du Embeddings persistierst, ist Modell-Wechsel teuer (kompletter Re-Embedding-Lauf), also vor Production-Start einmal sorgfältig wählen.
Re-Ranking: rohe Vector-Search liefert oft Top-20 die qualitativ unterschiedlich relevant sind. Re-Ranker-Modelle (Cohere Rerank, bge-reranker-large, Voyage Rerank) nehmen Top-20 und sortieren neu, was den nutzbaren Recall fast verdoppelt bei minimalem Aufwand. Faustregel: für jeden RAG in Produktion, baue Re-Ranking ein bevor du andere Optimierungen versuchst.
RAG vs Long-Context ist die Debatte 2025-2026. Long-Context-Modelle (Claude mit 200k-1M Tokens, Gemini mit 2M+) machen es möglich gesamte Korpora direkt in den Prompt zu packen. Das funktioniert für mittelgrosse Datenmengen erstaunlich gut, ist aber teuer pro Anfrage und hat nicht den Audit-Vorteil von RAG. Simon Willison hat das nüchtern eingeordnet: für unter 50k Tokens lohnt sich Long-Context oft, ab 200k Tokens wird RAG wieder ökonomisch, und Hybrid-Pattern (RAG-Pre-Filtering plus Long-Context-Final-Answer) sind im Trend.
Evaluation ist der unterschätzte Teil. Ein RAG-System fühlt sich oft besser an als es ist. Hamel Husain hat sehr klar gemacht: ohne harten Eval-Setup (Retrieval-Recall@K, Answer-Quality-Rubric, Hallucination-Rate) optimierst du im Blindflug. Minimum-Setup: 50 manuell kuratierte Question-Answer-Pairs als Holdout, automatisierter Test der Retrieval-Recall sichtbar macht, plus LLM-as-Judge für Answer-Quality.
Common Failure-Modes: zu lange Chunks (Embedding-Verwässerung), zu kurze Chunks (verlorener Kontext), schlechte Chunk-Boundaries (mitten in einem Satz), Vector-DB-Index-Drift wenn neue Dokumente kommen, Mix verschiedener Embedding-Modelle in derselben DB (passiert leichter als man denkt), und das absolute Lieblings-Problem: die User-Frage matcht semantisch nicht mit der Antwort sondern mit der Frage in der Dokumentation. Letzteres adressierst du mit Question-Generation während Ingestion (für jeden Chunk LLM-generierte Frage-Varianten generieren und mit-embedden).
Wo dir das diese Woche begegnet ist
In der Aggregation tauchten mehrere RAG-Themen auf: Arxiv-Papers zu Hybrid-Search (BM25 + Vector), eine Reddit-Diskussion auf r/LocalLLaMA zu lokalen Embedding-Modellen für deutsche Texte, Latent Space hat einen Pod zu Late-Interaction-Retrieval released, und ein Hacker-News-Thread debattierte ob RAG mit Long-Context-Modellen obsolet wird. Konsens ist klar: RAG bleibt für grosse Korpora und Audit-Pflicht, Long-Context wird zusätzliche Option für mittlere Pools.
Wenn du selber einen RAG baust und es nicht performt: erst Re-Ranking dazu, dann Chunking überdenken, dann erst Embeddings tauschen.
Erklärt 2026-05-28 durch kaschnai-Konzept-Pipeline. Quality-Gates: 3-Tier-Klarheit (Gate 12), Source-Diversity (6 Quellen). Nächste Frische-Prüfung: 2027-05-28.