RAG metaduomenų filtrai DI pokalbių botams: kalbos, versijos ir prieigos atskyrimas

DI pokalbių botas gali rasti semantiškai labai panašias teksto vietas ir vis tiek parengti neteisingą atsakymą: instrukciją anglų, o ne lietuvių kalba, ankstesnės, o ne dabartinės versijos dokumentaciją arba vidines pastabas svečiui, neturinčiam atitinkamų teisių. Tai nebūtinai reiškia, kad reitingavimas yra blogas. tiesiog paieškos erdvė buvo neteisinga.

RAG metaduomenų filtrai išsprendžia būtent šią problemą. Prieš paiešką arba jos metu jie apriboja, kurie dokumentai ir teksto fragmentai (angl. chunks) apskritai gali būti naudojami kaip kontekstas. Reikšmingumas vėliau atsako į klausimą „Kas geriausiai tinka pagal turinį?“. Tačiau filtras pirmiausia atsako į klausimą „Ką leidžiama ir reikėtų įvertinti šioje situacijoje?“.

Kodėl vien tik panašumas nėra patikima paieškos aprėptis

Vektorinė ir hibridinė paieška rikiuoja turinį pagal kalbinį arba semantinį artumą. Produkto 4 versijos vadovas gali būti itin panašus į klausimą apie 5 versiją. Kitos rinkos kainoraštyje gali būti tie patys produktų pavadinimai. O vidinis pagalbos dokumentas gali pateikti tikslesnį atsakymą nei vieši DUK, nors viešajame pokalbyje jis jokiu būdu neturėtų pasirodyti.

Todėl informacijos paieškos sistema (angl. retriever) turėtų atskirti dviejų rūšių sąlygas:

• Griežtos ribos, tokios kaip klientas (angl. tenant), rolė, publikavimo būsena arba leistina duomenų sritis. Esant nežinomai reikšmei, paieška privalo likti uždara.
• Funkciniai atrankos kriterijai, tokie kaip kalba, produktų šeima, versija, regionas arba galiojimo laikotarpis. Jie padidina tikslumą ir apsaugo nuo prieštaringo konteksto.
Sub-process execution standard set.

Dabartinė OWASP apžvalga LLM taikomosioms programoms vektorių ir įtraukčių (angl. embeddings) rizikas aiškiai priskyria DI taikomosios programos pasitikėjimo ribai. Tai svarbi perspektyva: autorizacijos patikrinimo prieš pokalbį neužtenka, jei vėlesnė panašumo paieška vis tiek vykdoma per per daug plačią indeksavimo erdvę.

Metaduomenų schema, kuri pasiteisina kasdienybėje

Geri filtrai prasideda ne nuo ilgos užklausos, o nuo kelių kanoninių laukų. Daugeliui svetainių pokalbių botų pakanka šešių grupių:

• Kalba ir rinka: pavyzdžiui, locale ir market, naudojant griežtai apibrėžtas reikšmes, o ne laisvą tekstą.
• Produktas ir versija: stabili produkto ID, versijų diapazonas ir pasirinktinai platforma arba planas.
• Galiojimas: patvirtinimo būsena, galioja nuo, galioja iki ir unikali šaltinio versija.
• Tikslinė auditorija: vieša, klientas, partneris arba vidinė komanda – atskirai nuo pačios rolių patikros.
• Prieigos sritis: klientas (tenant), grupė arba subjektas (principal), tik iš patikrintos serverio aplinkos.
• Kilmė: šaltinio ID, URL, dokumento tipas ir atsakinga turinio sritis sekamumui užtikrinti.

Metaduomenys turi priklausyti tam lygmeniui, kuriame vykdoma paieška. Jei dokumentas suskaidomas į fragmentus (chunks), svarbiausi aprėpties laukai turi patikimai patekti į kiekvieną fragmentą. Priešingu atveju dokumentas gali būti klasifikuotas teisingai, tačiau atskiri paieškos rezultatai šią klasifikaciją praras. Pavyzdžiui, OpenAI dokumentacija apie „File Search“ rodo, kaip failų atributai naudojami metaduomenų filtravimui. Amazon Bedrock nuoroda aprašo palyginimo, sąrašų ir diapazonų operatorius tai pačiai pagrindinei idėjai.

Niekada neleiskite kalbos modeliui autorizuoti filtrų

Modelis iš klausimo gali išskirti užuominas, pavyzdžiui, kalbą ar sąsają su produktu. Tačiau jis neturi spręsti, kuriam klientui priklauso asmuo arba kokias roles jis turi. Šios reikšmės turi ateiti iš sesijos, identifikavimo sistemos ir serverio verslo logikos taisyklių. Taip pat modelio sugeneruota filtro eilutė neturėtų būti perduodama paieškos tarnybai be patikrinimo.

