Turvallinen asiakirjojen ingestointi RAG:lle: PDF:t, OCR, metatiedot ja säilytys

Useimmat RAG-epäonnistumiset alkavat ennen hakua. Asiakirja oli vanhentunut. OCR ohitti taulukon. Lähteellä ei ollut omistajaa. Käyttöoikeusmetatiedot katosivat. Poistettu sopimus jäi vektorivarastoon. Skannatussa PDF:ssä oli piilotettua tekstiä, jota kukaan ei katselmoinut. Järjestelmä vastasi itsevarmasti, koska ingestointiputki käsitteli ”tekstiä on olemassa” -tilan kuin ”tietämys on turvallista käyttää”.

Turvallinen asiakirjojen ingestointi on yrityksen tietämyksen lähdehallintaa. Se päättää, mitä hakujärjestelmään tulee, kuka saa nähdä sen, miten tuoreutta seurataan, miten poisto toimii ja miten huonot syötteet tarttuvat.

Tämä artikkeli kattaa ingestointikerroksen: PDF:t, OCR, metatiedot, käyttöoikeudet, säilytys ja operatiiviset tarkistukset.

Jos käyttäjän ei pitäisi käyttää asiakirjaa lähdejärjestelmässä, hänen ei pitäisi käyttää sen paloja, upotuksia, tiivistelmiä tai välimuistiin tallennettuja vastauksia RAG-järjestelmässä. Käyttöoikeusmetatiedot eivät ole valinnaisia.

Ingestointiputki

Tuotantoputkessa pitäisi olla eksplisiittiset vaiheet:

1. Lähteen rekisteröinti.
2. Datan luokittelu.
3. Tiedoston turvallisuustarkistukset.
4. Tekstin poiminta ja OCR.
5. Rakenteen säilyttäminen.
6. Metatietojen liittäminen.
7. Käyttöoikeuksien kartoitus.
8. Pilkkominen ja upottaminen.
9. Laatutarkistukset.
10. Indeksin julkaisu.
11. Säilytys ja poiston käsittely.

Tarkat työkalut voivat vaihdella. Kontrollipisteiden ei pitäisi.

Vaihe 1: lähteen rekisteröinti

Älä ingestoi satunnaisia kansioita siksi, että ne on helppo yhdistää.

Kullekin lähteelle tallenna:

• lähteen nimi,
• tietolähdejärjestelmä,
• lähteen omistaja,
• datan omistaja,
• sallitut käyttäjät tai roolit,
• asiakirjatyypit,
• herkkyystaso,
• säilytyssääntö,
• päivitystiheys,
• poistokäyttäytyminen,
• katselmointiaikataulu.

Esimerkkilähteitä:

• julkinen tukikeskus,
• sisäinen tuen playbook,
• myynnin materiaalit,
• asiakassopimukset,
• HR-politiikat,
• kehityksen runbookit,
• tuotedokumentaatio,
• kokousten litteraatit.

Näiden lähteiden ei pitäisi kaikki päätyä samaan indeksiin samoilla käyttöoikeuksilla.

Vaihe 2: luokittele data ennen poimintaa

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

Hyödyllisiä luokkia:

Luokittelu ei ole vain vaatimustenmukaisuuden paperityötä. Se päättää, voidaanko sisältö lähettää hostattuun upotus-API:in, tallentaa jaettuun vektoritietokantaan, sisällyttää lokeihin tai käyttää arviointiesimerkkeihin.

Vaihe 3: tiedoston turvallisuustarkistukset

Asiakirjat voivat olla vihamielisiä tai yksinkertaisesti rikkinäisiä.

Ennen poimintaa:

• tarkista tiedostotyyppi sallittujen listaa vasten,
• aseta tiedostokoon rajat,
• skannaa haittaohjelmien varalta, kun ympäristösi sitä edellyttää,
• hylkää salatut tiedostot, ellei ole hyväksyttyä salauksenpurkupolkua,
• hylkää tiedostot, joissa on tukemattomia upotettuja objekteja,
• normalisoi tiedostonimet,
• tallenna alkuperäisen tiedoston tiiviste,
• kirjaa, kuka latasi tai yhdisti tiedoston.

