RAG-Systeme selbst gebaut — was ich in AuditShield gelernt habe

Kaum ein Begriff wird in KI-Projekten so oft fallen gelassen wie RAG — Retrieval Augmented Generation. Jeder Softwareanbieter behauptet inzwischen, sein Produkt sei "RAG-basiert", jede Beratung verspricht, damit ließen sich Compliance-Fragen in Sekunden beantworten. Der Hype verspricht ein System, das jedes Dokument versteht und nie lügt. Die Realität: RAG ist ein solides, gut verstandenes Architekturmuster — aber es steht und fällt mit fünf technischen Entscheidungen, die in den Marketing-Folien meist fehlen. Ich habe diese Entscheidungen für AuditShield, meine eigene KI-Plattform für ISO 27001, TISAX und NIS2, alle selbst getroffen — mit ein paar teuren Fehlern auf dem Weg. Dieser Artikel fasst zusammen, was davon für Sie als Entscheider relevant ist, auch wenn Sie RAG nicht selbst bauen, sondern bei einem Anbieter einkaufen.

Was RAG wirklich ist

Ohne Buzzwords: Ein LLM (Large Language Model) kennt nur, was in seinen Trainingsdaten stand — meist bis zu einem Stichtag, meist ohne Ihre internen Dokumente. RAG ergänzt das LLM um eine Suche in Ihrem eigenen Wissen, bevor das Modell antwortet. Statt "Was weißt du über A.5.7?" zu fragen und auf eine vage, möglicherweise erfundene Antwort zu hoffen, sucht das System zuerst den passenden Abschnitt aus dem tatsächlichen ISO-27001-Katalog heraus und gibt ihn dem LLM als Kontext mit. Das Modell antwortet dann auf Basis dieses Kontexts, nicht auf Basis von Vermutungen.

Eine häufige Frage in Beratungsgesprächen: Warum nicht einfach das Modell auf die eigenen Daten fine-tunen, also nachtrainieren? Für die meisten KMU-Anwendungsfälle ist das die falsche Antwort. Fine-Tuning ist teuer, muss bei jeder Dokumentenänderung wiederholt werden, und es macht das Modell nicht zuverlässiger bei Fakten — es verändert eher Stil und Verhalten. Wenn sich Ihr ISO-27001-Katalog oder Ihre Rechtstexte ändern, wollen Sie das nicht neu trainieren, sondern einfach neue Dokumente in eine Datenbank einspielen. Genau das leistet RAG: Wissen bleibt austauschbar, das Modell bleibt unverändert.

Der klassische RAG-Flow läuft in fünf Schritten ab: Eine Nutzeranfrage (Query) wird in einen Vektor umgewandelt (Embedding), dieser Vektor wird gegen eine Datenbank mit vorab indexierten Dokumenten abgeglichen (Retrieve), die Ergebnisse werden nach Relevanz neu sortiert (Rerank), die besten Treffer werden in einen Prompt eingebettet, und erst dann generiert das LLM die eigentliche Antwort. Jeder dieser Schritte kann gut oder schlecht umgesetzt sein — und das Endergebnis ist immer nur so gut wie das schwächste Glied.

Die fünf Komponenten in der Praxis

Chunking — die häufigste Fehlerquelle

Bevor Dokumente überhaupt in die Datenbank kommen, müssen sie in Abschnitte zerlegt werden — Chunking. Das ist der Schritt, an dem die meisten RAG-Projekte scheitern, ohne dass es jemandem auffällt, weil das System trotzdem "irgendwie" antwortet, nur eben schlecht. Zu große Chunks (etwa ganze Kapitel) verwässern die Relevanz: Das Retrieval findet den Abschnitt, aber der enthält zu viel Rauschen, und das LLM verliert sich. Zu kleine Chunks (einzelne Sätze) reißen den Kontext auseinander — eine Anforderung und ihre Ausnahmeregelung landen in getrennten Chunks und werden nie gemeinsam gefunden.

