RAG-Systeme für Unternehmen — Wissensdatenbank-Chat mit eigenen Dokumenten

Der häufigste Wunsch in unseren KI-Erstgesprächen mit mittelständischen Geschäftsführungen lautet seit drei Jahren fast wortgleich: „Wir wollen einen Chatbot, der unsere eigenen Dokumente kennt — unsere Verträge, unsere technischen Datenblätter, unsere Service-Handbücher.“ Dahinter steht eine richtige Intuition: ein generisches Sprachmodell kennt das Internet, aber nicht die hauseigene Auftragsabwicklung, das interne Compliance-Handbuch oder das gesammelte Wissen aus zehn Jahren Support-Tickets. Genau diese Lücke schließt Retrieval-Augmented Generation, kurz RAG — und es ist 2026 das mit Abstand wichtigste KI-Architekturmuster für den Mittelstand. Dieser Artikel zeigt, was RAG technisch leistet, wann es die richtige Wahl ist, wie ein produktionstaugliches System aufgebaut wird, welche Vektor-Datenbanken und Embedding-Modelle in Frage kommen und wie Sie die Antwort-Qualität messbar machen. Für die strategische Einordnung siehe unseren KI-Guide für den Mittelstand.

Was ist RAG — Definition und Abgrenzung zu Fine-Tuning

Retrieval-Augmented Generation ist ein Architekturmuster, das ein Sprachmodell zur Laufzeit mit zusätzlichem Kontext versorgt, der nicht in seinem Trainingsdatensatz steht. Statt das Modell auf neue Inhalte zu trainieren, durchsucht das System bei jeder Nutzeranfrage eine eigene Dokumentenbasis nach relevanten Passagen und liefert diese Passagen zusammen mit der Frage an das Modell. Das Modell generiert seine Antwort dann nicht aus reinem Vorwissen, sondern aus den konkret bereitgestellten Quellen. Der Unterschied zu klassischem Prompt-Engineering ist die Skalierbarkeit: RAG funktioniert auch dann, wenn die Dokumentenbasis hunderttausende Seiten umfasst, weil nur die jeweils relevanten Auszüge in den Kontext geladen werden.

Die Abgrenzung zu Fine-Tuning ist für Entscheiderinnen wichtig, weil beide Konzepte häufig verwechselt werden. Fine-Tuning bedeutet, das Modell selbst auf eigenen Daten weiter zu trainieren — die internen Gewichte verändern sich, und das Modell „weiß“ danach mehr. Das klingt zunächst eleganter, hat in der Praxis aber drei Nachteile: erstens dauert jeder Trainingslauf Stunden bis Tage und kostet vierstellige Beträge, zweitens sind die Quellen einer Antwort nicht mehr nachvollziehbar, drittens veralten die einprogrammierten Inhalte sofort, sobald sich das zugrundeliegende Material ändert. Für reines Faktenwissen ist Fine-Tuning daher selten die richtige Wahl. Es lohnt sich vor allem dort, wo Stil, Format oder Domänensprache verändert werden sollen — etwa wenn ein Modell konsequent in einem juristischen Schreibstil antworten soll oder wenn es ein internes Klassifikations-Schema beherrschen muss.

RAG dagegen hält das Modell unverändert und tauscht stattdessen die Dokumentenbasis dynamisch aus. Eine neue Vertragsversion ist nach wenigen Minuten Teil des Systems, ein zurückgezogenes Datenblatt verschwindet sofort, jede Antwort enthält Quellenangaben mit Seitenzahl. Diese Eigenschaften sind im Mittelstand entscheidend, weil sie nicht nur technische Anforderungen sind, sondern juristische — wer einer Mitarbeiterin eine Antwort gibt, muss sagen können, woher sie kommt.

Wann RAG sinnvoll ist — typische Use-Cases

Nicht jede KI-Anwendung braucht RAG. Sinnvoll ist es überall dort, wo ein Modell auf eigene, oft aktualisierte, oft umfangreiche Inhalte zugreifen soll und die Antworten nachvollziehbar bleiben müssen. Vier Use-Cases dominieren in unserer Mittelstands-Praxis:

