[Next] [Previous] [Up] [Top]

chapitre 5 La modélisation d'une décision administrative par le génie cognitif

5-2.1 Le langage Mycin

Il existe plusieurs variantes du langage Mycin. On constate notamment de grandes différences en ce qui concerne les interfaces du développeur et de l'utilisateur. Notre logiciel SMYC ("Simulation-Mycin") a été développé à partir de Mini-Mycin qui a été utilisé comme outil d'enseignement pour un cours d'intelligence artificielle au M.I.T. au début des années 80. Il s'agit ici d'un logiciel assez rudimentaire par rapport aux implantations commerciales courantes, toutefois grâce à la disponibilité du code source, on peut facilement l'adapter à des besoins spécifiques. Ainsi nous avons, par exemple, rajouté une forme de chaînage avant utile pour la modélisation de décisions juridiques ainsi que des outils pour analyser un modèle. En tout, nous avons à peu près doublé le code originalement reçu.

Le langage "Mycin" est assez facile à apprendre au plan de la syntaxe. Ceci est encore plus vrai en ce qui concerne les système commerciaux de la dernière génération; la logique reste la même, mais l'interface et le langage de codage utilisé simplifient beaucoup de choses. Toutefois, il faut passer à travers une phase d'apprentissage et le premier système n'est pas facile à coder. La difficulté réside dans la sémantique d'une base de règles. Mais une fois cette étape franchie, les systèmes suivants seront construits avec beaucoup plus de facilité.

Un système de type Mycin vise à produire un diagnostic au sens large du terme. Diagnostiquer signifie essentiellement classer. Décider, dans le contexte d'un tel système, signifie donc analyser les attributs d'un cas, et ensuite le décrire avec un vocabulaire précis à la suite d'un processus de collection de données et de raisonnement. Un "cas" est décrit (et donc classé) par un nombre variable d'attributs, appelés paramètres dans Mycin. Chaque attribut peut avoir une ou plusieurs valeurs. Ces valeurs seront déterminées à l'aide de règles probabilistes. Les valeurs sont regroupées dans des contextes. Chaque cas est donc décrit par un certains nombre d'attributs qui peuvent être regroupés en plusieurs contextes. Les contextes servent à regrouper des paramètres selon certains critères logiques. Les paramètres et les contextes dans un modèle sont définis comme types abstraits. Ainsi, il est possible d'utiliser plusieurs instances d'un contexte pour décrire un cas. Pour chaque contexte, on définit un ensemble de paramètres et un paquet de règles qui permettent de déterminer les valeurs d'un certain nombre de paramètres représentant une solution.

Les contextes

Un système est composé de contextes organisés dans une structure arborescente. Au niveau le plus élevé dans cette hiérarchie, on peut faire figurer toutes les connaissances générales qui dépendent de celles des contextes inférieurs. Les connaissances comprennent des paramètres à déterminer pendant le processus d'inférence, ainsi que les règles nécessaires. Les connaissances spécifiques à un certain contexte seront donc insérées plus bas dans l'arbre, c'est-à-dire au niveau du contexte en question. Les contextes ont une fonction structurante dans plusieurs sens:

  1. en organisant les données d'un cas, les contextes permettent de structurer un problème. Dans certains systèmes, ils représentent les parties physiques d'un objet, dans d'autres il s'agit d'éléments logiques.

  2. d'une façon plus restrictive, on peut utiliser des contextes pour structurer les composantes d'un cas.

  3. les contextes permettent de réduire et de diriger la recherche d'une solution. Les règles d'inférence ne recherchent de l'information que dans leur propre contexte ou dans des contextes inférieurs.

On voit une partie de la définition d'un arbre de contexte du système M-LEX dans la figure 5-3 "Définition d'un arbre de contexte" [p. 174]

. On voit implicitement que le contexte "top" possède trois contextes inférieurs: "acquisition", "person" et "motive". Dans la base de données des contextes, on entre de l'information pour chaque contexte. Avec des expressions du type

(belongs-to <contexte fille> <contexte parent>),
on définit les relations de hiérarchie entre les contextes. Dans SMYC, nous utilisons deux autres attributs pour caractériser les contextes. Pour empêcher que le système tente d'instancier les contextes en plusieurs exemplaires, on peut le définir comme "single", et pour empêcher que le système ne demande s'il faut instancier un contexte, on peut le déclarer "inferred". Normalement, le système Mycin était conçu pour demander à l'utilisateur s'il voulait créer un contexte lorsqu'il rencontrait le premier paramètre dont il fallait déterminer une valeur. Ceci n'a de sens que s'il peut exister plusieurs instanciations d'un même contexte, nécessaire dans le système original de Mycin, mais pas toujours utile dans notre travail.

Les paramètres