In der Praxis funktionieren für strukturierte Compliance-Texte Chunk-Größen von 300 bis 600 Tokens mit einem Overlap von 10 bis 20 Prozent am besten — der Overlap verhindert, dass ein Satz genau an der Chunk-Grenze zerschnitten wird und seinen Sinn verliert. Noch wichtiger als die reine Größe ist aber die Methode: Semantisches Chunking, das an natürlichen Grenzen wie Absätzen, Paragraphen oder Kontrollnummern trennt, schlägt fixed-size Chunking (starre Zeichen- oder Tokenanzahl ohne Rücksicht auf Struktur) in fast jedem Compliance-Anwendungsfall deutlich.

Embeddings — Sprache ist keine Nebensache

Ein Embedding-Modell wandelt Text in einen Vektor um, der die Bedeutung repräsentiert. Ähnliche Bedeutungen liegen im Vektorraum nah beieinander. Das Problem: Viele der bekanntesten Embedding-Modelle sind primär auf Englisch trainiert und optimiert. Bei deutschen Compliance-Texten mit ihrer spezifischen Terminologie — "Auftragsverarbeitungsvertrag", "Meldepflicht", "Schutzbedarfsfeststellung" — verlieren rein englische Modelle deutlich an Präzision. Ein Vektor, der "Bedrohungsanalyse" nicht klar von "Risikoanalyse" unterscheiden kann, führt zu falschen Treffern im Retrieval, lange bevor das LLM überhaupt beteiligt ist.

Für deutschsprachige oder mehrsprachige Anwendungsfälle haben sich in meiner Erfahrung Modelle wie jina-embeddings-v3, BGE-M3 und E5-Multilingual als deutlich robuster erwiesen als rein englische Alternativen. Sie sind speziell für mehrsprachige Retrieval-Aufgaben trainiert und behandeln deutsche Fachbegriffe nicht als Fremdkörper. Der Unterschied ist im laufenden Betrieb spürbar: gleiche Frage, gleicher Dokumentenbestand, aber deutlich höhere Trefferquote bei den wirklich relevanten Abschnitten.

Vector-Datenbank — für KMU meist Postgres+pgvector

Die Vektoren müssen irgendwo gespeichert und durchsucht werden. Zur Wahl stehen unter anderem Postgres mit der pgvector-Erweiterung, spezialisierte Systeme wie Qdrant oder Weaviate. Qdrant und Weaviate sind auf reine Vektorsuche optimiert und skalieren bei sehr großen Datenmengen (mehrere Millionen Vektoren, hoher gleichzeitiger Zugriff) besser. Für die meisten KMU-Anwendungsfälle — ein Compliance-Katalog, eine interne Wissensdatenbank, ein paar Zehntausend Chunks — ist das schlicht nicht die Größenordnung, um die es geht.

Ich setze bei AuditShield bewusst auf Postgres mit pgvector: Eine zusätzliche Datenbank, die ohnehin für relationale Daten (Nutzer, Audits, Berichte) läuft, kann Vektoren gleich mitverwalten. Das reduziert die Betriebskomplexität erheblich — ein System zu pflegen statt zwei, ein Backup-Prozess statt zwei, eine Zugriffskontrolle statt zwei. Für KMU mit begrenzten IT-Ressourcen ist das oft der entscheidende Vorteil gegenüber einer dedizierten Vector-DB, deren Skalierungsvorteile erst bei Datenmengen greifen, die im Mittelstand selten erreicht werden.

Retrieval und Reranking — der unterschätzte Hebel

