Turvaline dokumentide ettevalmistus RAG-i jaoks: PDF-id, OCR, metaandmed ja säilitus

RAG-i tõrked võivad tekkida enne taotlemist: aegunud dokumendid, vahele jäänud tabelid, omanikuta allikad, kadunud õiguste metaandmed, kustutamata vektorid, vastuoluline varjatud tekst või ebakohased failid.

Turvaline dokumentide ettevalmistus on ettevõtte teadmiste allikakontroll. See otsustab, mis otsingusüsteemi siseneb, kes seda näha võib, kuidas värskust jälgitakse, kuidas kustutamine töötab ja kuidas halvad sisendid kinni püütakse.

See artikkel käsitleb dokumentide ettevalmistuskihti: PDF-id, OCR, metaandmed, õigused, säilitus ja operatsioonilised kontrollid.

Kui kasutaja ei tohiks allikasüsteemis dokumendile ligi pääseda, ei tohiks ta RAG-süsteemis ligi pääseda ka selle tekstiplokkidele, embedding’utele, kokkuvõtetele ega vahemällu salvestatud vastustele. Õiguste metaandmed ei ole valikulised.

Dokumendi töötlemisvoog

Tootmise töötlemisvoog peaks sisaldama selgeid etappe:

1. Allika registreerimine.
2. Andmete klassifitseerimine.
3. Failiohutuse kontrollid.
4. Teksti extraktsioon ja OCR.
5. Struktuuri säilitamine.
6. Metaandmete lisamine.
7. Õiguste kaardistamine.
8. Tükeldamine ja embedding.
9. Kvaliteedikontrollid.
10. Indeksi avaldamine.
11. Andmete säilitus ja kustutamine.
12. Operatiivne vastutus.

Täpsed tööriistad võivad erineda. Kontrollpunktid ei tohiks.

Etapp 1: allika registreerimine

Ära too juhuslikke kaustu süsteemi ainult sellepärast, et neid on lihtne ühendada.

Iga allika kohta salvesta:

• allika nimi,
• süsteem, mida loetakse tõeallikaks,
• allika omanik,
• andmete omanik,
• lubatud kasutajad või rollid,
• dokumenditüübid,
• tundlikkuse tase,
• säilitusreegel,
• uuendussagedus,
• kustutamiskäitumine,
• ülevaatuse ajakava.

Näidisallikad:

• avalik abikeskus,
• sisemine kasutajatoe tegevusjuhend,
• müügimaterjalid,
• kliendilepingud,
• HR-poliitikad,
• arenduse käitusjuhendid,
• tootedokumentatsioon,
• koosolekute transkriptsioonid.

Need allikad ei tohiks kõik sattuda samasse indeksisse samade õigustega.

Etapp 2: klassifitseeri andmed enne eraldamist

Klassifitseeri allikas enne, kui mudel või embedding’u pakkuja sisu näeb.

Kasulikud klassid:

Klassifitseerimine ei ole ainult vastavusdokument. See otsustab, kas sisu võib saata majutatud embedding API-le, salvestada jagatud vektorandmebaasi, lisada logidesse või kasutada eval-näidetes.

Etapp 3: failiohutuse kontrollid

Dokumendid võivad olla vaenulikud või lihtsalt katki.

Enne teksti eraldamist:

• kontrolli failitüüpi lubatud nimekirja vastu,
• jõusta failisuuruse piirangud,
• skanni pahavara suhtes seal, kus keskkond seda nõuab,
• lükka krüpteeritud failid tagasi, kui pole heakskiidetud dekrüpteerimisteed,
• lükka tagasi toetamata manustatud objektidega failid,
• normaliseeri failinimed,
• salvesta algse faili hash,
• registreeri, kes faili üles laadis või ühendas.

See on eriti oluline, kui dokumente saavad üles laadida ka mitte-admin kasutajad. Ainult adminidele lubatud sisestus vähendab küll ühte ohtu, kuid ei tee kahjustatud, pahatahtlikku, liiga suurest või vigasest dokumendist ohutut. Ühendaja- ja URL-sisestus vajavad ka lubatud päritolude nimekirja, ümbersuunamise ja DNS-i kontrolli, autentimise ulatuse piiramist, kiiruspiiranguid ning SSRF-testimist.

