Warum RAG — und nicht einfach ChatGPT?
ChatGPT (oder ein anderes Foundation Model) kennt Ihr Unternehmen nicht. Es kennt keine internen Service-Berichte, keine spezifischen Konstruktions-Standards, keine kundenspezifischen Konditionen, keine Hersteller-Spezifikationen. Wer ChatGPT zu unternehmensspezifischen Themen befragt, bekommt entweder eine generische Antwort („nach allgemeinen Maßstäben…“) oder eine erfundene Antwort (Halluzination). Beides ist im Geschäftskontext nicht brauchbar.
RAG löst genau dieses Problem. Vor jeder LLM-Antwort werden relevante Quellen aus einer eigens aufgebauten Wissensdatenbank geholt und dem LLM als Kontext mitgegeben. Das LLM beantwortet die Frage auf Basis dieser Quellen. Vorteile: aktuelle Daten (Wissensdatenbank wird regelmäßig aktualisiert), geringere Halluzination (Modell hat Quellen, muss nicht raten), Quellenangabe in jeder Antwort möglich, Datenschutz (Quellen können privat bleiben — kein Modell-Training).
RAG ist die häufigste produktive KI-Architektur im Mittelstand 2026. Wir setzen RAG in etwa 70 % unserer Mandate ein, häufig kombiniert mit anderen Komponenten (agentische Workflows, klassische ML, Voice).
Standard-Architektur
RAG-Pipeline — Daten- und Anfrage-Pfad
- 1
Daten-Pipeline
Quellen extrahieren (PDF, Word, DB, API), bereinigen, chunken, embedden, in Vektor-DB speichern.
- →Sauberer Index
- →Metadaten erfasst
- →Re-Indexierungs-Job
- 2
Anfrage-Verarbeitung
User-Frage embedden, Query-Erweiterung (optional), hybride Suche (Vektor + BM25).
- →Query-Embedding
- →Kandidaten-Set
- 3
Re-Ranking
Kandidaten neu sortieren mit Cross-Encoder (z. B. Cohere Rerank, BGE Reranker).
- →Top-N relevante Quellen
- 4
Generierung
LLM bekommt Quellen + Frage als Kontext, antwortet mit Quellen-Verlinkung.
- →Antwort + Quellen
- →Logging für Eval
Datenaufbereitung — wo 60 % der Arbeit liegt
Die meisten RAG-Probleme entstehen nicht beim Modell, sondern bei den Daten. Wir investieren in Pilotprojekten regelmäßig 50–65 % des Aufwands in die Daten-Pipeline. Die wichtigsten Aufgaben:
- Quellen-Extraktion: PDFs (oft mehrseitig, mit Tabellen, mit Bildern), Word/Excel-Dokumente, SharePoint-Bibliotheken, Confluence/Notion, Datenbank-Exports, E-Mail-Archive, Wissens-Tickets aus Service-Tools.
- OCR für historische Bestände: Scans, Faxausdrucke, alte Kopien. Tesseract als Open-Source-Option, kommerzielle Tools (Azure Document Intelligence, Google Document AI) für komplexere Layouts.
- Bereinigung: Duplikate entfernen, veraltete Versionen markieren, Boilerplate (Header, Footer) abschneiden.
- Strukturierung: Hierarchie erkennen (Kapitel, Abschnitte), Tabellen extrahieren, Bild-Captions erfassen.
- Metadatenanreicherung: Pro Chunk: Quell-Dokument, Datum, Autor, Komponente/Produkt, Sprache, Berechtigung.
- Versionierung: Änderungs-Verfolgung, damit obsolete Inhalte rauswandern können.
Chunking-Strategien
Chunks sind die Einheiten, die in der Vektor-DB gespeichert werden. Die Strategie ist domänenspezifisch:
Embeddings — Modell-Wahl
Embeddings sind die mathematische Repräsentation, die semantische Ähnlichkeit messbar macht. Im Mittelstand mit deutschsprachigen Inhalten haben sich folgende Modelle 2026 bewährt:
- Cohere multilingual-v3 — Beste Balance aus Qualität, Kosten (ca. 0,10 $/1M Tokens), Mehrsprachigkeit. EU-Hosting verfügbar.
- BAAI/bge-m3 — Open Source, selbst hostbar, sehr gute Qualität auf Deutsch. Beste Wahl für Datenschutz-Maximalismus.
- OpenAI text-embedding-3-large — Hohe Qualität, breite Verbreitung. US-Hosting (problematisch für sensible Daten).
- Voyage AI voyage-3 — Sehr gute Qualität, eher hochpreisig.
Wichtig: Sobald ein Embedding-Modell gewählt ist, sollte es konsequent gehalten werden — Wechsel erfordert vollständige Re-Indexierung. Wir empfehlen, im Pilot 2 Modelle gegen das Eval-Set zu testen und dann eines verbindlich zu wählen.
Retrieval & Re-Ranking
Standard-Vektor-Suche allein reicht in Produktion fast nie. Wir empfehlen ein dreistufiges Setup:
- Hybrid Retrieval: Vektor-Suche (Top-30) + BM25-Suche (Top-30), Vereinigung der Kandidaten (Top-50 nach Reziprokal-Rank-Fusion).
- Re-Ranking: Cross-Encoder (Cohere Rerank-3 oder BGE Reranker) auf die Top-50 Kandidaten, Auswahl Top-N (typisch 5–8).
- Optional Query-Erweiterung: User-Frage über LLM in 2–3 Suchanfragen umformulieren, Ergebnisse mergen. Verbessert Recall bei vagen Fragen.
Antwort-Generierung
Das LLM bekommt im Prompt die Top-N Quellen plus die User-Frage. Wichtig: das LLM muss explizit angewiesen werden, ausschließlich aus den Quellen zu antworten und „weiß ich nicht“ zu sagen, wenn die Antwort nicht in den Quellen steht. Quellen-Verlinkung ist Pflicht. Beispiel-System-Prompt (verkürzt):
Du bist ein Wissens-Assistent. Beantworte Fragen ausschließlich auf Basis
der unten gegebenen Quellen. Wenn die Quellen die Frage nicht beantworten,
sage genau: "Diese Information habe ich nicht in den verfügbaren Quellen
gefunden." Verlinke jede Aussage mit der Quelle in eckigen Klammern,
z.B. [Bericht-Nr. 7842, Abschnitt 4.2].
Quellen:
{quellen}
Frage: {frage}
Antwort:Modell-Wahl
- Mistral Large via La Plateforme EU — sehr gute Wahl im Mittelstand (EU-Hosting, gute Qualität, faire Kosten).
- Claude 3.5 Sonnet via Anthropic EU — exzellente Qualität bei komplexen Antworten, sehr gutes Instruction-Following.
- GPT-4-Klasse via Azure OpenAI EU — Standard, breit getestet, höchste Verbreitung.
- Llama 3.x oder Mistral Open-Weight selbst gehostet — für Datenschutz-Maximalismus oder hohe Volumina.
Eval-Pipeline — wie messe ich Qualität?
Ein Eval-Set ist ein zentrales Asset jedes RAG-Projekts. Wir bauen typisch 50–200 Test-Cases auf:
- Standard-Fragen mit bekannter erwarteter Antwort
- Out-of-Scope-Fragen (System soll „weiß ich nicht“ sagen)
- Mehrdeutige Fragen (System sollte Klärung anfordern)
- Adversariale Fragen (Versuche, das System zu Halluzinationen zu bewegen)
- Domänen-spezifische Edge Cases
Pro Test-Case wird gemessen: Antwort-Korrektheit, Quellen-Übereinstimmung, Halluzinations-Quote, Antwort-Vollständigkeit. Tools: ragas (Open Source), eigene Eval-Pipelines mit LLM-as-Judge oder menschlichen Reviews. Eval läuft im CI/CD bei jedem Modell-Wechsel und mindestens monatlich.
Häufige Fehler — und wie wir sie vermeiden
- Zu wenig Aufwand in Daten-Pipeline. 60 % des Aufwands gehört in die Daten — wer das überspringt, hat einen schönen Bot, der unzuverlässig antwortet.
- Falsche Chunking-Strategie. Standardmäßig 500 Tokens funktioniert nicht für alle Datenklassen. Strategie domänenspezifisch testen.
- Kein Re-Ranking. Reine Vektor-Suche ist in Produktion zu schwach. Re-Ranking ist Pflicht.
- Keine Quellen-Verlinkung. Akzeptanz-Killer Nr. 1. Ohne Quellen vertrauen Anwender dem System nicht.
- Eval erst spät. Eval-Set sollte im Pilot von Anfang an existieren, nicht „nach Roll-out“.
- Falsches Erwartungsmanagement. RAG ist sehr gut, aber nicht perfekt — typische Genauigkeit 80–90 % bei sauber gebauten Setups. Best Practices: Restrisiko klar kommunizieren, Mensch-im-Loop bei kritischen Anwendungen.
- Vendor-Lock-in im LLM. Wer im Code nur eine spezifische LLM-API hardcoded, kann später nicht wechseln. Abstraktion ist Pflicht.
Kosten & Skalierung
Typische Kosten-Struktur eines mittelständischen RAG-Setups (Jahr 1)
Skalierung in der Vektor-DB: pgvector skaliert auf einzelnen Nodes bis ca. 10–50 Mio. Vektoren komfortabel; darüber Sharding oder Wechsel auf spezialisierte Lösungen. Im Mittelstand selten relevant — typisches Datenvolumen 0,1–5 Mio. Vektoren.
Wenn Sie einen RAG-Use-Case planen, ist der einfachste Schritt ein kostenfreies Erstgespräch. Wir prüfen Ihre Datenlage und liefern eine erste Architektur-Skizze. Konkrete Beispiel-Implementierung in unserer Maschinenbau-Case-Study.