Combiner les approches à la pointe de la technologie du NLP et de l’IA pour l’analyse des documents.

Introduction

Dans le monde des affaires d’aujourd’hui, de nombreux processus clés impliquent l’analyse et le traitement d’informations textuelles. Pour ces processus, c’est une bonne nouvelle qu’aujourd’hui une grande variété de composants de NLP soient disponibles, dont beaucoup sont dans le domaine public. Nous allons esquisser un scénario pour un exemple de tâche d’analyse et la façon dont cela peut être abordé avec une combinaison de ces composants. Là où le logiciel lui-même devient de plus en plus une commodité, l’accent est mis sur les données requises pour former les modèles ainsi que sur l’expertise nécessaire pour faire un usage raisonnable des outils disponibles : L’utilisation, l’optimisation et l’intégration d’approches pour aborder ces scénarios est au cœur de la proposition de valeur de Kairntech. Pour répondre au besoin croissant de construire et de déployer de nouveaux produits ou services basés sur l’IA à partir de contenus non structurés (texte, audio…) en s’appuyant sur les technologies d’apprentissage automatique et de bases de connaissances.

Dans ce texte, nous donnons un rapide aperçu pour illustrer notre approche.

Exemple : Analyse d’essais cliniques

Comme exemple de scénario pour le reste de ce texte, nous sélectionnons des essais cliniques, c’est-à-dire des textes qui documentent une étape clé du développement de médicaments dans l’industrie pharmaceutique. Les essais cliniques représentent un type de document très réglementé puisqu’ils doivent respecter des normes strictes concernant les informations qu’ils doivent documenter et leur format. Ils sont également accessibles au public, ce qui en fait un cas d’exemple bien adapté. Notez cependant que l’approche que nous esquissons ici s’applique en principe à d’autres types de documents également, tels que les documents commerciaux (comme les factures, les offres, les contrats), les documents juridiques (comme les lois, les opinions) ou les publications techniques/scientifiques.

Dans ce qui suit, nous utiliserons un échantillon de plusieurs milliers d’essais cliniques.

Nous utiliserons le vaste ensemble de métadonnées qui accompagnent ces documents, nous les stockerons dans une base de données de type « graphe » (nous utilisons ici ArangoDB) et nous enrichirons encore le contenu en utilisant une approche d’extraction d’entités de pointe de Entity-Fishing qui permet de désambiguïser les entités et de les relier aux connaissances de base de Wikidata. Notez que si les choix ci-dessus concernant Arango comme moteur de base de données et Wikidata comme source de connaissances facilitent les déploiements en raison de la disponibilité publique, l’approche de Kairntech s’étend évidemment aussi aux configurations propriétaires, par exemple des sources de données spécifiques à une entreprise au lieu de Wikidata.

Pourquoi la recherche en texte intégral ne suffit-elle pas ?

De toute évidence, le fait que nos échantillons de données soient disponibles sous forme numérique et indexés dans un moteur de recherche en texte intégral permet déjà de répondre à une grande variété de recherche, telles que « quelles sont les études qui mentionnent « Novartis » » ou « montrez-moi des documents qui mentionnent « Merck » ainsi que « Diabète » » ». Ce type d’accès est bien compris et puissant, mais il est clair qu’un large éventail de recherche tout aussi pertinentes sont hors de portée de cette approche et exigent des méthodes plus élaborées :

• « Quelle entreprise pharmaceutique est la plus active dans le domaine du paludisme ? » Pour répondre à cette question, un moteur en texte intégral ne suffit pas. Nous devons plutôt être en mesure de reconnaître le type d’une expression en tant que société pharmaceutique, puis de les rassembler et de les trier.
• « Quelle entreprise pharmaceutique est la plus active dans le domaine du cancer ? » Ici, en plus de l’exigence ci-dessus, nous devons être capables de faire correspondre toutes les occurrences de « leucémie » et de nombreuses autres expressions se référant à des types spécifiques de cancer en tant que tels, c’est-à-dire inclure les connaissances taxonomiques.
• « Quelle est l’étude la plus récente sur le SRAS » ? Notre approche doit ici non seulement être capable de reconnaître et de normaliser une grande variété de formats de date (« 21 octobre 2015 », « 2015-10-21 », « 21 octobre 2015 », …) mais aussi de détecter la signification précise d’une date dans le document : Une date spécifique pourrait être la date de publication de l’étude, du début du recrutement des patients, la date à laquelle un incident spécifique s’est produit ou à laquelle un règlement a été promulgué concernant la conception de l’étude, et bien d’autres possibilités de ce type.

