Sikker dokumentingestion til RAG: PDF'er, OCR, metadata og opbevaring

De fleste RAG-fejl begynder før hentningen. Dokumentet var forældet. OCR-processen overså en tabel. Kilden havde ingen ejer. Tilladelsesmetadata gik tabt. En slettet kontrakt blev liggende i vektorlageret. En scannet PDF havde et skjult tekstlag, som ingen havde gennemgået. Systemet svarede med stor sikkerhed, fordi ingestion-pipelinen behandlede »der findes tekst« som »denne viden er sikker at anvende«.

Sikker dokumentingestion er kildekontrol for virksomhedsviden. Den afgør, hvad der kommer ind i hentningssystemet, hvem der må se det, hvordan aktualiteten følges, hvordan sletning fungerer, og hvordan dårlige input opdages.

Denne artikel gennemgår ingestion-laget: PDF’er, OCR, metadata, tilladelser, opbevaring og operationelle kontroller.

Hvis en bruger ikke må få adgang til et dokument i kildesystemet, må brugeren heller ikke få adgang til dokumentets chunks, embeddings, opsummeringer eller cachelagrede svar i RAG-systemet. Tilladelsesmetadata er obligatoriske.

Ingestion-pipelinen

En produktionspipeline skal have eksplicitte faser:

1. Registrering af kilder.
2. Dataklassificering.
3. Kontrol af filsikkerhed.
4. Tekstudtræk og OCR.
5. Bevarelse af struktur.
6. Tilføjelse af metadata.
7. Kortlægning af tilladelser.
8. Chunking og embedding.
9. Kvalitetskontrol.
10. Publicering i indeks.
11. Håndtering af opbevaring og sletning.

De konkrete værktøjer kan variere. Kontrolpunkterne må ikke.

Fase 1: registrering af kilder

Indlæs ikke vilkårlige mapper, blot fordi de er lette at forbinde.

Registrer følgende for hver kilde:

• kildens navn,
• det autoritative system,
• kildens ejer,
• dataejer,
• tilladte brugere eller roller,
• dokumenttyper,
• følsomhedsniveau,
• opbevaringsregel,
• opdateringsfrekvens,
• sletteadfærd,
• reviewplan.

Eksempler på kilder:

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

Kilderne bør ikke alle placeres i det samme indeks med de samme tilladelser.

Fase 2: klassificer data før udtræk

Klassificer kilden, før modellen eller embeddingleverandøren ser indholdet.

Nyttige klasser:

Klassificering er ikke blot administrativ regelefterlevelse. Den afgør, om indhold må sendes til et hostet embedding-API, lagres i en delt vektordatabase, indgå i logfiler eller anvendes som eksempler i evalueringer.

Fase 3: kontrol af filsikkerhed

Dokumenter kan være fjendtlige eller blot defekte.

Før udtræk:

• kontroller filtypen mod en positivliste,
• håndhæv grænser for filstørrelse,
• scan for malware, hvor miljøet kræver det,
• afvis krypterede filer, medmindre der findes en godkendt dekrypteringsvej,
• afvis filer med ikke-understøttede indlejrede objekter,
• normaliser filnavne,
• gem hashværdien for den oprindelige fil,
• registrer, hvem der uploadede eller tilknyttede filen.

Det er især vigtigt, hvis brugere uden administratorrettigheder kan uploade dokumenter. Ingestion kun for administratorer reducerer risikoen, men fjerner den ikke.

Antivirus og mekanismer til at uskadeliggøre indhold er ikke automatisk indbygget i de fleste RAG-stacks. Hvis brugere, der ikke er tillid til, kan uploade filer, skal I tilføje et reelt filsikkerhedslag før parsing.

I praksis kan laget se sådan ud, med stigende forsigtighed: Som minimum en signaturbaseret scanner i ClamAV-klassen; parsing i en isoleret container uden udgående netværksadgang — parsere til PDF- og Office-formater har en lang historik med CVE’er, så betragt selve parseren som en angrebsflade; og ved reelt utroværdig ingestion content disarm and reconstruction (CDR), som opbygger en ren kopi af filen i stedet for at stole på originalen. De fleste SMV-pipelines har brug for de to første. Tilføj CDR, når eksterne parter kan indsende dokumenter.

