Discussion technique : Une approche complète de l'automatisation de l'extraction d'informations documentaires

De plus en plus, les organisations appliquent l'apprentissage automatique et les algorithmes connexes au traitement automatisé des documents, un domaine également connu sous le nom de reconnaissance optique de caractères (OCR).

Si vous devez traiter de grandes quantités de fichiers visuels ou textuels, vous pouvez économiser beaucoup de temps et d'argent en utilisant la ML et l'automatisation que l'on trouve dans les bons outils au lieu de traiter manuellement les fichiers.

Cet article présente l'approche adoptée dans le cadre d'un de nos projets pour relever le défi de la classification des documents et de l'extraction d'informations. Dans le cadre de ce projet, notre client souhaitait insérer un processus automatisé de classification des documents dans son écosystème opérationnel déjà bien développé. L'objectif était de recevoir des scans de PDF remplis manuellement par les clients, d'en extraire toutes les informations nécessaires et de les envoyer au client.

La solution pour l'extraction d'informations sur les documents

Nous avons créé un pipeline composé d'une série de contrôles et d'étapes de traitement. Chaque PDF passe par ce pipeline pour être entièrement traité.

Tout d'abord, nous avons reconnu le modèle actuel parmi un ensemble de modèles possibles. Le modèle est reconnu par sa page de garde, qui contient un en-tête et généralement d'autres caractéristiques spéciales. Ces caractéristiques facilitent la différenciation dans OpenCV. Nous utilisons la fonction cv2.matchTemplate pour obtenir un score de corrélation entre la première page du document actuel et toutes les premières pages de la base de données de modèles. Si le meilleur candidat a un score de corrélation supérieur à un seuil minimum, le modèle est considéré comme reconnu.

Nous avons hébergé la base de données des modèles et leurs fichiers de configuration sur un bucket S3 sur AWS, interrogé depuis l'intérieur d'une image Docker contenant le pipeline.

Ensuite, chaque page du document actuel à traiter doit être reliée à la page correspondante du modèle de référence identifié. Cette étape permet de s'assurer que les algorithmes savent sur quelle page ils travaillent. Cette étape est cruciale pour déterminer quelle information correspond à quelle question du document. Le pipeline compare la première page d'un document de référence à la première page d'un autre document en cours de traitement, et ainsi de suite. S'il y a des pages manquantes ou des scans non ordonnés, le pipeline envoie le document pour une révision manuelle. La comparaison page par page utilise le même principe que la reconnaissance de modèles, avec un usage intensif de notre cher cv2.matchTemplate.

Une fois les pages identifiées, les zones d'information de chaque page sont automatiquement détectées. La détection se fait principalement à l'aide des fonctions cv2.morphologyEx et cv2.connectedComponentsWithStats d'OpenCV. cv2.morphologyEx applique un filtre d'arêtes horizontales et verticales sur les pages. Et cv2.connectedComponentsWithStats trouve les boîtes fermées créées par les bords verticaux et horizontaux et renvoie leurs positions.

Ensuite, un autre filtrage est appliqué pour conserver les boîtes qui répondent à des contraintes particulières de position et de dimension. À partir des positions finales, le pipeline récolte les boîtes d'information de l'image de la page principale. Dans notre cas, les boîtes contiennent les réponses aux questions du document. Le pipeline spécifie les contraintes dans le fichier de configuration du modèle.

Si les fonctions du pipeline n'ont pas détecté toutes les cases d'information d'une page, on considère que l'étape a échoué et le pipeline envoie le document pour une révision manuelle.

Ce pipeline envoie les images recadrées à un réseau neuronal convolutif (CNN). Le réseau de neurones déjà entraînés détermine chaque case à cocher et l'associe à un niveau de confiance. Le niveau de confiance est la probabilité associée à l'étiquette du contenu de la case. S'il est inférieur à un certain seuil de probabilité, cela signifie que le modèle n'est pas sûr du contenu, et le pipeline envoie le document pour examen manuel.

