RAG-metadatafilters voor AI-chatbots: taal, versie en toegang scheiden

Een AI-chatbot kan semantisch zeer vergelijkbare tekstfragmenten vinden en toch het verkeerde antwoord voorbereiden: de Engelse handleiding in plaats van de Nederlandse, de documentatie van de vorige versie in plaats van de huidige, of interne instructies voor een gast zonder toegangsrechten. De ranking is dan niet per se slecht. De zoekruimte was verkeerd.

RAG-metadatafilters lossen precies dit probleem op. Ze beperken voor of tijdens het zoeken welke documenten en chunks überhaupt als context in aanmerking komen. Relevantie beantwoordt daarna de vraag "Wat past inhoudelijk het beste?". Het filter beantwoordt eerst "Wat mag en moet in deze situatie worden meegenomen?".

Waarom overeenkomst alleen geen betrouwbare scope is

Vector- en hybride zoekopdrachten ordenen inhoud op basis van taalkundige of semantische nabijheid. Een handboek voor productversie 4 kan bijzonder veel lijken op een vraag over versie 5. Een prijslijst voor een andere markt kan dezelfde productnamen bevatten. En een intern supportdocument kan een nauwkeuriger antwoord bieden dan de openbare FAQ, hoewel het nooit in een openbare chat mag verschijnen.

Daarom moet de retriever twee soorten voorwaarden uit elkaar houden:

• Harde grenzen zoals tenant, rol, publicatiestatus of toegestaan databereik. Bij een onbekende waarde moet de zoekopdracht gesloten blijven.
• Functionele selectiecriteria zoals taal, productfamilie, versie, regio of geldigheidsperiode. Ze verhogen de precisie en voorkomen tegenstrijdige context.

Het actuele OWASP-overzicht voor LLM-toepassingen deelt vector- en embeddingrisico's uitdrukkelijk in bij de vertrouwensgrens van een AI-toepassing. Dat is een belangrijk perspectief: een auth-check vóór de chat is niet voldoende als de aansluitende gelijkeniszoekopdracht alsnog over een te brede index loopt.

Een metadataschema dat in de praktijk standhoudt

Goede filters beginnen niet met een lange query, maar met een paar canonieke velden. Voor veel website-chatbots zijn zes groepen voldoende:

• Taal en markt: bijvoorbeeld locale en market, met vastgedefinieerde waarden in plaats van vrije tekst.
• Product en versie: stabiele product-ID, versiebereik en optioneel platform of tarief.
• Geldigheid: vrijgavestatus, geldig vanaf, geldig tot en een unieke bronversie.
• Doelgroep: openbaar, klant, partner of intern team – gescheiden van de daadwerkelijke rolcontrole.
• Toegangsbereik: tenant, groep of principal, uitsluitend uit een geverifieerde servercontext.
• Herkomst: bron-ID, URL, documenttype en verantwoordelijk contentbereik voor traceerbaarheid.

Metadata horen thuis op het niveau waarop gezocht wordt. Als een document in chunks wordt opgedeeld, moeten de cruciale scopevelden betrouwbaar op elke chunk terechtkomen. Anders kan een document correct geclassificeerd zijn, terwijl individuele zoekresultaten die indeling verliezen. De OpenAI-documentatie over File Search laat bijvoorbeeld zien hoe bestandseigenschappen worden gebruikt voor metadatafiltering. De Amazon Bedrock-referentie documenteert vergelijkings-, lijst- en bereikoperatoren voor hetzelfde grondbeginsel.

Laat filters nooit autoriseren door het taalmodel

Een model mag uit de vraag aanwijzingen zoals taal of productbetrekking afleiden. Het mag echter niet beslissen tot welke tenant een persoon behoort of welke rol deze heeft. Deze waarden moeten afkomstig zijn uit de sessie, het identiteitssysteem en server-side bedrijfsregels. Ook een door het model gegenereerde filterstring mag niet ongecontroleerd worden doorgegeven aan de zoekdienst.

