RAG-metatietosuodattimet tekoäly-chatboteissa: kielen, version ja käyttöoikeuksien erottaminen

Tekoäly-chatbot voi löytää semanttisesti erittäin samanlaisia tekstikohtia ja silti valmistella väärän vastauksen: englanninkielisen ohjeen saksankielisen sijaan, edellisen version dokumentaation nykyisen sijaan tai sisäisiä ohjeita vierailijalle ilman käyttöoikeutta. Hakutulosten järjestys ei silloin välttämättä ole huono. Hakualue oli väärä.

RAG-metatietosuodattimet ratkaisevat juuri tämän ongelman. Ne rajaavat ennen hakua tai hakuprosessin aikana, mitkä dokumentit ja tekstilohkot (chunkit) voivat yleensäkin tulla kysymykseen kontekstina. Relevanssi vastaa sen jälkeen kysymykseen ”Mikä sopii sisällöllisesti parhaiten?”. Suodatin vastaa ensin kysymykseen ”Mitä tässä tilanteessa saa ja pitää ottaa huomioon?”.

Miksi samankaltaisuus yksinään ei ole luotettava laajuus

Vektori- ja hybridihaku järjestävät sisällöt kielellisen tai semanttisen läheisyyden mukaan. Tuoteversion 4 käsikirja voi olla erittäin samankaltainen versiota 5 koskevan kysymyksen kanssa. Toisen markkina-alueen hinnasto voi sisältää samat tuotenimet. Ja sisäinen tukidokumentti voi tarjota tarkemman vastauksen kuin julkinen UKK, vaikka se ei saisi koskaan näkyä julkisessa chatissa.

Siksi hakujärjestelmän (retriever) tulisi pitää erillään kahdenlaisia ehtoja:

• Ehdottomat rajoitukset kuten asiakkuus (tenant), rooli, julkaisutila tai sallittu data-alue. Tuntemattoman arvon kohdalla haun on pysyttävä suljettuna.
• Sisällölliset valintakriteerit kuten kieli, tuoteperhe, versio, alue tai voimassaoloaika. Ne lisäävät tarkkuutta ja estävät ristiriitaisen kontekstin.

Nykyinen OWASP-katsaus LLM-sovelluksille luokittelee vektori- ja embedding-riskit nimenomaan tekoälysovelluksen luottamusrään rajoihin. Tämä on tärkeä näkökulma: Todennustarkistus ennen chattia ei riitä, jos sen jälkeinen samankaltaisuushaku ajetaan silti liian laajan indeksin läpi.

Metatietoskeema, joka kantaa arjessa

Hyvät suodattimet eivät ala pitkästä kyselystä, vaan muutamasta kanonisesta kentästä. Monille verkkosivustojen chatboteille riittää kuusi ryhmää:

• Kieli ja markkina: kuten locale ja market, kiinteästi määritellyillä arvoilla vapaan tekstin sijaan.
• Tuote ja versio: stabiili tuote-ID, versioalue ja valinnaisesti alusta tai hinnoittelutaso.
• Voimassaolo: julkaisutila, voimassa alkaen, voimassa päättyen ja yksiselitteinen lähdeversio.
• Kohderyhmä: julkinen, asiakas, kumppani tai sisäinen tiimi – erotettuna varsinaisesta roolitarkistuksesta.
• Käyttöoikeusalue: asiakkuus (tenant), ryhmä tai principal, yksinomaan tovennetusta palvelinkontekstista.
• Alkuperä: lähde-ID, URL, dokumenttityyppi ja vastuullinen sisältöalue jäljitettävyyttä varten.

Metatiedot kuuluvat tasolle, jolla haku suoritetaan. Jos dokumentti pilkotaan palasiin (chunks), ratkaisevien scope-kenttien on päädyttävä luotettavasti jokaiseen palaan. Muuten dokumentti voi olla luokiteltu oikein, mutta yksittäiset hakutulokset menettävät tämän luokituksen. Esimerkiksi OpenAI-dokumentaatio File Search -toiminnosta näyttää, miten tiedostoattribuutteja käytetään metatietosuodattimissa. Amazon Bedrock -referenssi dokumentoi vertailu-, lista- ja alue-operaattorit samalle perusidealle.

Älä koskaan anna kielimallin valtuuttaa suodattimia

Malli saa päätellä kysymyksestä vihjeitä, kuten kielen tai tuoteliitännäisyyden. Se ei kuitenkaan saa päättää, mihin asiakkuuteen henkilö kuuluu tai mikä rooli hänellä on. Näiden arvojen on tultava istunnosta, identiteettijärjestelmästä ja palvelinpuolen liiketoimintasäännöistä. Mallin luomaa suodatinnauhaa ei myöskään pitäisi välittää hakupalvelulle tarkistamatta.

Vankka toimintamalli näyttää tältä:

