RAG von Grund auf: vom Dokument zur verifizierten Antwort
Eine Production-RAG-Pipeline von Ingestion, Normalisierung, Chunking und Embeddings über Retrieval und Reranking bis zu Grounded Generation, Zitaten und Evaluation.
Artikelinhalt
Was RAG löst
Retrieval-Augmented Generation ergänzt eine Anfrage um externe Wissensfragmente. Dadurch kann ein System mit privaten Dokumenten, aktuellen Daten und Quellen arbeiten, die beim Training des Modells nicht vorhanden waren.
RAG aktualisiert die Parameter des LLM nicht. Das Wissen bleibt in einem externen Speicher und kann deshalb versioniert, gelöscht, zugriffsbeschränkt und zitiert werden.
Ingestion und Normalisierung
PDFs, HTML, E-Mails und Tabellen enthalten Rauschen: Menüs, Duplikate, Kopf- und Fußzeilen, versteckte Zeichen und falsche Lesereihenfolgen. Wenn die Ingestion Struktur verliert, kann Retrieval sie später nicht wiederherstellen.
Jedes Fragment sollte document_id, Version, Quelle, Datum, Sprache, Zugriffsrechte und seine Position im Original behalten. Metadaten werden für Filterung, Zitate und das Entfernen veralteter Einträge benötigt.
Chunking und Repräsentation
Zu kleine Chunks verlieren Kontext, zu große Chunks vermischen Themen und belegen wertvollen Platz im Kontextfenster. Sinnvoller sind semantische Grenzen wie Überschriften, Absätze, Policy-Klauseln oder Code-Funktionen.
Nach der Normalisierung werden Chunks in Embeddings umgewandelt. Vektorsuche findet semantische Ähnlichkeit, sollte für Namen, Codes und exakte Begriffe aber mit Keyword Search und Metadatenfiltern kombiniert werden.
Retrieval, Reranking und Grounding
Der erste Retriever liefert schnell Kandidaten, während ein Reranker genauer bestimmt, welche Fragmente die Anfrage tatsächlich beantworten. An das Modell sollte nur ein kompakter Satz der stärksten Evidenz gehen.
Das Modell sollte auf Basis der bereitgestellten Quellen antworten und fehlende Evidenz ausdrücklich melden. Zitate werden aus realen source_id-Werten gebildet, und das System prüft, ob jede Kennung im Kontext vorhanden war.
RAG evaluieren
Retrieval und Generation sollten getrennt evaluiert werden. Wenn das richtige Dokument nicht gefunden wurde, liegt das Problem nicht am Modell. Wenn die Evidenz gefunden wurde, die Antwort aber unbelegte Aussagen ergänzt, liegt das Problem beim Grounding oder in der Generation Policy.
Ein Eval-Set sollte reale Fragen, erwartete Quellen, korrekte Antworten und negative Fälle enthalten, in denen das System ablehnen muss. Geeignete Metriken sind Retrieval Recall, Precision, Groundedness und Citation Accuracy.
Eine minimale Production-RAG-Architektur
Ein grundlegender RAG-Stack besteht aus Ingestion, Normalisierung, Chunking, Embeddings, Index, Retrieval und Antwortgenerierung. In Production kommen ACLs, Dokumentversionierung, Metadata Filters, Reranking, Query-Logging und ein Mechanismus zum Entfernen veralteter Fragmente hinzu. Ohne diese Schichten wird ein Prototyp schnell zu einer unkontrollierten Vektorsammlung.
Jeder Chunk sollte Provenance behalten: Dokument, Version, Seite oder Abschnitt, Indexierungszeit und Zugriffsrechte. So lässt sich eine Antwort erklären, prüfen und nach einer Quellenänderung zurückziehen. Ein Vektor ohne Herkunft ist für ein zuverlässiges System fast unbrauchbar.
Retrieval getrennt von der Generation evaluieren
Wenn eine Antwort falsch ist, muss zuerst geklärt werden, ob das Modell die erforderliche Evidenz erhalten hat. Retrieval wird mit Recall, Precision, Hit Rate, MRR oder nDCG auf Queries mit bekannten relevanten Fragmenten bewertet. Die Generation wird separat geprüft: Nutzung der Quellen, Widerspruchsfreiheit und korrekte Zitate.
Diese Trennung verkürzt die Diagnose. Wenn ein relevanter Chunk nicht gefunden wurde, hilft eine Prompt-Änderung nicht; verbessern Sie Chunking, Embeddings, Query Rewriting oder Reranking. Wenn die Evidenz vorhanden ist, aber ignoriert wird, untersuchen Sie Context Assembly, Instruktionen oder das Modell.
Typische Ursachen für RAG-Fehler
Häufige Probleme sind zu große oder zu kleine Chunks, fehlende Metadata Filters, Duplikate, vermischte Dokumentversionen, schwache Nutzeranfragen und zu viele zurückgegebene Fragmente. Mehr Kontext garantiert keine bessere Antwort: irrelevante Passagen senken das Signal und erzeugen Widersprüche.
Starten Sie mit einem kleinen Eval-Dataset, messen Sie Retrieval vor der Einbindung des LLM und protokollieren Sie jede Stufe. Nach dem Launch sollten fehlgeschlagene Queries gesammelt, Ursachen klassifiziert und Index oder Pipeline anhand von Fakten statt einzelner Demos verbessert werden.
End-to-End-Abnahme für das erste RAG
Behandeln Sie das erste RAG als messbare Pipeline: Ingestion, Parsing, Chunking, Embedding, Indexing, Retrieval, Reranking, Generation und Citation Validation. Jede Stufe braucht eigene Identifikatoren und Traces, damit sichtbar wird, wo das richtige Dokument verloren ging. Das Evaluation Dataset sollte reale Queries, erwartete Quellen und Kriterien für Vollständigkeit enthalten. Bei unzureichender Evidenz sollte die Antwort ablehnen oder um Klärung bitten, statt schwaches Retrieval durch selbstsichere Generation zu kaschieren.
Der Production-Baseline gehören Access Filters im Retrieval, ein versionierter Index, idempotentes Reindexing und Rollback an. Die Metriken sollten recall@k, Citation Precision, Groundedness, p95 Latency und Cost per Successful Answer abdecken. Nach jeder Änderung an Embeddings, Chunking oder Prompts wird derselbe Regression Set erneut ausgeführt.
- Trennen Sie Retrieval-Fehler von Antwortfehlern.
- Behalten Sie Source IDs in der finalen Antwort.
- Nutzen Sie einen kontrollierten Reindex-Prozess.
Praktische Beispiele
Evidence Package
Der Retriever liefert source_id, document_version, Fragment, Score und Access Policy. Die Antwort darf nur Fragmente aus diesem Paket zitieren.
FAQ
Braucht jedes RAG eine Vektordatenbank?
Nein. Für einen kleinen Corpus können PostgreSQL, eine Suchmaschine oder sogar eine kontrollierte Keyword-Suche ausreichen.
Warum erfindet RAG Zitate?
Das passiert, wenn das Modell Referenzen als freien Text generiert. Source IDs sollten strukturiert übergeben und nach der Generierung validiert werden.
Wann sollte der Index aktualisiert werden?
Bei Änderungen der Quellen oder gemäß einem definierten SLA. Jede Dokumentversion sollte rückverfolgbar bleiben.