Tämä on erityisen tärkeää, jos muut kuin ylläpitäjät voivat ladata asiakirjoja. Vain ylläpitäjien ingestointi vähentää riskiä, mutta ei poista sitä.

Antivirus- ja content-disarm-kontrollit eivät ole automaattisia useimmissa RAG-pinoissa. Jos epäluotettavat käyttäjät voivat ladata tiedostoja, lisää todellinen tiedostoturvakerros ennen jäsennystä.

Miltä kerros näyttää käytännössä, kasvavan varovaisuuden järjestyksessä: allekirjoitusskanneri (ClamAV-luokka) minimitasoksi; jäsennys eristetyssä, ilman ulospääsyä olevassa kontissa — PDF- ja office-muotojen jäsentimillä on pitkä CVE-historia, joten käsittele itse jäsennintä hyökkäyspintana; ja aidosti epäluotettavalle vastaanotolle content disarm and reconstruction (CDR), joka rakentaa tiedostosta puhtaan kopion alkuperäiseen luottamisen sijaan. Useimmat pk-yritysten putket tarvitsevat kaksi ensimmäistä; lisää CDR, kun ulkopuoliset voivat lähettää asiakirjoja.

Vaihe 4: tekstin poiminta ja OCR

PDF:t eivät ole käytännössä yksi muoto. Joissakin on valittavaa tekstiä. Jotkin ovat skannauksia. Joissakin on palstoja, taulukoita, alaviitteitä, lomakkeita, kommentteja, leimoja tai piilotettuja tekstikerroksia.

Valitse poimintapolku asiakirjatyypin mukaan: tekstipainotteinen poimija digitaalisesti syntyneille PDF:ille (PyMuPDF- tai pdfplumber-luokka), asettelua ymmärtävä muunnin rakenteisille asiakirjoille (Docling- tai Unstructured-luokka — taulukot ja lukujärjestys säilyvät huomattavasti paremmin) ja OCR vain aidoille skannauksille (Tesseract itsehostattuna lähtötasona; pilvi-OCR-palvelu, kun skannauksen laatu on heikko ja datan luokittelu sen sallii).

Kynnysarvoista: älä omaksu yleistä OCR-luottamuksen rajaa blogikirjoituksesta — kalibroi omien asiakirjojesi otoksella. Hyödyllinen muoto on kaksi kaistaa: alemman kaistan alle sivu hylätään suoraan; kaistojen välillä se jonotetaan ihmisen katselmointiin; ylemmän kaistan yli se etenee. Missä kaistat sijaitsevat, riippuu skanneristasi, asiakirjojesi iästä ja kielestäsi.

Omaamme markkinaan liittyvä huomio: vironkielinen OCR on vaikeampaa kuin englanninkielinen. Tesseract toimittaa vironkielisen mallin, mutta tarkkuus õ/ä/ö/ü-merkeissä, vanhemmissa konekirjoitetuissa arkistoissa ja seka-viro–venäjä-asiakirjoissa vaihtelee niin paljon, että sinun pitäisi ajaa pilottivertailu edustavalla otoksella omasta arkistostasi ennen moottoriin sitoutumista. Virolaisyrityksille tämä pilotti on puolen päivän työ, joka säästää myöhemmin neljänneksen hiljaisista hakuepäonnistumisista.

Seuraa poiminnan laatua:

• poimintamenetelmä,
• OCR-luottamus,
• sivumäärä,
• poimittujen merkkien määrä,
• taulukon poiminnan tila,
• tunnistettu kieli,
• sivut ilman tekstiä,
• jäsentimen varoitukset.

Heikkolaatuisen poiminnan ei pitäisi hiljaa päästä indeksiin. Ohjaa se katselmointiin tai merkitse se matalaksi luottamukseksi.

