Tech Talk: Een complete aanpak voor het automatiseren van documentinformatie-extractie
Steeds meer organisaties passen Machine Learning en aanverwante algoritmen toe op de geautomatiseerde verwerking van documenten, een vakgebied dat ook wel bekend staat als optische tekenherkenning (OCR).
Als je te maken hebt met grote hoeveelheden visuele of tekstuele bestanden, kun je veel tijd en kosten besparen door ML en automatisering te gebruiken in de juiste tools in plaats van de bestanden handmatig te verwerken.
Dit artikel gaat over de aanpak van een van onze projecten voor de uitdaging van documentclassificatie en informatie-extractie. In het kader van dit project wilde onze klant een geautomatiseerd proces voor het classificeren van documenten toevoegen aan hun al goed ontwikkelde operationele ecosysteem. Het doel was om handmatig door klanten ingevulde PDF-scans te ontvangen, alle benodigde informatie te verzamelen en deze naar de klant te sturen.
De oplossing voor het extraheren van documentinformatie
We creëerden een pijplijn bestaande uit een reeks controles en verwerkingsstappen. Elke PDF doorliep deze pijplijn om volledig te worden verwerkt.
Eerst herkennen we de huidige sjabloon uit een reeks mogelijke sjablonen. De sjabloon wordt herkend aan de voorpagina, die een koptekst en meestal andere speciale kenmerken bevat. Deze kenmerken maken de differentiatie gemakkelijker in OpenCV. We gebruiken de functie cv2.matchTemplate om een correlatiescore te krijgen tussen de eerste pagina van het huidige document en alle eerste pagina's van de database met sjablonen. Als de beste kandidaat een correlatiescore heeft die hoger is dan een minimumdrempel, wordt de sjabloon als herkend beschouwd.
We hebben de database met sjablonen en hun configuratiebestanden ondergebracht in een bucket S3 op AWS, die kan worden opgevraagd vanuit een Docker image dat de pijplijn bevat.
Daarna moest elke pagina van het huidige document dat we moesten verwerken, linken naar de overeenkomende pagina van het geïdentificeerde referentiesjabloon. Het nut van deze stap is om ervoor te zorgen dat de algoritmen weten op welke pagina ze werken. Dit is cruciaal om te bepalen welke informatie overeenkomt met welke vraag in het document. De pijplijn vergelijkt de eerste pagina van een referentiedocument met de eerste pagina van een ander behandeld document, enzovoort. Als er pagina's ontbreken of als scans niet geordend zijn, stuurt de pijplijn het document door voor handmatige controle. Pagina voor pagina vergelijken gebruikt hetzelfde principe als sjabloonherkenning, met veel gebruik van onze dierbare cv2.matchTemplate.
Zodra we de pagina's hebben geïdentificeerd, worden de informatievakken van elke pagina automatisch gedetecteerd. De detectie wordt voornamelijk gedaan met behulp van de functies cv2.morphologyEx en cv2.connectedComponentsWithStats van OpenCV. cv2.morphologyEx past een horizontale en verticale randfilter toe op de pagina's. cv2.connectedComponentsWithStats vindt de gesloten vakken die worden gemaakt door de verticale en verticale randen en geeft hun posities terug. En cv2.connectedComponentsWithStats vindt de gesloten vakken die worden gemaakt door de verticale en horizontale randen en geeft hun posities terug.
Daarna wordt er nog een keer gefilterd om ervoor te zorgen dat de vakken aan bepaalde positie- en afmetingseisen voldoen. Vanuit de uiteindelijke posities worden de informatievakken uit de afbeelding van de hoofdpagina gewist. In ons geval bevatten de vakken de antwoorden op de vragen van het document. De pijplijn specificeert beperkingen in het configuratiebestand van de sjabloon.
Als de pijplijnfuncties niet alle informatievakken op een pagina hebben gedetecteerd, wordt de stap als mislukt beschouwd en stuurt de pijplijn het document door voor handmatige controle.
Deze pijplijn stuurt bijgesneden afbeeldingen naar een Convolutioneel Neuraal Netwerk (CNN). Het reeds getrainde netwerk van neuronen bepaalt elk selectievakje en koppelt het aan een betrouwbaarheidsniveau. Het betrouwbaarheidsniveau is de waarschijnlijkheid geassocieerd met het label van de inhoud van het vakje. Als de waarschijnlijkheid onder een bepaalde drempel ligt, betekent dit dat het model onzeker is over de inhoud en stuurt de pijplijn het document door voor handmatige controle.
Als alle voorgaande stappen zijn geslaagd, stuurt de pijplijn de antwoorden in JSON-formaat naar de cliënt.
De uitdagingen tijdens het extraheren van documentinformatie
Tijdens de ontwikkeling kwamen we een aantal uitdagingen tegen; de verscheidenheid aan sjablonen, de verscheidenheid aan menselijk gedrag en de harde betrouwbaarheidseisen.
Verschillende sjablonen
Ten eerste zijn er voor het bedrijf ongeveer tien verschillende sjablonen in gebruik. Om een goede dekking te hebben, moest de pijplijn er een paar kunnen herkennen. We kozen voor de twee meest voorkomende, die 90% van alle documenten uitmaken. Bovendien hadden we voor elk sjabloon een configuratiebestand nodig voor het algoritme om de gedetecteerde vakken te koppelen aan hun vraagspecificaties.
De oplossing: Omdat deze configuratie complex kan zijn voor een niet-ingewijde gebruiker, hebben we een sjabloongenerator gemaakt waarmee je in een paar klikken een nieuw sjabloon kunt toevoegen.
Verscheidenheid aan menselijk gedrag
Een andere uitdaging was het realiseren van de verscheidenheid aan menselijk gedrag bij het invullen van documenten en proberen daarmee om te gaan. We moesten de afweging vinden tussen het maximaliseren van de dekking van automatisering en het minimaliseren van de complexiteit van het proces. Een complexiteit die toeneemt naarmate je meer specifieke gevallen wilt afdekken.
Bovendien is het, vooral voor de classificatie van dozen met het neurale netwerk, onmogelijk om 0% fout te garanderen in het huidige kader. Omdat de documenten in eerste instantie niet zijn gemaakt om automatisch te worden behandeld, kan er dubbelzinnigheid zitten in de geschreven antwoorden van klanten.
De oplossing: Er is geen goed antwoord om een goede afweging te maken. Afhankelijk van de klant zou je meer tijd kunnen besteden aan het ontwikkelen van een zeer complexe infrastructuur om bijna 100% van de documenten te verwerken, waardoor de dekking wordt gemaximaliseerd. Maar de kosten van het maken van zo'n infrastructuur zouden de winst niet waard zijn. Meestal zal een klant zijn Return On Investment(ROI) willen optimaliseren, rekening houdend met het feit dat papieren documenten steeds zeldzamer worden in het volledig digitale tijdperk.
Wat betreft het vullen van de vakken, de enige manier om hiermee om te gaan is het installeren van een schoon kader waarin we de vulmethode aan de klanten uitleggen. Dat kader zou op toekomstige sjablonen moeten verschijnen.
Een harde eis in betrouwbaarheid voor documentinformatie-extractie
Ten slotte moesten we voldoen aan een harde eis op het gebied van betrouwbaarheid, idealiter 0% fout. In termen van machinaal leren moesten we zorgen voor 100% precisie, wat het gevolg is van het uitputten van de recall, oftewel de dekking.
Een hoge betrouwbaarheid is noodzakelijk voor onze klanten om volledig vertrouwen te hebben in de automatisering en deze te integreren in hun activiteiten. Dit heeft echter tot gevolg dat we minder documenten kunnen automatiseren.
De oplossing: Voor een gegeven architectuur is de typische manier om de beste pijplijn te vinden met deze 100% precisie terwijl de dekking wordt gemaximaliseerd, het optimaliseren van de hyperparameters. Met behulp van de dataset van eerdere documenten kunnen de parameters bij elke stap worden aangepast terwijl aan de twee voorwaarden wordt voldaan. De parameters hier zijn voornamelijk de drempels van correlatie voor sjabloon- en paginaherkenning en de vertrouwensdrempel van het neurale netwerk. Als we een erg strenge drempel kiezen, garanderen we 100% precisie, maar zal de dekking afnemen. Als we de drempel te los kiezen, zullen er fouten optreden en gaat 100% precisie verloren. We hebben twee versies ontwikkeld.
De hulpmiddelen voor het extraheren van documentinformatie
We hebben een reeks tools gebruikt om zo'n pijplijn te implementeren en volledig in productie te nemen, namelijk OpenCV, PyTorch, Docker en AWS.
OpenCV
We hebben veel gebruik gemaakt van de OpenCV bibliotheek in verschillende stappen van het proces. OpenCV is een bekende open-source bibliotheek voor klassieke computervisie. We hebben het gebruikt voor sjabloonherkenning, paginavolgordecontrole en automatische detectie van informatievakken.
PyTorch
We ontwikkelden het neurale netwerkmodel in PyTorch. Het is een Convolutioneel Neuraal Netwerk (CNN), perfect voor beeldclassificatie. Transfer learning werd toegepast door uit te gaan van de voorgetrainde ResNet50 architectuur voordat er werd getraind op de afbeeldingen van de klant. Het CNN geeft de klasse en een waarschijnlijkheidsscore over hoe zeker het is van zijn keuze. Deze score is nuttig om verkeerde classificaties te voorkomen.
Docker
We hebben onze pijplijn in een container geïmplementeerd met behulp van Docker. Het echte voordeel hiervan is dat je je geen zorgen meer hoeft te maken over compatibiliteitsproblemen bij het inzetten op nieuwe servers. Het proces draait in de "black box" container en werkt op elke machine waarop Docker is geïnstalleerd.
Amazon Web Services (AWS) en de Cloud Development Kit
Onze klant had al meerdere services in een stack geïmplementeerd op AWS. We hebben ervoor gezorgd dat dit project aansluit op de rest van hun ecosysteem. In de praktijk betekent dit dat de operaties dagelijks draaien op de servers van Amazon, gehuurd door onze klant.
Het voordeel van het gebruik van de Cloud Development Kit is dat alle infrastructuur kan worden gespecificeerd als code en kan worden ingezet via de opdrachtregel. De belangrijkste componenten die worden gebruikt zijn Buckets, Lambda-functies en de Elastic Container Service en Batch. Dit alles maakt het mogelijk om Docker-containers in te zetten en flexibel aan te passen aan het aantal te verwerken documenten door meer of minder servers toe te wijzen.
AWS biedt ook een tool om op een efficiënte manier menselijke afbeeldingen te labelen op grote datasets. Deze tool was nuttig bij het trainen van het neurale netwerk op de gegevens van de klant. De tool stuurt de labeling naar verschillende personen die het juiste label aan de afbeelding toekennen.
Conclusie
In de uiteindelijke versie van onze oplossing kon de klant 47% van alle documenten automatiseren die na de extractie van documentinformatie naar de pijplijn kwamen. We kunnen gerust zeggen dat dit de klant een aanzienlijke hoeveelheid tijd en kosten heeft bespaard.
Schatting van de winst voor documentinformatie-extractie
Onze klant ontvangt gemiddeld 100 documenten per dag. Het duurt 75 seconden om elk document handmatig te verwerken. De klant schat dat dit ongeveer € 26.000 per jaar kost. Gezien de prijzen van Amazon servers zouden onze installatiekosten minder dan € 100 per jaar moeten zijn, wat te verwaarlozen is. Omdat we ~50% van de documenten automatiseren, is het bespaarde bedrag per jaar ~13.000 €.
Het andere effect is dat, omdat we de architectuur modulair hebben gemaakt, deze met minder kosten kan worden uitgebreid naar verschillende soorten klantdocumenten, waarbij informatie-extractie een rol speelt.
Beperkingen en mogelijke verbeteringen
De pijplijn zal werken als het document afkomstig is van een geschikte sjabloon, met pagina's in de juiste volgorde en het document correct ingevulde informatie bevat in de daarvoor bestemde vakken.
Een ander mogelijk risico dat kan optreden bij dergelijke machine-leerprocessen is de evolutie van gegevens. Dit wordt datasetverschuiving genoemd. Als de soorten sjablonen veranderen, als de kwaliteit van de pdf-scans verslechtert, kan de dekking dalen. Om een dergelijk probleem aan te pakken, moeten dagelijkse prestaties worden gerapporteerd om elk aanzienlijk verschil in resultaten te meten.
Ideeën om de automatiseringsdekking te verbeteren zouden zijn om betere vulrichtlijnen in het document op te nemen en slechts één goede sjabloon voor het document te behouden.
Voor de huidige architectuur zouden twee directe verbeteringen betere resultaten kunnen opleveren: verbetering van de automatische detectie van de vakken (slechts 75% die in de buurt van 100% zou kunnen komen) en een automatische herschikking van de pagina's van een ongeordend document.
Tot slot, om een significante ROI te garanderen, zou het ideaal zijn om de architectuur uit te breiden naar alle documenten die nog steeds handmatig worden behandeld met informatiekaders.
