RAG — Retrieval Augmented Generation in der Praxis

Große Sprachmodelle können Text generieren, haben aber ein fundamentales Problem — sie halluzinieren. Sie erfinden Fakten, zitieren nicht existierende Quellen und behaupten mit Überzeugung Unsinn. RAG (Retrieval Augmented Generation) löst dieses Problem elegant: Statt sich auf das Gedächtnis des Modells zu verlassen, liefern wir ihm in Echtzeit relevante Daten aus unseren eigenen Quellen. Hier sind unsere Erfahrungen aus Enterprise-Implementierungen.

Warum ein LLM allein nicht ausreicht¶

GPT-4, Claude, Gemini — all diese Modelle haben einen Knowledge Cutoff. Sie wissen nichts über Ihre internen Dokumente, aktuelle Preislisten oder Unternehmensprozesse. Fine-Tuning ist teuer, langsam und muss bei jeder Datenänderung wiederholt werden. RAG bietet eine Alternative: Das Modell bleibt universell einsetzbar, erhält aber bei jeder Anfrage Kontext aus Ihrer Knowledge Base.

In der Praxis bedeutet das, dass ein Kundenchatbot nicht antwortet „Ich denke, dass…”, sondern „laut Dokument XY vom Januar 2024 gilt Folgendes…”. Und das ist ein fundamentaler Unterschied für Enterprise-Deployments, bei denen Sie sich Halluzinationen nicht leisten können.

RAG-Pipeline-Architektur¶

Eine grundlegende RAG-Pipeline hat drei Phasen: Indexierung, Retrieval und Generierung.

Indexierung: Dokumente (PDF, Word, Confluence, Datenbanken) werden in Chunks aufgeteilt (typischerweise 500–1.000 Tokens), in Embedding-Vektoren mithilfe eines Modells umgewandelt (OpenAI ada-002, Cohere embed oder Open-Source-Alternativen wie nomic-embed) und in einer Vektordatenbank gespeichert.

Retrieval: Die Nutzeranfrage wird mit demselben Modell in ein Embedding umgewandelt. Die Vektordatenbank findet die ähnlichsten Chunks (typischerweise top-k = 5–10). Optional wird ein Re-Ranking-Modell für eine genauere Sortierung hinzugefügt.

Generierung: Die abgerufenen Chunks werden als Kontext in den Prompt eingefügt. Das LLM generiert auf Basis dieses Kontexts eine Antwort mit Verweisen auf die Quelldokumente.

Wahl der Vektordatenbank¶

Der Markt bietet 2024 eine überraschende Vielfalt an Optionen. Spezialisierte Vektor-DBs wie Pinecone (managed, einfacher Start), Weaviate (Open Source, Hybrid Search), Qdrant (Rust, Performance) oder Milvus (Enterprise Scale). Aber auch traditionelle Datenbanken fügen Vektorunterstützung hinzu — pgvector für PostgreSQL, Azure AI Search, Elasticsearch kNN.

Unsere Empfehlung: Wenn Sie bereits PostgreSQL haben, starten Sie mit pgvector. Für größere Volumina (Millionen von Dokumenten) und erweiterte Filter greifen Sie zu einer dedizierten Lösung. Managed Services (Pinecone, Azure AI Search) sind ideal, wenn Sie keine Infrastruktur verwalten möchten.

Chunking — Die Kunst, ein Dokument aufzuteilen¶

RAG-Qualität steht und fällt mit dem Chunking. Zu kleine Chunks verlieren Kontext. Zu große Chunks verwässern die relevante Information mit Rauschen. In der Praxis funktioniert eine Kombination: Semantic Chunking (Aufteilung entlang semantischer Grenzen — Überschriften, Absätze) plus Overlap (10–20 % Überlappung zwischen Chunks zur Kontexterhaltung).

Für strukturierte Dokumente (Verträge, Gesetzgebung) verwenden wir hierarchisches Chunking — Metadaten über Abschnitt, Kapitel und Dokument werden jedem Chunk hinzugefügt. Beim Retrieval können wir dann filtern: „Suche nur in Verträgen aus 2024” oder „nur im Abschnitt Preise”.

Fortgeschrittene Techniken: Beyond Naive RAG¶

Grundlegendes RAG ist ein guter Anfang, aber Enterprise-Deployments erfordern mehr:

• Hybrid Search: Kombination von Vektor- (semantischem) und Keyword- (BM25) Suche. Semantik findet Synonyme; Keywords finden exakte Begriffe.
• Query-Transformation: Nutzer fragen vage. HyDE (Hypothetical Document Embeddings) generiert zuerst eine hypothetische Antwort und nutzt diese für das Retrieval.
• Multi-Step Retrieval: Komplexe Fragen werden in Unterfragen zerlegt, jede einzeln ausgewertet, die Ergebnisse aggregiert.
• Re-Ranking: Ein Cross-Encoder-Modell (Cohere Rerank, BGE Reranker) sortiert Ergebnisse nach tatsächlicher Relevanz zur Anfrage um.
• Agentic RAG: Das LLM entscheidet, ob es überhaupt Retrieval benötigt, welche Quelle es nutzt und ob die Antwortqualität ausreichend ist.

Evaluation — Wie man Qualität misst¶

RAG ohne Evaluation ist wie Code ohne Tests — es funktioniert, bis es nicht mehr funktioniert. Wir messen drei Dimensionen: Retrieval-Qualität (haben wir die richtigen Dokumente gefunden?), Generierungsqualität (ist die Antwort korrekt und fundiert?) und End-to-End (ist der Nutzer zufrieden?).

Tools wie RAGAS, DeepEval oder eigene Eval-Sets mit Golden Questions ermöglichen automatisiertes Testen. Zentrale Metriken: Faithfulness (die Antwort stimmt mit dem Kontext überein), Answer Relevancy (die Antwort adressiert die Frage) und Context Precision (die abgerufenen Dokumente sind relevant).

Sicherheit und Governance¶

In Enterprise-Umgebungen ist es entscheidend, Zugriffsrechte zu adressieren. Wenn ein Dokument die Klassifizierung „vertraulich” hat, darf RAG seinen Inhalt nicht an einen Nutzer ohne entsprechende Autorisierung zurückgeben. Wir implementieren metadatenbasiertes Filtern auf Ebene der Vektordatenbank — jeder Chunk trägt ACL-Metadaten, und beim Retrieval wird basierend auf der Nutzeridentität gefiltert.

RAG als Fundament der Enterprise AI¶

RAG ist kein Allheilmittel, aber es ist der praktischste Weg, LLMs mit Unternehmensdaten in die Produktion zu bringen. Beginnen Sie einfach — pgvector, einfaches Chunking, eine Datenquelle. Iterieren Sie auf Basis der Evaluation. Und denken Sie daran: 80 % des RAG-Erfolgs liegen in der Datenqualität und im Chunking, nicht in der Modellauswahl.