Yleisiä ongelmia:

• palstat luetaan väärässä järjestyksessä,
• taulukon rivit yhdistetään väärin,
• yläotsikot toistuvat jokaisessa palassa,
• skannatut sivut puuttuvat kokonaan,
• käsinkirjoitetut muistiinpanot ohitetaan,
• piilotettu tekstikerros on ristiriidassa näkyvän skannauksen kanssa,
• OCR muuntaa tilinumerot väärin.

Korkean arvon asiakirjoille vertaa renderöityä sivua poimittuun tekstiin pistokokein.

Vaihe 5: säilytä rakenne

RAG-järjestelmät tarvitsevat enemmän kuin tekstiä. Ne tarvitsevat riittävästi rakennetta hyödyllisten, lähteisiin perustuvien vastausten tuottamiseen.

Säilytä:

• otsikko,
• otsikkopolku,
• osion numero,
• sivunumero,
• taulukoiden kuvatekstit,
• listojen rajat,
• asiakirjan versio,
• voimaantulopäivä,
• lähde-URL tai tallennuspolku.

Pilko teksti otsikoilla ja sivuviittauksilla. Pala, joka sanoo ”Seuraava pätee” ilman edeltävää otsikkoa, on heikkoa näyttöä.

Taulukoille päätä, joko:

• säilytät taulukon Markdownina,
• muunnat sen rakenteiseksi JSON:iksi,
• tallennat sekä tekstin että rakenteiset rivit,
• jätät sen pois, kunnes parempi jäsennin on käytettävissä.

Älä teeskentele, että taulukon poiminta on ratkaistu, jos käyttötapauksesi riippuu tarkoista hinnoista, päivämääristä, rajoista tai kynnysarvoista.

Vaihe 6: liitä metatiedot

Jokaisen palan pitäisi kantaa metatietoja, jotka selviävät hausta:

