Open Source AI · Retrieval Augmented Generation
RAG: KI mit eigenen
Dokumenten verbinden.
Dein Modell kennt deine internen Dokumente nicht — und antwortet trotzdem veraltet. RAG löst das ohne Neu-Training: Das Modell bekommt die richtigen Dokumente zur Laufzeit als Kontext.
Was ist Retrieval Augmented Generation?
RAG steht für Retrieval Augmented Generation. Das Prinzip ist einfach: Anstatt ein Modell mit deinen Daten neu zu trainieren, gibst du ihm die relevanten Dokumente bei jeder Anfrage direkt mit — als Teil des Prompts.
Der entscheidende Unterschied zu Fine-Tuning: RAG ändert das Modell nicht. Es ergänzt den Kontext zur Laufzeit. Das Modell “lernt” nichts dauerhaft — aber es antwortet auf Basis deiner aktuellen Dokumente.
Das bedeutet auch: Wenn sich deine Dokumente ändern, ist RAG sofort aktuell. Kein Neu-Training, kein Deployment-Prozess. Du aktualisierst die Wissensbasis, fertig.
Wie RAG funktioniert — Schritt für Schritt
Dokumente indexieren
Deine Dokumente (PDFs, Word-Dateien, Wiki-Seiten) werden in Textabschnitte (Chunks) aufgeteilt und in numerische Vektoren umgewandelt — sogenannte Embeddings. Diese landen in einer Vektor-Datenbank.
# Beispiel: Dokument chunken und in Chroma indexieren
from langchain.vectorstores import Chroma
from langchain.embeddings import OllamaEmbeddings
embeddings = OllamaEmbeddings(model="nomic-embed-text")
vectorstore = Chroma.from_documents(docs, embeddings)Relevante Chunks abrufen
Wenn eine Frage gestellt wird, wird sie ebenfalls in einen Vektor umgewandelt. Die Vektor-DB sucht die ähnlichsten Dokument-Abschnitte — das ist das "Retrieval" in RAG.
# Ähnlichkeitssuche: Top-3 relevante Chunks finden
retriever = vectorstore.as_retriever(
search_kwargs={"k": 3}
)
docs = retriever.get_relevant_documents(query)Modell mit Kontext antworten lassen
Die gefundenen Dokument-Abschnitte werden zusammen mit der Frage als Kontext an das Modell übergeben. Das Modell antwortet auf Basis dieser Dokumente — nicht aus seinem allgemeinen Training.
# Prompt mit Kontext zusammenbauen
prompt = f"""Beantworte die Frage nur auf Basis
der folgenden Dokumente:
{context}
Frage: {question}"""Wichtig für die Qualität: Die Chunking-Strategie entscheidet über alles. Zu große Chunks verwässern den Kontext, zu kleine Chunks verlieren den Zusammenhang. Eine gute Faustregel: 300–500 Token pro Chunk mit 50 Token Überlappung.
Tools für den Einstieg
Von All-in-One bis zur eigenen Integration — drei Ansätze für unterschiedliche Reifegrade.
Desktop-App mit integrierter Vektor-DB, Ollama-Anbindung und Chat-Interface. Du lädst Dokumente hoch, verbindest ein lokales Modell — fertig. Ideal für den ersten RAG-Prototyp ohne Programmierung.
Wählen wenn: Einstieg, Proof of Concept, nicht-technische Teams
Das meistgenutzte Framework für RAG-Pipelines. Abstraktion über Retrieval, Embeddings, Vektor-DBs und Modelle. Flexibel, aber auch komplex. Gut wenn du eigene Pipelines bauen willst.
Wählen wenn: Eigene Integration, individuelle Anforderungen, Entwickler-Team vorhanden
Stärker auf Daten-Ingestion und Indexierung fokussiert als LangChain. Besonders gut für strukturierte Dokumente (PDFs, Tabellen, Datenbanken). OpenAI-kompatibel, funktioniert mit Ollama.
Wählen wenn: Viele verschiedene Dokumenttypen, komplexe Indexierungsanforderungen
Die Vektor-DB speichert die Embeddings deiner Dokumente. Chroma ist einfacher zu starten (embedded, kein separater Server). Qdrant ist production-ready, unterstützt Millionen von Vektoren.
Wählen wenn: Chroma: Prototypen und kleine Datenmengen. Qdrant: Production-Betrieb.
Wofür Unternehmen RAG einsetzen
- Interne Wissensdatenbank: Mitarbeitende stellen Fragen — das Modell antwortet auf Basis von Handbüchern, Prozessdokumenten, Richtlinien. Kein endloses Suchen mehr.
- HR-FAQs: Urlaubsregelungen, Onboarding-Prozesse, Benefit-Fragen — automatisch beantwortet, immer aktuell, DSGVO-konform wenn lokal betrieben.
- Rechtsdokumente: Verträge, Compliance-Richtlinien, Datenschutzhinweise durchsuchen und zusammenfassen — mit Quellenangabe welches Dokument die Grundlage ist.
- Technische Dokumentation: Support-Teams fragen, Entwickler fragen — das Modell findet die relevanten Stellen in der technischen Doku und fasst sie zusammen.
- Angebots- und Produktwissen: Vertrieb fragt nach Produktspezifikationen, Preislisten, Case Studies — RAG liefert die passenden Inhalte aus dem internen Katalog.
DSGVO-Hinweis
RAG mit lokalem Betrieb (Ollama + lokale Vektor-DB) ist vollständig DSGVO-konform: Dokumente und Anfragen verlassen nie den eigenen Server. Kein Cloud-Transfer, kein Drittland-Problem. Das gilt auch für Modelle aus dem Ausland — der Verarbeitungsort entscheidet, nicht die Herkunft des Modells.
“RAG ist kein KI-Produkt das man kauft. Es ist eine Architekturentscheidung: Wo liegen die Daten, wer greift zu, und was soll das Modell damit machen?”
— Ralf Kruse
RAG oder Fine-Tuning — wann was?
Die Frage kommt in jedem Projekt: Sollen wir RAG machen oder Fine-Tuning? Die Antwort hängt davon ab was du eigentlich willst.
RAG — wählen wenn
- Deine Dokumente sich regelmäßig ändern
- Du aktuelle, abrufbare Fakten brauchst
- Quellenangaben wichtig sind (“steht in Dokument X”)
- Schnell starten ohne Trainingsdaten
- DSGVO-Konformität kritisch ist (lokal betreibbar)
Fine-Tuning — wählen wenn
- Das Modell einen spezifischen Stil/Ton braucht
- Domänen-Terminologie konsistent sein muss
- Das Verhalten tief verändert werden soll
- Du 500+ qualitativ hochwertige Beispiele hast
- RAG-Latenz ein Problem ist (Fine-Tuning ist schneller)
In der Praxis: Die meisten Organisationen starten mit RAG. Es ist günstiger, schneller und sofort aktuell. Fine-Tuning kommt später — wenn RAG nicht mehr ausreicht und du genug Qualitätsdaten hast.
Stand: 2026-05
Wie RAG die Arbeit verändert — was sich durchsetzt
Nicht Technik-Evolution, sondern Adoption-Muster: was funktioniert, was scheitert, was bleibt.
RAG hat den Proof-of-Concept-Status hinter sich gelassen: Unternehmen betreiben es produktiv als Knowledge-Base-Infrastruktur — die Herausforderung ist nicht mehr ob es funktioniert, sondern wie es zuverlässig bleibt.
Use Cases die sich in der Praxis bewähren
- Query enhancement is necessary because real users write ambiguous, incomplete queries that match poorly against well-structured knowledge base documents
- Interne Wissensdatenbanken: Mitarbeitende fragen Prozesse, Richtlinien und Handbücher — das System antwortet mit Quellenangabe auf Basis aktueller Dokumente
- HR- und Compliance-FAQs: Urlaubsregelungen, Betriebsvereinbarungen, DSGVO-Richtlinien — automatisch beantwortet, lokal betrieben, audit-fähig
- Technischer Support: Entwickler- und Support-Teams fragen gegen API-Dokumentationen, Release-Notes und interne Wikis — Ticket-Aufwand sinkt messbar
Organisationen starten fast immer mit einem einzelnen, klar abgegrenzten Dokumentenpool (z.B. HR-Dokumente oder eine Produktdokumentation), messen die Qualität händisch an 50–100 echten Fragen, und weiten dann schrittweise aus. Der Sprung in die Breite scheitert häufig an Dokumentenqualität — nicht an der Technologie.
Wie sich die Arbeit konkret verändert
- Wissensträger werden entlastet: Fragen die bislang per E-Mail oder Slack beantwortet wurden, landen zuerst beim RAG-System — erst bei Unsicherheit oder Kritikalität beim Menschen
- Dokumentenpflege wird strategisch: Schlecht strukturierte oder veraltete Dokumente führen direkt zu schlechten Antworten — das erzeugt einen neuen Anreiz für Dokumentenqualität
- Antworten werden referenzierbar: Mit Quellenangaben ("steht in Dokument X, Stand März 2026") können Entscheidungen nachvollzogen werden — das verändert wie intern kommuniziert wird
- Onboarding verkürzt sich spürbar: Neue Mitarbeitende bekommen kontextspezifische Antworten aus dem gesamten Unternehmenswissen statt auf Suche durch Laufwerke angewiesen zu sein
Wo RAG scheitert — die häufigen Fallen
- Chunking strategy, metadata enrichment, and context prepending drive larger gains than DB selection
- Schlechte Dokumentenqualität: Wenn Quelldokumente veraltet, widersprüchlich oder schlecht strukturiert sind, antwortet das System auf Basis falscher Prämissen — Garbage in, garbage out gilt hier absolut
- Falsche Chunking-Strategie: Zu große Textabschnitte verwässern den Kontext, zu kleine verlieren den Zusammenhang — Organisationen unterschätzen wie viel Engineering-Zeit in die Vorverarbeitung gehört (nicht in die Vektordatenbank-Wahl)
Was stabil bleibt
- BM25 is a hard-to-beat baseline that most RAG implementations never benchmark against
- Chunking strategy, metadata enrichment, and context prepending drive larger gains than DB selection
Was jetzt konkret ansteht
- Human evaluation remains essential; AI-as-judge metrics can drift when underlying models update
- Operational monitoring catches infrastructure failure; functional monitoring catches model quality failure
- Functional monitoring tracks data quality (input), model behaviour (feature attribution), and prediction quality (output)
Datenstand: 2026-05-11 · Dieses Feld wird monatlich aktualisiert — nicht für Technik-Updates, sondern für Adoption-Muster: was funktioniert in der Praxis, was scheitert, was bleibt stabil
Weiter im Cluster
Lokal betreiben
Modelle mit Ollama lokal laufen lassen — die Grundlage für jede RAG-Lösung.
Ollama erklärt →Fine-Tuning
Wenn RAG nicht reicht: Modelle auf eigene Daten anpassen — Stil, Terminologie, Domänenwissen.
Fine-Tuning verstehen →DSGVO & KI
Welche Betriebsmodelle sind rechtlich sicher? Drei Szenarien für Datenschutz-konforme KI.
DSGVO-Optionen →Open Source AI
RAG konkret umsetzen — begleitet
Du willst RAG in eurer Organisation einführen und weißt nicht wo starten? Ich helfe euch bei Architekturentscheidung, Tool-Auswahl und erstem Prototyp.