chapitre 7 Epistémologie et méthodes de la modélisation IA
Newell (81) affirme que le niveau *1conceptuel le plus important d'un système à bases de connaissances est le "knowledge level".
"The focus for determining the behavior of the system rests with the knowledge, i.e. with the content of what is known. The internal structure of the system is defined exactly so that nothing needs to be known about it to predict the agent's behavior. The behavior is to depend only on what the agent knows, what it wants [....] (Newell 81:20).
Cette vision de Newell donne une vision très fonctionnelle à la notion de connaissance. Elle s'accorde bien à la problématique de la modélisation du décideur. Lorsqu'on modélise un décideur politique, on lui attribue des connaissances (le "knowledge level"). Le contenu de ces connaissances encodées dans un langage de représentation peut être calculé selon les principes "rationnels" de l'infrastructure du "knowledge level"*2. Au plan de l'observation du système, les connaissances à modéliser correspondent donc à ce que le système fait grâce au contenu des représentations. Pour "comprendre" (au sens herméneutique du terme) le modèle, il faut "lire" les représentations et les simuler (les "penser"). Autrement dit, l'utilisateur qui étudie le comportement d'un modèle, devrait transposer ces représentations au "knowledge level" pour les traiter ensuite dans son système de représentations grâce à des processus cognitifs. Le même principe s'applique à l'étude de la dynamique d'un système: les nouvelles structures générées par le système peuvent être interprétées au niveau des connaissances.
Notre idée de modélisation est d'utiliser un langage "informatique" pour parler dynamiquement des connaissances utilisées (quasi-)rationnellement par un individu ou une organisation. Ainsi, pour modéliser un décideur, il est important d'utiliser des langages de représentations qui peuvent être "lus" et interprétés facilement. Sinon le modèle possède une orientation trop "psychologique" voire "psycho-biologique", ce qui n'est pas notre but. La description d'un système au "knowledge level" met l'accent sur le contenu d'un système (buts, actions), tandis qu'une description au "symbol level" fait référence à des représentations et des mécanismes d'inférence. La notion de représentation prend sa signfication théorique avant tout à ce niveau de description inférieure de la cognition (le "symbol level" de Newell) d'où sa formule "representation = knowledge + access". C'est ce niveau-là qui réalise un jeu de connaissances et il nous intéresse moins ici. Ainsi faut-il conceptuellement bien distinguer le contenu des connaissances que l'on met dans un système (par exemple sous forme de règles) et ce que le système peut en faire grâce à la forme des contenus et ses mécanismes d'inférence.
Dans la littérature de recherche récente*3 sur les systèmes expert, le "knowledge level" est surtout valorisé comme étape intermédiaire dans le processus du "knowledge engineering". La notion du "knowledge level" est plus opérationel que chez Newell et elle s'intéresse beaucoup aux types de connaissances utilisées par un agent humain. En étudiant la structure de quelques systèmes bien connus, Clancey (83) a mis évidence l'importance des connaissances implicites qui ne sont pas explicitées dans les règles, mais "perdues" dans les heuristiques de sélection des règles. Le besoin de dissocier plusieurs niveaux de connaissances est devenu particulièrement clair dans le développement de systèmes tuteurs intelligents. L'apprentissage de raisonnements complexes exige en effet de pouvoir isoler les aspects stratégiques de la résolution de problème. Ceci montrait qu'une réalisation typique d'un jeu de connaissances marchait bien pour un certain type de simulation (système expert) et qu'il en fallait une autre pour un autre domaine (enseignement). Ce type d'observation a amené Breuker (85) et d'autres à postuler une analyse beaucoup plus poussée des connaissances avant l'implémentation. Il s'agissait notamment de rendre explicites les différents types de connaissances utilisées implicitement par l'expert et pas seulement celles qui sont nécessaires à première vue pour faire tourner un système. Steels (90:37-42) distingue par exemple les composantes d'expertise suivantes:
Generated with WebMaker