Une nouvelle approche pour suggérer des catégories BISAC automatiquement

Nous avons déjà expliqué pourquoi nous nous intéressons aux systèmes de classification dans un texte précédent. Et nous avons expliqué avoir obtenu des résultats intéressants, mais insuffisamment précis pour être utiles. 

Après de nouveaux travaux, nous pensons être arrivés à une solution plus satisfaisante!

Ce texte explique comme nous y sommes arrivés et présente quelques résultats.

Rappel sur les classificateurs de textes

Pour comprendre notre démarche, il faut se rappeler comme fonctionnent les classificateurs de textes disponibles sur le marché. Sans s’attarder aux détails techniques et aux nuances, il faut comprendre que les classificateurs de textes en général «apprennent» à classifier à partir d’exemples. On fournit à un algorithme des milliers d’échantillons de textes, accompagnés de la catégorie à laquelle appartient le texte. L’algorithme «s’entraîne» à reconnaître de nouveaux textes, similaires à ceux des échantillons, et prédire dans quelle catégorie il doit le placer.

On peut illustrer le processus comme ceci:

C’est à l’algorithme de déterminer quels facteurs font qu’un texte doit être associé à telle ou telle catégorie. Il le fait essentiellement en établissant des corrélations statistiques entre des mots et des combinaisons de mots, et des catégories. Par exemple, les textes qui contiennent souvent «Bas Canada» et «Haut Canada» sont associés à la catégorie histoire (alors que «Canada» seul est peut être neutre et n’influence pas la catégorie). Ceux qui contiennent «Trudeau» et «Lévesque» sont plus susceptibles de traiter de politique; «influenza» et «appendice» sont des indicateurs de textes en médecine; etc.

Avec de très longs textes, les centaines de milliers de mots de la langue française, et près de 5000 catégories BISAC, on a du mal à imaginer la complexité des calculs statistiques nécessaires pour faire de bons classificateurs.

Les problèmes rencontrés précédemment

Les algorithmes de classification décrits précédemment sont évidemment influencés par la qualité et la quantité des données utilisées pour les entraîner.

Par exemple, si on ne donne en entraînement aucun texte dans la catégorie des biographies, l’algorithme ne pourra jamais identifier des biographies.

De la même façon, si on lui donne en grande majorité des textes classés comme une fiction (sans plus de précision), il fera en grande majorité des prédictions dans la catégorie fiction (…sans plus de précision!).

Notre première version de classificateur BISAC était affectée par ce problème. Les classifications dont nous disposons dans nos jeux de données ne sont pas nécessairement représentatives de ce qu’on veut voir dans nos résultats. On sait qu’on a beaucoup trop de livres classés dans la catégorie BISAC FIC000000 (la plus générale en fiction), on cherche à générer des classifications plus précises et plus riches.

Comment résoudre ce problème? Une approche est d’augmenter le nombre de textes disponibles pour l’entraînement, si on émet l’hypothèse que les nouveaux textes amènent de la diversité dans les catégories. Nous avons augmenté d’environ 25% le nombre de titres disponibles pour l’entraînement dans la nouvelle version de notre classificateur BISAC (essentiellement en traitant les fichiers PDF disponibles; nous avions utilisé les EPUB seulement dans la première version).

Un autre problème de la première version de notre classificateur était qu’il distinguait mal les textes de fiction des textes documentaires. Pour reprendre un des exemples précédents, un roman historique pourrait utiliser les termes «Bas Canada» et «Haut Canada» autant qu’un essai sur la politique à l’époque. Comme le classificateur ne connaît pas le système de classification, qui est hiérarchique (on distingue d’abord la fiction d’autres thèmes, puis à l’intérieur de chaque thème on a des sous-thèmes), il est très difficile pour lui de traiter ces cas.

Une nouvelle approche: on remplace le classificateur par des dizaines de classificateurs qui travaillent en équipe!

Nos travaux sur la nouvelle version du classificateur ont donc été réalisés pour atteindre deux objectifs:

  • trouver une façon «d’aider» l’algorithme à comprendre la hiérarchie du système de classification ;
  • ajuster la quantité de textes utilisés sur l’entraînement pour éviter de «surexposer» les algorithmes à certaines catégories.

Le résultat final est que le classificateur BISAC de TAMIS est en fait constitué d’une quarantaine de classificateurs spécialisés sur certaines «branches» de la hiérarchie BISAC. Ainsi, chaque texte est d’abord passé à un premier classificateur, qui sait distinguer les textes des catégories de premier niveau pour lesquelles nous avons un nombre suffisant d’échantillons. 

Pour chaque catégorie, le classificateur indique la probabilité qu’elle s’applique au texte. Notre algorithme identifie les catégories les plus probables, trouve une classificate «spécialisé» pour chaque, et répète le processus.

Une fois le processus complété, un autre algorithme assemble les résultats, en pondérant les probabilités obtenues de chaque classificateur spécialisé, et arrive à une suggestion de 3 à 5 codes BISAC. Dans certains cas, si la probabilité obtenue de tous les classificateurs est trop faible, aucune suggestion n’est faite.

Note sur la technologie de classification utilisée

Pour nos lecteurs intéressés par les questions de développement logiciel… les autres peuvent passer à la section suivante!

Lors de nos premiers tests, nous avions retenu la solution Comprehend d’AWS pour faire les classification. Cette solution était la seule qui répondait à nos besoins lors de nos travaux il y a quelques mois.

Il s’est toutefois avéré qu’elle n’était pas adaptée à notre nouveau besoin. Nous avons rencontré plusieurs contraintes lors du passage de la recherche au développement. En particulier, la limite sur le nombre de classificateurs personnalisés actifs dans un compte AWS, et le fait que les opérations de classification ne puissent être opérées qu’en lot dans un traitement différé en arrière plan. Cela rendait impossible d’utiliser notre stratégie.

Nous nous sommes alors tournés vers la solution AutoML Natural Language dans Google Cloud. Nous l’avions écartée précédemment parce que c’est un produit toujours en phase «beta» et la gestion du français n’est pas garantie. Malgré cela, les résultats sont impressionnants, et les contraintes d’utilisation sont moins grandes. Nous avons quand même été limités par un quota sur le nombre de classificateurs actifs. Aussi, bien que les opérations de classification soient réalisées en direct (et pas en traitement différé) dans des délais relativement courts, il reste que la performance n’est pas encore instantanée (il peut parfois s’écouler 3 à 5 secondes avant qu’un utilisateur de la console n’obtienne les résultats).

Les résultats

Nous observons de façon générale que les classifications proposées sont plus riches et plus diversifiées. C’était ce qu’on souhaitait.