Si toutes les étapes précédentes ont réussi, le pipeline envoie les réponses au client au format JSON.

Les défis de l'extraction d'informations sur les documents

Nous avons rencontré quelques difficultés au cours du développement : la variété des modèles, la variété du comportement humain et les exigences élevées en matière de fiabilité.

Variété de modèles

Tout d'abord, pour l'entreprise, il existe une dizaine de modèles différents actuellement utilisés. Pour obtenir une bonne couverture, le pipeline devait être capable de reconnaître quelques-uns d'entre eux. Nous avons opté pour les deux modèles les plus courants, qui représentent 90 % de tous les documents. En outre, pour chaque modèle, nous avions besoin d'un fichier de configuration permettant à l'algorithme de relier les boîtes détectées aux spécifications de la question.

La solution : Parce que cette configuration peut être complexe pour un utilisateur non initié, nous avons créé un générateur de modèles qui permet d'ajouter n'importe quel nouveau modèle en quelques clics.

Variété des comportements humains

Un autre défi a consisté à prendre conscience de la diversité des comportements humains lors du remplissage des documents et à essayer d'y faire face. Nous avons dû trouver un compromis entre la maximisation de la couverture de l'automatisation et la minimisation de la complexité du processus. Une complexité qui augmente avec le nombre de cas particuliers que vous souhaitez couvrir.

De plus, notamment pour la classification des boîtes avec le réseau neuronal, il est impossible de garantir 0 % d'erreur dans le cadre actuel. Les documents n'ayant pas été créés initialement pour être traités automatiquement, il peut y avoir des ambiguïtés dans les réponses écrites des clients.

La solution : Il n'y a pas de réponse correcte pour trouver un bon compromis. En fonction du client, vous pourriez passer plus de temps à développer une infrastructure très complexe pour traiter presque 100 % des documents, maximisant ainsi la couverture. Mais le coût de création d'une telle infrastructure n'en vaudrait pas la peine. En général, un client souhaite optimiser son retour sur investissement(ROI), en gardant à l'esprit que les documents papier deviennent de plus en plus rares à l'ère du tout numérique.

En ce qui concerne le remplissage des boîtes, la seule façon d'y remédier est d'installer un cadre propre dans lequel nous expliquons la méthode de remplissage aux clients. Ce cadre devrait figurer sur les futurs modèles.

Une exigence forte en matière de fiabilité pour l'extraction d'informations sur les documents

Enfin, nous devions répondre à une exigence stricte en matière de fiabilité, idéalement 0 % d'erreur. En termes d'apprentissage automatique, nous devions garantir une précision de 100 %, ce qui a pour conséquence d'épuiser le rappel, c'est-à-dire la couverture.

Une grande fiabilité est nécessaire pour que nos clients aient une confiance totale dans l'automatisation et l'intègrent dans leurs opérations. Cependant, cela a pour conséquence de diminuer le nombre de documents que nous pouvons automatiser.

La solution : Pour une architecture donnée, la façon typique de trouver le meilleur pipeline avec cette précision de 100% tout en maximisant la couverture est de faire l'optimisation des hyperparamètres. En utilisant le jeu de données des documents précédents, on peut ajuster les paramètres à chaque étape tout en remplissant les deux conditions. Les paramètres ici sont principalement les seuils de corrélation pour la reconnaissance des modèles et des pages et le seuil de confiance du réseau neuronal. Si nous choisissons un seuil très strict, nous assurerons une précision de 100 %, mais la couverture diminuera. Si nous choisissons un seuil trop lâche, des erreurs se produiront et la précision de 100 % sera perdue. Nous avons développé deux versions.

Les outils d'extraction d'informations documentaires

Nous avons utilisé une série d'outils pour mettre en œuvre un tel pipeline et le mettre en production, à savoir OpenCV, PyTorch, Docker et AWS.

OpenCV

Nous avons fait un usage intensif du logiciel OpenCV à différentes étapes du processus. OpenCV est une bibliothèque open-source connue pour la vision par ordinateur classique. Nous l'avons utilisée pour la reconnaissance de modèles, la vérification de l'ordre des pages et la détection automatique des boîtes d'information.

