TECHNOLOGIE

RAG

Retrieval-Augmented Generation

Injiziert zur Laufzeit relevanten Kontext aus deinen eigenen Daten in den LLM-Prompt, damit das Modell aus deinem Wissen antwortet, nicht aus seinen Trainingsdaten.

Zuletzt geprüft: vonKevin Riedl wiki ↗

RAG ist die Architektur, die einem LLM erlaubt, Fragen zu Daten zu beantworten, auf denen es nie trainiert wurde. Die Mechanik ist geradlinig: Frage des Nutzers nehmen, die relevantesten Chunks aus deinem Korpus per Vector-Search, Keyword-Search oder Hybrid abrufen, in den Prompt packen, das Modell antworten lassen. Es ist die Erdungsschicht unter den meisten nützlichen AI Agents.

Der Grund, warum RAG existiert: Ein Modell auf privaten Daten zu trainieren ist teuer, langsam und veraltet, sobald die Daten sich ändern. RAG umgeht das, indem es die Daten als Laufzeit-Kontext behandelt. Der Trade-off: Retrieval-Qualität wird der Engpass. Ein Modell mit schlechtem Kontext produziert selbstbewusst falsche Antworten.

Beispiel für das klassische Versagen: Eine Firma baut einen Support-Bot über ihre Hilfe-Docs, die Demo ist beeindruckend, und dann zitiert er in Produktion selbstbewusst die falsche Rückerstattungsrichtlinie. Der Instinkt ist, das Modell zu beschuldigen und ein größeres zu versuchen. Die Antworten bleiben falsch, weil das Problem upstream liegt: Die Docs wurden mitten im Satz gechunkt, die Embeddings können „Rückerstattung" nicht von „Rückgabe" unterscheiden, und es gibt keinen Reranker, der die richtige Passage nach oben schiebt. Tausch besseres Chunking, Hybrid Search und einen Reranker ein, und dasselbe Modell wirkt plötzlich klug. Die Lehre verallgemeinert: Wenn RAG falsch liegt, verdächtige fast immer das Retrieval vor der Generierung.

Der ehrliche Trade-off und wo RAG zusammenbricht: Es glänzt bei lookup-förmigen Fragen, die aus wenigen Passagen beantwortbar sind, und verschlechtert sich, wenn die Antwort eine Synthese über viele Dokumente verlangt oder Widersprüche im Korpus auflösen muss. An diesem Punkt willst du einen kleineren kuratierten Korpus, eine agentische Pipeline, die in Schritten denkt, oder Fine-Tuning, keinen größeren Retriever. Die unsexy Wahrheit ist, dass 80 % der Arbeit gutes Retrieval ist (Chunking, Embeddings, Reranking, Hybrid Search) und 20 % das Modell. Deine Datenquellen als MCP-Server zu verpacken, macht die Retrieval-Schicht portabel, aber nicht gut. Anbieter, die RAG als Ein-Klick-Feature pitchen, pitchen den einfachen Teil.

// FAQ

Häufige Fragen

RAG, wenn die Daten sich ändern und Quellen-Nachvollziehbarkeit zählt. Fine-Tuning, wenn Du Stil oder Format prägen willst, nicht Fakten. Beides zu mischen ist sinnvoll, aber nicht als erster Schritt; meist reicht gutes RAG.
Weil das Modell nicht das Problem ist. Schlechte Chunks, fehlendes Reranking, naive Embeddings und keine Hybrid-Search liefern dem besten Modell Müll. 80 Prozent der RAG-Qualität liegen vor dem Modell-Call.
Für unter 10 Millionen Vektoren reicht pgvector, weil Postgres Du sowieso hast. Über 10 Millionen oder mit hybriden Filtern: Qdrant oder Weaviate. Pinecone für reines Managed ohne Self-Hosting-Wunsch. Wähle nach Operational-Fit, nicht nach Benchmark.