Asiakirjojen turvallinen tuonti RAG-järjestelmään: PDF:t, OCR, metatiedot ja säilytys

RAG-järjestelmän virheet voivat alkaa jo ennen hakua: vanhentuneet asiakirjat, huomaamatta jääneet taulukot, vailla omistajaa olevat lähteet, kadonneet käyttöoikeusmetatiedot, poistamattomat vektorit, näkyvän sisällön kanssa ristiriitainen piiloteksti tai turvattomat tiedostot.

Asiakirjojen turvallinen tuonti on yritystiedon lähteiden hallintaa. Siinä ratkaistaan, mitä hakujärjestelmään pääsee, kuka saa nähdä tiedot, miten ajantasaisuutta seurataan, miten poistaminen toimii ja miten haitalliset syötteet havaitaan.

Tässä artikkelissa käsitellään asiakirjojen tuontikerrosta: PDF-tiedostoja, OCR:ää, metatietoja, käyttöoikeuksia, säilytystä ja toiminnan tarkistuksia.

Jos käyttäjällä ei ole oikeutta asiakirjaan lähdejärjestelmässä, hänellä ei saa olla oikeutta myöskään sen tekstikatkelmiin, vektoriesityksiin, tiivistelmiin tai välimuistiin tallennettuihin vastauksiin RAG-järjestelmässä. Käyttöoikeusmetatiedot ovat pakollisia.

Asiakirjojen tuontiputki

Tuotantoputkessa tulisi olla selkeät vaiheet:

1. Lähteen rekisteröinti.
2. Tietojen luokittelu.
3. Tiedoston turvallisuustarkastukset.
4. Tekstin poiminta ja OCR.
5. Rakenteen säilyttäminen.
6. Metatietojen liittäminen.
7. Käyttöoikeuksien kartoitus.
8. Tekstin osittaminen ja vektorointi.
9. Laatutarkastukset.
10. Indeksin julkaisu.
11. Säilytyksen ja poiston käsittely.
12. Ylläpitovastuu.

Työkalut voivat vaihdella. Hallintapisteiden ei pitäisi.

Vaihe 1: lähteen rekisteröinti

Älä syötä satunnaisia kansioita vain siksi, että niiden yhdistäminen on helppoa.

Jokaiselle lähteelle tulee kirjata:

• lähteen nimi,
• virallinen tietolähde,
• lähteen omistaja,
• tietojen omistaja,
• sallitut käyttäjät tai roolit,
• asiakirjatyyppi,
• luottamuksellisuustaso,
• säilytyssääntö,
• päivitystaajuus,
• poistomenettely,
• tarkastusrytmi.

Esimerkkejä lähteistä:

• julkinen tukikeskus,
• sisäinen tukitoiminnan käsikirja,
• myyntimateriaali,
• asiakassopimukset,
• HR-käytännöt,
• tekniset toimintaohjeet,
• tuotedokumentointi,
• kokouslitteroinnit.

Näitä lähteitä ei pidä sijoittaa samaan indeksiin samoilla käyttöoikeuksilla.

Vaihe 2: luokittele tiedot ennen poimintaa

Luokittele lähde ennen kuin malli tai upotuspalveluntarjoaja näkee sisällön.

Hyödyllisiä luokkia:

Luokittelu ei ole vain vaatimustenmukaisuuteen liittyvää paperityötä. Sen perusteella ratkaistaan, voiko sisältöä lähettää isännöityyn vektorointi-APIin, tallentaa jaettuun vektoritietokantaan, sisällyttää lokeihin tai käyttää arviointiesimerkkeinä.

Vaihe 3: tiedostojen turvallisuustarkastukset

Asiakirjat voivat olla haitallisia tai yksinkertaisesti vioittuneita.

Ennen tekstin poimintaa:

• tarkista tiedostotyyppi sallittujen tiedostotyyppien luettelosta,
• aseta tiedostokoon rajat,
• skannaa haittaohjelmia ympäristön vaatiessa,
• hylkää salatut tiedostot, ellei niille ole hyväksyttyä salauksen purkuprosessia,
• hylkää tiedostot, joissa on objekteja, joita järjestelmä ei tue,
• normalisoi tiedostonimet,
• tallenna alkuperäisen tiedoston tiiviste (hash),
• kirjaa, kuka latasi tiedoston tai liitti lähteen.

