Sikker dokumentindlæsning til RAG: PDF'er, OCR, metadata og opbevaringsperioder

RAG-fejl kan opstå før selve søgningen: forældede dokumenter, oversete tabeller, kilder uden ejer, mistede tilladelsesmetadata, vektorer, der ikke er blevet slettet, modstridende skjult tekst eller usikre filer.

Sikker dokumentindlæsning er kildestyring for virksomhedens viden. Den afgør, hvad der kommer ind i søgesystemet, hvem der må se det, hvordan kildernes aktualitet følges, hvordan sletning fungerer, og hvordan dårlige input opdages.

Denne artikel dækker indlæsningslaget: PDF’er, OCR, metadata, tilladelser, opbevaring og driftsmæssig kontrol.

Hvis en bruger ikke må tilgå et dokument i kildesystemet, må vedkommende heller ikke kunne tilgå dokumentets tekststykker, indlejringsvektorer, resuméer eller cachelagrede svar i RAG-systemet. Tilladelsesmetadata er obligatoriske.

Indlæsningspipelinen

En produktionspipeline skal have eksplicitte trin:

1. Registrering af kilder.
2. Klassificering af data.
3. Sikkerhedstjek af filer.
4. Tekstudtrækning og OCR.
5. Bevaring af struktur.
6. Vedhæftning af metadata.
7. Kortlægning af tilladelser.
8. Opdeling i tekststykker og dannelse af indlejringsvektorer.
9. Kvalitetstjek.
10. Publicering af indeks.
11. Håndtering af opbevaring og sletning.
12. Driftsansvar.

De konkrete værktøjer kan variere. Det bør kontrolpunkterne ikke.

Trin 1: kilderegistrering

Indlæs ikke tilfældige mapper blot fordi de er nemme at forbinde.

For hver kilde skal du registrere:

• kildens navn,
• autoritativt kildesystem (system of record),
• kildeejer,
• dataejer,
• tilladte brugere eller roller,
• dokumenttyper,
• følsomhedsniveau,
• opbevaringsregel,
• opdateringsfrekvens,
• sletningsadfærd,
• plan for gennemgang.

Eksempler på kilder:

• offentligt hjælpecenter,
• intern supportmanual,
• salgsmateriale,
• kundekontrakter,
• HR-politikker,
• tekniske driftsvejledninger,
• produktdokumentation,
• mødeudskrifter.

Disse kilder bør ikke alle ende i det samme indeks med de samme tilladelser.

Trin 2: klassificér data før udtrækning

Klassificér kilden, før modellen eller udbyderen af embeddingtjenesten ser indholdet.

Relevante klasser:

Klassificering er ikke blot dokumentation af regelefterlevelse. Den afgør, om indholdet må sendes til en embedding-API hos en ekstern udbyder, gemmes i en fælles vektordatabase, medtages i logfiler eller bruges i evalueringseksempler.

Trin 3: kontrol af filsikkerhed

Dokumenter kan være fjendtlige eller blot ødelagte.

Før udtrækning:

• kontrollér filtypen mod en liste over tilladte typer,
• håndhæv grænser for filstørrelse,
• foretag malwarescanning, hvor dit miljø kræver det,
• afvis krypterede filer, medmindre der findes en godkendt procedure for dekryptering,
• afvis filer med ikke-understøttede indlejrede objekter,
• normaliser filnavne,
• gem den oprindelige fils hashværdi,
• registrér, hvem der overførte eller tilknyttede filen.

Dette er særligt vigtigt, hvis brugere uden administratorrettigheder kan overføre dokumenter. Indlæsning, der er begrænset til administratorer, reducerer én angrebsvej, men gør ikke et kompromitteret, ondsindet, for stort eller forkert udformet dokument sikkert. Indlæsning via forbindelser og URL’er kræver også en liste over tilladte oprindelser, kontrol af omdirigeringer og DNS, korrekt afgrænsning af godkendelsen, hastighedsgrænser og test for SSRF.

