Säker dokumentinläsning för RAG: PDF, OCR, metadata och lagringstid

De flesta fel i hämtningsförstärkt generering (RAG) uppstår före informationshämtningen. Dokumentet var inaktuellt. OCR-tolkningen missade en tabell. Källan saknade ägare. Behörighetsmetadata gick förlorade. Ett raderat avtal låg kvar i vektorlagret. En skannad PDF hade ett dolt textlager som ingen hade granskat. Systemet svarade självsäkert eftersom inläsningspipelinen behandlade ”det finns text” som ”kunskapen är säker att använda”.

Säker dokumentinläsning är källkontroll för företagets kunskap. Den avgör vad som förs in i hämtningssystemet, vem som får se det, hur aktualitet följs upp, hur radering fungerar och hur olämpliga indata fångas upp.

Den här artikeln behandlar inläsningslagret: PDF-filer, OCR, metadata, behörigheter, lagringstid och operativa kontroller.

Om en användare inte ska ha åtkomst till ett dokument i källsystemet ska användaren inte heller ha åtkomst till dess textsegment, inbäddningar, sammanfattningar eller cachelagrade svar i RAG-systemet. Behörighetsmetadata är obligatoriska.

Inläsningspipelinen

En produktionspipeline ska ha uttryckliga steg:

1. Registrering av källor.
2. Dataklassificering.
3. Säkerhetskontroller av filer.
4. Textextraktion och OCR.
5. Bevarande av struktur.
6. Tilldelning av metadata.
7. Behörighetsmappning.
8. Segmentering och inbäddning.
9. Kvalitetskontroller.
10. Publicering i index.
11. Hantering av lagringstid och radering.

De konkreta verktygen kan variera. Kontrollpunkterna ska inte göra det.

Steg 1: registrering av källor

Läs inte in godtyckliga mappar bara för att de är enkla att ansluta.

Registrera följande för varje källa:

• källans namn,
• verksamhetens källsystem,
• källans ägare,
• informationsägare,
• tillåtna användare eller roller,
• dokumenttyper,
• känslighetsnivå,
• regel för lagringstid,
• uppdateringsfrekvens,
• raderingsbeteende,
• granskningsintervall.

Exempel på källor:

• offentligt hjälpcenter,
• intern supporthandbok,
• säljmaterial,
• kundavtal,
• HR-policyer,
• tekniska driftinstruktioner,
• produktdokumentation,
• mötestranskriptioner.

Dessa källor ska inte hamna i samma index med samma behörigheter.

Steg 2: klassificera informationen före extraktion

Klassificera källan innan modellen eller leverantören av inbäddningar får se innehållet.

Användbara klasser:

Klassificeringen är inte bara dokumentation för regelefterlevnad. Den avgör om innehållet får skickas till ett värdbaserat API för inbäddningar, lagras i en gemensam vektordatabas, tas med i loggar eller användas i utvärderingsexempel.

Steg 3: säkerhetskontroller av filer

Dokument kan vara fientliga eller helt enkelt trasiga.

Före extraktionen:

• kontrollera filtypen mot en tillåtelselista,
• tillämpa storleksgränser,
• sök efter skadlig kod när miljön kräver det,
• avvisa krypterade filer om det inte finns en godkänd dekrypteringsväg,
• avvisa filer med inbäddade objekt som inte stöds,
• normalisera filnamn,
• lagra originalfilens hashvärde,
• registrera vem som laddade upp eller anslöt filen.

Det är särskilt viktigt om andra än administratörer kan ladda upp dokument. Inläsning som endast administratörer får utföra minskar risken, men eliminerar den inte.

Virusskydd och mekanismer för att oskadliggöra innehåll ingår inte automatiskt i de flesta RAG-stackar. Om ej betrodda användare kan ladda upp filer måste ett verkligt säkerhetslager för filer läggas till före parsningen.

I praktiken kan lagret bestå av följande, i stigande grad av försiktighet: som lägsta nivå en signaturskanner i samma klass som ClamAV; parsning i en isolerad container utan utgående nätverksåtkomst – parsrar för PDF- och Office-format har en lång historik av CVE:er och ska därför betraktas som en angreppsyta i sig; och för verkligt ej betrodda indata, oskadliggörande och rekonstruktion av innehåll (CDR), som bygger om en ren kopia av filen i stället för att lita på originalet. De flesta pipeliner i små och medelstora företag behöver de två första. Lägg till CDR när externa parter kan skicka in dokument.