Tämä on erityisen tärkeää, jos muutkin kuin ylläpitäjät voivat ladata asiakirjoja. Vain ylläpitäjille rajattu tuonti vähentää yhtä uhkareittiä, mutta ei tee vaarantuneesta, haitallisesta, liian suuresta tai viallisesta tiedostosta turvallista. Myös yhdistimistä ja URL-osoitteista tuotaville tiedoille tarvitaan sallittujen alkuperien luettelo, uudelleenohjausten ja DNS:n hallinta, todennuksen tarkka rajaus, nopeusrajoitukset ja SSRF-testaus.

Jos epäluotettavat käyttäjät voivat ladata tiedostoja, toteuta tiedostoturvallisuuskerros ennen jäsentämistä. Käytä ylläpidettyä OWASP File Upload Cheat Sheet lähtökohtana ja laadi uhkamalli valituille jäsentimille ja tallennuspoluille. Laajemman haun uhkamallissa, johon kuuluvat myös myrkytys, käyttöoikeuksien vuoto, kehoteinjektio ja turvaton tuloste, käytä lisäksi OWASP RAG Security Cheat Sheet.

Mahdollisia hallintakeinoja ovat sallittujen tiedostotyyppien varmistaminen tiedoston sisällöstä, tiedosto- ja puretun arkiston kokorajat, satunnaistetut tallennusnimet, allekirjoitusten skannaus, eristetty jäsentäminen ilman ulospääsyä verkkoon ja resurssirajoituksin sekä sisällön puhdistus ja uudelleenrakentaminen uhkamallin sitä vaatiessa. Yksikään skanneri ei yksin osoita tiedostoa turvalliseksi.

Vaihe 4: tekstin poiminta ja OCR

PDF:t eivät ole käytännössä yksi muoto. Jotkut sisältävät valittavissa olevan tekstin. Joissakin on skannauksia. Joissakin on sarakkeita, taulukoita, alaviitteitä, lomakkeita, kommentteja, leimoja tai piilotettuja tekstikerroksia.

Valitse tekstinpoimintapolku asiakirjatyypin mukaan: vertaile tekstipohjaisia poimijoita alun perin digitaalisille PDF-tiedostoille, asettelun huomioivia muuntimia rakenteisille asiakirjoille ja OCR:ää skannatuille sivuille. Työkalu on valittava mitatun asettelu- ja taulukkotarkkuuden, kielituen, lisenssin, tietoturvapäivitysten prosessin ja tietojen käsittelyrajan perusteella.

Älä ota yleispätevää OCR-luottamuksen kynnysarvoa blogikirjoituksesta, vaan kalibroi rajat omista asiakirjoistasi koostuvalla näytteellä. Käytännöllisessä mallissa on kaksi rajaa: alemman rajan alittava sivu hylätään, rajojen väliin jäävä sivu ohjataan ihmisen tarkastettavaksi ja ylemmän rajan ylittävä sivu jatkaa käsittelyyn. Rajat riippuvat skannerista, asiakirjojen iästä ja kielestä.

Viron- ja monikielisissä arkistoissa vertailuaineistoon on sisällytettävä tarkkeet, vanhat konekirjoitetut sivut, taulukot, leimat sekä viron- ja venäjänkieliset esimerkit. Varmista, että valitussa OCR-moottorissa on tarvittavat kieliaineistot, ja mittaa sitten merkki-, sana-, kenttä- ja taulukkotarkkuus edustavilla sivuilla. Älä lupaa yleispätevää pilotin kestoa.

Seuraa poiminnan laatua:

• poimintamenetelmä,
• OCR-varmuusarvio,
• sivumäärä,
• erotettujen merkkien määrä,
• taulukon poiminnan tila,
• havaittu kieli,
• sivut ilman tekstiä,
• jäsenninvaroitukset.

Heikkolaatuinen poimintatulos ei saa päätyä indeksiin huomaamatta. Ohjaa se tarkastukseen tai merkitse sen luotettavuus heikoksi.

