Comment transformer des données open-source pour un entraînement NLP
Introduction
De bons ensembles de données sont la base de toute intelligence artificielle réussie, notamment en ce qui concerne le NLP. Un ensemble de données mal maîtrisé, biaisé ou trop léger entraînera un échec de l’IA. En revanche, des ensembles de données bien contrôlés amélioreront les résultats obtenus. Par conséquent, travailler en amont sur les données est un élément fondamental de tout développement.
Nous allons voir ici, à travers un exemple détaillé, les différentes étapes permettant d’obtenir des ensembles de données pertinents, facilement construisibles et accessibles.
Objectif
Notre objectif ici était de réussir à obtenir des ensembles de données permettant de former notre IA pour automatiser les réponses aux demandes de devis (bids) et d’offres (asks) exprimées par email. Il y a de nombreux aspects sur lesquels il est nécessaire de l’entraîner pour obtenir une IA efficace : elle ne doit pas seulement être capable de reconnaître correctement les RFQ (Request for Quotes) – bien que ce soit son but principal –, mais aussi de reconnaître ce qui n’est pas un RFQ, par exemple, les formules d’introduction, les signatures (automatiques ou non), les bavardages, les emails envoyés par erreur ou mal formulés.
Cela implique la possibilité d’apprendre et de s’entraîner sur des notions spécifiques, et donc sur des ensembles de données nombreux et riches. C’est là que notre travail est fondamental.
À propos de l’ensemble de données
Pour développer une IA capable d’analyser les fils d’information et les demandes provenant des emails, il était nécessaire d’obtenir un ensemble de données pertinent pour l’entraîner. Les ensembles de données de ce type ne sont pas facilement disponibles, car les entreprises du secteur financier sont assez prudentes en matière de divulgation des données.
Il existe cependant un ensemble de données de taille considérable, qui regroupe des échanges d’emails des années 2000 dans une grande entreprise américaine du secteur de l’énergie.
L’entreprise étant en faillite, tous les emails non sensibles ont été rassemblés et rendus publics dans un célèbre ensemble de données ayant déjà trouvé de nombreuses applications dans le domaine du NLP, notamment dans l’analyse des sentiments.
L’ensemble de données est un dossier compressé contenant les boîtes aux lettres de 150 employés de l’entreprise : leurs mails reçus, envoyés et supprimés, leur boîte d’envoi, etc. Il contient un total de 517 401 mails.
Ces mails sont à la fois professionnels et informels, comme ceux échangés entre collègues ou même des mails indésirables de l’extérieur.
Le résultat est un ensemble de données extraordinairement riche, mais aussi rempli de données qui sont a priori peu intéressantes de notre point de vue (bavardages classiques entre employés, par exemple). Il est donc important d’avoir une méthode de classification très rigoureuse, afin de tirer le meilleur parti de toutes ces données.
Plus précisément, l’objectif ici est de gérer, après avoir traité ces données, la constitution facile de jeux de données pour l’apprentissage et l’entraînement. Il était donc essentiel de récupérer les éléments essentiels permettant d’identifier facilement les mails, afin de pouvoir les classer facilement.
Une fois l’ensemble de données décompressé (1,5 Go), et parcouru manuellement pour effectuer une première analyse, nous avons constaté un schéma stable dans le format des emails : certains de ses attributs étaient toujours situés au même endroit :
Deux points ont attiré notre attention :
- Une migration de mails a échoué et « gâché » certains mails qui sont remplis de caractères indésirables. Ces mails doivent être identifiés et traités pour être correctement exploités ;
- Des milliers de mails sont des chaînes de mails. Les décomposer nous permettrait d’améliorer le volume et la qualité de notre ensemble de données
L’ensemble de données se présente donc avec les volumes suivants :
Après traitement, cela nous donnerait un total de 622 791 emails.
Traitement des données
Le principal objectif était de pouvoir créer des sous-ensembles, selon nos besoins ponctuels, pour entraîner notre IA sur des ensembles personnalisés. Que peut-on faire avec un ensemble de données aussi vaste ? Nous avons imaginé de nombreux usages liés aux affaires, comme l’identification des noms d’entreprise, des actions, ou la reconnaissance d’entités liées au domaine du trading. Nous avons également envisagé des usages plus génériques : nous pouvons former notre IA à reconnaître les salutations, les signatures d’email et tout ce qui n’est pas pertinent pour les affaires. Ce n’est pas une liste exhaustive : d’autres usages peuvent être déterminés plus tard, en fonction de nos besoins.
Les données avec des méta-données claires sont facilement compréhensibles et accessibles. Il était donc nécessaire d’obtenir et d’isoler autant d’informations que possible à partir des emails, et de les analyser efficacement, pour permettre des requêtes rapides et efficaces.
Le parsing a été facile, car, comme nous l’avons vu auparavant, dans chacun de ces emails, nous étions assurés de récupérer facilement un identifiant associé à un expéditeur, un sujet, un destinataire, etc. En isolant ces éléments, nous pouvons effectuer une classification pertinente, rendant les données faciles à gérer.
Tous les éléments présentés ici seront stockés en tant qu’attributs complets des emails et nous permettront de lier facilement les mails ensemble et de reconstruire la chronologie d’une conversation. Nous pouvons nous concentrer sur l’intérêt du Message-ID. Le Message-ID est un identifiant unique généré par l’outil de gestion des emails de l’entreprise. Il nous permet de reconstituer une chaîne de mails à partir de l’un d’eux, par exemple pour donner un contexte intéressant à un mail à partir de l’ensemble de données.
Le gros du travail a donc consisté en deux tâches clés, toutes deux visant à améliorer la qualité de nos données :
- La correction des emails endommagés lors d’une migration, et désormais difficiles à lire pour une IA : environ 20 000 mails ont été “réparés” sur les 517 401 qui composent l’ensemble de données ;
- Le traitement des chaînes de mails transférés, et leur découpage en mails indépendants, nous a permis d’ajouter 2 663 emails (avec informations mises à jour) à l’ensemble de données
Après traitement des données, nous obtenons quelque chose comme cela pour chaque email :
Solution de stockage
Une fois ce travail terminé, nous avons dû choisir une solution de stockage qui nous permettrait de construire efficacement des ensembles de données pertinents à partir de notre ensemble de données original.
Plusieurs solutions nous ont été proposées, notamment dans le domaine du NoSQL. Nous pouvons noter deux principales, qui sont MongoDB et Elasticsearch.
Voici un tableau comparatif, donnant le meilleur de ces deux solutions dans différents domaines :
| Elasticsearch | MongoDB | |
| Recherche distribuée | ✅ | ❌ |
| Stockage distribué | ❌ | ✅ |
| Recherche en texte intégral | ✅ | ❌ |
| Analyseurs de recherche | ✅ | ❌ |
| Opérations CRUD | ❌ | ✅ |
| Outil de visualisation | ✅ | ❌ |
Nous avons choisi Elasticsearch.
Ce qui a scellé notre choix, en plus de son indexation documentaire, était la vaste gamme de recherches, infiniment adaptable et extrêmement flexible. En plus de la notion de « score », qui donne une valeur à la pertinence du résultat trouvé par Elasticsearch suite à une requête, Elasticsearch dispose d’un puissant DSL basé sur JSON, permettant aux équipes de développement de construire des requêtes complexes et de les affiner pour obtenir les résultats les plus précis possibles d’une recherche. Il fournit également un moyen de classer et de regrouper les résultats.
De plus, nous pouvions utiliser Kibana, l’outil de visualisation d’Elasticsearch.
Facile à utiliser et à configurer, car dédié à Elasticsearch, il nous permet de facilement obtenir une vue d’ensemble de nos données et de formuler intuitivement des requêtes pour construire et évaluer les ensembles de données. Cela a facilité la construction des ensembles de données en nous donnant une meilleure compréhension de nos données. C’est le premier pilier pour construire efficacement nos ensembles de données. Enfin, comme nous ne prévoyions pas de modifier la base de données, l’un des points forts de MongoDB était atténué.
Pour renforcer cette solution et garantir que nous ne passions pas à côté de données pertinentes, plusieurs solutions complémentaires ont été mises en place. C’est là que toutes les autres données que nous avons récupérées entrent en jeu : identifiant, date, expéditeur, destinataire. Toutes ces données nous permettent de reconstruire une conversation. Par exemple, en nous appuyant sur le Message-ID d’un email, nous pouvons récupérer tous les emails pouvant avoir été transférés ou liés à cet email. De plus, connaître précisément les protagonistes et la date d’une conversation permet de la reconstituer à partir d’un seul email.
Le travail réalisé en amont combiné à cette solution nous permet de tirer parti d’un ensemble de données colossal, détaillé et classifié de manière pertinente, ce qui nous permet d’obtenir tout type d’ensemble de données adapté à nos besoins.
Le travail en amont combiné à cette solution nous permet de tirer parti d’un ensemble de données colossal, incroyablement détaillé et classifié de manière pertinente, ce qui nous permet d’obtenir tout type d’ensemble de données adapté à nos besoins.
Grâce à Kibana, nous pouvons visualiser facilement nos données. Ainsi, il ne restait plus qu’à ajouter une pincée d’intelligence humaine pour construire des ensembles de données adaptés à nos nombreux besoins : reconnaissance des entités liées au domaine du trading, noms d’entreprise, signatures, etc.
Conclusion
Comme nous l’avons vu, un travail de préparation important est nécessaire pour obtenir des résultats de qualité avec le NLP :
- Tout d’abord, il est essentiel d’obtenir une source de données brutes pertinentes pour le travail que vous souhaitez accomplir, ce qui peut être très chronophage. En effet, il est assez rare de trouver un ensemble de données qui correspond parfaitement à vos besoins. Il est donc parfois nécessaire de trouver des ensembles de données qui ne correspondent pas exactement au souhait initial, et de les retravailler par la suite. C’est ce que nous avons fait.
- Il est également impératif de penser à une intégration intelligente de ces données. Cela a deux volets :
- Le premier est de travailler sur ces données brutes pour en tirer le meilleur parti : cela peut signifier extraire des méta-données (comme nous l’avons fait ici), travailler sur les données pour les rendre plus conformes à nos besoins, ou même supprimer les données superflues, par exemple.
- Le second aspect de cette intégration concerne le stockage et l’accès à ces données. Comme nous l’avons vu plus tôt, il existe de nombreuses solutions disponibles pour cela. Allant des solutions les plus classiques et éprouvées (Oracle SQL…), aux solutions NoSQL plus récentes et flexibles, telles que MongoDB ou Elasticsearch. Chacune a ses avantages, et il est important de choisir une solution en adéquation avec ce que vous souhaitez réaliser.
Une fois fait, vous avez la base pour construire un NLP robuste.
Le prochain défi est de construire vos ensembles de données et de les préparer pour le NLP. Cela sera couvert dans notre épisode 2, restez à l’écoute !
