Hyperlex propose un logiciel d’identification et d’analyse des informations pertinentes contenues dans vos contrats, facilitant ainsi la numérisation de vos documents.
La plupart des méthodes que nous utilisons reposent sur le traitement automatique du langage naturel (TALN). Nous montrons également dans cet article comment utiliser les tous derniers algorithmes en la matière, afin d’optimiser l’analyse de contrats et améliorer si besoin notre outil TALN.
Il faut tout d’abord importer les documents (souvent scannés au préalable) sur la plateforme, et un algorithme de reconnaissance optique des caractères (ROC) se charge d’extraire le texte à partir des images scannées.
En complément du traitement des documents, il faut également pouvoir cerner correctement les éléments hors-texte, comme les signatures ou les paraphes. Étant donné que ces éléments sont courants, nous proposons une méthode de détection de signatures sur les documents papier, présentée sous la forme d’un guide pratique.
Sur ce répertoire Github, nous fournissons un guide pratique montrant comment créer rapidement un jeu de données et personnaliser un modèle de détection d’objets pour la détection de signatures.
Problématique
Nous allons utiliser des algorithmes de détection d’objets, à même de détecter et de classer différents objets dans une même image, et ainsi de définir des zones autour des objets ciblés.
Nous nous basons sur Faster-RCNN, un modèle reposant sur les réseaux de neurones convolutifs, entraîné à partir du jeu de données fourni par COCO, puis nous utilisons une approche de finetuning pour le spécialiser sur la détection de signatures.
Jeux de données
Notre jeu de données est composé de différents contrats, signés ou non, fournis par nos clients. Pour des raisons évidentes de confidentialité, nous ne pouvons pas publier ce jeu de données.
Nous avons simplement extrait environ un millier d’images de ces contrats pour constituer notre échantillon d’apprentissage.
L’étape suivante a été la création d’un échantillon de test réaliste. Le système de détection de signatures que nous voulions créer devait être suffisamment généraliste pour s’appliquer aux différentes formes de contrats de nos clients (accords de confidentialité, contrats de leasing, etc.).
Afin de réaliser notre échantillon de test, nous avons utilisé environ 200 extraits de contrats (hors de notre échantillon d’apprentissage) pour générer de nouvelles données et juger de la fiabilité de notre système de détection.
Échantillons de données
L’étape suivante consiste à annoter les contrats. Pour des raisons de confidentialité également, nous avons utilisé le logiciel open source VOTT de Microsoft afin d’annoter les contrats. Il existe par ailleurs d’autres très bons logiciels d’annotation d’image (tels que Labelbox ou VGG Image Innotator).
L’interface de création d’un projet sur VOTT
L’utilisation de VOTT est assez intuitive. Après avoir créé un nouveau projet, vous devrez définir une connexion source (d’où charger les documents) et une connexion cible (où enregistrer le projet et les données exportées).
Vous pouvez ensuite ajouter les balises et les étiquettes dont vous avez besoin (dans le cas présent, la seule balise nécessaire est « signature »). Une fois que vous avez effectué cette étape d’annotation, vous pouvez exporter le fichier.
L’interface d’annotation d’image sur VOTT
Dans le répertoire où vous avez défini la connexion cible, vous trouverez le fichier « NOM_DU_PROJET-export.json », contenant toutes les annotations de zones.
Ce fichier json définit un identifiant unique pour chaque élément (« 39469fc1e79e0a3e8235ea772be6dd » dans l’exemple ci-dessous), relié à un répertoire contenant les informations liées à l’image (« asset » dans l’exemple ci-dessous).
Il y figure également une liste de toutes les zones(« regions » dans l’exemple ci-dessous) dont tous les éléments contiennent eux-mêmes un répertoire des données concernant chaque zone.
Entraîner automatiquement le détecteur de signatures
Nous allons utiliser le modèle Faster RCNN, publié initialement dans NIPS 2015. Les auteurs (Shaoqing Ren et al.) ont permis une avancée significative dans la détection automatique d’objets, en concevant un réseau de neurones convolutifs qui retient les zones d’intérêt (qui décide « où » chercher un objet dans une image).
Cela a permis de se passer de l’algorithme de recherche sélective, lourd en puissance de calcul, qui était utilisé dans les modèles précédents comme RCNN et Fast-RCNN pour déterminer ces zones d’intérêt.
Pour en savoir plus sur ces architectures d’algorithmes, nous vous recommandons la lecture de cet article de blog :
👉 R-CNN, Fast R-CNN, Faster R-CNN, YOLO – Object Detection Algorithms
Pour un approfondissement sur Faster-RCNN , nous vous conseillons la lecture de cet article :
👉 Faster R-CNN: Down the rabbit hole of modern object detection
Et de la publication originale :
👉 Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks
Dans le fichier README du répertoire Github, qui est une version modifiée du code de l’API Tensorflow Object Detection (nous y avons retiré toutes les parties du code qui n’étaient pas liées à la détection d’objets et incorporé nos propres données), nous proposons une méthode facile pour la création d’un détecteur de signature en quelques étapes, sans avoir à gérer la partie liée à la programmation ou à tensorflow.
Nous programmons l’apprentissage de notre modèle personnalisé de Faster-RCNN pour 20 epoch, avec un batch size de 8 et un learning rate de 0,0002. Tous les détails concernant la création du jeu de données, de l’apprentissage automatique et du processus d’inférence sont disponibles sur ce lien.
Résultats
Si vous vous êtes intéressé à la détection d’objets, cet indicateur doit vous être familier : la moyenne de la précision moyenne, ou mAP (pour mean average precision).
On commence par définir un critère de superposition : le ratio « intersection sur union », ou IoU (pour Intersection over Union).
L’IoU caractérise l’écart plus ou moins grand entre les aires de boîtes englobantes prédites et de vérité terrain, soit l’écart entre la prédiction et la réalité, et cela permet de déterminer si une zone donnée correspond à :
- Un vrai positif (TP) : IoU > 0,5 et la classe de l’objet est correctement détectée ;
- Un faux positif (FP) : IoU > 0,5 mais la classe de l’objet est incorrecte ;
- Un faux négatif (FN) : IoU < 0,5 ou l’objet n’est détecté ;
Une fois nos trois indicateurs TP, FP et FN calculés, nous pouvons calculer deux autres indicateurs cruciaux : la précision et le rappel, et construire la courbe Précision-Rappel (PR).
La précision moyenne sera donnée par l’aire sous la courbe PR interpolée. Enfin, le mAP est la moyenne des précisions moyennes obtenues pour chacune des classes (dans notre cas, la seule classe existante est « signature », donc mAP=AP).
Pour une explication plus exhaustive de ce qui précède, ou si vous n’êtes pas familier de la notion de mAP, je suggère de lire cet article :
👉 Measuring Object Detection models - mAP - What is Mean Average Precision ?
Pour résumer, le mAP est l’indicateur clé (davantage que la fiabilité ou l’AP, par exemple), car il fonctionne peu importe le modèle et n’est pas affecté par l’inégalité qui peut exister entre les classes (qui peut fréquemment être observée au sein de jeux de données utilisés pour la détection d’objets).
Dans le répertoire Github, nous détaillons la façon dont nous utilisons l’API COCO pour calculer ces indicateurs de fiabilité.
Nous obtenons finalement une performance mAP de 0,894 pour un seuil IoU classique de 0,5. Lorsque nous plaçons le seuil de l’IoU à 0,75 (ce qui signifie qu’une prédiction ne sera déclarée comme vrai positif seulement si l’IoU est supérieur à 0,75), nous observons que la performance chute brutalement à 0,40.
Cependant, un seuil de 0,5 est plus que suffisant dans notre cas, où notre but principal est la localisation de l’emplacement de la signature dans le document, et non la précision stricte de la zone.
Pour nuancer ces résultats prometteurs, nous pourrions faire remarquer que les signatures sont des éléments suffisamment larges et reconnaissables dans un contrat ou un document.
D’autres éléments comme des paraphes ou des phrases manuscrites pourraient s’avérer plus complexes, soit du fait de leur petite taille (auquel cas une des solutions pourrait être de redimensionner l’image, aux dépens de la rapidité de calcul), soit en raison de leur similarité avec les caractères imprimés.
Conclusion
Dans cet article, nous nous sommes focalisés sur la détection de signatures, car il s’agit d’un problème fréquemment rencontré dans nos projets.
Cependant, nous pouvons étendre le champ de détection à tout autre sorte d’écriture manuscrite ou d’éléments susceptibles d’être mal interprétés par un algorithme de reconnaissance de caractères.
En effet, extraire des entités spécifiques – ou des tâches du même ordre – demeure un défi, notamment en raison des multiples aspects que peuvent prendre les documents à traiter : faible qualité de l’image, documents salis ou froissés, polices de caractères spécifiques, caractères autres que latins, etc.
La présence de tableaux ou d’images peut également avoir un impact sur la précision de l’OCR. Ces difficultés sont susceptibles de masquer ou de conduire à une mauvaise lecture des caractères, et donc d’affecter l’analyse et l’extraction d’entités.
Bien entendu, il est également possible d’apprendre à un modèle à détecter différentes sortes d’éléments dans un document (les modèles de détection d’objets sont conçus initialement avec un grand nombre de classes d’objets). Voici ci-dessous certaines autres classes que nous avons explorées :
- signatures et initiales/paraphes
- phrases manuscrites (noms, dates, commentaires, etc.)
- cases à cocher
Cela pourrait également vous intéresser :