La difficulté de l’évaluation

1.4.5.1 Un manque d’évaluation ?

La question de l’évaluation en ingénierie des connaissances est une question complexe, régulièrement abordée car elle conditionne la crédibilité du caractère scientifique des approches proposées. Elle est pourtant un des points faibles de l’IC parce que les chercheurs ont du mal à établir des critères de validité de la plupart des résultats qu’ils proposent. L’absence de métrique, de standards d’évaluation donne l’impression d’une mauvaise maîtrise de la portée et de la qualité de ces résultats : en quoi un modèle, une méthode ou une technique peut-il s’appliquer dans un autre contexte d’application, à un autre type de tâche ou de domaine ? en quoi un résultat constitue-t-il une réelle avancée dans le domaine ?

S’interroger sur l’évaluation revient à préciser les objets, méthodes et critères d’évaluation :

- La nature des résultats à valider : faut-il évaluer les méthodes, techniques et outils proposés par l’IC par eux-mêmes ? ou les systèmes résultants de la mise en œuvre de ces moyens méthodologiques ? ou encore l’apport de ces systèmes auprès de leurs utilisateurs, la qualité de la réponse au besoin ?

- La pertinence d’un résultat : s’agit-il de la réponse à un besoin, l’adéquation à une théorie de la connaissance, l’utilisation effective d’un logiciel par un cogniticien ou un gain réel dans l’activité assistée par le logiciel développé ?

- Les méthodes d’évaluation : Que peut-on vraiment mesurer à partir d'applications en vraie grandeur ? comment mener des expérimentations, des études de cas représentatives ? des évaluations de résultats intermédiaires, de techniques particulières ou d’outils supposent de bien délimiter leur portée. En quoi ces évaluations partielles garantissent-elles la validité de l’ensemble ?

Ces questions se croisent. Il paraît indispensable de parvenir au final à évaluer des résultats globaux dans des situations réelles d’usage, c’est-à-dire la qualité du système développé à l’issue du processus d’ingénierie des connaissances. Or ce type d’évaluation globale se heurte à plusieurs difficultés : le coût, la durée, la multiplicité des paramètres non maîtrisés, le grand nombre de concepts ou d’hypothèses à évaluer. Un compromis consiste à s’appuyer sur des validations plus ciblées, soit en se focalisant sur une partie de l’approche proposée (langages, modèles, techniques, logiciels d’extraction, etc.) soit en s’appuyant sur des expériences mieux maîtrisées comme les études de cas ou les simulations.

1.4.5.2 Quelques cadres d’évaluation

Afin de réduire la complexité du problème et de se donner des éléments de comparaison des résultats produits en IC, la communauté scientifique s’est

organisée à partir de 1992. Elle a proposé des études de cas à utiliser lors de campagnes d’évaluation.

 Les premières propositions, les projets Sisyphus I (1992-1994), ont porté sur la modélisation de connaissances de résolution de problème. Un énoncé simple de problème d’affectation (de bureaux aux membres d’un laboratoire) était proposé pour construire un modèle permettant de résoudre ce problème. Aucune méthode de résolution n’était suggérée a priori. La proposition s’est affinée dans le projet Sisyphus II sous forme d’une grille de questions pour permettre de comparer la méthode suivie par chaque participant pour obtenir le modèle, les logiciels utilisés, les choix de modélisation, la représentation des connaissances ou encore la manière d’opérationnaliser le modèle.

 Le deuxième projet Sisyphus III (dit V.T.) (autour de 1995) proposait un problème plus complexe de conception d’un ascenseur par assemblage de pièces à choisir en fonction de contraintes matérielles. Outre le type de tâche, le changement venait de la richesse des informations fournies pour guider la modélisation et l’enrichissement de la grille de comparaison des travaux. Cette expérience a permis d’aborder un nouveau type de problème, la conception.

 Un dernier projet Sisyphus IV (autour de 1996-1997), dans le domaine de la géologie, a porté sur de la modélisation de connaissances à partir de textes. Ce projet était beaucoup plus ambitieux et sa complexité plus proche d’une étude de cas réelle. Le modèle à construire devait répondre à un besoin d’utilisation donné aux participants, la source de connaissance était un ensemble de documents tels qu’ils avaient été étudiés dans un projet.

Ces projets ont favorisé la connaissance réciproque des travaux de recherche. Ils ont permis de mieux comprendre chacune des approches, méthodes et solutions des participants, de dégager des éléments de confrontation, de présenter bien plus précisément que dans des articles classiques les langages de modélisation. Ils ont eu des impacts très bénéfiques au niveau des échanges scientifiques, des réflexions méthodologiques et de l’utilisation des logiciels. Cependant, ils n’ont pas vraiment permis de (et même se sont refusés à) juger de la qualité des modèles obtenus : comment décider qu’un modèle était meilleur, plus valide ou plus performant, qu’un autre ? ils n’apportaient pas davantage de réponse qualitative à la comparaison des méthodes.

