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.

Le défi

L’hypothèse fondamentale derrière le projet TAMIS est qu’on peut enrichir la description du produit livre en s’appuyant sur l’oeuvre elle-même, et pas seulement sur la description qu’en fait l’éditeur. Nos premiers travaux ont porté sur le contenu visuel de la page couverture. Nous abordons maintenant le coeur de l’oeuvre, en tentant d’en extraire des mots-clés pertinents qui serviront à son référencement.

En effet, les sites qui présentent des livres en ligne s’appuient essentiellement sur quelques métadonnées fournies par l’éditeur pour alimenter leurs outils de recherche : titre, auteur, description… et parfois la biographie de l’auteur. Pour bien comprendre les enjeux associés aux mots-clés (et la façon dont Amazon les utilise dans son outil de recherche), nous vous recommandons ce texte, publié sur le blogue de Booknet Canada.

Notre défi est donc de générer, de façon automatisée, des suggestions de mots-clés qu’un éditeur pourrait ajouter à la description de son livre, pour alimenter différents moteurs d’indexation ou de recherche : d’abord celui des librairies en ligne et des bibliothèques, mais éventuellement aussi d’autres, comme Google.

Et l’indexation complète des oeuvres?

Pourquoi ne pas indexer entièrement le contenu textuel de l’oeuvre? Ce serait évidemment une bonne idée : certains rares éditeurs offrent sur leur site web des outils de recherche dans le contenu des textes. Mais c’est l’exception plutôt que la règle. Et à notre connaissance, aucune librairie (ou bibliothèque) en ligne ne le fait. Cela s’explique (probablement) par des considérations techniques, légales et commerciales qui sont en dehors du périmètre de nos travaux.

De plus, pour d’autres contextes, comme celui des moteurs de recherche grand public (lire les Google et autres Bing), l’indexation ne serait possible qu’en rendant public, sur le web, le texte intégral de l’oeuvre. Cela n’est évidemment pas compatible avec la protection du droit d’auteur… ni avec la préoccupation de tous de ne pas divulgâcher les textes!

Le traitement du langage naturel

Le traitement du langage naturel (ou natural language processing en anglais, qu’on voit souvent sous la forme de son abréviation NLP), c’est la branche de l’intelligence artificielle qui porte sur l’analyse de textes. Tout comme pour le traitement des images, c’est un domaine qui a connu de grands progrès au cours des dernières années. Ce champ de recherche a plusieurs applications : traduction, résumés de textes, analyse de sentiments, classification automatique, extraction d’entités.

C’est sur cette dernière application que nous souhaitons nous appuyer pour générer des mots-clés décrivant des oeuvres littéraires. Les « entités », ce sont des mots représentant des objets (des personnes, des lieux, des concepts) qui sont présents dans le texte. Et la « promesse » des algorithmes d’extraction d’entités, c’est qu’ils peuvent nous dire que la phrase « J’ai ouvert le bouquin » fait référence à un livre.

Les API de traitement du langage naturel

Avec les mêmes préoccupations que dans notre démarche sur les images, nous préférons d’abord tenter d’utiliser des outils existants plutôt que de tout développer à partir de zéro. Nos recherches nous ont permis d’identifier plus d’une dizaine de fournisseurs d’API de traitement du langage naturel. Les fonctionnalités offertes, les langues traitées, les modèles d’affaires de toutes ces API sont toutefois très différents. Avant de choisir lesquelles étudier et essayer, il a été nécessaire d’analyser ces caractéristiques pour cibler les solutions adéquates pour notre défi.

Nos notes de recherche sur les 8 outils qui nous semblaient les plus prometteurs sont compilées dans ce document.

Au final, deux caractéristiques semblent déterminantes pour identifier sur quelles API porteront nos essais :

