RAG metadatu filtri AI tērzēšanas botiem: valodas, versijas un piekļuves nošķiršana

AI tērzēšanas bots var atrast semantiski ļoti līdzīgas teksta vietas un tomēr sagatavot nepareizu atbildi: instrukciju angļu, nevis latviešu valodā, iepriekšējās versijas dokumentāciju pašreizējās vietā vai iekšējās norādes viesim bez atbilstošām piekļuves tiesībām. Šādā gadījumā meklēšanas rezultātu rangs (ranking) nav obligāti slikts. Meklēšanas telpa bija nepareiza.

RAG metadatu filtri atrisina tieši šo problēmu. Tie pirms meklēšanas vai tās laikā ierobežo, kuri dokumenti un teksta fragmenti (chunks) vispār var tikt izmantoti kā konteksts. Atbilstība (relevance) pēc tam atbild uz jautājumu „Kas vislabāk atbilst satura ziņā?“. Savukārt filtrs vispirms atbild uz jautājumu „Ko šajā situācijā drīkst un vajag ņemt vērā?“.

Kāpēc līdzība vien nav uzticams tvērums

Vektoru un hibrīdā meklēšana sakārto saturu pēc valodnieciskās vai semantiskās līdzības. Produkta 4. versijas rokasgrāmata var būt īpaši līdzīga jautājumam par 5. versiju. Citu tirgu cenu lapās var būt tie paši produktu nosaukumi. Un iekšējs atbalsta dokuments var sniegt precīzāku atbildi nekā publiskie BUJ (FAQ), lai gan publiskajā čatā tas nekad nedrīkstētu parādīties.

Tāpēc ieguves mehānismam (retriever) vajadzētu nošķirt divu veidu nosacījumus:

• Stingri ierobežojumi, piemēram, klients (tenant), loma, publicēšanas statuss vai pieļaujamā datu zona. Ja vērtība nav zināma, meklēšanai jāpaliek slēgtai.
• Biznesa atlases kritēriji, piemēram, valoda, produktu saime, versija, reģions vai derīguma termiņš. Tie palielina precizitāti un novērš pretrunīga konteksta rašanos.

Aktuālais OWASP pārskats LLM lietotnēm vektoru un iegulšanas (embedding) riskus tieši attiecina uz AI lietotnes uzticamības robežu. Tas ir svarīgs skatpunkts: ar autentifikācijas pārbaudi pirms čata nepietiek, ja sekojošā līdzības meklēšana joprojām darbojas pārāk plašā indeksā.

Metadatu shēma, kas strādā ikdienā

Labi filtri nesākas ar garu vaicājumu, bet gan ar dažiem kanoniskiem laukiem. Daudzām tīmekļa vietņu tērzēšanas būtnēm pietiek ar sešām grupām:

• Valoda un tirgus: piemēram, locale un market, izmantojot stingri definētas vērtības, nevis brīvu tekstu.
• Produkts un versija: stabils produkta ID, versiju diapazons un pēc izvēles platforma vai tarifs.
• Derīgums: apstiprinājuma statuss, derīgs no, derīgs līdz un unikāla avota versija.
• Mērķauditorija: publisks, klients, partneris vai iekšējā komanda – nošķirti no faktiskās lomu pārbaudes.
• Piekļuves zona: klients, grupa vai subjekts (principal), tikai no verificēta servera konteksta.
• Izcelsme: avota ID, URL, dokumenta tips un atbildīgā satura sadaļa izsekojamībai.

Metadati pieder līmenim, kurā tiek veikta meklēšana. Ja dokuments tiek sadalīts fragmentos (chunks), svarīgajiem tvēruma laukiem droši jānonāk katrā no tiem. Pretējā gadījumā dokuments var būt pareizi klasificēts, bet atsevišķi meklēšanas rezultāti šo iedalījumu var zaudēt. OpenAI dokumentācija par File Search parāda, piemēram, kā failu atribūti tiek izmantoti metadatu filtriem. Amazon Bedrock atsauce dokumentē salīdzināšanas, sarakstu un diapazonu operatorus šai pašai pamatidejai.

Nekad neļaujiet valodas modelim autorizēt filtrus

Modelis drīkst no jautājuma atvasināt tādas norādes kā valodu vai saistību ar produktu. Tomēr tas nedrīkst lemt par to, kuram klientam persona pieder vai kāda loma tai ir. Šīm vērtībām jānāk no sesijas, identitātes sistēmas un servera puses biznesa noteikumiem. Arī modeļa ģenerēto filtra virkni nedrīkst nodot meklēšanas pakalpojumam bez pārbaudes.

Izturīgs darba process izskatās šādi:

1. Serveris autentificē pieprasījumu un nosaka pieļaujamo datu zonu.
2. Deterministiski noteikumi iestata stingros laukus, piemēram, klientu, lomu un publicēšanas statusu.
3. Atpazītās pazīmes, piemēram, valoda vai produkts, tiek validētas pret atļautajām vērtībām.
4. Retriever izpilda tikai tipizētu, parametrizētu filtra struktūru.
5. Lietotne vēlreiz pārbauda atgrieztos avotus, vai tie atbilst paredzētajam tvērumam.
6. Trūkstoša vai pretrunīga konteksta gadījumā čatbots uzdod precizējošu jautājumu vai sniedz drošu rezerves atbildi (fallback).

Microsoft dokumentācijā par drošības filtriem (Security Filters) ir sniegts noderīgs nošķīrums: subjekts (principal) filtrā vispirms ir tikai vērtība. Autentifikācijai un autorizācijai droši jānotiek ārpus meklēšanas izteiksmes. Klientu portāliem mūsu raksts par publiska un autentificēta AI tērzēšanas bota nošķiršanu padziļina šo robežu.

Pirmsfiltrēšana vai pēcfiltrēšana?

Filtra novietojums ietekmē kvalitāti un izpildes laiku. Pirmsfiltrēšana (Pre-filter) ierobežo kandidātus jau vektoru meklēšanas laikā. Pēcfiltrēšana (Post-filter) vispirms meklē plašāk un pēc tam noņem nepieļaujamos rezultātus. Saskaņā ar Azure dokumentāciju par vektoru filtriem pēcfiltrēšana ar selektīviem filtriem un mazu k vērtību var palaist garām atbilstošus rezultātus; pirmsfiltrēšana dod priekšroku meklēšanas precizitātei atļautajā apakškopā, bet ļoti šauru filtru gadījumā var prasīt vairāk skaitļošanas resursu.

Stingrām piekļuves robežām pieeja „vispirms meklēt plaši, pēc tam paslēpt“ nav piemērots pamatmodelis. Autorizētais tvērums ir jāpieprasa pašā meklēšanas pieprasījumā. Tīri biznesa filtriem komanda var izmērīt gan pirms-, gan pēcfiltrēšanas variantus. Šeit nozīme ir ne tikai vidējam atbildes laikam, bet arī tam, cik bieži izvēlētās secības dēļ trūkst kāda pieejama, atļauta rezultāta.

Filtri neaizstāj rangsakarību (ranking). Atļautā korpusa ietvaros Hybrid Search un Reranking joprojām var piešķirt prioritāti labākajiem avotiem. Tātad secība ir šāda: noteikt tvērumu, iegūt kandidātus, novērtēt atbilstību, pārbaudīt avotus, ģenerēt atbildi.

Četri tipiski filtrēšanas gadījumi

Valoda ar apzinātu rezerves scenāriju (fallback)

Jautājumam latviešu valodā pirmajā ieguves reizē jāizvēlas apstiprināts saturs latviešu valodā. Ja rezultātu nav, lietotne nedrīkst klusējot sajaukt vairākas valodas. Eksplicīts otrais ceļš var atgriezties pie apstiprinātas bāzes valodas un atbildē norādīt uz šo apstākli. Daudzvalodu zināšanu bāzes Locale-QA papildus pārbauda, vai varianti saturiski tiešām ir līdzvērtīgi.

Produkta versija un laika derīgums

Avotam nav jāizskatās aktuālam tikai tāpēc, ka tas nesen tika pārmeklēts (crawled). Izšķirošā ir faktiskā versija un apstiprinājums. Atzīmējiet saturu ar stabilu produkta ID, versiju diapazonu, valid_from, valid_until un statusu. Pārklājošos apstiprinājumu gadījumā konveijerim (pipeline) jāziņo par konfliktu, nevis jāievieto abi teksti vienā vaicājumā (prompt). Kā savstarpēji mijiedarbojas pārmeklēšanas biežums un avotu uzturēšana, aprakstīts rokasgrāmatā par AI tērzēšanas bota zināšanu bāzes aktualitāti.

Klients un loma

Kopīga indeksa gadījumā katram pieprasījumam jāsatur servera pusē noteiktais klients un derīgie subjekti (principals). Trūkstoši ACL metadati nozīmē „nav pieejams“, nevis „publisks“. Pēc lomu maiņas vai piekļuves tiesību atsaukšanas testam jāparāda, ka vecās sesijas vairs nesaņem iepriekš atļautos fragmentus.

Publiskais atbalsts un iekšējās darba instrukcijas

Iekšējā eskalācijas instrukcija saturiski var perfekti atbilst klienta jautājumam. Tas nepadara to par pieļaujamu avotu. Nošķiriet publicēšanas tvērumu un dokumenta tipu; atzīmējiet neapstiprinātu saturu pēc noklusējuma kā izslēgtu. Šaubu gadījumā publiskajam botam vajadzētu pāriet uz kontakta vai nodošanas cilvēkam (handoff) ceļu, nevis minēt iekšējās detaļas.