Les attributs qui permettent la description d'un cas sont appelés paramètres. Les paramètres forment le squelette à partir duquel on définit un cas dans un espace de solutions. Cet espace est défini et limité par l'ensemble des valeurs que peuvent prendre ces paramètres. Ainsi dans Mycin, il faut distinguer entre la définition d'un paramètre et un attribut spécifique (un paramètre instancié). Le modéliseur doit indiquer pour chaque paramètre quel type d'information il représente, et quelle est son utilisation durant une "consultation" du système. Voici le type d'information qu'il faut fournir:

  1. le type d'information: "oui/non", valeur unique, ou valeurs multiples.
    Un paramètre "oui/non" (YesNo dans Mycin) définit un prédicat binaire qui peut être juste ou faux. Par exemple, une personne est "étrangère" ou "non étrangère". Un paramètre à valeur unique (Single en Mycin) peut prendre une valeur parmi une liste de valeurs mutuellement exclusives. Toutefois, pendant le processus d'analyse, le système peut attribuer des probabilités à plusieurs valeurs simultanément et choisir la plus probable (une fois l'évaluation d'un paramètre terminée). Il existe aussi des paramètres à valeurs multiples. Dans ce cas le système tient compte de toutes les valeurs dépassant un certain seuil de probabilité

  2. les valeurs possibles: la réponse que peut fournir l'utilisateur d'un système expert.
    Il existe quatre possibilités: (1) un nombre, (2) une liste de valeurs possibles, (3) une réponse "libre", et (4) "oui" ou "non" pour les paramètres YesNo. Les réponses libres sont peu utilisées, car difficiles à traiter dans la logique de Mycin.

  3. l'utilisation pendant le processus d'inférence: est-ce que les valeurs sont demandées à l'utilisateur ou inférées par le moteur d'inférence?
    (1) Les "LabType" sont fournis par l'utilisateur. (2) Les paramètres "Inferred" et "normal" sont d'abord "à la charge" du moteur. S'il n'arrive pas à trouver une réponse, elle sera demandée à l'utilisateur. (3) La dernière catégorie que nous allons mentionner ici sont les "Mainprops", les paramètres principaux qui caractérisent un contexte et dont les valeurs sont demandées automatiquement à l'utilisateur lors de la première création d'un contexte.

  4. un "prompt" pour l'utilisateur qui sera affiché lorsque le système demande à l'utilisateur de rentrer une valeur.

  5. finalement chaque paramètre doit avoir un nom unique et il doit être attaché à un contexte spécifique.

Dans notre système SMYC

, nous utilisons une syntaxe simple en forme de liste pour définir un paramètre. On donne une définition plus formelle de cette syntaxe*1 dans la figure 5-4.

Les règles, un premier aperçu

Une règle Mycin comprend normalement une prémisse contenant un ensemble de clauses et une conclusion simple. Ces clauses sont des conjonctions, elles doivent être toutes "vraies" afin de "prouver" la conclusion. Une clause contient soit des "fonctions Mycin" soit des disjonctions de clauses (une chaîne de clauses dont une doit être vraie). Examinons un exemple en langage "naturel":

IF a person is foreign
and if a person acquires real-estate
or a company dealing with real-estate

THEN the person is subject to the authorization regime

Ce type de règle est encodé de façon très différente dans les différentes coquilles Mycin. Certaines offrent un langage de description très proche de l'anglais. SMYC est moins élaboré, il faut traduire cette règle dans une syntaxe plus formelle que nous allons introduire à l'aide de l'exemple

montré dans la figure 5-5. Les clauses de la prémisse se trouve avant la flèche "==>" et la conclusion se trouve après. Chaque clause de prémisse simple est une liste de trois objets: Le premier élément est une fonction Mycin qui définit la relation entre le paramètre (2ème élément) et la valeur (3ème élément). Par exemple, "(defis person foreign)" veut dire qu'il faut avoir une certitude complète (la fonction "defis") que le paramètre "person" possède la valeur "foreign". Nous allons donner des détails dans les pages suivantes. Finalement, les paramètres doivent appartenir à un même contexte ou alors à des "parents" ou des "enfants" d'un contexte.

Le raisonnement probabiliste

Le mécanisme d'inférence de Mycin utilise un raisonnement probabiliste. Le modéliseur peut attacher un facteur de certitude à une conclusion (et par conséquent à une règle). Examinons la conclusion de la règle dans la figure 5-5. La clause "submitted-to-regime yes 1.0)" signifie que le paramètre "submitted-to-regime" obtient la valeur "yes" avec une certitude absolue "1.0" lorsque la prémisse est vraie avec une certitude absolue. "1.0" est donc le facteur de certitude de la règle.

La force de la conclusion dépend en outre de la certitude attribuée aux clauses de la prémisse. Lorsque le moteur d'inférence interroge un utilisateur (par le biais des paramètres du type "lab"), ce dernier peut assigner des probabilités à ses réponses en donnant des facteurs de certitude à une valeur.

