Sommaire

Un système expert, c'est quoi ?

Architecture générale d'un système expert

Les règles

Le chaînage avant

Le chaînage arrière

Le chaînage mixte

Un exemple de transfert de connaissances

Mettre au point une base de connaissances

Bibliographie

En 1965, une équipe de l'université de Stanford travaille sur la résolution d'un problème pour lequel on ne connaît pas de solution algorithmique : il s'agit de trouver la correspondance entre le spectre de masse et la formule développée d'un corps chimique. Le premier système expert est né. L'idée fut d'introduire la connaissance des experts dans les ordinateurs en les rendant intelligents. Le concept de système expert inclut de plus l'idée selon laquelle cette connaissance des experts n'est pas noyée dans un algorithme, elle est explicite. L'expertise se traduit bien souvent par un ensemble de règles. déductives qui reflètent par leur enchaînement le raisonnement des experts eux-mêmes. Le programme va lire ces règles et établir un raisonnement en tentant de les appliquer, ce que nous appelerons les chaîner.

L'idée qui apparaît ensuite consiste à transférer l'expertise de l'homme à la machine.

Comment faire ? C'est très simple ! Il "suffit" d'aller voir un expert humain et de formaliser ce que nous appellerons l'ensemble des règles qu'il utilise dans son expertise. Une fois qu'un premier ensemble de règles est établi, il ne reste plus qu'à les appliquer, ce qui est censé simuler le raisonnement de l'expert humain.

Tout cela est très bien mais ne sommes-nous pas un peu présomptueux dans cette volonté d'automatiser le raisonnement humain ?

La démarche qui consiste à simuler ce dernier par un enchaînement de règles préstockées a paru à certains philosophes d'un simplisme bien naïf. C'est le raisonnement d'un débutant que vous simulez ! ont-ils dit. Dans la tête de l'expert humain chevronné, il y a des choses bien plus complexes et plus riches qui se passent qu'un simple enchaînement de règles, voyons !

Toutefois, face à ces attaques, les chercheurs en intelligence artificielle n'ont pas baissé les bras. Et ils ont eu raison car les systèmes experts, cela sert. A quoi ? D'abord ce sont des adjuvants à l'expert humain qui le déchargent des expertises simples et répétitives, et lui permettent de concentrer sa science rare sur les problèmes inédits et complexes. Cela sert aussi pour transmettre une expertise. Pour cela il est nécessaire d'atomiser celle-ci en un ensemble de règles logiques donc pédagogiquement transmissibles.

Ce que l'on retient de cette brève introduction, c'est d'abord la notion de règles appelées règles de production. Mais vous aurez aussi noté l'occurrence à plusieurs reprises de la notion de chaînage de règles. En effet tout n'est pas de recenser celles-ci et d'en faire une base (au cours d'une phase appelée de transfert de connaissance), il faut pouvoir ensuite mener des raisonnements, des inférences, sur cette base de règles. L'entité dans le système qui va mener ces raisonnements, est le MOTEUR D'INFERENCES.

Que va faire ce moteur ?

Il va chaîner les règles a-t-on dit à plusieurs reprises. Nous dirons qu'il va effectuer un CHAINAGE.

Il existe plusieurs types de chaînages, c'est-à-dire plusieurs types de raisonnements. Le plus immédiat est le chaînage avant qui permet de déduire les faits (conséquences) découlant de données initiales (data oriented). Avec du chaînage arrière , on cherchera à atteindre un ou plusieurs buts (goal oriented). Mais ce dernier présentant quelques lacunes, on lui préfèrera le chaînage mixte qui est ce que l'on pourrait appeler un savant mélange des deux.

Celle-ci consiste en trois composantes interactives: une base de connaissances, un moteur d'inférences et une interface.

La base de connaissances contient toute l'information dont un expert humain aurait besoin pour s'acquitter de son travail, ceci dans un domaine donné. C'est la seule composante du syst&eagrave;me qui contienne les connaissances propres au domaine que le système est censé recouvrir. Cette base de connaissances est elle-même divisée en deux composantes:
1) La première contient des faits spécifiques du domaine (par exemple, "Lisp est un langage de l'Intelligence Artificielle"). Ce sont les connaissances factuelles de la base ou encore base de faits.
2) La seconde contient des principes plus généraux, des règles, des heuristiques de résolution de problèmes qui représentent les modes de raisonnement propres au domaine considéré (par exemple, "Toute personne âgée de plus de 28 ans est dégagée des obligations militaires"). Ce sont les connaissances déductives souvent représentées par ce qu'on appelle des règles de production. La connaissance de ces heuristiques peut provenir, de la part de l'expert humain, soit d'une accumulation d'observations empiriques, soit de connaissances techniques propres au domaine.