La construction d’ontologies a donné un nouvel élan à ce type de projet, car il semble plus facile d’établir des métriques pour juger de leur pertinence, les comparer et confronter des approches pour leur construction. Des protocoles ont été définis pour mieux mesurer les avancées, comparer des travaux et qualifier ou quantifier des résultats, enfin d’en assurer une visibilité à l’extérieur de la communauté concernée.

 Plusieurs conférences EON (Evaluation of Ontology based Tools) ont porté sur l’évaluation d’outils utilisés pour la construction d’ontologies.

Une étude de cas très simple proposait une page décrivant les éléments d’un domaine et une application supposée utiliser l’ontologie. Lors de la première expérience², la comparaison a porté sur les choix de modélisation et le langage de représentation des connaissances. Lors du

2 http://km.aifb.uni-karlsruhe.de/eon2002

39

workshop suivant³, l’évaluation a porté sur l’interopérabilité des modèles et des outils, la capacité des éditeurs à lire des modèles construits par d’autres équipes, et celle des modèles à être réutilisés ou adaptés.

Enfin, l’édition de 2004⁴ s’intéressait aux méthodes d’alignement d’ontologies. Ces workshops ont dynamisé et fait progresser la communauté de recherche, en favorisant une meilleure connaissance des capacités des méthodes et des logiciels. Ils ont rendu plus visibles ces résultats. Cependant, ils ne permettent pas de dire si une méthode ou une représentation des connaissances est plus adaptée ou plus efficace qu’une autre. La difficulté est propre au domaine, où il n’existe pas un « bon » modèle pour une application et une description de connaissances données.

 Depuis 5 ans, le développement de systèmes pour la construction d’ontologies à partir de textes rapproche l’IC de deux communautés plus familières de campagnes d’évaluations qualitatives et quantitatives : d’une part, la communauté du traitement automatique des langues, qui fournit les outils d’analyse des textes, et d’autre part celle de la recherche d’information qui utilise ces ontologies pour indexer ou classer des documents, améliorer les capacités des moteurs de recherche, etc.

Le succès récent de l’utilisation de l’apprentissage et de l’extraction d’information n’a fait que renforcer ce phénomène et rend possible de mesurer plus précisément certains traitements sur les textes et leurs apports à l’enrichissement des ontologies. Actuellement, le réseau d’excellence OntoKnowledge, en lien avec une série de workshops OLP, a mis en place le projet PASCAL qui propose plusieurs tâches liées à l’analyse automatique de textes et à l’enrichissement d’ontologies à partir de textes. Les tâches consistent à acquérir des types de connaissance à partir de textes (termes, concepts, relations, etc.) et à les utiliser pour enrichir ou construire complètement une ontologie dans un domaine particulier.

Le risque est de tomber dans des travers technologiques analogues à ceux auxquels est confrontée la recherche d'information avec les grandes campagnes d’évaluation (TREC, CLE, etc.). Les tâches proposées ne sont pas forcément très représentatives de la problématique effective de construction d’ontologie. Par exemple, la référence pour la validation d’un modèle reste le contenu du texte alors que l’on sait que l’application visée oblige à s’éloigner du contenu du texte. Ces campagnes ne s’intéressent pas vraiment à l’utilisabilité des modèles, à leur pertinence en usage, car mesurer la satisfaction des utilisateurs supposerait des protocoles complexes et lourds, et à des résultats qualitatifs difficilement comparables.

1.4.5.3 Validation versus évaluation des modèles

En ce qui concerne les modèles conceptuels, et plus encore pour les ontologies et terminologies (RTO), la communauté donne un sens particulier à validation et évaluation [RIA, 04]. Par validation d’un modèle, on entend le moment où l’analyste présente le modèle à l’expert, et lui demande de valider ou d’invalider les choix de modélisation effectués. L’enjeu est de s’assurer avec les experts que la conceptualisation représentée n’est pas en contradiction avec leurs connaissances. Une fois le modèle construit, s’engage

3 http://km.aifb.uni-karlsruhe.de/ws/eon2003

4 http://km.aifb.uni-karlsruhe.de/ws/eon2004

un processus d’évaluation selon les procédures de base du génie logiciel. Il s’agit de vérifier si le modèle satisfait le cahier des charges et répond aux attentes spécifiées au début du projet. Définir un cadre pour ce genre d’évaluation présente deux types de difficulté. Tout d’abord, l’ontologie n’est qu’un élément de l’application cible, qui est le dispositif à évaluer. Il faut donc concevoir des expériences et des bancs d’essais qui permettent de cibler l’évaluation sur la seule ressource. Ensuite, chaque cas étant particulier, les procédures d’évaluation doivent être adaptées aux types d’application, à la manière dont elles utilisent le modèle, etc.

1.4.5.4 Évaluation des outils

À côté de l’évaluation des modèles, se pose le défi de l’évaluation des outils de construction des modèles. La source des difficultés est double : d’abord il s’agit d’outils d’aide, ensuite chaque outil est rarement utilisé seul.