• La possibilité d’extraire des mots-clés ou des entités depuis des textes en français. En effet, certains fournisseurs indiquent traiter un grand nombre de langues, mais il s’avère que le français n’est géré que pour un sous-ensemble des fonctionnalités (c’est le cas de Microsoft Cloud Services au moment de rédiger ce texte). Ou d’autres indiquent qu’ils peuvent traiter des textes en français, mais donneront des entités en anglais, en suggérant de les soumettre à leur moteur de traduction automatique (c’est le cas d’Amazon Comprehend).
• La taille maximale des textes pouvant être traités. Plusieurs des outils sur le marché semblent avoir été pensés pour analyser de courts textes (de la taille d’un tweet à celle d’un article de journal). Dans notre cas, on veut idéalement analyser des livres en entier (ou peut-être un chapitre à la fois).

Sur la base de ces critères, nous avons identifié 4 fournisseurs d’API de traitement du langage naturel pouvant être utiles dans le cadre de notre projet : TextRazor, Google Cloud, Rosette et IBM Watson.

Mise à jour au 22 janvier 2019: Amazon a annoncé que son API Comprehend était disponible en français peu après notre inventaire. Elle n’est donc malheureusement pas incluse dans notre comparatif.

Prochaine étape

Dans les prochains textes de cette série, nous présenterons les étapes réalisées pour arriver à obtenir des résultats de ces API. Nous y présentons également deux outils que nous avons développés dans le cadre du projet, et que nous rendons disponibles en code source ouvert. Nous y présenterons également les résultats obtenus suite au traitement d’une centaine de textes tirés de notre corpus.

Mise à jour: le deuxième texte de la série est maintenant disponible.

Pour connaître le contexte de cette comparaison et la méthodologie utilisée, il faut lire la première partie du texte.

Barème d’évaluation des résultats

Nous avons généré une version tabulaire des résultats détaillés obtenus avec Cloudy Vision, contenant également nos annotations humaines, de façon à accorder une note à chaque résultat d’API. L’évaluation des résultats étant subjective, nous avons choisi de la limiter à une catégorisation selon le barème suivant :

• A : les résultats pourraient être utilisés dans l’état ou presque
• B : les résultats pourraient être utilisés en partie suite à une intervention humaine (corrections, retraits, ajouts)
• C : les résultats ne sont pas utilisables

Il faut noter que notre évaluation est faite dans une perspective d’indexation, pas de description. Il nous apparaît utopique, à ce stade, d’espérer qu’une des API génère des mots-clés suffisamment précis pour décrire la couverture. Nous cherchons plutôt à générer des mots-clés qui peuvent alimenter un moteur d’indexation et de recherche. Le souhait est que l’image soit identifiée quand un consommateur cherche un des mots-clés obtenus par l’API, mais pas d’afficher cette liste de mots au consommateur. Pour cette raison, nous avons accordé des A ou des B quand plusieurs mots-clés convenaient, même si certains pouvaient être parfois être à la limite de ce qui décrit l’image (pourvu que cela restait dans la bonne thématique).

Notre évaluation détaillée est disponible ici.

Évaluation des API

En résumé, nos notes se répartissent comme ceci :

Note	Amazon Rekognition	Microsoft	IBM	Google	Cloudsight	Clarifai
A	6	2	1	3	0	2
B	16	19	15	20	2	30
C	26	27	32	25	44	16

On constate que nous avons accordé très peu de A. En effet, malgré plusieurs résultats impressionnants, il est assez fréquent que les mots-clés contiennent également des termes qui ne s’appliquent pas du tout, ou qu’il manque un élément essentiel. Dans ces cas, nous avons attribué un B.

Si on analyse la situation strictement du point de vue de la note A, la solution Rekognition d’Amazon semble être la meilleure (mais encore, à moins de 13 % d’efficacité, on hésite à utiliser le superlatif). On obtient un portrait différent si on considère les A et les B de façon cumulative :

Note	Amazon Rekognition	Microsoft	IBM	Google	Cloudsight	Clarifai
A et B	22	21	16	23	2	32
En %	46 %	44 %	33 %	48 %	4 %	67 %

Dans ce cas, c’est Clarifiai qui se démarque positivement.