Afin de favoriser une plus grande maniabilité de la connaissance, il est fréquent de la stocker déclarativement dans un langage clair, proche du langage naturel, et non noyée dans des pages de code informatique. Grâce à ce type de représentation, la connaissance du système sera facilement accessible à l'utilisateur qui pourra ainsi aisément la modifier ou l'agrandir, ou encore simplement la consulter.

Pour exploiter cette connaissance, un moteur d'inférences est nécessaire pour relier la description d'un problème aux capacités d'analyse d'une situation donnée. De façon générale et grâce à la structuration de la base de connaissances, le moteur d'inférences sera capable de répondre à des questions, de raisonner et de tirer les conséquences impliquées par la connaissance incluse dans le système.

La troisième composante importante d'un système expert contient des interfaces utilisateur. Les deux plus importantes sont:
1) une interface grâce à laquelle les utilisateurs pourront obtenir une consultation du système expert. Ce peut être un formulaire dans le cas d'un système fonctionnant en chaînage avant, ou un module de questions posées à l'utilisateur pour un système fonctionnant en chaînage arrière ou mixtre.
2) et une interface permettant l'acquisition des connaissances. Cette dernière est utilisée par l'expert humain pour mettre à jour et vérifier ses connaissances.

Une particularité majeure dans l'architecture d'un système expert réside donc en une nette séparation entre la base de connaissances et le moteur d'inférences, mécanisme d'exploitation de cette connaissance.

Les règles sont le plus communément d'ordre 0+. Mais sans rentrer dans le détail des formalismes logiques, donnons un exemple de règle :

SI voiture_couleur = rouge ET voiture_marque = Ferrari ALORS conducteur = heureux

Un peu de vocabulaire.

Dans la règle précédente, on recense plusieurs notions :

• Un Attribut : voiture_couleur, voiture_marque et conducteur sont des attributs.
• Une Valeur : rouge, Ferrari et heureux sont des valeurs.
• Un Opérateur : c'est ce qui lie un attribut et une valeur. Dans notre cas, on a des opérateurs =.
• Des connecteurs ici de conjonction : "et".

Une chose importante à comprendre est le fait que les opérateurs et les valeurs de la prémisse sont des opérateurs et des valeurs de comparaison ; alors que les opérateurs et les valeurs de conclusion sont des opérateurs et des valeurs d'affectation.

L'idée est qu'on va essayer de déclencher la règle.

Qu'est-ce cela veut dire ?

On va prendre les attributs en prémisse, et on va voir si la prémisse est vérifiée. Par exemple, on va comparer voiture_couleur à rouge, et si c'est le cas, c'est-à-dire si la voiture dont on dispose est effectivement rouge, alors c'est bon et on passe à la prémisse suivante. Si la marque de la voiture dont on dispose est effectivement Ferrari, alors c'est bon : la règle se déclenche.

Le déclenchement de la règle conduit à l'exécution des affectations de valeurs aux attributs présents en conclusion. Cela veut dire que l'on va pouvoir en tirer les conclusions. On va affecter les valeurs en conclusion à leurs attributs respectifs. On va par exemple en déduire que l'attribut conducteur est heureux.

Par contre, si l'une des prémisses n'avait pas été vérifiée alors la règle eût été abandonnée.

Finalement, tout le but du système expert est d'affecter des valeurs à des attributs en déclenchant des règles.

Une chose toutefois a pu susciter chez vous quelque interrogation. On a dit "si la voiture dont on dispose est rouge", mais qu'en sait-on ?

Là apparaît la notion de fait.