Kui ebausaldusväärsed kasutajad saavad faile üles laadida, rakenda enne parsimist failiohutuse kiht. Kasuta hooldatavat OWASP File Upload Cheat Sheet’i lähtetasemena ja teosta valitud parserite ning salvestustee suhtes ohtude modelleerimine. Laiema taotlusmudeliga seotud ohtude – sealhulgas mürgituse, õiguste lekete, prompt-injection’i ja ebasõbraliku väljundi – jaoks kasuta ka OWASP RAG Security Cheat Sheet’i.

Kandidaatkontrollid hõlmavad failisisu kinnitatud lubatud tüüpe, suuruse ja arhiivi laiendamise piiranguid, juhuslikke salvestusnimetusi, signatuuripõhist skaneerimist, isoleeritud parsimist ilma väljamineva võrguühenduseta koos ressursside piirangutega ning sisu kahjutustamist ja rekonstrueerimist seal, kus ohtude modelleerimine seda õigustab. Ükski üksik skanner ei taga faili ohutust.

Etapp 4: teksti eraldamine ja OCR

PDF-id ei ole praktikas üks formaat. Mõnes on valitav tekst. Mõned on skaneeringud. Mõnes on veerud, tabelid, joonealused märkused, vormid, kommentaarid, templid või varjatud tekstikihid.

Vali eraldustee dokumenditüübi järgi: võrdle tekstipõhiseid eraldajaid digitaalselt sündinud PDF-ide jaoks, paigutust arvestavaid teisendajaid struktureeritud dokumentide jaoks ning OCR-i skaneeringute jaoks. Tööriistavalik peab lähtuma benchmarkitud paigutuse/tabeli täpsusest, keeletoe kättesaadavusest, litsentsist, parandusprotsessist ja andmete piiridest.

Lävenditest: ära võta universaalset OCR-usalduse piirmäära blogipostitusest — kalibreeri see oma dokumentide valimi peal. Kasulik kuju on kaks vööndit: alumisest vööndist allpool lükatakse lehekülg kohe tagasi; vööndite vahel läheb see inimese ülevaatuse järjekorda; ülemisest vööndist ülalpool liigub edasi. Kus need vööndid asuvad, sõltub sinu skannerist, dokumentide vanusest ja keelest.

Eesti ja segakeelsete arhiivide puhul lisa võrdlusesse diakriitilised tähed, vanemad masinakirjaleheküljed, tabelid, pitserid ja eesti-vene näited. Kontrolli, et valitud OCR-mootoril oleks vajalik keeleandmestik, ning mõõda tähtede, sõnade, väljade ja tabelite täpsust esinduslikel lehekülgedel. Ära luba kindlat piloodi kestust.

Jälgi eralduskvaliteeti:

• eraldusmeetod,
• OCR-i usaldus,
• lehekülgede arv,
• eraldatud märkide arv,
• tabeli eraldamise staatus,
• tuvastatud keel,
• tekstita leheküljed,
• parseri hoiatused.

Madala kvaliteediga eraldus ei tohiks vaikselt indeksisse siseneda. Suuna see ülevaatusele või märgi madala usaldusega allikaks.

Tavalised probleemid:

• veerud loetakse vales järjekorras,
• tabeliread liidetakse valesti,
• päised korduvad igas tekstiplokis,
• skaneeritud leheküljed puuduvad täielikult,
• käsitsi kirjutatud märkmed jäävad tähelepanuta,
• varjatud tekstikiht on nähtava skaneeringuga vastuolus,
• OCR teisendab kontonumbrid valesti.

Väärtuslike dokumentide puhul kontrolli renderdatud lehekülge eraldatud teksti vastu pisteliselt.

Etapp 5: säilita struktuur

RAG-süsteemid vajavad rohkem kui teksti. Neil on vaja piisavalt struktuuri, et anda kasulikke ja allikapõhiseid vastuseid.

Säilita:

• pealkiri,
• pealkirjade rada,
• jaotise number,
• leheküljenumber,
• tabelite pealkirjad,
• loendi piirid,
• dokumendi versioon,
• jõustumiskuupäev,
• allika URL või salvestustee.

Tükelda tekst koos pealkirjade ja leheküljeviidetega. Tekstiplokk, mis ütleb “järgnev kehtib” ilma eelneva pealkirjata, on nõrk tõendus.

Tabelite puhul otsusta, kas:

• hoida tabel Markdownina,
• teisendada see struktureeritud JSON-iks,
• salvestada nii tekst kui struktureeritud read,
• välistada see seni, kuni parem parser on olemas.