• Technische Dokumentation und Service-WissenMaschinenbauer, Anlagenbauer und Softwarehersteller speichern Tausende Seiten an Bedienungsanleitungen, Wartungsplänen und Fehler-Codes. Ein RAG-System macht diese Wissensbasis für Service-Technikerinnen direkt durchsuchbar — typische Antwortzeit unter fünf Sekunden, mit Verweis auf konkrete Handbuch-Seiten.
• Verträge, Angebote und Rechts-TexteVertriebs- und Rechtsabteilungen arbeiten mit Hunderten von Verträgen, Rahmen-Vereinbarungen und Standardklauseln. RAG findet vergleichbare Klauseln aus älteren Verträgen, beantwortet Fragen zu Laufzeiten und Sonderkonditionen und erkennt Abweichungen zu Standardvorlagen.
• Interne Wissensdatenbank und OnboardingHR, IT-Helpdesk und Compliance pflegen Confluence-, SharePoint- oder Notion-Wissensbasen, die ungenutzt verstauben, weil die Suche schlecht ist. RAG macht aus diesen Beständen einen echten Assistenten — neue Mitarbeitende fragen in natürlicher Sprache, statt durch verschachtelte Ordner zu klicken.
• Support-FAQ und KundenserviceCustomer-Support-Teams beantworten dieselben Fragen Tag für Tag. Ein RAG-System lernt aus alten Tickets und FAQ-Artikeln und schlägt der Support-Mitarbeiterin eine Antwort vor, die sie nur noch prüfen und versenden muss. Realistische Bearbeitungs-Zeit-Reduktion: 35 bis 60 Prozent.

Worin RAG dagegen schwach ist: bei mathematischen Berechnungen, bei reinen Logik-Aufgaben ohne Bezug zu Quelltexten und bei kreativen Aufgaben ohne dokumentierte Grundlage. Wer einen Texter-Assistenten für Marketing-Slogans bauen will, braucht kein RAG, sondern ein gutes Prompt-Template. Mehr zur Tooling-Auswahl im KI-Tools-Vergleich 2026.

RAG-Architektur — die fünf Komponenten

Ein produktionstaugliches RAG-System besteht aus fünf klar abgegrenzten Komponenten. Wer eine davon weglässt oder schludert, bekommt entweder schlechte Antworten oder ein nicht skalierbares System. Die Komponenten greifen in dieser Reihenfolge ineinander:

Komponente	Aufgabe	Typische Wahl 2026
Embedding-Modell	Wandelt Text-Chunks und Nutzerfragen in numerische Vektoren	OpenAI text-embedding-3-large, Voyage-3, BGE-M3
Vektor-Datenbank	Speichert Chunk-Vektoren, liefert ähnliche Vektoren in Millisekunden	pgvector, Qdrant, Pinecone, Weaviate
Retrieval-Logik	Übersetzt Frage in Vektor, fragt DB ab, filtert nach Metadaten	Hybrid Search aus BM25 + Vektor-Ähnlichkeit
Reranking	Sortiert die Top-N Treffer mit präziserem Modell neu	Cohere Rerank, Voyage rerank-2, BGE-Reranker
LLM-Generator	Erzeugt Antwort aus Frage und Top-Chunks mit Quellenverweis	Claude Sonnet 4.5, GPT-5, Gemini 2.5 Pro

Der eigentliche Wert-Hebel sitzt an einer Stelle, die in Demos oft übersprungen wird: das Reranking. Eine Vektor-Suche liefert typischerweise 20 bis 50 grob passende Chunks. Ohne Reranking landet alles davon im Modell-Kontext — das ist verschwenderisch und reduziert die Antwortqualität. Mit einem dedizierten Reranker-Modell wird diese Liste auf die fünf bis acht tatsächlich relevantesten Chunks reduziert, bevor das LLM antwortet. Wir messen in Kundenprojekten durch sauberes Reranking regelmäßig 15 bis 25 Prozent bessere Faithfulness-Scores bei gleichem Modell und gleicher Datenbasis.

Vektor-Datenbanken im Vergleich