Notez les fonctions Mycin "same" dans la figure 5-6. Il s'agit d'une fonction qui retourne des valeurs probabilistes associées aux paramètres, probabilités qui seront utilisées pour calculer la force de la conclusion. Ainsi dans cet exemple, si l'utilisateur répond comme dans l'exemple suivant

> Please enter residence/nationality:
			(foreign 0.5)
cela veut dire qu'il attache une probabilité (facteur de certitute) de 50% à sa réponse. En conséquence, la conclusion ne dépassera pas en tout cas ce seuil. Les facteurs de certitude varient entre -1 et +1 couvrant toute la gamme entre la certitude absolue négative (-1), l'incertitude totale (0) et la certitude absolue (1).

Pour l'utilisateur d'un système écrit avec Mycin, il est également possible de rentrer deux valeurs alternatives ayant des probabilités correspondant à leur plausibilité. Dans le système M-Lex, nous n'utilisons pas de facteur de certitude dans les conclusions étant donné que les règles juridiques sont censées êtres claires. Par contre, en ce qui concerne la qualification de faits (réels) en termes juridiques, l'utilisation de probabilités est plus logique.

Les "fonctions Mycin"

Nous avons déjà rencontré les fonctions "same" et "defis". Le principe d'une fonction Mycin est en gros le suivant: elle indique avec quelle certitude un paramètre possède une (ou plusieurs) valeur(s).

Les fonctions dites "Mycin func1" testent le degré de connaissance d'un paramètre. Elles sont utiles pour diriger le processus d'inférence dans une direction ou pour réévaluer un paramètre. Supposons qu'un paramètre "nationality" soit connu avec un facteur de certitude CF=1. La fonction "(known nationality") retournera 1.0, la fonction "(definite nationality)" retournera "T" (signifiant vrai), les deux autres fonctions "notknown" et "notdefinite" retourneront NIL (signifiant faux). Dans Mycin, les seuils de certitude de 0.2 et de 0.8 sont considérés comme importants. Tout facteur de certitude (CF) au-dessus de 0.2 signifie "connu d'une certaine façon" et tout CF au-dessus de 0.8 signifie "bien connu" (angl. "strongly suggestive"). Les paramètres "Yes/No" sont traités un peu différemment, car leur CF peut varier entre -1 et +1. "(yes -0.2)" signifie "(no 0.2), etc.

Les fonctions "func2" testent si un paramètre possède une ou plusieurs valeur(s) avec un certain seuil de certitude. On retrouve les fonctions les plus souvent utilisées dans la figure 5-7. "Same" nous donne le CF pour une valeur donnée à condition qu'il dépasse le seuil critique de 0.2. L'emploi de "defis" se justifie surtout dans les situations où une conclusion doit être juste ou fausse, à utiliser par exemple dans des chaînes de raisonnement juridique bien codifiées par la loi. Nous utilisons encore assez souvent la fonction "notsame" qui teste pour l'absence d'une valeur.

Dans SMYC, nous disposons finalement des fonctions "func3" utiles pour manipuler des nombres (et non pas des CF). Nous reviendrons plus tard sur leur usage.

Fonctionnement et syntaxe d'une règle "SMYC"

Retournons à la règle "demo-2" dans la figure 5-6 "Une règle SMYC ayant des clauses probabilistes" [p. 177]. Elle possède deux clauses formant une conjonction logique:

		(same person foreign)
  		($or 	(same type-of-acquisition direct)
			(same type-of-acquisition real-estate-company))
Si la première clause et au moins une des deux disjonctions de la clause ($or ...) possèdent un CF > 0.2, la règle "marche". Supposons que "(same person foreign)" retourne un CF de 1, "(type-of-acquisition direct)" un CF de 0.8 et "(type-of-acquisition real-estate-company)" un CF de 0. Dans ce cas la conclusion

		(submitted-to-regime yes 1.0)
est valable, mais uniquement avec un CF de 0.8. Le CF de la conclusion est toujours calculé en prenant le CF le plus faible dans la prémisse (0.8 dans notre cas) et en le multipliant avec le CF de la conclusion donnée d'avance (1.0 dans ce cas). Notons encore - ce qui est évident - que l'on prend toujours la clause la plus "forte" dans une disjonction.

Nous présentons la définition formelle d'une règle

dans la figure 5-8. Elle montre que le nombre de clauses dans une prémisse est illimité, mais qu'il n'est pas possible d'avoir des conjonctions "et" à l'intérieur d'un "ou". Il suffit d'écrire deux ou plusieurs règles pour contourner cette dernière limitation. Les conclusions doivent contenir au moins une clause, à savoir celle qui déclenche les règles. D'autres clauses peuvent être rajoutées notamment pour "écrire" des effets secondaires dans la base de données. Notons également qu'il est possible d'avoir des règles sans prémisses (des conclusions toujours vraies) ou des règles sans conclusion. Nous allons discuter ces extensions au fur et à mesure de nos besoins.