Hvis brugere, du ikke har tillid til, kan overføre filer, skal du indføre et filsikkerhedslag før fortolkningen. Brug den vedligeholdte OWASP File Upload Cheat Sheet som udgangspunkt, og trusselsmodellér de valgte fortolkere og lagringsforløbet. Brug også OWASP RAG Security Cheat Sheet til den bredere trusselsmodel for RAG, herunder forgiftning, lækage på tværs af tilladelser, promptinjektion og usikkert output.

Mulige kontroller omfatter tilladte filtyper, der verificeres ud fra filindholdet, grænser for størrelse og udpakning af arkiver, tilfældige lagernavne, signaturscanning, isoleret fortolkning uden udgående netværksadgang og med ressourcegrænser samt afvæbning og rekonstruktion af indhold (CDR), hvor trusselsmodellen begrunder det. Ingen enkelt scanner kan fastslå, at en fil er sikker.

Trin 4: tekstudtrækning og OCR

PDF er i praksis ikke ét enkelt format. Nogle PDF’er indeholder tekst, der kan markeres. Andre består af scannede sider. Nogle har kolonner, tabeller, fodnoter, formularer, kommentarer, stempler eller skjulte tekstlag.

Vælg udtrækningsmetode efter dokumenttypen: sammenlign tekstbaserede udtrækkere til digitalt skabte PDF’er, layoutbevidste konverteringsværktøjer til strukturerede dokumenter og OCR til scanninger. Værktøjsvalget skal baseres på målt nøjagtighed for layout og tabeller, sprogunderstøttelse, licens, opdateringspraksis og den tilladte datagrænse.

Brug ikke en universel tærskel for OCR-konfidens fra et blogindlæg. Kalibrér i stedet på et udsnit af dine egne dokumenter. En brugbar model har to grænser: under den nedre grænse afvises siden; mellem grænserne sendes den til menneskelig gennemgang; over den øvre grænse fortsætter den automatisk. Grænsernes placering afhænger af scanneren, dokumenternes alder og sproget.

Til estiske og flersprogede arkiver skal prøvematerialet omfatte diakritiske tegn, ældre maskinskrevne sider, tabeller, stempler og estisk-russiske eksempler. Kontrollér, at den valgte OCR-motor har de nødvendige sprogdata, og mål derefter nøjagtigheden for tegn, ord, felter og tabeller på repræsentative sider. Lov ikke en fast varighed for pilotfasen.

Spor udtrækningskvalitet:

• udtrækningsmetode,
• OCR-konfidens,
• antal sider,
• antal udtrukne tegn,
• status for tabeludtrækning,
• detekteret sprog,
• sider uden tekst,
• advarsler fra fortolkeren.

Udtrækning af lav kvalitet bør ikke ubemærket ende i indekset. Send den til gennemgang, eller markér den som lav konfidens.

Almindelige problemer:

• kolonner læst i forkert rækkefølge,
• tabelrækker slået sammen forkert,
• sidehoveder gentaget i hvert tekststykke,
• scannede sider mangler helt,
• håndskrevne noter ignoreret,
• et skjult tekstlag, der modsiger den synlige scanning,
• OCR konverterer kontonumre forkert.

For dokumenter af høj værdi skal du kontrollere stikprøver af den gengivne side mod den udtrukne tekst.

Trin 5: bevar strukturen

RAG-systemer har brug for mere end tekst. De har brug for tilstrækkelig struktur til at producere nyttige, kildeforankrede svar.

Bevar:

• titel,
• overskriftssti,
• afsnitnummer,
• sidetal,
• tabeloverskrifter,
• listegrænser,
• dokumentversion,
• ikrafttrædelsesdato,
• kilde-URL eller lagringssti.

Opdel teksten i tekststykker med overskrifter og sidehenvisninger. Et tekststykke, der siger “Det følgende gælder” uden den foregående overskrift, er et svagt kildegrundlag.

For tabeller skal du beslutte, om du vil:

• beholde tabellen som Markdown,
• konvertere den til struktureret JSON,
• gemme både tekst og strukturerede rækker,
• udelade den, indtil en bedre fortolker er tilgængelig.

Påstå ikke, at tabeludtrækning er løst, hvis anvendelsen afhænger af nøjagtige priser, datoer, grænser eller tærskelværdier.