1. Palvelin todentaa pyynnön ja määrittää sallitun data-alueen.
2. Deterministiset säännöt asettavat ehdottomat kentät, kuten asiakkuuden, roolin ja julkaisutilan.
3. Tunnistetut ominaisuudet, kuten kieli tai tuote, validoidaan sallittuja arvoja vasten.
4. Hakujärjestelmä suorittaa vain tyypitetyn ja parametroidun suodatinrakenteen.
5. Sovellus tarkistaa palautetut lähteet vielä kerran odotetun laajuuden osalta.
6. Jos konteksti puuttuu tai on ristiriitainen, chatbot kysyy tarkennusta tai antaa turvallisen oletusvastauksen (fallback).

Microsoftin dokumentaatio Security Filters -ominaisuudesta tekee hyödyllisen erottelun: Principal suodattimessa on aluksi vain arvo. Todennetun tunnistuksen ja valtuutuksen on tapahduttava luotettavasti hakuilmaisun ulkopuolella. Asiakasportaaleja varten artikkelimme julkisen ja todennetun tekoäly-chatbotin erottamisesta syventää tätä rajaa.

Esisuodatus (Pre-filter) vai jälkisuodatus (Post-filter)?

Suodattimen sijainti vaikuttaa laatuun ja suoritusaikaan. Esisuodatus rajaa ehdokkaat jo vektorihaut aikana. Jälkisuodatus hakee ensin laajemmin ja poistaa sen jälkeen luvattomat osumat. Azure-dokumentaation vektorisuodattimia koskevan osion mukaan jälkisuodatus voi valikoivilla suodattimilla ja pienellä k-arvolla missata sopivia tuloksia; esisuodatus suosii saavutettavuutta (recall) sallitussa osajoukossa, mutta voi erittäin tiukoilla suodattimilla aiheuttaa enemmän laskentakustannuksia.

Ehdottomille käyttöoikeusrajoille ”hae ensin laajasti, piilota vasta sitten” ei ole sopiva perusmalli. Valtuutettu alue on pakotettava hakukyselyn sisällä. Pelkästään sisällöllisille suodattimille tiimi voi mitata esi- ja jälkisuodatusvaihtoehtoja. Tällöin ei ratkaise vain keskimääräinen vastausaika, vaan myös se, kuinka usein olemassa oleva, sallittu osuma puuttuu valitun järjestyksen vuoksi.

Suodattimet eivät korvaa järjestämistä (ranking). Sallitun korpuksen sisällä Hybrid Search ja Reranking voivat edelleen priorisoida parhaat lähteet. Järjestys on siis seuraava: määritä alue, hae ehdokkaat, arvioi relevanssi, tarkista lähteet, luo vastaus.

Neljä tyypillistä suodatintapausta

Kieli ja hallittu varajärjestelmä (fallback)

Suomenkieliselle kysymykselle ensimmäisen haun tulisi valita suomenkielisiä, julkaistuja sisältöjä. Jos osumaa ei löydy, sovellus ei saa hiljaisesti sekoittaa useita kieliä. Eksplisiittinen toinen polku voi turvautua julkaistuun peruskieleen ja tuoda tämän seikan ilmi vastauksessa. Moniukielisten tietopohjien Locale-QA tarkistaa lisäksi, ovatko eri versiot sisällöllisesti todella samanarvoisia.

Tuoteversio ja ajallinen voimassaolo

Lähde ei saa vaikuttaa ajantasaiselta vain siksi, että se on indeksoitu viimeisimpänä. Ratkaisevia ovat sisällöllinen versio ja hyväksyntä. Merkitse sisällöt stabiililla tuote-ID:llä, versioalueella, valid_from-, valid_until-arvoilla ja tilalla. Päällekkäisten hyväksyntöjen kohdalla putkiston (pipeline) on ilmoitettava konfliktista sen sijaan, että se laittaisi molemmat tekstit samaan kehotteeseen (prompt). Kuinka indeksointitiheys ja lähteiden ylläpito toimivat yhdessä, kuvaillaan oppaassa tekoäly-chatbotin tietopohjan pitämisestä ajantasaisena.

Asiakkuus ja rooli

Jaetussa indeksissä jokaisen haun on sisällettävä palvelimelta määritetty asiakkuus (tenant) ja voimassa olevat principal-arvot. Puuttuvat ACL-metatiedot tarkoittavat ”ei haettavissa”, ei ”julkinen”. Roolin muuttumisen tai käyttöoikeuden peruuttamisen jälkeen testin on osoitettava, että vanhat istunnot eivät enää saa aiemmin sallittuja lohkoja.

Julkinen tuki ja sisäinen työohje

