1

Intellectica, 1991/2, 12, pp. 101-137

Jean-Paul KRIVINE et Jean-Marc DAVID L'ACQUISITION DES CONNAISSANCES VUE COMME UN PROCESSUS DE MODLISATION : MTHODES ET OUTILS
Introduction I. Transcription ou modlisation ? II. Un peu d'histoire III. Modliser le domaine, modliser le raisonnement 1. A propos des mthodes de conception orientes objets 2. Des primitives pour modliser le raisonnement - Generic Tasks de Chandrasekaran - Le modle d'expertise de KADS - Convergence des approches 3. Une architecture refltant le modle conceptuel IV. L'acquisition des connaissances 1. Construction du modle 2. Instancier le modle conceptuel V. Aide l'acquisition des connaissances 1. Aide l'instanciation de modles - MOLE (Eshelman 88) - SALT (Marcus 88) - Protocole dans le systme DIVA 2. Aide la construction de modles - KADS

- Generic Tasks - RIME Conclusions

Introduction L'acquisition des connaissances est une des difficults majeures de la conception des systmes experts. Combien de centaines d'articles commencent par une telle introduction. Pourtant cette affirmation, bien qu'exacte, est trop gnrale. Il nous semble important de mieux prciser o est la difficult et quelle est la nature du goulet d'tranglement, pour reprendre l'expression consacre. C'est ce que nous allons chercher faire dans la premire partie de cet article en montrant comment l'acquisition des connaissances, perue initialement comme un problme de transcription, est maintenant considre comme un problme de modlisation. Nous dcrirons ensuite les travaux visant donner une base cette modlisation. Nous montrerons enfin comment il est alors possible de mettre au point des mthodes de conception et de construire des outils automatiques d'aide l'acquisition des connaissances. Les affirmations suivantes, que nous chercherons argumenter, vont servir de structure cet article : 1- L'acquisition des connaissances est principalement un processus de construction de modles. 2- La mauvaise adquation du niveau d'abstraction des formalismes classiquement utiliss dans la premire gnration de systmes experts a induit un processus d'acquisition des connaissances dirig par l'implmentation. 3- Les mthodes de conception dites orientes objets permettent de bien modliser une partie du problme (modlisation du domaine) en proposant

un niveau d'abstraction adapt. Mais elles sont incompltes pour modliser la rsolution du problme dans son ensemble.

4- Construire un modle de la rsolution de problmes ncessite des primitives permettant de reprsenter le raisonnement et les mthodes de rsolution. 5- Des outils d'aide et des mthodes de conception assez puissants vont pouvoir s'appuyer sur ce paradigme. Ces outils seront exposs dans le dernier paragraphe de cet article. I. Transcription ou modlisation ? L'acquisition des connaissances constitue l'une des tches les plus dlicates lors de la conception d'un systme base de connaissances. La littrature en ce domaine est abondante. Mais avant de poursuivre, il importe de prciser un point de vocabulaire. Les travaux dans ce domaine se sont clairement diviss en deux groupes ayant des objectifs relativement diffrents (Aussenac 1989) : le transfert d'expertise qui vise mettre en place des moyens pour donner un systme base de connaissances les connaissances issues d'un expert, de documents ou de manuels, et l'apprentissage automatique, qui vise doter les systmes de capacits d'acquisition de nouvelles connaissances par eux-mmes. Dans cet article, nous nous intresserons essentiellement au transfert d'expertise dans le sens donn ci-dessus. Mais en quoi consiste donc l'acquisition des connaissances lors de la conception d'un systme expert 1? Il est important de souligner que la dfinition de cette activit a largement volu dans la dernire dcennie. L'acquisition des connaissances a d'abord t perue comme une activit d'accs quelque-chose de prexistant puis de transcription dans un formalisme donn. Ainsi, l'expert du domaine tait sens possder une connaissance plus ou moins explicite qu'il s'agissait d'extraire (do
1

Les termes systme expert et systme base de connaissances seront employs sans distinction dans la suite de larticle

l'expression extraction des connaissances) pour ensuite la transcrire dans un programme, selon un formalisme plus ou moins universel : rgles de productions, objets, logique... (Hayes-Roth & al. 1983). Trs tt, des difficults sont apparues. D'une part, le dcalage trop important entre le langage utilis par l'expert et le niveau d'abstraction des formalismes de reprsentation des connaissances a constitu un obstacle que de nombreux travaux ont cherch surmonter. Ceux-ci se sont principalement attachs fournir des niveaux intermdiaires permettant une meilleure modlisation du problme. Nous reviendrons largement sur ces travaux qui ont conduit redfinir l'acquisition des connaissances en terme de construction de modles. D'autre part, le caractre subconscient et implicite des connaissances de l'expert a ncessit le dveloppement de nombreuses techniques de verbalisation et d'aide aux interviews d'experts. A propos de ces techniques d'licitation, on pourra se reporter Hoffman (1989) ou Aussenac (1989). Bien que ceci ne soit pas totalement indpendant de notre propos, nous n'insisterons pas sur cet aspect du problme. Mais notons avec Breuker & Wielenga (1989) que le problme n'est pas tant qu'il serait impossible d'obtenir par de telles techniques une description trs dtaille de toutes les connaissances utilises, mais que nous serions incapables de les organiser. Le goulet d'tranglement (la phase d'acquisition des connaissances) apparat ainsi plutt comme un facteur limitatif, un filtre indispensable, qui permet effectivement d'aborder le problme. Ces mthodes de verbalisation, pour aussi utiles qu'elles soient, ne peuvent donc se suffire. Mais revenons sur la premire difficult, le dcalage entre le langage dans lequel l'expert exprime ses connaissances et le niveau d'abstraction des formalismes classiques de reprsentation des connaissances. Il est apparu progressivement que le problme n'tait pas simplement un problme de transcription, mais fondamentalement un problme de

modlisation (Boose, Nagai 1987). L'acquisition des connaissances se fixe alors pour but la construction de modles (Clancey 1985, Wielenga & Breuker 1986, Clancey 1989). En effet, si les systmes que l'on construit visent simuler des performances d'experts dans un domaine particulier, pour une tche prcise, ils n'ont pas la prtention de reflter ou modliser les processus rellement mis en oeuvre par le cerveau humain. A partir des donnes et connaissances issues des interviews et des verbalisations, le cogniticien doit organiser cette information et abstraire des concepts. En ce sens, il s'agit bien de construire un modle. Il importe nanmoins de prciser que cette modlisation comporte deux aspects imbriqus : une modlisation du domaine et une modlisation du processus de rsolution, du raisonnement (Wielinga & Breuker 1986, Steels 1990). Si le premier a souvent t largement trait, en particulier au travers des mthodes de conception orientes objets, le second est souvent nglig ou ramen dans le formalisme du premier. Pourtant, et c'est un des propos essentiels de cet article, la modlisation explicite des processus de raisonnement est indispensable pour la mise en place de mthodes compltes de conception ou de cration d'outils automatiques. Elle ncessite des primitives et un formalisme adapt de reprsentation. Au del d'une grande diversit de vocabulaire, de nombreux travaux ont recherch une telle modlisation ce que Newell a appel le knowledge level (1981). II. Un peu d'histoire Comme nous l'avons indiqu, l'acquisition des connaissances, encore au dbut des annes 80, tait comprise comme un processus de transcription dans un formalisme rput gnral (souvent bas sur un systme de rgles de productions) d'un savoir recueilli auprs d'un expert. Ainsi, dans Building Expert Systems, l'ouvrage de rfrence du dbut des annes 80,

F. Hayes-Roth, D. Waterman et D. Lenat distinguaient-ils 5 phases dans la conception d'un systme expert.
[1] Identification : Dterminer les caractristiques du problme. [2] Conceptualisation : Trouver les concepts reprsentant les connaissances. [3] Formalisation : Concevoir les structures pour organiser les connaissances. [4] Implmentation : crire les rgles qui capturent les connaissances. [5] Test : Valider les rgles qui capturent les connaissances. figure 1 : Les tapes de la construction d'un systme expert (Hayes-Roth & al. 1983)