Biežākās ieviešanas kļūdas

• Brīvā teksta taksonomija: tādas vērtības kā lv, LV un lv-LV netīši veido trīs dažādas grupas.
• Noklusējuma atvērtība (default-open): fragmenti bez lomas, statusa vai klienta iekļūst katrā meklēšanas telpā.
• Nepareiza Bula loģika: OR izmantošana starp klientu un valodu praktiski atceļ stingro robežu.
• Dokumentu un fragmentu novirze (drift): veicot atkārtotu indeksēšanu, jauni metadati netiek pārnesti uz visiem fragmentiem.
• Tikai pozitīvi testi: komanda pārbauda, vai parādās atļautais dokuments, bet nepārbauda, vai droši trūkst līdzīgi skanoša aizliegta dokumenta.
• Tukši rezultāti kā modeļa problēma: šaurs filtrs nesniedz nekādus rezultātus, un lietotne ļauj modelim turpināt atbildēt bez avotiem.

Filtru kvalitātes nodrošināšana (QA): testējiet ne tikai rezultātus, bet arī robežas

Lietojamā testa kopā katrai paredzamajai atbildei jābūt vismaz vienam līdzīgam pretkandidātam: nepareiza valoda, veca versija, beidzies apstiprinājums, cits klients vai iekšējā mērķauditorija. Tādējādi tests parāda, vai filtrs patiešām nošķir saturu, nevis tikai nejauši novieto pareizo rezultātu augšgalā.

Svarīgi rādītāji ir tvēruma pārkāpumu līmenis, ieguves pilnīgums (recall) atļautajā apakškopā, tukšo ieguvju īpatsvars, nezināmu metadatu vērtību skaits, filtra aizture (latency) 95. percentilē, kā arī rezerves variantu (fallbacks) un precizējošo jautājumu īpatsvars. Ierobežotam saturam pieļaujamajam tvēruma pārkāpumu līmenim jābūt nullei. NIST AI RMF Core iesaka testēt AI sistēmas pirms to ieviešanas un regulāri lietošanas laikā, kā arī dokumentēt drošības, uzticamības un konteksta robežas.

Šim nolūkam neprotokolējiet nevajadzīgu saturu vai pilnus lietotāju jautājumus. Parasti pietiek ar filtra versiju, abstrakto tvērumu, kandidātu skaitu, izvēlētajiem avotu ID, noraidīšanas iemeslu un pēcpārbaudes rezultātu. Tādējādi kļūdu meklēšana paliek iespējama, neveidojot otru datu noplūdi novērojamības (observability) sistēmā.

Praktisks kontrolsaraksts pirms izvēršanas (rollout)

1. Dokumentēt kanoniskos metadatu laukus, datu tipus, atļautās vērtības un īpašniekus.
2. Nošķirt stingrās piekļuves robežas no biznesa atlases laukiem.
3. Trūkstošās drošībai būtiskās vērtības konsekventi apstrādāt kā neatļautas.
4. Veidot filtrus no verificēta servera konteksta un parametrizēt ievaddatus.
5. Pēc datu ievades (ingestion) un sadalīšanas fragmentos (chunking) izlases veidā nolasīt metadatus.
6. Testēt pozitīvos, negatīvos, robežgadījumus un atsaukšanas gadījumus pret reālo indeksu.
7. Mērīt pirms-/pēcfiltrēšanas uzvedību ar reālistisku k un selektīviem tvērumiem.
8. Tukšus rezultātus novirzīt uz precizējošu jautājumu, drošu rezerves scenāriju vai nodošanu cilvēkam (Human Handoff).
9. Veidot versijas filtru izmaiņām un izvērst tās kopā ar ieguves regresijas testiem.

Tādējādi RAG metadatu filtri ir kas vairāk nekā tikai meklēšanas ērtības funkcija. Tie ir savienotājelements starp satura modeli, identitāti, aktualitāti un ieguves kvalitāti. Kurš vispirms deterministiski nosaka tvērumu, tas dod rangsakarības mehānismam un valodas modelim mazāku, tīrāku un pārbaudāmu darba bāzi.

Nākamais solis: Izvēlieties reālu atbalsta jautājumu un izveidojiet tam piecus gandrīz atbilstošus pretavotus no nepareizas valodas, versijas un piekļuves līmeņa. Tikai tad, kad neviens no tiem nepārkāpj atļauto ieguves tvērumu, filtram vajadzētu nonākt produktīvajā čata plūsmā.

Avoti

• OpenAI: File Search un metadatu filtrēšana
• Microsoft: Filtri vektoru vaicājumos
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026