Sisäinen eskalaatio-ohje voi sopia sisällöllisesti täydellisesti asiakkaan kysymykseen. Se ei tee siitä sallittua lähdettä. Erota julkaisualue ja dokumenttityyppi; merkitse ei-julkaistut sisällöt oletusarvoisesti poissuljetuiksi. Julkisen botin tulisi epäselvässä tilanteessa siirtyä yhteystieto- tai ihmisagenttipolulle sen sijaan, että se arvailisi sisäisiä yksityiskohtia.

Tavallisimmat toteutusvirheet

• Vapaatekstitaksonomia: Arvot kuten de, DE ja de-DE muodostavat tahattomasti kolme eri ryhmää.
• Default-open (oletuksena avoin): Lohkot ilman roolia, tilaa tai asiakkuutta päätyvät jokaiseen hakualueeseen.
• Väärä boolelainen logiikka: OR-operaattori asiakkuuden ja kielen välillä kumoaa ehdottoman rajan käytännössä.
• Dokumentin ja lohkon välinen siirtymä (drift): Uudelleenindeksoinnissa uusia metatietoja ei välitetä kaikille lohkoille.
• Vain positiiviset testit: Tiimi testaa, näkyykö sallittu dokumentti, mutta ei sitä, puuttuuko samanlaiselta kuulostava kielletty dokumentti varmasti.
• Tyhjät osumat mallin ongelmana: Tiukka suodatin ei palauta mitään, ja sovellus antaa mallin jatkaa vastaamista ilman lähteitä.

Suodatin-QA: Testaa rajat, älä vain osumia

Toimiva testijoukko sisältää jokaiselle odotetulle vastaukselle vähintään yhden läheisen vastaehdokkaan: väärä kieli, vanha versio, vanhentunut hyväksyntä, toinen asiakkuus tai sisäinen kohderyhmä. Näin testi osoittaa, erottaako suodatin todella eikä vain sijoita oikeaa osumaa sattumalta ylimmäksi.

Tärkeitä tunnuslukuja ovat alueen rikkomisaste (scope violation rate), saavutettavuus (recall) sallitussa osajoukossa, tyhjien hakujen osuus, tuntemattomien metatietoarvojen määrä, suodatinviive 95. persentiilissä sekä varajärjestelmien ja tarkennuskysymysten osuus. Rajoitetuille sisällöille sallitun alueen rikkomisasteen on oltava nolla. NIST AI RMF Core suosittelee tekoälyjärjestelmien testaamista ennen käyttöönottoa ja säännöllisesti käytön aikana sekä turvallisuus-, luotettavuus- ja kontekstirajojen dokumentointia.

Älä lokita tätä varten tarpeettomia sisältöjä tai täydellisiä käyttäjäkysymyksiä. Yleensä riittävät suodatinversio, abstrakti alue, ehdokkaiden määrä, valitut lähde-ID:t, hylkäyssyy ja jälkitarkistuksen tulos. Näin vianmääritys pysyy mahdollisena ilman toisen tietovuodon rakentamista valvontajärjestelmään (observability).

Käytännön muistilista ennen käyttöönottoa

1. Dokumentoi kanoniset metatietokentät, tietotyypit, sallitut arvot ja omistajat.
2. Erota ehdottomat käyttöoikeusrajat sisällöllisistä valintakentistä.
3. Käsittele puuttuvia turvallisuuden kannalta olennaisia arvoja johdonmukaisesti ei-sallittuina.
4. Rakenna suodattimet tovennetusta palvelinkontekstista ja parametroi syötteet.
5. Lue metatiedot pistokokein takaisin datan sisäänluvun (ingestion) ja lohkotuksen (chunking) jälkeen.
6. Testaa positiiviset, negatiiviset, raja- ja peruuttamistapaukset todellista indeksiä vasten.
7. Mittaa esi-/jälkisuodatuksen käyttäytymistä realistisella k-arvolla ja valikoivilla alueilla.
8. Ohjaa tyhjät tulokset tarkennuskysymykseen, turvalliseen varajärjestelmään tai ihmisagentille.
9. Versioi suodatinmuutokset ja ota ne käyttöön yhdessä haun regressiotestien kanssa.

RAG-metatietosuodattimet ovat siten enemmän kuin haun mukavuusominaisuus. Ne ovat linkki sisältömallin, identiteetin, ajantasaisuuden ja hakulaadun välillä. Se, joka määrittää alueen ensin deterministisesti, antaa järjestämiselle ja kielimallille pienemmän, puhtaamman ja tarkastettavan työpohjan.

Seuraava vaihe: Valitse todellinen tukikysymys ja rakenna sitä varten viisi melko sopivaa vastalähdettä väärästä kielestä, versiosta ja käyttöoikeudesta. Vasta kun mikään niistä ei ylitä sallittua hakualuetta, suodatin pitäisi päästää tuotannolliseen chat-virtaan.

Lähteet

• OpenAI: File Search ja Metadata Filtering
• Microsoft: Suodattimet vektorikyselyissä
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026