Reine Vektorsuche findet semantisch Ähnliches, übersieht aber manchmal exakte Begriffe — etwa eine konkrete Normnummer wie "A.5.7". Hybrid-Search kombiniert deshalb Vektorsuche mit klassischer Keyword-Suche und gleicht die Schwächen beider Ansätze aus. Noch wichtiger in der Praxis: ein Reranking-Schritt danach. Die erste Suche liefert typischerweise 20 bis 50 Kandidaten-Chunks; ein Reranker wie die Modelle von Cohere oder der jina-reranker bewertet diese Kandidaten noch einmal präziser gegen die konkrete Frage und wählt die tatsächlich fünf bis zehn relevantesten aus.

Der Effekt eines guten Rerankers wird regelmäßig unterschätzt. In meinen eigenen Tests hat allein die Einführung eines Rerankers die Trefferquote der wirklich richtigen Quelle im obersten Antwortbereich um einen zweistelligen Prozentbereich verbessert — ohne dass am Embedding-Modell oder an den Chunks irgendetwas verändert wurde. Wer RAG ohne Reranking betreibt, verschenkt einen der günstigsten Qualitätshebel im gesamten System.

Prompt-Engineering — der letzte Schutzwall

Selbst mit perfektem Retrieval entscheidet der finale Prompt, was das LLM aus dem gefundenen Kontext macht. Ein gut formulierter RAG-Prompt weist das Modell explizit an, nur auf Basis des gelieferten Kontexts zu antworten, Quellen zu benennen und bei fehlender Information dies auch zu sagen — statt zu improvisieren. Das ist der wichtigste Baustein gegen Halluzinationen: Ein LLM, dem gesagt wird "antworte ausschließlich basierend auf folgendem Text, und sage explizit, wenn die Antwort nicht enthalten ist", fabuliert deutlich seltener als eines, das offen gefragt wird. RAG reduziert Halluzinationen, eliminiert sie aber nicht — dieser letzte Schutzwall im Prompt bleibt notwendig.

Meine Erfahrungen aus AuditShield

In AuditShield läuft RAG über drei Wissensquellen: den vollständigen ISO-27001-Kontrollkatalog, den TISAX-Anforderungskatalog und die relevanten NIS2-Rechtstexte. Wenn ein Nutzer fragt "Was fordert A.5.7 zur Threat Intelligence?", passiert im Hintergrund genau der oben beschriebene Flow: Die Frage wird eingebettet, gegen die indexierten Katalog-Chunks abgeglichen, die relevantesten Abschnitte werden durch den Reranker gefiltert, und erst dann generiert das LLM eine Antwort — mit Verweis auf die exakte Kontrollnummer und den Originaltext als Quelle. Ohne diese Quellenangabe wäre die Antwort für einen Auditor wertlos, egal wie gut sie klingt.

Die erste Version von AuditShield hatte gleich drei der Fehler, die ich weiter unten beschreibe. Ich habe zunächst ein rein englisches Embedding-Modell verwendet, weil es in Benchmarks gut abschnitt — bei deutschen Normtexten mit ihrer sehr spezifischen Terminologie war die Trefferqualität aber enttäuschend. Zweitens habe ich Chunks zu groß gewählt, teils ganze Unterkapitel, um "genug Kontext" zu liefern — das Ergebnis waren Antworten, die zwar plausibel klangen, aber Details aus benachbarten, nicht angefragten Kontrollen mit einmischten. Drittens gab es zunächst keinen Reranking-Schritt, weil ich die reine Vektorsuche für ausreichend hielt. Erst nach dem Wechsel zu einem mehrsprachigen Embedding-Modell, deutlich kleineren, semantisch getrennten Chunks und einem nachgeschalteten Reranker wurde die Antwortqualität so, dass ich sie im produktiven Audit-Einsatz verantworten konnte.

Die fünf typischen Fehler bei RAG-Projekten in KMU

Aus eigener Erfahrung und aus Gesprächen mit Beratungskunden, die RAG-Lösungen einkaufen oder selbst bauen wollen, wiederholen sich fünf Fehler immer wieder:

1. Sprach-Mismatch beim Embedding-Modell

