RAG-metadatafilter för AI-chatbottar: Separera språk, version och åtkomst

En AI-chatbot kan hitta textavsnitt som är semantiskt väldigt likartade och ändå förbereda fel svar: den engelska instruktionen i stället för den svenska, dokumentationen för den tidigare versionen i stället för den aktuella eller interna anvisningar för en gäst som saknar behörighet. Rankningen är då inte nödvändigtvis dålig. Sökrummet var felaktigt.

RAG-metadatafilter löser exakt detta problem. De begränsar före eller under sökningen vilka dokument och chunks som överhuvudtaget kan komma i fråga som kontext. Relevans besvarar därefter frågan "Vad passar innehållsmässigt bäst?". Filtret besvarar först "Vad får och bör beaktas i denna situation?".

Varför likhet ensamt inte är ett tillförlitligt scope

Vektor- och hybridsökning ordnar innehåll efter språklig eller semantisk närhet. En handbok för produktversion 4 kan vara väldigt lik en fråga om version 5. En prislista för en annan marknad kan innehålla samma produktnamn. Och ett internt supportdokument kan ge ett mer exakt svar än den öppna FAQ-sidan, trots att det aldrig får visas i den öppna chatten.

Därför bör retrievern hålla isär två typer av villkor:

• Hårda gränser såsom tenant, roll, publiceringsstatus eller tillåtet dataområde. Om ett värde är okänt måste sökningen förbli stängd.
• Domänspecifika urvalskriterier såsom språk, produktfamilj, version, region eller giltighetsperiod. De ökar precisionen och förhindrar motstridig kontext.

Den aktuella OWASP-översikten för LLM-applikationer placerar uttryckligen vektor- och inbäddningsrisker vid förtroendegränsen för en AI-applikation. Det är ett viktigt perspektiv: En autentiseringskontroll före chatten räcker inte om den efterföljande likhetssökningen ändå körs över ett för brett index.

Ett metadataschema som håller i vardagen

Bra filter börjar inte med en lång query, utan med ett fåtal kanoniska fält. För många webbplats-chatbottar räcker det med sex grupper:

• Språk och marknad: exempelvis locale och market, med fast definierade värden i stället för fritext.
• Produkt och version: stabil produkt-ID, versionsspann och valfri plattform eller taxa.
• Giltighet: godkännandestatus, giltig från, giltig till och en entydig källversion.
• Målgrupp: offentlig, kund, partner eller internt team – separerat från själva rollkontrollen.
• Åtkomstområde: tenant, grupp eller principal, uteslutande från verifierad serverkontext.
• Ursprung: käll-ID, URL, dokumenttyp och ansvarigt innehållsområde för spårbarhet.

Metadata hör hemma på den nivå där sökningen sker. Om ett dokument delas upp i chunks måste de avgörande scope-fälten tillförlitligt hamna på varje chunk. Annars kan ett dokument vara korrekt klassificerat, medan enskilda sökträffar tappar denna inordning. OpenAI-dokumentationen för File Search visar till exempel hur filattribut används för metadatafilter. Amazon Bedrock-referensen dokumenterar jämförelse-, list- och intervalloperatorer för samma grundidé.

Auktorisera aldrig filter genom språkmodellen

En modell får härleda ledtrådar som språk eller produktkoppling från frågan. Den får dock inte avgöra vilken tenant en person tillhör eller vilka roller personen har. Dessa värden måste komma från sessionen, identitetssystemet och affärsregler på serversidan. Inte heller en filtersträng som genererats av modellen bör skickas vidare okontrollerad till söktjänsten.

Ett robust flöde ser ut så här:

1. Servern autentiserar förfrågan och fastställer det tillåtna dataområdet.
2. Deterministiska regler sätter hårda fält som tenant, roll och publiceringsstatus.
3. Identifierade egenskaper som språk eller produkt valideras mot tillåtna värden.
4. Retrievern kör endast en typad, parametriserad filterstruktur.
5. Applikationen kontrollerar de returnerade källorna en gång till mot förväntat scope.
6. Vid saknad eller motstridig kontext ställer chatboten en följdfråga eller ger en säker fallback.

Microsoft-dokumentationen om Security Filters gör en hjälpsam uppdelning: En principal i filtret är till att börja med bara ett värde. Autentisering och auktorisering måste ske tillförlitligt utanför sökuttrycket. För kundportaler fördjupar vår artikel om separering av offentlig och autentiserad AI-chatbot denna gräns.

Pre-filter eller post-filter?

Filtrets placering påverkar kvalitet och körtid. Ett pre-filter begränsar kandidaterna redan under vektorsökningen. Ett post-filter söker först bredare och tar därefter bort otillåtna träffar. Enligt Azure-dokumentationen om vektorfilter kan post-filtering vid selektiva filter och ett litet k missa passande resultat; pre-filtering prioriterar recall i det tillåtna delbeståndet, men kan vid väldigt snäva filter kräva mer beräkningsresurser.

För hårda åtkomstgränser är "sök brett först, göm sedan" inget lämpligt grundmönster. Auktoriserat scope bör framtvingas inom sökfrågan. För rent domänspecifika filter kan ett team mäta pre- och post-varianter. Då räknas inte bara genomsnittlig svarstid, utan även hur ofta en befintlig, tillåten träff saknas på grund av den valda ordningen.