Ära teeskle, et tabelite eraldus on lahendatud, kui sinu kasutusjuht sõltub täpsetest hindadest, kuupäevadest, limiitidest või piirmääradest.

Etapp 6: lisa metaandmed

Iga tekstiplokk peaks kandma metaandmeid, mis jäävad otsingus alles:

{
  "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:..."
}

Metaandmed edastavad sisu poliitikajõustamisse; need ei jõusta poliitikat iseseisvalt. Rakendus peab valideerima usaldusväärse metaandmete päritolu ning jõustama õigusi avaldamisel, otsimisel, vahemälu kasutamisel, viitamisel, genereerimisel ja eksportimisel.

Etapp 7: õiguste kaardistamine

Volituste kontroll peab toimuma enne, kui otsingutulemused jõuavad mudelini, ning uuesti igal vastuse, viite, vahemälu või ekspordi piiril, kus identiteet või poliitika on muutunud.

Hea muster:

1. Kasutaja küsib küsimuse.
2. Rakendus tuletab autentimisest tenant’i, kasutaja, rollid, grupid ja andmeõigused.
3. Otsingukiht filtreerib kandidaatsed tekstiplokid õiguste järgi.
4. Järjestamine toimub lubatud tekstiplokkide sees.
5. Mudel saab ainult lubatud tekstiplokid.

Halb muster:

1. Tee otsing laialt.
2. Saada kõik tõenäolised tekstiplokid mudelile.
3. Prompt ütleb “vasta ainult tekstiplokkide põhjal, millele kasutajal võib ligipääs olla.”

Halb muster on andmed juba mudeli konteksti paljastanud.

Kui allikaõigused on keerulised, alusta kitsamalt. Parem on vastusest ilma jääda kui konfidentsiaalne dokument lekkida.

Etapp 8: tükeldamine ja embedding

Tükeldamine on turva- ja kvaliteediotsus, mitte ainult otsingu häälestamine.

Juhised:

• Hoia tekstiplokid õigusepiiride sees.
• Ära ühenda avalikku ja konfidentsiaalset teksti ühte tekstiplokki.
• Lisa pealkirjad ja allikaviited.
• Väldi hiiglaslikke tekstiplokke, mis sisaldavad seosetuid jaotisi.
• Väldi pisikesi tekstiplokke, mis kaotavad konteksti.
• Tee embedding uuesti, kui allikatekst või metaandmed muutuvad.
• Salvesta embedding’u mudel ja versioon.

Tundlike allikate puhul kinnita, kas embedding’u pakkuja, vektorhoidla ja logid on selle andmeklassi jaoks heaks kiidetud.

Etapp 9: kvaliteediväravad

Enne allika avaldamist tootmise otsingu jaoks käivita kontrollid:

• kõigil dokumentidel on omanikud,
• kõigil tekstiplokkidel on õiguste metaandmed,
• aegunud dokumendid on märgistatud,
• ebaõnnestunud eraldusega leheküljed on välistatud või üle vaadatud,
• näidisküsimused leiavad oodatud allikad,
• volitamata kasutajad ei leia ühtegi piiratud tekstiplokki,
• kustutatud dokumendid kaovad otsingust,
• viited osutavad kehtivatele allikakohtadele,
• dokumentides olevad kahtlased juhised isoleeritakse sisuna, mitte ei järgita.

Viimane punkt loeb. Dokumendid võivad sisaldada prompt injection’it. Töövoog ei peaks vaikimisi kogu sellist teksti eemaldama, sest kasutajad peavad teadma, mida dokument sisaldab, ja eemaldamine võib kahjustada tõendeid. Mudel peab hoidma otsitud sisu andmekanalis, takistama sellel tööriistu lubamast või poliitikat muutmast, valideerima tööriista argumentide iseseisvalt ning nõudma inimkinnitust tagajärgede eest.

Etapp 10: avalda indeksi versioon atomiliselt

Ära lase osaliselt töödeldud dokumentidel või vanade ja uute volituste segunemisel lekke aktiivsesse indeksisse. Loo kandidaatindeks või versioonitud nimeruum, siis:

1. külmuta allika/versiooni manifest ja sisu hashid;
2. kontrolli dokumentide arvu, tuletamisvigade arvu, volituste katvust, dubleerimise poliitikat, embedding-mudeli/versiooni ja esinduslikke lubatud/mitteloadud päringuid;
3. salvesta kandidaadi versioon, allikaversioonid, testi tulemus, heakskiitja ja rollbacki sihtkoht;
4. lülita atomiliselt alias või rakenduse viide heaks kiidetud versioonile, kui hoidla seda toetab;
5. kehtetuksusta või uuenda otsingu- ja vastuse vahemälu versioone; ning
6. jälgigu vigu, ligipääsu keeldusid, tühja otsingu tulemusi ja aegunud versiooni liiklust pärast promootimist.

Kui vektorhoidla ei toeta versioonide atomaarset lülitamist, rakenda rakenduse poolel avaldamisolek, mis välistab mittetäielikud kirjed, ning testi edutamise ajal paralleelseid lugejaid. Volituste tühistamine ja allika kiire kustutamine ei tohi oodata täielikku ümberehitust: jõusta kehtivad volitused indeksist eraldi, keela mõjutatud allikas kohe, puhasta asjakohased vahemälud ning lõpeta tuletatud andmete puhastamine elutsükli töövoo kaudu.

Tagasipööramine peab taastama viimase heakskiidetud indeksiviite, taastamata keelatud juurdepääsu või kustutatud andmeid. Kontrolli, et tagasipööramine ei taastaks aegunud juurdepääsuloendit, kustutatud dokumenti, mürgitatud allikat ega aegunud vahemäluvastust.

Etapp 11: säilitus ja kustutamine

RAG-süsteemid hoiavad andmeid sageli kogemata kauem kui allikasüsteem.

GDPRi artikli 17 määratleb õigusele andmete kustutamisele koos tingimuste ja eranditega. Kohaldatava kohustuse ja seadusliku säilitamise peab määrama kvalifitseeritud õigusnõustaja. Süsteem vajab siiski inventari ja elutsükli juhtimist iga koopia ja tuletise jaoks:

• algse faili puhvri,
• eraldatud teksti,
• plokid,
• embeddingud,
• kokkuvõtted,
• pisipildid või renderdatud leheküljed,
• hindamisnäidised,
• logid koos heakskiidetud minimeerimise ja säilituse alusega,
• varukoopiad koos dokumenteeritud aegumise ja taastamise käitumisega.

Kui dokument kustutatakse või ligipääs tühistatakse, peavad otsingu- ja vastuste puhvrid lõpetama selle tagastamise kooskõlas dokumenteeritud sihtajaga. Kustutamise töövoog peab hõlmama tuletatud salvestusi ja takistama vanade varukoopiate või viivitatud sisendtööde poolt kirje taaselustamist.

Jälgi:

• deletedAt,
• deletedBy või allikasündmus,
• kustutamise põhjus,
• järgnevate puhastustööde staatus,
• kontrolli tulemus.

Ära toetu mõttele “eemaldasime selle UI-st”. Vektorhoidlad ja cache’id ununevad kergesti.

Etapp 12: operatiivne vastutus

Igal tootmiskeskkonna allikal peab olema vastutav omanik ja ülevaatuse käivitaja või rütm, mis tuleneb selle muutmise sagedusest ja mõjust.

Iga allika puhul määra:

• kes kiidab dokumendi lisamise heaks,
• kes kiidab õigusemuudatused heaks,
• kes vaatab aegunud dokumendid üle,
• kes tegeleb eraldustõrgetega,
• kes vastab andmete kustutamise taotlustele,
• kes uurib otsingu vigu.

Kui allikal pole omanikku, ei peaks see olema tootmise RAG-süsteemis.

Allikakontroll, mitte garantiid

Turvaline RAG-i dokumentide sisestamine on sihipärane allikakontroll. See teeb otsingu käitumise ja ebaõnnestumised paremini jälgitavad ja testitavad; see ei tee genereeritud vastuseid iseenesest õiged või ohutud.

Põhikontrollid:

• registreeri allikad,
• klassifitseeri andmed,
• kontrolli faile enne parsimist,
• mõõda eralduskvaliteeti,
• säilita struktuur,
• lisa metaandmed,
• jõusta õigused enne otsingut,
• testi volitamata ligipääsu,
• toeta kustutamist,
• määra omanikud.

Allika kvaliteet ja allikakontroll on vastuse kvaliteedi ja ohutuse jaoks vajalikud sisendid, mitte garantiid. Kontrolli otsingu, volituste kontrolli, allikapõhisuse, keeldumise, tööriistade kasutamise ja elutsükli käitumist lõpust lõppu.