Enamik RAG-i tõrkeid algab enne otsingut. Dokument oli aegunud. OCR jättis tabeli vahele. Allikal puudus omanik. Õiguste metaandmed kadusid. Kustutatud leping jäi vektorhoidlasse. Skaneeritud PDF-il oli varjatud tekstikiht, mida keegi ei üle vaadanud. Süsteem vastas enesekindlalt, sest dokumentide töötlemisvoog käsitles põhimõtet "tekst on olemas" kui "teadmist on ohutu kasutada".
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:
- Allika registreerimine.
- Andmete klassifitseerimine.
- Failiohutuse kontrollid.
- Teksti eraldamine ja OCR.
- Struktuuri säilitamine.
- Metaandmete lisamine.
- Õiguste kaardistamine.
- Tükeldamine ja embedding.
- Kvaliteedikontrollid.
- Indeksi avaldamine.
- Säilitus ja kustutamiskäitumine.
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 playbook,
- müügimaterjalid,
- kliendilepingud,
- HR-poliitikad,
- arenduse runbook'id,
- 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:
Klass | Näide | Vaikehoiak |
|---|---|---|
Avalik | avaldatud dokumendid, turunduslehed | Lubatud laiale otsingule |
Sisemine | playbook'id, protsessidokumendid | Ainult ettevõttes, rollifiltriga |
Konfidentsiaalne | lepingud, kliendiandmed, finants | Piiratud rollid, tugevam logimine |
Reguleeritud/tundlik | tervis, õigus, HR, palgaarvestus, turvaintsidendid |
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 mitte-admin kasutajad. Ainult adminidele lubatud dokumentide lisamine vähendab riski, kuid ei eemalda seda.
Viirusetõrje ja content-disarm kontrollid ei ole enamikus RAG-stack'ides automaatsed. Kui mitteusaldusväärsed kasutajad saavad faile üles laadida, lisa enne parsimist päris failiohutuse kiht.
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.
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 on viis, kuidas rakendus jõustab poliitikat pärast otsingut. Ilma nendeta saab mudel teksti, mis on lahutatud reeglitest, mis muudavad selle kasutamise ohutuks.
Etapp 7: õiguste kaardistamine
Õiguste kaardistamine peab toimuma enne, kui otsingutulemused mudelini jõuavad.
Hea muster:
- Kasutaja küsib küsimuse.
- Rakendus tuletab autentimisest tenant'i, kasutaja, rollid, grupid ja andmeõigused.
- Otsingukiht filtreerib kandidaatsed tekstiplokid õiguste järgi.
- Järjestamine toimub lubatud tekstiplokkide sees.
- Mudel saab ainult lubatud tekstiplokid.
Halb muster:
- Tee otsing laialt.
- Saada kõik tõenäolised tekstiplokid mudelile.
- 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. Dokumentide töötlemisvoog ei peaks kogu sellist teksti eemaldama, sest mõnikord peab kasutaja teadma, mida dokument ütleb. Kuid käitusaegne süsteem peab käsitlema seda mitteusaldusväärse dokumendisisuna.
Etapp 10: säilitus ja kustutamine
RAG-süsteemid hoiavad andmeid sageli kogemata kauem kui allikasüsteem.
Kustutamine peab katma:
- algse faili cache,
- eraldatud teksti,
- tekstiplokid,
- embedding'ud,
- kokkuvõtted,
- pisipildid või renderdatud leheküljed,
- eval-näidised,
- logid seal, kus seadus seda nõuab,
- varukoopiad vastavalt poliitikale.
Kui dokument kustutatakse või ligipääs tühistatakse, peab otsing lõpetama selle tekstiplokkide tagastamise. Ideaalis peaks süsteem toetama tundlike allikate lõplikku kustutamist ja dokumenteeritud säilitust varukoopiate jaoks.
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 11: operatsiooniline omaniklus
Iga allikas vajab omanikku. Iga omanik vajab ülevaatuse rütmi.
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.
Kokkuvõte
Turvaline RAG-i dokumendiettevalmistus on parimas mõttes igav. See teeb otsingu ennustatavaks.
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.
Head vastused tulevad headest allikatest. Ohutud vastused tulevad heast allikakontrollist.