Een robuust proces ziet er zo uit:

1. De server authenticeert het verzoek en bepaalt het toegestane databereik.
2. Deterministische regels stellen harde velden in zoals tenant, rol en publicatiestatus.
3. Herkende kenmerken zoals taal of product worden gevalideerd tegen toegestane waarden.
4. De retriever voert alleen een getypeerde, geparametriseerde filterstructuur uit.
5. De toepassing controleert de geretourneerde bronnen nogmaals op de verwachte scope.
6. Bij ontbrekende of tegenstrijdige context vraagt de chatbot om verduidelijking of geeft een veilige fallback.

De Microsoft-documentatie over Security Filters maakt een nuttig onderscheid: een principal in het filter is in eerste instantie slechts een waarde. Authenticatie en autorisatie moeten betrouwbaar buiten de zoekexpressie plaatsvinden. Voor klantportalen gaat ons artikel over de scheiding van een openbare en een geauthenticeerde AI-chatbot dieper in op deze grens.

Pre-filter of post-filter?

De positie van het filter beïnvloedt de kwaliteit en de verwerkingstijd. Een pre-filter beperkt de kandidaten al tijdens de vectorzoekopdracht. Een post-filter zoekt eerst breder en verwijdert vervolgens niet-toegestane resultaten. Volgens de Azure-documentatie over vectorfilters kan post-filtering bij selectieve filters en een kleine k geschikte resultaten over het hoofd zien; pre-filtering geeft de voorkeur aan recall binnen het toegestane deelbestand, maar kan bij zeer strenge filters meer rekenkracht vergen.

Voor harde toegangsgrenzen is "eerst breed zoeken, daarna verbergen" geen geschikt basispatroon. Een geautoriseerde scope moet binnen de zoekopdracht worden afgedwongen. Voor puur functionele filters kan een team pre- en post-varianten testen. Daarbij telt niet alleen de gemiddelde responstijd, maar ook hoe vaak een aanwezig, toegestaan resultaat ontbreekt door de gekozen volgorde.

Filters vervangen de ranking niet. Binnen het toegestane corpus kunnen Hybrid Search en Reranking nog steeds de beste bronnen prioriteren. De volgorde is dus: scope bepalen, kandidaten ophalen, relevantie beoordelen, bronnen controleren, antwoord genereren.

Vier typische filtergevallen

Taal met een bewuste fallback

Voor een Nederlandse vraag moet de eerste retrieval-actie Nederlandse, goedgekeurde inhoud selecteren. Is er geen resultaat, dan mag de toepassing niet stilzwijgend meerdere talen mengen. Een expliciet tweede pad kan terugvallen op een goedgekeurde basistaal en deze situatie in het antwoord vermelden. Een Locale-QA voor meertalige kennisbanken controleert bovendien of de varianten inhoudelijk echt gelijkwaardig zijn.

Productversie en tijdelijke geldigheid

Een bron moet niet alleen actueel lijken omdat deze recent is gecrawld. Bepalend zijn de functionele versie en de vrijgave. Markeer inhoud met een stabiele product-ID, versiebereik, valid_from, valid_until en status. Bij overlappende vrijgaves moet de pipeline een conflict melden, in plaats van beide teksten in dezelfde prompt te plaatsen. Hoe crawl-frequentie en brononderhoud samenwerken, wordt beschreven in de gids over de actualiteit van de AI-chatbotkennisbank.

Tenant en rol

Bij een gedeelde index moet elke zoekopdracht de server-side vastgestelde tenant en de geldige principals bevatten. Ontbrekende ACL-metadata betekenen "niet opvraagbaar", niet "openbaar". Na een rolwijziging of het intrekken van een machtiging moet een test aantonen dat oude sessies geen eerder toegestane chunks meer ontvangen.

Openbare support en interne werkinstructies

