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

Fel i ett RAG-system kan uppstå redan före hämtningen: inaktuella dokument, förbisedda tabeller, källor utan ansvarig, förlorade behörighetsmetadata, vektorer som inte har raderats, motsägelsefull dold text eller osäkra filer.

Säker dokumentinläsning är källstyrning 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 felaktiga indata upptäcks.

Den här artikeln behandlar dokumentinlä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 kunna nå dess segment, inbäddningar, sammanfattningar eller cachelagrade svar i RAG-systemet. Behörighetsmetadata är obligatoriska.

Arbetsflöde för dokumentinläsning

En produktionspipeline bör ha tydligt definierade steg:

1. Källregistrering.
2. Informationsklassificering.
3. Filsäkerhetskontroller.
4. Textextrahering och OCR.
5. Strukturbevarande.
6. Tilldelning av metadata.
7. Mappning av behörigheter.
8. Segmentering och inbäddning.
9. Kvalitetskontroller.
10. Indexpublicering.
11. Hantering av lagringstid och radering.
12. Operativt ansvar.

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

Steg 1: källregistrering

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

För varje källa, registrera:

• källnamn,
• verksamhetens källsystem,
• källägare,
• dataägare,
• tillåtna användare eller roller,
• dokumenttyper,
• känslighetsnivå,
• regel för lagringstid,
• uppdateringsfrekvens,
• raderingsbeteende,
• granskningsschema.

Exempel på källor:

• offentligt hjälpcenter,
• intern supporthandbok,
• försäljningsmaterial,
• kundkontrakt,
• HR-policyer,
• tekniska driftinstruktioner,
• produktdokumentation,
• mötesreferat.

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

Steg 2: klassificera data innan extrahering

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

Användbara klasser:

Klassificering är inte bara dokumentation för regelefterlevnad. Den avgör om innehållet får skickas till ett hanterat API för inbäddningar, lagras i en gemensam vektordatabas, tas med i loggar eller användas som exempel vid utvärdering.

Steg 3: filsäkerhetskontroller

Dokument kan vara fientliga eller helt enkelt trasiga.

Före extraheringen:

• kontrollera filtypen mot en lista över tillåtna filtyper,
• tillämpa gränser för filstorlek,
• sök efter skadlig kod dä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 kopplade till filen.

Detta är särskilt viktigt om användare utan administratörsbehörighet kan ladda upp dokument. Inläsning som endast administratörer får utföra minskar en angreppsväg, men gör inte ett komprometterat, fientligt, överdimensionerat eller felaktigt formaterat dokument säkert. Inläsning via anslutningar och URL:er kräver också tillåtna ursprung, kontroll av omdirigeringar och DNS, avgränsad autentisering, hastighetsbegränsning och testning mot SSRF.

Om användare som inte är betrodda kan ladda upp filer ska ett filsäkerhetslager införas före parsningen. Använd den uppdaterade OWASP File Upload Cheat Sheet som utgångspunkt och hotmodellera de valda parserna och lagringsvägen. För den bredare hotmodellen för hämtning – inklusive förgiftning, behörighetsläckage, promptinjektion och osäkra utdata – bör även OWASP RAG Security Cheat Sheet användas.

Möjliga kontroller är bland annat tillåtna filtyper som verifieras utifrån filinnehållet, gränser för filstorlek och uppackning av arkiv, slumpmässigt genererade lagringsnamn, signaturbaserad skanning, isolerad parsning utan utgående nätverkstrafik och med resursgränser samt sanering och rekonstruktion av innehåll (content disarm and reconstruction) där hotmodellen motiverar det. Ingen enskild skanner kan fastställa att en fil är säker.

Steg 4: textextrahering och OCR

PDF-filer är i praktiken inte ett enhetligt format. Vissa innehåller markerbar text. Andra är skannade bilder. En del har kolumner, tabeller, fotnoter, formulär, kommentarer, stämplar eller dolda textlager.

Välj extraheringsmetod efter dokumenttyp: jämför textinriktade extraktorer för digitalt skapade PDF-filer, layoutmedvetna konverterare för strukturerade dokument och OCR för skannade dokument. Verktygsvalet ska baseras på uppmätt noggrannhet för layout och tabeller, språkstöd, licens, säkerhetsuppdateringar och den fastställda datagränsen.

Använd inte ett generellt gränsvärde för OCR-tillförlitlighet från ett blogginlägg. Kalibrera i stället med ett urval av de egna dokumenten. En praktisk modell har två gränser: under den lägre gränsen avvisas sidan helt, mellan gränserna köas den för mänsklig granskning och över den övre gränsen går den vidare. Gränsernas placering beror på skannern, dokumentens ålder och språket.

