Source de l’image : Blog Nanonets

Introduction

Dans ce rapport, nous aborderons la manière d’extraire des informations depuis des documents structurés ou non-structurés. Nous parlerons en particulier de la publication de Google, Representation Learning for Information Extraction from Form-like Documents (Apprentissage de représentation pour l’extraction d’informations de documents de type formulaire), qui a été notamment acceptée au congrès de l’ACL 2020.

Si on pouvait ajouter tous les coordonnées de contact tels que le numéro de contact, l’adresse e-mail, l’adresse postale, etc. directement en scannant une carte de visite, ce serait intéressant, n’est-ce pas ? Cette petite fonctionnalité nous ferait gagner beaucoup de temps.

L’extraction d’informations dans les documents est une tâche fastidieuse pour les humains, et bien évidemment, coûteuse. Voyons ensemble certaines approches d’apprentissage profond (deep learning) sur la manière d’extraire des informations.

Consultez le code sur GitHub →

Note: : l’implémentation de code ne fonctionne pas comme prévu. Mais ce sera un bon point de départ pour appliquer le modèle de cette publication.

Les différentes approches

1. Templatic based Information Extraction (Extraction d’information basée sur un modèle)

2. Analyse syntaxique de formulaire sans modèle en représentation visuelle profonde (Deep Visual Template-Free Form Parsing )

3. Attend, Copy, Parse (Suivre, Copier, Analyser)

4. Graph Convolutional Networks (Réseaux Convolutifs Graphiques)

5. Apprentissage de représentation pour l’extraction d’informations de documents de type formulaire (Representation Learning for Information Extraction from Form-like Documents )

   

Source de l’image : ACL Demo Slides

Les approches traditionnelles utilisent des méthodes basées sur des modèles, recherchent les correspondances entre le modèle et le texte océrisé (traité par reconnaissance optique de caractères, OCR,), puis extraient l’information. Mais dû aux variations énormes que peuvent comporter les factures, il n’est pas possible d’appliquer ces approches à grande échelle.

Figure 1

Source : Publication

Les factures issues de vendeurs différents présentent des informations avec des dispositions différentes. L’usage des approches modélisées ne peut pas être mis à l’échelle et risque d’induire des erreurs.

Dans cet article de blog, nous discuterons d’une vue à haut-niveau de ce papier, Representation Learning for Information Extraction from Form-like Documents. Pour en apprendre plus sur d’autres techniques, vous pouvez consulter cet [article de blog] this [blog post] par Nanonets.

Détails de Dataset

Dans ce papier, les auteurs utilisent deux datasets différents.

1. Factures (invoices) : Il y a deux corpus de Factures. Le premier contient 14 237 factures tandis que le deuxième en contient 595. Les factures ne partagent aucun modèle commun. Chaque modèle de facture est différent des autres.

Les corpus de Factures (Invoices corpora) sont des datasets privés.

2. Reçus (receipts) : Ce dataset est un corpus disponible au public de reçus scannés, publié en tant que partie du Robust Reading Challenge ICDAR 2019 sur la Scanned Receipts OCR and Information Extraction (SROIE, ROC de Reçus Scannés et Extraction d’Information).

Ce dataset contient 626 images ainsi que les ground truths (vérités terrain) pour quatre champs d’adresse, de nom d’entreprise, de montant total, et de date. Nous utiliserons uniquement les champs de montant total (total amount) et de date (date) comme cible. Ce dataset contient également des fichiers CSV reconnu en OCR avec les coordonnées et les textes correspondants associés.

Échantillon d’image Échantillon GroundTruth

{
    "company": "BOOK TA .K (TAMAN DAYA) SDN BHD",
    "date": "25/12/2018",
    "address": "NO.53 55,57 & 59, JALAN SAGU 18, TAMAN DAYA, 81100 JOHOR BAHRU, JOHOR.",
    "total": "9.00"
}

Observations

Avant de passer à la partie modèle, parlons de quelques observations.

1. Chaque champ correspond généralement à un type bien compris. Par exemple, les candidats possibles pour le montant total (total amount) seront les instances de valeurs numériques. Un texte comme "Weights and Biases" serait clairement incorrect pour le champ de montant total.

Image Source : ACL Demo Slides

Limiter l’espace de recherche par type réduit drastiquement la complexité du problème. Donc, nous utiliserons quelques librairies pour générer des candidats dans chaque champ. Par exemple, un potentiel générateur de candidat pour le champ date sera la librairie date parser. Nous pouvons aussi utiliser des Cloud Services comme Google NLP pour générer des candidats de manière plus efficace.