Die Vektor-Datenbank ist die zentrale Infrastruktur-Entscheidung im RAG-Aufbau, weil sie über Betriebskosten, Datenresidenz und Skalierungs-Verhalten entscheidet. Vier Optionen dominieren 2026 den Markt — die Wahl hängt weniger von der Vektor-Performance als von den umliegenden Anforderungen ab.

Lösung	Betriebs-Modell	Stärke	Schwäche
pgvector	PostgreSQL-Erweiterung, self-hosted	Keine Zusatz-Komponente, transaktional, DSGVO-einfach	Bei mehreren Millionen Chunks Index-Tuning nötig
Qdrant	Self-hosted oder Cloud, EU-Region verfügbar	Sehr schnelle Filter-Logik, ausgereifte Metadaten, Open-Source	Zweite DB zu betreiben, eigenes Backup
Weaviate	Self-hosted oder Cloud	Modul-System mit eingebettetem Vektorisierer, GraphQL-API	Komplexer Betrieb, höhere Lernkurve
Pinecone	Reine Managed-Cloud (US-Anbieter)	Null Betriebsaufwand, sehr schnelle Skalierung	Datenresidenz mit DSGVO-Argumentation nötig

Für mittelständische Erstprojekte ist unsere Standardempfehlung pgvector — die Mehrzahl der Kundinnen hat ohnehin eine PostgreSQL-Datenbank im Einsatz, der Mehraufwand für die Vektor-Erweiterung ist eine Stunde Konfiguration, und die DSGVO-Diskussion entfällt komplett. Ab etwa fünf Millionen Chunks oder wenn komplexe Metadaten-Filter mit hoher Schreiblast gefragt sind, wechseln wir auf Qdrant. Pinecone empfehlen wir nur, wenn explizit Managed-Service-Komfort über Datenresidenz steht — selten der Fall im Mittelstand.

Embedding-Modelle — Auswahl und Kosten

Das Embedding-Modell bestimmt die Qualität jeder Suche im RAG-System, denn die Vektor-Datenbank kann nur so präzise antworten, wie das Embedding den semantischen Gehalt eines Texts abbildet. Vier Modell-Familien sind 2026 relevant:

• OpenAI text-embedding-3-large — 3072 Dimensionen, sehr gute deutsche Qualität, 0,13 Dollar pro Million Token. EU-Datenresidenz über Azure OpenAI mit Standorten in Frankfurt und Schweden möglich.
• Voyage voyage-3-large — 1024 Dimensionen, in vielen unabhängigen Benchmarks Spitzenreiter für Fachtexte, 0,18 Dollar pro Million Token. Anthropic-naher Anbieter, US-Hosting.
• Cohere embed-multilingual-v3 — 1024 Dimensionen, hervorragend für gemischtsprachige Korpora mit mehr als zwei Sprachen, 0,10 Dollar pro Million Token. EU-Hosting verfügbar.
• BGE-M3 / Multilingual-E5-large — Open-Source, self-hosted auf einer T4- oder L4-GPU lauffähig, kostenlos in der Lizenz. Qualität auf Deutsch liegt rund fünf bis zehn Prozent unter den US-Anbietern, dafür verlassen Daten das eigene Netz nicht.

Eine pragmatische Faustregel: solange keine streng vertraulichen Inhalte eingebettet werden, ist OpenAI text-embedding-3-large auf Azure die wirtschaftlich klügste Wahl — gute Qualität, EU-Standort, niedriger Preis. Für DSGVO-strenge Setups mit Verträgen, Personalakten oder Patientendaten ist self-hosted BGE-M3 die Empfehlung. Wichtig: das gewählte Modell muss konsequent eingesetzt werden, sowohl beim initialen Befüllen der Datenbank als auch bei jeder späteren Suchanfrage. Ein Wechsel des Embedding-Modells erfordert ein vollständiges Neu-Indizieren des gesamten Bestands.

Chunking-Strategien

Chunking — also das Zerlegen langer Dokumente in einzelne Vektor-bare Stücke — ist der unscheinbarste, aber qualitätskritischste Schritt im RAG-Aufbau. Schlechtes Chunking kann durch kein Embedding-Modell und kein Reranking ausgeglichen werden. Drei Strategien dominieren die Praxis:

Feste Größe mit Overlap. Der einfachste Ansatz: jedes Dokument wird in Stücke fester Token-Länge geteilt, typischerweise 400 bis 800 Token, mit 10 bis 15 Prozent Overlap zwischen aufeinander folgenden Chunks. Vorteil: deterministisch, schnell, in zwei Stunden implementiert. Nachteil: zerreißt logische Einheiten wie Tabellen, Vertragsklauseln und Code-Blöcke an beliebigen Stellen.

Struktur-bewusstes Chunking. Chunks folgen der Dokumentstruktur — also Überschriften-Hierarchie, Paragraphen-Grenzen, Vertragsklauseln oder Markdown-Sections. Bei technischer Dokumentation und juristischen Texten liefert dieser Ansatz regelmäßig 15 bis 30 Prozent bessere Retrieval-Ergebnisse. Implementierung dauert ein bis zwei Tage je Dokumenttyp.

Semantisches Chunking. Ein zusätzliches Modell entscheidet pro Absatz, ob er thematisch mit dem vorigen verschmolzen oder als neuer Chunk begonnen wird. Höchste Qualität, aber teuerster Index-Lauf und am schwersten zu warten. Empfehlung nur für sehr heterogene Bestände, in denen weder Token-Grenzen noch Struktur-Marker sinnvoll funktionieren.

Für 80 Prozent der Mittelstands-Projekte ist Struktur-bewusstes Chunking mit moderaten 600 Token Maximalgröße und 80 Token Overlap die richtige Wahl. Eine ergänzende Best Practice ist das Anreichern jedes Chunks mit Metadaten — Dokumenttyp, Version, Datum, Mandant, Sprache — damit die Retrieval-Logik später nach Mandant filtern oder veraltete Versionen ausschließen kann.

Bewertung der Antwort-Qualität — Recall, Precision, Faithfulness, RAGAS

Ein RAG-System ohne Mess-Setup ist ein Blindflug. Die folgenden vier Kennzahlen gehören in jedes RAG-Projekt vom ersten Prototyp an — sie liefern objektive Zahlen statt Bauchgefühl und machen Verbesserungen vergleichbar.

Kennzahl	Was sie misst	Zielwert (Produktion)
Context Recall	Anteil relevanter Dokumente, die das Retrieval gefunden hat	über 70 Prozent
Context Precision	Anteil tatsächlich relevanter Treffer unter den abgerufenen	über 60 Prozent
Faithfulness	Anteil der Antwort-Aussagen, die durch Quellen gedeckt sind	über 80 Prozent
Answer Relevancy	Wie direkt die Antwort die ursprüngliche Frage adressiert	über 75 Prozent

Das RAGAS-Framework — ein Open-Source-Projekt für RAG-Evaluation — automatisiert diese Messungen, indem es ein zweites Sprachmodell als Judge einsetzt. Praktisch heißt das: Sie pflegen einen Testdatensatz aus 50 bis 200 typischen Fragen mit Musterlösungen, RAGAS schickt sie durchs System und berechnet pro Frage die vier Kennzahlen. Diese Mess-Pipeline läuft idealerweise automatisch bei jeder Änderung am System — anderes Embedding-Modell, anderes Chunking, anderer Prompt — und liefert sofort eine Vergleichszahl.

Aus der Praxis: die häufigste Schwäche frischer RAG-Systeme ist niedriger Context Recall — also das Retrieval findet die richtigen Dokumente nicht. Die zweithäufigste ist niedrige Faithfulness — das Modell erfindet Inhalte trotz vorhandener Quellen. Beide Probleme haben unterschiedliche Lösungen, und ohne Messung wäre nicht zu entscheiden, welches zu adressieren ist.

Sicherheit und DSGVO

RAG-Systeme verarbeiten typischerweise die internen Wissensbestände — und damit das schützenswerteste Material im Unternehmen. Drei datenschutzrelevante Fragen sollten vor der Architektur-Entscheidung beantwortet sein.