Een interne escalatie-instructie kan inhoudelijk perfect passen bij een klantvraag. Dat maakt het nog geen toegestane bron. Scheid de publicatiescope en het documenttype; markeer niet-vrijgegeven inhoud standaard als uitgesloten. Een openbare bot moet bij twijfel overschakelen naar een contact- of handoff-pad, in plaats van te gissen naar interne details.

De meest voorkomende implementatiefouten

• Vrije-teksttaxonomie: waarden zoals nl, NL en nl-NL vormen ongewild drie aparte groepen.
• Default-open: chunks zonder rol, status of tenant belanden in elke zoekruimte.
• Verkeerde Booleaanse logica: een OR tussen tenant en taal heft de harde grens in de praktijk op.
• Document-chunk-drift: bij het herindexeren worden nieuwe metadata niet naar alle chunks overgedragen.
• Alleen positieve testen: het team controleert of een toegestaan document verschijnt, maar niet of een vergelijkbaar klinkend, verboden document daadwerkelijk ontbreekt.
• Lege zoekresultaten als modelprobleem zien: een strikt filter levert niets op en de toepassing laat het model zonder bronnen verder antwoorden.

Filter-QA: niet alleen resultaten, maar ook grenzen testen

Een bruikbare testset bevat voor elk verwachte antwoord minstens één nabije tegenkandidaat: verkeerde taal, oude versie, verlopen vrijgave, andere tenant of interne doelgroep. Zo toont de test aan of het filter echt scheidt en niet alleen toevallig het juiste resultaat bovenaan plaatst.

Belangrijke metrieken zijn het percentage scopeschendingen, de recall binnen het toegestane deelbestand, het aandeel lege retrievals, het aantal onbekende metadatawaarden, de filterlatentie op het 95e percentiel en het aandeel fallbacks en verduidelijkingsvragen. Voor afgeschermde inhoud moet de getolereerde scope-schendingsrate nul zijn. Het NIST AI RMF Core raadt aan om AI-systemen vóór gebruik en regelmatig tijdens het bedrijf te testen en veiligheids-, betrouwbaarheids- en contextgrenzen te documenteren.

Logleer hiervoor geen onnodige inhoud of volledige gebruikersvragen. Meestal zijn de filterversie, abstracte scope, het aantal kandidaten, de geselecteerde bron-ID's, de reden van afwijzing en het resultaat van de post-check voldoende. Zo blijft foutopsporing mogelijk zonder een tweede datalek in het observabilitiesysteem te creëren.

Praktische checklist voor de rollout

1. Documenteer canonieke metadatavelden, datatypen, toegestane waarden en eigenaren.
2. Scheid harde toegangsgrenzen van functionele selectievelden.
3. Behandel ontbrekende beveiligingsrelevante waarden consequent als niet toegestaan.
4. Bouw filters op vanuit een geverifieerde servercontext en parametriseer invoer.
5. Lees metadata na ingestie en chunking steekproefsgewijs terug.
6. Test positieve, negatieve, grens- en intrekkingsgevallen tegen de echte index.
7. Meet het gedrag van pre-/post-filters met een realistische k en selectieve scopes.
8. Stuur lege resultaten naar een verduidelijkingsvraag, veilige fallback of human handoff.
9. Achterhaal versiebeheer voor filterwijzigingen en rol deze uit samen met retrieval-regressietests.

RAG-metadatafilters zijn daarmee meer dan een gemakskenmerk van de zoekfunctie. Ze vormen de verbinding tussen het contentmodel, identiteit, actualiteit en retrieval-kwaliteit. Wie de scope eerst deterministisch vastlegt, geeft de ranking en het taalmodel een kleinere, schonere en controleerbare werkbasis.

Volgende stap: Kies een echte supportvraag en bouw daarvoor vijf bijna passende tegenbronnen uit de verkeerde taal, versie en machtiging. Pas wanneer geen van deze bronnen de toegestane retrieval-scope overschrijdt, moet het filter naar de productieve chatflow.

Bronnen

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