PyTorch

Nous avons développé le modèle de réseau neuronal dans PyTorch. Il s'agit d'un réseau neuronal convolutif (CNN), parfait pour la classification d'images. L'apprentissage par transfert a été appliqué en commençant par l'architecture ResNet50 pré-entraînée avant de s'entraîner sur les images du client. Le CNN donne la classe et un score de probabilité sur la confiance qu'il a dans son choix. Ce score permet de s'assurer qu'il n'y a pas d'erreur de classification.

Docker

Nous avons déployé notre pipeline dans un conteneur en utilisant Docker. Le véritable avantage est de ne plus se soucier des problèmes de compatibilité lors du déploiement sur de nouveaux serveurs. Le processus s'exécute dans le conteneur "boîte noire" et fonctionne sur n'importe quelle machine sur laquelle Docker est installé.

Amazon Web Services (AWS) et le kit de développement cloud

Notre client disposait déjà de plusieurs services dans une pile déployée sur AWS. Nous avons veillé à ce que ce projet s'intègre au reste de son écosystème. En pratique, cela signifie que les opérations sont exécutées quotidiennement sur les serveurs d'Amazon, loués par notre client.

L'avantage d'utiliser le kit de développement cloud est que toute l'infrastructure peut être spécifiée sous forme de code et déployée en ligne de commande. Les principaux composants utilisés sont les Buckets, les fonctions Lambda , ainsi que Elastic Container Service et Batch. Tout cela permet de déployer des conteneurs Docker et de s'adapter de manière flexible au nombre de documents à traiter en allouant plus ou moins de serveurs.

AWS propose également un outil permettant d'étiqueter efficacement des images humaines sur de grands ensembles de données. Cet outil a permis d'entraîner le réseau neuronal sur les données du client. L'outil distribue l'étiquetage à différentes personnes qui attribueront l'étiquette appropriée à l'image.

Conclusion

Dans la version finale de notre solution, le client a pu automatiser 47% de tous les documents arrivant dans le pipeline après l'extraction des informations du document. On peut dire que cela a permis au client d'économiser beaucoup de temps et d'argent.

Estimation du gain pour l'extraction d'informations sur les documents

Notre client reçoit en moyenne 100 documents par jour. Le traitement manuel de chaque document prend 75 secondes. Le client estime que cela lui coûte environ 26 000 € par an. Compte tenu des prix des serveurs Amazon, notre coût d'installation devrait être inférieur à 100 € par an, ce qui est négligeable. Comme nous automatisons ~50% des documents, le montant épargné par an est de ~13.000 €.

L'autre impact est qu'en raison de la modularité de l'architecture, celle-ci peut être étendue à moindre coût à différents types de documents de clients, où l'extraction d'informations est impliquée.

Limites et améliorations possibles

Le pipeline fonctionnera si le document provient d'un modèle approprié, si les pages sont dans le bon ordre et si le document contient des informations correctement complétées dans les cases prévues à cet effet.

L'évolution des données est un autre risque qui peut survenir dans ces processus d'apprentissage automatique. C'est ce qu'on appelle le changement d'ensemble de données. Si les types de modèles changent, si la qualité des scans pdf se détériore, la couverture peut diminuer. Pour faire face à un tel problème, il convient de mettre en place des rapports quotidiens sur les performances afin de mesurer toute différence notable dans les résultats.

Les idées pour améliorer la couverture de l'automatisation seraient de créer de meilleures directives de remplissage dans le document et de ne conserver qu'un seul bon modèle pour le document.

Pour l'architecture actuelle, deux améliorations directes pourraient donner de meilleurs résultats : améliorer la détection automatique des boîtes (seulement 75% qui pourraient s'approcher de 100%) et un réordonnancement automatique des pages d'un document non ordonné.

Enfin, pour assurer un retour sur investissement significatif, l'idéal serait d'étendre l'architecture à tous les documents encore traités manuellement contenant des boîtes d'information.