Patikimas procesas atrodo taip:

1. Serveris autentifikuoja užklausą ir nustato leistiną duomenų sritį.
2. Deterministinės taisyklės nustato griežtus laukus, tokius kaip klientas, rolė ir publikavimo būsena.
3. Aptikti požymiai, tokie kaip kalba ar produktas, yra patikrinami pagal leistinas reikšmes.
4. Paieškos sistema vykdo tik tipizuotą, parametrizuotą filtro struktūrą.
5. Taikomoji programa dar kartą patikrina grąžintus šaltinius pagal tikėtiną paieškos aprėptį.
6. Jei trūksta konteksto arba jis yra prieštaringas, pokalbių botas paklausia papildomai arba pateikia saugų atsarginį atsakymą (angl. fallback).

Microsoft dokumentacija apie saugumo filtrus atskiria labai svarbų dalyką: subjektas (principal) filtre iš pradžių yra tik reikšmė. Autentifikavimas ir autorizavimas turi patikimai vykti už paieškos išraiškos ribų. Klientų portalams skirtas mūsų straipsnis apie viešojo ir autentifikuoto DI pokalbių boto atskyrimą išsamiau nagrinėja šią ribą.

Išankstinis filtravimas (Pre-filtering) ar papildomas filtravimas (Post-filtering)?

Filtro vieta daro įtaką kokybei ir vykdymo laikui. Išankstinis filtras apriboja kandidatus dar vektorinės paieškos metu. Papildomas filtras iš pradžių ieško plačiau ir tik po to pašalina neleistinus rezultatus. Pasak Azure dokumentacijos apie vektorių filtrus, taikant papildomą filtravimą su selektyviais filtrais ir maža k reikšme galima praleisti tinkamus rezultatus; išankstinis filtravimas teikia pirmenybę atšaukimui (angl. recall) leistinoje duomenų dalyje, tačiau esant labai siauriems filtrams gali pareikalauti daugiau skaičiavimo resursų.

Griežtoms prieigos riboms modelis „iš pradžių ieškoti plačiai, o po to paslėpti“ nėra tinkamas. Autorizuota paieškos aprėptis turi būti užtikrinta pačioje paieškos užklausoje. Grynai funkciniams filtrams komanda gali išmatuoti išankstinio ir papildomo filtravimo variantus. Čia svarbus ne tik vidutinis atsako laikas, bet ir tai, kaip dažnai dėl pasirinktos sekos prarandamas esamas, leistinas rezultatas.

Filtrai nepakeičia reitingavimo. Leistiname korpuse hibridinė paieška ir perskaičiavimas (reranking) ir toliau gali teikti pirmenybę geriausiems šaltiniams. Vadinasi, seka yra tokia: apibrėžti paieškos aprėptį, gauti kandidatus, įvertinti reikšmingumą, patikrinti šaltinius, sugeneruoti atsakymą.

Keturi tipiniai filtravimo atvejai

Kalba su sąmoningu atsarginiu variantu (Fallback)

Atsakant į klausimą lietuvių kalba, pirmoji paieška turėtų pasirinkti patvirtintą turinį lietuvių kalba. Jei rezultatų nėra, programa neturėtų tyliai maišyti kelių kalbų. Aiškus antrasis kelias gali sugrįžti prie patvirtintos bazinės kalbos ir apie šią aplinkybę informuoti atsakyme. Daugiakalbių žinių bazių „Locale-QA“ papildomai patikrina, ar variantai turinio atžvilgiu tikrai yra lygiaverčiai.

Produkto versija ir laiko galiojimas

Šaltinis neturėtų atrodyti aktualus vien todėl, kad jis buvo nuskaitytas paskutinis. Svarbiausia yra funkcinė versija ir patvirtinimas. Pažymėkite turinį stabilia produkto ID, versijų diapazonu, valid_from, valid_until ir būsena. Jei patvirtinimai dubliuojasi, sistema turi pranešti apie konfliktą, o ne įkelti abu tekstus į tą pačią užklausą (angl. prompt). Kaip sąveikauja nuskaitymo dažnumas ir šaltinių priežiūra, aprašyta vadove apie DI pokalbių boto žinių bazės atnaujinimą.

Klientas (Tenant) ir rolė

Naudojant bendrą indeksą, kiekvienoje užklausoje turi būti serverio nustatytas klientas ir galiojantys subjektai (principals). Trūkstami ACL metaduomenys reiškia „nepasiekiamas“, o ne „viešas“. Pasikeitus rolei arba panaikinus teisę, testas turi parodyti, kad senos sesijos dabar nebeggauna anksčiau leistinų teksto fragmentų.

Viešasis palaikymas ir vidinės darbo instrukcijos