Steg 4: textextraktion och OCR

PDF är i praktiken inte ett enda format. Vissa filer innehåller markerbar text. Andra är skanningar. Vissa har kolumner, tabeller, fotnoter, formulär, kommentarer, stämplar eller dolda textlager.

Välj extraktionsväg efter dokumenttyp: en textorienterad extraktor för digitalt skapade PDF-filer (i samma klass som PyMuPDF eller pdfplumber), en layoutmedveten konverterare för strukturerade dokument (i samma klass som Docling eller Unstructured – tabeller och läsordning bevaras betydligt bättre) och OCR endast för verkliga skanningar (Tesseract som basalternativ i egen drift; en OCR-molntjänst när skanningskvaliteten är dålig och informationsklassificeringen tillåter det).

Använd inte ett generellt tröskelvärde för OCR-konfidens från ett blogginlägg. Kalibrera mot ett urval av de egna dokumenten. En användbar modell har två intervallgränser: under den nedre avvisas sidan direkt, mellan gränserna köas den för mänsklig granskning och över den övre går den vidare. Gränsernas placering beror på skannern, dokumentens ålder och språket.

En anmärkning som är särskilt relevant för vår marknad: OCR för estniska är svårare än OCR för engelska. Tesseract levereras med en estnisk modell, men precisionen för õ/ä/ö/ü, äldre maskinskrivna arkiv och dokument med blandad estniska och ryska varierar så mycket att ett pilotförsök bör jämföra representativa exempel ur det egna arkivet innan en motor väljs. För estniska företag tar piloten en halv dag och förebygger senare en fjärdedel av de tysta hämtningsfelen.

Följ extraktionskvaliteten:

• extraktionsmetod,
• OCR-konfidens,
• antal sidor,
• antal extraherade tecken,
• status för tabellextraktion,
• identifierat språk,
• sidor utan text,
• varningar från parsern.

Extraktion av låg kvalitet ska inte obemärkt föras in i indexet. Skicka den till granskning eller märk den med låg konfidens.

Vanliga problem:

• kolumner läses i fel ordning,
• tabellrader slås ihop fel,
• sidhuvuden upprepas i varje textsegment,
• skannade sidor saknas helt,
• handskrivna anteckningar ignoreras,
• ett dolt textlager motsäger den synliga skanningen,
• OCR omvandlar kontonummer felaktigt.

För värdefulla dokument bör den renderade sidan stickprovskontrolleras mot den extraherade texten.

Steg 5: bevara strukturen

RAG-system behöver mer än text. De behöver tillräcklig struktur för att kunna ge användbara och källbelagda svar.

Bevara:

• titel,
• rubrikhierarki,
• avsnittsnummer,
• sidnummer,
• tabellrubriker,
• listgränser,
• dokumentversion,
• ikraftträdandedatum,
• käll-URL eller lagringssökväg.

Dela upp texten med rubriker och sidreferenser. Ett textsegment som endast säger ”Följande gäller” utan föregående rubrik är ett svagt belägg.

Bestäm följande för tabeller:

• behåll tabellen som Markdown,
• konvertera den till strukturerad JSON,
• lagra både text och strukturerade rader,
• uteslut den tills en bättre parser finns tillgänglig.

Låtsas inte att tabellextraktion är ett löst problem om användningsfallet beror på exakta priser, datum, gränser eller tröskelvärden.

Steg 6: tilldela metadata

Varje textsegment ska innehålla metadata som följer med genom informationshämtningen:

{
  "sourceId": "policy-2026-expenses",
  "documentId": "doc_123",
  "tenantId": "tenant_a",
  "visibility": "internal",
  "allowedRoles": ["finance", "leadership"],
  "sensitivity": "confidential",
  "sourceOwner": "Ekonomi",
  "version": "2026-02",
  "lastReviewedAt": "2026-02-10",
  "effectiveFrom": "2026-03-01",
  "page": 7,
  "headingPath": ["Resor", "Hotellgränser"],
  "contentHash": "sha256:..."
}

Med hjälp av metadata kan applikationen tillämpa regler efter hämtningen. Utan dem får modellen text som har skilts från de regler som gör den säker att använda.

Steg 7: behörighetsmappning

Behörighetsmappningen måste ske innan hämtningsresultaten når modellen.

Bra mönster:

1. Användaren ställer en fråga.
2. Applikationen härleder klientorganisation, användare, roller, grupper och databehörigheter från autentiseringen.
3. Hämtningskomponenten filtrerar möjliga textsegment efter behörighet.
4. Rangordningen sker inom mängden tillåtna textsegment.
5. Modellen får endast tillåtna textsegment.

Dåligt mönster:

1. Hämta brett.
2. Skicka alla sannolika textsegment till modellen.
3. Prompten säger ”svara endast med textsegment som användaren har behörighet till”.

Det dåliga mönstret har redan exponerat informationen i modellens kontext.

Börja snävare om källbehörigheterna är komplexa. Det är bättre att missa ett svar än att läcka ett konfidentiellt dokument.

Steg 8: segmentering och inbäddning

Segmenteringen är ett säkerhets- och kvalitetsbeslut, inte bara ett beslut om sökoptimering.

Riktlinjer:

• Håll textsegmenten inom behörighetsgränserna.
• Slå inte samman offentlig och konfidentiell text i samma textsegment.
• Ta med rubriker och källreferenser.
• Undvik mycket stora textsegment som innehåller orelaterade avsnitt.
• Undvik mycket små textsegment som tappar sammanhanget.
• Skapa nya inbäddningar när källtext eller metadata ändras.
• Lagra inbäddningsmodell och version.

Kontrollera för känsliga källor att leverantören av inbäddningar, vektorlagret och loggarna är godkända för den aktuella informationsklassen.

Steg 9: kvalitetsgrindar

Kör följande kontroller innan en källa publiceras för informationshämtning i produktion:

• alla dokument har ägare,
• alla textsegment har behörighetsmetadata,
• inaktuella dokument är märkta,
• sidor där extraktionen misslyckades är uteslutna eller granskade,
• exempelfrågor hämtar förväntade källor,
• obehöriga användare hämtar noll skyddsvärda textsegment,
• raderade dokument försvinner från sökningen,
• källhänvisningar pekar på giltiga platser i källan,
• misstänkta instruktioner i dokument isoleras som innehåll och följs inte.

Den sista punkten är viktig. Dokument kan innehålla promptinjektion. Inläsningspipelinen ska inte ta bort all sådan text eftersom användarna ibland behöver veta vad dokumentet säger. Systemet måste däremot under körning behandla den som ej betrott dokumentinnehåll.

Steg 10: lagringstid och radering (här tillämpas artikel 17 i GDPR)

RAG-system behåller ofta data längre än källsystemet av misstag.

I det här steget blir rätten till radering enligt artikel 17 i GDPR ett tekniskt krav i stället för en policyformulering: när en begäran om radering kommer in är ”vi tog bort källfilen” inte ett försvarbart svar om kopior finns kvar på andra platser i pipelinen. Raderingen måste omfatta:

• cache för originalfiler,
• extraherad text,
• textsegment,
• inbäddningar,
• sammanfattningar,
• miniatyrbilder eller renderade sidor,
• utvärderingsexempel,
• loggar när lagen kräver det,
• säkerhetskopior i enlighet med policyn.

När ett dokument raderas eller åtkomsten återkallas ska informationshämtningen sluta returnera dess textsegment. Systemet bör helst stödja definitiv radering av känsliga källor och dokumenterade lagringstider för säkerhetskopior.

Följ upp:

• deletedAt,
• deletedBy eller källhändelse,
• raderingsorsak,
• status för rensning nedströms,
• verifieringsresultat.

Förlita dig inte på ”vi tog bort det från användargränssnittet”. Vektorlager och cacheminnen är lätta att glömma.

Steg 11: operativt ägarskap

Varje källa behöver en ägare. Varje ägare behöver ett granskningsintervall.

Definiera följande för varje källa:

• vem som godkänner inläsning,
• vem som godkänner behörighetsändringar,
• vem som granskar inaktuella dokument,
• vem som hanterar extraktionsfel,
• vem som svarar på begäranden om radering,
• vem som utreder fel i informationshämtningen.

Om ingen äger en källa ska den inte finnas i ett produktionssatt RAG-system.

Slutsats

Säker RAG-inläsning är odramatisk på bästa möjliga sätt. Den gör informationshämtningen förutsägbar.

De centrala kontrollerna:

• registrera källor,
• klassificera information,
• kontrollera filer före parsning,
• mät extraktionskvalitet,
• bevara struktur,
• tilldela metadata,
• tillämpa behörigheter före hämtning,
• testa obehörig åtkomst,
• stöd radering,
• utse ägare.

Bra svar kommer från bra källor. Säkra svar kommer från god källkontroll.