RAG filtri metapodatkov za AI klepetalnike: Ločevanje jezika, različice in dostopa

AI klepetalnik lahko najde semantično zelo podobne dele besedila in vseeno pripravi napačen odgovor: angleška navodila namesto slovenskih, dokumentacijo prejšnje različice namesto trenutne ali interna navodila za gosta brez ustreznega dovoljenja. Uvrstitev (ranking) v takem primeru ni nujno slaba. Napačno je bilo območje iskanja.

RAG filtri metapodatkov rešujejo točno to težavo. Pred iskanjem ali med njim omejijo, kateri dokumenti in izseki (chunks) sploh pridejo v poštev kot kontekst. Ustreznost (relevanca) nato odgovori na vprašanje »Kaj vsebinsko najbolj ustreza?«. Filter pa najprej odgovori na »Kaj se v tej situaciji sme in mora upoštevati?«.

Zakaj sama podobnost ni zanesljivo območje iskanja

Vektorsko in hibridno iskanje razvrščata vsebine glede na jezikovno ali semantično bližino. Priročnik za različico izdelka 4 je lahko izjemno podoben vprašanju o različici 5. Cenik za drug trg lahko vsebuje enaka imena izdelkov. Interni dokument za podporo pa lahko ponudi natančnejši odgovor kot javna pogosta vprašanja (FAQ), čeprav v javnem klepetu ne bi smel biti nikoli prikazan.

Zato mora pridobivalnik (retriever) ločevati dve vrsti pogojev:

• Stroge meje, kot so najemnik (tenant), vloga, status objave ali dovoljeno območje podatkov. Pri neznani vrednosti mora iskanje ostati zaprto.
• Strokovna izbirna merila, kot so jezik, družina izdelkov, različica, regija ali obdobje veljavnosti. Ta povečujejo natančnost in preprečujejo nasprotujoč si kontekst.

Trenutni OWASP pregled za LLM aplikacije tveganja vektorjev in vgradenj (embeddings) izrecno uvršča na mejo zaupanja AI aplikacije. To je pomemben vidik: preverjanje avtentikacije pred klepetom ne zadošča, če poznejše iskanje po podobnosti kljub temu poteka po preširokem indeksu.

Shema metapodatkov, ki deluje v praksi

Dobri filtri se ne začnejo z dolgo poizvedbo, temveč z nekaj kanoničnimi polji. Za večino spletnih klepetalnikov zadošča šest skupin:

• Jezik in trg: na primer locale in market, s fiksno določenimi vrednostmi namesto prostega besedila.
• Izdelek in različica: stabilna ID izdelka, razpon različic ter izbirno platforma ali paket.
• Veljavnost: status odobritve, veljavno od, veljavno do in enolična različica vira.
• Ciljna skupina: javno, stranka, partner ali interna ekipa – ločeno od dejanskega preverjanja vlog.
• Območje dostopa: najemnik, skupina ali nosilec pravic (principal), izključno iz preverjenega strežniškega konteksta.
• Poreklo: ID vira, URL, vrsta dokumenta in odgovorno vsebinsko področje za sledljivost.

Metapodatki sodijo na raven, na kateri se izvaja iskanje. Če se dokument razdeli na izseke (chunks), morajo ključna polja območja zanesljivo pristati na vsakem izseku. V nasprotnem primeru je dokument lahko pravilno klasificiran, medtem ko posamezni rezultati iskanja to razvrstitev izgubijo. Dokumentacija OpenAI za File Search na primer prikazuje, kako se atributi datotek uporabljajo za filtriranje metapodatkov. Referenca Amazon Bedrock pa dokumentira primerjalne operaterje, operaterje seznamov in razponov za enako osnovno zamisel.

Filtrov nikoli ne določajte prek jezikovnega modela

Model lahko iz vprašanja izpelje namige, kot sta jezik ali povezava z izdelkom. Vendar ne sme odločati o tem, kateremu najemniku pripada oseba ali kakšno vlogo ima. Te vrednosti morajo izhajati iz seje, sistema identitet in strežniških poslovnih pravil. Tudi niz za filtriranje, ki ga ustvari model, ne bi smel biti nepreverjeno posredovan iskalni storitvi.

Zanesljiv potek je videti takole:

