RAG-Metadatenfilter für KI-Chatbots: Sprache, Version und Zugriff trennen

Ein KI-Chatbot kann semantisch sehr ähnliche Textstellen finden und trotzdem die falsche Antwort vorbereiten: die englische Anleitung statt der deutschen, die Dokumentation der Vorgängerversion statt der aktuellen oder interne Hinweise für einen Gast ohne Berechtigung. Das Ranking ist dann nicht zwingend schlecht. Der Suchraum war falsch.

RAG-Metadatenfilter lösen genau dieses Problem. Sie begrenzen vor oder während der Suche, welche Dokumente und Chunks überhaupt als Kontext infrage kommen. Relevanz beantwortet danach die Frage „Was passt inhaltlich am besten?“. Der Filter beantwortet zuerst „Was darf und soll in dieser Situation berücksichtigt werden?“.

Warum Ähnlichkeit allein kein verlässlicher Scope ist

Vektor- und Hybridsuche ordnen Inhalte nach sprachlicher oder semantischer Nähe. Ein Handbuch für Produktversion 4 kann einer Frage zu Version 5 besonders ähnlich sein. Eine Preisliste für einen anderen Markt kann dieselben Produktnamen enthalten. Und ein internes Support-Dokument kann eine präzisere Antwort liefern als die öffentliche FAQ, obwohl es im öffentlichen Chat niemals erscheinen dürfte.

Deshalb sollte der Retriever zwei Arten von Bedingungen auseinanderhalten:

• Harte Grenzen wie Mandant, Rolle, Veröffentlichungsstatus oder zulässiger Datenbereich. Bei einem unbekannten Wert muss die Suche geschlossen bleiben.
• Fachliche Auswahlkriterien wie Sprache, Produktfamilie, Version, Region oder Gültigkeitszeitraum. Sie erhöhen Präzision und verhindern widersprüchlichen Kontext.

Die aktuelle OWASP-Übersicht für LLM-Anwendungen ordnet Vektor- und Embedding-Risiken ausdrücklich der Vertrauensgrenze einer KI-Anwendung zu. Das ist eine wichtige Perspektive: Ein Auth-Check vor dem Chat reicht nicht, wenn die nachfolgende Ähnlichkeitssuche trotzdem über einen zu breiten Index läuft.

Ein Metadatenschema, das im Alltag trägt

Gute Filter beginnen nicht mit einer langen Query, sondern mit wenigen kanonischen Feldern. Für viele Website-Chatbots reichen sechs Gruppen:

• Sprache und Markt: etwa locale und market, mit fest definierten Werten statt freiem Text.
• Produkt und Version: stabile Produkt-ID, Versionsbereich und optional Plattform oder Tarif.
• Gültigkeit: Freigabestatus, gültig ab, gültig bis und eine eindeutige Quellversion.
• Zielgruppe: öffentlich, Kunde, Partner oder internes Team – getrennt von der eigentlichen Rollenprüfung.
• Zugriffsbereich: Mandant, Gruppe oder Principal, ausschließlich aus verifiziertem Serverkontext.
• Herkunft: Quell-ID, URL, Dokumenttyp und verantwortlicher Content-Bereich für Nachvollziehbarkeit.

Metadaten gehören an die Ebene, auf der gesucht wird. Wird ein Dokument in Chunks zerlegt, müssen die entscheidenden Scope-Felder zuverlässig an jedem Chunk landen. Sonst kann ein Dokument korrekt klassifiziert sein, während einzelne Suchtreffer diese Einordnung verlieren. Die OpenAI-Dokumentation zu File Search zeigt beispielsweise, wie Dateiattribute für Metadatenfilter genutzt werden. Die Amazon-Bedrock-Referenz dokumentiert Vergleichs-, Listen- und Bereichsoperatoren für dieselbe Grundidee.

Filter nie vom Sprachmodell autorisieren lassen

Ein Modell darf aus der Frage Hinweise wie Sprache oder Produktbezug ableiten. Es darf jedoch nicht entscheiden, welchem Mandanten eine Person angehört oder welche Rolle sie besitzt. Diese Werte müssen aus Session, Identitätssystem und serverseitigen Geschäftsregeln kommen. Auch eine vom Modell erzeugte Filterzeichenfolge sollte nicht ungeprüft an den Suchdienst weitergereicht werden.