2. Chaque instance de champ est associée avec une phrase clef (key phrase). Par exemple, dans la fig1, nous pouvons inférer que les instances de dates sont toujours entourées de phrases clefs Date ou Dated. Il n’arrive pas toujours que les phrases clefs soient sur la même ligne. La solution effective est d’inclure des informations spatiales avec les informations de texte.

Image Source : ACL Demo Slides

Comment inclure des informations spatiales ?

L’information spatiale est incluse en considérant les voisins (neighbors) autour de chaque mot. Pour sélectionner les voisins, les auteurs de ce papier ont défini une zone de voisinage (neighborhood zone).

Zone de voisinage : Pour chaque candidat, la zone de voisinage s’étend jusqu’au bord gauche de la page, et 10 pour cent de la hauteur de la page au-dessus du candidat.

Tout token de texte dont les bounding box ont un chevauchement de plus de 50 pour cent avec la zone de voisinage est considéré comme voisin (neighbor).

3. Les phrases clefs pour un champ sont largement tirées d’un vocabulaire limité. Environ 93% des instances de dates dans les factures sont associés avec des phrases clefs comme "date" ou "dated"(d’après le papier). Cela suggère que ce problème peut être résolu avec un montant modeste de données d’entraînement.

Source d’image : ACL Demo Slides

Toutes les observations ci-dessus sont applicables sur de nombreux champs et sur des documents variés.

Dans ce problème, le pré-traitement des données (data pre-processing) est crucial et plus important que la partie modèle. Regardons le pipeline de data processing utiliser les observations vues plus haut.

Source d’image : ACL Demo Slides

1. Pour extraire du texte depuis l’image, il faut appliquer de l’OCR (ROC). Vous pouvez utiliser des outils open-source comme EasyOCR, PyTesseract ou des Cloud Services comme Google OCR. Dans notre cas, ICDAR a déjà fourni du texte reconnu en OCR.

2. Générateurs de Candidat (Tagging d’entité, entity tagging) : Comme vu dans les observations plus haut, nous allons générer des candidats en utilisant des générateurs de candidats multiples. Puisque le recall du système dans son intégralité ne peut pas excéder le recall des générateurs de candidats, il est important que leur recall soit élevé

3. Module de score et d’assignement : Ce module calcule un score entre 0 et 1 pour chaque candidat de manière indépendante en utilisant un module neuronal, puis nous assignons à chaque champ le candidat avec score qui est le plus probable d’être la véritable extraction de ce champ.

• Cette séparation de score et d’attribution nous permet d’apprendre une représentation pour chaque candidat en se basant uniquement sur son voisinage, indépendamment des autres candidats et des autres champs. Cela nous laisse aussi la liberté d’encoder des règles de business complexes et arbitraires dans l’assigneur si c’est nécessaire, par exemple, que la date d’échéance d’une facture ne peut pas (chronologiquement) précéder sa date de facture, etc…(extrait du papier)

Pour des questions de brièveté, les auteurs ont omis les détails du module d’assignement et ont cité des résultats en prenant un assignement simple, qui choisit le candidat au plus haut score pour chaque champ de manière indépendante des autres champs

Modèle de Score Neuronal

Pour s’assurer que le modèle généralise sur plusieurs types de documents, le modèle essaye d’apprendre des embeddings séparés pour le candidat et pour le champ auquel il appartient, et où les similitudes entre l’embedding de candidat et de champ déterminent le score.

Un autre choix de conception important des auteurs est de ne pas incorporer de texte candidat dans le modèle pour éviter l’overfitting accidentel (surapprentissage). Par exemple, le dataset peut contenir uniquement des factures qui datent d’avant 2020, il est possible que le modèle puisse apprendre que la date de facture (invoice date) doive être antérieure à 2020.

Neighborhood Embedding (Embeddings de voisinage): Les tokens de textes voisins sont plongés en utilisant un tableau de plongement de mots (word embedding table). Chaque position relative voisine est plongée par un embedding positionnel non-linéaire qui consiste de deux couches ReLU-activated avec dropout. Cet embedding non-linéaire permet au modèle d’apprendre à résoudre les différences à petite échelle dans les positions, par exemple entre des voisins qui partagent la même ligne que le candidat et ceux qui se trouvent sur la ligne du dessus. (d’après le paper)

