RAG & Wissensbasis
Ihre Daten. Präzise Antworten. Null Halluzinationen.
Wir bauen RAG-Pipelines, die tatsächlich in der Produktion funktionieren — mit hybrider Suche, Re-Ranking und messbarer Qualität.
Was ist RAG und warum Sie es brauchen¶
Retrieval-Augmented Generation (RAG) ist ein Architekturmuster, das Datensuche mit generativer KI kombiniert. Anstatt sich nur auf sein Training zu verlassen, sucht das LLM für jede Anfrage zunächst relevante Informationen aus Ihren Quellen und formuliert dann eine Antwort basierend darauf — mit Quellenangaben.
Warum nicht einfach LLM?¶
Ein eigenständiges LLM (GPT-4, Claude, Llama) hat drei grundlegende Probleme für den Unternehmenseinsatz:
- Wissensstichtag — kennt Ihre internen Dokumente, Prozesse, aktuelle Daten nicht
- Halluzinationen — wenn es die Antwort nicht kennt, erfindet es eine mit überzeugender Zuversicht
- Nicht überprüfbar — Sie können nicht verifizieren, woher die Information stammt
RAG löst alle drei: Das Modell antwortet nur aus dem bereitgestellten Kontext, zitiert Quellen und arbeitet mit aktuellen Daten.
Architektur eines Produktions-RAG-Systems¶
┌──────────────────────────────────────────────────────────────┐
│ INGESTION-PIPELINE │
│ │
│ Quellen (DMS, Wiki, E-Mail, DB) │
│ │ │
│ ▼ │
│ Dokumentenverarbeitung (OCR, Parsing, Bereinigung) │
│ │ │
│ ▼ │
│ Semantisches Chunking (adaptiv, nicht feste Größe) │
│ │ │
│ ▼ │
│ Embedding + Indexierung (Vektor-DB + BM25) │
│ │ │
│ ▼ │
│ Metadatenanreicherung (Autor, Datum, Version, Kategorie) │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ ABFRAGE-PIPELINE │
│ │
│ Benutzeranfrage │
│ │ │
│ ▼ │
│ Query Expansion (HyDE, Multi-Query) │
│ │ │
│ ▼ │
│ Hybrides Retrieval (dense + sparse, α-Blending) │
│ │ │
│ ▼ │
│ Re-Ranking (Cross-Encoder, domänengetunt) │
│ │ │
│ ▼ │
│ Kontextaufbereitung (Deduplizierung, Ordnung, Token-Budget) │
│ │ │
│ ▼ │
│ LLM-Generierung (mit Zitaten, mit Guardrails) │
│ │ │
│ ▼ │
│ Output-Validierung (Treueprüfung, PII-Schwärzung) │
└──────────────────────────────────────────────────────────────┘
Chunking — das Fundament, auf dem alles steht¶
Naives Chunking (Dokumente alle 512 Token schneiden) ist der häufigste Fehler in RAG-Systemen. Kontext wird mitten im Satz unterbrochen, Tabellen aufgeteilt, Referenzen verlieren ihre Bedeutung.
Unser Ansatz: - Semantisches Chunking — wir teilen nach semantischen Grenzen (Abschnitte, Absätze, Themen) - Hierarchische Chunks — Eltern-Chunk (ganzer Abschnitt) + Kind-Chunks (Absätze). Retrieval auf Kind, Kontext vom Eltern. - Überlappung mit intelligentem Schnitt — Überlappung an Satzgrenzen, nicht mitten im Wort - Tabellen und strukturierte Daten — spezielle Behandlung, Beibehaltung der Struktur - Metadaten-Propagierung — jeder Chunk trägt Metadaten aus dem Dokument (Titel, Autor, Datum, Kapitel)
Für jedes Projekt testen wir 3-5 Chunk-Konfigurationen auf echten Anfragen. Wir messen Recall@k und wählen die optimalen Einstellungen.
Hybride Suche¶
Vektorsuche allein (Dense Retrieval) hat Schwächen — erfasst exakte Begriffe, IDs, Zahlen schlecht. BM25 allein (Sparse) versteht keine Semantik. Die Kombination beider liefert konsistent bessere Ergebnisse.
Reciprocal Rank Fusion (RRF): Standardmethode zur Kombination von Ergebnissen mehrerer Retriever. Jeder Retriever gibt Top-k zurück, Ergebnisse werden zusammengeführt und neu gerankt. Typisches Verhältnis Dense:Sparse 0,7:0,3, aber wir tunen pro Domäne.
Re-Ranking — wo der Unterschied gemacht wird¶
Bi-Encoder-Embeddings sind schnell, aber ungenau für feine Relevanzunterscheidung. Cross-Encoder Re-Ranking nimmt die Top-50-Ergebnisse und ordnet sie mit voller Attention zwischen Anfrage und Dokument neu. Verbessert typischerweise Precision@5 um 15-25 %.
Wir verwenden Cohere Rerank, BGE-Reranker oder domänengetunete Cross-Encoder für spezifische Domänen.
RAG-Qualitätsevaluierung¶
Metriken, die wir messen¶
Retrieval-Qualität: - Recall@k — wie viele relevante Dokumente sind in den Top-k-Ergebnissen - NDCG — Qualität des Ergebnis-Rankings - MRR — Position des ersten relevanten Ergebnisses
Generierungsqualität: - Treue (Faithfulness) — wird die Antwort durch den Kontext gestützt? (nicht erfunden) - Antwortrelevanz — beantwortet die Antwort die Anfrage? - Vollständigkeit — deckt die Antwort alle Aspekte der Anfrage ab? - Halluzinationsrate — wie viele Behauptungen in der Antwort sind nicht im Kontext verankert
Golden Dataset¶
Für jedes RAG-Projekt erstellen wir einen Golden Dataset — 200-500 Paare (Anfrage, erwartete Antwort, relevante Dokumente). Dieser Datensatz dient als: - Benchmark für die Qualitätsmessung - Regressionstest bei Änderungen (neues Modell, neues Chunking, neue Dokumente) - Grundlage für die kontinuierliche Evaluierung in CI/CD
Häufige Fehler bei der RAG-Implementierung¶
In den letzten Jahren haben wir Dutzende von RAG-Systemen auditiert. Häufigste Probleme:
1. Naives Chunking¶
Problem: Chunks fester Größe (512 Token) brechen Kontext, Tabellen, Listen auf. Lösung: Semantisches Chunking mit hierarchischer Struktur.
2. Fehlendes Re-Ranking¶
Problem: Bi-Encoder-Retrieval liefert „ungefähr relevante” Ergebnisse, aber die Präzision ist gering. Lösung: Cross-Encoder Re-Ranking verbessert die Präzision um 15-25 %.
3. Keine Evaluierung¶
Problem: „Es funktioniert” bei 5 Testanfragen ≠ es funktioniert in der Produktion. Lösung: Golden Dataset, automatische Eval-Suite, kontinuierliches Monitoring.
4. Ignorieren von Metadaten¶
Problem: Chunk ohne Kontext (welches Dokument, welche Version, welches Datum) führt zu falschen Antworten. Lösung: Umfangreiche Metadaten auf jedem Chunk + Metadatenfilterung bei der Abfrage.
5. Übersehen der OCR-Qualität¶
Problem: Müll rein, Müll raus. Schlechtes OCR = schlechte Chunks = schlechte Antworten. Lösung: OCR-Qualitätspipeline mit Validierung, Fallback zu Vision-Modellen für komplexe Dokumente.
Produktions-Deployment¶
Ingestion-Pipeline¶
- Quellsysteme überwachen (SharePoint, Confluence, DMS, S3)
- Inkrementelle Verarbeitung — nur neue/geänderte Dokumente
- Versionierung — ältere Chunk-Versionen archivieren, neue indexieren
- Quality Gates — Dokumente mit niedriger OCR-Qualität gehen in manuelle Überprüfung
Skalierung¶
- Vektor-DB (Qdrant/Weaviate) skaliert horizontal auf Millionen von Dokumenten
- Embedding-Berechnung parallelisieren (Batch-Verarbeitung)
- Caching — häufige Anfragen auf Retrieval- und Generierungsebene cachen
- CDN für statische Wissensbasis (interne Dokumentation)
Monitoring¶
- Retrieval-Qualitätsmetriken (tägliche Eval auf Golden Dataset)
- Abfragelatenz (P50/P95/P99)
- Cache-Hit-Rate
- Fehlgeschlagene Anfragen (kein relevanter Kontext gefunden)
- Nutzer-Feedback-Schleife (Daumen hoch/runter)
Wenn RAG nicht ausreicht¶
RAG ist kein Allheilmittel. Situationen, die einen anderen Ansatz erfordern:
- Modell kennt die Domäne überhaupt nicht → Fine-Tuning + RAG
- Sie brauchen Reasoning über die gesamte Wissensbasis → Graph RAG oder Agentisches RAG
- Daten ändern sich in Echtzeit → Streaming-Ingestion + RAG
- Anfragen erfordern Multi-Hop-Reasoning → Agentischer Workflow mit RAG als Tool
In diesen Fällen kombinieren wir RAG mit anderen Techniken aus unserem Portfolio.
Häufig gestellte Fragen
RAG fügt jeder Anfrage Kontext aus externen Quellen hinzu — das Modell antwortet basierend auf aktuellen Daten. Fine-Tuning verändert das Modell selbst — es lernt neue Verhaltensmuster. RAG ist besser für Faktenanfragen aus sich ändernden Daten, Fine-Tuning für konsistenten Stil oder spezialisierte Domänen. Wir kombinieren häufig beides.
Praktisch unbegrenzt. Unsere Deployments arbeiten typischerweise mit Hunderttausenden bis Millionen von Dokumenten. Der Schlüssel ist Chunking und Indexierung — ein richtig konzipiertes System hat konstante Latenz unabhängig von der Größe der Wissensbasis.
Inkrementelle Ingestion-Pipeline — wir überwachen Änderungen in Quellsystemen (DMS, Wiki, SharePoint), re-indexieren automatisch geänderte Dokumente. Chunk-Versionen werden getrackt, sodass wir aus einer bestimmten Dokumentversion antworten können.
Multilinguale Embeddings (Cohere multilingual, BGE-M3) bewältigen sprachübergreifendes Retrieval. Eine Anfrage auf Deutsch findet relevante Chunks auf Englisch und umgekehrt. Für spezifische Sprachkombinationen testen wir und wählen das optimale Modell.
Drei Ebenen: Retrieval-Qualität (Recall@k, NDCG, MRR), Generierungsqualität (Treue, Antwortrelevanz, Vollständigkeit), End-to-End (Nutzerzufriedenheit, Lösungsrate). Automatische Eval-Suites + LLM-as-Judge + menschliche Annotation zur Kalibrierung.