RAG-metadata-filtrering for AI-chatbots: Adskil sprog, version og adgang

En AI-chatbot kan finde tekststykker, der er semantisk meget lig hinanden, og alligevel forberede det forkerte svar: den engelske vejledning i stedet for den danske, dokumentationen for den forrige version i stedet for den aktuelle eller interne noter til en gæst uden rettigheder. Rangeringen er ikke nødvendigvis dårlig. Søgeområdet var blot forkert.

RAG-metadata-filtre løser præcis dette problem. De begrænser før eller under søgningen, hvilke dokumenter og chunks der overhovedet kan komme i betragtning som kontekst. Relevans besvarer derefter spørgsmålet "Hvad passer bedst indholdsmæssigt?". Filteret besvarer først "Hvad må og skal der tages højde for i denne situation?".

Hvorfor lighed alene ikke er et pålideligt scope

Vektor- og hybridsøgning sorterer indhold efter sproglig eller semantisk nærhed. En manual til produktversion 4 kan ligne et spørgsmål om version 5 rigtig meget. En prisliste for et andet marked kan indeholde de samme produktnavne. Og et internt supportdokument kan give et mere præcist svar end den offentlige FAQ, selvom det aldrig burde dukke op i en offentlig chat.

Derfor bør retrieveren holde to typer betingelser adskilt:

• Hårde grænser som tenant, rolle, udgivelsesstatus eller tilladt dataområde. Ved en ukendt værdi skal søgningen forblive lukket.
• Faglige udvælgelseskriterier som sprog, produktfamilie, version, region eller gyldighedsperiode. De øger præcisionen og forhindrer modstridende kontekst.

Den aktuelle OWASP-oversigt for LLM-applikationer placerer udtrykkeligt vektor- og embedding-risici ved tillidsgrænsen for en AI-applikation. Det er et vigtigt perspektiv: Et auth-tjek før chatten er ikke nok, hvis den efterfølgende likhedssøgning alligevel kører over et for bredt indeks.

Et metadataskema, der holder i hverdagen

Gode filtre starter ikke med en lang query, men med få kanoniske felter. For mange webside-chatbots er seks grupper nok:

• Sprog og marked: f.eks. locale og market, med fastdefinerede værdier i stedet for fri tekst.
• Produkt og version: stabil produkt-ID, versionsområde og valgfrit platform eller abonnement.
• Gyldighed: godkendelsesstatus, gyldig fra, gyldig til og en entydig kildeversion.
• Målgruppe: offentlig, kunde, partner eller internt team – adskilt fra den faktiske rollekontrol.
• Adgangsområde: tenant, gruppe eller principal, udelukkende fra verificeret serverkontekst.
• Oprindelse: kilde-ID, URL, dokumenttype og ansvarligt indholdsområde for sporebarhed.

Metadata hører til på det niveau, hvor der søges. Hvis et dokument opdeles i chunks, skal de afgørende scope-felter lande pålideligt på hver enkelt chunk. Ellers kan et dokument være korrekt klassificeret, mens enkelte søgeresultater mister denne placering. OpenAI-dokumentationen om File Search viser for eksempel, hvordan filattributter bruges til metadata-filtre. Amazon Bedrock-referencen dokumenterer sammenlignings-, liste- og områdeoperatorer for den samme grundlæggende idé.

Lad aldrig sprogmodellen autorisere filtre

En model må gerne udlede ledetråde som sprog eller produktreference ud fra spørgsmålet. Den må dog ikke afgøre, hvilken tenant en person tilhører, eller hvilken rolle personen har. Disse værdier skal komme fra sessionen, identitetssystemet og forretningsregler på serversiden. En filterstreng genereret af modellen bør heller ikke sendes ubehandlet videre til søgetjenesten.

Et robust flow ser således ud:

1. Serveren autentificerer forespørgslen og fastslår det tilladte dataområde.
2. Deterministiske regler sætter hårde felter som tenant, rolle og udgivelsesstatus.
3. Genkendte kendetegn som sprog eller produkt valideres mod tilladte værdier.
4. Retrieveren udfører kun en typificeret, parametriseret filterstruktur.
5. Applikationen tjekker de returnerede kilder en ekstra gang for det forventede scope.
6. Ved manglende eller modstridende kontekst spørger chatbotten ind eller returnerer et sikkert fallback.

Microsoft-dokumentationen om Security Filters laver en nyttig adskillelse: En principal i filteret er i første omgang blot en værdi. Autentificering og autorisering skal finde sted pålideligt uden for søgeudtrykket. For kundeportaler uddyber vores artikel om adskillelse af offentlig og autentificeret AI-chatbot denne grænse.

Pre-filter eller post-filter?

Filterets placering påvirker kvalitet og svartid. Et pre-filter begrænser kandidaterne allerede under vektorsøgningen. Et post-filter søger først bredere og fjerner efterfølgende utilladte resultater. Ifølge Azure-dokumentationen om vektorfiltre kan post-filtering ved selektive filtre og lille k overse relevante resultater; pre-filtering fremmer recall i den tilladte delmængde, men kan ved meget snævre filtre kræve mere beregningskraft.

For hårde adgangsgrænser er "søg bredt først, skjul bagefter" ikke et egnet grundmønster. Autoriseret scope bør gennemtvinges inde i selve søgeforespørgslen. For rent faglige filtre kan et team måle pre- og post-varianter. Her er det ikke kun den gennemsnitlige svartid, der tæller, men også hvor ofte et eksisterende, tilladt resultat mangler på grund af den valgte rækkefølge.