L'tape 3 de formalisation tait ainsi dcrite : Formalization involves mapping the key concepts and relations into a formal representation suggested by some expert-system building tool or language. The knowledge engineer must select the language and, with the help of the expert, represent the basic concepts and relations within the language framework (Hayes-Roth & al. 1983). Pour caractriser cette poque, plusieurs auteurs parleront d' acquisition des connaissances dirige par l'implmentation (Hickman & al. 1989). En effet, le niveau d'abstraction fourni par les structures classiques de reprsentation des connaissances, les expert-system building tools cits plus haut (frames, logique, rgles, etc.) est trop bas pour permettre de reprsenter les connaissances et le contrle de manire satisfaisante. Chandrasekaran ira mme jusqu' employer l'expression langage d'assemblage des connaissances pour comparer ce niveau celui effectivement ncessaire : These architectures (with relatively small additions, if needed) are computationaly universal. Thus the important point about building

knowledge systems with them is not whether a task can be performed, but whether they offer knowledge and control constructs that are natural to the task. All of these (and other similar) languages fall short when one considers tasks of some complexity such as planning or diagnosis. (...) The level of abstraction of these languages obscurses the essential nature of the information processing that is needed for the performance of higher level tasks. They are like knowledge system assembly languages, rather than programming languages with constructs for capturing the essence of the information processing phenomena (Chandrasekaran 1987). Ainsi, dans la ralit, les tapes de formalisation et d'implmentation d'un systme expert vont bien souvent faire appel des trucs et astuces de programmation. La figure 2 tire de Programming Expert Systems in OPS5 (Bronstown & al 1985) rcapitule les techniques pour bien programmer en OPS5. Un tel type de connaissance est en fait indispensable, et pas seulement dans le but de programmer efficacement. On est loin de lessence des processus de traitement de l'information souhaite par Chandrasekaran. Comprendre le fonctionnement d'un systme expert devient alors une tche ardue. La figure 3 montre un exemple de rgle de MYCIN et les connaissances ncessaires son interprtation. Cet exemple est tir de Farenny (1987).

[1] Avoid conditions that match many working memory elements. a) Add attribute tests that change the condition so that fewer working memory elements match it. Tests may be based on restrictions to data or on state of processing. b) Add new element classes or modify representation to change the data elements so that fewer of them match the condition. c) Represent and enumerate sequences carefully. [2] Avoid big cross-products between conditions. a) Order the conditions so the more restrictive ones occur first. This limits the number of consistent matches that are passed on to the next condition. b) Write rules with a few big conditions rather than many simple conditions by merging the attributes of related element classes into fewer element classes. c) Use build to specialize rules. [3] Avoid frequent changes to matched conditions. a) Put conditions that match frequently changing elements as far toward the end of the rule as possible. b) Avoid excessive changes in control elements. [4] Make matching individual condition elements faster. a) Put the most restrictive attribute tests first to speed the match of working memory elements against conditions. b) Change the representation of data to speed up matching. [5] [6] Limit the size of the conflict set. Call user-defined functions. figure 2 : Programmer efficacement en OPS5 (Brownston & al. 1985)

Cette difficult a galement t largement souligne propos de l'volution du systme R1 de Digital Equipement, systme considr comme l'un des touts premiers systmes experts oprationnels (Bachant & McDermott 1984).

10

La rgle suivante est issue du systme MYCIN, pour le diagnostic des maladies du sang. MYCIN est l'un des premiers systmes experts. Son architecture est reprsentative d'une grande partie des ralisations actuelles. R1 SI la coloration de l'organisme est GRAM+ et si la morphologie de l'organisme est Cocci et si le mode de dveloppement de l'organisme est en colonies ALORS il existe une vidence (0.7) que l'identit de l'organisme soit Staphylococcus.

Pour crire une telle rgle, le concepteur devra savoir comment MYCIN fonctionne. Ici, il faut savoir que cette rgle, parce qu'elle conclut sur l'identit de Staphylococcus et parce que le moteur fonctionne en chanage arrire, ne sera envisage que lorsque le systme se proccupera de dterminer l'identit d'un organisme. Il faut de plus savoir qu' chaque instant, le moteur s'intresse un contexte particulier, c'est--dire un organisme retrouver. Un ordre des prmisses dans une autre rgle fera en sorte que MYCIN s'intressera d'abord l'organisme courant avant de rechercher des organismes prsents antrieurement. A chaque type d'organisme est associ un ensemble de caractristiques (par exemple, identit de l'organisme pour l'organisme courant). A chaque caractristique est associ un attribut mis--jour-par qui contient la liste des rgles qui permettent d'tablir la caractristique en question (l'identit de l'organisme, par exemple). La rgle R1 ci-dessus fait partie de cette liste de rgles... Voil pourquoi et comment cette rgle va tre examine ! figure 3 : Un contrle largement implicite

A la base de ceci tait sans doute la conviction que les langages de l'IA sont suffisamment puissants et naturels pour encoder les connaissances utiles. N. Aussenac dveloppe ce propos le parallle entre diffrents modles cognitifs et diffrents formalismes de reprsentation des connaissances (Aussenac 1989). Porcheron, dans sa thse, rappelle la

11

problmatique des rgles de production et lopinion sur la qualit anthropomorphique des systmes de production (Porcheron 1990). Il cite ce propos Newell et Simon : We confess to a strong premonition that the organization of human programs closely resembles the production system organization... (Newell & Simon 1972). Aujourd'hui, sans aller jusque l, on observe toujours une tendance attribuer des qualits intrinsques trs fortes au diffrents langages de reprsentation des connaissances. Si la mode rgles de production est maintenant largement attnue, certaines des critiques faites peuvent s'appliquer aux langages objets et mthodes orientes objets. Nous y reviendrons dans le paragraphe suivant. Les limites des formalismes classiques et le cadre contraignant qu'ils imposent s'ils sont adopts comme seul formalisme de conceptualisation ont t souligns trs tt. Ainsi, il est intressant de rapporter le commentaire fait par Davis lui-mme sur Mycin l'occasion de la conception de TEIRESIAS, systme d'aide l'acquisition de nouvelles rgles de MYCIN : We speculated about the possibility of a representation of control structures that emphasized intentional information, which, combined with a formalization of the concept of explanation, might make the system far more flexible and general. It might, ideally, be possible for the system to examine its own code, generating explanations of what it found there (Davis & Lenat 1982). Nanmoins, Clancey est probablement le premier raliser un systme sur de tels principes. NEOMYCIN, qui traite le mme problme que MYCIN, va manipuler des primitives telles que grouper et diffrencier,

12