Il y a des faits. Le raisonnement va se baser sur eux pour déduire des conclusions, qui sont des affectations d'attributs dont on ignorait les valeurs.

Résumons-nous : Notions à connaître :

• Règle - Règle qui se déclenche
• Attribut - opérateur - valeur
• Prémisse - conclusion
• Fait

Parlons un peu des limitations et extensions du schéma de la règle et de la manière dont les choses sont implantées dans CyberExpert.

• Il peut y avoir des disjonctions "ou" en prémisse de la règle, ce qui n'est pas le cas dans CyberExpert.
• Une règle peut comporter plusieurs conclusions liées par des "et" conjonctifs (rarement de "ou"), ce qui est le cas dans CyberExpert.
• L'affectation en conclusion peut être ce que l'on appelle une valeur complexe, c'est-à-dire une expression où apparaissent des attributs, ce qui est le cas aussi dans un système expert.

Sur cette base comment appliquer le raisonnement ?

C'est l'objet des chapitres suivants.

Le chaînage avant est très simple.

L'utilisateur du système expert rentre des faits. A partir de ces faits rentrés, le système va essayer de déduire toutes les conclusions possibles, c'est-à-dire tous les attributs qui pourront être affectés, évalués, dirons-nous. Il est clair que dans cet ensemble de conclusions possibles, il en est qui intéresseront l'utilisateur, il en est d'autres qui ne lui diront rien, il en est enfin qui manqueront.

Comment s'y prend-on concrètement pour effectuer ce chaînage ?

Les faits sont de la forme :

attribut = valeur

On va prendre chaque fait et on va examiner toutes les règles où ce fait apparaît en prémisse. Grâce au mécanisme explicité plus haut, on va voir pour chacune de ces règles si elle est déclenchée. Si elle l'est, on va affecter les attributs en conclusion des valeurs qui leur correspondent. On dira que les faits ont été propagés.

Ces attributs affectés feront partie du résultat final de l'expertise ; et, en même temps, ils seront eux-mêmes propagés.

On fait cela jusqu'à l'épuisement des faits, et on communique les résultats à l'utilisateur.

Le chaînage arrière permet d'obtenir une information sur un attribut. C'est une réponse à la question "Quelle est la valeur de A ?" où A est un attribut appelé but.

Pour déterminer la valeur de A, on dispose de sources d'informations. Ces sources peuvent être soit des questions à l'utilisateur lui demandant la valeur de l'attribut, soit des règles dont l'enchaînement permet de trouver la valeur de l'attribut qui serait en conclusion d'une ou de plusieurs d'entre elles.

L'algorithme dans son principe est assez simple.

Pour chaque attribut, on définit ses sources.

• Si l'attribut est initial c'est-à-dire s'il n'apparaît qu'en prémisse de règle, les sources sont réduites aux questions.
• Si l'attribut est final, les sources sont les règles dans lesquelles l'attribut est en conclusion.
• Si l'attribut est intermédiaire, apparaissant à la fois en prémisse et en conclusion, alors les sources peuvent être les règles, ou alors on peut se replier sur les questions au cas où elles n'auraient rien donné.

Si, une fois la question posée, l'utilisateur répond, la valeur qu'il donne est affectée à l'attribut et c'est bon. Si les sources sont les règles, on prend cahcune des règles où l'attribut but apparaît en conclusion, et on essaye d'évaluer les attributs qui sont en prémisse. Si la règle se déclenche, l'attribut en conclusion est évalué.

Sommaire --- Département Informatique et Réseaux

Le chaînage mixte est une extension du chaînage arrière qui supplante ce dernier car il pallie à un problème qu'il pose. En effet le chaînage arrière pose le problème du retard à l'évaluation. Lorsque l'on évalue un but par chaînage arrière, l'évaluation peut conduire à des conclusions sur d'autres attributs, qui ne sont pas faites et pour lesquelles d'autres procédures de chaînage arrière sont inutilement invoquées.

De là l'idée de combiner le chaînage arrière, inefficace à lui seul, à du chaînage avant. Ainsi après chaque évaluation d'une prémisse de règle, une propagation en avant de cette évaluation est faite pour tirer l'ensemble des conclusions qu'il est possible d'en tirer.