Filtre erstatter ikke rangeringen. Inden for det tilladte korpus kan Hybrid Search og Reranking fortsat prioritere de bedste kilder. Rækkefølgen lyder altså: Fastlæg scope, hent kandidater, vurder relevans, kontroller kilder, generer svar.

Fire typiske filtercases

Sprog med bevidst fallback

For et dansk spørgsmål bør det første udtræk vælge dansk, godkendt indhold. Hvis der ikke er noget resultat, må applikationen ikke stiltiende blande flere sprog. En eksplicit anden sti kan falde tilbage på et godkendt basissprog og gøre opmærksom på dette i svaret. En Locale-QA for flersprogede vidensbaser tjekker desuden, om varianterne indholdsmæssigt reelt er ligeværdige.

Produktversion og tidsmæssig gyldighed

En kilde bør ikke virke aktuel blot fordi den sidst blev crawlet. Det afgørende er faglig version og godkendelse. Mærk indhold med stabil produkt-ID, versionsområde, valid_from, valid_until og status. Ved overlappende frigivelser skal pipelinen rapportere en konflikt i stedet for at lægge begge tekster i den samme prompt. Hvordan crawl-kadence og kildepleje spiller sammen, beskrives i guiden om at holde AI-chatbot-vidensbasen opdateret.

Tenant og rolle

Ved et fælles indeks skal enhver forespørgsel indeholde den tenant og de gyldige principals, der er fastslået på serversiden. Manglende ACL-metadata betyder "ikke tilgængelig", ikke "offentlig". Efter et rolleskift eller tilbagekaldelse af en rettighed skal en test vise, at gamle sessioner ikke længere modtager tidligere tilladte chunks.

Offentlig support og intern arbejdsinstruks

En intern eskaleringsinstruks kan fagligt passe perfekt til et kundespørgsmål. Det gør den ikke til en tilladt kilde. Adskil publiceringsscope og dokumenttype; mærk som standard ikke-godkendt indhold som ekskluderet. En offentlig bot bør i tvivlstilfælde skifte til en kontakt- eller handoff-sti i stedet for at gætte interne detaljer.

De hyppigste implementeringsfejl

• Fritekst-taksonomi: Værdier som da, DA og da-DK danner utilsigtet tre grupper.
• Default-open: Chunks uden rolle, status eller tenant ender i ethvert søgeområde.
• Forkert boolsk logik: Et OR mellem tenant og sprog ophæver i praksis den hårde grænse.
• Dokument-chunk-drift: Ved genindeksering overføres nye metadata ikke til alle chunks.
• Kun positive tests: Teamet tjekker, om et tilladt dokument dukker op, men ikke om et forbudt dokument, der lyder næsten ens, med sikkerhed mangler.
• Tomme resultater som modelproblem: Et snævert filter leverer intet, og applikationen lader modellen svare videre uden kilder.

Filter-QA: Test ikke kun resultater, men også grænser

Et brugbart testsæt indeholder for hvert forventet svar mindst én tæt modkandidat: forkert sprog, gammel version, udløbet godkendelse, anden tenant eller intern målgruppe. På den måde viser testen, om filteret virkelig adskiller og ikke kun tilfældigt placerer det rigtige resultat øverst.

Vigtige nøgletal er scope-overtrædelsesrate, recall i den tilladte delmængde, andel af tomme retrievals, antal ukendte metadataværdier, filterlatenstid ved det 95. percentil samt andelen af fallbacks og afklarende spørgsmål. For begrænset indhold skal den tolererede scope-overtrædelsesrate være nul. NIST AI RMF Core anbefaler at teste AI-systemer før ibrugtagning og regelmæssigt i drift samt at dokumentere sikkerheds-, pålideligheds- og kontekstgrænser.

Undlad at logge unødvendigt indhold eller komplette megerspørgsmål til dette formål. Som regel er det nok med filterversion, abstrakt scope, antal kandidater, valgte kilde-ID'er, afvisningsårsag og resultat af post-tjekket. På den måde er fejlsøgning stadig mulig uden at opbygge et nyt datalæk i observability-systemet.

Praktisk tjekliste før udrulning

1. Dokumenter kanoniske metadatafelter, datatyper, tilladte værdier og ejere.
2. Adskil hårde adgangsgrænser fra faglige udvælgelsesfelter.
3. Behandl konsekvent manglende sikkerhedsrelevante værdier som ikke-tilladte.
4. Opbyg filtre fra verificeret serverkontekst og parametriser input.
5. Foretag stikprøvekontrol af metadata efter ingestion og chunking.
6. Test positive, negative, grænse- og tilbagekaldelsessager mod det ægte indeks.
7. Mål pre-/post-filter-adfærd med realistisk k og selektive scopes.
8. Før tomme resultater til et afklarende spørgsmål, et sikkert fallback eller overdragelse til et menneske (human handoff).
9. Versionsstyr filterændringer og rul dem ud sammen med retrieval-regressionstests.

RAG-metadata-filtre er dermed mere end blot en komfortfunktion i søgningen. De er bindeleddet mellem indholdsmodel, identitet, aktualitet og retrieval-kvalitet. Den, der først fastlægger scopet deterministisk, giver rangeringen og sprogmodellen et mindre, renere og mere verificerbart arbejdsgrundlag.

Næste skridt: Vælg et reelt supportspørgsmål og opbyg fem næsten matchende modkilder ud fra forkert sprog, version og rettighed. Først når ingen af dem overskrider det tilladte retrieval-scope, bør filteret gå i det produktive chatflow.

Kilder

• OpenAI: File Search og Metadata Filtering
• Microsoft: Filtre i vektorforespørgsler
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026