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: 2026-05-24 vonKevin Riedl wiki ↗

RAG ist die Architektur, die einem LLM erlaubt, Fragen zu Daten zu beantworten, auf denen es nie trainiert wurde. Mechanik: Frage des Nutzers nehmen, die relevantesten Chunks aus deinem Korpus per Vector-Search, Keyword-Search oder Hybrid abrufen, in den Prompt packen, Modell antworten lassen.

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.

Unsexy Wahrheit zu RAG: 80 % der Arbeit ist gutes Retrieval (Chunking, Embeddings, Reranking, Hybrid Search), 20 % das Modell selbst. Anbieter, die RAG als Ein-Klick-Feature pitchen, pitchen den einfachen Teil."

// FAQ

Häufige Fragen

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.