Cet article est une suite d'une série en deux parties. Pour le moment, nous allons discuter de notre flux de travail pour notre projet de classification de documents. Premièrement, la page d'accueil de l'application apparaît automatiquement lorsque l'utilisateur exécute le fichier main.py.

Comme illustré à la figure 1, nous présentons deux options. Soit l'utilisateur peut exécuter l'ensemble du processus de l'entraînement des modèles jusqu'à la prédiction des nouveaux documents. Soit, l'utilisateur peut uniquement utiliser la prédiction de documents (basée sur la spécification d'un modèle préalablement entraîné).

Figure 1. Le flux de travail global de l'application de classification et de prédiction de documents

Programmation en Python pour la classification de documents

1. API RESTful Flask

Nous avons développé deux API pour ce projet, fonctionnant simultanément et pour des objectifs différents.

L'API principale agit comme un cadre central. Elle coordonne l'ensemble du processus et du flux de travail et permet une communication fluide entre l'interface utilisateur et les objets Python.

L'API secondaire se trouve dans le fichier main.py. Elle récupère les variables envoyées au système lorsque des requêtes asynchrones s'exécutent lors de la navigation dans l'application (JavaScript). Nous ne pouvions pas récupérer ces informations autrement.

2. Objets Python

Le projet compte au total une dizaine d'objets de classe Python parmi lesquels nous présentons ici les plus importants.

L'objet de classe 'Extractor' de ce fichier peut accueillir un large éventail de formats de fichiers. Cela inclut des documents natifs ainsi que des documents scannés ou des formats d'images. Les formats de fichiers pris en charge sont les suivants :

• formats de fichiers de documents : .txt, .pdf, .doc/.docx, .ppt/.pptx

• format de fichiers image/document scanné : pdf scannés, .bmp, .dib, .jpeg, .jpg, .jpe, .jp2, .png, .pbm, .pgm, .ppm, .pxm, .pnm, .pfm, .sr, .ras, .exr, .hdr, .pi

L'extracteur de documents repose, entre autres, sur les bibliothèques suivantes : win32com, docx, pptx, pytesseract (OCR), pdfminer, pdf2image;

L'objet de classe 'TextCleaner' de ce fichier utilise les méthodes de nettoyage de texte NLP suivantes : suppression du délimiteur (p. ex. '\n'), suppression des balises HTML, analyse de l'URL (en gardant uniquement le nom de domaine tel que, par exemple, ‘cosmetic’ pour www.cosmetic.be), expansion de contraction, correction orthographique (optionnelle), suppression de l'accent, suppression de la ponctuation, suppression des chiffres, lemmatisation, suppression des mots vides, suppression du caractère unique et suppression des espaces blancs supplémentaires.

La correction orthographique est optionnelle, un utilisateur peut l'utiliser ou non. Par exemple, lors de la navigation dans l'interface de l'application, consultez la section suivante. Nous recommandons d'utiliser cette option uniquement lorsque le texte peut être de mauvaise qualité. Par exemple, contenu des réseaux sociaux avec leur langage 'argotisé' et les scans et/ou images de basse qualité où l'OCR pourrait produire des erreurs. Pour les textes connus pour être de bonne qualité (par exemple, les articles scientifiques ou les résumés), il est préférable de ne pas utiliser cette option. Nous avons remarqué que la bibliothèque de correction orthographique remplace parfois des mots corrects par d'autres mots similaires, par exemple 'physique' pour 'topologique'.

La fonction 'supprimer les mots vides' est basée sur une liste de mots vides construite au cours du processus. Cette liste est partiellement basée sur la liste de mots vides existante fournie par certaines bibliothèques NLP (y compris sklearn, spacy, gensim, et nltk). Cette liste est également basée sur le corpus lui-même, car elle inclut tous les mots qui n'apparaissent que dans un document. La logique pour inclure les mots 'rares' est qu'ils ne discriminent pas entre les classes et peuvent être considérés comme du bruit.

En plus de nettoyer le texte, TextCleaner produit également le vecteur TF-IDF nécessaire pour exécuter le modèle XGBoost.

Les deux modèles que nous avons discutés précédemment sont matérialisés par deux autres objets de classe qui ont une structure assez similaire :

1. Répartition train-validation stratifiée

2. Entraînement du modèle

3. Évaluation du modèle sur l'ensemble de validation (30 % de l'échantillon total)

Nous avons dû adapter à la fois des types de jeux de données multiclasses et multilabels lors de l'entraînement. Par conséquent, nous avons choisi d'opérer une répartition train-validation stratifiée au lieu de la répartition train-validation plus conventionnelle.

Lorsqu'un ensemble de données multilabels est confronté pendant l'entraînement, le modèle considère le nombre de classes originales et toutes les combinaisons de classes présentées. Ainsi, le nombre de toutes les combinaisons de classes potentielles est largement supérieur au nombre original de classes. Certaines combinaisons de classes peuvent avoir très peu de documents ou même aucun document.

La figure 2 présente le compte de valeur de chaque combinaison de classes spécifique (comme une multiclass encodée à chaud) pour un ensemble de données donné. Comme mentionné précédemment, nous pouvons voir que certaines combinaisons de classes n'apparaissent pas dans le compte (p. ex. [1 0 1 1 1 1]) car elles n'ont aucun document, et d'autres ont très peu de documents (p. ex., combinaison de classes [0 0 1 1 0 1] n'a qu'un seul document).

Figure 2. Comptes de valeurs de combinaisons de classes pour un ensemble de données multilabels