Dans le cas d’un outil automatique, du type « boîte noire », ses performances peuvent être mesurées en comparant ses résultats à des résultats attendus (« gold standard »). Dans le cas des outils d’aide, les résultats fournis sont interprétés par l’analyste. Or les conséquences de cette interprétation sont variables : une modification, un enrichissement du modèle à un ou plusieurs endroits, voire l’absence d’action immédiate, sans que cela signifie nécessairement que les résultats en question soient faux ni même non pertinents. De plus, cette interprétation s’appuie normalement sur une confirmation par retour aux sources de connaissances. Il n’y a pas systématiquement de lien direct entre un résultat de l’outil et une portion de modèle. Si on rajoute à cela, qu’une portion de modèle n’a pas de sens prise isolément, et que la ressource elle-même ne peut être évaluée qu’en contexte, on saisit l’ampleur de la tâche. Il y a un parcours interprétatif considérable entre les résultats de l’outil et la ressource construite. De ce fait, la comparaison des résultats de l’outil et d’une ressource de référence ne peut apporter que des évaluations limitées, même si elle fournit des indications intéressantes pour faire évoluer l’outil (Nazarenko et al., 2001).

L’idéal serait par exemple de comparer deux modèles, l’un construit avec tel outil, et l’autre sans, en termes de temps de réalisation et de qualité.

Quand on connaît le temps de développement d’un modèle, on imagine la lourdeur et la difficulté de mise en œuvre d’une telle méthodologie. Le problème reste ouvert. Pour mesurer, ne serait-ce que d’un point de vue qualitatif, l’intérêt des outils, considérons pour le moment qu’il est primordial de les tester dans des contextes nombreux et variés et aussi réels que possible pour faire avancer la recherche.

1.4.5.5 Valeur des expériences en IC

L’accumulation d’expériences bien ciblées, décrites et mesurées semble donc une des seules pistes envisageables pour évaluer les propositions de l’IC.

Or B. Bachimont a invité à la prudence dans l’utilisation du terme

« expérience », affirmant de manière provocatrice qu’ « il n’y a pas d’expérience en IC » (Bachimont, 2004). Il rappelle alors qu’expérience correspond ici à la validation expérimentale d’une théorie, d’hypothèses concernant des lois établies pour décrire une ensemble de phénomènes observés. Or justement, n’étant pas une science mais une ingénierie, l’IC ne cherche pas à décrire ou prédire, à travers les modèles qu’elle élabore, des hypothèses scientifiques sur la connaissance. Ces modèles contribuent à

41

définir le comportement du système informatique visé, et leur validation, empirique, se mesure à leur capacité à rendre le système final pertinent.

Pour lui, les modèles conceptuels définissent des normes qui doivent s’ajuster aux usages et pratiques. Et par l’accumulation d’utilisations et d’adaptations de ce type, se définit un cadre d’applicabilité de chaque modèle ou type de modèle pour des usages futurs. L’IC doit être capable de critiquer chaque nouvelle situation et de dégager des principes d’adaptation aux nouveaux usages à partir de ceux déjà réalisés. Une application, un projet ne valide donc pas une technique ou une méthode, mais augmente la possibilité de les critiquer et de préciser comment les adapter ou les réutiliser dans de nouveaux contextes.

De plus, l’IC se nourrit des concepts d’autres disciplines pour en produire des spécifiques. Pour B. Bachimont, cela impliquerait que les modes de validation correspondent aux méthodes des disciplines d’origine de ces concepts. Ceci expliquerait une partie du malaise des praticiens et chercheurs de l’IC. Soit ils valident séparément et selon des approches d’autres disciplines des contributions ponctuelles au processus de modélisation. Soit ils mettent en place des expériences portant sur la globalité de leurs propositions, dont il est délicat d’identifier ce qu’elles valident.

Face à cette vue qui me semble réductrice, puisqu’elle donne l’impression d’une faible créativité et d’un manque de repères pour évaluer les propositions faites, j’oppose près de quinze années de recherche dans le domaine. Ces travaux ont produit des résultats propres à l’IC, et pas seulement empruntés, essentiellement sur les représentations et les typologies de modèles conceptuels, leurs composantes ou encore leur mode de construction. Le souci constant de la validation a pris des formes originales pour chacune de ces contributions prises séparément, qui passe souvent par le développement de prototypes, de modèles ou d’applications illustrant la mise en œuvre de ces propositions. Globalement, la particularité du domaine est de rappeler la nécessité d’utiliser les concepts proposés dans des situations réelles, pour contribuer à des projets opérationnels avec leurs contraintes. Ces utilisations ne sont peut être pas des expériences au sens de la physique : il faudrait construire l’application une première fois selon une approche « classique » puis une deuxième fois selon la méthode ou les outils originaux proposés, et mesurer le gain apporté. Toutefois, elles offrent un retour suffisant pour juger de l’intérêt des propositions mises en place, pour estimer leurs apports effectifs ou leurs limites. La confrontation de plusieurs expériences pose la base d’une réflexion sur le statut des modèles, sur ce qui fait leur pertinence, ainsi que sur le rôle et les compétences des personnes concernées, en particulier le cogniticien chargé de mener à bien le processus. Je rejoins ici B.

Bachimont : les expériences ne peuvent pas tenir lieu de validation absolue, mais elles orientent des choix et infléchissent des directions.