RAG-System selbst bauen: Tutorial fuer Retrieval-Augmented Generation

ChatGPT halluziniert, erfindet Fakten und kennt Ihre internen Dokumente nicht. Die Loesung: Retrieval-Augmented Generation (RAG). Statt blind auf das Wissen des Modells zu vertrauen, fuettern Sie ihm relevante Dokumente als Kontext. Das Ergebnis: praezise Antworten basierend auf Ihren echten Daten. In unserer KI-Beratung ist RAG die am haeufigsten nachgefragte Technologie – und das aus gutem Grund.

Das Prinzip ist bestechend einfach: Anstatt ein Sprachmodell mit allen Unternehmensinformationen zu trainieren (was teuer, aufwendig und schnell veraltet waere), durchsuchen Sie bei jeder Anfrage Ihre Dokumentenbasis und geben nur die relevanten Passagen als Kontext mit. So bleibt das System immer aktuell, ohne Nachtraining.

Was ist RAG und warum brauchen Sie es?

Large Language Models haben ein fundamentales Problem: Ihr Wissen ist eingefroren auf den Zeitpunkt des Trainings. Fragen Sie GPT-4 nach Ereignissen von letzter Woche, kennt es die Antwort nicht. Fragen Sie nach Ihren internen Richtlinien, kann es nur raten.

RAG loest dieses Problem elegant: Bei jeder Anfrage durchsucht das System Ihre Dokumentenbasis, findet relevante Passagen und gibt diese als Kontext an das LLM weiter. Das Modell antwortet nun auf Basis echter, aktueller Informationen.

Typische Anwendungsfaelle

• Unternehmens-Chatbot - Mitarbeiter koennen interne Dokumente befragen
• Kundenservice - Bot antwortet basierend auf FAQs und Dokumentation
• Rechtsabteilung - Vertragsanalyse und Recherche in Rechtsdokumenten
• Technische Dokumentation - Entwickler finden Antworten in der Codebasis

Die RAG-Architektur verstehen

Ein RAG-System besteht aus mehreren Komponenten, die zusammenspielen muessen.

1. Document Loader

Ihre Dokumente muessen eingelesen werden: PDFs, Word-Dateien, Web-Seiten, Datenbanken. Jedes Format braucht einen eigenen Loader. LangChain bietet ueber 100 verschiedene Document Loader.

2. Text Splitter

Grosse Dokumente muessen in kleinere Chunks aufgeteilt werden. Warum? Weil LLMs begrenzte Kontextfenster haben und weil kleinere Chunks praezisere Suchtreffer liefern.

Die Kunst liegt in der richtigen Chunk-Groesse: Zu klein, und der Kontext geht verloren. Zu gross, und irrelevante Informationen verwaeessern die Antwort. 500-1000 Tokens mit 100-200 Tokens Ueberlappung ist ein guter Startpunkt.

3. Embedding Model

Jeder Text-Chunk wird in einen numerischen Vektor umgewandelt. Diese Embeddings erfassen die semantische Bedeutung des Textes. Aehnliche Texte haben aehnliche Vektoren - das ermoeglicht die spaetere Suche.

4. Vector Store

Die Embeddings werden in einer spezialisierten Vektordatenbank gespeichert. Diese ermoeglicht schnelle Similarity-Suche: "Finde die 5 Chunks, deren Embeddings am aehnlichsten zur Anfrage sind."

5. LLM

Das eigentliche Sprachmodell, das die finale Antwort generiert. Es erhaelt die Nutzeranfrage plus die gefundenen relevanten Chunks als Kontext.

Schritt-fuer-Schritt-Implementation

Wir bauen ein RAG-System mit Python, LangChain und Chroma als Vektordatenbank. Alle Komponenten laufen lokal - ideal fuer sensitive Daten.

Voraussetzungen

pip install langchain langchain-community chromadb
pip install sentence-transformers  # fuer lokale Embeddings
pip install ollama  # fuer lokales LLM

Schritt 1: Dokumente laden

from langchain_community.document_loaders import DirectoryLoader
from langchain_community.document_loaders import PyPDFLoader

# Alle PDFs aus einem Verzeichnis laden
loader = DirectoryLoader(
    "./dokumente/",
    glob="**/*.pdf",
    loader_cls=PyPDFLoader
)
documents = loader.load()
print(f"{len(documents)} Seiten geladen")