Pour un livre sur l’histoire des patriotes, l’algorithme propose la catégorie «Political science». Pour le coffret 1967, l’éditeur avait choisi la catégorie «Fiction», l’algorithme propose «Fiction / Sagas» (c’est effectivement une saga!). Pour la biographie de Normand Brathwaite, il propose la catégorie «Performing arts».

Évidemment, comme dans la plupart de nos expériences, nous obtenons également des résultats farfelus ou impertinents. Toutefois, ces suggestions moins intéressantes sont souvent accompagnées d’une cote de «confiance» (nous y reviendrons plus loin) assez faible.

Il arrive aussi que l’algorithme ne propose que des catégories BISAC que l’éditeur avait déjà identifiées… Ça démontre sa précision, bien sûr, mais n’atteint pas nos objectifs d’enrichir les métadonnées. Cela est plus fréquent chez les éditeurs qui indiquent plusieurs catégories (et ont donc vraisemblablement déjà des métadonnées assez riches sur le plan des classifications).

L’utilisation dans la console

Concrètement, dans la console de l’éditeur, une page permet, pour chaque livre, d’obtenir les suggestions. Elle prend la forme suivante:

Dans le haut, on voit les métadonnées que l’éditeur avait documentées. Dans le bas, les suggestions de l’algorithme. Pour les suggestions qui n’avaient pas déjà été choisies par l’éditeur, le bouton «+» permet de confirmer et de l’ajouter aux métadonnées. 

Chaque suggestion est accompagnée d’un indicateur de «confiance». Il s’agit d’un nombre, entre 0 et 100, qui donne une approximation du niveau de pertinence de la suggestion, selon l’algorithme. Un nombre élevé indique qu’il est probable que la suggestion soit pertinente.

Conclusion

Cette nouvelle version de notre classificateur BISAC n’est certe pas parfaite, mais elle résout plusieurs des problèmes de la version précédente. Son développement a présenté plusieurs défis techniques qui ne sont qu’évoqués superficiellement ici. Nous croyons que les résultats améliorés justifient les efforts.

Je cherche un livre à la couverture rouge…

Un des sujets les plus évocateurs quand on parle du projet TAMIS est celui de la couleur dominante des couvertures. L’anecdote du client en librairie qui cherche un livre dont il a oublié le titre, mais dont la couverture est rouge (ou verte ou jaune ou…) est classique. Comme TAMIS permet de générer des mots-clés décrivant les couvertures des livres, nous souhaitons également y intégrer les couleurs dominantes.

Notre première piste consistait à utiliser les mêmes API de vision par ordinateur que nous avions utilisées pour obtenir des suggestions de mots-clés. Les résultats n’étaient toutefois pas concluants sur les couleurs. Certaines API permettaient d’identifier des couleurs dominantes simplement par un code de couleur : #ED032B n’est pas très parlant pour un humain. Celle qui identifiait la couleur par un nom le faisait de façon trop sophistiquée : on s’attend à ce que les consommateurs utilisent des noms de couleurs simples (bleu, jaune, vert), pas des termes plus précis ou nuancés (saphir, ambre, émeraude).

Nous avons donc choisi, pour l’enjeu des couleurs, de ne pas utiliser d’API d’intelligence artificielle. Nous avons plutôt développé un système qui s’appuie sur une analyse des pixels composant l’image, et d’une charte qui permet d’associer des familles de codes à des noms de couleur très simples (grosso modo, les couleurs qu’un enfant de maternelle connaît!).

C’est plus simple à expliquer qu’à mettre ne place, mais ça fonctionne assez bien! La Console TAMIS, dont nous avons présenté un aperçu récemment, intégrera donc des suggestions de mots-clés associés aux couleurs dominantes de la page couverture.

Voici quelques exemples de résultats. Pour chaque image, les 5 couleurs dominantes sont présentées en ordre décroissant d’importance, selon notre algorithme. Lorsque le même nom est répété, c’est que différentes nuances de cette même couleur sont dominantes.

Un aperçu de la console pour les éditeurs

Les travaux dans le projet TAMIS passent progressivement de l’étape de la recherche à celle des applications. La console des éditeurs prend forme. Elle permettra de voir les données générées par les intelligences artificielles, retenir celles d’intérêt, et récupérer les fiches enrichies

Voici un premier aperçu de l’outil qui affiche les descriptifs d’images suggérés par une IA de vision par ordinateur, et permet de choisir les mots-clés les plus pertinents.

Utilisation d’API de classification de textes pour assigner des catégories BISAC ou Thema à des livres (deuxième partie)

Ce texte est le deuxième d’une série de deux décrivant notre démarche portant sur l’assignation automatique de catégories BISAC ou Thema depuis des textes de livres. Consultez d’abord le premier texte pour des explications.

Nous avons soumis une centaine de textes (les mêmes que nous avions utilisés pour notre expérience sur l’extraction de mots-clés) aux classificateurs personnalisés que nous avons bâtis avec TextRazor et Amazon Comprehend. Les résultats seront plus faciles à interpréter si on comprend bien la méthodologie qui a mené à la création de ces classificateurs.

Méthodologie d’entraînement des classificateurs

Amazon Comprehend

Le processus d’entraînement de Comprehend est relativement simple : il faut lui fournir un tableau dans lequel chaque ligne contient d’abord le code de classification, puis le texte correspondant. Nous avons constitué un tel tableau en procédant comme ceci :

  • pour l’ensemble des titres de notre corpus, nous avons extrait les chapitres plus longs qu’une certaine taille déterminée (pour éliminer les « chapitres » EPUB à faible valeur sémantique)
  • puis nous avons associé ces chapitres à chacun des codes BISAC qui avaient été assignés au titre par l’éditeur.

Donc, pour un livre placé dans 2 catégories BISAC par son éditeur, et dont 8 chapitres se qualifiaient, on a 16 (2 x 8) entrées dans le tableau d’entraînement.

Cela a produit un tableau à 117 121 lignes (provenant de 62 461 chapitres différents).

Nous avons choisi d’inclure toutes les données disponibles pour maximiser la taille de nos données d’entraînement (sachant que nous n’aurions pas le minimum suggéré d’environ 1000 textes par catégorie). Nous n’avons pas équilibré le nombre d’échantillons associé à chaque catégorie.

Une fois le tableau transféré dans Comprehend, puis « digéré » (au bout du processus « d’apprentissage », qui prend quelques heures), ce dernier est en mesure de suggérer trois catégories pour tout nouveau texte qui lui est soumis.

TextRazor

L’entraînement de TextRazor est fondamentalement différent sur les données, mais assez semblable sur la technique. Dans son cas, on doit créer un tableau où chaque ligne contient d’abord la catégorie, puis des mots-clés associés à cette catégorie. Dans notre cas, nous avons utilisé les termes du texte descriptif des catégories comme mots-clés. Ainsi, la ligne du tableau BISAC pour les livres de fiction sur les dragons contenait le code FIC009120 et les mots-clés « fiction fantasy dragons mythical creatures ».

