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

Enamik RAG-i tõrkeid algab enne retrieval'it. 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 ingestion-pipeline käsitles põhimõtet "tekst on olemas" kui "teadmist on ohutu kasutada".

Turvaline dokumentide ingestion on ettevõtte teadmiste allikakontroll. See otsustab, mis retrieval-sü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 ingestion-kihti: 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 chunk'idele, embedding'utele, kokkuvõtetele ega vahemällu salvestatud vastustele. Õiguste metaandmed ei ole valikulised.

Ingestion-pipeline

Tootmise pipeline'il peaksid olema selged etapid:

1. Allika registreerimine.
2. Andmete klassifitseerimine.
3. Failiohutuse kontrollid.
4. Teksti eraldamine ja OCR.
5. Struktuuri säilitamine.
6. Metaandmete lisamine.
7. Õiguste kaardistamine.
8. Chunk'imine ja embedding.
9. Kvaliteedikontrollid.
10. Indeksi avaldamine.
11. Säilitus ja kustutamiskäitumine.

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

Etapp 1: allika registreerimine

Ära ingest'i juhuslikke kaustu ainult sellepärast, et neid on lihtne ühendada.

Iga allika kohta salvesta:

• allika nimi,
• system of record,
• 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 retrieval'ile | | Sisemine | playbook'id, protsessidokumendid | Ainult ettevõttes, rollifiltriga | | Konfidentsiaalne | lepingud, kliendiandmed, finants | Piiratud rollid, tugevam logimine | | Reguleeritud/tundlik | tervis, õigus, HR, palgaarvestus, turvaintsidendid | Väldi, kui pole selgelt heaks kiidetud |

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 ingestion 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 chunk'is,
• 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.

Chunk'i tekst koos pealkirjade ja leheküljeviidetega. Chunk, 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 chunk peaks kandma metaandmeid, mis jäävad retrieval'is 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 retrieval'it. Ilma nendeta saab mudel teksti, mis on lahutatud reeglitest, mis muudavad selle kasutamise ohutuks.

Etapp 7: õiguste kaardistamine

Õiguste kaardistamine peab toimuma enne, kui retrieval'i tulemused mudelini jõuavad.

Hea muster:

1. Kasutaja küsib küsimuse.
2. Rakendus tuletab autentimisest tenant'i, kasutaja, rollid, grupid ja andmeõigused.
3. Retriever filtreerib kandidaatsed chunk'id õiguste järgi.
4. Ranking toimub lubatud chunk'ide sees.
5. Mudel saab ainult lubatud chunk'id.

Halb muster:

1. Tee retrieval laialt.
2. Saada kõik tõenäolised chunk'id mudelile.
3. Prompt ütleb "vasta ainult chunk'ide 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: chunk'imine ja embedding

Chunk'imine on turva- ja kvaliteediotsus, mitte ainult otsingu häälestamine.

Juhised:

• Hoia chunk'id õigusepiiride sees.
• Ära ühenda avalikku ja konfidentsiaalset teksti ühte chunk'i.
• Lisa pealkirjad ja allikaviited.
• Väldi hiiglaslikke chunk'e, mis sisaldavad seosetuid jaotisi.
• Väldi pisikesi chunk'e, 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 retrieval'i jaoks käivita kontrollid:

• kõigil dokumentidel on omanikud,
• kõigil chunk'idel 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 chunk'i,
• 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. Ingestion-pipeline ei peaks kogu sellist teksti eemaldama, sest mõnikord peab kasutaja teadma, mida dokument ütleb. Kuid runtime 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,
• chunk'id,
• 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 retrieval lõpetama selle chunk'ide tagastamise. Ideaalis peaks süsteem toetama tundlike allikate hard deletion'it ja dokumenteeritud säilitust varukoopiate jaoks.

Jälgi:

• deletedAt,
• deletedBy või allikasündmus,
• kustutamise põhjus,
• downstream cleanup'i 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 ingestion'i heaks,
• kes kiidab õigusemuudatused heaks,
• kes vaatab aegunud dokumendid üle,
• kes tegeleb eraldustõrgetega,
• kes vastab andmete kustutamise taotlustele,
• kes uurib retrieval'i vigu.

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

Kokkuvõte

Turvaline RAG ingestion on parimas mõttes igav. See teeb retrieval'i ennustatavaks.

Põhikontrollid:

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

Head vastused tulevad headest allikatest. Ohutud vastused tulevad heast allikakontrollist.