Schritt 2: Dokumente aufteilen

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,      # Zeichen pro Chunk
    chunk_overlap=200,    # Ueberlappung zwischen Chunks
    separators=["\n\n", "\n", ".", " "]
)

chunks = splitter.split_documents(documents)
print(f"{len(chunks)} Chunks erstellt")

Schritt 3: Embeddings erstellen und speichern

from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma

# Lokales Embedding-Modell
embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-m3"
)

# Vektordatenbank erstellen
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

Schritt 4: Retriever konfigurieren

# Retriever mit den Top 5 relevantesten Chunks
retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 5}
)

Schritt 5: LLM und Chain zusammenbauen

from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA

# Lokales LLM via Ollama
llm = Ollama(model="llama3")

# RAG Chain
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # alle Chunks in einen Prompt
    retriever=retriever,
    return_source_documents=True
)

# Anfrage stellen
result = qa_chain.invoke("Was sind die wichtigsten Richtlinien?")
print(result["result"])

RAG-System optimieren

Ein einfaches RAG-System ist schnell gebaut. Die Kunst liegt in der Optimierung fuer Qualitaet und Performance.

Chunk-Strategie verfeinern

Nicht alle Dokumente sollten gleich behandelt werden. Code-Dateien brauchen andere Splitter als Fliesstext. Tabellarische Daten erfordern spezielle Aufbereitung.

• Semantic Chunking - Chunks basierend auf Bedeutungseinheiten, nicht Zeichenzahl
• Parent Document Retriever - Kleine Chunks fuer Suche, grosse fuer Kontext
• Metadata Filtering - Chunks nach Dokumenttyp, Datum oder Abteilung filtern

Retrieval verbessern

Manchmal findet die Vektorsuche nicht die besten Ergebnisse. Hybride Ansaetze kombinieren verschiedene Suchmethoden.

# Hybrid Search: Vektor + Keyword
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever

# BM25 fuer Keyword-Suche
bm25_retriever = BM25Retriever.from_documents(chunks)

# Kombination aus beiden
ensemble_retriever = EnsembleRetriever(
    retrievers=[retriever, bm25_retriever],
    weights=[0.6, 0.4]  # 60% Vektor, 40% Keyword
)

Re-Ranking

Nach dem initialen Retrieval koennen die Ergebnisse mit einem Cross-Encoder neu sortiert werden. Das verbessert die Qualitaet signifikant, kostet aber Performance.

RAG in Produktion

Ein Prototyp ist schnell gebaut. Fuer den Produktionseinsatz muessen weitere Aspekte beruecksichtigt werden.

Vektordatenbank-Auswahl

Chroma eignet sich fuer Prototypen. Fuer Produktion gibt es spezialisierte Loesungen:

• Qdrant - Open Source, hohe Performance, gute Filterung
• Weaviate - Hybrid Search out-of-the-box, GraphQL-API
• Pinecone - Managed Service, einfaches Scaling (aber Cloud)
• Milvus - Enterprise-ready, hohe Skalierbarkeit

Monitoring und Evaluation

Wie gut sind Ihre RAG-Antworten wirklich? Ohne Messung keine Verbesserung. Relevante Metriken:

• Retrieval Precision - Wie viele gefundene Chunks sind relevant?
• Retrieval Recall - Wie viele relevante Chunks wurden gefunden?
• Answer Faithfulness - Basiert die Antwort auf den Quellen?
• Answer Relevance - Beantwortet die Antwort die Frage?

Dokumenten-Pipeline

Dokumente aendern sich. Sie brauchen einen Prozess, um neue Dokumente automatisch zu indexieren und veraltete zu entfernen. Webhooks, Cronjobs oder Event-basierte Architekturen sind gaengige Ansaetze.

Kosten und Ressourcenplanung

Eine haeufige Frage in unserer KI-Beratung: Was kostet ein RAG-System? Die Antwort haengt vom Ansatz ab.

Cloud-basierter Ansatz