Notons que le mauvais résultat de Cloudsight s’applique à notre contexte : dans pratiquement tous les cas, Cloudsight indique « couverture du livre [titre] ». C’est une bonne description dans un contexte généraliste de reconnaissance d’image, mais c’est inutile (d’où les C) pour nos besoins.

Notons enfin que pour la plupart des API, il y a de grands écarts dans la qualité des résultats selon le type d’image utilisé sur la page couverture. En faisant l’analyse seulement sur les photographies, les résultats Amazon Rekognition se rapprochent de Clarifai sur les notes A et B (63 et 68 % respectivement). Sur les illustrations figuratives (réalistes, pas stylisées), les résultats sont encore meilleurs (88 % pour Clarifai, suivie de Amazon Rekognition et Microsoft à égalité à 75 %).

Vous pouvez pousser l’analyse à l’onglet Sommaire de notre compilation des données.

Notes sur les couleurs

Notre expérience portait également sur l’identification des couleurs dominantes des pages couvertures. Voici quelques notes à ce sujet :

• L’API de Google nous fournit des couleurs sous forme de code hexadécimal. C’est utile pour générer d’autres images dans les mêmes tons, mais inutile pour atteindre les objectifs qu’on cherche (un humain va demander « vert », pas « #00FF00 »).
• L’API de Microsoft retourne certaines couleurs en mélangeant des appellations « humaines » (comme « White ») et des codes hexadécimaux. Elle indique également si la couleur est une couleur d’avant-plan, d’arrière-plan, ou d’accent. Les résultats sont parfois bons, mais aussi parfois plus douteux, comme lorsque le blanc est identifié comme couleur dominante de couvertures pour lesquelles notre classificateur humain n’avait même pas remarqué cette couleur.
• L’API d’IBM identifie les couleurs par leur nom. Toutefois, dans certains cas, l’appellation de la couleur est trop précise pour correspondre à une requête humaine (il apparaît peu probable qu’un consommateur de livre mentionne que la couverture est « rouge d’alizarine »). De plus, elle semble se limiter aux couleurs d’accent, ignorant souvent les couleurs d’arrière-plan, en particulier s’il s’agit de blanc.

Au final, les résultats des l’API d’IBM et de Microsoft (nous avons exclu Google parce qu’il n’offre pas de noms « humains » pour les couleurs) sont similaires selon notre barème d’évaluation. Toutefois, considérant que les résultats sont imparfaits et contiennent des termes peu représentatifs du langage utilisé par les consommateurs, nous croyons qu’il serait possible de faire aussi bien sans utiliser d’API ni d’algorithmes d’apprentissage automatique. Nous explorerons cette option plus tard dans le cadre des travaux de Projet TAMIS.

Notons que nous pourrions également tenter de convertir les codes de couleur fournis par Google vers des noms de couleurs. Nous avons choisi de ne pas le faire ici puisque nous voulions comparer les API disponibles sur le marché sans adaptation supplémentaire.

Autres observations

L’observation détaillée des mots-clés identifiés par les API a permis de constater que dans certains cas, les IA sont en mesure d’identifier des concepts associés aux images, pas seulement les objets qui y apparaissent.

Alors qu’on cherchait à décrire factuellement ce qui était illustré dans les images, nos API nous amènent plus loin. Ces mots-clés ne seraient certainement pas nuisibles pour les objectifs que nous avons, mais ils pourraient également être à la base d’outils de mise en marché innovants (une sélection de livres qui regroupés autour d’une idée évoquée par leur page couverture, par exemple).

Conclusions

À ce stade, considérant les faibles résultats, il ne semble pas réaliste d’utiliser des algorithmes de description par mots-clés automatisés sur n’importe quel lot de pages couverture.

Toutefois, cela pourrait s’avérer faisable sur des lots de titres dont la couverture présente une photographie ou une illustration figurative. On peut donc imaginer qu’un traitement automatisé pourrait s’appliquer à certaines collections, voir à une majorité de titres pour les catalogues de certains éditeurs.

Dans une telle situation, notre recommandation serait d’utiliser l’API Clarifai, ou encore mieux, de combiner les résultats de Clarifai et ceux d’Amazon Rekognition.