Avec l’explosion de la collecte et du stockage de données textuelles, le besoin d’analyser et d’extraire de l’information pertinente de cette masse est de plus en plus présent.
De plus, l’essor des modèles de deep learning pour le traitement automatique du langage naturel (TALN) ont facilité l’usage des données textuelles dans des problématiques opérationnels. Le résumé automatique de texte, au même titre que le question answering, l’analyse de similarité, la classification de document et autres tâches liées au TALN font partie de ces problématiques.
C’est dans ce contexte que le Lab Innovation de Lincoln a décidé de mener des travaux sur le résumé automatique de texte. Ces travaux ont permis d’établir un benchmark des modèles de résumé automatique disponibles pour la langue Française, d’entrainer notre propre modèle et enfin de le mettre en production.
🔥 L’entrainement des modèles
Les données
Avant de pouvoir démarrer nos travaux, il a d’abord fallu construire une base de données pour l’apprentissage de modèles de résumé automatique. Nous avons récupéré des articles de presse depuis plusieurs sites de journaux français. Cette base contient ~60K articles et est continuellement mise à jour.
L’état de l’art
Les algorithmes de résumé automatique peuvent-être séparés en deux catégories : les résumés extractifs et les résumés abstractifs. Dans le cadre extractif, les résumés sont construits à partir de phrases extraites depuis le texte alors que les résumés abstractifs sont générés à partir de nouvelles phrases.
Les modèles de résumé automatique sont assez courants en langue anglaise mais ils le sont beaucoup moins en langue française.
Les métriques
Pour l’évaluation des modèles nous avons utilisé les métriques suivantes :
ROUGE : sans doute la mesure la plus souvent rapportée dans les tâches de résumé, le Recall Oriented Understudy for Gisting Evaluation (Lin, 2004) calcule le nombre de n-grams similaires entre le résumé évalué et le résumé de référence humain.
METEOR : The Metric for Evaluation of Translation with Explicit ORdering (Banerjee and Lavie, 2005) a été conçue pour l’évaluation des résultats de la traduction automatique. Elle est basée sur la moyenne harmonique de la précision et du rappel sur les unigrams, le rappel ayant une pondération supérieure à la précision. METEOR est souvent utilisé dans les publications sur le résumé automatique (See et al., 2017 ; Dong et al., 2019), en plus de ROUGE.
NOVELTY : il a été remarqué que certains modèles abstractifs se reposent trop sur l’extraction (See et al., 2017 ; Krysci ‘nski et al.‘, 2018). Par conséquent, il est devenu courant de mesurer le pourcentage de nouveaux n-grams produits au sein des résumés générés.
Source: Traduction depuis le papier MLSUM [2].
Le déploiement des modèles
Pour l’entrainement des modèles, nous avons utilisé le service cloud Azure ML qui fournit un environnement complet pour l’entrainement, le monitoring et le déploiement de modèles.
Nous avons plus précisément utilisé le SDK python qui permet de gérer tout l’environnement AzureML de façon programmatique, du lancement de “jobs” au déploiement des modèles.
Nous avons toutefois encapsulé notre modèle final dans une application Flask conteneurisée puis déployé via des pipelines de CI/CD sur un cluster kubernetes
Les résultats
Tout d’abord, nous avons fait plusieurs tentatives, en entrainant les modèles sur 10K articles, en faisant varier le nombre de tokens donnés en entrée du modèle (512 ou 1024) et différentes architectures.
Première observation : les métriques ROUGE et METEOR ne semblent pas très adaptées à l’évaluation des performances de nos modèles. Nous avons donc choisi de baser nos comparaisons sur le score de Novelty uniquement et avons sélectionné l’architecture privilégiant les résumés plus abstractifs.
Après avoir poussé l’entrainement de notre modèle sur 700K articles, nous avons amélioré sensiblement les résultats et avons validé une première version que vous trouverez plus bas.
Les points d’attention
Au-delà des performances, cette expérimentation nous a permis de mettre en lumière quelques limites du résumé automatique :
Actuellement, la taille du texte en entrée des modèles de type Transformer est limitée par la capacité en mémoire des GPU. Le coût en mémoire étant quadratique avec la taille du texte en entrée, cela pose un vrai problème pour les tâches de résumé automatique où le texte à résumer est souvent assez long.
Il est très difficile de trouver des métriques pertinentes pour évaluer les tâches de génération de texte.
Faire attention au poids de l’extractif : Nous avons également rencontré plusieurs problèmes liés aux données en elles-mêmes. Le principal problème est que le chapeau de l’article était souvent une paraphrase voire un duplicata des premières phrases de l’article. Cela avait pour conséquence d’inciter nos modèles à être plus extractifs qu’abstractifs en renvoyant simplement les premières phrases de l’article. Il a donc fallu faire un travail de curation en supprimant les articles posant problème pour éviter ce genre de biais.
A vous de tester votre texte 😊 !