Yleisiä ongelmia:

• sarakkeet luettu väärässä järjestyksessä,
• taulukon rivit yhdistetty virheellisesti,
• ylätunnisteet toistuvat jokaisessa tekstikatkelmassa,
• skannatut sivut puuttuvat kokonaan,
• käsinkirjoitetut muistiinpanot ohitettu,
• piilotettu tekstikerros ristiriidassa näkyvän skannauksen kanssa,
• OCR tunnistanut tilinumerot väärin.

Arvokkaista asiakirjoista kannattaa verrata pistokokein renderöityä sivua poimittuun tekstiin.

Vaihe 5: säilytä rakenne

RAG-järjestelmät tarvitsevat enemmän kuin pelkkää tekstiä. Ne tarvitsevat riittävästi rakennetta tuottaakseen hyödyllisiä, lähteisiin perustuvia vastauksia.

Säilytä:

• otsikko,
• otsikkohierarkia,
• osion numero,
• sivunumero,
• taulukon kuvatekstit,
• luetteloiden rajat,
• asiakirjan versio,
• voimassaoloaika,
• lähde-URL tai tallennuspolku.

Jaa teksti katkelmiin niin, että otsikot ja sivuviitteet säilyvät. Katkelma, jossa lukee vain ”Seuraava koskee” ilman edeltävää otsikkoa, on heikko todiste.

Päätä taulukoille, haluatko:

• pitää taulukon Markdown-muodossa,
• muuntaa sen rakenteiseksi JSON-dataksi,
• tallentaa sekä tekstin että rakenteelliset rivit,
• jättää se väliin kunnes parempi jäsentin on saatavilla.

Älä esitä taulukoiden poimintaa ratkaistuna, jos käyttötapauksesi riippuu tarkkoista hinnoista, päivämääristä, rajoista tai kynnyksistä.

Vaihe 6: liitä metatiedot

Jokaisella tekstikatkelmalla on oltava metatiedot, jotka säilyvät mukana hakuprosessissa:

{
  "sourceId": "policy-2026-expenses",
  "documentId": "doc_123",
  "tenantId": "tenant_a",
  "visibility": "internal",
  "allowedRoles": ["finance", "leadership"],
  "sensitivity": "confidential",
  "sourceOwner": "Finance",
  "version": "2026-02",
  "lastReviewedAt": "2026-02-10",
  "effectiveFrom": "2026-03-01",
  "page": 7,
  "headingPath": ["Travel", "Hotel limits"],
  "contentHash": "sha256:..."
}

Metatiedot tarjoavat lähtötiedot käytännön täytäntöönpanoon, mutta ne eivät yksin pane käytäntöä täytäntöön. Sovelluksen on varmistettava metatietojen luotettava alkuperä ja valvottava käyttöoikeuksia julkaisun, haun, välimuistin, lähdeviitteiden, generoinnin ja viennin kaikissa vaiheissa.

Vaihe 7: käyttöoikeuksien kartoitus

Käyttöoikeudet on tarkistettava ennen kuin hakutulokset päätyvät mallille sekä uudelleen jokaisessa vastauksen, lähdeviitteen, välimuistin tai viennin vaiheessa, jossa käyttäjän identiteetti tai käytäntö on voinut muuttua.

Hyvä toimintamalli:

1. Käyttäjä kysyy kysymyksen.
2. Sovellus johtaa todennustiedoista tenantin, käyttäjän, roolit, ryhmät ja tietojen käyttöoikeudet.
3. Hakukomponentti suodattaa ehdokkaiksi nousseet tekstikatkelmat käyttöoikeuksien perusteella.
4. Katkelmat järjestetään vain sallittujen tulosten joukossa.
5. Malli saa vain sallitut katkelmat.

Huono toimintamalli:

1. Haetaan laajasti.
2. Lähetetään kaikki mahdolliset katkelmat mallille.
3. Kehotteessa sanotaan: ”Vastaa vain katkelmilla, joihin käyttäjällä on oikeus.”

Huonossa toimintamallissa tiedot ovat jo paljastuneet mallin kontekstissa.