För estniska och flerspråkiga arkiv bör utvärderingen omfatta diakritiska tecken, äldre maskinskrivna sidor, tabeller, stämplar och estnisk-ryska exempel. Kontrollera att den valda OCR-motorn har nödvändiga språkdata och mät sedan noggrannheten för tecken, ord, fält och tabeller på representativa sidor. Utlova inte en generell tidsåtgång för pilotprojektet.

Följ upp extraheringskvaliteten:

• extraheringsmetod,
• OCR-konfidens,
• sidantal,
• antal extraherade tecken,
• status för tabellextrahering,
• detekterat språk,
• sidor utan text,
• varningar från parsern.

Lågkvalitativ extrahering ska inte tyst gå in i indexet. Skicka den till granskning eller markera den som låg konfidens.

Vanliga problem:

• kolumner lästa i fel ordning,
• tabellrader sammanslagna felaktigt,
• sidhuvuden som upprepas i varje segment,
• skannade sidor helt saknade,
• handskrivna anteckningar ignorerade,
• dolt textlager som motsäger den synliga skanningen,
• OCR som konverterar kontonummer felaktigt.

För dokument med högt värde bör stickprov göras där den renderade sidan jämförs med den extraherade texten.

Steg 5: bevara struktur

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

Bevara:

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

Dela upp texten i segment som innehåller rubriker och sidreferenser. Ett segment som säger ”Följande gäller” utan föregående rubrik utgör ett svagt underlag.

För tabeller, bestäm om du ska:

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

Ge inte sken av att tabellextrahering är ett löst problem om användningsfallet är beroende av exakta priser, datum, gränser eller tröskelvärden.

Steg 6: tilldela metadata

Varje segment ska innehålla metadata som finns kvar och är tillgängliga vid hämtningen:

{
  "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 ger underlag för att upprätthålla policyn, men upprätthåller inte policyn i sig. Applikationen måste verifiera att metadata kommer från en betrodd källa och kontrollera behörigheten vid publicering, hämtning, cachning, källhänvisning, generering och export.

Steg 7: mappa behörigheter

Behörighetskontrollen måste ske innan hämtningsresultaten når modellen och upprepas vid varje gräns för svar, källhänvisning, cache eller export där identiteten eller policyn kan ha ändrats.

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 autentiseringssystemet.
3. Hämtningskomponenten filtrerar kandidatsegmenten efter behörighet.
4. Rangordningen sker endast bland de tillåtna segmenten.
5. Modellen får enbart de tillåtna segmenten.

Dåligt mönster:

1. Hämtningen görs brett.
2. Alla sannolikt relevanta segment skickas till modellen.
3. Prompten säger ”bara svara med de segment som användaren har behörighet att läsa”.

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

Om källbehörigheter är komplexa, börja striktare. Det är bättre att missa ett svar än att läcka ett konfidentiellt dokument.

Steg 8: segmentering och inbäddning

Segmentering är ett säkerhets- och kvalitetsbeslut, inte bara en fråga om att finjustera sökningen.

Riktlinjer:

• Håll segmenten inom behörighetsgränserna.
• Blanda inte offentlig och konfidentiell text i samma segment.
• Inkludera rubriker och källreferenser.
• Undvik jättestora segment som innehåller orelaterade avsnitt.
• Undvik små segment som förlorar kontext.
• Skapa nya inbäddningar när källtext eller metadata ändras.
• Lagra vilken inbäddningsmodell och version som används.

För känsliga källor måste det säkerställas att leverantören av inbäddningstjänsten, vektordatabasen och logglagringen är godkända för den aktuella dataklassen.

Steg 9: kvalitetskontroller

Innan en källa publiceras för hämtning i produktion ska följande kontroller göras:

• alla dokument har ägare,
• alla segment har behörighetsmetadata,
• inaktuella dokument är flaggade,
• sidor med misslyckad extrahering exkluderas eller granskas,
• representativa frågor hämtar förväntade källor,
• obehöriga användare får inte tillgång till några begränsade segment,
• raderade dokument försvinner från sökningen,
• källhänvisningar pekar på giltiga platser i källorna,
• 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 automatiskt ta bort all sådan text, eftersom användarna kan behöva veta vad ett dokument säger och borttagningen kan förstöra bevisvärdet. Körmiljön måste hålla hämtat innehåll i en datakanal, förhindra att innehållet ger åtkomst till verktyg eller ändrar policyn, validera verktygsargument oberoende och kräva mänskligt godkännande före åtgärder med betydande konsekvenser.

Steg 10: publicera en indexversion atomiskt

Låt inte delvis inlästa dokument eller en blandning av gamla och nya behörigheter läcka in i det aktiva indexet. Bygg ett kandidatindex eller en versionshanterad namnrymd och gör sedan följande:

1. Lås manifestet över källor och versioner samt innehållshasharna.
2. Verifiera antalet dokument, extraheringsfel, behörighetstäckning, dubblettpolicy, inbäddningsmodell och modellversion samt representativa frågor från både behöriga och obehöriga användare.
3. Registrera kandidatversionen, källversionerna, testresultatet, godkännaren och återställningsmålet.
4. Växla atomiskt ett alias eller en applikationspekare till den godkända versionen där lagringslösningen stöder det.
5. Ogiltigförklara eller versionshantera cacheposter för hämtning och svar.
6. Övervaka fel, nekad åtkomst, tomma hämtningsresultat och trafik mot inaktuella versioner efter publiceringen.

Om vektordatabasen inte kan växla versioner atomiskt ska applikationen ha ett publiceringstillstånd som utesluter ofullständiga poster. Testa samtidigt parallella läsare under publiceringen. Återkallade behörigheter och brådskande radering av källor får inte behöva vänta på en fullständig ombyggnad: upprätthåll den aktuella behörighetskontrollen utanför indexet, blockera den berörda källan omedelbart, rensa relevanta cacheposter och slutför rensningen av härledda data genom livscykelflödet.

En återställning ska återföra indexpekaren till den senast godkända versionen utan att återinföra återkallad åtkomst eller raderade data. Testa att återställningen inte återaktiverar en ersatt åtkomstkontrollista (ACL), ett raderat dokument, en förgiftad källa eller ett inaktuellt cachelagrat svar.

Steg 11: datalagringstid och radering

RAG-system håller ofta kvar data längre än källsystemet.

Artikel 17 i GDPR anger en rätt till radering med villkor och undantag. En kvalificerad juridisk rådgivare måste avgöra vilka skyldigheter och lagliga grunder för fortsatt lagring som gäller. Systemet behöver ändå en inventering och livscykelhantering för varje kopia och härledd datamängd:

• cachelagrad originalfil,
• extraherad text,
• segment (chunks),
• inbäddningar,
• sammanfattningar,
• miniatyrbilder eller renderade sidor,
• utvärderingsexempel,
• loggar, med en godkänd grund för dataminimering och lagringstid,
• säkerhetskopior, med dokumenterad giltighetstid och återställningshantering.

När ett dokument raderas eller åtkomsten återkallas ska cacheposter för hämtning och svar sluta returnera det inom den dokumenterade tidsgränsen. Raderingsflödet måste omfatta alla lager med härledda data och förhindra att en gammal säkerhetskopia eller ett fördröjt inläsningsjobb återinför posten.

Registrera:

• deletedAt,
• deletedBy eller den utlösande källhändelsen,
• raderingsskäl,
• status för rensning i efterföljande system,
• verifieringsresultat.

Lita inte på påståendet ”vi tog bort det från användargränssnittet”. Vektordatabaser och cacheposter är lätta att glömma.

Steg 12: operativt ansvar

Varje produktionskälla behöver en ansvarig samt en händelseutlöst eller återkommande granskning som anpassas efter källans förändringstakt och påverkan.

För varje källa ska du definiera:

• vem som godkänner dokumentinläsning,
• vem som godkänner behörighetsförändringar,
• vem som granskar inaktuella dokument,
• vem som hanterar extraheringsfel,
• vem som svarar på begäran om radering av data,
• vem som utreder hämtningsfel.

En källa utan ansvarig ska inte finnas i ett RAG-system i produktion.

Källstyrning, inte garantier

Säker dokumentinläsning i RAG är avsiktlig källstyrning. Den gör hämtningsbeteenden och fel lättare att observera och testa, men innebär inte att genererade svar automatiskt blir korrekta eller säkra.

De grundläggande kontrollerna:

• registrera källor,
• klassificera data,
• kontrollera filer innan bearbetning,
• mäta extraheringskvalitet,
• bevara struktur,
• bifoga metadata,
• tillämpa behörigheter före hämtning,
• testa obehörig åtkomst,
• möjliggöra radering,
• tilldela ägare.

Källkvalitet och källkontroller är nödvändiga förutsättningar för svarskvalitet och säkerhet, men ger inga garantier. Validera hämtning, behörighetskontroll, källförankring, vägranden, verktygsanvändning och livscykelhantering från början till slut.