Ein robuster Ablauf sieht so aus:

1. Der Server authentifiziert die Anfrage und ermittelt den zulässigen Datenbereich.
2. Deterministische Regeln setzen harte Felder wie Mandant, Rolle und Veröffentlichungsstatus.
3. Erkannte Merkmale wie Sprache oder Produkt werden gegen erlaubte Werte validiert.
4. Der Retriever führt nur eine typisierte, parametrisierte Filterstruktur aus.
5. Die Anwendung prüft die zurückgegebenen Quellen nochmals auf den erwarteten Scope.
6. Bei fehlendem oder widersprüchlichem Kontext fragt der Chatbot nach oder gibt einen sicheren Fallback aus.

Die Microsoft-Dokumentation zu Security Filters macht eine hilfreiche Unterscheidung: Ein Principal im Filter ist zunächst nur ein Wert. Authentifizierung und Autorisierung müssen außerhalb des Suchausdrucks verlässlich stattfinden. Für Kundenportale vertieft unser Beitrag zur Trennung von öffentlichem und authentifiziertem KI-Chatbot diese Grenze.

Pre-Filter oder Post-Filter?

Die Position des Filters beeinflusst Qualität und Laufzeit. Ein Pre-Filter begrenzt die Kandidaten bereits während der Vektorsuche. Ein Post-Filter sucht zunächst breiter und entfernt unzulässige Treffer anschließend. Laut Azure-Dokumentation zu Vektorfiltern kann Post-Filtering bei selektiven Filtern und kleinem k passende Ergebnisse übersehen; Pre-Filtering bevorzugt den Recall im erlaubten Teilbestand, kann bei sehr engen Filtern aber mehr Rechenaufwand verursachen.

Für harte Zugriffsgrenzen ist „erst breit suchen, danach verstecken“ kein geeignetes Grundmuster. Autorisierter Scope sollte innerhalb der Suchanfrage erzwungen werden. Für rein fachliche Filter kann ein Team Pre- und Post-Varianten messen. Dabei zählt nicht nur die mittlere Antwortzeit, sondern auch, wie oft ein vorhandener, erlaubter Treffer durch die gewählte Reihenfolge fehlt.

Filter ersetzen das Ranking nicht. Innerhalb des zulässigen Korpus können Hybrid Search und Reranking weiterhin die besten Quellen priorisieren. Die Reihenfolge lautet also: Scope festlegen, Kandidaten abrufen, Relevanz bewerten, Quellen prüfen, Antwort erzeugen.

Vier typische Filterfälle

Sprache mit bewusstem Fallback

Für eine deutsche Frage sollte der erste Abruf deutsche, freigegebene Inhalte wählen. Gibt es keinen Treffer, darf die Anwendung nicht stillschweigend mehrere Sprachen mischen. Ein expliziter zweiter Pfad kann auf eine freigegebene Basissprache zurückfallen und diesen Umstand in der Antwort kenntlich machen. Eine Locale-QA für mehrsprachige Wissensbasen prüft zusätzlich, ob die Varianten inhaltlich wirklich gleichwertig sind.

Produktversion und zeitliche Gültigkeit

Eine Quelle sollte nicht allein deshalb aktuell wirken, weil sie zuletzt gecrawlt wurde. Entscheidend sind fachliche Version und Freigabe. Markieren Sie Inhalte mit stabiler Produkt-ID, Versionsbereich, valid_from, valid_until und Status. Bei überlappenden Freigaben muss die Pipeline einen Konflikt melden, statt beide Texte in denselben Prompt zu legen. Wie Crawl-Kadenz und Quellenpflege zusammenspielen, beschreibt der Leitfaden zur Aktualität der KI-Chatbot-Wissensbasis.

Mandant und Rolle

Bei gemeinsamem Index muss jeder Abruf den serverseitig ermittelten Mandanten und die gültigen Principals enthalten. Fehlende ACL-Metadaten bedeuten „nicht abrufbar“, nicht „öffentlich“. Nach Rollenwechsel oder Entzug einer Berechtigung muss ein Test zeigen, dass alte Sessions keine früher erlaubten Chunks mehr erhalten.

Öffentlicher Support und interne Arbeitsanweisung