Le fait d’avoir importé des échantillons de données dans notre base de données permet de répondre immédiatement à certaines des demandes de recherche ci-dessus. Nous commencerons par utiliser les métadonnées qui accompagnent les données, puis nous les compléterons en ajoutant des métadonnées supplémentaires par le biais de l’extraction d’entités.

Si des requêtes comme celle ci-dessus peuvent bien sûr être traitées avec des données structurées dans une base de données relationnelle, un certain nombre de raisons expliquent la récente tendance à modéliser les connaissances plutôt dans des bases de données de type « graphe » : les bases de graphes sont « sans schéma », ce qui signifie qu’il est beaucoup plus facile de stocker, de manipuler et de naviguer dans des données hétérogènes que dans des bases de données relationnelles. En outre, l’exploitation des liens entre différents éléments (par exemple entre une étude, son chercheur principal, le site de l’étude, etc.) dans le cas des relations implique souvent l’exécution de jointures coûteuses alors que dans le cas des bases de graphes, elles peuvent être réalisées en utilisant des méthodes de parcours de graphes qui peuvent être beaucoup plus efficaces. Pour une discussion plus détaillée sur ce sujet, voir ce lien.

Cependant, outre le fait que nous apprécions les avantages du stockage des données dans des bases de graphes plutôt que dans une base de données relationnelle conventionnelle, nous n’avons jusqu’à présent fait que nous baser sur des informations qui accompagnent déjà nos données sous une forme propre et explicite : Les essais que nous utilisons comme échantillons de données sont formatés en tant que documents JSON avec un riche ensemble de champs, listant non seulement le chercheur principal, le promoteur de l’étude et la date de lancement, mais aussi des informations détaillées sur la conception de l’étude, les sites participants et leurs adresses respectives, les maladies étudiées et bien d’autres types d’informations. Toutes les informations qui nous intéressent et qui ne sont pas représentées sous forme de métadonnées explicites dans nos documents dépassent pour l’instant l’approche ci-dessus. De plus : Dans la plupart des cas, les documents ne seront pas organisés de manière aussi soignée avec des métadonnées explicites propres et riches. Dans de nombreux cas, seul le texte intégral est disponible. C’est pourquoi nous étendrons ci-dessous notre approche à l’utilisation d’informations provenant de parties non structurées des documents.

Extraire, désambiguïser, normaliser et relier les informations

Notre corpus d’essai contient, outre tous les champs de métadonnées explicites, deux champs qui contiennent le texte intégral, le « résumé succinct » et la « description détaillée ». Quelles que soient les informations pertinentes qui s’y trouvent, elles doivent d’abord être traitées à l’aide d’algorithmes appropriés pour exécuter la séquence d’étapes ci-dessus :

• L’entité doit être détectée dans le texte non structuré
• La chaîne dans le texte peut avoir différentes significations (comme « Saturne » – la planète et « Saturne » – le dieu de la mythologie grecque). La désambiguïsation identifie dans ces cas la signification appropriée pour tous les concepts de Wikidata sans qu’il soit nécessaire de définir manuellement les contraintes de désambiguïsation.
• La chaîne dans le texte peut également représenter une variante d’un contenu, pour lequel il existe un terme préféré communément accepté : La normalisation est le processus qui garantit que ces termes préférés sont utilisés dans les résultats de l’analyse.
• Enfin, la normalisation est le processus qui garantit que ces termes préférés sont utilisés dans les résultats de l’analyse : La liaison établit un lien entre le concept figurant dans le texte et les informations de base relatives à ce concept : pour une personne, il peut s’agir de sa photo ou de son lot et de son lieu de naissance, pour une substance chimique, il peut s’agir de la masse moléculaire de cette substance, de la formule de la somme ou du nom commercial.

L’approche décrite ici utilise un logiciel basé sur l’apprentissage automatique (entity fishing) qui s’appuie sur l’ensemble des connaissances de Wikidata.

