|
|
Case Based Reasoning : Cas et Base de Cas |
|
| LAURENT Jean-Marc - Méthode OCSIMA | Audit - Conseil - Développement - Formation | |
|
|
|
II.1 Qu'est ce qu'un cas ?Un cas est une représentation structurée d'une histoire (passée ou imaginée) composée de trois parties principales: les prémisses, le contexte et le développement avec sa conclusion. Cette histoire doit bien sûr être lisible et affichable par la machine. De plus elle doit paraître intéressante pour l'utilisateur: d'une part elle doit lui permette d'apprendre quelque chose et d'autre part elle doit lui être présentée sous un format et une écriture qu'il comprenne et apprécie. Le raisonnement basé sur les cas (RBC) est une technique de raisonnement utilisée principalement dans les domaines du contrôle de système (diagnostic/thérapie, surveillance, maintenance, ...), de la conception et de l'élaboration de plan. Les systèmes développés à partir de cette technique sont destinés à apporter une aide à l'utilisateur dans ces différents domaines. Ces systèmes permettent également de capitaliser l'expertise d'une entreprise . Ils mettent à la disposition de toute personne habilitée l'expertise accumulée par cette entreprise. Il faut noter également qu'un cas peut être la représentation d'une connaissance superficielle (par exemple le résultat d'une compilation d'autres connaissances) ou au contraire d'une connaissance profonde (il se peut par exemple que pour le domaine étudié ce soit le seul type de connaissance disponible: il n'existe aucun modèle mathématique, qualitatif, etc.). II.2 Que doit-il contenir ?La base de cas (BC) peut être considérée comme une bibliothèque dans laquelle il n'y aurait pas nécessairement de rangement ni de classement thématique ou autre. Les cas doivent donc inclure le moyen de les retrouver facilement. C'est la contrainte principale concernant la constitution d'un cas: il doit contenir des index. Plus généralement un cas doit être composé au minimum des trois parties suivantes :
Il se peut aussi que le problème représenté par ce cas n'ait jamais été résolu de manière satisfaisante: il faut alors l'indiquer en précisant les actions qui ont été entreprises et les résultats obtenus jusqu'alors. Puisque l'on accepte (et/ou que l'on est obligé d'accepter) qu'il n'y ait pas parfaite concordance entre le cas mémorisé et retrouvé par le système, et le problème courant à résoudre, il peut être nécessaire de modifier, d'adapter la solution, figurant dans le cas retrouvé à la situation courante. Cette adaptation peut être automatique lorsque l'on peut utiliser les techniques du raisonnement approximatif [KOS, 92] (ex.: utilisation d'inférences graduelles: plus .... plus ... [LAU, 90]) ou un ensemble de règles de production. Lorsque cette automaticité ne peut pas être atteinte, il est souhaitable d'inclure dans ce champ une aide pour guider l'utilisateur dans cette adaptation, gardant à l'esprit la complémentarité entre les capacités respectives de mémorisation de l'ordinateur et d'adaptation de l'être humain. Pour les systèmes automatiques ou non interactifs, il est possible de limiter la composition des cas à ces trois parties, les cas étant indexés par la première partie ou fonction à assumer. Pour les systèmes interactifs d'aide à la décision, il est préférable d'adjoindre une quatrième partie narrative: l'explication destinée à l'utilisateur. En effet la résolution de problème fondée sur le RBC n'inclut pas le déclenchement d'un enchaînement de règles de productions. La génération automatique d'une explication, par sélection intelligente des règles utilisées, est donc impossible. Cette explication, nécessaire si l'on veut préserver l'aspect formateur ou pédagogique, doit être incluse dans le cas. D'autre part cette explication devrait être adaptable à la demande de l'utilisateur ou à son niveau d'expérience, et pouvoir consister soit en un simple rappel théorique ou pratique, soit en une description précise, complète et détaillée. Contraintes sur le domaine et les indexL'histoire racontée par un cas décrit généralement la résolution d'un problème déjà rencontré. Pour que le système développé présente un intérêt, la première condition portant sur le domaine est que les problèmes, mis sous forme de cas et mémorisés, surviennent de nouveau. Il faut également que le domaine présente une continuité dans le temps et l'espace. En effet deux problèmes similaires (par exemple un ancien et un nouveau problème) doivent accepter pour solutions des solutions similaires. Ce sont les index qui doivent permettre une mesure fiable de la similitude entre cas. Ces index ne doivent ni être trop stricts (le "matching" ne sera que rarement obtenu) ni au contraire trop abstraits (ils représentent alors une contrainte de similitude trop lâche). Un exemple d'étude de constitution des casStrube & al [STR, 95] ont mené une étude intéressante permettant la compréhension de la composition des cas dans le domaine de la conception architecturale, étude résumée ci-après. Strube & al ont demandé à deux groupes d'architectes de concevoir un centre de conférences. Le premier groupe (practioner group), appartenant à un cabinet d'architectes, était constitué de deux architectes qui possédaient une expérience de plusieurs dizaines d'années dans la conception de maisons et de bâtiments, et d'un plus jeune architecte moins expérimenté. Le deuxième groupe (academic group) était constitué quant à lui de trois architectes universitaires dont la principale expérience était plus théorique que pratique, et orientée vers la conception assistée par ordinateurs. Par observation des étapes et des techniques étudiées par les deux groupes, Strube & al ont abouti au tableau de résultats suivants :
Dans ce tableau, examples signifie solutions d'autres personnes (ex. catalogues), cases sont des solutions imaginées antérieurement par les mêmes architectes, schemata sont des structures de cas général, qui représentent une connaissance abstraite et complexe, scripts sont des schemata représentant une connaissance de séquences d'actions et stratégies, rules sont des prescriptions abstraites et indépendantes du contexte, norms réfèrent aux lois, standards, ou prescriptions administratives, principles désignent des valeurs personnelles, des standards et des principes d'esthétisme, requirements sont les demandes figurant dans le cahier des charges, prior results sont des solutions d'étapes de travail précédentes. Leur conclusion est la suivante: "We may conclude that cases do not have the significance which CBR theory suggests. Compared to other kinds of input they are used rather infrequently and mostly in connection with schemata and norms. However, even a single case may be used extensively, and guide much of the design process." On peut tout de suite remarquer concernant cette conclusion que si les deux groupes avaient eu à leur disposition un système RBC, particulièrement le groupe d'académiciens, le nombre d'appels à ce type d'aide aurait été certainement beaucoup plus important. Mais on peut surtout déduire de ce tableau que, dans ce domaine de la conception, plus synthétique qu'analytique, certains cas doivent contenir des connaissances abstraites pour répondre aux utilisations de schemata, rules, norms et principles, et d'autres des propositions de startegies. II.3 Quelle doit être sa taille ?La troisième question évoquée à laquelle il est relativement aisé d'apporter une réponse concerne la taille que doit avoir un cas. Un cas doit représenter un sous problème auquel l'utilisateur est typiquement confronté. Par exemple dans le domaine de la conception de bâtiments, si le cas représente tout le bâtiment, sa réutilisabilité et son intérêt seront beaucoup plus faibles que si le bâtiment est décomposé en l'ensemble de ses parties et de ses fonctions. Une réponse pertinente à cette question proposée entre autres par Kolodner [KOL, 93] consiste à attribuer au cas la taille d'une leçon, concernant le domaine, telle que celle-ci soit aisée à enseigner et à apprendre. II.4 Comment Collecter un Cas ?Qu'est-ce qu'un bon cas ?En effet il faut commencer par déterminer ce que peut être un "bon cas" avant de chercher comment le collecter. Un bon cas est un cas qui satisfait aux deux conditions suivantes :
Ces conditions correspondent en fait aux activités de test habituelles du génie logiciel (remarque: c'est le premier parallélisme entre l'activité de recensement d'une base de cas et les activités du génie logiciel) :
Ces tests peuvent être effectués en faisant entrer par l'expert des symptômes simulés, en lui présentant les résultats, en lui demandant d'étudier les réactions d'un utilisateur non expert placé devant la même situation, et en lui demandant de certifier le cas, ou de le modifier. Comment le Collecter ?Un cas peut être obtenu par extraction et structuration de données déjà enregistrées sous une autre forme, et/ou le plus souvent par dialogue avec l'expert (les techniques d’interview sont rappelées au paragraphe suivant). Il peut être intéressant d’interviewer plusieurs experts, en même temps ou successivement, mais on risque de se retrouver face à des désaccords entre experts, désaccords concernant généralement une interprétation de symptômes ou de contexte, et désaccords qu'il faudra résoudre (ex.: utilisation des techniques de raisonnement approximatif pour tenter de remédier aux différences d'interprétation, nomination de l'expert "final", etc.). |
|
|
|
Dernière révision janvier 06 |
Plan du site OCSIMA |
Pour nous écrire, cliquez ici : |
Définition(s)
Case Based Reasoning
Recensement des Cas