Metadaten und Filter in RAG: Pre-Filter vs Post-Filter, Qdrant Payload Index, pgvector WHERE

Was sind Metadaten in RAG?

Metadaten in RAG sind strukturierte Schlüssel-Wert-Paare, die jedem Chunk neben Text und Embedding mitgegeben werden: Mandanten-ID, Dokumenten-Typ, Erstelldatum, Vertraulichkeits-Tier, Sprache, Quellsystem, Tags, Author, MIME-Type, Hash. Sie sind das Gerüst, das aus einem semantischen Suchsystem ein produktiv brauchbares RAG-Werkzeug macht.

Ohne Metadaten findet das Retrieval die semantisch ähnlichsten Chunks, ohne Rücksicht auf Kontext-Logik. Eine Frage zu Mandant Bachmann liefert Antworten über Mandant Hartmann mit. Eine Frage zu MWST 2024 trägt Antworten von 2021 herbei. Eine Frage des Lohnbuchhalters greift auf vertrauliche Anwalts-Daten zu, die er nicht sehen darf. Alles ist semantisch korrekt, alles ist kontextuell falsch.

Im Mai 2026 ist Metadaten-Filterung ein Pflicht-Baustein in jeder produktiven RAG-Pipeline. Die Technik dafür ist in den grösseren Vektor-Datenbanken nativ verfügbar. Qdrant unterstützt Payload-Indices auf beliebigen Feldern (Keyword-Index, Range-Index für Zahlen und Daten, Full-Text-Index). Pinecone nutzt Metadata-Filter via JSON-Subset-Sprache. pgvector kombiniert Vektor-Suche mit Standard-SQL-WHERE-Klauseln (HNSW-Index plus B-Tree-Index). Weaviate hat ein Schema-basiertes Filter-System.

Die Entwurfs-Entscheidung lautet: was wird in der Metadaten-Payload gespeichert, und welche Felder werden indexiert. Indexierung kostet Memory, Filtern auf nicht-indexierten Feldern ist langsam. Ein gut entworfenes Metadaten-Schema balanciert das. Typische Pflicht-Felder: Mandant-ID, Erstelldatum, Vertraulichkeits-Tier, Quelle, Sprache. Optional: Author, Tags, Dokumenten-Typ, Schlagworte.

Warum es wichtig ist

Drei Effekte machen Metadaten zum entscheidenden Faktor in produktiven RAG-Systemen.

Erstens: Tenant-Isolation. In jeder Treuhand-Kanzlei und jedem Anwaltsbüro hat jeder Mandant Anspruch darauf, dass seine Daten nur den ihm zugeordneten Mitarbeitern zugänglich sind. Ohne Metadaten-Filter findet eine semantische Suche cross-tenant. Mit Mandanten-ID als Pflicht-Filter bei jeder Anfrage bleibt die Suche im Mandanten-Scope. Das ist nicht nur Komfort, sondern Voraussetzung für Berufsgeheimnis (StGB Art. 321) und Mandantenverhältnis.

Zweitens: Aktualitäts-Filterung. Eine Anfrage "MWST-Satz Standard 2024" darf keine 2021-Quelle zurückliefern. Time-aware Retrieval filtert Quellen auf einen relevanten Zeitraum, optional gewichtet (jüngere Quellen höher bewertet). Bei Gesetzes-Änderungen ist das Pflicht: alte Wegleitungen müssen markiert sein und bei "aktuell"-Anfragen herausfallen.

Drittens: Vertraulichkeits-Tiers. Eine Kanzlei mit Anwalts-Sekretariaten muss differenzieren: öffentliches Wissen (Gesetzes-Texte, Wegleitungen), internes Wissen (Praxis-Vermerke), Mandanten-Wissen (Akten), Spezial-Vertraulichkeit (Compliance, Disziplinar-Fälle). Metadaten-Tier plus rollenbasierte Filter ist die saubere Lösung. Ein Lohnbuchhalter sieht keine Anwalts-Akten.