Nous avons produit un tableau d’entraînement pour les codes BISAC (en anglais, puisque BISAC n’est disponible qu’en anglais) et les codes Thema francophones.

Une fois entraîné avec ces tableaux, TextRazor peut suggérer un nombre variable de catégories pour un texte (nos résultats vont d’aucune suggestion, jusqu’à dix).

Aperçu des résultats

L’ensemble des résultats de classifications ont été ajoutés aux données de l’expérience précédente sur les mots-clés.

Codes BISAC suggérés par Amazon Comprehend

Comprehend a suggéré 3 codes BISAC pour chaque texte. On constate rapidement toutefois que la majorité de ses suggestions sont des catégories très générales, par exemple « FIC00000 Fiction », ce qui n’ajoute pas à la richesse des classifications déjà identifiées par l’éditeur.

Il y a bien quelques exceptions intéressantes. Par exemple, pour Mathieu 06 — La Colère du roi, l’éditeur avait choisi « JUV000000 JUVENILE FICTION / General », et le classificateur suggère « JUV001000 JUVENILE FICTION / Action & Adventure / General » et « JUV028000 JUVENILE FICTION / Mysteries & Detective Stories », qui semblent pertinents au regard de la description du livre.

On voit également quelques cas où la catégorie suggérée est pertinente, mais peut-être trop précise. L’éditeur de La Science en 30 secondes avait choisi « SCI000000 SCIENCE / General », la catégorie générale pour la science. Le classificateur suggère en plus des sous-catégories plus précises : « SCI004000 SCIENCE / Astronomy » et « SCI075000 SCIENCE / Philosophy & Social Aspects (0,035) ». Considérant la description du livre, on peut deviner que ces thèmes sont également abordés, mais on peut également se demander si le sujet est suffisamment important pour assigner la catégorie au livre.

Cependant, hors quelques résultats intéressants, il y a de très nombreux exemples de suggestions génériques ou erronées.

Codes BISAC suggérés par TextRazor

Dans ce cas, il y a très peu de suggestions. Pour un grand nombre de textes, TextRazor n’a simplement pas émis de suggestion. Nous n’avons pas clairement identifié pourquoi (soit il ne trouvait rien, soit un problème technique non détecté l’empêchait de faire des suggestions, soit le fait d’entraîner avec des étiquettes en anglais puis d’appliquer le classificateur à des textes en français pose problème). Notons toutefois qu’il se reprend sur les cotes Thema (voir plus bas).

Ceci dit, parmi les résultats obtenus, certains sont encourageants. Pour La Construction du droit des Autochtones par la Cour suprême du Canada, l’éditeur avait choisi « LAW110000 LAW / Indigenous Peoples » et TextRazor suggère cinq autres catégories légales (« LAW011000 LAW / Civil Law », « LAW103000 LAW / Common », « LAW018000 LAW / Constitutional »…) qui semblent pertinentes.

Codes Thema suggérés par TextRazor

C’est ce classificateur qui génère les suggestions les plus nombreuses et en apparence les plus pertinentes.

Pour le livre Philippe H. dans l’angle mort dont la description parle de mythomanie et d’épisode psychotique, le classificateur suggère « JM Psychologie », « MKL Psychiatrie » et « JMP Psychopathologie » (ainsi que quelques autres catégories liées, mais en apparence moins pertinentes). Ou pour Félicité T3, il suggère « MBNK Vaccination », ce qui correspond bien à ce qu’on comprend de la description.

Par contre, il arrive souvent que les suggestions soient trop précises, comme « AVRL1 Guitare », « WGGB Bateaux », « AV Musique », « A Arts », « DC Poésie », « AVRL3 Violon » et « AVRG1 Piano », qui sont suggérés pour Passion Islande. On ne doute pas que tous ces thèmes soient mentionnés dans le texte, mais aucun n’est représentatif du texte dans son ensemble.

Dans tous les cas

Pour tous les classificateurs, il faut noter que les outils que nous utilisons, dans l’état actuel des choses, ne connaissent pas les règles associées à chaque système de classification, et ne sont pas en mesure de faire la nuance entre des catégories associées au type d’oeuvre (fiction ou pas) et des catégories « disciplinaires » (science, arts, droit, etc.). Ils ne savent pas non plus exploiter la hiérarchie des catégories (par exemple, dans Thema, AVRL3 correspond à Violon qui est un sous-thème de AV Musique, qui est un sous-thème d’A Arts).

Cela fait en sorte que leurs suggestions sont parfois strictement disciplinaires, même pour des oeuvres de fiction. Dans Thema, cela est « permis » si on assigne d’abord une catégorie de la famille F (Fiction); c’est moins clair pour BISAC.

Ceci dit, nous choisissons de ne pas tenir compte de ces nuances dans le contexte de cette expérience. On cherche à savoir si des classificateurs automatiques peuvent arriver à placer des textes dans des catégories, tout en sachant qu’une application industrielle de la solution demanderait un raffinement supplémentaire.

Analyse des résultats

Pour faire une analyse quantifiée des résultats, nous avons dû choisir une métrique qui permettrait d’évaluer la « performance » des suggestions, et sachant que sa mesure de pourrait pas être automatisée. En effet, dans les expériences typiques en apprentissage machine dont les résultats doivent appartenir à une seule catégorie, on réserve en général une partie des données dont on dispose pour mesurer la précision du classificateur. Dans notre cas, comme on souhaite générer des données supplémentaires, on ne peut pas les comparer avec les données d’origine.

Pour rendre la tâche possible, nous avons choisi de compter combien de classifications suggérées pouvaient être rejetées sur la seule base de la description du livre. Mesurer l’inverse, c’est à dire combien de classifications peuvent être retenues, demande une connaissance assez fine de chaque oeuvre (et on manquait de temps pour lire une centaine de bouquins!). Par contre, identifier qu’une catégorie « juvenile fiction » suggérée pour un roman érotique doit être rejetée est relativement simple.

Dans le cas des thèmes BISAC, nous avons également calculé la redondance des suggestions, c’est-à-dire le nombre de suggestions qui correspondaient à des classifications déjà identifiées par l’éditeur. Cette métrique est utile, mais doit être interprétée :

  • si elle est basse, cela signifie que les classificateurs ne suggèrent pas souvent la ou les classifications assignées par l’éditeur (donc qu’ils ne reconnaissent pas bien les textes)
  • si elle est élevée, cela signifie que les classificateurs n’amènent pas beaucoup de valeur, car ils suggèrent des classifications déjà identifiées.

