Was ist RAG in einem Satz?

RAG (Retrieval-Augmented Generation) ist ein Muster, bei dem ein LLM vor der Antwort die relevanten Stellen aus deiner Wissens-DB abruft, diese in den Prompt einbettet und damit antwortet - mit Quellen-Belegen.

Wann ist RAG besser als Fine-Tuning?

Wenn dein Wissen sich häufig ändert (Doku, FAQ, Preise) oder du Quellen-Belege brauchst. Fine-Tuning passt eher zum Stil-Lernen oder zum Trainieren spezialisierter Klassifikation, nicht zur Wissens-Vermittlung.

Welche Technologie steckt hinter RAG?

Embeddings (Vektor-Darstellungen von Text), Vektor-Datenbank (z.B. pgvector in Postgres), Suchstrategie (vector + BM25 hybrid), Reranker, und ein LLM für die finale Antwortgenerierung.

Wissen

RAG - Retrieval-Augmented Generation

RAG ist ein Muster, bei dem ein LLM vor der Antwort die relevanten Stellen aus deiner eigenen Wissensquelle abruft, sie in den Prompt einbettet, und dann mit Bezug auf diese Stellen antwortet. Das spart teures Fine-Tuning, hält das Wissen aktuell, und liefert Quellen-Belege statt Halluzinationen.

Wie RAG technisch abläuft

Indexierung: dein Wissen (PDFs, FAQ, Doku, Tickets) wird in Chunks zerlegt und als Embeddings in einer Vektor-DB gespeichert.
Retrieval: User stellt Frage, Frage wird embeddet, ähnlichste Chunks aus der DB gezogen.
Reranking: oft holen wir 20-50 Chunks raus und reranken sie mit einem zweiten Modell auf 3-5 wirklich relevante.
Generation: das LLM bekommt Frage + Top-Chunks im Prompt und antwortet mit Quellen-Belegen.

Wann RAG das richtige Werkzeug ist

Wissensbasis ändert sich häufig (Preise, Produkte, FAQ)
Quellen-Belege sind Pflicht (Compliance, Vertrauen)
Wissensmenge zu groß, um im Prompt zu landen
Multi-Tenant: jeder Kunde hat eigenes Wissen

Wann RAG das falsche Werkzeug ist

Wissensmenge ist klein und stabil - dann gehört es einfach in den System-Prompt
Es geht nicht um Wissen, sondern um Stil oder Klassifikation - dann ist Few-Shot oder Fine-Tuning passender
Du brauchst exakte Lookup-Antworten (Bestellnummer → Lieferdatum) - dann ist eine SQL-Query schneller, billiger, korrekter

Unser Stack für RAG

Postgres mit pgvector als Vektor-DB - kein extra Service nötig, transaktional, und kombinierbar mit klassischer SQL-Suche für Hybrid-Retrieval.

Hybrid-Search: Vector- Similarity + BM25 (klassische Volltext-Suche) parallel, danach Reranking. Schlägt reine Vector-Search in den meisten Use-Cases.

Embeddings wahlweise von OpenAI, Voyage, Cohere oder lokal (BGE, E5). Auswahl hängt von Sprache, Domäne, Datenschutz-Anforderung ab.

Wo RAG-Setups häufig scheitern

Schlechtes Chunking (zu groß, zu klein, falsche Grenzen)
Kein Reranking, nur naive Vector-Search
Kein Evaluation-Setup, niemand weiß wie gut die Antworten sind
Kein Mechanismus für "weiß ich nicht" - das Modell antwortet sicher trotz fehlendem Kontext
Wissensbasis veraltet, niemand re-indexiert

Genau diese Stellen härten wir, wenn wir RAG bauen oder ein bestehendes Setup übernehmen.

RAG-Setups bauen wir als Teil von KI-Integrationen:Zur Leistung →

Hast du Wissen, das ein LLM nutzen sollte?

Erstgespräch klärt: Reicht ein Workflow, oder lohnt sich RAG?

Erstgespräch buchen Zum Glossar