Retrieval-Augmented Generation oder RAG ist ein Applikationsmuster, das relevante externe Informationen zu einem Task holt und ausgewählten Kontext an ein generatives Modell gibt. Das Modell antwortet auf Basis dieses Kontexts statt nur seiner trainierten Parameter.
Eine Vector Database macht Antworten nicht automatisch faktisch. Das System kann falsche Inhalte indexieren, irrelevante Passagen holen, entscheidende Klauseln verpassen, Berechtigungen verletzen oder Claims erzeugen, die der Text nicht trägt. End-to-end-Qualität versteckt die Fehlerstufe.
RAG ist eine kontrollierte Evidenzpipeline. Steuern Sie Quellenautorität, Berechtigung, Parsing, Retrieval, Kontext, Zitate und Answer Policy separat und evaluieren Sie jede Stufe mit Fragen aus dem echten Workflow.
Architektur
RAG besitzt mehrere Fehlerstellen
Ingestion entdeckt Content, prüft Zugriff, parst Struktur, segmentiert Text, hängt Metadaten an und aktualisiert den Index. Query Handling interpretiert Task, filtert erlaubte Quellen, holt Kandidaten, rerankt, baut Kontext und generiert. Zitate und Feedback folgen.
Ein früher Fehler propagiert. Verliert der Parser eine Tabellenspalte, kann Retrieval die Beziehung nicht rekonstruieren. Kommt Permission Filtering zu spät, ist sensibler Inhalt bereits exponiert. Geht der Source Link beim Chunking verloren, fehlt Provenance.
| Stufe | Fehlerbeispiel | Diagnose |
|---|---|---|
| Ingestion | Aktuelle Datei fehlt | Ist die führende Quelle vorhanden? |
| Retrieval | Pflichtklausel fehlt | War Evidenz in den Kandidaten? |
| Kontext | Duplikate verdrängen Details | Erhielt der Prompt genug Evidenz? |
| Generation | Claim geht über Passagen hinaus | Folgt jeder Claim? |
| Zitat | Link öffnet alte Version | Kann der Nutzer prüfen? |
Grenzen
RAG verbessert Evidenzzugriff und erzeugt nicht automatisch Wahrheit
RAG passt zu Wissen, das sich ändert, intern ist oder Zitate braucht. Es ersetzt keine deterministische Datenbank für Transaktionsstatus, keine Policy Engine für Rechte und keinen Berechnungscode. Diese Systeme können als Tools dienen.
Retrieval löst keine falsche oder wirklich ambige Quelle. Die Applikation zeigt Autorität und Konflikt und synthetisiert keine Sicherheit ohne Beleg. Für High-impact-Interpretation bleiben menschliche Owner nötig.
- Vor Kontextzugabe autorisieren.
- Version und exakten Fundort bewahren.
- Retrieval vor Model Blame evaluieren.
- Zitate auf Support statt Overlap prüfen.
- Bei fehlender oder widersprüchlicher Evidenz enthalten.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für Retrieval-Augmented Generation
- Antworten nutzen aktuelle und erlaubte Quellen.
- Nutzer prüfen Zitate, die wesentliche Claims wirklich unterstützen.
- Retrieval- und Generation-Fehler bleiben unterscheidbar.
- Contentänderungen lassen sich ohne Modelltraining indexieren und testen.
- Das System enthält sich bei fehlender oder widersprüchlicher Evidenz.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Quellenautorität und Zugriff definieren
Bestimmen Sie führende Repositories je Fragetyp und Berechtigung. Bewahren Sie Dokument-ID, Version, Gültigkeit und Owner. Wenden Sie User Permissions vor oder im Retrieval an, damit relevante, aber unzulässige Passagen nie das Modell erreichen.
- 02
Retrievable Content vorbereiten
Parsen Sie Überschriften, Tabellen, Listen und Metadaten ohne Strukturverlust. Wählen Sie Chunkgrenzen, die vollständige Bedeutung tragen, und bewahren Sie Links zum Fundort. Erkennen Sie Duplikate, ersetzte Dokumente und Extraction-Fehler vor Indexierung.
- 03
Retrieval und Kontextaufbau
Nutzen Sie lexikalische, semantische oder hybride Suche mit Filtern und bei Bedarf Reranking. Prüfen Sie, ob die nötige Evidenz im gewählten Kontext und nicht nur im Corpus liegt. Bevorzugen Sie diverse Belege statt wiederholter Near-Duplicates.
- 04
Generieren, zitieren und evaluieren
Das Modell antwortet innerhalb der Evidenz, zeigt Unsicherheit und nennt Fundorte. Validieren Sie Citation Entailment und strukturierte Felder. Messen Sie Retrieval Recall, Context Precision, Korrektheit, Unsupported Claims und Abstention separat.
Bewertung
Fragen, die den Entscheid verändern
- Welche Quelle führt bei Widersprüchen?
- Welche Chunks und Metadaten bewahren die nötige Bedeutung?
- Braucht der Task lexikalische, semantische, hybride oder Tool-Suche?
- Wie viel Evidenz muss vor einer Antwort vorliegen?
- Welche Zitatgranularität ermöglicht rasche Prüfung?
Fehlermuster
Wo Teams die Kontrolle verlieren
Unzulässiger Inhalt gelangt durch Retrieval in den Prompt.
Schlechtes Parsing trennt Tabellenwerte und Qualifier von Klauseln.
Top-Passagen sind thematisch relevant, aber ungenügend.
Das Modell zitiert eine echte Quelle, die den Claim nicht trägt.
Veraltete Duplikate ranken über dem aktuellen Dokument.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Retrieval Recall für benötigte Evidenz
- Precision und Diversität des Kontexts
- Korrektheit und Vollständigkeit der Antwort
- Citation Entailment wesentlicher Claims
- Unsupported- und angemessene Abstention-Rate
- Index Freshness und Extraction-Fehler
Fragen
Häufige Fragen
Was bedeutet RAG in KI?
RAG bedeutet Retrieval-Augmented Generation. Eine Anwendung holt externe Information und gibt sie einem generativen Modell als Kontext für die Antwort.
Verhindert RAG Halluzinationen?
Nein. Es liefert bessere Evidenz, doch Retrieval kann scheitern und das Modell unbelegte Claims bilden. Retrieval, Korrektheit, Zitate und Abstention separat messen.
Ist RAG eine Vector Database?
Nein. Ein Vector Index ist eine mögliche Komponente. Das System enthält auch Governance, Parsing, Rechte, Query Handling, Ranking, Kontext, Generation, Zitate und Evaluation.
Wann sollte ein Unternehmen RAG nutzen?
Wenn Antworten aktuelles, privates, fachspezifisches oder zitierbares Wissen brauchen. Für exakte Transaktionen, Berechnungen und Regeln sind direkte Tools besser.
Quellen
Primärquellen
Zeke
AI Product Engineering, das aus einem Software-Briefing ein zuverlässiges Produkt im Betrieb macht.
Produktverantwortliche, Gründungsteams und Software-Engineering-Teams. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zeke ansehen→