Avec quelques lignes de code, nous étendons notre stockage de données de sorte que non seulement les documents avec leurs métadonnées originales sont stockés, mais aussi les nouvelles entités extraites des champs de texte intégral. Nous pouvons maintenant étendre nos scénarios de recherche à des cas tels que « montrez-moi les substances les plus populaires dans les essais pour lesquels le chercheur principal était XYZ » ou lorsque les métadonnées des substances ont été créées en analysant le résumé ou la description.

Les entités identifiées, n.b. ne sont pas seulement des chaînes de caractères avec un type, elles sont, comme indiqué ci-dessus, des entités normalisées, désambiguïsées et liées en vertu de la connexion avec les informations stockées dans la base de connaissances source (Wikidata dans ce cas). Il en résulte que les entités portent une foule d’informations de fond, comme l’illustre cet exemple de « Leptin » pour lequel le processus d’extraction est capable d’ajouter de nombreuses informations supplémentaires :

La configuration ci-dessus est appropriée lorsque les entités à extraire des champs de texte sont connues dans le domaine public – et dans le cas plus spécifique énumérées dans Wikidata. Et pourtant, si Wikidata est une énorme source d’information, dans les projets industriels, il sera le plus souvent nécessaire de gérer des informations qui ne sont pas répertoriées dans ces sources publiques : On ne peut pas toujours s’attendre à ce que les listes d’employés avec leurs coordonnées et leurs profils, les vocabulaires spécifiques à un domaine ou les significations spécifiques d’entités communes fassent partie des sources publiques. Pour compléter l’approche décrite jusqu’à présent, un outil est donc nécessaire pour soutenir et faciliter la génération d’ensembles de données de formation pour ces scénarios.

La suggestion que nous avons mise en œuvre est la plateforme Kairntech qui répond précisément à cette exigence dans de nombreux contextes industriels qui exigent des composants d’annotation spécifiques, les ensembles de données de formation nécessaires sont même, à l’ère prétendue des « Big Data » d’aujourd’hui, tout simplement non disponibles. Au lieu de cela, les projets sont souvent entravés par l’insuffisance des données d’entrainement ou par des efforts prohibitifs pour les créer – des efforts qui sont souvent exacerbés par le fait que les environnements et les formats disponibles pour la création des jeux de données exigent une vaste expérience technique qui peut ne pas être disponible chez les experts du domaine.

La plateforme Kairntech intègre cette tâche de création de corpus dans un environnement qui facilite la collaboration et l’adoption rapide également par les utilisateurs non techniques et réduit en outre considérablement les efforts d’annotation en mettant en œuvre l’apprentissage actif : L’environnement fait des choix informés sur les échantillons à présenter aux utilisateurs dans les étapes suivantes afin de maximiser les bénéfices de l’entrainement. En substance, l’échantillon suivant que l’utilisateur annote est celui où l’algorithme de formation actuel est le moins certain (en laissant de côté les nombreux exemples où la décision peut déjà être prise avec une grande confiance). Il a été démontré que l’apprentissage actif peut réduire le temps d’annotation de manière significative (cf. ce lien) et, de toute évidence, dans les projets industriels, chaque jour d’effort d’annotation qui peut être économisé peut être un critère essentiel.

Conclusion

Le traitement de données textuelles dans des contextes industriels peut aujourd’hui s’appuyer sur des avancées spectaculaires dans les fondements algorithmiques ainsi que dans les composants accessibles au public. Nous en avons énuméré un certain nombre, comme les grandes sources de connaissances publiques (par exemple Wikidata), les environnements de stockage de données (comme ArangoDB ou Cayley), les bibliothèques NLP et ML (comme Keras, Delft et Spacy) ainsi que les corpus de documents pertinents (comme ici ou là). Cette situation souligne l’observation souvent formulée selon laquelle, avec une telle abondance de logiciels puissants dans le domaine public aujourd’hui, le véritable défi (outre la capacité à utiliser, intégrer, optimiser et maintenir le logiciel) est l’acquisition des données d’apprentissage permettant d’appliquer la pile logicielle à un problème commercial pertinent. Nous avons présenté la plateforme Kairntech comme un environnement d’annotation de texte qui répond à cette demande essentielle.