Nous avons compilé les données à l’onglet Analyse de notre tableau de compilation des résultats des classificateurs.

Les valeurs moyennes obtenues pour chacune des métriques reflètent toutefois assez mal l’effet d’ensemble constaté lors de l’observation des suggestions pour chaque titre. C’est en segmentant les résultats par type de livre (fiction, fiction juvenile ou non-fiction) qu’on peut observer les tendances les plus intéressantes. On observe en particulier pour les textes de non-fiction :

  • que TextRazor suggère significativement plus de catégories Thema sans pour autant augmenter le nombre de rejets
  • c’est également le cas pour ses suggestions de catégories BISAC, quoique le nombre de suggestions soit faible
  • qu’au contraire, pour Amazon Comprehend, les rejets sont plus élevés.

Conclusion

Au regard des résultats, il apparaît que les classificateurs que nous avons entraînés, dans l’état actuel des choses, ne seraient pas utilisables. Ils génèrent trop de bruit et pas assez de signal.

Cependant, l’approche demeure prometteuse. Malgré les problèmes relevés, il reste somme toute fascinant de constater qu’avec un entraînement de base, qui ne tient pas compte de la hiérarchie et des subtilités des systèmes de classification, on obtienne des résultats qui sont assez souvent bons ou presque bons.

Nous sommes donc convaincus qu’il serait possible d’arriver à des résultats significativement meilleurs en retravaillant nos données d’entraînement. En effet, en apprentissage machine, les données sont parfois aussi importantes (sinon plus) que les algorithmes. Dans notre cas, les données pourraient être mieux équilibrées (pour éviter les biais qui amènent Comprehend à suggérer les mêmes catégories à plusieurs reprises) et hiérarchisées (pour séparer les textes de fiction des autres avant d’établir les catégories « disciplinaires »).

Utilisation d’API de classification de textes pour assigner des catégories BISAC ou Thema à des livres (première partie)

Jusqu’à maintenant, dans le contexte du projet TAMIS, nous nous sommes intéressés à la génération de mots-clés descriptifs des oeuvres, qu’ils soient tirés de l’image de la page couverture, ou du contenu lui-même.

Les mots-clés sont évidemment importants, mais le choix d’une catégorie au sein d’un système de classification normalisé l’est également. Il existe différents systèmes de classifications. Le système BISAC de BISG (ou des variantes régionales) est utilisé internationalement, en particulier chez les revendeurs de livres numériques (mais pas seulement). La CLIL en France a également un système de classification normalisé. Plus récent, le projet Thema, porté par EDItEUR, propose un système normalisé à vocation internationale (multilingue et disposant « d’extensions » régionales).

Plusieurs librairies en lignes s’appuient sur ces catégories pour placer les livres dans le bon « rayon » virtuel. C’est le cas d’Amazon, qui utilise deux codes BISAC (et certains mots-clés spécifiques) pour déterminer la ou les catégories dans lesquelles le livre sera placé.

Pourquoi générer plus de catégories?

On peut vouloir générer plus de catégories pour différentes raisons.

Plusieurs titres sont décrits avec un seul code de catégorie BISAC. En fait, plus de 35 % des titres du corpus constitué par les éditeurs participant au projet TAMIS sont décrits par un seul code BISAC (et parfois aucun). Il s’agit là d’une opportunité manquée : un livre décrit avec plus de codes BISAC apparaîtra typiquement dans plus de catégories, et aura donc plus d’opportunités d’être présenté à la clientèle qui navigue sur le site de la librairie en ligne.

De plus, le standard Thema présente un potentiel intéressant pour l’industrie, mais souffre d’un déficit d’adoption large. Dans notre corpus, 0,4 % des livres présentent un code Thema (il faut noter qu’il existe des tables de correspondance de BISAC vers Thema, mais elles ont leurs limites, qui sont elles-mêmes amplifiées si la description BISAC à l’origine n’est pas suffisamment riche).

Enfin, certains livres de fond ne disposent tout simplement pas de classification dans les systèmes récents. C’est le cas par exemple, pour des oeuvres indisponibles qui seraient numérisées et rendues disponibles commercialement : sans code BISAC (ou autre), peu de visibilité dans les rayons de librairies en ligne.

Comment l’intelligence artificielle et le traitement du langage naturel peuvent-ils aider (ou pas) à la classification des livres?

En traitement du langage naturel, le problème de classifier ou catégoriser des textes est hyper connu. L’exemple classique, qu’on trouve dans tous les textes d’introduction au traitement du langage naturel, est celui des filtres antipourriel (antispam). Ces filtres sont en fait des classificateurs, qui à partir d’un texte (le contenu d’un courriel) peuvent lui assigner une catégorie dans un système qui n’en contient que deux : pourriel et non-pourriel.

Il y a plusieurs autres applications pratiques semblables : diriger des courriels d’assistance technique vers le bon département, catégoriser des gazouillis selon qu’ils sont d’intérêt pour faire de la veille sur un sujet précis, placer des textes de blogue dans des catégories, etc.

Les algorithmes permettant de classifier du texte sont donc très bien documentés.

Le cas du livre est toutefois significativement plus complexe, pour plusieurs raisons :

  • les textes sont longs, très longs (des centaines ou des milliers de pages, c’est beaucoup plus que 140 caractères!);
  • le nombre de catégories est très grand (la dernière édition de BISAC compte près de 5000 catégories; c’est approximativement la même chose pour la version de base Thema, sans les qualificateurs; et la « petite » classification de la CLIL dépasse le millier de catégories);
  • les catégories ne sont pas mutuellement exclusives, et il est normal (même souhaitable) qu’un livre se retrouve dans plusieurs catégories.

Ces caractéristiques guideront le choix des API que nous pourrons utiliser pour tenter de générer des suggestions de classifications pour nos oeuvres.

Inventaire des API de classification disponibles

Dans le cadre de notre démarche précédente d’identification des API de traitement du langage naturel, nous avions documenté les options pour créer des classificateurs personnalisés des différents outils disponibles sur le marché. Il est possible de créer des classificateurs personnalisés dans plusieurs cas, mais la liste de candidats se rétrécit rapidement si on tient compte des particularités du livre, déjà évoquées. À titre d’exemple :

  • IBM Watson est éliminé parce qu’il ne peut classifier que des documents d’au plus 60 mots;
  • Microsoft Cognitive Services est quant à lui limité à 5000 caractères;
  • Google Cloud AutoML ne pose pas de problème sur la longueur des textes, mais est limité à un maximum de 100 catégories (et la gestion des langues autres que l’anglais n’est pas garantie).

La plupart des outils offrent des systèmes de classification maison (par exemple, chez Google) qui n’ont pas de correspondances dans le domaine du livre. Ils n’ont donc pas d’intérêt dans notre démarche.