1. Strežnik preveri avtentikacijo zahteve in določi dovoljeno območje podatkov.
2. Deterministična pravila nastavijo stroga polja, kot so najemnik, vloga in status objave.
3. Zaznane lastnosti, kot sta jezik ali izdelek, se potrdijo glede na dovoljene vrednosti.
4. Pridobivalnik (retriever) izvede le tipizirano, parametrizirano strukturo filtrov.
5. Aplikacija ponovno preveri vrnjene vire glede na pričakovano območje.
6. Ob manjkajočem ali nasprotujočem si kontekstu klepetalnik zastavi dodatno vprašanje ali vrne varen nadomestni odgovor (fallback).

Microsoftova dokumentacija o varnostnih filtrih navaja koristno razliko: nosilec pravic (principal) v filtru je sprva le vrednost. Avtentikacija in avtorizacija se morata zanesljivo zgoditi zunaj iskalnega izraza. Za portale za stranke naš prispevek o ločevanju javnega in avtenticiranega AI klepetalnika podrobneje obravnava to mejo.

Pred-filtriranje (Pre-filtering) ali po-filtriranje (Post-filtering)?

Položaj filtra vpliva na kakovost in čas izvajanja. Pred-filtriranje omeji kandidate že med vektorskim iskanjem. Po-filtriranje najprej išče širše in naknadno odstrani nedovoljene zadetke. Glede na dokumentacijo Azure o vektorskih filtrih lahko po-filtriranje pri selektivnih filtrih in majhnem k spregleda ustrezne rezultate; pred-filtriranje daje prednost preklicu (recall) v dovoljenem delnem naboru, vendar lahko pri zelo tesnih filtrih povzroči več računske zahtevnosti.

Za stroge meje dostopa vzorec »najprej išči široko, nato skrij« ni primeren. Avtorizirano območje je treba uveljaviti znotraj iskalne zahteve. Za čisto strokovne filtre lahko ekipa izmeri različici pred- in po-filtriranja. Pri tem ne šteje le povprečni čas odziva, temveč tudi to, kako pogosto zaradi izbranega vrstnega reda manjka obstoječi, dovoljeni zadetek.

Filtri ne nadomeščajo razvrščanja (ranking). Znotraj dovoljenega korpusa lahko hibridno iskanje in ponovno razvrščanje (reranking) še naprej dajeta prednost najboljšim virom. Vrstni red je torej: določitev območja, pridobivanje kandidatov, ocena relevantnosti, preverjanje virov, ustvarjanje odgovora.

Štirje tipični primeri filtriranja

Jezik z premišljenim nadomestnim korakom (fallback)

Za vprašanje v slovenščini bi moralo prvo pridobivanje izbrati slovenske, odobrene vsebine. Če ni zadetkov, aplikacija ne sme tiho mešati več jezikov. Eksplicitna druga pot se lahko vrne na odobren osnovni jezik in to dejstvo navede v odgovoru. Preverjanje kakovosti lokacije (Locale-QA) za večjezične baze znanja dodatno preveri, ali so različice vsebinsko res enakovredne.

Različica izdelka in časovna veljavnost

Vir ne bi smel delovati aktualno le zato, ker je bil nazadnje indeksiran (crawled). Odločilni sta strokovna različica in odobritev. Označite vsebine s stabilno ID izdelka, razponom različic, valid_from, valid_until in statusom. Pri prekrivajočih se odobritvah mora cevovod (pipeline) prijaviti konflikt, namesto da obe besedili postavi v isti poziv (prompt). Kako medsebojno delujeta pogostost indeksiranja in vzdrževanje virov, opisuje vodnik o ohranjanju aktualnosti baze znanja AI klepetalnika.

Najemnik in vloga

Pri skupnem indeksu mora vsako pridobivanje vsebovati na strežniku določenega najemnika in veljavne nosilce pravic (principals). Manjkajoči metapodatki ACL pomenijo »ni mogoče pridobiti«, ne pa »javno«. Po spremembi vloge ali odvzetju dovoljenja mora test pokazati, da stare seje ne prejmejo več prej dovoljenih izsekov.

Javna podpora in interna delovna navodila

Interno navodilo za eskalacijo se lahko strokovno popolnoma prilega vprašanju stranke. Vendar to iz njega ne naredi dovoljenega vira. Ločite območje objave in vrsto dokumenta; neodobrene vsebine privzeto označite kot izključene. Javni bot bi se moral v primeru dvoma preusmeriti na kontaktno pot ali predajo človeku (handoff), namesto da ugiba interne podrobnosti.