{
  "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 ovat tapa, jolla sovellus valvoo käytäntöä haun jälkeen. Ilman niitä malli vastaanottaa tekstiä irrotettuna säännöistä, jotka tekevät sen käytöstä turvallista.

Vaihe 7: käyttöoikeuksien kartoitus

Käyttöoikeuksien kartoituksen on tapahduttava ennen kuin hakutulokset saavuttavat mallin.

Hyvä malli:

1. Käyttäjä esittää kysymyksen.
2. Sovellus johtaa tenantin, käyttäjän, roolit, ryhmät ja dataoikeudet autentikoinnista.
3. Haku suodattaa ehdokaspalat käyttöoikeuksien mukaan.
4. Järjestäminen tapahtuu sallittujen palojen sisällä.
5. Malli vastaanottaa vain sallitut palat.

Huono malli:

1. Hae laajasti.
2. Lähetä kaikki todennäköiset palat mallille.
3. Kehote sanoo ”vastaa vain paloilla, joihin käyttäjällä on pääsy”.

Huono malli on jo altistanut datan mallin kontekstille.

Jos lähteen käyttöoikeudet ovat monimutkaisia, aloita kapeammin. On parempi ohittaa vastaus kuin vuotaa luottamuksellinen asiakirja.

Vaihe 8: pilkkominen ja upottaminen

Pilkkominen on tietoturva- ja laatupäätös, ei vain haun säätöpäätös.

Ohjeita:

• Pidä palat käyttöoikeusrajojen sisällä.
• Älä yhdistä julkista ja luottamuksellista tekstiä yhteen palaan.
• Sisällytä otsikot ja lähdeviittaukset.
• Vältä jättipaloja, jotka sisältävät liittymättömiä osioita.
• Vältä pikkupaloja, jotka menettävät kontekstin.
• Upota uudelleen, kun lähdeteksti tai metatiedot muuttuvat.
• Tallenna upotusmalli ja versio.

Arkaluonteisille lähteille varmista, onko upotuspalvelusi, vektorivarastosi ja lokisi hyväksytty kyseiselle dataluokalle.

Vaihe 9: laatuportit

Ennen lähteen julkaisua tuotantohakuun aja tarkistuksia:

• kaikilla asiakirjoilla on omistajat,
• kaikilla paloilla on käyttöoikeusmetatiedot,
• vanhentuneet asiakirjat on merkitty,
• epäonnistuneen poiminnan sivut on jätetty pois tai katselmoitu,
• esimerkkikysymykset hakevat odotettuja lähteitä,
• luvattomat käyttäjät hakevat nolla rajoitettua palaa,
• poistetut asiakirjat katoavat hausta,
• viittaukset osoittavat kelvollisiin lähdesijainteihin,
• asiakirjojen epäilyttävät ohjeet eristetään sisällöksi, ei noudateta.

Viimeinen kohta merkitsee. Asiakirjat voivat sisältää kehoteinjektiota. Ingestointiputken ei pitäisi poistaa kaikkea tällaista tekstiä, koska joskus käyttäjien on tiedettävä, mitä asiakirja sanoo. Mutta ajon aikana se on käsiteltävä epäluotettavana asiakirjasisältönä.

Vaihe 10: säilytys ja poisto (GDPR:n artikla 17 elää täällä)

RAG-järjestelmät pitävät dataa vahingossa usein pidempään kuin lähdejärjestelmä.

Tässä vaiheessa GDPR:n oikeus tulla unohdetuksi (artikla 17) muuttuu suunnitteluvaatimukseksi politiikkalauseen sijaan: kun poistopyyntö saapuu, ”poistimme lähdetiedoston” ei ole puolustettava vastaus, jos kopioita säilyy putken muualla. Poiston on katettava:

• alkuperäisen tiedoston välimuisti,
• poimittu teksti,
• palat,
• upotukset,
• tiivistelmät,
• pikkukuvat tai renderöidyt sivut,
• arviointiotokset,
• lokit, kun laki edellyttää,
• varmuuskopiot käytännön mukaan.

Kun asiakirja poistetaan tai pääsy peruutetaan, haun pitäisi lakata palauttamasta sen paloja. Ihanteellisesti järjestelmän pitäisi tukea kovaa poistoa arkaluonteisille lähteille ja dokumentoitua säilytystä varmuuskopioille.

Seuraa:

• deletedAt,
• deletedBy tai lähdetapahtuma,
• poiston syy,
• alavirran siivouksen tila,
• varmennuksen tulos.

Älä luota siihen, että ”poistimme sen käyttöliittymästä”. Vektorivarastot ja välimuistit on helppo unohtaa.

Vaihe 11: operatiivinen omistajuus

Jokainen lähde tarvitsee omistajan. Jokainen omistaja tarvitsee katselmointirytmin.

Kullekin lähteelle määritä:

• kuka hyväksyy ingestoinnin,
• kuka hyväksyy käyttöoikeusmuutokset,
• kuka katselmoi vanhentuneet asiakirjat,
• kuka käsittelee poimintavirheet,
• kuka vastaa datan poistopyyntöihin,
• kuka tutkii hakivirheet.

Jos kukaan ei omista lähdettä, sen ei pitäisi olla tuotannon RAG-järjestelmässä.

Yhteenveto

Turvallinen RAG-ingestointi on tylsää parhaalla tavalla. Se tekee hausta ennustettavaa.

Keskeiset kontrollit:

• rekisteröi lähteet,
• luokittele data,
• tarkista tiedostot ennen jäsennystä,
• mittaa poiminnan laatu,
• säilytä rakenne,
• liitä metatiedot,
• valvo käyttöoikeuksia ennen hakua,
• testaa luvaton pääsy,
• tue poistoa,
• määritä omistajat.

Hyvät vastaukset tulevat hyvistä lähteistä. Turvalliset vastaukset tulevat hyvästä lähdehallinnasta.