Au final, nous avons retenu deux outils qui nous permettraient de faire des classificateurs adaptés à nos besoins : Amazon Comprehend et TextRazor.

Amazon Comprehend

Amazon Comprehend est une API qui permet d’utiliser l’approche classique pour la création d’un classificateur : on lui fournit des centaines d’exemples de textes de chaque catégorie, et la machine « apprend » à identifier les catégories. Par la suite, le classificateur « prédit » des catégories pour de nouveaux textes (qui typiquement ne lui ont évidemment pas servi de donnée d’entraînement).

Comprehend est limité à 1000 catégories, et doit être entraîné avec au moins 50 textes par catégorie (mais il est recommandé de fournir 1000 textes par catégorie pour avoir de bons résultats).

Ces contraintes ne sont pas complètement compatibles avec le projet, mais nous avons choisi de tenter l’expérience quand même. D’une part, bien que BISAC comporte près de 5000 catégories, notre corpus en couvre à peine plus. Et d’autre part, bien que nous n’ayons pas un nombre de livres suffisant pour la contrainte des 50 textes pour chaque catégorie, on peut s’en approcher en considérant chaque chapitre d’un même livre comme un texte différent.

Ces choix amènent quand même des réserves sur les résultats que nous obtiendrons : il s’agira d’un aperçu du potentiel, mais pas d’un résultat optimal (le résultat optimal pourrait être atteint en ayant un nombre élevé de titres dans toutes les catégories BISAC).

TextRazor

TextRazor permet de créer des classificateurs personnalisés sans faire d’entraînement sur des textes exemples, mais en s’appuyant simplement sur quelques mots-clés associés à chaque catégorie. C’est une approche originale qui permet d’envisager deux résultats impossibles avec l’approche classique d’entraînement sur des exemples de textes :

  • identifier des catégories BISAC pour lesquelles nous ne disposons d’aucun échantillon
  • créer un classificateur Thema alors que nous ne disposons de pratiquement aucune donnée relative à ce standard.

Prochaine étape

Dans le prochain texte de cette série, nous présenterons les résultats obtenus suite au traitement d’une centaine de textes tirés de notre corpus pour générer des suggestions de codes de catégories BISAC et Thema. Nous commenterons également les résultats.

Mise à jour: le deuxième texte est maintenant disponible.

Comparaison de 4 API d’extraction de mots-clés appliquées à des textes d’oeuvres littéraires (troisième partie)

Ce texte est le troisième et dernier 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, et le second texte pour une description de notre méthodologie.

Les données obtenues avec les outils que nous avons développés représentent un très grand volume d’information, et leur pertinence varie selon l’angle d’analyse que nous prenons, et les objectifs que nous tentons d’atteindre. Nous ferons donc une analyse de ces données selon trois approches différentes : la quantité, la qualité et la précision.

1. Quantité : est-ce que les API identifient vraiment un volume significatif des mots-clés qui ajoutent à la trouvabilité?

On s’intéresse ici au nombre de mots-clés identifiés par les API et qui enrichissent vraiment la description qui avait préalablement été réalisée par l’éditeur. En effet, une API qui n’identifierait que des mots-clés apparaissant déjà dans les métadonnées du livre ne serait pas très utile.

Dans cette perspective, nous avons établi deux indicateurs quantitatifs pour chacun de nos échantillons :

  • le nombre absolu de mots-clés obtenus des API qui étaient redondants (déjà présents dans le titre, la description ou la liste de mots-clés)
  • le pourcentage correspondant (proportion du résultat d’une API qui est redondant)

Les résultats sont présentés dans le tableau suivant, sous la forme d’une moyenne par titre :

Les données brutes, compilées titre par titre, et les formules utilisées pour obtenir ces résultats sont disponibles dans notre version tabulaire des données. Notons qu’il faut évidemment interpréter ces indicateurs avec réserve. D’une part, ils ne tiennent pas compte de la qualité des mots-clés générés. D’autre part, notre vérification à savoir si un mot est déjà présent dans les métadonnées est très basique (une comparaison des chaînes de caractères, qui ne tient donc pas compte des variations en genre et en nombre, par exemple).

TextRazorIBM Watson (entités)IBM Watson (mots-clés)Google Cloud
Rosette
Nombre de mots-clés identifiés689,246,250,01748,154,0
Redondants avec les métadonnées8,95,51,7230,14,3
Pourcentage de redondance2,4 %12,5 %3,4 %13,2 %12,4 %
Pourcentage d’originalité97,6 %87,5 %96,6 %86,8 %87,6 %

Le tableau permet quand même de constater une grande variabilité sur le nombre de mots-clés obtenus : TextRazor et Google Cloud sont particulièrement « verbeux », mais TextRazor semble identifier plus de termes originaux (~97,6 % de ses résultats le sont) que Google Cloud (à 86,8 %).

Dans le cas d’IBM Watson, il semble important de noter deux choses :

  • L’API retourne au maximum 50 résultats, parce que nous avons laissé la valeur « par défaut » au paramètre du nombre d’entités à retourner (nous avons également utilisé les paramètres « par défaut » pour toutes les autres API). Ça explique les volumes plus faibles, mais il faut retenir que Watson pourrait retourner plus de résultats.
  • Nous avons choisi d’afficher les résultats des entités et des mots-clés (deux types de requêtes différentes à l’API). Aucune des autres API utilisées n’offrait deux catégories de résultats avec des volumes suffisants pour être pertinents dans notre analyse.

Enfin, on observe certains écarts dans les indicateurs d’un éditeur à l’autre. Sans avoir fait une analyse approfondie, il semble que dans certains cas, les chiffres de redondance sont plus élevés chez les éditeurs qui documentent eux-mêmes des mots-clés, que chez ceux qui ne le font pas (ce qui serait donc plutôt un indicateur du « bon travail » de l’éditeur, qu’une qualification du travail des API).

Chose certaine, avec les résultats quantitatifs obtenus, on pourrait dire que les API ajoutent significativement à la trouvabilité, si on ne tenait pas compte de la qualité des résultats.

2. Qualité : est-ce que les mots-clés générés sont pertinents?

Évidemment, dans ce cas, la réponse est plus subjective. Comment déterminer la pertinence d’un mot-clé? Est-ce qu’un mot est pertinent s’il est représentatif du contenu de l’oeuvre? Ou plutôt s’il correspond à un élément anecdotique du point de vue du texte, mais important pour attirer l’attention d’un grand nombre de consommateurs? Est-ce que certains mots-clés, même s’ils permettent d’atteindre l’objectif d’augmenter la trouvabilité du livre, devraient être proscrits, parce qu’ils pourraient révéler une partie de l’intrigue? Est-ce que la réponse à la question précédente est la même selon que les mots soient affichés aux acheteurs, ou simplement indexés, mais pas affichés?