Dans un tel contexte, le risque avec une répartition train-validation conventionnelle est que certaines combinaisons de classes que le modèle n'a pas encore vues pendant l'entraînement peuvent être présentées lors de son évaluation. À cet égard, la répartition train-validation stratifiée assure que la proportion de séparation train-validation (dans notre cas 70 % contre 30 %) est respectée dans chaque combinaison de classes et qu'aucune combinaison de classes inédite n'est présentée lors de l'évaluation du modèle.

L'objet de classe 'Report' offre une analyse détaillée et approfondie du modèle à la fois globalement et au niveau de la classe, y compris, entre autres, des rapports de classification, des matrices de confusion, des courbes ROC et de précision-rappel. La figure 3 montre quelques exemples de résultats de ce rapport.

Figure 3. Exemples de résultats du rapport de performance

Lorsque l'utilisateur est satisfait de la performance d'un modèle, l'objet 'Prediction' peut prédire une classe de document non étiquetée entrante. Avant d'exécuter son code, cet objet appelle les objets 'Extractor' et 'Cleaner' pour pré-traiter précisément le texte des documents comme pendant l'entraînement.

Navigation à travers l'interface utilisateur de l'application pour la classification de documents

Pour afficher les fichiers HTML conçus pour l'interface utilisateur, le projet actuel s'appuie sur un wrapper d'interface utilisateur graphique (GUI) spécifique à Python (le package pywebview) car il a permis certaines fonctionnalités spécifiques requises pour exécuter le code qui ne seraient pas permises avec des GUIs basées sur le web plus couramment utilisées (p. ex., Google Chrome). Au cours du processus, le système a dû récupérer le chemin complet de certains fichiers ou répertoires, par exemple, pour traiter l'ensemble de données de documents. Bien que cela soit parfaitement réalisable avec pywebview, Chrome téléchargerait le fichier et récupérerait le nom du fichier (sans le chemin) dans des cas similaires.

Nous avons conçu l'interface utilisateur pour être explicite et intuitive. De plus, nous avons essayé de donner à l'utilisateur le contrôle de chaque étape du processus et de lui offrir une visibilité claire sur le déroulement des opérations (rapports intermédiaires fournis après chaque étape et avant de lancer la suivante). L'intention était d'aider l'utilisateur à avoir une bonne compréhension des données, du traitement des données et de la qualité du modèle. La figure 4 montre la page d'accueil de l'interface utilisateur de l'application.

Figure 4. Page d'accueil de l'interface utilisateur de l'application

L'application web de prédiction de documents

Comme mentionné précédemment, l'application web ne couvre que le flux de travail de prédiction de documents (et non le flux de travail d'entraînement de modèle). En ce sens, elle utilise le même code Python que pour l'ensemble du projet (mais seulement les classes et fonctions utilisées pour la prédiction), mais des modifications doivent être apportées en ce qui concerne l'interface utilisateur et le déploiement.

Lorsque l'utilisateur télécharge un document, la prédiction est automatiquement traitée et l'utilisateur est ensuite redirigé vers la page du rapport de prédiction, qui inclut les résultats suivants :

• Le nom du document

• Statut : 'ok' ou 'ko' (signifiant que quelque chose s'est mal passé : le format de fichier n'est pas pris en charge ou le document est ouvert dans un autre système/logiciel)

• Classe prédite

Un autre changement par rapport à l'application locale est que les fichiers HTML ont dû être extraits de pywebview pour les rendre dans n'importe quel navigateur/GUI web (voir la figure 5).

Figure 5. Page d'accueil de l'application web

L'application web a été déployée sur Microsoft Azure pour tester son bon fonctionnement. Nous avons utilisé Docker pour créer l'environnement de développement. Pour utiliser Docker, deux fichiers ont été créés :

• Le 'Dockerfile' nous permet de créer une image Docker du projet avec toutes les exigences pour l'exécuter (y compris tous les packages Python utilisés par le système).

• Le fichier 'docker-compose.yml' donne toutes les instructions nécessaires à l'environnement d'hébergement pour lancer l'application et la faire fonctionner.

Travis CI est un service d'intégration continue hébergé utilisé pour construire et tester les projets logiciels hébergés sur GitHub. En complément de Docker, nous avons également utilisé Travis CI pour créer une pipeline de connexion directe entre le dépôt local (cloné depuis le dépôt actuel) et l'application web déployée sur Azure. Dans l'intérêt de ce projet, il est plus facile de mettre à jour le système avec de nouveaux modèles entraînés.

Conclusion et développements futurs potentiels pour la classification de documents

Globalement, le projet actuel a atteint un point où il est très performant et hautement fonctionnel (qu'il soit utilisé par des utilisateurs inexpérimentés ou par des utilisateurs experts). Tant que nous présentons correctement les données au système (le répertoire contenant les documents de l'ensemble de données avec des sous-répertoires comme noms d'étiquettes), l'application peut accueillir divers formats de fichiers et types de jeux de données (pour la classification de documents binaire, multiclass ou multi-labels).

En ce sens, ce projet offre des outils très polyvalents que nous pouvons adapter à divers cas d'affaires. Enfin, les applications commerciales de ce type de projet sont également virtuellement infinies. Pour n'en nommer que quelques exemples :

• Automatisation de la répartition des documents de l'entreprise (à la bonne personne ou au bon département);

• Automatisation de la répartition et du tri des e-mails

• Amélioration de la performance des moteurs de recherche de documents/texte

• Détection de spam ou de documents frauduleux/atypiques

• Traitement du texte des dossiers médicaux pour détecter des pathologies et des comorbidités (situation de type multilabel). Bien qu'un tel système devrait utilement intégrer des données médicales supplémentaires des patients, notamment des imageries médicales, des résultats de tests.