Les données constituent un élément clé de la prise de décision. De nos jours, les entreprises déploient des processus complexes pour automatiser la collecte, le stockage et le traitement d'une grande quantité de données. La plupart de ces données se présentent sous forme de documents non structurés. Les solutions logicielles de Berger-Levrault manipulent des documents de natures variées : des factures, des devis, des formulaires, etc. Malheureusement, cette représentation non structurée est difficilement exploitable par la machine. Il devient donc important de concevoir des outils pour le traitement intelligent des documents (IDP). Ces outils ont pour but de capturer, d'extraire et de traiter intelligemment des données provenant de divers formats de documents. Pour cela, il faut utiliser des techniques d'analyse d'image, de traitement du langage naturel et d'apprentissage automatique profond.
BL.IDP a vu le jour en 2019. Toutefois, cet article s'intéresse à la version 2 de BL IDP. Nous allons donc revenir sur ce qu'est BL.IDP v1, et sur ce qu'apporte sa version 2.
BL IDP version 1
Ce projet « Traitement intelligent des documents », ou bien IDP « Intelligent Document Processing » est né au sein de la DRIT (Direction de la Recherche et Innovation Technologiques) de Berger Levrault (BL). Il vise à capturer, extraire et traiter des données à partir de divers formats de documents. Il transforme les données non exploitables en données structurées facilement manipulables par un processus métier automatisé. Sans solution IDP, le processus nécessite une intervention humaine pour lire les documents, extraire les données et les saisir. Le traitement intelligent des documents libère tout le potentiel de l'automatisation.
A la base, IDP version 1, ou ex Deep facture, est un projet ne concernant que les factures : à l’entrée, nous avons une image ou un PDF d’une facture, et nous appliquons la détection d’objet pour détecter l’adresse du destinataire et l’expéditeur, le Logo et le Datamatrix de la facture ; suivi ensuite d'un passage par un OCR « Reconnaissance Optique de Caractères » pour terminer par une couche de contrôle des exigences des factures BL.
Voici l'architecture globale de BL.IDP v1 :
BL IDP version 2
La différence entre la version 1 et 2 d'IDP, ce sont bien l’architecture et les cas d’usage, ainsi que les outils utilisés.
Pour l’architecture, la partie d’entrainement du modèle en IDP v1 se fait en local. Ensuite, nous récupérons le modèle (les poids) et l’ajoutons manuellement sur la plateforme pour pouvoir tester. Quant à la partie d’annotation, elle se fait manuellement sans une plateforme dédiée.
Voici ci-dessous l’architecture proposée pour IDP v2 :
D’après l’architecture, nous remarquons que cette plateforme comporte plusieurs modèles, plusieurs cas d’usages, mais aussi un outil pour l’annotation.
L’architecture interne de ce projet est composée de deux parties essentielles : le service d’entrainement et le service d’inférence. Il est tout à fait logique que le résultat du service d’entrainement soit l’entrée du service d’inférence, le service d’entrainement étant le producteur des modèles, tandis que l’inférence est le consommateur.
Tout commence avec un jeu de données, non annoté. Nous souhaitons créer un modèle capable de détecter des objets dans ce jeu de données. Ainsi : nous faisons passer ce jeu de données au service d’entrainement ; ce dernier applique la sélection d’images ; ensuite les images sélectionnées seront envoyées à l’outil d’annotation ; dans cet outil nous choisissons les objets à annoter ; nous annotons et l’entrainement commence.
A la fin de l’entrainement, le modèle généré sera stocké dans un serveur de stockage de Amazon, Aws s3. Via Kafka, nous informons le service d’inférence que le modèle est sur s3, et qu'il doit donc le récupérer.
A chaque cas d’usage bien spécifié, un modèle est généré et enregistré pour ce dernier. Donc si l’utilisateur fait appel au service d’inférence, et que le modèle associé au cas d’usage est existant, les étapes seront les suivantes :
- Le modèle fait une prédiction sur l'image envoyée ;
- Nous vérifions si cet exemple est bon pour refaire l’entrainement avec ou pas ; si c’est le cas, envoyer l’image au service d’entrainement ;
- Appliquer l'OCR pour les résultats trouvés.
Ce qui diffère aussi la version 2 de sa précédente est l’application de l'apprentissage actif.
L'apprentissage actif
L’apprentissage actif est un sous domaine de l’IA, l’hypothèse clé de ce type d’approches est la suivante : si l’algorithme d’apprentissage est autorisé à choisir les données à partir desquelles il va apprendre, il sera plus performant avec moins de données annotées.
Les systèmes d’apprentissage actif tentent d’éliminer le manque de données annotées ou de disponibilités d’annotateurs, en demandant des requêtes sous forme d’instance non étiquetées qui doivent être annotées par un oracle.
Il existe plusieurs scénarios de problèmes différents dans lesquels l’algorithme peut interroger l’oracle, les trois principaux scénarios sont :
- La synthèse de requêtes par adhésion,
- L’échantillonnage sélectif basé sur le flux,
- L’apprentissage actif basé sur le pool.
Dans BL IDP v2, nous avons appliqué l'apprentissage actif basé sur le pool.
Apprentissage actif basé sur le pool
Pour plusieurs problèmes du monde réel, nous pouvons récupérer une énorme masse de données non étiquetées. C’est ce qui motive ce scénario : nous supposons que nous avons un petit jeu de données étiqueté et un pool de données non annotées, les requêtes sont tirées sélectivement du pool, et les instances sont interrogés d’une manière avide, en fonction de mesure d’informativité utilisée pour évaluer toutes les instances du pool ou d’un sous échantillon de celui-ci.
Nous utilisons ce scénario dans plusieurs domaines de l’apprentissage automatique, comme la classification des textes, l’extraction d’informations, extraction et classification des images, vidéos et audios.
Diagramme de cas d'utilisation
Dans le diagramme ci-dessus, nous remarquons que nous avons deux acteurs dans le système : un annotateur et un data scientist, qui peut être un annotateur aussi. Le rôle d’annotateur est d’annoter les documents qui lui ont été attribué, tandis que le data scientist a plusieurs missions :
- La gestion des modèles : qui consiste à créer des modèles et les supprimer avec la possibilité de modifié le nombre d’itération pour l’entrainement
- Lancer l’entrainement des modèles
- Ajuster la précision avec l’apprentissage actif
- Faire de la prédiction sur des nouveaux documents pour un test visuel
Conclusion
Le projet IDP v2 a pris les bonnes roues. Il fonctionne sur trois cas d’usages, avec des performances prometteuses. Il est donc entre de bonnes mains. Les étapes suivantes sont la comparaison de la solution avec l’existant, l'affinement de la précision des résultats et la généralisation de la méthode pour d’autres types de documents.
Par Toufik Kerdjou