Viertens: Quellen-Audit. Bei revisionsfähiger KI-Nutzung (Art. 957a OR, FINMA-Rundschreiben 2024/4) muss jede Antwort Quellen zitieren. Metadaten tragen Quellen-Information (Datei, Seite, Erstelldatum, Author), die in die Zitation eingebettet wird. Ohne Metadaten ist die Antwort nicht nachvollziehbar.

Fünftens: Performance. Ein Pre-Filter (Quelle wird vor Vektor-Suche eingeschränkt) reduziert den durchsuchten Index-Bereich oft um 90 Prozent. Suche über 100.000 Chunks wird zur Suche über 5000 Chunks - schneller und präziser.

Wie es funktioniert

Pre-Filter (vor Vektor-Suche): die Filter-Bedingung wird vor der Vektor-Suche angewandt, der Index wird auf passende Chunks reduziert, dann erst Vektor-Ähnlichkeit berechnet. Qdrant macht das über Payload-Indices effizient (Keyword-Index B-Tree-ähnlich, Range-Index für Zahlen und Daten). Effizient bei strikten, selektiven Filtern (Mandant=Bachmann reduziert von 1M auf 5000 Chunks).

Post-Filter (nach Vektor-Suche): erst Top-k=100 mit Vektor-Suche holen, dann Filter anwenden, am Ende Top-k=5 nehmen. Funktioniert, wenn der Filter wenig selektiv ist. Riskant: bei stark selektivem Filter können die Top-100 alle weggeworfen werden, und der Retriever liefert 0 Treffer trotz vorhandener passender Chunks.

Qdrant Payload Index: erstellt via REST oder Client-SDK pro Feld. Keyword-Index für String-Felder (mandant_id, dokumenten_typ). Integer/Float-Range-Index für Zahlen (year, page_number). Datetime-Index für ISO-8601-Daten. Full-Text-Index für Volltext-Felder (title, summary). Indexierung kostet Memory: ca. 30 bis 60 Bytes pro Eintrag pro indexiertem Feld. Bei 1M Chunks und 5 indexierten Feldern: 150 bis 300 MB Memory.

pgvector mit WHERE: in Postgres läuft Vektor-Suche als ORDER BY embedding <-> query_vector LIMIT k, mit einem standard WHERE-Filter davor. B-Tree-Indices auf gefilterten Feldern beschleunigen die Pre-Filter-Phase. HNSW-Index auf der Vektor-Spalte beschleunigt die Nähe-Suche. Mit pgvector 0.7+ unterstützt Postgres iterative Index-Scans, die Filter-Selektivität automatisch erkennen.

Time-aware Retrieval: zwei Patterns. (a) harter Datums-Filter: nur Chunks im definierten Zeitraum kommen in Frage. (b) weiche Datums-Gewichtung: Chunks ausserhalb des Zeitraums werden im Score abgewertet, aber nicht ausgeschlossen. Pattern (b) ist robuster bei knappen Daten, Pattern (a) ist klarer bei rechtlichen Anwendungen.

Schema-Design Best-Practices: pro Chunk 5 bis 10 Pflicht-Felder, nicht mehr. Mandant-ID immer indexiert. Erstelldatum als ISO-8601 immer indexiert. Vertraulichkeits-Tier als Enum (public/internal/client/restricted) immer indexiert. Sprache als ISO-639-Code immer indexiert. Quellsystem als String indexiert. Tags als Array, falls relevant. Custom-Felder optional, nicht indexiert. Änderungen am Schema brauchen Re-Indexing.

Mandanten-Löschanspruch: bei revDSG-Löschanspruch können alle Chunks mit mandant_id=X in einer Query entfernt werden. Voraussetzung: mandant_id ist payload-indexiert, sonst wird das Löschen ein Vollscan.