identifier le problme, tablir l'espace des hypothses (Clancey 1986) alors que MYCIN faisait du chanage arrire, du pattern matching, de la rsolution de conflits. Ce type d'architecture va tre la base d'une nouvelle gnration de systmes experts appels Systmes Experts de Seconde Gnration (David & al. 1989), et va offrir un cadre pour des mthodes plus labores d'acquisition des connaissances. III. Modliser le domaine, modliser le raisonnement 1. A propos des mthodes de conception orientes objets Avec le large dveloppement des langages orients objets est apparue une multitude de mthodes de dveloppement orientes objets. Il nous semble important de les examiner avec un regard critique afin d'viter de retomber dans les travers noncs plus haut propos des systmes base de rgles. Nous allons prciser leurs forces et leurs limites. Classiquement, la conception d'un systme base de connaissances, la construction d'un modle qualitatif selon l'expression de Clancey, comportera deux aspects (d'ailleurs largement interdpendants) : Une modlisation du domaine : domain models dans Wielinga & Breuker (1986) et Steels (1990). Une modlisation du processus de rsolution, du raisonnement : task level dans Wielinga & Breuker (1986), Role-limiting-methods dans McDermott (1988) ou Problem Solving Methods pour d'autres auteurs.

Le premier type de modlisation va tout naturellement faire appel un certain nombre de primitives. On cherchera dcrire les objets, les entits du domaine, identifier les concepts. Chacun d'entre eux sera qualifi en

13

termes de caractres, de comportements. On cherchera ensuite dcrire leurs relations mutuelles et les dcompositions ventuelles. Ainsi, tout logiquement, les langages orients objets (ou des langages analogues, langages centrs relations par exemple) vont offrir un cadre naturel pour ce type de modlisation. Ils offrent en effet les bonnes primitives de modlisation : classes, attributs, hritage, relations, mthodes, etc. Ils apparaissent comme des bons formalismes de reprsentation, au bon niveau d'abstraction, pour le premier type de modlisation voqu cidessus. Les mthodes orientes objets ne font que formaliser cette adquation en proposant un protocole permettant l'mergence des bons concepts . Ainsi, G. Booch (1986) propose dans sa mthode la dcomposition suivante : - Identifier les objets du monde rel, les caractristiques de ces objets. (Diffrentes techniques sont suggres pour aider les faire ressortir partir de la verbalisation des experts). - Identifier les oprations : ce sont les actions que peut subir ou provoquer chaque objet. - tablir la visibilit : comment chaque objet est vu des autres, comment ils communiquent. - tablir l'interface, c'est--dire la visibilit des objets par le monde extrieur. - Implmenter les objets, ce qui peut ncessiter la cration d'objets de plus bas niveau d'abstraction. Cette dcomposition assez caractristique se retrouve dans beaucoup d'autres mthodes (voir par exemple Meyer 1988). Mais soulignons ici le point essentiel : la force de ce type de mthodologie provient d'abord de la bonne adquation entre le formalisme

14

de reprsentation des connaissances (le concept d'objet) et la ralit que l'on veut modliser (le domaine). Les limites sont prcisement celles du type de modlisation que l'on aborde. Vouloir donner un caractre plus gnral ces mthodes, et en particulier celui de permettre les modlisations du raisonnement, conduit aux mmes biais que ceux noncs plus haut propos des dbuts de l'acquisition des connaissances. En effet, modliser un raisonnement, un processus de rsolution de problme va ncessiter d'autres primitives. De ce point de vue, les mthodes (au sens des langages objets) apparaissent aussi pauvres que les rgles. L'adquation souligne ci-dessus disparait. Les mthodes dites orientes objets ne suffisent plus. Enfin, il convient de rpter ici que modlisation du domaine et modlisation du raisonnement, sont totalement imbriqus. On ne modlise jamais un domaine dans l'absolu, sans la dfinition d'un traitement spcifique, d'une utilisation particulire. La bonne adquation mentionne plus haut concerne donc plutt des problmes o le traitement sur les donnes est relativement simple et homogne, ce qui est souvent le cas dans les systmes d'information classiques. 2. Des primitives pour modliser le raisonnement (i) Generic Tasks de Chandrasekaran De nombreux auteurs ont soulign la mauvaise adquation des formalismes de description de la premire gnration de systmes experts (rgles, objets, frames, etc). Ainsi Chandrasekaran fera-t-il remarquer que MYCIN est soit dcrit comme un systme de diagnostic des maladies du sang, ce qui est exact mais trop gnral, soit comme un systme expert faisant du chanage arrire et utilisant des coefficients de vraisemblance, ce qui est galement vrai, mais peu informatif. Pourtant, on conoit qu'il existe des stratgies diffrentes entre, par exemple, la mthode de

15

conception d'une automobile et la manire dont on va diagnostiquer une panne de moteur. Or, ces deux tches vont utiliser les mmes primitives : dclencher des rgles, rsoudre un ensemble de conflits, vrifier des prmisses, etc. A l'oppos, diagnostic mdical et diagnostic de cartes lectroniques par exemple, sont deux tches de diagnostic. Mais chacune met en oeuvre des techniques et mthodes trs diffrentes. Le terme diagnostic dcrivant ces deux activits apparat ainsi comme un peu trop gnral et ne prcise pas la mthode mise en oeuvre. D'un ct donc, des langages de trop bas niveau d'abstraction, d'un autre ct, une description trop gnrale Chandrasekaran (1983, 1987), Chandrasekaran & al. (1989). L'objectif est alors double. D'une part, on va chercher fournir un langage de description au bon niveau d'abstraction et d'autre part, un ensemble de modles gnriques pouvant servir de briques de base cette modlisation vont tre proposs. Il s'agit en fait de trouver le pendant des primitives de modlisation du domaine, voques dans le paragraphe prcdent (objets, relations, attributs, etc.), mais cette fois pour la modlisation du raisonnement. Le bien fond de cette approche est confort par l'identification, dans des systmes diffrents, de tches similaires, par exemple l'abstraction de donnes et la classification dans NEOMYCIN (Clancey 1986), MDX2 (Sticklen 1989) ou DIVA (David & Krivine 1989). C'est dans ce cadre que Chandrasekaran a propos son approche Tches Gnriques sur laquelle nous reviendrons. (ii) Le modle d'expertise de KADS Le dveloppement de KADS (Breuker & Wielenga 1985, 1989) s'appuie sur des motivations similaires mais avec de plus, la volont de conserver ce qui tait sain dans les mthodes classiques de dveloppement de logiciels, tout en y intgrant la spcificit des systmes base de

16

connaissances (Hickman & al. 1989). Ces spcificits concernent essentiellement la phase d'analyse qui va dboucher sur des modles plus complexes. Les auteurs ont ainsi propos un modle d'expertise permettant de dcrire la rsolution du problme par le systme. C'est le modle en 4 couches propos par (Wielinga & Breuker 1986) o chaque couche va organiser et structurer la couche infrieure : [1] Domaine : Connaissances statiques dcrivant les concepts, relations et structures du domaine. [2] Infrence : Les infrences qui peuvent tre faites sur les entits du niveau prcdent (description en termes de rles et de sources de connaissances). [3] Tches : Comment effectuer et squencer les infrences afin d'atteindre un but. [4] Stratgie : comment enchaner les diffrentes tches, grer les checs d'une mthode de rsolution, etc. On retrouve une dcomposition analogue celle faite plus haut entre modles du domaine (ici, essentiellement la couche 1) et modles du raisonnement (les couches 2, 3 et 4). (iii) Convergence des approches Au-del d'un vocabulaire parfois disparate, ces diffrents travaux partagent une mme motivation : appuyer la conception d'un systme expert sur des primitives d'un meilleur niveau d'abstraction . Le terme knowledge level souvent employ pour dsigner un tel niveau est d Newell (1981) qui l'oppose au symbol level. Ce knowledge level caractrise ce que fait le systme et les connaissances utilises, indpendamment du formalisme de reprsentation. Les travaux dcrits dans les sections prcdentes proposent des primitives de modlisation que Steels (Steels 1990) a cherch unifier

17

dans une mme terminologie. Les trois concepts de base seront alors : les tches, les mthodes de rsolution de problmes et les connaissances du domaine. Les tches. Une tche va tre associe un but atteindre. Elle va tre caractrise par les proprits des entres, les rsultats attendus en sortie et la nature des oprations permettant le processus de transformation. Une tche de classification, par exemple, va indiquer en sortie les classes d'une taxinomie les plus reprsentatives d'une instance relle particulire fournie en entre. Les mthodes de rsolution de problmes (ou Problem Solving Methods). C'est la manire d'excuter une tche particulire, de satisfaire un but. Plusieurs mthodes peuvent s'appliquer une mme tche. Par exemple, pour une mme tche de classification, on peut imaginer une grande varit de mthodes de rsolution (Steels 1990) : recherche linaire, recherche par raffinement descendant, recherche associative, diffrenciation, calculs de distances, etc. Une mthode particulire peut induire une dcomposition de la tche qu'elle rsout en sous-tches. Les connaissances du domaine (ou Domain Knowledge). Elles reprsentent l'univers du problme, et plus particulirement la partie utile aux mthodes de rsolution de problmes (par exemple une taxinomie de pannes dans un systme de classification)

Pour une discussion plus prcise de ces concepts on se reportera Steels (1990), Karbach & al. (1990) ou Vanwelkenhuysen & Rademakers (1990) par exemple. Tches et mthodes de rsolution de problmes vont lgrement varier selon les auteurs. Clancey produira une des premires analyses dtailles d'une tche particulire (classification). Chandrasekaran et son quipe chercheront identifier un ensemble vari

18

de tches pouvant servir de base une bote outils (Generic Task Toolset). McDermott sera un des premiers aborder le problme de plusieurs mthodes pour une mme tche. Au del d'un vocabulaire pas toujours trs homogne, de relles convergences se dessinent aujourd'hui. Nous avons montr que l'acquisition des connaissances ncessitait la construction d'un modle du problme que l'on veut traiter. Cela revient identifier les grandes tches ralises, pour chacune d'elles, spcifier les mthodes mises en oeuvre et donc les sous-tches qui en dcoulent. Pour cela, il est ncessaire de disposer de primitives au bon niveau d'abstraction. Les travaux dcrits plus haut traitent ce problme. Le modle en 4 couches de KADS, les trois concepts proposs par Steels, les role-limiting-methods de McDermott sont relativement quivalents pour notre propos dans cet article. Ils constituent des primitives de modlisation. Dans la suite, nous appellerons modle conceptuel un modle construit l'aide de ces primitives 2. Sur cette base, nous indiquerons plus loin des outils d'aide l'acquisition des connaissances qui ont t rcemment dvelopps. 3. Une architecture refltant le modle conceptuel La question de l'implmentation du systme est une question cruciale. Comment passer d'un modle conceptuel un systme rel ? Comment ne pas perdre les avantages d'une conception au bon niveau d'abstraction? En effet, analyse, spcification et implmentation sont sujettes tre remises en cause au fur et mesure de l'avancement d'un projet. On le conoit alors, le modle conceptuel doit se reflter sous une forme ou une autre dans l'architecture du systme. Faute de quoi, toute la formalisation
2

Une dfinition applicable l'informatique classique est donne dans (Aussenac 1989) et semble particulirement adapte : Le modle conceptuel est un cadre smantique partag par des utilisateurs d'un programme et ses dveloppeurs qui leur permet de communiquer. On trouvera galement une dfinition intressante dans (Norman 1983).

19

du problme dcrite prcdemment risque de ne s'avrer qu'une belle construction pour l'esprit. En outre, la qualit de l'architecture va avoir d'autres avantages que la seule aide l'acquisition des connaissances : la maintenance et l'volution de la base de connaissances seront facilites, les explications gnres seront de meilleure qualit. Chandrasekaran propose une architecture adapte chacune des tches gnriques identifies. Chaque tche possdant ses propres connaissances et sa propre stratgie de rsolution sera implmente dans un formalisme adapt. La bote outils propose consiste en un regroupement de shells de dveloppement pour chacune des tches gnriques. Il y a d'ailleurs correspondance entre les shells et les tches gnriques : ces dernires sont considres comme des blocs constitutifs de base, non dcomposables. Construire un systme consiste alors identifier les grandes tches ralises et slectionner les shells correspondants. Le contrle de l'ensemble reste nanmoins encore assez mal dfini. Il est cens merger de l'interaction entre les diffrentes tches, celles-ci communiquant par envoi de messages. De rcents travaux ont cherch traiter diffremment cette question (Punch & Chandrasekaran 1990). La mthodologie KADS souligne galement la ncessit d'une architecture refltant le modle conceptuel. Il est mme fait rfrence un semi-isomorphisme entre les modles issus de l'analyse (en termes de tches) et l'implmentation. Dans la pratique, ceci devrait se faire au travers d'une succession de modles conduisant des spcifications de plus en plus prcises. La dcomposition en termes de tches, mthodes et modles du domaine prsente plus haut a suscit un certain nombre dautres travaux visant la ralisation d'architectures permettant une reprsentation explicite et plus naturelle de ces concepts (Pierret-Goldbreich & Delouis 1990), (Vanwelkenhuysen & Rademakers 1990) ou (Tong & Tueni 1990) par exemple. Il est intressant de noter ici la convergence avec les recherches sur les Blackboards (Nii 1989) ou sur des architectures

20

vocation plus large telles que SOAR (Laird & al. 1987), en particulier pour l'expression du contrle dans ces systmes. IV. L'acquisition des connaissances L'acquisition des connaissances a t dfinie essentiellement comme un processus de modlisation. Des typologies et des primitives ont t proposes dans le paragraphe prcdent. Nous allons maintenant montrer comment elles permettent d'aider ce travail de modlisation. Deux tapes distinctes doivent tre auparavant distingues : l'tape de construction du modle, l'tape d'instanciation du modle prcdemment construit. Des outils diffrents viseront faciliter chacune de ces tapes. Ces outils seront dcrits dans le paragraphe 5. 1. Construction du modle La construction de modles va s'appuyer, d'une part, sur l'ensemble des primitives dfinies plus haut, d'autre part, sur l'existence d'une bibliothque de modles gnriques. Cette partie du processus d'acquisition des connaissances s'en trouve ainsi facilite : Il est en effet beaucoup plus simple de construire un modle par raffinements successifs partir de modles gnriques que de le crer ex-nihilo. C'est la dmarche suggre par la mthode KADS (slectionner et raffiner des modles gnriques). C'est galement la logique des Generic Tasks de Chandrasekaran. Bien sr, ce n'est pas toujours possible. La bibliothque de tches gnriques peut tre insuffisante, le problme traiter peut tre atypique ou d'un nouveau type. Dans de tels cas, s'il reste une part d'empirisme, on gagne au moins se poser de bonnes questions, ou tout du moins de meilleures

21

questions. Un modle du type de celui propos dans KADS (le modle d'expertise en 4 couches) indique la structure de ce qu'il faut construire (ce modle est d'ailleurs galement utile pour raffiner des modles gnriques prexistants). S'interroger sur le systme que l'on construit en termes de tches, mthodes de rsolution de problmes et modles du domaine est mieux adapt que de se poser des problmes de chanage avant, arrire ou ensemble de conflits. 2. Instancier le modle conceptuel Une fois le modle conceptuel labor, il s'agit de le remplir, c'est-dire d'y inclure les connaissances ncessaires. Bien que cette deuxime tape puisse rtro-agir sur le modle prcdemment construit, elle sera souvent clairement dissocie partir d'un certain tat d'avancement. Cette phase d'instanciation de modles a t plus largement approfondie par diffrentes quipes, et depuis plus longtemps. Les avantages sont donc mieux identifis, les outils automatiques d'aide sont plus nombreux. Le point cl est la bonne identification du rle jou par chacune des connaissances dans le processus de rsolution de problme. On sait prcisment ce qui doit tre acquis et quel rle chacune des entits de connaissance va jouer. Parmi les avantages de l'approche, nous pouvons relever un certain nombre de points (David & Krivine 1988, Marcus 1988) : On sait ce qu'il faut acqurir. L'acquisition des connaissances est guide par le modle que l'on cherche remplir. Chaque tche, chaque mthode de rsolution de problme ncessite des connaissances prcises, pour un rle bien spcifi. Du ct de l'expert, une bonne dfinition et une bonne comprhension de la fonction des connaissances demandes en facilite l'expression.

22

On dispose d'une sorte de mtrique sur l'avancement du travail de constitution de la base de connaissances. On peut ainsi identifier facilement les endroits o il manque des connaissances. Ceci peut tre mis profit dans une phase de mise au point du systme (simulation des mthodes manquantes lors de la validation incrmentale d'une base encore incomplte). Le systme sait galement identifier lui-mme les mthodes o les connaissances sont manquantes. Il lui sera alors possible, dans une phase de rsolution de problme, de rechercher des mthodes alternatives pour la mme tche ou, ventuellement, de demander l'utilisateur. Ainsi, le systme peut avoir une meilleure comprhension de ce qu'il sait faire et de ce qu'il ne sait pas (encore) faire.

Sur cette base, et pour des tches particulires, des outils et des mthodes ont t largement dvelopps. C'est ce que nous allons dcrire dans le paragraphe suivant. V. Aide l'acquisition des connaissances Les aides l'acquisition de connaissances que nous allons dcrire se situent bien sr explicitement dans le paradigme dcrit dans cet article. Nous n'avons donc pas la volont d'tre exhaustifs en matire d'outils d'acquisition, ni mme d'tre complets sur chacun des outils dcrits. En particulier, nous ne dcrivons pas les outils ou les mthodes visant aider l'instanciation d'un modle conceptuel en s'appuyant sur des modles plus profonds voir par exemple (Reynaud 1989) ou (Charlet 1989) ou des outils visant une autre partie plus amont dans l'acquisition des connaissances mthode KOD (Vogel 88), MACAO (Aussenac 1989) par exemple. Dans l'aide l'acquisition des connaissances, nous distinguerons des outils (logiciels visant aider le cogniticien construire son systme) et

23

des mthodes de conception, qui peuvent ne pas tre associes un logiciel particulier. Ces mthodes peuvent tre compltes (toutes les phases de l'acquisition dcrites dans cet article) ou plus spcifiques (protocoles particuliers). Enfin, nous avons regroup ces aides en deux classes selon la distinction faite dans le paragraphe 4 : les aides l'instanciation d'un modle particulier et les aides la construction d'un modle conceptuel. 1. Aide l'instanciation de modles Nous allons dcrire deux systmes dvelopps Carnegy Mellon University par l'quipe de John McDermott et portant sur deux mthodes relativement gnriques. Nous verrons ensuite sur un tout autre exemple comment il est possible de mettre en uvre un protocole portant sur un modle conceptuel particulier. (i) MOLE MOLE (Eshelman 1988) est un des premiers systmes de ce type. Il est la fois un shell de dveloppement de systmes experts et un outil d'acquisition des connaissances. MOLE suppose que la tche raliser est une tche de classification et met en oeuvre une mthode de rsolution de problme de type expliquer et diffrencier (cover-and-differentiate). Cette mthode consiste rechercher dans un premier temps des explications exhaustives et exclusives pour des faits observs, des symptmes par exemples 3. Dans un deuxime temps, le systme va rechercher la meilleure explication en liminant celles juges moins satisfaisantes. L'utilisation du systme suppose que l'on s'est assur au pralable que le problme correspondait bien ce type de modlisation (que le modle conceptuel de MOLE est adquat). McDermott suggre un
3

La mme mthode porte le nom d'abduction chez Chandrasekaran.

24

certain nombre de critres afin de s'en assurer : possibilit d'identifier un ensemble d'observations (symptmes, signes) expliquer ; pour chacun d'entre eux, possibilit d'numrer statiquement diffrentes explications ; reprsentation de la stratgie de rsolution sous la forme expliquer puis discriminer, etc. Les connaissances acqurir pour construire un systme avec MOLE sont alors clairement dfinies par le rle qu'elles auront jouer. Il faudra acqurir la liste des observations, pour chacune d'entre elles, les explications possibles, et enfin, les connaissances visant discriminer parmi plusieurs explications concurrentes. MOLE propose alors un outil automatique visant aider l'acquisition de ces connaissances. Une fois les observations expliquer entres dans le systme, MOLE va construire un rseau causal reprsentant les diffrentes explications possibles. Puis il va chercher y incorporer les connaissances permettant d'liminer une explication. Ce processus est itratif. MOLE est capable d'identifier les faiblesses de son rseau pour ensuite aider raffiner les connaissances. MOLE a t utilis pour la construction de plusieurs systmes dans le domaine du diagnostic, bien que la tche ralise (classification) ne soit pas propre au diagnostic. (ii) SALT SALT (Marcus 1988) est un systme d'aide l'acquisition des connaissances pour une tche de conception sous contraintes. Il s'applique des problmes de conception ou d'ordonnancement (affectation de ressources). Les systmes gnrs par SALT mettent en oeuvre une stratgie de rsolution de problme de type Proposer et rviser (propose-and-revise). Le systme expert va commencer par construire un premier plan approximatif. Ceci consiste affecter des valeurs un certain nombre de paramtres. Il va ensuite vrifier qu'aucune contrainte

25

n'est viole par ces valeurs. Pour chaque violation de contrainte, SALT va chercher des modifications permettant d'arriver une solution admissible. Cette mthode de rsolution de problmes va dlimiter les rles que vont jouer les diffrents types de connaissances : Proposer une solution. C'est l'affectation de valeurs un ensemble de paramtres. Des procdures vont indiquer comment calculer des valeurs pour chacun des paramtres. Un paramtre pourra accepter plusieurs mthodes. Une procdure est reprsente sous forme de frame regroupant des informations indiquant le paramtre qualifi, des prconditions ventuelles, une description de la procdure en elle mme (calcul, table, etc.) ainsi qu'une justification indiquant l'origine la mthode. Identifier les contraintes. Diffrentes informations vont dcrire une contrainte : le paramtre contraint, la nature de la contrainte, une prcondition, une justification, etc. Proposer une amlioration. Une rparation va dcrire la manire de remdier une violation de contrainte. Chaque rparation va tre dcrite par plusieurs attributs (paramtre qualifi, type de violation de contrainte, mthode d'amlioration, critres de prfrence, etc.).

Les connaissances de base ncessaires SALT pour gnrer une base de connaissances sont ainsi numres : paramtres, procdure, contraintes et rparation. Une liste d'attributs jouant un rle spcifique bien identifi dans la rsolution de problme vont dcrire chacun de ces objets. Mais si cette description constitue les briques lmentaires du systme, il s'agit ensuite d'organiser l'ensemble de manire cohrente. SALT va alors construire un rseau de dpendance exprimant les relations mutuelles entre ces diffrents concepts. Ce rseau est en quelque sorte la reprsentation interne de la comprhension de SALT du processus de

26

rsolution de problme. Les noeuds du rseau vont tre constitus de paramtres ou de contraintes. Les relations seront de trois types : des relations contribue- pour exprimer qu'une procdure concluant sur un paramtre utilise un autre paramtre, des relations contraint pour exprimer le contenu d'une contrainte et des relations suggre-rvisionde pour exprimer le contenu des rparations. Les connaissances sont maintenant clairement identifies, leur rle est trs prcisement spcifi. C'est sur cette base que SALT peut alors aider acqurir les connaissances. Mais SALT fait plus que de fournir une aide pour remplir les attributs des diffrents concepts numrs. SALT est bien plus qu'un diteur de base de connaissances. Il utilise sa reprsentation du processus (le rseau de dpendance) pour effectuer un certain nombre de vrifications et d'actions. Il va vrifier la compltude du rseau (identification de noeuds o manquent des relations particulires, des noeuds non contraints), sa compilabilit (possibilit d'assigner des valeurs tous les paramtres), son unicit et sa connexit, l'absence de boucle, etc. Il aidera formuler des modifications en cas de problme. SALT a t utilis pour gnrer deux systmes experts : VT pour la conception d'ascenseurs et un systme expert pour l'ordonnancement d'ateliers flexibles (Marcus & al. 1988). (iii) Protocole dans le systme DIVA Nous allons maintenant prsenter un protocole dvelopp pour une des tches composant le systme DIVA. DIVA est un systme expert dont le modle conceptuel est compos de trois grandes tches : une tche d'abstraction de donnes et deux tches de classification (reconnaissance de situations et classification de dfauts ; cf. David & Krivine 1989). L'acquisition des connaissances pour la tche la plus importante (reconnaissance de situations) s'est appuye sur la mise en place d'un vritable protocole. Cette tche de classification met en uvre une mthode de rsolution tablir/raffiner. Le but est de reconnatre dans

27

un ensemble de situations types celles qui rendent le mieux compte d'une situation relle observe. Les situations sont organises au travers d'une hirarchie de situations types (prototypes) que le systme va parcourir. Comme nous l'avons dit plus haut dans cet article, la mthode de rsolution d'une tche particulire induit la dcomposition en sous-tches. Plusieurs mthodes peuvent coexister pour une mme tche. Ici, la stratgie tablir et raffiner va se concrtiser sous la forme de deux tches : la tche tablir et la tche raffiner. Cette dcomposition se poursuivra jusqu' des actions non dcomposables. Une trentaine de tches vont ainsi structurer l'ensemble du systme. Poursuivons en dcomposant maintenant la tche tablir. La mthode de rsolution de cette sous-tche consiste dans un premier temps acqurir les traits les plus importants pour la situation particulire que l'on cherche tablir. Ensuite, si aucune valeur de rejet n'a t obtenue et si suffisamment d'informations significatives ont t acquises, le systme va chercher valuer la correspondance entre la situation relle et la situation typique. Enfin, si le prototype est suffisamment reconnu, des suggestions seront faites quant la poursuite du processus (quels sous-prototypes envisager, dans quel ordre). Le contrle effectif du parcours sera pris en charge par la tche raffiner sur la base de ces suggestions (David & Krivine 1989). De cette stratgie dcoulent logiquement trois sous-tches appeles acquisition des traits caractristiques , valuation de la correspondance et vocation. Chacune de ces tches ou mthodes associes va ncessiter des connaissances spcifiques, pour un rle clairement dfini. Ainsi, par exemple, la premire de ces trois tches va demander l'numration des traits caractristiques de la situation et la seconde va demander les connaissances permettant de juger la correspondance. Sur cette base, un protocole systmatique a pu tre mis en place, structur autour de fiches prototypes (David & Krivine 1988). La transcription de ces fiches dans le systme se fait quasi-automatiquement.

28

En bout de chane, le contenu de la base de connaissances pourra tre restitu sous une forme comparable celle des fiches prototypes. L'expert pourra s'y retrouver et procder des vrifications et de nouvelles modifications. Une importante base de connaissances a pu ainsi se constituer ces deux dernires annes (Ricard & al. 1989) Ce type de protocole illustre les deux facettes du modle conceptuel. D'un ct, son expression dans des termes significatifs pour l'expert (situation typique, reconnaissance de situations), d'un autre ct, dans des termes plus gnriques (classification heuristique, stratgie de recherche). Une illustration de proccupations analogues ayant conduit la ralisation d'un outil automatique d'aide la constitution de la base de connaissances peut tre trouve dans (Musen & al. 1987). 2. Aide la construction de modles Nous allons maintenant dcrire trois ensembles de travaux adressant l'aide la construction de modles. Ils se placent donc en amont des outils et mthodes de la section prcdente. (i) KADS KADS (Breuker & Wielenga 1985, Wielenga & Breuker 1986, Breuker & Wielinga 1989, Hickman & al. 1989) a dj t prsent dans cet article. Si son apport original concerne l'aide la cration de modles, il importe nanmoins de souligner que la mthodologie couvre la totalit des phases de la ralisation d'un systme. Dans un premier temps, des techniques de conduite d'interviews et de verbalisation vont permettre d'accumuler informations et connaissances sur le domaine. Celles-ci vont ensuite tre structures et organises au travers d'un modle conceptuel. Celui-ci va dcrire l'expertise selon les 4 couches exposes plus haut (domaine, infrences, tches et stratgies). Un langage semi-formel va aider cette description. Ce modle conceptuel

29

peut soit tre construit par slection dans une bibliothque de modles d'interprtation gnriques puis raffinement, soit par construction directe. Ensuite, partir du modle conceptuel, une succession de transformations va permettre de spcifier l'implmentation (design model). La structure en 4 couches (le modle d'expertise) et le modle gnrique sont les deux lments essentiels de la mthode. KADS apparat comme trs flexible (Karbach & al. 1990). Nanmoins, la tche de construction du modle conceptuel proprement dite reste trs dlicate et largement base sur l'exprience. Avant d'tre une mthode formelle, KADS apparat encore pour le moment comme une philosophie de conception. (ii) Generic Tasks Nous avons indiqu plus haut les motivations la base de l'approche Tches Gnriques (Chandrasekaran 1987). On peut expliquer l'approche, avec du recul et dans le vocabulaire prcdemment introduit comme suit : Il existe un certain nombre de problem-solving methods qui permettent de traiter une large classe de tches. Ce qui les caractrise, c'est leur faible nombre, leur ubiquit et le fait qu'elles couvrent rellement une large classe de problmes travers diffrents domaines. Ces mthodes sont appeles Tches Gnriques (GT, avec le risque de confusion de vocabulaire qui en dcoule maintenant) auxquelles des connaissances spcifiques sont associes. Pour chaque GT identifie va tre dfini un langage de haut niveau au moyen de la ralisation d'un outil. Les GT vont ainsi apparatre comme des bloc lmentaires (building blocks) permettant, par composition, la conception de systmes complexes. Ceci a conduit la ralisation d'une bote outils (Generic Task Toolset), sorte d'atelier de conception de systmes base de connaissances.

30

Les principales GT de cette bote outils rpondent aux tches suivantes : - classification hirarchique : CSRL (Bylander & Mittal 1986). - synthse (conception) par raffinement descendant de plans prdfinis : DSPL (Brown & Chandrasekaran 1986). - abstraction de donnes : IDABLE (Sticklen 1987). - matching d'hypothses : HYPER (Johnson & Josephson 86). - abduction ou de l'assemblage d'hypothses : PEIRCE (Punch & al. 1986). - raisonnement bas sur un modle de fonctionnement : FR (Sticklen & Chandrasekaran 1989). Par rapport KADS, cette bote outils offre l'avantage de proposer un moyen direct d'implmentation (il s'agit d'outils effectivement implments). Mais cette approche ne fournit pas une mthode explicite de conception, n'est pas proprement parler un outil d'aide automatique l'acquisition des connaissances. Rien n'est explicit sur la manire de slectionner une ou plusieurs tches gnriques pour un problme donn (David 1988). (iii) RIME RIME (Soloway & al. 1987, Bachant 1988) apparat comme une mthodologie de dveloppement de systmes base de connaissances. En fait, initialement RIME a t conu pour aider l'volution et la maintenance du systme R1 (appel galement XCON) de Digital Equipment (RIME est l'acronyme de R1 Implicit Made Explicit). Oprationnel depuis le dbut des annes 80, R1 voit sa base de connaissances en constante volution. Le taux de modification des rgles est de l'ordre de 40% 50% par an. Cette volution n'est pas toujours facile raliser. Il faut parfois inclure de nouvelles tches dans le systme. Les connaissances de contrle tant largement noyes dans les prmisses des diffrentes rgles, il est parfois ncessaire de restructurer une grande

31

partie de la base de connaissances, ce que seuls des programmeurs matrisant bien R1 arrivent mener bien (Bachant & McDermott 1984). Indiquons enfin les difficults dues aux incohrences entre les diffrents programmeurs et les diffrents styles de programmation. Le but de la mthodologie RIME est donc d'aider les ingnieurs de la connaissance faire voluer le systme en leur proposant des primitives, la fois de bas niveau (techniques de programmation, d'organisation et numrotage des rgles), et de haut niveau (stratgies et contrle). RIME va jouer en fait un rle d'interface entre un niveau conceptuel adapt aux besoins des gestionnaires de la base de connaissances et le niveau de l'implmentation du systme. Cet interface consiste en une sorte d'interprtation ou de traduction des concepts de bas niveau selon une typologie compose des quatre niveaux suivants : contrle (slection des problem solving methods) focalisation du processus (focus of attention) structure de reprsentation conventions de programmation.

Pour chaque niveau, une mthodologie adapte et des points de repres ont t dfinis. Le niveau de contrle correspond l'identification des Problem-Solving Methods. RIME connait actuellement 32 mthodes. C'est particulirement ce niveau que RIME prend tout son sens (expliciter l'implicite du contrle de R1/XCON). En 1988 a commenc une rcriture de R1/XCON avec RIME et les premiers rsultats semblent positifs, en particulier du point de vue de la maintenance et des capacits d'volution du systme. Bien qu'initialement dvelopp pour R1, RIME a une porte plus gnrale, comparable au modle d'expertise de KADS. De fait, il a t appliqu d'autres domaines, d'autres systmes. Mais surtout, il est le point de dpart de travaux en cours qui visent dvelopper des outils

32

automatiques d'aide l'acquisition des connaissances incluant la partie slection/construction du modle et la partie instanciation. VI. Conclusions Nous avons montr dans cet article comment, en considrant le processus d'acquisition des connaissances comme un processus de construction de modles, de nombreux travaux convergent aujourd'hui pour proposer une typologie et des primitives de modlisation adaptes. A partir de l, des outils d'aide l'acquisition des connaissances et des mthodologies sont dveloppes qui vont se rpartir selon trois catgories : L'aide aux interviews d'experts (techniques de conduite d'entretiens et de verbalisation). Ces aspects n'ont pratiquement pas t voqus dans le prsent article. Nous avons juste soulign, que pour indispensables qu'elles soient, ces techniques ne peuvent prendre leur sens que si des cadres conceptuels sont proposs pour organiser et modliser les connaissances. L'aide la construction du modle conceptuel, par abstraction ( partir des verbalisation d'experts ou des recueils de connaissances) et par slection et raffinement de modles gnriques (RIME, KADS, Generic Toolset). Cette partie est de loin la moins matrise et fait l'objet de nombreuses recherches : tablissement de bibliothques de tches et de mthodes, guide pour identifier et slectionner les mthodes adaptes, etc. L'aide l'instanciation de modles (c'est--dire au remplissage de ceux-ci par les connaissances du domaine).

Les futurs systmes d'aide l'acquisition des connaissances devront essayer de proposer une intgration harmonieuse de ces diffrentes tapes : verbalisations d'experts, constitution du modle conceptuel,

33

slection des outils permettant de remplir la base de connaissances, d'instancier le modle. Nous avons indiqu un autre aspect qu'il importe de souligner nouveau. Le but d'un concepteur de systme bases de connaissances est de construire un artefact et non pas de simuler ou reproduire le raisonnement rel d'un expert. Ainsi, le modle conceptuel dont nous avons parl tout au long de l'article et que le concepteur du systme se doit d'laborer, n'est pas a priori un modle rellement prexistant dans le cerveau humain (ce serait une vision trs simpliste et rductrice de l'intelligence humaine). Ce modle est une construction commune de l'expert et du cogniticien visant fournir un langage d'expression des connaissances relativement naturel aux yeux de l'expert et performant aux yeux du cogniticien. La validation et la maintenance de base de connaissances ont galement t abordes par un certain nombre de travaux. Il est en effet plus simple de retrouver ce qui a conduit le systme expert un rsultat jug erron lorsque le rle jou par chacune des connaissances est clairement identifi au sein des diffrentes stratgies de rsolution de problmes. Mais l'acquisition des connaissances n'est pas le seul attrait de cette approche. On peut galement observer des retombes sur la qualit des systmes conus. Ainsi, par exemple, un certain nombre de travaux se sont focaliss sur les capacits explicatives de systmes construits sur une reprsentation explicite de ce que fait le systme les tches raliser et de comment il le fait au travers des mthodes de rsolution de problmes et des connaissances du domaine (voir par exemple Hasling & al. 1984, Marcus 1988, Chandrasekaran & al. 1989, David & Krivine 1990. Remerciements

34

Nous tenons remercier ici Nathalie Aussenac, Isabelle Delouis, Marc Linster, Chantal Massip et Philippe Mazas pour leur relecture et leurs commentaires sur une premire version de cet article.

Jean-Paul KRIVINE
EDF - Direction des Etudes et Recherches 1, avenue du Gnral de Gaulle 92140 CLAMART

Jean-Marc DAVID
RENAULT Service Systmes Experts 860 Quai Stalingrad 92109 BOULOGNE-BILLANCOURT

Article reu en septembre 1990 Version rvise en mars 1991 Rfrences

Aussenac (1989) Nathalie Aussenac. Conception d'une mthodologie et d'un outil d'acquisition de connaissances expertes, Thse de l'universit Paul Sabatier de Toulouse, octobre 1989. Bachant, McDermott (1984) Judith Bachant et John McDermott. R1 revisited : Four years in the trenches, The AI Magazine 5(3), pp. 21-32, 1984. Bachant (1988) Judith Bachant. RIME : Preliminary Work Toward a KnowledgeAcquisition Tool Automating Knowledge Acquisition for Expert Systems, dit par Sandra Marcus, Kluwer Academic Publishers, 1988. Booch (1986) Grady Booch. Object-Oriented Development, IEEE Transaction on Software engineering, 12(2), pp. 211-221, fvrier 1986. Boose, Nagai (1987) John H. Boose et Arthur T. Nagai. Knowledge Acquisition Research : A summary of the AAAI Knowledge Acquisition for Knowledge-Based Systems Workshop, Cognitive Engineering in the Design of Human-Computer Interaction and Expert Systems, dit par G. Salvendy, Elsevier Science Publisher, 1987.

35

Breuker, Wielenga (1985) Joost Breuker et Bob Wielenga KADS : Structured Knowledge Acquisition for Expert Systems, Actes des 5mes journes internationales Les systmes experts et leurs applications, Avignon, France 1985, Breuker, Wielenga (1989) Joost Breuker et Bob Wielenga Models of Expertise in Knowledge Acquisition, Topics in Expert System Design : methodologies and tools. Guida & Tasso Eds, North Holland Publishing Company 1989. Bronstown & al (1985) Lee Brownston, Robert Farell, Elaine Kant et Nancy Martin. Programming Expert Systems in OPS5, Addison-Wesley Publishing, 1985. Brown, Chandrasekaran (1986) D. Brown et B. Chandrasekaran. Knowledge and control for a mechanical design expert system, IEEE-Computer, 19(7), Juillet 1986. Bylander, Mittal (1986) T. Bylander et S. Mittal. CSRL: A Language for Classificatory Problem Solving and Uncertainty Handling, The AI Magazine 7(3), pp. 66-77, 1986. Chandrasekaran (1983) B. Chandrasekaran. Towards a taxinomy of problem solving types, The AI Magazine 4(1), pp. 9-17, 1983. Chandrasekaran (1987) B. Chandrasekaran. Towards a Functional Architecture for Intelligence Based on Generic Information Processing Tasks, Tenth International Joint Conference on Artificial Intelligence (IJCAI-87), pp. 1183-1192, Milan, Italie, Aot 1987. Chandrasekaran & al (1989) B. Chandrasekaran, M.C. Tanner et J.R Josephson. Explaining Control Strategies in Problem Solving, IEEE-Expert, Printemps 1989. Charlet (1989) Jean Charlet. LEZARD : Acquisition des Connaissances et Gestion de l'Incertitude dans un Systme Expert de Seconde Gnration, Thse d'universit, Paris 1989. Clancey (1985) W.J. Clancey. Heuristic Classification, Artificial Intelligence 27(3), pp. 289-350, 1985. Clancey (1986) W.J. Clancey. From GUIDON to NEOMYCIN and HERACLES in Twenty Short Lessons : ORN Final Report 1979-1985, The AI Magazine, Aot 1986. Clancey (1989) William J. Clancey. Viewing Knowledge Bases as Qualitative Models, IEEE-Expert, 1989. David (1988) Jean-Marc David. Functional Architectures and the Generic Task Approach, The Knowledge Engineering Review, Vol. 3, numro 3, 1988. David, Krivine (1988) Jean-Marc David et Jean-Paul Krivine. Acquisition de Connaissances Expertes Partir de Situations Types, Actes des 8mes journes internationales Les systmes experts et leurs applications, Avignon, France , Mai 1988. David, Krivine (1989) Jean-Marc David et Jean-Paul Krivine. Designing KnowledgeBased Systems within Functional Architecture : the DIVA Experiment, Fifth IEEE Conference on Artificial Intelligence Applications (CAIA), Miami, Mars 1989.

36

David & al. (1989) Jean-Marc David, Jean-Paul Krivine et Reid Simmons. Prface des actes de la confrence sur les Systmes Experts de Seconde Gnration, Actes des 9mes journes internationales Les systmes experts et leurs applications, Avignon, France, 1989. David, Krivine (1990) Jean-Marc David et Jean-Paul Krivine. Explaining Reasoning from Knowledge Level Models, European Conference on Artificial Intelligence (ECAI-90), 1990. Davis, Lenat (1982) Randall Davis et Douglas B. Lenat. Knowledge Based Systems in Artificial Intelligence, New York, McGraw Hill, 1982. Eshelman (1988) Larry Eshelman. MOLE : A Knowledge-Acquisition Tool for Cover-and-Differentiate Systems, Automating Knowledge Acquisition for Expert Systems, dit par Sandra Marcus, Kluwer Academic Publishers, 1988. Farenny (1987) Henri Farreny. Les systmes experts, principes et exemples, Cepadues Editions, 1987. Hasling & al (1984) D.W. Hasling, W.J. Clancey et G. Rennels. Strategic explanations for a diagnostic consultation system, Int. Journal of Man-Machine Studies 20, 1984. Hayes-Roth & al (1983) Frederick Hayes-Roth, Donald A. Waterman et Douglas B. Lenat. An Overview of Expert Systems, Building Expert Systems, dit par Frederick Hayes-Roth, Donald A. Waterman et Douglas B. Lenat, Technoledge Series in Knowledge Engineering, 1983. Hickman & al (1989) Frank R. Hickman, Jonathan L. Killin, Lise Land, Tim Mulhall, David Porter et Robert M. Taylor. Analysis for Knowledge-Based Systems, a practical guide to the KADS methodology, Ellis Horwood, 1989. Hoffman (1989) Robert R. Hoffman. A survey of methods for extracting the knowledge of experts, Sigart Newsletter, Special Issue on Knowledge Acquisition (108), Avril 1989. Johnson, Josephson (1986) T. R. Johnson et J.R. Josephson. HYPER: The Hypothesis Matcher Tool, Rapport interne Ohio State University. Karbach & al (1990) Werner Karbarch, Marc Linster et Angi Voss. Models of Problem-Solving : One label - One idea ?, Fourth European Knowledge Acquisition for Knowledge-Based Systems Workshop (EKAW-90), Amsterdam, Pays-Bas, Juin 1990. Laird & al. (1987) John E. Laird, Allen Newel et Paul S. Rosenbloom. SOAR : An Architecture for General Intelligence, Artificial Intelligence 33, pp. 1-64, 1987. Marcus (1988) Sandra Marcus. SALT : A Knowledge-Acquisition Tool for Proposeand-Revise Systems, Automating Knowledge Acquisition for Expert Systems, dit par Sandra Marcus, Kluwer Academic Publishers, 1988. Marcus & al (1988) Sandra Marcus, J. Stout et John McDermott. VT : An expert elevator configurer that uses knowledge backtracking, The AI Magazine 9(1), pp. 95-112, 1988.

37

McDermott (1988) John McDermott. Preliminary Steps Toward a Taxinomy of Problem-Solving Methods, Automating Knowledge Acquisition for Expert Systems, dit par Sandra Marcus, Kluwer Academic Publishers, 1988. Meyer (1988) Bertrand Meyer. Object-oriented Software Construction, Prentice Hall, International Series in Computer Science, 1988. Musen & al (1987) Mark A. Musen, L. M. Fagan, D.M. Combs, E.H. Shortliffe. Use of a domain-model to drive an interactive knowledge-editing tool, International Journal of Man-Machine Studies 26(1987), pp. 105-121. Newell (1981) A. Newell. The Knowledge Level, The AI Magazine 2(2), pp. 1-20, 1981. Newell, Simon (1972) A. Newell et H. Simon. Human Problem Solving, Englewood Cliffs, N.J., Prentice-Hall, 1972. Nii (1989) H. Penny Nii. Blackboard Systems, The Handbook of Artificial Intelligence, Volume IV, chapitre XVI. Barr, Cohen et Feigenbaum eds, 1989. Norman (1983) Donald H. Norman. Some Observations on Mental Models, Dans Mental Models, New Jersey : Hillsdale, Gentner D., 1983. Pierret-Goldbreich, Delouis (1990) Christine Pierret-Goldbreich et Isabelle Delouis. TASK : Task Architecture for the Structuration of Knowledge, Confrence spcialise sur les systmes experts de deuxime gnration, Actes des 10mes journes internationales Les systmes experts et leurs applications, Avignon, France 1990. Porcheron (1990) Marc Porcheron. Utilisation de mta-connaissances pour la compilation de rgles de production, Thse de l'universit Pierre et Marie Curie, Paris, 1990. Punch & al. (1990) W. F. Punch, M.C. Tanner et J.R. Josephson. Design Considerations for PEIRCE: A High Level Language for Hypothesis Assembly, Expert Systems in Government, McLean Virginie USA, 1986. Punch, Chandrasekaran (1990) William F. Punch III et B. Chandrasekaran. An Investigation of the Roles of Problem-Solving Methods in Diagnosis, Confrence spcialise sur les systmes experts de deuxime gnration, Actes des 10mes journes internationales Les systmes experts et leurs applications, Avignon, France 1990. Reynaud (1989) Chantal Reynaud. ADELE : un outil d'aide l'acquisition des connaissances bas sur des justifications, Thse de l'universit Paris-XI, Orsay 1989. Ricard & al (1989) Benot Ricard, Roger Chevalier, Jean-Charles Bonnet et JeanPierre Tiarri. Testing Diva, A Turbine-Generator Diagnosis Expert System, International Symposium AIPAC'89, Advanced Information Processing in Automatic Control, Nancy France, 1989. Soloway & al. (1987) Elliot Soloway, Judy Bachant et Keith Jensen. Assessing the Maintainability of XCON-in-RIME : Coping with the Problems of a VERY Large Rule-Base, Confrence AAAI-87, 1987.

38

Steels (1990) Luc Steels. Components of Expertise, The AI Magazine 11(2), 1990. Sticklen (1987) Jon Sticklen. MDX2 : An Integrated Medical Diagnostic System, Ph.D. thesis. Ohio State University, 1987. Sticklen (1989) Jon Sticklen. Distributed abduction in MDX2, Artificial Intelligence in Scientific Computation : towards Second Generation Systems. Editeurs : Hubert, Kulikowski, David et Krivine. J.C. Baltzer Publishing, 1989. Sticklen, Chandrasekaran (1989) Jon Sticklen et B. Chandrasekaran. Integrating Classification-Based Compiled Level Reasoning with Function-Based Deep Level Reasoning, Applied Artificial Intelligence. Numro spcial, 1989. Tong, Tueni (1990) Xuejun Tong et Michel Tueni. CARMEN: A Platform for Building Second Generation Expert Systems, Confrence spcialise sur les systmes experts de deuxime gnration, Actes des 10mes journes internationales Les systmes experts et leurs applications, Avignon, France 1990. Vanwelkenhuysen, Rademakers (1990) Johan Vanwelkenhuysen et Philip Rademakers. Mapping a Knowledge Level Analysis onto a Computational Framework, European Conference on Artificial Intelligence (ECAI-90), 1990. Vogel (1988) Claude Vogel. Gnie Cognitif, Paris, Masson, 1988. Wielinga, Breuker (1986) B.J. Wielinga et J.A. Breuker. Models of Expertise, European Conference of Artificial Intelligence (ECAI-86), 1986.