𝗦𝘁𝗼𝗽 𝗺𝗲𝘁 𝗵𝗲𝘁 𝗽𝗮𝗿𝘀𝗲𝗻 𝘃𝗮𝗻 𝗣𝗗𝗙'𝘀 𝗼𝗽 𝗿𝗲𝗻𝗱𝗲𝗿-𝘁𝗶𝗷𝗱

De meeste ontwikkelaars bouwen PDF-extractietools op de verkeerde manier.

Ze proberen de documentstructuur te raden op basis van de visuele output. Ze renderen een pagina naar een canvas en kijken naar pixelposities. Ze gebruiken computer vision om kolommen of tabellen te vinden.

Deze aanpak is omgekeerd.

Een PDF bevat de benodigde structuur al in de operator stream.

Een tabel is niet zomaar een verzameling pixels. Het is een verzameling path operators zoals moveTo, lineTo en rectangle. Zonegrenzen zijn gecodeerd in de CTM stack. Je hoeft niet te reconstrueren wat er al is.

Stop met het gebruiken van visuele heuristieken. Gebruik de brongegevens.

Ik heb eerder geprobeerd om De Casteljau-subdivisie te gebruiken voor bounding boxes. Ik heb dit tijdens het testen afgewezen.

De Casteljau is een subdivisie-algoritme. Je splitst curven totdat de segmenten klein genoeg zijn. Dit werkt voor rendering, maar is slecht voor bounding boxes.

Je moet een tolerantie kiezen. Als de tolerantie te ruim is, is de box foutief. Als deze te nauw is, verspil je resources aan recursie. Er is een betere manier. Een analytische oplossing met behulp van de kwadratische formule is exact. Het recurseert niet. Het wijst geen segmenten toe.

Dezelfde logica is van toepassing op zone-detectie.

Veel tools berekenen zonegrenzen door het middelpunt tussen twee tekstgroepen te vinden. Dit is een visuele gok. Het is niet structureel.

Als je middelpuntberekeningen gebruikt, zorgt subpixel-afronding ervoor dat regio's in de verkeerde zones terechtkomen.

De oplossing is eenvoudig. Gebruik de bovenrand van de bounding box. Een regio behoort tot een zone op basis van waar deze begint. Gebruik de werkelijke Y-coördinaat van de bovenrand.

Het bouwen van een echte PDF-extractor is moeilijker. Je moet:

Stop met het parsen van PDF's op render-tijd: Een betere architectuur voor gestructureerde extractie

Veel ontwikkelaars maken de fout om PDF's te parsen op het moment dat de data nodig is voor weergave of verwerking. Dit wordt "render-time parsing" genoemd. Hoewel dit in het begin eenvoudig lijkt, schaalt het niet en leidt het tot enorme vertragingen en kosten, vooral wanneer je LLM's gebruikt voor gestructureerde extractie.

Het probleem met render-time parsing

Stel je voor dat je een applicatie bouwt die facturen verwerkt. De workflow ziet er vaak zo uit:

  1. De gebruiker vraagt om informatie uit een factuur.
  2. Het systeem haalt de PDF op uit de opslag.
  3. Het systeem start een parsing-proces (bijv. met een bibliotheek of een LLM).
  4. De data wordt geëxtraheerd.
  5. De data wordt naar de gebruiker gestuurd.

Dit proces heeft verschillende nadelen:

De oplossing: Ingestie-tijd parsing

In plaats van de PDF te parsen wanneer de data nodig is, moet je het parsen verplaatsen naar de fase waarin de PDF het systeem binnenkomt: de ingestie-fase.

De nieuwe workflow:

  1. Een PDF wordt geüpload.
  2. Het systeem parseert de PDF onmiddellijk.
  3. De geëxtraheerde, gestructureerde data (bijv. in JSON-formaat) wordt opgeslagen in een database.
  4. De gebruiker vraagt om informatie.
  5. Het systeem haalt de reeds gestructureerde data direct uit de database.

Voordelen van deze architectuur

1. Razendsnelle respons

Omdat de data al gestructureerd en klaar voor gebruik is, is de ophaaltijd minimaal. Je serveert data in milliseconden in plaats van seconden.

2. Kostenbesparing

Je voert het dure extractieproces (zoals een LLM-call) slechts één keer uit per document, in plaats van elke keer dat iemand de data wil zien.

3. Betere data-integriteit

Door de extractie te scheiden van de weergave, kun je validatiestappen toevoegen tijdens de ingestie. Als een PDF niet goed geparst kan worden, kun je dit direct signaleren voordat het in je systeem terechtkomt.

Conclusie

Stop met het parsen van PDF's op render-tijd. Door te kiezen voor een architectuur waarbij extractie plaatsvindt tijdens de ingestie, bouw je systemen die sneller, goedkoper en veel robuuster zijn.