Les outils de text-mining ont pour vocation d’automatiser la structuration des documents peu ou faiblement structurés.

Ainsi, à partir d’un document texte, un outil de text-mining va générer de l’information sur le contenu du document. Cette information n’était pas présente, ou explicite, dans le document sous sa forme initiale, elle va être rajoutée, et donc enrichir le document.

A quoi cela peut bien servir ?

• à classifier automatiquement des documents
• à avoir un aperçu du contenu d’un document sans le lire
• à alimenter automatiquement des bases de données
• à faire de la veille sur des corpus documentaires importants
• à enrichir l’index d’un moteur de recherche pour améliorer la consultation des documents

Bref, plusieurs usages et plusieurs services peuvent découler des solutions de text-mining.

Comment çà marche ?

Il y a quelques règles de base que les outils de text-mining se doivent de respecter dans leur traitement. Ces règles de base sont plus ou moins chronologiquement les suivantes :

• D’abord le logiciel doit reconnaître les unités de la langue que sont les mots (tokenisation)
• Ensuite il doit savoir interpréter et prendre en compte la ponctuation et la mise page (retour à la ligne, paragraphe, etc.)
• Puis les formes lexicales et grammaticales, qui peuvent énormément varier selon que la langue est l’anglais, l’arabe ou le chinois.
• Ensuite, il y a une phase de lemmatisation : elle consiste à identifier les différentes flexions d’un terme, ou déclinaisons d’un verbe.

L’ensemble des phases précédentes relèvent de ce que j’appelle l’analyse linguistique, au sortir de laquelle nous avons un document que le logiciel de text-mining a transformé. Si le document initial était fait pour les yeux de l’humain, le document après traitement est fait pour un traitemtn par les machines.

Deux approches, qui ne sont pas antinomiques, peuvent ensuite être envisagées :

• une approche statistique
• une approche sémantique

1. L’approche statistique :
Elle consiste à ne voir le document que via le prisme du nombre et des chiffres.

Ainsi l’outil statistique de text-mining produit des informations sur le nombre d’occurrence d’un terme, le nombre de cooccurrence de plusieurs terme, la fréquence d’apparition d’un terme dans un document ou un corpus.
Il peut encore produire ce que l’on appelle des « vecteurs de sens », qui sont des « concepts » statistiques de cooccurrence de termes qui permettent de classer et/ou de catégoriser tout un corpus.

• Les avantages de l’approche statistique :

Le principal réside dans son très faible coût d’entretien eut égard au véritable service que cela peut apporter, à condition que le volume du corpus documentaire soit significatif, voire très important.

• Les désavantages de l’approche statistique :

Le revers de la médaille, c’est qu’il n’y a pas de prise en compte des spécificités du corpus documentaire traité : textes médicaux, commerciaux, scientifiques ou autres, seront adressés de manière identique, grâce à la puissance du calcul statistique.
Autre élément à prendre en compte, c’est la pertinence du traitement qui est non seulement difficilement prévisible, et en tout cas généralement moins élevée que l’approche sémantique.

2. L’approche sémantique :

Dans le cas de l’approche sémantique, la démarche ne va plus s’appuyer sur la force brute de la puissance de calcul mais sur un élément externe. Cet élément externe, appelons le référentiel. Il peut être statique ou dynamique.
Une fonction comme la reconnaissance d’entité (entity recognition) va ainsi déduire que le groupe de mots « Christian Fauré », écrit sans plus d’information dans un document, est une personne de nationalité française parce que le moteur de text-mining aura été cherché mon nom dans un référentiel de personne, et qu’il l’aura trouvé dans la catégorie « personne de nationalité française ».

Les référentiels statiques peuvent être des mots clés, des listes à plats, des thesaurus, des ontologies. Le moteur de text-mining va rajouter aux documents qu’il traite l’ensemble des informations que peut contenir le référentiel.
Les référentiels dynamiques existent aujourd’hui surtout dans ma tête. Ce sont des référentiels qui mettent en oeuvre des logiques. Celles-ci peuvent être des logiques formelles (celles que décrivent OWL), mais aussi des logiques probabilistes (comme les réseaux bayesiens). La différence avec le référentiel statique est que le document qui passe par le moteur de text-mining va être enrichi par des informations qui sont déduites du référentiel : le référentiel fait un travail de déduction avant de donner sa réponse au moteur de text-ming qui va enrichir le document.

• Les avantages de l’approche sémantique :

On peut paramétrer le moteur de text-mining pour coller à la spécificité du corpus documentaire en exploitant l’ensemble des référentiels du domaine ou de l’organisation. On peut également modéliser des connaissances métiers spécifiques pour effectuer des traitements de text-mining qui répondent à un besoin bien identifié. La pertinence des résultats obtenus est beaucoup plus fine et généralement meilleure que dans l’approche statistique (la notion de « meilleur » étant toute fois toujours relative).

• Les désavantages :

Le coût d’exploitation et de maintenance est très fort. Cela demande des ressources matérielles, budgétaires et humaines significatives. De plus si le corpus est important, le temps de traitement requis peut être très long et représenter un frein à la démarche.

3. Quelle complémentarité des approches statistiques et sémantiques ?

Comme je l’ai déjà dit, ces deux approches du text-mining (statistique et sémantique) ne sont pas antinomiques. Pour éclairer la complémentarité des approches je vais prendre l’exemple des moteurs de recherche.
Je considère en effet, mais c’est une conviction personnelle, que la meilleure valorisation des outils de text-ming c’est de les utiliser afin d’enrichir l’index d’un moteur de recherche.