Sommaire --- Département Informatique et Réseaux

Le transfert de connaissances est un long travail d'analyse du problème, d'étude du travail des experts et de discussion avec ceux-ci.
Ce travail va déboucher sur la rédaction de plusieurs documents complémentaires qui serviront ensuite pour leur transcription dans l'environnement informatique à proprement parler.
Nous présentons ici les documents qui ont servi à l'écriture des règles de décision pour aider les experts de la Maif à voir si le sinistre d'un assuré est couvert par leur assurance Raqvam.
Ceci n'est bien sûr qu'un cas d'école et, en dehors du document officiel d'assurance, ne correspond en rien à un quelconque système existant dans les locaux de cet organisme.

Les documents constituant le problème dans son ensemble et sa résolution sont :

• Le document contractuel de la Maif

  C'est le document unique à partir duquel seront constitués les suivants. En général, un véritable transfert de connaissances repose également sur de longs entretiens avec un expert du domaine qui a accepté que ses connaissances servent au tranfert.
  Ce document regroupe les clauses de l'assurance auquel le client est censé avoir souscrit.
  Son analyse repose beaucoup sur :

  • le vocabulaire utilisé. Il servira à l'élaboration des attributs et de leurs valeurs possibles.
  • la structuration des paragraphes. Elle permet d'identifier les cas et les sous-cas et servira à une première ébauche de la structuration des attributs, leurs relations de dépendance.
  • la syntaxe utilisée. Les phrases affirmative ou négatives seront identifiées, les parenthèses reflètent souvent des sous-cas (valeurs possibles)

• Le tableau des attributs

  Il contient trois colonnes :

  • les noms des attributs à proprement parler
  • leur nature : final (ne peut qu'être conclu), initial (est forcément renseigné par l'utilisateur) ou mixte (peut être soit une hypothèse, soit une conclusion). Ce sont ces derniers qui élaborent le chaînage des règles.
  • leurs valeurs possibles.

• L'arbre des attributs

  C'est un graphique qui représente les attributs et leurs relations de dépendance dans les règles. Lors de l'élaboration de ce document, l'écriture des règles est faite conjointement afin qu'elles puissent être nommées explicitement dans cet arbre.

• Les règles écrites en pseudo-langage

  C'est simplement une écriture des règles déductives issues du travail de tranfert. Leur écriture se fait en utilisant le vocabulaire choisi lors de la définition des attributs et de leurs valeurs.
  La syntaxe utilisée est libérée des contraintes d'un quelconque environnement informatique.
  Le travail de transcrition dans l'environnement de développement choisi se fera d'autant plus facilement que cette étape aura été réalisée avec le plus grand soin.

• Les règles et les attributs transcrits dans l'environnement dédié

  Il n'y a pas de structure normalisée. Nous vous donnons ici deux fichiers qui sont manipulés par un environnement simple qui est utilisé à l'enst pour les TP :

  • le fichier des règles transcrites
  • le fichier des paramètres utilisés

Sommaire --- Département Informatique et Réseaux

Nous nous plaçons dans le contexte où une analyse préalable a été faite et que le fait d'utiliser un système expert est tout à fait possible (techniquement et humainement), justifié (économiquement) et approprié (au problème).
Ces conseils s'adressent donc à ceux qui vont devoir concevoir puis mettre au point une base de connaissances.

• Choix des attributs

  Choisir les noms des attributs dans le vocabulaire propre au domaine d'étude. Ainsi l'écriture des règles reflètera au mieux l'énonciation en langage naturel de la déduction à laquelle elle fait référence.

• Valeurs possibles pour les attributs

  Il est toujours préférable de choisir un attribut qui puisse avoir plusieurs valeurs différentes, plutôt que de définir plusieurs attributs à valeur oui/non.

  Par exemple, dans le cas de la classification des animaux, il faut prendre l'attribut
  

  • peau à valeurs (poils, écailles, plumes)
  plutôt que les trois attributs
  
  • poils à valeurs (oui, non)
    
  • écailles à valeurs (oui, non)
    
  • plumes à valeurs (oui, non)
    
  En effet, en une seule question la seule connaissance du premier attribut permet de statuer sur les trois autres qui, dans un cas extrême, pourraient occasionner trois questions successives et provoqueraient une lourdeur du système non souhaitable.