Jos lähteen käyttöoikeudet ovat monimutkaisia, aloita kapeammalla. On parempi jäädä ilman vastausta kuin vuotaa luottamuksellinen asiakirja.

Vaihe 8: tekstin osittaminen ja vektorointi

Tekstin osittaminen on turvallisuus- ja laatupäätös, ei vain haun säätöä.

Ohjeet:

• Pidä tekstikatkelmat käyttöoikeusrajojen sisällä.
• Älä yhdistä julkista ja luottamuksellista tekstiä samaan katkelmaan.
• Sisällytä otsikot ja lähdeviitteet.
• Vältä valtavia katkelmia, jotka sisältävät toisiinsa liittymättömiä osioita.
• Vältä liian pieniä katkelmia, joista asiayhteys katoaa.
• Muodosta vektoriesitykset uudelleen, kun lähteen teksti tai metatiedot muuttuvat.
• Tallenna vektorointimallin nimi ja versio.

Varmista arkaluonteisista lähteistä, että vektorointipalvelu, vektoritietokanta ja lokit on hyväksytty kyseiselle tietoluokalle.

Vaihe 9: laatuportit

Ennen kuin julkaiset lähteen tuotannon hakuun, aja tarkastukset:

• kaikilla asiakirjoilla on omistajat,
• kaikissa tekstikatkelmissa on käyttöoikeusmetatiedot,
• vanhentuneet asiakirjat on merkitty,
• sivut, joiden tekstinpoiminta epäonnistui, on suljettu pois tai tarkastettu,
• näytekysymykset hakevat odotetut lähteet,
• luvattomat käyttäjät eivät saa haussa yhtään rajoitettua tekstikatkelmaa,
• poistetut asiakirjat häviävät hausta,
• lähdeviitteet osoittavat kelvollisiin lähteen sijainteihin,
• epäilyttävät ohjeet asiakirjoissa on eristetty sisällöksi, ei noudatettu.

Viimeinen kohta on tärkeä. Asiakirjat voivat sisältää kehoteinjektioita. Tuontiputken ei pidä poistaa kaikkea tällaista tekstiä huomaamatta, koska käyttäjän voi olla tarpeen tietää, mitä asiakirjassa lukee, ja poistaminen voi vahingoittaa todistusaineistoa. Ajoympäristön on pidettävä haettu sisältö tietokanavana, estettävä sitä myöntämästä käyttöoikeuksia työkaluihin tai muuttamasta käytäntöä, validoitava työkalujen argumentit erikseen ja vaadittava ihmisen hyväksyntä merkittäviä seurauksia aiheuttaville toimille.

Vaihe 10: julkaise indeksiversio atomisesti

Älä päästä osittain tuotuja asiakirjoja tai vanhojen ja uusien käyttöoikeuksien yhdistelmää aktiiviseen indeksiin. Rakenna ehdokasindeksi tai versioitu nimitila ja tee sitten seuraavat vaiheet:

1. jäädytä lähde- ja versioluettelo sekä sisällön tiivisteet;
2. varmista asiakirjamäärät, poiminnan epäonnistumiset, käyttöoikeuksien kattavuus, kaksoiskappaleita koskeva käytäntö, vektorointimalli ja sen versio sekä edustavat sallittujen ja luvattomien käyttäjien kyselyt;
3. kirjaa ylös ehdokasversio, lähteiden versiot, testitulos, hyväksyjä ja palautuskohde;
4. vaihda atomisesti alias tai sovelluksen osoitin hyväksyttyyn versioon, jos tietokanta tukee sitä;
5. mitätöi tai versioi haku- ja vastausvälimuistit; ja
6. seuraa virheitä, pääsyn eväämisiä, tyhjää hakua ja vanhentuneen version liikennettä käyttöönoton jälkeen.

Jos vektoritietokanta ei voi vaihtaa versioita atomisesti, toteuta sovellukseen julkaisutila, joka sulkee keskeneräiset tietueet pois, ja testaa rinnakkaisia lukijoita julkaisun aikana. Käyttöoikeuksien peruuttaminen ja lähteen kiireellinen poistaminen eivät saa odottaa täydellistä uudelleenrakennusta: valvo ajantasaisia käyttöoikeuksia indeksin ulkopuolella, estä kyseisen lähteen käyttö heti, tyhjennä siihen liittyvät välimuistit ja poista johdannaiset elinkaaren hallintatyönkulussa.