Je prendrai deux exemples concrets : le premier avec le moteur de recherche de FAST et le deuxième avec la plate-forme UIMA corrélée au moteur de recherche OmniFind d’IBM.
Ces deux solutions ont en commun de proposer un « tuyau de traitement » des documents avant indexation.

Chez FAST, cela donne quelque chose qui peut s’illustrer de la manière suivante : un tuyau dont les anneaux sont autant d’étapes de traitement et d’enrichissement du document initial. Chaque étape enrichie le document tel qu’il arrive dans le tuyaux et le renvoie dans le tuyau pour une nouvelle étape de traitement.

Les premiers anneaux de traitement sont ceux de la normalisation et de l’analyse linguistique évoquées plus haut, ensuite les traitements peuvent être de type statistique ou sémantique. A la fin des traitements, le document est indexé et accessible vie le moteur de recherche. Entre temps, il est devenu structuré.
Le fait est que ce tuyau est la propriété de FAST, et les outils de text-mining tiers ne peuvent pas s’y greffer facilement.

C’est là qu’arrive IBM.

Le moteur OmniFind d’IBM n’a pas la réputation d’être un foudre de guerre, et il est en tout cas commercialement peu présent sur un marché dominé par les grands acteur du Search en entreprise et les petits éditeurs dynamiques. Aussi, pour tenter de s’imposer, IBM a proposé en open source son Bus Middleware, qui correspond au tuyau de traitement et d’enrichissement avant l’indexation par le moteur de recherche. Ce bus middleware s’appelle UIMA (Unstructured Information Management Architecture) et son architecture peut être illustrée de la manière suivante :

Comme UIMA est ouvert et libre, IBM souhaite s’imposer, non pas comme outil de text-mining, mais comme l’architecture qui permet d’accueillir divers outils de text-mining tiers. Ainsi la solution de l’editeur de text-mining TEMIS est « UIMA compliant » : on peut les « plugger » sur le bus UIMA d’IBM.

On peut quand même se demander si, au bout de la chaîne UIMA, le moteur de recherche qui va exploiter toute cette chaîne de traitement peut être autre chose que le moteur OmniFind d’IBM ; « j’en doute » me disait récemment un consultant. Mais c’est quand même bien joué de la part d’IBM, acteur reconnu du Middleware, de se positionner comme le Middleware ouvert du monde du traitement des informations non-structurées.

Si cette note pouvait permettre aux entreprises d’arrêter d’imaginer que le text-mining est une solution magique, elle aurait atteint son but. C’est une solution technique qui a des impacts budgétaires, organisationnels et métiers qu’il faut clairement identifier.
Je rappelle également qu’il existe une autre méthode pour structurer les documents : c’est de les structurer dès leur création en menant une politique éditoriale (je passe la main à Got).

Le tout est de savoir où on veut mettre le curseur… et son argent.

Related posts:

1. XML Pipeline Langage Un working draft de XML Pipeline Langage vient d’être publié....
2. Quand le « Search » bouscule la « Business Intelligence » Ce note aurait tout aussi bien pu s’intituler « la Business...
3. Google et la sémantique Il est difficile de dire que Google ne fait pas...

C’est bien connu, l’ensemble des applications du système d’information d’une entreprise reposent sur des bases de données utilisant des sémantiques différentes.

Alors, pour que tout çà puisse causer ensemble il y avait trois principales solutions :

• passer à un ERP, c’est à dire que vous donnez les clés de votre système d’information à votre fournisseur de logiciel.
• faire du codage « à la main » pour les échanges entre vos applications.
• mettre des briques logicielles tissant des liens d’échange entre les applications, c’est pareil que le point précédent, à part qu’un éditeur vous propose un atelier logiciel unique pour développer et gérer ces d’échanges (EAI)

Et bien maintenant les éditeurs réinvestissent ce terrain fructueux du middleware en proposant des solutions de Master Data Management. C’est quoi ? C’est une base de données dans laquelle on gère un format pivot de l’information. Ce dernier assure la sémantique et la synchronisation des différentes bases applicatives connectées.

C’est bien de proposer tout çà, mais c’est quant même mieux d’encoder les données aux normes du web sémantique plutôt que de construire des usines à gaz entre chaque application. Ne vaut-il pas mieux dépenser ses bugbets au niveau de l’architecture de l’information plutôt qu’au niveau de l’architecture de la couche applicative ?

L’embêtant est que ces investissement dans le middleware pérennisent le maintient de solutions logicielles qui ne jouent pas le jeu de l’inter-opérabilité (« si, si, on fait du XML », répondraient-ils avec cynisme), et cette situtation retarde la pénétration des normes web sémantiques dans les entreprises.

- Mais, pourrait-on m’objecter, il y a les architectures orientés service (SOA) et les Web services !
- A quoi je répondrais : où avez vous vu de la sémantique dans les Web services ?
- Mais il y a quand même un changement de paradigme intéressant dans ces architecture de service !
- A quoi je répondrais : les éditeurs facturent des logiciels (et de la maintenance), pas des services (au sens service rendu, pas au sens « Professionnal Services »). Quand ce sera le cas, on en reparlera.

Related posts:

1. WebMethods s’offre Cerebra L’editeur américain WebMethods, offrant des solutions EAI (Enterprise Application Integration)...
2. You ? Vous êtes convaincu que le web est la plateforme ?...
3. Le web sémantique pour les petits Le web sémantique est ludique et favorise l’éveil de vos...