Ce texte est le second d’une série décrivant notre démarche portant sur l’extraction de mots-clés depuis des textes de livres. Consultez d’abord le premier texte pour des explications.

Sélection des textes pour les tests

À cette étape de la démarche, nous souhaitons simplement avoir un aperçu relativement représentatif des résultats des différentes API, et pas faire un travail exhaustif d’analyse. Pour ce faire, il fallait obtenir un échantillon de textes représentatif de notre corpus, dans un format adéquat pour le traitement par les API.

Concernant la sélection, nous avons simplement choisi une centaine de textes au hasard (parmi environ 3700 au moment de début l’expérience), en nous assurant de représenter tous les éditeurs participants au projet (au prorata du nombre de titres disponibles).

C’est sur le format que le défi est plus grand. D’un côté, nos oeuvres sont disponibles au format EPUB, alors que tous les API demandent du contenu au format texte. L’extraction basique de textes depuis un EPUB est relativement simple : il faut extraire tous les fichiers de l’archive, puis retirer le balisage HTML. Cela donne un résultat très imparfait. Par exemple, certains fichiers de l’archive correspondent au « vrai » contenu, alors que d’autres sont plutôt des éléments périphériques (table des matières, notes, index, bibliographie, page de titre, etc.). Il serait probablement pertinent de les traiter différemment.

Nous avons choisi d’accepter les limites associées à l’approche basique. Le code source de notre extracteur, qui convertit un fichier EPUB en plusieurs textes (un par « chapitre », au sens qui lui est donné dans un fichier EPUB), est disponible librement sur le compte Github du projet.

Cela menait donc à devoir choisir un (ou plusieurs) fichier, parmi l’ensemble des « chapitres » extraits de l’EPUB, pour le soumettre aux API de traitement du langage naturel. Comment identifier le plus pertinent sans devoir tout lire? Ou minimalement, comment éviter de soumettre une table des matières ou une page de garde contenant simplement des remerciements? Nous avons choisi d’appliquer une heuristique simple : nous avons sélectionné le texte le plus volumineux, en émettant l’hypothèse que c’était le plus pertinent, et que nous minimisons la probabilité de sélectionner une page de garde ou une table des matières.

L’outil de test et de comparaison.

Les API de traitement du langage naturel n’offrent pas toutes des solutions de test en ligne qui soient en mesure de traiter des textes aussi longs que ceux de nos échantillons. Et il n’était de toute façon pas réaliste d’envisager de réaliser nos 400 tests (une centaine de titres chez 4 fournisseurs) et compiler les résultats à la main. Une approche automatisée était donc nécessaire.

Selon nos recherches, il n’existe pas d’outil permettant d’automatiser la comparaison des résultats de différentes API de traitement du langage naturel, comme le fait l’outil Cloudy Vision que nous avions utilisé lors de notre démarche sur les images.

Nous avons donc choisi de développer un outil semblable, mais adapté à un nouveau besoin. Entre Guillemets est un outil de test d’API de traitement du langage naturel, dont le code source est libre et disponible sous une licence non contraignante. Il permet d’obtenir et compiler les résultats des quatre API que nous avons identifiées (TextRazor, Google Cloud, Rosette et IBM Watson), mais est facilement extensible pour inclure d’autres outils. Il génère des résultats consultables directement sur le web, mais également sous forme d’un tableau Excel récapitulant l’ensemble des résultats.

Les résultats

Les résultats pour la centaine de textes de notre échantillon sont disponibles ici. Une version compilée au format Excel est également disponible.

Pour chaque texte et pour chaque fournisseur, le rapport présente le nombre d’entités trouvées, une vingtaine d’exemples sommaires (triés en ordre décroissant de pertinence, lorsque le fournisseur donne un indicateur quantitatif de pertinence), et 5 exemples détaillés (les données brutes au format JSON, telles que retournées par l’appel de l’API). Nous avons également extrait, lorsque c’était possible les entités correspondant à certaines classes spécifiques : les personnages (fictifs ou pas), les lieux, et les événements ou dates.

Enfin, les rapports contiennent également des informations de référence sur les oeuvres, pour aider à analyser les résultats des API. Ces informations sont le titre, l’auteur, l’éditeur, la description, les catégorisations BISAC et Théma, ainsi que les mots-clés sélectionnés par l’éditeur (lorsqu’il y en a). Il s’agit des métadonnées « traditionnelles » de ces livres, qui seraient typiquement utilisées par les différents sites les présentant.

Les données générées sont massives. Un premier regard permet de constater qu’il y a à la fois des résultats intéressants et étonnants. Le prochain texte de cette série présentera notre analyse plus détaillée des résultats, et nos conclusions sur l’intérêt d’utiliser les outils de traitement du langage naturel pour générer des mots-clés pour enrichir les métadonnées de livres.