Sans avoir de réponses à toutes ces questions, nous faisons quand même des observations sur les résultats des différentes API analysées.

TextRazor

TextRazor impressionne par le nombre, la diversité et la précision des entités qu’il identifie.

Par exemple, pour le recueil Les nouvelles du père, il identifie 400 entités, dont :

  • des objets du quotidien, comme « photographie », « cigarette » ou « ascenseur »
  • des marques et des produits, comme « YouTube », « Mattel » ou « PowerPoint »
  • des personnes ou des personnages, par exemple « Henri Ford » ou « Dora »
  • des lieux, comme « Vieux-Québec » et « Sainte-Brigitte-de-Laval »
  • des éléments un peu plus abstraits, ou des concepts, comme « sommeil », « sourire », « innovation » ou « divorce »

On peut présumer que certains de ces mots-clés seraient d’intérêt pour différents acheteurs potentiels du livre. Et à première vue, dans aucun cas ces mots-clés ne semblent nuisibles.

TextRazor n’identifie toutefois pas strictement des mots présents dans le texte, il identifie l’entité. Dans Noémie 21 — Papa Dracula !, il a identifié « Lycanthrope », alors que le texte mentionnait « même si, au loin, les sirènes hurlent comme des loups-garous ». C’est peut-être un problème du point de vue de la trouvabilité : l’acheteur type cherchera probablement « loup-garou » et pas « lycanthrope ».

Notons que TextRazor identifie des sujets (Topics), qui pourraient également être une source intéressante de mots-clés.

IBM Watson

Dans nos résultats, Watson identifie un moins grand nombre de mots-clés que les autres API (voir l’explication plus haut, dans l’analyse quantitative), mais présente des résultats sous trois formes différentes, qu’il appelle entités, mots-clés et concepts. Par exemple, pour le livre J’ai confiance — Réflexion (sans cynisme) d’un jeune politicien de Simon Jolin-Barrette, il identifie :

  • des entités, comme « États-Unis », « État québécois » et « Trump »
  • des mots-clés, comme « centralisation du pouvoir », « sens de l’état » et « service public »
  • des concepts, comme « Justice », « Culture », « Démocratie ».

On pourrait questionner qu’est-ce qui correspond à quoi (« centralisation du pouvoir » pourrait être un concept), mais dans notre perspective d’enrichir la trouvabilité des livres sans nécessairement afficher les mots-clés (au sens large, pas le sous-ensemble des résultats de Watson), tout est utile.

Évidemment, les exemples que nous choisissons sont intéressants, mais Watson sait également identifier des banalités : au 3e rang des entités les plus pertinentes, on trouve « un » (le chiffre).

Google Cloud

Dans le cadre de nos tests, les outils de traitement du langage naturel de Google ne produisaient que des entités.

Pour Les Fées-du-phénix T3, l’API a identifié les personnages principaux et différentes entités pertinentes (comme « fées »), mais on note surtout qu’il sait identifier des noms communs pour les lieux et les personnes (alors qu’on remarque surtout des noms propres chez les autres API) :

  • « souterrains », « extérieur » et « montagne » pour les lieux
  • « combattant », « enchanteur », « guerriers » ou « vengeurs » pour les personnes

Autre élément distinctif, l’API sait identifier des événements : « bataille », « victoire », « adieux », « tempête ».

Rosette

Comme Gloud Cloud, dans le cadre de nos tests (lire : avec des textes en français), Rosette ne sait qu’identifier des entités. Un survol des résultats obtenus semble indiquer que cette API donne beaucoup d’importance aux personnes et personnages.

Elle identifie néanmoins également d’autres mots-clés. Par exemple, dans À Juillet, toujours nue dans mes pensées, elle identifie « Chine », « France », « Jujube », « Bingo ».

3. Précision : est-ce que les API identifient bien les concepts?

Dans la perspective de notre projet, il importe peu de savoir si les API ont bien compris le sens des mots-clés qui sont identifiés : on voudra les inclure (ou pas) dans les métadonnées pour que le titre sorte lors d’une requête sur le terme concerné. On ne cherche pas à faire de l’affichage ou à bâtir un graphe de connaissances.

Il nous apparaît néanmoins pertinent de se poser la question de la précision. Les réponses pourraient être importantes si on s’intéresse à d’autres applications potentielles des outils de traitement du langage naturel pour la mise en marché des livres. Il y en a plusieurs, qui sortent du cadre de la présente analyse, mais on peut rapidement évoquer la géolocalisation des oeuvres sur une carte, le référencement et l’optimisation pour les moteurs de recherche, le web sémantique et les données structurées et liées…

Les résultats sont mitigés. Dans certains cas, comme Biographie d’un discours d’André Pratte, TextRazor identifie bien que…

  • « Toronto », « Plaines d’Abraham » et « Le Bourget » correspondent à des lieux
  • « James Wolfe », « Élisabeth II » et « La Fontaine » sont des personnes
  • « Église catholique », « Parti libéral du Canada » et « les républicains » sont des organisations
  • et enfin que « Révolution française » et « Rébellion des Patriotes » sont des événements.

Mais pour le même texte, il identifie également des entités douteuses : « désespérés » comme lieu (le texte disait « Désespérés d’être venus trop tard pour jouer leur tête dans les événements de 37 »), « le nôtre » comme personne, ou « Mgr » comme organisation.

Les résultats varient évidemment d’un texte à l’autre. Anecdotiquement, les API semblent avoir un peu plus de mal avec les expressions typiquement québécoises. Dans Séraphin, « Ti-Mousse » et « Astheure » sont des lieux et « yâble » un événement.

Notons que pour chaque entité, les API donnent généralement un indicateur de confiance sur la pertinence de leur choix. Dans notre analyse, nous avons choisi d’utiliser cet indicateur exclusivement comme moyen de trier les mots-clés des plus intéressants aux moins intéressants. Il aurait également pu être utilisé comme filtre (pour exclure toutes les entités dont l’indicateur de confiance est inférieur à une valeur donnée). Peut-être que certains des cas inappropriés seraient éliminés.

Chose certaine, la conclusion concernant la précision dans le cadre d’applications allant au-delà de la simple indexation de mots-clés, est que malgré une précision étonnante dans certains cas, la présence quasi systématique d’erreurs rend impossible une utilisation directe des résultats associés à des concepts, sans supervision humaine.

Enfin, mention spéciale pour deux API, qui donnent des liens vers des bases de données ou des graphes de connaissances publics. TextRazor inclut presque systématiquement des liens vers Wikipédia, ainsi que les identifiants Wikidata et Freebase des entités. L’API d’IBM Watson met quant à elle parfois des liens vers DBPedia.