• Pourquoi créer une hiérarchie d'attributs ?

  La création d'attributs mixtes fictifs peut s'avérer très intéressante dans le cas où cela réalise une segmentation dans l'espace des possibilités d'un autre attribut. Cela permettra au système espert de diminuer le nombre de règles à envisager pour ce dernier, si le premier est connu.

  Par exemple, toujours dans le cas de la classification des animaux, il vaut mieux disposer d'un attribut supplémentaire
  

  • catégorie à valeurs (mammifère, ovipare)
  En effet, la connaissance de cet attribut (par exemple mammifère) permettra au système d'éviter d'envisager les règles qui conclueraient sur des animaux qui ne seraient pas des mammifères.

• Écriture des règles
  • conserver une forme quasi naturelle aux règles. Il faut prévoir d'associer à chaque règle une forme lisible (sous forme de commentaire).
    
  • si une règle paraît très grosse : vérifier qu'elle n'encode pas plusieurs concepts à la fois. Si c'est le cas, décomposer la règle en autant de concepts qu'elle manipule.
    
  • si plusieurs règles se ressemblent : vérifier qu'il n'existe pas un concept commun à ces règles n'ayant pas été identifié.
    
  • ordonner les règles par paquets : pour en faciliter l'accès lors de l'écriture de la base, les règles doivent être ordonnées dans la base de connaissances par concept manipulé, étape de raisonnement, contexte,... Ceci, bien entendu, uniquement dans un but de clarté pour la lecture du fichier, le moteur d'inférences se chargeant seul d'ordonner les règles à sa guise.

• Remarques importantes
  • L'ordre dans lequel le système va regarder les paramètres intervenant dans la partie prémisses d'une règle dépendant de sa stratégie propre, vous ne devez en aucun cas poser comme préalable qu'il regardera les conditions dans l'ordre où elles sont écrites. En particulier, il faut veiller à ce que une seconde prémisse corresponde bien, dans votre esprit, à un "et" et non à un "et si"
    
  • Pour cette même raison d'ordre, vous devez toujours utiliser en prémisses des attributs qui soient indépendants les uns des autres.

Sommaire --- Département Informatique et Réseaux

• Intelligence Artificielle : généralités
  • Alain BONNET : L'intelligence artificielle, promesses et rèalités, Inter Editions (1984)
  • Patrick H. WINSTON : Intelligence Artificielle, Inter Editions (1988)

• Systèmes experts : principes
  • Henri FARRENY : Les Systèmes experts : principes et exemples, Cépaduès (1985-1989).
  • J.N. CHATAIN, A. DUSSAUCHOY : Systèmes experts : méthodes et outils, Eyrolles (1987).
  • Jean-Louis ERMINE : Systèmes experts : théorie et pratique, Lavoisier (1989)
  • R. I. LEVINE, D.E. DRANG, B. EDELSON : A Comprehensive guide to AI and expert systems, McGraw-Hill (1986).

• Transfert de connaissances
  • Alain BONNET, J.P. Haton et J.M. Truong-Ngoc : Systèmes experts, vers la maîtrise technique, Inter Editions (1986)
  • Jean-François GALLOUIN : Transfert de connaissances, Eyrolles (1988)
  • Donald A WATERMAN : A guide to expert systems, Addison Wesley (1985)
  • M. MUSZINSKY : Système expert : applications pratiques pour l'entreprise, Paris : Sybex (1990).
  • J.M. KARKAN, G. TJOEN : Systèmes experts : un nouvel outil pour l'aide à la décision, Paris : Masson (1993).

• Théorie, implémentation
  • Patrick H. WINSTON et Berthold K.P.HORN : Lisp, Addison Wesley (1988)
  • B.G. BUCHANAN, E.H. SHORTLIFFE. : Rule-based expert systems : the MYCIN experiments of the Stanford heuristic programming project, Addison-Wesley (1984).
  • Robert VOYER : moteurs de systèmes experts, Eyrolles (1987)