Sechs Monate nach Projektbeginn kann das Team immer noch nicht erklären, warum das Modell selbstsicher eine Richtlinie zitiert, die vor zwei Jahren aktualisiert wurde. Das Retrieval-System liefert Dokumente. Das Modell generiert Antworten. Die Halluzinationen bestehen. Die übliche Diagnose: “Wir brauchen ein besseres Modell.” Die tatsächliche Diagnose: Die Retrieval-Schicht wurde als Suchmaschine gebaut, und Suchmaschinen sind keine Beweissammlungssysteme.
Diese Unterscheidung ist nicht semantisch. Sie verändert das, was Sie bauen.
Das RAG-Missverständnis, das sechs Monate kostet
Retrieval-Augmented Generation, RAG, steht für Retrieve, Augment, Generate. Die meisten Enterprise-Implementierungen konzentrieren sich stark auf den Generate-Schritt (welches Modell, welches Prompt) und behandeln Retrieve als gelöstes Problem, weil Semantic-Search-Bibliotheken existieren und Tutorials das Chunking trivial aussehen lassen.
Das architektonische Versagen liegt im Augment-Schritt. Augmentation ist keine Konkatenation. Es ist der Prozess der Zusammenstellung eines Kontextfensters, das dem Modell die spezifischen Beweise liefert, die es benötigt, um die Frage ohne Lücken zu beantworten. Wenn die Augmentation versagt, füllt das Modell Lücken mit Trainingswissen. Das ist der Halluzinations-Mechanismus.
Das mentale Modell, das Scheitern vorhersagt: Wenn Sie RAG als “semantische Suche mit einer Zusammenfassungsschicht obendrauf” betrachten, werden Sie genau das bauen und sich fragen, warum das Modell immer noch Dinge erfindet.
Das mentale Modell, das Erfolg vorhersagt: RAG ist ein Beweissammlungssystem. Die Retrieval-Schicht ist ein Ermittler, der die richtigen Dokumente, die richtigen Abschnitte mit den richtigen Metadaten zurückliefern muss. Das Modell ist eine Reasoning-Schicht, die auf diese Beweise angewendet wird. Das Modell kann nicht gut über schlechte Beweise urteilen.
Die naiven RAG-Fehler-Modi
Vier Fehler-Modi machen den Großteil der Halluzinationsprobleme in Enterprise-RAG-Deployments aus:
Fixed-size Chunking. Der Standard in den meisten Tutorials: Text alle 512 Tokens teilen, 50 Tokens überlappen, speichern. Ein Verfahren, das über zwei Seiten beschrieben wird, wird an einer Chunk-Grenze geteilt. Das Modell erhält die Hälfte eines Verfahrens und füllt den Rest aus dem Training. Fix: semantisches oder hierarchisches Chunking, das die Dokumentstruktur bewahrt.
Kein Reranking. Top-K nach Kosinus-Ähnlichkeit ist nicht Top-K nach Relevanz für die tatsächliche Frage. Ein Dokument mit hoher Embedding-Ähnlichkeit zu den Anfragebegriffen kann weniger relevant für die Benutzerabsicht sein als ein Dokument mit geringerer Ähnlichkeit aber direkter prozeduraler Abdeckung. Fix: Cross-Encoder-Reranking als zweiter Durchlauf nach dem initialen Retrieval.
Fehlende Metadaten-Filterung. Die Retrieval-Schicht gibt Dokumente aus der falschen Abteilung, falschen Sprache oder veralteten Versionen zurück. Das Modell kann eine aktuelle Richtlinie nicht von einer veralteten unterscheiden ohne explizite temporale und Klassifizierungs-Metadaten. Fix: Jeder Chunk trägt Quelle, Datum, Eigentümer, Jurisdiktion und Klassifizierung; Filterung geschieht vor der Vektorsuche, nicht danach.
Kein Faithfulness-Check. Die Antwort des Modells wird nicht gegen den erhaltenen Kontext verifiziert. Eine Antwort kann flüssig, selbstsicher und faktisch inkonsistent mit den abgerufenen Dokumenten sein. Fix: Faithfulness-Scoring als Gate, nicht als nachträgliches Log.
Jeder Fehler-Modus ist unabhängig. Das Beheben des Chunkings ohne Beheben des Rerankings produziert eine andere Klasse von Halluzinationen, nicht null Halluzinationen.
Der erweiterte Retrieval-Stack, der tatsächlich funktioniert
Die folgenden Retrieval-Techniken sind keine universell anzuwendende Checkliste. Jede adressiert einen spezifischen Fehler-Modus. Alle einzusetzen ohne einen Ziel-Fehler-Modus verschwendet Engineering-Zeit.
Hybrid Search mit RRF Fusion. BM25 (Keyword-Matching) kombiniert mit dichter Vektorsuche, Ergebnisse fusioniert mit Reciprocal Rank Fusion. BM25 erfasst Exact-Match-Terme, Gerätecodes, Namen, Referenznummern, die dichte Vektoren schlecht handhaben. Die dichte Suche erfasst semantische Absicht, die BM25 verfehlt. Die Kombination übertrifft beides allein auf Enterprise-Dokumenten-Corpora. Das ist jetzt die Baseline, keine erweiterte Option.
HyDE (Hypothetical Document Embedding). Statt die Frage des Benutzers einzubetten und nach ähnlichen Dokumenten zu suchen, generiert das Modell eine hypothetische ideale Antwort auf die Frage, und diese Antwort wird eingebettet und für das Retrieval verwendet. Auf diese Weise abgerufene Dokumente entsprechen der Struktur und Spezifität einer korrekten Antwort und nicht der Struktur einer Frage. Besonders effektiv für technisches Dokumenten-Retrieval, wo die Frageformulierung stark von der Antwortformulierung abweicht.
RAG-Fusion. Mehrere Umformulierungen der ursprünglichen Anfrage generieren, parallele Retrievals für jede ausführen, Ergebnisse fusionieren. Verbessert den Recall für Anfragen, bei denen die Formulierung des Benutzers nicht der direkteste Weg zum relevanten Dokument ist.
Cross-Encoder-Reranking. Nach dem initialen Retrieval bewertet ein Cross-Encoder-Modell jedes (Anfrage, Dokument)-Paar gemeinsam, statt unabhängige Embeddings zu vergleichen. Langsamer als Vektorsuche, läuft auf einem kleinen Kandidatensatz (Top-20 bis Top-50), verbessert die Präzision erheblich. Bibliotheken wie FlashRank bieten selbst-hostbares Cross-Encoder-Reranking.
Hierarchisches Chunking. Übergeordnete Chunks halten Dokumentzusammenfassungen; untergeordnete Chunks halten granulare Inhalte. Retrieval operiert auf der übergeordneten Ebene, um relevante Abschnitte zu identifizieren, ruft dann die untergeordneten Chunks für Kontext ab. Bewahrt die Dokumentstruktur bei gleichzeitiger Ermöglichung granularen Retrievals. Geeignet für lange regulatorische Dokumente, technische Handbücher und Vertragsrepositories.
Die Retrieval-Schicht ist kein Detail. Sie ist die Einschränkung, die bestimmt, wie viel von der Fähigkeit des Modells tatsächlich nutzbar ist.
Das Evaluations-Framework, das Deployment-Reue verhindert
Enterprise-Teams, die RAG ohne Evaluations-Harness deployen, operieren auf Meinungsbasis. Die Meinungen sind oft falsch, und die Entdeckung ist teuer.
Das RAGAS-Framework bietet vier Metriken, die zusammen RAG-Qualität messen, ohne menschliche Annotation für jede Antwort zu erfordern:
- Faithfulness: Ist die Antwort im abgerufenen Kontext verankert, oder führt sie Behauptungen ein, die nicht durch die Dokumente gestützt werden?
- Answer Relevancy: Adressiert die Antwort die Frage des Benutzers?
- Context Precision: Sind die abgerufenen Chunks relevant für die Frage?
- Context Recall: Wurden alle relevanten Chunks abgerufen, oder fehlt Material?
Geringe Faithfulness bei hoher Context Precision bedeutet, dass das Modell die Beweise ignoriert. Geringer Context Recall bedeutet, dass die Retrieval-Schicht relevante Dokumente verpasst. Jede Metrik identifiziert eine andere Systemschicht zum Beheben.
Bauen Sie das Evaluations-Dataset vor dem Deployment, nicht danach: 50 bis 100 repräsentative Fragen mit erwarteten Antworten und Quellenzitierungen, aus der tatsächlichen Nutzerpopulation entnommen. Jede Prompt-Änderung, jedes Modell-Upgrade, jede Chunking-Modifikation und jede Reranking-Parameteränderung wird gegen diese Baseline getestet. Das ist Regressionstesting, angewendet auf ein probabilistisches System.
Der Produktions-Feedback-Loop erweitert das Eval-Set kontinuierlich: Benutzerkorrekturen, abgelehnte Antworten und eskalierten Anfragen werden zu neuen Testfällen. Der Eval-Harness ist kein einmaliges Gate, er ist der Mechanismus zur Aufrechterhaltung der Qualität, wenn das System sich weiterentwickelt.
Sicherheit und Berechtigungen in Enterprise-RAG
Die Retrieval-Schicht erbt Datenberechtigungen. Ein Benutzer, der ein RAG-System abfragt, sollte keine Dokumente abrufen, auf die er im Quellsystem keinen Zugriff hat. Die meisten Enterprise-RAG-Deployments überspringen das bis zum Security-Review.
Row-Level-Security in Vektor-Datenbanken erfordert, dass jeder Chunk Benutzergruppen-, Klassifizierungs- und Jurisdiktions-Metadaten trägt, und dass diese Metadaten zum Retrieval-Zeitpunkt durchgesetzt werden, nicht nach dem Retrieval gefiltert. Nach dem Retrieval zu filtern bedeutet, dass das Dokument abgerufen und vom System bearbeitet wurde, auch wenn es dem Benutzer nicht angezeigt wird. Je nach Jurisdiktion ist das relevant.
Private-Perimeter-RAG hält Daten innerhalb der Infrastruktur der Organisation. Modell-Inferenz läuft On-Premise oder in einer privaten Cloud-Umgebung. Kein Dokumentinhalt, kein Chunk und kein Embedding verlässt den Perimeter. Für regulierte Branchen und DSGVO-sensible Daten ist das Architektur, keine Präferenz.
Die Audit-Trail-Anforderung verdient explizite Behandlung: Für EU-AI-Act-Compliance und ISO-42001-Ausrichtung muss das System die Frage beantworten können: “Welche Dokumente haben diese Antwort begründet, für welchen Benutzer, zu welchem Zeitpunkt?” Ein RAG-System ohne Audit-Trail ist unabhängig von der Genauigkeit seiner Antworten nicht compliant.
Wann RAG nicht die Antwort ist
RAG ist die richtige Architektur für eine spezifische Klasse von Enterprise-Wissensproblemen: Frage-Antwort über ein heterogenes Dokumenten-Corpus, wo die Antwort in spezifischen Passagen verankert sein kann.
Es ist nicht die richtige Architektur für jedes Wissensabrufproblem.
Wenn die Frage gleichzeitig eine Synthese über Hunderte von Dokumenten erfordert, Beziehungen zwischen Entitäten über ein Corpus hinweg verfolgt oder regulatorische Anforderungen über mehrere Jurisdiktionen verbindet, ist GraphRAG geeigneter. Graph-basiertes Retrieval durchquert Entitätsbeziehungen; Vektor-Retrieval findet ähnliche Passagen. Das sind unterschiedliche Operationen.
Wenn die Wissensdomäne hochstrukturiert, tabellarisch oder transaktional ist, ist eine deterministische Abfrageschicht zuverlässiger als Vektorsuchverfahren. Das Modell, das SQL generiert und gegen eine strukturierte Datenbank ausführt, wird Vektorsuche, die auf Dokumente angewendet wird, die strukturierte Daten beschreiben, übertreffen.
Wenn das Wissen statisch, gut begrenzt und stabil ist, kann eine kompilierte Kontextschicht oder ein feinabgestimmtes Modell das Retrieval übertreffen. RAG fügt Latenz und Komplexität für einen Nutzen hinzu, der nur materialisiert, wenn die Wissensdomäne groß, dynamisch oder heterogen ist.
Die richtige Rahmung: RAG ist eine Beweisabruf-Architektur. Stimmen Sie die Architektur auf die epistemische Struktur des Problems ab. Beginnen Sie mit dieser Frage, nicht mit dem Framework, das am einfachsten zu deployen ist.
Die Ingestion Pipeline ist der Ort, an dem die meisten RAG-Qualitätsprobleme entstehen, bevor das Modell jemals eine Anfrage sieht. Diese Architektur ist hier abgedeckt.
Wenn Ihr Team bewertet, welche Retrieval-Architektur zu Ihrem spezifischen Anwendungsfall passt, ist der AI Opportunity Sprint der Ausgangspunkt.