Neighborhood encoding (Encoding de voisinage) : Tous les neighborhood embeddings sont indépendants les uns des autres. Pour capturer la relation entre voisins, un mécanisme de self-attention est utilisé. Cela permet d’écarter les voisins qui ne sont pas pertinents pour la prédiction et de générer une représentation contextualisée des voisins.

Candidate Position Embedding (Plongement de position de Candidat) : La position du candidat est plongée en utilisant une simple couche linéaire.

Puisque les informations sur les positions relatives des voisins en rapport avec les candidats sont déjà capturées dans les embeddings en eux-mêmes, pour nous assurer que l’encoding de voisinage est invariant à l’ordre (arbitraire) dans lequel les voisins sont inclus dans les features, un mécanisme de max-pooling est employé.

Candidate Encoding (Encoding de Candidat) : Un candidate encoding est obtenu en concaténant le neighborhood encoding (encoding de voisinage) avec le candidate position embedding (plongement de position de candidat).

Field Embedding (Plongement de Champ) : La Field ID est aussi plongée en utilisant une Field Embedding Layer (couche de plongement de champ) pour générer une représentation de la field id.

Candidate Score (Score de Candidat) : Le Candidate Encoding doit contenir toutes les informations sur la Candidate Position, ainsi que les détails de voisinage. Il est indépendant du champ auquel le candidat appartient.

Maintenant, nous calculons la CosineSimilarity entre le Candidate Encoding et le Field Embedding. Puisque la valeur de similitude se trouve entre -1 et 1, nous remettons simplement la valeur à l’échelle entre 0 et 1 et nous choisissons le candidat avec le plus haut score.

Résultats

Pour démontrer les bénéfices de ce modèle, les auteurs de ce papier ont proposé deux baselines et ont comparé les résultats.

La baseline bag-of-words (BoW) incorpore seulement les tokens de voisinages d’un candidat (neighboring tokens), mais pas leurs positions. La baseline MLP utilise les mêmes features input que notre modèle proposé, ce qui inclue les positions relatives des voisins du candidat, et encode le candidat en utilisant trois couches cachées (hidden layers).

Ces deux baselines suivent la même approche, en encodant le candidat et le champ de manière séparée.

Il apparaît clairement que ce modèle est plus efficace que ces deux baselines. L’utilisation de la position de voisinage de la baseline MLP offre de meilleurs résultats que la baseline BoW.

L’ordre relatif de l’importance des features :

neighbor text > candidate position > neighbor position

Il est aussi observé que retirer la couche de self-attention mène à une détérioration d’1 point dans le scorer ROC AUC et à une détérioration d’1.7 point dans l’end-to-end max F1.

Représentations de Modèle

La partie captivante de ce papier est qu’ils ont enquêté sur les représentations internes du modèle et qu’ils l’ont visualisé en utilisant t-SNE (Dimensionality Reduction Technique).

Est-ce que vous avez hâte de savoir à quoi ressemblent les représentations ? Voyons ça ensemble.

Points importants :

1. D’après la Fig 4(b), il est clairement évident que les points positifs sont bien regroupés ensemble en cluster, tandis que les points négatifs montrent une distribution spatiale éparse.

2.Il est important de noter que le field embedding (plongement de champ) se trouve au bord du cluster, éloigné des points, plutôt qu’au centre du cluster. Ce schéma est prédit par le fait que la loss function essaye essentiellement de minimiser la cosine distance entre le field embedding et ses positifs tout en maximisant la distance avec ses négatifs, en particulier les positifs des autres champs.

3. D’après la Fig 4(c), un exemple de invoice date se trouve loin du cluster d’invoice date. Il est clairement évident que c’est la faute de l’annotateur, qui a libellé la purchase date (date d’achat) comme invoice date (date de facture).

4. Le Candidate Encoding du sample dans la Fig 4(d) se trouve entre invoice date et due date. C’est expliqué par le fait que ce candidat est entouré à la fois des termes due date (date d’échéance) et date of invoice (date de facture).

5. Le Candidate Encoding du sample dans la Fig 4(e) se trouve loin du cluster invoice date. Après un examen attentif, il a été découvert que c’est dû à une erreur d’OCR, à cause du bruit de scan.

Je pense que visualiser des représentations de modèles, de manière générale, aide grandement pour n’importe quel modèle.

Conclusion

J’espère que vous avez apprécié la lecture de cet article de blog. L’extraction d’information à partir de documents est difficile et complexe. L’augmentation de la précision des générateurs de candidats est encore en recherche, et requiert beaucoup d’expertise dans le domaine. N’hésitez pas à me dire ce que vous en pens