Palautuksen on otettava käyttöön viimeinen hyväksytty indeksiosoitin palauttamatta peruttuja käyttöoikeuksia tai poistettuja tietoja. Testaa, ettei palautus ota uudelleen käyttöön korvattua käyttöoikeusluetteloa, poistettua asiakirjaa, myrkytettyä lähdettä tai vanhentunutta välimuistivastausta.

Vaihe 11: säilytys ja poisto

RAG-järjestelmiin jää tietoja usein vahingossa pidemmäksi aikaa kuin lähdejärjestelmään.

GDPR:n 17 artiklassa säädetään oikeudesta tietojen poistamiseen tietyin ehdoin ja poikkeuksin. Pätevän oikeudellisen asiantuntijan on määritettävä sovellettava velvoite ja mahdollinen lainmukainen säilytys. Järjestelmä tarvitsee silti luettelon ja elinkaaritoiminnot jokaiselle kopiolle ja johdannaiselle:

• alkuperäisen tiedoston välimuisti,
• erotettu teksti,
• tekstikatkelmat,
• vektoriesitykset,
• tiivistelmät,
• pikkukuvat tai renderöidyt sivut,
• arviointinäytteet,
• lokit, joiden minimoinnille ja säilytykselle on hyväksytty peruste,
• varmuuskopiot, joiden vanheneminen ja palautustapa on dokumentoitu.

Kun asiakirja poistetaan tai sen käyttöoikeus perutaan, haun ja vastausvälimuistin on lopetettava sen palauttaminen dokumentoidun tavoiteajan kuluessa. Poistotyönkulun on katettava johdannaistallenteet ja estettävä vanhaa varmuuskopiota tai viivästynyttä tuontityötä palauttamasta tietuetta järjestelmään.

Seuraa:

• deletedAt,
• deletedBy tai lähdetapahtuma,
• poiston syy,
• jatkojärjestelmien siivouksen tila,
• vahvistustulos.

Älä luota “poistimme sen käyttöliittymästä.” Vektoritietokannat ja välimuistit on helppo unohtaa.

Vaihe 12: ylläpitovastuu

Jokaisella tuotantolähteellä on oltava vastuullinen omistaja sekä muutosten ja vaikutusten perusteella määritetty tarkastuksen käynnistävä ehto tai tarkastusrytmi.

Määrittele jokaiselle lähteelle:

• kuka hyväksyy syötön,
• kuka hyväksyy käyttöoikeusmuutokset,
• kuka tarkastaa vanhentuneet asiakirjat,
• kuka käsittelee tekstinpoiminnan epäonnistumiset,
• kuka vastaa tietojen poistopyynnöistä,
• kuka tutkii hakuvirheet.

Jos lähteellä ei ole vastuuhenkilöä, se ei kuulu tuotannon RAG-järjestelmään.

Lähdehallintaa, ei takuita

Turvallinen RAG-aineiston tuonti on harkittua lähdehallintaa. Se tekee haun toiminnasta ja virheistä paremmin havaittavia ja testattavia, mutta ei tee tuotetuista vastauksista automaattisesti oikeita tai turvallisia.

Keskeiset hallintakeinot:

• rekisteröi lähteet,
• luokittele tiedot,
• tarkasta tiedostot ennen jäsentämistä,
• mittaa poiminnan laatu,
• säilytä rakenne,
• liitä metatiedot,
• pane käyttöoikeudet täytäntöön ennen hakua,
• testaa luvaton pääsy,
• tue poistoa,
• määritä omistajat.

Lähteiden laatu ja hallintakeinot ovat vastauksen laadun ja turvallisuuden välttämättömiä lähtökohtia, mutta ne eivät takaa kumpaakaan. Validoi haku, valtuutus, lähteisiin ankkurointi, kieltäytyminen, työkalujen käyttö ja elinkaaren toiminta päästä päähän.