Par rapport à un moteur Mycin standard, nous avons rajouté une extension importante: les assertions. Une assertion est une clause qui déclenchera l'évaluation d'une règle dès que le fait en question existera dans la base de données.

Le "moteur" Mycin et l'architecture de SMYC

Sans entrer dans les détails nous présentons brièvement le fonctionnement du moteur d'inférence de Mycin. Au coeur du système se trouvent deux procédures bien décrites dans la littérature (cf. Shortcliffe 76 ou Buchanan 84): MONITOR et FINDOUT.

La procédure "Monitor" est chargée de l'évaluation d'une règle. Elle évalue pas à pas les clauses de la prémisse d'une règle afin de déterminer les clauses de la conclusion. Lorsque les valeurs d'un paramètre dans une condition sont inconnues, elle fait appel à la procédure "Findout" qui a la charge de "tracer" les paramètres. La procédure "Monitor" s'arrête lorsqu'une clause de la prémisse est fausse. Après cette évaluation séquentielle des clauses et à condition que toutes les clauses retournent "vrai" ou encore un CF, elle écrit les faits qui correspondent aux clauses de la conclusion dans la base de données. Finalement "Monitor" calcule le CF de chacune des ces nouvelles assertions en multipliant le CF de chaque conclusion avec le CF le plus bas de la prémisse.

La procédure "Findout" évalue la valeur d'un paramètre. Si le paramètre est du type "LabType", elle demande à l'utilisateur une valeur. Sinon, elle procède à une sorte de chaînage arrière. Elle prend toutes les règles qui peuvent potentiellement déterminer la valeur de ce paramètre, c'est-à-dire les règles où ce paramètre apparaît dans la conclusion. Ensuite la procédure "Monitor" est appliquée à chacune de ces règles. Une fois que toutes les règles ont été consultées, Mycin examine les valeurs retrouvées pour le paramètre en question; (il faut se souvenir que Mycin autorise l'existence de valeurs alternatives qui sont "en concurrence"). Si la somme de tous les CF excède 1, les CF pour chaque valeur seront normalisés: on les diminue pour que la somme des CF soit égale à 1. Mentionnons deux autres variantes de cette procédure. Dans SMYC, "Findout" abandonne sa recherche lorsqu'elle trouve une valeur sûre (CF = 1). En outre, lorsque "Findout" ne peut pas déterminer les valeurs d'un paramètre, la procédure demande à l'utilisateur d'indiquer une valeur. Ce type de chaînage arrière est très différent de celui de Prolog: la procédure "Findout" n'essaie pas seulement de déterminer si tel paramètre possède telle valeur, mais elle applique toutes les règles dans lesquelles le paramètre (indépendamment de la valeur) se trouve dans une conclusion. En outre, rappelons que l'évidence pour une valeur ne constitue pas une contre-évidence pour d'autres valeurs. Cette ambiguïté est un des atouts de ce type de moteur. Il est possible d'instruire le système pour demander une vérification de la valeur d'un paramètre dont le CF < 1. Les deux algorithmes

sont schématisés dans la figure 5-9.

Une note sur SMYC

L'acronyme "SMYC" fait allusion à plusieurs choses: "Simulation Mycin", "Small Mycin", "Schneider's Mycin" et fait allusion au minimum qu'il faut avoir (le salaire minimal "Smic" en France). Nous avons apporté quelques modifications importantes à la coquille originale "Mini-Mycin". SMYC inclut notamment:

Ce système a été crée en 1984. Depuis il existe certains systèmes commerciaux dont l'utilisation est plus facile. Toutefois, l'avantage de SMYC est son ouverture, il assez facile de rajouter certaines fonctionnalités et une interface graphique puissante pourrait être rajoutée en quelques mois de travail. Malgré les développements de la technologie des systèmes experts cette dernière décennie, la logique Mycin reste toujours valable: elle marie une simplicité de représentation avec une logique d'inférence facile à comprendre. Un politologue sachant utiliser des logiciels comme "Excel" ou SPSS" est en mesure d'apprendre un logiciel de la famille "Mycin". Ce type de coquille expert reste toujours un très bon outil pour modéliser des situations de diagnostic où l'on peut confronter un "cas" à un système de décision/classification en forme de règles comme nous allons le voir dans les sections suivantes.

Les contextes
Les paramètres
Les règles, un premier aperçu
Le raisonnement probabiliste
Les "fonctions Mycin"
Fonctionnement et syntaxe d'une règle "SMYC"
Le "moteur" Mycin et l'architecture de SMYC
Une note sur SMYC
THESE présentée par Daniel Schneider - 19 OCT 94

Generated with WebMaker