Vidinė eskalavimo instrukcija pagal turinį gali puikiai tikti kliento klausimui. Tačiau dėl to ji netampa leistinu šaltiniu. Atskirkite publikavimo aprėptį ir dokumento tipą; nepatvirtintą turinį pagal nutylėjimą pažymėkite kaip išimtą. Kilus abejonių, viešasis botas turėtų nukreipti į kontakto arba perdavimo žmogui (angl. handoff) kelią, užuot bandęs spėlioti vidines detales.

Dažniausios diegimo klaidos

• Laisvo teksto taksonomija: tokios reikšmės kaip de, DE ir de-DE netyčia sukuria tris skirtingas grupes.
• Atvira numatytoji būsena (Default-open): fragmentai be rolės, būsenos ar kliento pateks į bet kurią paieškos erdvę.
• Neteisinga Bulio logika: operatorius OR tarp kliento ir kalbos praktiškai panaikina griežtą ribą.
• Dokumento ir fragmento nuokrypis (Drift): iš naujo indeksuojant nauji metaduomenys neperduodami visiems fragmentams.
• Tik teigiami testai: komanda patikrina, ar leistinas dokumentas pasirodo, bet nepatikrina, ar panašiai skambantis draudžiamas dokumentas yra tikrai atmetamas.
• Tušti paieškos rezultatai laikomi modelio problema: siauras filtras nieko negrąžina, o programa leidžia modeliui toliau atsakinėti be šaltinių.

Filtrų QA: Tikrinkite ne tik rezultatus, bet ir ribas

Tinkamas testavimo rinkinys kiekvienam tikėtinam atsakymui turi bent vieną artimą priešingą kandidatą: neteisinga kalba, sena versija, pasibaigęs galiojimas, kitas klientas arba vidinė tikslinė grupė. Taip testas parodo, ar filtras tikrai atskiria duomenis, ar tik atsitiktinai iškelia teisingą rezultatą į viršų.

Svarbūs rodikliai yra aprėpties pažeidimo dažnumas, atšaukimas (recall) leistinoje duomenų dalyje, tuščių paieškų dalis, nežinomų metaduomenų reikšmių skaičius, filtrų delsos laikas 95-ajame percentile, taip pat atsarginių variantų ir patikslinančių klausimų dalis. Apribotam turiniui leistinas aprėpties pažeidimo dažnumas turi būti lygus nuliui. NIST AI RMF Core rekomenduoja patikrinti DI sistemas prieš naudojimą ir reguliariai eksploatacijos metu bei dokumentuoti saugumo, patikimumo ir konteksto ribas.

Šiam tikslui neregistruokite nereikalingo turinio ar pilnų vartotojų klausimų. Dažniausiai pakanka filtro versijos, abstrakčios aprėpties, kandidatų skaičiaus, pasirinktų šaltinių ID, atmetimo priežasties ir patikrinimo po paieškos rezultato. Taip išlaikoma galimybė ieškoti klaidų nesukuriant antrojo duomenų nuotėkio stebėsenos sistemoje.

Praktinis kontrolinis sąrašas prieš paleidimą

1. Dokumentuokite kanoninius metaduomenų laukus, duomenų tipus, leistinas reikšmes ir savininkus.
2. Atskirkite griežtas prieigos ribas nuo funkcinių atrankos laukų.
3. Trūkstamas saugumui svarbias reikšmes nuosekliai laikykite neleistinomis.
4. Kurkite filtrus iš patikrinto serverio konteksto ir parametrizuokite įvestis.
5. Po duomenų įkėlimo ir suskaidymo (chunking) atlikite atsitiktinį metaduomenų nuskaitymo patikrinimą.
6. Išbandykite teigiamus, neigiamus, ribinius ir teisių atšaukimo atvejus tikrajame indekse.
7. Išmatuokite išankstinio / papildomo filtravimo elgseną naudodami realistišką k ir selektyvias aprėptis.
8. Tuščius rezultatus nukreipkite į patikslinantį klausimą, saugų atsarginį atsakymą arba perdavimą žmogui.
9. Filtro pakeitimams taikykite versijavimą ir išleiskite juos kartu su paieškos regresiniais testais.

RAG metaduomenų filtrai yra daugiau nei tik patogi paieškos funkcija. Jie yra jungtis tarp turinio modelio, tapatybės, aktualumo ir paieškos kokybės. Tie, kurie iš pradžių deterministiškai nustato aprėptį, suteikia reitingavimui ir kalbos modeliui mažesnį, švaresnį ir patikrinamą darbo pagrindą.

Kitas žingsnis: Pasirinkite realų pagalbos klausimą ir sukurkite penkis beveik tinkančius priešingus šaltinius iš neteisingos kalbos, versijos ar teisių. Tik tada, kai nė vienas iš jų neviršys leistinos paieškos aprėpties, filtras turėtų patekti į gamybinį pokalbių srautą.

Šaltiniai

• 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