Réflexion sur l’expérience utilisateur

Un problème observé, peu importe l’API concernée, est la difficulté probable pour le consommateur d’établir un lien entre le terme qu’il aura vraisemblablement cherché, et le résultat obtenu.

Par exemple, « divorce » est identifié dans le contexte de Parce que c’était toi de Marc Fisher, et ce pourrait être un terme ajouté à ses métadonnées. À lire la description du texte, c’est assez pertinent, et un consommateur qui cherche « divorce » ne devait pas être surpris de trouver ce titre, même si le mot « divorce » n’apparaît pas dans la description.

Mais cette situation est l’exception plutôt que la règle : assez souvent, le lien entre les mots-clés et la description du livre n’est pas évident. Ou même si on peut deviner le lien, il est plus difficile de savoir à quel point le résultat est pertinent. Par exemple, si on ajoutait « Jean Chrétien » dans les mots-clés associés à La Bataille de Londres, le consommateur qui trouve ce titre suite à cette requête pourrait se demander si le rôle de Jean Chrétien est réellement abordé dans le livre, ou s’il est simplement mentionné une ou deux fois dans le texte.

Ceci dit, ces réserves s’appliquent également à des mots-clés qui seraient choisis uniquement par des humains, sans assistance d’intelligence artificielle. À partir du moment où on choisit d’ajouter des mots qui ne font pas partie du titre ou de la description, on s’expose à ce genre de situation.

Conclusions de l’expérience

Les API de traitement du langage naturel sont certainement des outils à considérer pour enrichir les métadonnées de livres, en particulier les mots-clés. Elles sont une solution simple pour générer des idées de termes liés au contenu.

Dans un contexte de pure indexation sans limite sur le nombre de termes indexés, on pourrait même envisager de les utiliser sans trop de supervision humaine. En effet, les mots identifiés, bien qu’imparfaits, ne sont pratiquement jamais nuisibles s’ils ne servent qu’à de la recherche (et pas de l’affichage).

Toutefois, dans le contexte réel, où les libraires en ligne qui indexent les mots-clés (Amazon et peut-être d’autres) limitent probablement le nombre de mots ou la taille totale du texte indexé, il apparaît nécessaire d’ajouter une couche de curation humaine sur les mots-clés générés.

Pour faire un exemple clair : prenons un titre pour lequel une API nous donne 500 mots-clés. Pour une application où il n’y a pas de limites d’indexation (par exemple : le moteur de recherche sur le site web de l’éditeur), on peut probablement utiliser les résultats de l’API sans intervention humaine. Toutefois, lorsqu’il y a des limites (par exemple : les mots-clés transmis à la chaîne de valeur du livre via les métadonnées en ONIX, et dont Amazon, vraisemblablement le seul utilisateur de ces données, ne retiendra qu’un nombre limité), il vaudra mieux effectuer une curation par un humain pour ne conserver que les mots-clés les plus pertinents.

Nous retenons donc que ces API pourraient constituer une très bonne base d’outil d’aide à l’enrichissement de métadonnées.

Comparaison de 4 API d’extraction de mots-clés appliquées à des textes d’oeuvres littéraires (deuxième partie)

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.

Comparaison de 4 API d’extraction de mots-clés appliquées à des textes d’oeuvres littéraires (première partie)

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.

Comparaison de 6 API de description d’images appliquées à des pages couvertures de livres (deuxième partie)

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).

quebec_amerique_9782764421246
À titre d’exemple, nous avons accordé un A à Amazon Rekognition pour les mots-clés « Glacier (0.99), Ice(0.99), Mountain(0.99), Nature (0.99), Outdoors(0.99), Snow(0.99) ».

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.

editions_hurtubise_9782897234737
Ici, on ne comprend pas pourquoi l’API de Microsoft identifie le blanc comme couleur dominante d’arrière et d’avant-plan.

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.

editions_hurtubise_9782897239480
Clarifai voit de la « togetherness » dans cette illustration.

quebec_amerique_9782764424018
Clarifai voit « love » et « freedom » dans celle-ci.

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.

Comparaison de 6 API de description d’images appliquées à des pages couvertures de livres (première partie)

Le défi

La page couverture d’un livre est un des éléments les plus tangibles pour décrire une oeuvre. Elle est souvent utilisée pour mettre les oeuvres en valeur dans les librairies et les bibliothèques. C’est également cas, quasi systématiquement, dans les références en ligne : librairies et bibliothèques numériques, cartes enrichies dans les résultats sur Google, réseaux sociaux spécialisés dans la lecture…

Il n’est donc pas étonnant que les professionnels de l’édition consacrent tant d’efforts à créer de « bonnes » pages couvertures, et tentent de comprendre les facteurs qui font qu’une couverture « vend ».

D’un autre côté, on constate qu’il existe assez peu de moyens, dans une perspective de découvrabilité, de trouver des oeuvres en fonction de leur couverture. On peut assez facilement retrouver un livre dont on connaît l’auteur, le titre et la maison d’édition. Mais ce n’est pas le cas si on se souvient seulement que la page couverture est bleue et grise et montre un cheval tirant une voiture devant une grande maison.

Or, notre conviction, c’est qu’un certain nombre de consommateurs cherchent des livres comme ça : parfois avec un élément du titre, et typiquement avec une description de la page couverture. Nous émettons donc l’hypothèse qu’il serait avantageux d’enrichir les métadonnées qui décrivent les livres par un descriptif de leur page couverture. Cette description pourrait prendre la forme d’une énumération de ce qu’on y voit et des couleurs dominantes.

Nous croyons également qu’il est nécessaire de le faire de façon automatisée ou semi-automatisée, sur de grands volumes de titres. Cela permettra d’obtenir la masse critique qui amènera les plateformes qui présentent les oeuvres à utiliser ces nouvelles métadonnées.

Nous émettons donc une seconde hypothèse : il est possible d’automatiser la création de métadonnées descriptives d’images. Nous avons donc entrepris une expérience pour vérifier cette seconde hypothèse. Voici notre démarche, et les résultats obtenus à ce jour.

Identification des outils à notre disposition

Les avancées en traitement d’images constituent un des éléments les plus frappants dans le domaine de l’intelligence artificielle. Et il existe une panoplie d’outils disponibles gratuitement ou à peu de frais pour entraîner des réseaux de neurones à identifier les éléments présentés dans une image.

Dans l’esprit d’arriver rapidement à des résultats de façon efficace, nous avons choisi d’aborder le problème en utilisant des algorithmes de reconnaissance d’images préexistants, mais qui ne sont pas spécialisés dans le traitement des couvertures de livres. L’alternative aurait été d’entraîner nous-mêmes des réseaux neuronaux — mais c’est une solution qui aurait été clairement plus complexe et vraisemblablement plus coûteuse.