• OpenAI Embeddings - Ca. 0,10 USD pro 1 Million Token (guenstig fuer Prototypen)
• Managed Vector DB - Pinecone ab ca. 70 USD/Monat fuer Produktion
• LLM-API-Kosten - Variabel, typisch 10-100 USD/Monat je nach Nutzung
• Nachteil: Unternehmensdaten verlassen Ihre Infrastruktur

On-Premise-Ansatz

• Hardware - GPU-Server ab ca. 5.000 EUR (gebraucht) oder ueber unsere KI-Server-Loesungen
• Software - Komplett Open Source moeglich (Kosten: 0 EUR)
• Betrieb - Strom und Wartung, aber keine laufenden API-Kosten
• Vorteil: Volle Datenkontrolle, DSGVO-konform, keine Abhaengigkeit

Fuer die meisten mittelstaendischen Unternehmen amortisiert sich ein On-Premise-RAG-System innerhalb von 6-12 Monaten gegenueber Cloud-Kosten – besonders bei hohem Anfragevolumen.

Typischer Zeitaufwand

Ein funktionierender RAG-Prototyp ist in 1-2 Tagen gebaut. Die Optimierung fuer Produktionsqualitaet dauert typischerweise 2-4 Wochen, einschliesslich Chunk-Strategie-Optimierung, Evaluation und UI-Entwicklung. Die Integration in bestehende Systeme (Intranet, Ticketsystem, ERP) erfordert weitere 2-4 Wochen je nach Komplexitaet.

Sicherheit und Datenschutz

Bei einem RAG-System mit Unternehmensdaten ist Sicherheit kein optionales Feature, sondern Grundvoraussetzung.

• Zugriffssteuerung - Nicht jeder Mitarbeiter sollte alle Dokumente durchsuchen koennen. Implementieren Sie rollenbasierte Zugriffsrechte, die sich an bestehenden Berechtigungsstrukturen orientieren.
• Audit-Logging - Protokollieren Sie, wer welche Anfragen stellt und welche Dokumente als Quellen verwendet werden. Das ist nicht nur fuer Compliance wichtig, sondern auch fuer die Qualitaetssicherung.
• Prompt Injection - Schuetzen Sie Ihr System gegen Manipulation. Nutzer koennten versuchen, ueber geschickt formulierte Fragen an Informationen zu gelangen, fuer die sie keine Berechtigung haben.
• Datenklassifizierung - Nicht alle Dokumente sollten im RAG-System landen. Definieren Sie klare Kriterien, welche Daten indexiert werden duerfen und welche nicht.

Haeufig gestellte Fragen

Was ist ein RAG-System und warum brauche ich es?

RAG steht fuer Retrieval-Augmented Generation. Es kombiniert ein Sprachmodell mit einer externen Wissensdatenbank. Bei jeder Anfrage werden relevante Dokumente gesucht und als Kontext an das LLM uebergeben. Dadurch basieren die Antworten auf aktuellen, verifizierten Daten statt auf veraltetem Trainingswissen. RAG reduziert Halluzinationen erheblich.

Welche Vektordatenbank eignet sich am besten fuer RAG?

Fuer Prototypen eignet sich Chroma (einfache Einrichtung, lokal). Fuer Produktion empfehlen sich Qdrant (hohe Performance, Open Source), Weaviate (Hybrid Search) oder Milvus (Enterprise-Skalierbarkeit). Die Wahl haengt von Datenvolumen, Performance-Anforderungen und Datenschutz ab.

Wie gross sollten die Text-Chunks fuer RAG sein?

Ein guter Startpunkt sind 500-1000 Zeichen pro Chunk mit 100-200 Zeichen Ueberlappung. Zu kleine Chunks verlieren den Kontext, zu grosse verwaessern die Relevanz. Semantic Chunking, das nach Bedeutungseinheiten statt Zeichenzahl aufteilt, liefert oft bessere Ergebnisse.

Kann ich ein RAG-System komplett lokal betreiben?

Ja, vollstaendig lokale RAG-Systeme sind moeglich und empfehlenswert fuer sensible Daten. Sie benoetigen ein lokales Embedding-Modell (z.B. BGE-M3), eine lokale Vektordatenbank und ein lokales LLM via Ollama. Alle Daten bleiben auf Ihrem Server. Unsere On-Premise KI-Loesungen bieten dafuer die optimale Infrastruktur.