Erstens die Embedding-Datenresidenz. Wer Vektor-Repräsentationen vertraulicher Dokumente an ein US-Embedding-Modell schickt, übermittelt damit verarbeitete personenbezogene oder geschäftskritische Daten in die USA. Embeddings sind zwar numerisch, aber nicht anonym — moderne Inversions-Verfahren können Originaltext mit hoher Treffsicherheit rekonstruieren. Folge: für DSGVO-strenge Inhalte gehören Embeddings entweder zu einem EU-gehosteten Anbieter wie Azure OpenAI in Frankfurt oder zu einem self-hosted Modell.

Zweitens die Mandanten-Trennung im Retrieval. Wenn ein RAG-System mehrere Abteilungen, Tochtergesellschaften oder Kunden bedient, muss die Such-Logik zwingend auf Berechtigungen filtern. Es genügt nicht, Berechtigungen erst in der UI zu prüfen — das LLM darf die fremden Chunks gar nicht erst sehen. Die saubere Lösung sind Metadaten-Filter direkt im Vektor-Datenbank-Query mit pro-Nutzerin gepflegten Berechtigungs-Tags.

Drittens das Logging. Jede Nutzeranfrage enthält potenziell sensible Informationen — eine Frage nach „Kündigung von Mitarbeiterin Müller“ ist selbst eine personenbezogene Verarbeitung. Logs sollten verschlüsselt, mandanten-getrennt und mit kurzen Aufbewahrungs-Fristen geführt werden. Für DSGVO-Konformität ist ein Logging-Konzept Pflicht-Bestandteil der Datenschutz-Folgenabschätzung. Tiefer zur DSGVO-Architektur in unserem Cluster zu KI und DSGVO und zur generellen Hosting-Frage im Vergleich LLM On-Premise vs. Cloud.

Reepa-RAG-Setup mit Claude und pgvector

Für mittelständische Erstprojekte empfehlen wir einen bewusst schlanken Stack, der in zwei bis vier Wochen produktionsreif gemacht werden kann. Der folgende Setup-Vorschlag deckt rund 80 Prozent unserer Kundenanforderungen ohne Anpassungen:

• DatenhaltungPostgreSQL mit pgvector-Erweiterung, gehostet in einer EU-Region (Hetzner, OVH, AWS Frankfurt). Eine einzige Datenbank für strukturierte Daten und Vektor-Embeddings — kein zweites System nötig.
• Embedding-ModellOpenAI text-embedding-3-large via Azure OpenAI Frankfurt für nicht-strenge Inhalte, BGE-M3 self-hosted für streng vertrauliche Bestände. Konsistenz zwischen Index-Build und Query-Time ist Pflicht.
• Retrieval und RerankingHybrid Search aus pgvector-Cosine-Similarity und PostgreSQL-Full-Text-Search, gefolgt von Cohere-Rerank für die Top 20 Treffer. Reduktion auf 5 bis 8 finale Chunks für den Modell-Kontext.
• LLM-GeneratorClaude Sonnet 4.5 für die meisten Antworten, Claude Opus 4 für komplexe Vertragsanalysen. Beide via Anthropic-API mit EU-Datenverarbeitungs-Zusatz im DPA.
• OrchestrierungVercel AI SDK in einer Next.js-Anwendung, deployt auf einer EU-Region. Streaming-Antworten, Quellenangaben pro Antwort, Audit-Log in derselben PostgreSQL-DB.
• EvaluationRAGAS-Pipeline mit 100 kuratierten Testfragen, automatischer Lauf bei jeder Konfigurationsänderung, Dashboard mit Trend-Zahlen für Context Recall, Precision und Faithfulness.

Dieser Stack ist bewusst undramatisch — keine exotischen Komponenten, keine Vendor-Abhängigkeit über zwei Lieferanten hinaus, klare DSGVO-Argumentation. Der erste Prototyp läuft typischerweise innerhalb von drei Wochen, produktionsreife Qualität mit RAGAS-Validierung erreichen wir nach acht bis zwölf Wochen. Wer die Prompt-Seite des Setups vertiefen möchte, findet die wichtigsten Muster in unserem Prompt-Engineering-Cluster.

Häufige Fragen