Il existe différentes API de description d’images. Nous en avons identifié six, offertes par les grands joueurs de l’industrie techno (IBM, Microsoft, Google, Amazon) ou des startups spécialisés en IA (Clarifai, Cloudsight).

Méthodologie d’évaluation

Comme première démarche d’évaluation des différentes API, nous souhaitons avoir un portrait global des résultats obtenus sur un échantillon représentatif de pages couvertures.

Nous avons choisi de façon aléatoire une cinquantaine d’images de notre corpus (environ 2500 titres provenant de 6 éditeurs québécois au moment de faire l’expérience), avec une représentativité de chaque éditeur proportionnelle à la taille du catalogue auquel nous avions accès. Nous avons fait une démarche de description des images, avec des mots-clés et des couleurs, « à la main » (donc pas d’API impliquée, mais un humain qui faisait le travail). Le fichier de travail est ici.

Dès cette première étape, il nous est apparu évident que nos API auraient du mal à décrire certaines images… Notre échantillon contenait certaines couvertures claires, montrant des images simples. Mais il contenait également des images abstraites, floues, ou avec un traitement artistique particulier qui les rend plus difficiles à décrire, même pour un humain.

echantillon
Quelques images de notre échantillon.

Nous souhaitions par la suite obtenir les résultats des API identifiées. Avec 50 images pour 6 API, l’utilisation des outils de tests manuels en ligne aurait impliqué beaucoup, beaucoup de manipulations… Heureusement, Gaurav Oberai a partagé l’outil qu’il a développé, nommé Cloudy Vision, pour automatiser une démarche similaire à la nôtre en 2016. Il s’agit essentiellement d’un script qui utilise les API, soumet les images, et génère un rapport agrégeant tous les résultats.

Après avoir installé le script, nous avons constaté que les API avaient beaucoup changé depuis 2016. Il fut donc nécessaire de faire des adaptations… Nous en avons profité pour bonifier le script pour lui faire extraire quelques informations supplémentaires et les afficher dans le rapport. Il s’agit des couleurs dominantes, et des annotations en français lorsqu’elles étaient disponibles.

Notre version modifiée du code source est disponible sur le compte Github de Projet TAMIS, et nos modifications seront vraisemblablement intégrées dans le projet d’origine.

Résultats

Le rapport généré par Cloudy Vision est intégralement disponible en ligne.

Nous observons toutefois déjà quelques tendances.

Sur les couleurs, seule l’API d’IBM retourne des noms de couleurs qui correspondent (plus ou moins) à une requête que formulerait un humain. Les codes de couleur retournés par l’API de Google ne sont d’aucune utilité pour les besoins qui nous intéressent.

CloudSight semble identifier la majorité de nos livres… comme des livres! Comme il ne fournit pas de description de ce qui est illustré sur la couverture, il est de bien peu d’utilité.

Les résultats de description d’images ont de l’intérêt pour les photos ou les illustrations réalistes. Les résultats se gâtent pour les illustrations trop stylisées, ou les représentations plus abstraites.

editions_multimondes_9782897730543
Une photo qui amène de bons résultats. Rekognition mentionne « Glacier (.98) , Ice (.98) , Mountain (.98) , Nature (.98) , Outdoors (.98) , Snow (.98) , Iceberg (.91) , Arctic (.78) , Winter (.78) , Boat (.51) », Microsoft « outdoor , water , mountain , snow , hill , man , riding , red , people ,surfing , large , skiing », Clarifai « snow (1.00) , winter (1.00) , ice (.98) , frozen (.96) , sport (.96) , outdoors (.95) , nature (.95) , cold (.95) , frosty (.93) , season (.92) , mountain (.90) , glacier (.89) , horizontal (.89) , frost (.88) , travel (.88) , adventure (.88) » (les résultats d’IBM et Google sont similaires; seuls ceux de CloudSight sont décevants).

editions_hurtubise_9782891448093
Les illustrations sont clairement plus difficiles à analyser. Amazon Rekognition y voit d’abord « Bandage (.96) , First Aid (.96) », l’API de Microsoft ne se mouille pas et mentionne « Others ». L’API d’IBM identifie bien les couleurs, mais n’est pas très utile avec « périphérique de stockage (.82), enregistrement (.80) , presse écrite (.80) , CD-ROM (.70) , boite de céréales (.62) , boîte (.62) ». CloudSight remporte la palme du loufoque avec « white and pink Hello Kitty print smartphone case ».

Il faut noter que les résultats sont assez inégaux. Sur l’illustration précédente, Google a donné des résultats corrects : « cartoon (.94) , facial expression (.94) , text (.93) , flower (.83) , emotion (.82) , clip art (.81) , play (.78) , art (.75) , smile (.75) , child (.74) ». Les écarts de performance sont visibles ailleurs également.

presses_de_l_universite_de_montreal_9782760627130
Pour cette image, Rekognition d’Amazon fait un travail honnête : « Building (.74) , Office Building (.74) , Corridor (.63) , Banister (.61) , Handrail (.61) , Lighting (.61) , Indoors (.53) , Interior Design (.53) , Alley (.52) , Alleyway (.52) , City (.52) , Road (.52) , Street (.52) , Town (.52) , Urban (.52) , Housing ». L’API de Microsoft confond toutefois le corridor bleu et sinueux avec un cours d’eau : « water , scene , fence , pier , photo , bridge , body , river , board , sitting , blue , standing , large , riding , white , boat , sign , man , dock , red , night »

Il faut également noter que seule l’API d’IBM permet d’obtenir des résultats en français. Dans tous les autres cas, les résultats sont en anglais. Cela ajoutera un défi supplémentaire à l’utilisation des résultats. Il existe des solutions pour traduire des textes de façon automatique, et on peut penser que les résultats seront plus satisfaisants sur de simples mots (ce que nous traitons) que pour de longs textes. Toutefois, sans le contexte, on peut également émettre l’hypothèse que certaines traductions seront erronées.

Parmi les autres trouvailles étonnantes, notons que l’API de Google permet d’identifier les oeuvres reprises sur les pages couvertures.

Le Coeur gros
L’API de Google a correctement identifié la peinture de Eugenia Martinez Vallejo partiellement reprise dans la composition de cette couverture.

Nous publierons prochainement notre analyse plus détaillée de ces résultats, afin d’identifier si certaines de ces API sont suffisamment précises pour atteindre nos objectifs initiaux, à tout le moins pour certaines catégories d’images.

Mise à jour 27 septembre 2018: la deuxième partie du texte est maintenant disponible.