Ein primär englisches Embedding-Modell wird für deutsche Fachtexte eingesetzt, ohne die Trefferqualität zu prüfen. Die Suche liefert Ergebnisse — nur eben die falschen, ohne dass das im Alltag sofort auffällt.

2. Chunks zu groß oder zu klein

Es gibt keine pauschal richtige Chunk-Größe, aber es gibt naheliegende Fehler: ganze Dokumente als ein Chunk, oder einzelne Sätze ohne jeden Zusammenhang. Beides zerstört die Retrieval-Qualität auf unterschiedliche Weise.

3. Keine Metadaten und Quellenangaben

Wenn ein Chunk nicht weiß, aus welchem Dokument, welcher Seite oder welcher Normnummer er stammt, kann die Antwort später nicht belegt werden. Für Compliance-Anwendungen ist das ein Ausschlusskriterium — eine unbelegte Antwort ist im Audit-Kontext wertlos.

4. Kein Reranking

Viele Projekte verlassen sich ausschließlich auf die erste Vektorsuche. Wie oben beschrieben, ist der Qualitätsgewinn durch einen nachgeschalteten Reranker eines der besten Kosten-Nutzen-Verhältnisse im gesamten RAG-Stack — und wird trotzdem regelmäßig übersprungen.

5. Kein Evaluation-Setup

Ohne systematische Bewertung, etwa mit einem Framework wie RAGAS, weiß niemand, ob eine Änderung an Chunking, Embedding-Modell oder Prompt die Antwortqualität tatsächlich verbessert oder verschlechtert hat. Ohne Evaluation wird RAG zur Bauchgefühl-Entwicklung — jede Anpassung ist ein Blindflug.

Wann ich RAG empfehle, wann nicht

RAG lohnt sich, wenn Sie über einen substanziellen, sich verändernden Wissensbestand verfügen, auf den regelmäßig präzise Fragen mit Quellenangabe gestellt werden — etwa Compliance-Kataloge, interne Richtlinien, Produktdokumentation oder Vertragswerke. Der Aufwand für Chunking, Embedding-Auswahl und Reranking rechnet sich, wenn viele Personen wiederholt auf dasselbe Wissen zugreifen müssen und Fehler teuer sind.

RAG lohnt sich in der Regel nicht, wenn der Wissensbestand klein und stabil ist — dann reicht oft, die relevanten Dokumente direkt in den Prompt-Kontext eines modernen LLM zu geben, ohne Retrieval-Infrastruktur aufzubauen. Ebenso wenig sinnvoll ist RAG als Antwort auf Aufgaben, die eigentlich Prozessautomatisierung sind: Wenn es um automatisierte Abläufe statt um Wissensabfrage geht, ist ein anderer Architekturansatz gefragt — dazu berate ich im Rahmen der Prozessautomatisierung gesondert. Für Beratungskunden gilt als Faustregel: Erst den tatsächlichen Anwendungsfall und die Frequenz der Abfragen klären, dann über RAG als Lösung sprechen — nicht umgekehrt.

Fazit

RAG ist kein Zaubertrick, sondern eine Ingenieursaufgabe mit fünf klar benennbaren Stellschrauben: Chunking, Embeddings, Vector-Datenbank, Retrieval mit Reranking, und Prompt-Engineering. Wer diese Bausteine versteht, kann sowohl eigene Systeme sauberer bauen als auch die Angebote von Drittanbietern kritischer prüfen — etwa mit der einfachen Frage: "Welches Embedding-Modell nutzen Sie für deutsche Texte, und setzen Sie einen Reranker ein?" Wenn die Antwort ausweichend bleibt, lohnt ein zweiter Blick. Aus meiner Arbeit an AuditShield weiß ich: Die Unterschiede zwischen einem sorgfältig konfigurierten und einem naiven RAG-System sind in der täglichen Nutzung deutlich spürbar — gerade dort, wo es auf belastbare, quellenbasierte Antworten ankommt.