Eine interne Eskalationsanweisung kann fachlich perfekt zu einer Kundenfrage passen. Das macht sie nicht zu einer zulässigen Quelle. Trennen Sie Veröffentlichungsscope und Dokumenttyp; markieren Sie nicht freigegebene Inhalte standardmäßig als ausgeschlossen. Ein öffentlicher Bot sollte im Zweifel auf einen Kontakt- oder Handoff-Pfad wechseln, statt interne Details zu erraten.

Die häufigsten Implementierungsfehler

• Freitext-Taxonomie: Werte wie de, DE und de-DE bilden ungewollt drei Gruppen.
• Default-open: Chunks ohne Rolle, Status oder Mandant gelangen in jeden Suchraum.
• Falsche Boolesche Logik: Ein OR zwischen Mandant und Sprache hebt die harte Grenze praktisch auf.
• Dokument-Chunk-Drift: Beim Reindexieren werden neue Metadaten nicht an alle Chunks übertragen.
• Nur positive Tests: Das Team prüft, ob ein erlaubtes Dokument erscheint, aber nicht, ob ein ähnlich klingendes verbotenes Dokument sicher fehlt.
• Leere Treffer als Modellproblem: Ein enger Filter liefert nichts und die Anwendung lässt das Modell ohne Quellen weiterantworten.

Filter-QA: Nicht nur Treffer, sondern Grenzen testen

Ein brauchbares Testset enthält für jede erwartete Antwort mindestens einen nahen Gegenkandidaten: falsche Sprache, alte Version, abgelaufene Freigabe, anderer Mandant oder interne Zielgruppe. So zeigt der Test, ob der Filter wirklich trennt und nicht nur zufällig den richtigen Treffer oben platziert.

Wichtige Kennzahlen sind die Scope-Verletzungsrate, Recall im erlaubten Teilbestand, Anteil leerer Retrievals, Zahl unbekannter Metadatenwerte, Filterlatenz am 95. Perzentil sowie der Anteil von Fallbacks und Klärungsfragen. Für eingeschränkte Inhalte muss die tolerierte Scope-Verletzungsrate null sein. Das NIST AI RMF Core empfiehlt, KI-Systeme vor dem Einsatz und regelmäßig im Betrieb zu testen und Sicherheits-, Zuverlässigkeits- und Kontextgrenzen zu dokumentieren.

Protokollieren Sie dafür keine unnötigen Inhalte oder vollständigen Nutzerfragen. Meist reichen Filterversion, abstrakter Scope, Zahl der Kandidaten, ausgewählte Quell-IDs, Ablehnungsgrund und Ergebnis des Post-Checks. So bleibt eine Fehlersuche möglich, ohne ein zweites Datenleck im Observability-System aufzubauen.

Praktische Checkliste vor dem Rollout

1. Kanonische Metadatenfelder, Datentypen, erlaubte Werte und Besitzer dokumentieren.
2. Harte Zugriffsgrenzen von fachlichen Auswahlfeldern trennen.
3. Fehlende sicherheitsrelevante Werte konsequent als nicht zugelassen behandeln.
4. Filter aus verifiziertem Serverkontext aufbauen und Eingaben parametrisieren.
5. Metadaten nach Ingestion und Chunking stichprobenartig zurücklesen.
6. Positive, negative, Grenz- und Widerrufsfälle gegen den echten Index testen.
7. Pre-/Post-Filter-Verhalten mit realistischem k und selektiven Scopes messen.
8. Leere Ergebnisse in Klärungsfrage, sicheren Fallback oder Human Handoff führen.
9. Filteränderungen versionieren und gemeinsam mit Retrieval-Regressionstests ausrollen.

RAG-Metadatenfilter sind damit mehr als ein Komfortmerkmal der Suche. Sie sind die Verbindung zwischen Content-Modell, Identität, Aktualität und Retrieval-Qualität. Wer den Scope zuerst deterministisch festlegt, gibt Ranking und Sprachmodell eine kleinere, sauberere und überprüfbare Arbeitsgrundlage.

Nächster Schritt: Wählen Sie eine reale Supportfrage und bauen Sie dazu fünf fast passende Gegenquellen aus falscher Sprache, Version und Berechtigung. Erst wenn keine davon den erlaubten Retrieval-Scope überschreitet, sollte der Filter in den produktiven Chatfluss.

Quellen

• OpenAI: File Search und Metadata Filtering
• Microsoft: Filter in Vektorabfragen
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026