Fase 4: tekstudtræk og OCR

PDF’er er i praksis ikke ét format. Nogle indeholder markerbar tekst. Andre er scanninger. Nogle har kolonner, tabeller, fodnoter, formularer, kommentarer, stempler eller skjulte tekstlag.

Vælg udtræksvej efter dokumenttype: En tekstbaseret parser til digitalt oprettede PDF’er i klassen PyMuPDF eller pdfplumber; en layoutbevidst konverter til strukturerede dokumenter i klassen Docling eller Unstructured, hvor tabeller og læserækkefølge bevares langt bedre; og kun OCR til reelle scanninger — Tesseract som selvhostet grundløsning eller en cloudbaseret OCR-tjeneste, når scanningskvaliteten er dårlig, og dataklassificeringen tillader det.

Anvend ikke en universel grænse for OCR-konfidens fra et blogindlæg. Kalibrer på et udsnit af jeres egne dokumenter. Den nyttige model har to bånd: Under det nedre bånd afvises siden; mellem båndene sendes den til menneskeligt review; over det øvre bånd fortsætter den automatisk. Placeringen afhænger af scanner, dokumenternes alder og sproget.

En bemærkning om vores marked: Estisk OCR er vanskeligere end engelsk OCR. Tesseract leveres med en estisk model, men nøjagtigheden for õ/ä/ö/ü, ældre maskinskrevne arkiver og dokumenter med både estisk og russisk varierer så meget, at I bør gennemføre en pilotsammenligning med et repræsentativt udsnit af jeres eget arkiv, før I vælger en engine. For estiske virksomheder er denne pilot en halv dags arbejde, der senere kan forhindre en fjerdedel af de skjulte hentningsfejl.

Følg kvaliteten af udtrækket:

• udtræksmetode,
• OCR-konfidens,
• sideantal,
• antal udtrukne tegn,
• status for tabeludtræk,
• registreret sprog,
• sider uden tekst,
• advarsler fra parseren.

Udtræk af lav kvalitet må ikke umærkeligt indgå i indekset. Send det til review, eller marker det med lav konfidens.

Almindelige problemer:

• kolonner læses i forkert rækkefølge,
• tabelrækker flettes forkert,
• sidehoveder gentages i hver chunk,
• scannede sider mangler helt,
• håndskrevne noter ignoreres,
• et skjult tekstlag er i konflikt med den synlige scanning,
• OCR konverterer kontonumre forkert.

Foretag stikprøver, hvor den renderede side sammenlignes med den udtrukne tekst, ved dokumenter med stor værdi.

Fase 5: bevar strukturen

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

Bevar:

• titel,
• overskriftssti,
• afsnitsnummer,
• sidetal,
• tabeltekster,
• listegrænser,
• dokumentversion,
• ikrafttrædelsesdato,
• kilde-URL eller lagersti.

Opdel teksten med overskrifter og sidehenvisninger. En chunk, der siger »Følgende gælder« uden den foregående overskrift, er svag dokumentation.

For tabeller skal I vælge, om I vil:

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

Foregiv ikke, at tabeludtræk er løst, hvis anvendelsen afhænger af præcise priser, datoer, grænser eller tærskler.

Fase 6: tilføj metadata

Hver chunk skal indeholde metadata, der bevares gennem hentningen:

{
  "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 gør det muligt for applikationen at håndhæve politikker efter hentning. Uden metadata modtager modellen tekst, der er adskilt fra de regler, som gør teksten sikker at anvende.

Fase 7: kortlæg tilladelser

Tilladelser skal kortlægges, før hentningsresultater når modellen.

Godt mønster:

1. Brugeren stiller et spørgsmål.
2. Applikationen udleder tenant, bruger, roller, grupper og datatilladelser fra autentificeringen.
3. Retrieveren filtrerer mulige chunks efter tilladelser.
4. Rangeringen sker inden for de tilladte chunks.
5. Modellen modtager kun tilladte chunks.

Dårligt mønster:

1. Hent bredt.
2. Send alle sandsynlige chunks til modellen.
3. Angiv i prompten: »Svar kun ved hjælp af chunks, som brugeren må tilgå.«

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

Hvis kildetilladelserne er komplekse, skal I begynde mere restriktivt. Det er bedre at overse et svar end at lække et fortroligt dokument.

Fase 8: chunking og embedding

Chunking er en sikkerheds- og kvalitetsbeslutning, ikke kun finjustering af søgningen.

Retningslinjer:

• Hold chunks inden for tilladelsesgrænserne.
• Flet ikke offentlig og fortrolig tekst i én chunk.
• Medtag overskrifter og kildehenvisninger.
• Undgå meget store chunks med indbyrdes uafhængige afsnit.
• Undgå meget små chunks, der mister konteksten.
• Opret nye embeddings, når kildeteksten eller metadata ændres.
• Gem embeddingmodellens navn og version.

Bekræft ved følsomme kilder, om embeddingleverandøren, vektorlageret og logfilerne er godkendt til den pågældende dataklasse.

Fase 9: kvalitetsporte

Kør kontroller, før en kilde publiceres til hentning i produktion:

• alle dokumenter har ejere,
• alle chunks har tilladelsesmetadata,
• forældede dokumenter er markeret,
• sider, hvor udtrækket fejlede, er udeladt eller gennemgået,
• eksempelspørgsmål henter de forventede kilder,
• uautoriserede brugere henter ingen adgangsbegrænsede chunks,
• slettede dokumenter forsvinder fra søgningen,
• kildehenvisninger peger på gyldige placeringer,
• mistænkelige instruktioner i dokumenter isoleres som indhold og følges ikke.

Det sidste punkt er vigtigt. Dokumenter kan indeholde prompt injection. Ingestion-pipelinen bør ikke fjerne al sådan tekst, fordi brugerne undertiden har brug for at vide, hvad et dokument siger. Men systemet skal ved runtime behandle teksten som dokumentindhold, der ikke er tillid til.

Fase 10: opbevaring og sletning (GDPR artikel 17 hører til her)

RAG-systemer kommer ofte til at opbevare data længere end kildesystemet.

I denne fase bliver GDPR’s ret til sletning efter artikel 17 et teknisk krav i stedet for en politikerklæring. Når en anmodning om sletning modtages, kan »vi fjernede kildefilen« ikke forsvares, hvis kopier stadig findes andre steder i pipelinen. Sletning skal omfatte:

• cache med den oprindelige fil,
• udtrukket tekst,
• chunks,
• embeddings,
• opsummeringer,
• miniaturebilleder eller renderede sider,
• evalueringseksempler,
• logfiler, hvor loven kræver det,
• sikkerhedskopier i henhold til politikken.

Når et dokument slettes, eller adgang tilbagekaldes, må hentningen ikke længere returnere dets chunks. Systemet bør ideelt understøtte permanent sletning af følsomme kilder og dokumenteret opbevaring af sikkerhedskopier.

Følg:

• deletedAt,
• deletedBy eller kildehændelse,
• årsag til sletning,
• status for oprydning i efterfølgende systemer,
• resultat af verifikation.

Stol ikke på »vi fjernede det fra brugerfladen«. Vektorlagre og caches er lette at glemme.

Fase 11: operationelt ejerskab

Hver kilde skal have en ejer. Hver ejer skal have en reviewrytme.

Definer følgende for hver kilde:

• hvem der godkender ingestion,
• hvem der godkender ændringer af tilladelser,
• hvem der gennemgår forældede dokumenter,
• hvem der håndterer fejl ved udtræk,
• hvem der besvarer anmodninger om sletning af data,
• hvem der undersøger hentningsfejl.

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

Konklusion

Sikker RAG-ingestion er kedelig på den bedst tænkelige måde. Den gør hentningen forudsigelig.

De centrale kontroller:

• registrer kilder,
• klassificer data,
• kontroller filer før parsing,
• mål kvaliteten af udtrækket,
• bevar strukturen,
• tilføj metadata,
• håndhæv tilladelser før hentning,
• test uautoriseret adgang,
• understøt sletning,
• tildel ejere.

Gode svar kommer fra gode kilder. Sikre svar kommer fra god kildekontrol.