Filter ersätter inte rankning. Inom den tillåtna korpusen kan Hybrid Search och reranking fortsätta att prioritera de bästa källorna. Ordningen är alltså: Fastställ scope, hämta kandidater, utvärdera relevans, kontrollera källor, generera svar.

Fyra typiska filterfall

Språk med medveten fallback

För en svensk fråga bör den första hämtningen välja svenskt, godkänt innehåll. Om det inte finns någon träff får applikationen inte tyst blanda flera språk. En explicit sekundär väg kan falla tillbaka på ett godkänt basspråk och tydliggöra detta i svaret. En locale-QA för flerspråkiga kunskapsbaser kontrollerar dessutom om varianterna innehållsmässigt verkligen är likvärdiga.

Produktversion och tidsmässig giltighet

En källa bör inte verka aktuell enbart för att den senast indexerades nyligen. Avgörande är domänspecifik version och godkännande. Märk innehåll med stabil produkt-ID, versionsspann, valid_from, valid_until och status. Vid överlappande godkännanden måste pipelinen rapportera en konflikt i stället för att lägga båda texterna i samma prompt. Hur crawl-frekvens och källvård samverkar beskrivs i guiden om aktuell hållning av AI-chatbotens kunskapsbas.

Tenant och roll

Vid ett gemensamt index måste varje hämtning innehålla den tenant och de giltiga principals som fastställts på serversidan. Saknade ACL-metadata betyder "ej hämtningsbar", inte "offentlig". Efter ett rollbyte eller återkallande av en behörighet måste ett test visa att gamla sessioner inte längre får några tidigare tillåtna chunks.

Offentlig support och interna arbetsinstruktioner

En intern eskaleringsinstruktion kan sakmässigt passa perfekt för en kundfråga. Det gör den inte till en tillåten källa. Separera publiceringsscope och dokumenttyp; märk icke-godkänt innehåll som exkluderat som standard. En offentlig bot bör vid tveksamheter växla till en kontakt- eller handoff-väg i stället för att gissa interna detaljer.

De vanligaste implementeringsfelen

• Fritexttaxonomi: Värden som de, DE och de-DE bildar oavsiktligt tre grupper.
• Default-open: Chunks utan roll, status eller tenant hamnar i alla sökrum.
• Felaktig boolesk logik: Ett OR mellan tenant och språk upphäver i praktiken den hårda gränsen.
• Dokument-chunk-drift: Vid omindexering överförs inte nya metadata till alla chunks.
• Enbart positiva tester: Teamet kontrollerar om ett tillåtet dokument visas, men inte om ett liknande förbjudet dokument säkert saknas.
• Tomma träffar behandlas som ett modellproblem: Ett snävt filter ger inga resultat och applikationen låter modellen fortsätta svara utan källor.

Filter-QA: Testa inte bara träffar utan även gränser

Ett användbart testset innehåller för varje förväntat svar minst en nära motkandidat: fel språk, gammal version, utgånget godkännande, annan tenant eller intern målgrupp. På så sätt visar testet om filtret verkligen separerar och inte bara av en slump placerar rätt träff överst.

Viktiga nyckeltal är frekvensen av scope-överträdelser, recall i det tillåtna delbeståndet, andel tomma retrievals, antal okända metadatavärden, filterlatens vid 95:e percentilen samt andelen fallbacks och klargörande frågor. För begränsat innehåll måste den tolererade frekvensen av scope-överträdelser vara noll. NIST AI RMF Core rekommenderar att man testar AI-system före driftsättning och regelbundet i drift samt dokumenterar säkerhets-, tillförlitlighets- och kontextgränser.

Logga för detta inte onödigt innehåll eller fullständiga användarfrågor. Oftast räcker det med filterversion, abstrakt scope, antal kandidater, valda käll-ID:n, avvisningsorsak och resultat av post-kontrollen. Därmed är felsökning fortfarande möjlig utan att bygga en andra dataläcka i observability-systemet.

Praktisk checklista före lansering

1. Dokumentera kanoniska metadatafält, datatyper, tillåtna värden och ägare.
2. Separera hårda åtkomstgränser från domänspecifika urvalsfält.
3. Behandla konsekvent saknade säkerhetsrelevanta värden som ej tillåtna.
4. Bygg filter från verifierad serverkontext och parametrisera indata.
5. Läs stickprovsartat tillbaka metadata efter ingestion och chunking.
6. Testa positiva, negativa, gräns- och återkallningsfall mot det verkliga indexet.
7. Mät pre-/post-filterbeteende med realistiskt k och selektiva scopes.
8. Leda tomma resultat till klargörande fråga, säker fallback eller human handoff.
9. Versionshantera filterändringar och rulla ut dem tillsammans med retrieval-regressionstester.

RAG-metadatafilter är därmed mer än en bekvämlighetsfunktion för sökningen. De utgör länken mellan innehållsmodell, identitet, aktualitet och retrieval-kvalitet. Den som först fastställer scope deterministiskt ger rankningen och språkmodellen ett mindre, renare och verifierbart arbetsunderlag.

Nästa steg: Välj en verklig supportfråga och skapa fem nästan passande motkällor med fel språk, version och behörighet. Först när ingen av dem överskrider det tillåtna retrieval-scopet bör filtret tas i bruk i det produktiva chattflödet.

Källor

• OpenAI: File Search och Metadata Filtering
• Microsoft: Filter i vektorsökningar
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026