Wer 2026 als CIO ohne RAG-Strategie ins Budget-Meeting geht, hat einen schweren Stand. Retrieval-Augmented Generation ist die Standard-Antwort auf die Frage "Wie verbinden wir das Sprachmodell mit unseren eigenen Daten?" — und genau deshalb scheitern rund 70 Prozent der ersten Implementierungen. Nicht an der Technik, sondern an Permissions, Chunking-Strategie oder fehlendem Re-Ranking. Dieser Artikel ist die Architektur-Übersicht, die wir in jedem Audit zeichnen, bevor jemand über Pinecone oder Qdrant nachdenkt.
1. Was RAG ist — und was nicht
RAG ist kein Modell, sondern eine Architektur. Das Sprachmodell bleibt dasselbe (GPT-4, Claude, Mistral, was auch immer). Geändert wird, was das Modell sieht, bevor es antwortet: statt nur des User-Prompts bekommt es relevante Passagen aus eurer Wissensbasis mitgeliefert.
Der entscheidende Punkt: RAG ist nicht Fine-Tuning. Beim Fine-Tuning trainiert ihr ein Modell auf eigene Daten — teuer, langsam, oft ungeeignet, weil sich euer Wissen wöchentlich ändert. RAG arbeitet zur Laufzeit. Ein neues Dokument wird abends indexiert, morgens kann das System darauf antworten. Genau das ist der praktische Vorteil im Mittelstand.
Median-Setup-Kosten Production-RAG für 100 GB Unternehmensdaten DACH 2026
2. Die sieben Schichten — und wo es kracht
Jede der folgenden Schichten hat eigene Entscheidungen. Wer eine auslässt oder unsauber baut, sieht das spätestens in der dritten User-Frage.
Schicht 1 — Connector
Hier holt ihr Daten aus SharePoint, Confluence, Jira, dem Fileshare, SAP-Belegen, dem Outlook-Archiv. Klingt trivial, ist es nicht. Decision-Points:
- Pull oder Push? Pull-Connectoren (z. B. via Microsoft Graph API) sind einfacher zu bauen, brauchen aber Throttling. Push-Connectoren (Event Hub, Kafka) skalieren besser bei häufigen Änderungen.
- Wie oft re-indexieren? Volle Re-Indizes wöchentlich, Delta-Updates täglich oder eventbasiert sind die drei realistischen Optionen.
- Wie übersetzt ihr Permissions? SharePoint-ACLs müssen ins Vector-Store als Metadaten wandern — sonst leakt ihr Daten an User, die das Original nie gesehen hätten.
Schicht 2 — Chunking
Dokumente werden in Stücke zerschnitten, weil ein Embedding-Modell nicht 200 Seiten am Stück verarbeitet und das Sprachmodell sowieso nicht. Decision-Points:
- Fixe Größe oder semantisches Chunking? Fix (z. B. 600 Tokens) ist einfach, semantisches Chunking (am Absatz, an Überschriften) liefert bessere Retrieval-Qualität bei strukturierten Texten.
- Overlap? 10 bis 15 Prozent zwischen Chunks fängt Kontext-Verluste an Schnittstellen ab.
- Sonderbehandlung für Tabellen, Code-Blöcke, Listen? Ja — wer Excel-Tabellen mit dem gleichen Chunker wie Fließtext zerlegt, bekommt Schrott zurück.
Für deutsche Fachtexte (Versicherungsbedingungen, technische Dokumentation, juristische Texte) bewährt sich in der Praxis ein hybrider Ansatz: semantisches Chunking entlang Überschriften, mit hartem Max-Cap bei 800 Tokens.
Schicht 3 — Embedding
Jeder Chunk wird in einen Vektor übersetzt — eine Zahlenreihe, die
"Bedeutung" repräsentiert. Hier entscheidet ihr zwischen API-basiert
(OpenAI text-embedding-3-large, Cohere) und lokal (BGE, E5, deutsche
Multilingual-Modelle wie intfloat/multilingual-e5-large).
Decision-Points:
- Sind eure Texte mehrheitlich deutsch? Dann ist ein Multilingual-Modell oder ein deutsches Embedding-Modell oft besser als OpenAI-Default.
- Müsst ihr DSGVO-konform sein bei sensiblen Daten? Dann lokal — Embedding-Generation auf eigener Hardware oder in EU-Cloud.
- Wie hoch dürfen Inferenz-Kosten sein? OpenAI-Embeddings kosten in 2026 bei 100 GB ungefähr 200 bis 400 Euro für die Erst-Indizierung.
Schicht 4 — Vector-Store
Die Vektoren müssen irgendwo liegen, abfragbar in Millisekunden. Drei realistische Optionen im DACH-Mittelstand 2026:
- pgvector (PostgreSQL-Extension): wenn ihr ohnehin Postgres habt, bis ~10 Millionen Vektoren völlig ausreichend. Niedrigste Betriebskosten.
- Qdrant: Open-Source, EU-hostbar, performante Filter-Logik, brauchbares Hosting unter 50 Euro im Monat möglich.
- Pinecone: managed, gut, aber US-only kritisch bei DSGVO-Setups — und ab gewisser Größe teurer als selbst gehostetes Qdrant.
Wer kein klares Performance-Argument für Pinecone hat, fährt 2026 mit pgvector oder Qdrant besser.
Schicht 5 — Retrieval
Bei einer User-Frage wird die Frage embedded, dann werden die k ähnlichsten Chunks gesucht (Vektor-Distanz). Decision-Points:
- k? Übliche Werte sind 5 bis 20. Zu wenig: Kontext fehlt. Zu viel: Sprachmodell wird verwirrt und langsamer.
- Hybrid-Search (BM25 + Vektor)? In ungefähr 30 Prozent der Fälle schlägt klassische Keyword-Suche kombiniert mit Embeddings die reine Vektor-Suche — vor allem bei Eigennamen, Produkt-IDs, Vertragsnummern.
- Permissions-Filter zur Query-Zeit? Pflicht. Niemals nachträglich filtern, immer im Vector-Store-Query.
Schicht 6 — Re-Ranking
Die Retrieval-Schicht ist schnell, aber grob. Re-Ranking ist die
sauber-präzise Sortierung der Top-Treffer durch ein zweites,
spezialisiertes Modell — typischerweise ein Cross-Encoder
(cross-encoder/ms-marco, Cohere Rerank).
Schicht 7 — Generation
Die finale Antwort: das Sprachmodell bekommt die gerankten Top-Chunks als Kontext, die User-Frage und einen System-Prompt. Decision-Points:
- Welches Modell? Claude 4 / GPT-4o für komplexe deutsche Antworten, Haiku / Mistral Small für kostensensitive Massen-Queries.
- Citation-Pflicht? Bei Wissens-Bots Pflicht. Das Modell muss in der Antwort die Quell-Chunks nennen, sonst ist die Antwort nicht überprüfbar.
- Streaming oder Batch? UX-Frage. Streaming wirkt schneller, ist aber technisch aufwendiger.
3. Wo die meisten ersten RAG-Setups sterben
Drei wiederkehrende Fehler aus 25 Audits 2025/2026:
Fehler 1 — Permission-Bypass. Die Daten liegen unverschlüsselt im Vector-Store, der RAG-Bot zeigt jedem User alles. Lösung: Permission-Metadaten beim Indexing in jeden Chunk schreiben (User-Group, SharePoint-ACL-Hash), beim Retrieval als harter Filter mitsenden.
Fehler 2 — Chunking auf Default-Settings. Jemand nimmt
RecursiveCharacterTextSplitter mit 1000 Tokens ohne Overlap und
wundert sich, warum Antworten Halbsätze zitieren. Lösung: einen Tag
Zeit nehmen, Chunking-Strategie auf eigene Dokumenttypen anpassen,
mit Eval-Set testen.
Fehler 3 — Kein Re-Ranking. Top-5 aus reiner Vektor-Distanz genommen, ans LLM gegeben, fertig. Die Antworten sind okay, aber nicht gut. Re-Ranking nachrüsten kostet zwei Tage und liefert messbar bessere Outputs.
4. Praxis-Kosten 2026
Aus drei realen Setups im DACH-Mittelstand mit jeweils 80 bis 150 GB Indexierungs-Volumen:
| Komponente | Kosten einmalig | Kosten laufend |
|---|---|---|
| Connector-Engineering (3-5 Quellen) | €15.000-25.000 | — |
| Chunking + Embedding-Pipeline | €8.000-15.000 | €200-500/Mon (Compute) |
| Vector-Store (Qdrant EU) | €2.000-4.000 | €100-400/Mon (Hosting) |
| Retrieval + Re-Ranking | €5.000-12.000 | €100-300/Mon |
| LLM-Generation (Claude/GPT-4) | €3.000-8.000 (Eval) | €800-2.500/Mon (Inferenz) |
| Monitoring + Eval-Setup | €5.000-10.000 | €100-300/Mon |
| Summe | €38.000-74.000 | €1.300-4.000/Mon |
Das ist der Median für 100 GB Daten. Wer 10 GB hat, kommt mit der Hälfte hin. Wer 1 TB hat und Hybrid-Search auf Enterprise-Scale braucht, landet schnell im sechsstelligen Bereich.
5. Wann RAG übertrieben ist
Nicht jede Wissensfrage braucht eine Vektor-Datenbank. Wenn euer Use-Case lautet "die zwölf häufigsten Kundenfragen werden vom Bot beantwortet", reicht ein gepflegtes FAQ-Skript plus Sprachmodell vollkommen aus — kein Indexing, keine Embedding-Kosten, keine Operational Complexity.
Faustregel: Unter ungefähr 200 Dokumenten oder bei sehr stabilem Fragenkatalog ist RAG Overkill. Ab vier-bis-fünfstelligen Dokumentzahlen oder hoher Frage-Vielfalt führt aber kein Weg dran vorbei.
Häufige Fragen
Was Tech-Verantwortliche zu RAG fragen.
Welche Chunk-Größe ist optimal für deutsche Fachtexte?
Pinecone vs Qdrant vs pgvector — was wann?
Wie löst man Permissions ohne Index-Bypass?
Lokal-Embedding vs OpenAI — was lohnt sich?
Wann reicht ein FAQ-Bot statt RAG?
Was als Nächstes?
Wer 2026 RAG einführen will, fängt nicht mit dem Vector-Store an, sondern mit zwei Fragen: Welche Dokumente sollen rein, und wer darf welche sehen. Wenn diese beiden Antworten sauber sind, ist die technische Implementierung in vier bis acht Wochen machbar — bei sauberer Architektur und Re-Ranking von Anfang an. Ein RAG-Audit bei uns kostet €6.500 und liefert in drei Wochen eine vollständige Architektur-Empfehlung mit Kostenmodell und Tool-Auswahl. Discovery-Call dauert 30 Minuten und kostet nichts.