Najpogostejše napake pri implementaciji

• Taksonomija s prostim besedilom: Vrednosti, kot so sl, SL in sl-SI, nenamerno ustvarijo tri skupine.
• Privzeto odprto (Default-open): Izseki brez vloge, statusa ali najemnika pridejo v vsako območje iskanja.
• Napačna boolova logika: Operator OR med najemnikom in jezikom praktično odpravi strogo mejo.
• Odstopanje med dokumentom in izsekom (Document-Chunk-Drift): Pri ponovnem indeksiranju se novi metapodatki ne prenesejo na vse izseke.
• Samo pozitivni testi: Ekipa preverja, ali se pojavi dovoljeni dokument, ne pa tudi, ali zanesljivo manjka podobno zvočeči prepovedani dokument.
• Prazni zadetki kot težava modela: Ozka filtracija ne vrne ničesar, aplikacija pa pusti modelu, da nadaljuje z odgovarjanjem brez virov.

Zagotavljanje kakovosti (QA) filtrov: Testirajte meje, ne le zadetkov

Uporaben testni nabor za vsak pričakovani odgovor vsebuje vsaj enga bližnjega nasprotnega kandidata: napačen jezik, stara različica, potekla odobritev, drug najemnik ali interna ciljna skupina. Tako test pokaže, ali filter resnično ločuje in ne le naključno uvrsti pravega zadetka na vrh.

Ključne meritve so stopnja kršitev območja (scope violation rate), priklic v dovoljenem delnem naboru, delež praznih pridobivanj, število neznanih vrednosti metapodatkov, zakasnitev filtrov na 95. percentilu ter delež nadomestnih korakov (fallbacks) in pojasnjevalnih vprašanj. Za omejene vsebine mora biti tolerirana stopnja kršitev območja enaka nič. Okvir NIST AI RMF Core priporoča testiranje AI sistemov pred uporabo in redno med delovanjem ter dokumentiranje varnostnih meja, meje zanesljivosti in območja konteksta.

Pri tem ne beležite nepotrebnih vsebin ali celotnih uporabniških vprašanj. Večinoma zadoščajo različica filtra, abstraktno območje, število kandidatov, izbrane ID virov, razlog za zavrnitev in rezultat naknadnega preverjanja. Tako ostane odpravljanje napak mogoče, ne da bi ustvarili drugo puščanje podatkov v sistemu za sledljivost (observability).

Praktični kontrolni seznam pred začetkom uporabe

1. Dokumentirajte kanonična polja metapodatkov, podatkovne tipe, dovoljene vrednosti in skrbnike.
2. Ločite stroge meje dostopa od strokovnih izbirnih polj.
3. Manjkajoče varnostno pomembne vrednosti dosledno obravnavajte kot nedovoljene.
4. Filtre gradite iz preverjenega strežniškega konteksta in parametrizirajte vnose.
5. Metapodatke po vnosu in razdelitvi na izseke vzorčno preberite nazaj.
6. Testirajte pozitivne, negativne, mejne primere in primere preklica glede na pravi indeks.
7. Izmerite obnašanje pred-/po-filtriranja z realističnim k in selektivnimi območji.
8. Prazne rezultate usmerite v pojasnjevalno vprašanje, varen nadomestni odgovor ali predajo človeku.
9. Verzionirajte spremembe filtrov in jih uvajajte skupaj z regresijskimi testi pridobivanja.

RAG filtri metapodatkov so zato več kot le funkcija udobja pri iskanju. So povezava med vsebinskim modelom, identiteto, aktualnostjo in kakovostjo pridobivanja. Kdor najprej deterministično določi območje iskanja, daje razvrščanju in jezikovnemu modelu manjšo, čistejšo in preverljivo delovno osnovo.

Naslednji korak: Izberite resnično podporno vprašanje in zanj ustvarite pet skoraj ustreznih nasprotnih virov iz napačnega jezika, različice in dovoljenja. Šele ko noben od njih ne preseže dovoljenega območja pridobivanja, naj gre filter v produkcijski potek klepeta.

Viri

• OpenAI: File Search in filtriranje metapodatkov
• Microsoft: Filtri v vektorskih poizvedbah
• Microsoft: Vzorec varnostnih filtrov (Security Filter Pattern)
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026