Trin 6: tilføj metadata

Hvert tekststykke skal have metadata, som bevares gennem søgningen:

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

Metadata leverer grundlaget for håndhævelse af regler; de håndhæver ikke reglerne i sig selv. Applikationen skal validere, at metadata stammer fra en betroet kilde, og håndhæve autorisation ved publicering, søgning, cachelagring, kildehenvisning, generering og eksport.

Trin 7: tilladelseskortlægning

Tilladelser skal håndhæves, før søgeresultater når modellen, og igen ved enhver grænse for svar, kildehenvisninger, cache eller eksport, hvor identiteten eller reglerne kan have ændret sig.

Godt mønster:

1. Brugeren stiller et spørgsmål.
2. Applikationen udleder tenant-id, bruger-id, roller, grupper og datarettigheder fra autentificeringen.
3. Søgekomponenten filtrerer mulige tekststykker efter tilladelser.
4. Rangeringen sker kun blandt tilladte tekststykker.
5. Modellen modtager kun tilladte tekststykker.

Dårligt mønster:

1. Søgningen henter bredt.
2. Alle sandsynlige tekststykker sendes til modellen.
3. Prompten siger: “Svar kun ved hjælp af tekststykker, som brugeren må tilgå.”

Det dårlige mønster har allerede eksponeret dataene i modellens kontekst.

Hvis kildens tilladelser er komplekse, skal du begynde med en snævrere adgang. Det er bedre at gå glip af et svar end at lække et fortroligt dokument.

Trin 8: opdeling og indlejringsvektorer

Opdelingen i tekststykker er en sikkerheds- og kvalitetsbeslutning, ikke blot finjustering af søgningen.

Retningslinjer:

• Hold tekststykker inden for adgangsgrænserne.
• Bland ikke offentlig og fortrolig tekst i samme tekststykke.
• Inkluder overskrifter og kildehenvisninger.
• Undgå store tekststykker med afsnit, der ikke hænger sammen.
• Undgå små tekststykker, der mister konteksten.
• Dan indlejringsvektorerne på ny, når kildeteksten eller metadata ændres.
• Gem indlejringsmodellens navn og version.

For følsomme kilder skal du bekræfte, at udbyderen af embeddingtjenesten, vektorlageret og logfilerne er godkendt til den pågældende dataklasse.

Trin 9: kvalitetskontrol

Før en kilde publiceres i produktionssystemets søgeindeks, skal du kontrollere, at:

• alle dokumenter har ejere,
• alle tekststykker har tilladelsesmetadata,
• forældede dokumenter er markeret,
• sider med mislykket udtrækning ekskluderes eller gennemgås,
• stikprøver af spørgsmål returnerer de forventede kilder,
• uautoriserede brugere ikke henter nogen adgangsbegrænsede tekststykker,
• slettede dokumenter forsvinder fra søgningen,
• kildehenvisninger peger på gyldige placeringer i kildematerialet,
• mistænkelige instruktioner i dokumenter isoleres som indhold og ikke følges.

Det sidste punkt er vigtigt. Dokumenter kan indeholde promptinjektion. Indlæsningspipelinen bør ikke ubemærket fjerne al sådan tekst, fordi brugerne kan have behov for at vide, hvad dokumentet siger, og fordi fjernelsen kan beskadige kildegrundlaget. Kørselsmiljøet skal holde det fundne indhold i en datakanal, forhindre det i at give adgang til værktøjer eller ændre regler, validere værktøjsargumenter uafhængigt og kræve menneskelig godkendelse af handlinger med væsentlige konsekvenser.

Trin 10: publicér en indeksversion atomart

Lad ikke delvist indlæste dokumenter eller en blanding af gamle og nye tilladelser sive ind i det aktive indeks. Byg et kandidatindeks eller et versionsopdelt navneområde, og gør derefter følgende:

1. Frys manifestet over kilder og versioner samt indholdets hashværdier.
2. Kontrollér antallet af dokumenter, fejl ved udtrækning, tilladelsesdækning, regler for dubletter, indlejringsmodel og -revision samt repræsentative forespørgsler fra brugere med og uden adgang.
3. Registrér kandidatversionen, kildeversionerne, testresultatet, godkenderen og målet for tilbagerulning.
4. Skift atomart et alias eller en applikationsmarkør til den godkendte version, hvis lageret understøtter det.
5. Ugyldiggør søge- og svarcacher, eller versionsopdel dem.
6. Overvåg fejl, afviste adgangsforsøg, søgninger uden resultater og trafik til forældede versioner efter aktiveringen.

Hvis vektorlageret ikke kan skifte version atomart, skal du indføre en publiceringstilstand i applikationen, som udelukker ufuldstændige poster, og teste samtidige læsere under aktiveringen. Tilbagekaldelse af tilladelser og akut sletning af en kilde må ikke vente på en fuld genopbygning: håndhæv den aktuelle adgangskontrol uden for indekset, afvis straks den berørte kilde, ryd relevante cacher, og fuldfør oprydningen af afledte data gennem livscyklusprocessen.

En tilbagerulning skal gendanne markøren til det senest godkendte indeks uden at genindføre tilbagekaldt adgang eller slettede data. Test, at tilbagerulningen ikke genopliver en erstattet adgangskontrolliste, et slettet dokument, en forgiftet kilde eller et forældet cachelagret svar.

Trin 11: opbevaring og sletning

RAG-systemer holder ofte utilsigtet data længere end kildesystemet.

GDPR, artikel 17 fastlægger en ret til sletning med betingelser og undtagelser. Kvalificeret juridisk rådgivning skal afgøre, hvilke forpligtelser og lovlige opbevaringsperioder der gælder. Systemet har stadig brug for en fortegnelse og en livscyklusproces for hver kopi og hvert afledt datasæt:

• cache med den oprindelige fil,
• udtrukket tekst,
• tekststykker,
• indlejringsvektorer,
• resuméer,
• miniaturebilleder eller gengivne sider,
• evalueringseksempler,
• logfiler med et godkendt grundlag for dataminimering og opbevaring,
• sikkerhedskopier med dokumenteret udløb og gendannelsesadfærd.

Når et dokument slettes, eller adgangen tilbagekaldes, skal søge- og svarcacher ophøre med at returnere det inden for det dokumenterede tidsmål. Sletteprocessen skal omfatte afledte lagre og forhindre, at en gammel sikkerhedskopi eller et forsinket indlæsningsjob genopretter posten.

Spor:

• deletedAt,
• deletedBy eller hændelse fra kildesystemet,
• årsag til sletning,
• status for efterfølgende oprydning,
• kontrolresultat.

Stol ikke på udsagnet “vi fjernede det fra brugerfladen”. Vektorlagre og cacher er nemme at glemme.

Trin 12: driftsansvar

Hver kilde i produktion skal have en ansvarlig ejer samt en hændelse, der udløser gennemgang, eller et fast gennemgangsinterval baseret på kildens ændringsfrekvens og betydning.

For hver kilde skal du definere:

• hvem der godkender optagelsen,
• hvem der godkender tilladelsesændringer,
• hvem der gennemgår forældede dokumenter,
• hvem der håndterer fejl ved udtrækning,
• hvem der besvarer anmodninger om sletning af data,
• hvem der undersøger fejl i søgningen.

Hvis ingen ejer en kilde, bør den ikke indgå i et RAG-system i produktion.

Kildestyring, ikke garantier

Sikker RAG-indlæsning er bevidst kildestyring. Den gør søgeadfærd og fejl lettere at observere og teste; den gør ikke i sig selv de genererede svar korrekte eller sikre.

De centrale styringspunkter:

• registrer kilder,
• klassificér data,
• kontrollér filer før fortolkning,
• mål udtrækningskvaliteten,
• bevar strukturen,
• tilføj metadata,
• håndhæv tilladelser før søgningen,
• test uautoriseret adgang,
• understøt sletning,
• tildel ejere.

Kildekvalitet og kildestyring er nødvendige forudsætninger for svarenes kvalitet og sikkerhed, ikke garantier. Validér søgning, autorisation, kildeforankring, afvisning, værktøjsbrug og livscyklusadfærd fra ende til anden.