Metadaten-Workflow in 6 Schritten

1. 01Pflicht-Felder definieren: client_id, document_type, confidentiality_tier, language, created_at, source_system. Schema versionieren.
2. 02Indexierung planen: alle Pflicht-Felder payload-indexiert, optionale Felder nur wenn nachweisbar selektiv.
3. 03Ingestion-Pipeline: Metadaten beim Chunking aus Quell-Datei extrahieren (Datei-System, Header, Mail-Header, etc.) oder via LLM-Klassifizierung anreichern.
4. 04Pre-Filter standardmässig: jede RAG-Anfrage trägt mindestens client_id und role_based confidentiality_tier in der Filter-Klausel.
5. 05Time-aware: zeit-sensitive Felder mit hartem Datums-Filter (juristisch) oder weicher Gewichtung (Recherche) versehen.
6. 06Audit-Pfad: pro Chunk und pro Anfrage geloggte Filter-Klausel und Treffer-Liste. Bei revDSG-Löschanspruch alle Chunks mit client_id=X entfernt.

Wann es einsetzen

Pre-Filter mit Pflicht-Feldern (Mandant, Vertraulichkeit, Sprache): immer. Es gibt keinen sinnvollen produktiven RAG-Aufbau ohne diese Filter.

Datums-Filter: bei zeit-sensitiven Korpora (Gesetzes-Texte, Markt-Daten, Mandanten-Korrespondenz). Bei statischen Korpora (Lexika, fertige Wegleitungs-Sammlungen) optional.

Tags-Filter: bei thematisch gruppierten Korpora (Vertrags-Typen, Industrie-Segmente). Kostet wenig Schema-Komplexität, bringt deutliche Verbesserung der Trefferqualität.

Full-Text-Index auf Title/Summary: bei vorhandener guter Metadaten-Qualität, wenn Nutzer häufig nach Dokumenten-Titeln oder Summary-Begriffen suchen.

Post-Filter: nur wenn der Filter wenig selektiv ist (z.B. Sprache=Deutsch in einem überwiegend deutschen Korpus). Bei selektiven Filtern immer Pre-Filter.

Im Treuhand-/Anwalts-Kontext empfehlen wir mindestens folgende indexierte Felder: client_id, document_type, confidentiality_tier, language, created_at, source_system, role_required.

Wann zurückhaltend

Sehr kleine Korpora unter 1000 Chunks: Filter-Index ist Overkill. Voller Scan ist schneller als Index-Overhead.

Korpora ohne strukturierte Metadaten-Quellen: wenn nur Klartext-Dokumente vorliegen, muss Metadaten erst extrahiert werden (LLM-basiert oder Heuristik). Bei kleinen Mengen lohnt der Aufwand nicht.

Felder mit sehr hoher Kardinalität und kaum Filter-Verwendung: nicht indexieren. Kostet Memory ohne Nutzen.

Felder mit sehr niedriger Selektivität (z.B. language=Deutsch in 99 Prozent der Chunks): Index hilft nicht, weil das Pre-Filter den Index kaum reduziert.

Vorsicht bei Schema-Veränderungen: jede neue indexierte Spalte erfordert Re-Indexing. Bei grossen Korpora kann das Stunden bis Tage dauern. Schema-Entscheidungen also früh und stabil treffen.

Vorsicht bei Filter-Logik in der Anfrage selbst: das Antwort-LLM zur Generierung von Filter-Klauseln aus der Nutzer-Anfrage einzusetzen kann nützlich sein, ist aber Halluzinations-anfällig. Lieber strukturierte UI-Filter (Mandant, Datum, Typ als Dropdown) anbieten.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Qdrant - Payload and indexing documentation · 2026-05
2. pgvector - iterative index scans and HNSW filtering (0.7+) · 2026-05
3. Pinecone - metadata filtering and best practices · 2026-05
4. Weaviate - filter operators and where filters · 2026-05