RAG over pdf's: waarom scans je grootste vijand zijn
Gescande pdf’s maken RAG-systemen kwetsbaar voor extractiefouten. Lees waarom OCR, tabellen en complexe layouts problemen veroorzaken en hoe je documenten controleert voordat je ze indexeert.
Scans zijn een van de lastigste bronnen voor een RAG-systeem omdat een gescande pdf vaak helemaal geen tekst bevat. Wat voor jou eruitziet als een normale pagina, is voor software in feite een afbeelding. Zonder extra verwerking kan een RAG-pijplijn de woorden daarop niet betrouwbaar ophalen, opdelen of indexeren.
De oplossing begint daarom vóór de vectorindex: controleer eerst of een pdf een bruikbare tekstlaag bevat en gebruik OCR wanneer die ontbreekt. Behandel de uitkomst van OCR vervolgens niet automatisch als betrouwbare brontekst. Controleer de extractie, bewaar de relatie met het originele paginanummer en indexeer twijfelachtige documenten pas nadat duidelijk is dat de tekst voldoende correct is.
Een pdf met tekst is iets anders dan een scan
Een pdf is vooral een containerformaat. Twee bestanden die er op het scherm vrijwel hetzelfde uitzien, kunnen technisch heel verschillend zijn opgebouwd. Een digitaal gegenereerde pdf bevat meestal tekstelementen die software direct kan selecteren en uitlezen. Zo’n tekstlaag kan relatief eenvoudig worden gebruikt als invoer voor een RAG-systeem.
Een gescande pdf kan daarentegen bestaan uit één afbeelding per pagina. Er zijn dan pixels zichtbaar, maar geen afzonderlijke letters, woorden of alinea’s beschikbaar voor de extractiesoftware. De tekst moet eerst met optical character recognition, of OCR, uit het beeld worden afgeleid.
Dat verschil is belangrijk omdat RAG afhankelijk is van de kwaliteit van de bronextractie. Een uitleg van de rest van die keten vind je in RAG uitgelegd. Als de invoer aan het begin al beschadigd is, kunnen latere onderdelen van het systeem dat meestal niet volledig herstellen.
OCR maakt tekst bruikbaar, maar niet automatisch correct
OCR probeert visuele vormen op een pagina te herkennen als letters, woorden en soms ook structuurelementen. Bij duidelijke, rechte scans van goed gedrukt materiaal kan dat bruikbare tekst opleveren. De betrouwbaarheid verschilt echter sterk per document en per OCR-oplossing.
Slechte resolutie, vlekken, verbleekte tekst en compressie kunnen herkenning verstoren. Hetzelfde geldt voor scheef gescande pagina’s, handschrift, stempels, handtekeningen en tekst die over achtergrondbeelden loopt. Ook meerkolomsdocumenten veroorzaken problemen wanneer een extractor niet begrijpt in welke volgorde tekstblokken gelezen moeten worden.
Koppen en voetteksten kunnen op iedere pagina opnieuw in de geëxtraheerde tekst terechtkomen. Daardoor verschijnen bijvoorbeeld documenttitels, paginacodes of disclaimers herhaaldelijk tussen de inhoud. Een mens negeert zulke elementen vrijwel automatisch, maar voor een tekstverwerker zijn het gewoon extra tokens.
OCR-fouten werken door in chunks, embeddings en citaten
Een OCR-fout blijft niet beperkt tot één verkeerd gelezen woord. De fout wordt onderdeel van de tekst waarop de rest van de RAG-pijplijn verder bouwt. Bij chunking kan een verkeerd herkende alinea-indeling ervoor zorgen dat inhoud op onlogische plaatsen wordt gesplitst of samengevoegd.
Vervolgens worden die chunks omgezet naar embeddings. Een enkele OCR-fout hoeft semantisch niet doorslaggevend te zijn, maar grotere extractiefouten kunnen de betekenis van een chunk veranderen. Denk aan ontbrekende ontkenningen, door elkaar gehusselde kolommen of cijfers die verkeerd zijn herkend. De retriever kan daardoor een minder passend tekstfragment ophalen of juist relevante informatie missen.
Ook bronvermelding wordt lastiger. Als het RAG-systeem een passage citeert die in de extractie beschadigd is, kan de gebruiker de formulering mogelijk niet letterlijk terugvinden in het origineel. Bewaar daarom bij voorkeur de relatie tussen iedere geëxtraheerde passage en het oorspronkelijke document en paginanummer. Een verwijzing naar alleen een bestandsnaam is bij langere documenten vaak onvoldoende om een antwoord goed te controleren.
Tabellen en formulieren vragen om meer dan platte tekst
Tabellen zijn een afzonderlijk probleem. Een eenvoudige tekstextractor leest cellen soms achter elkaar uit zonder duidelijk te maken welke waarde bij welke rij of kolom hoort. Een tabel met bedragen, datums of producteigenschappen kan daardoor veranderen in een reeks losse woorden en cijfers waarvan de onderlinge relatie verloren is gegaan.
Formulieren hebben hetzelfde probleem. De betekenis zit vaak niet alleen in de ingevulde waarde, maar in de combinatie van label, veld, positie en eventueel een aangevinkt vakje. Als een extractor alleen losse tekst retourneert, kan bijvoorbeeld onduidelijk worden bij welke vraag een antwoord hoort.
Daarom kan layout-bewuste extractie geschikter zijn dan een eenvoudige omzetting naar platte tekst. Zo’n extractor probeert tekstblokken, kolommen, tabellen en andere pagina-elementen als structuur te herkennen. Dat lost niet ieder document betrouwbaar op, maar geeft een RAG-pijplijn meer informatie om de oorspronkelijke samenhang te behouden.
Voor tabellen kan het soms verstandiger zijn om ze naar een gestructureerde representatie om te zetten in plaats van ze als gewone alinea’s te behandelen. Welke aanpak geschikt is, hangt af van het documenttype en van de vragen die het systeem later moet kunnen beantwoorden.
Controleer de extractie voordat je gaat indexeren
Een document succesvol door een OCR- of extractietool halen is geen kwaliteitscontrole. Voordat tekst in een vectorindex terechtkomt, moet je beoordelen of de geëxtraheerde inhoud nog voldoende overeenkomt met het origineel.
Een praktische controlelijst:
- Controleer automatisch of een pdf een tekstlaag bevat of hoofdzakelijk uit afbeeldingen bestaat.
- Bekijk bij scans een steekproef van de OCR-uitvoer naast de oorspronkelijke pagina.
- Controleer documenten met tabellen, kolommen, formulieren, stempels of handschrift extra zorgvuldig.
- Controleer of koppen, voetteksten en paginanummers niet onnodig door iedere chunk worden herhaald.
- Bewaar documentnaam en oorspronkelijk paginanummer als metadata bij de geëxtraheerde tekst.
- Markeer documenten waarvan de extractiekwaliteit twijfelachtig is, zodat ze niet ongemerkt als normale bron worden behandeld.
- Test na indexering met vragen waarvan je weet waar het correcte antwoord in het brondocument staat.
Een vaste evaluatieset helpt om te bepalen of veranderingen in extractie, OCR of chunking de zoekkwaliteit verbeteren of verslechteren. Zie daarvoor ook hoe je RAG-kwaliteit meet. Zeker wanneer een systeem naar productie gaat, moet documentkwaliteit onderdeel zijn van de normale beheerketen en niet alleen van de eerste import.
Soms moet je een document juist niet indexeren
Niet ieder document hoeft koste wat kost in de kennisbank terecht te komen. Als een scan nauwelijks leesbaar is, veel handschrift bevat of door de layout structureel verkeerd wordt geïnterpreteerd, kan niet indexeren veiliger zijn dan slechte tekst als betrouwbare kennisbron beschikbaar maken.
Handmatige controle is vooral belangrijk wanneer kleine verschillen grote gevolgen kunnen hebben. Denk aan contractuele bepalingen, formulieren, bedragen, datums of documenten waarin tabellen de kern van de informatie vormen. Een taalmodel kan een beschadigde extractie vloeiend verwerken zonder te weten dat de bron beschadigd was. Juist daardoor kan een technisch succesvolle RAG-query inhoudelijk toch onbetrouwbaar zijn.
De belangrijkste regel is daarom eenvoudig: behandel documentextractie als een afzonderlijke kwaliteitsstap. RAG begint niet bij embeddings of een vectordatabase, maar bij een betrouwbare representatie van het oorspronkelijke document. Bij gescande pdf’s moet je die betrouwbaarheid eerst actief creëren en controleren voordat je het model erop laat vertrouwen.