Chapitre 8 : Réalisation
Cette thèse a été réalisée en collaboration avec la société Cybel, dans le cadre d’une convention CIFRE. Les impératifs industriels et commerciaux nous ont contraint à réaliser une application non pas sur la version finale de notre modèle, mais sur sa version initiale. Nous avons cependant décidé de présenter cette application dans notre document, car sa construction nous a apporté des informations intéressantes dans l’optique de la réalisation future d’un système critique basée sur notre modélisation.
A partir de cette réalisation, nous indiquerons la définition d’une application envisageable basée sur notre modélisation.
8.1 Réalisation d’un système critique : SAVANT-3
L’application SAVANT-3 que nous avons présentée au cours du chapitre 4 était destinée à tester la modélisation de Jean-Louis Dessalles sur les conversations spontanées, et de montrer qu’une application EIAO serait possible à partir de cette modélisation [DES 90]. Cette application souffrait d’un certain nombre de défauts : son ergonomie était mauvaise[1], son intégration à une autre application n’était pas prévue et la création d’une base de connaissances était un processus douloureux. A titre d’exemple, la critique par SAVANT-3 d’un prédicat prolog simple (3 clauses) a nécessité le développement de plus d’une centaine de règles [MEY 93].
Afin de pouvoir l’intégrer au sein de ses didacticiels, la société CYBEL a demandé qu’une nouvelle version de SAVANT-3 soit développée.
8.1.1 Exploitation industrielle
Les didacticiels CYBEL sont développés à partir de Macromedia Authorware. Ce système auteur, développé par Macromedia, permet de réaliser des présentations/didacticiels à partir d’un environnement graphique convivial et d’un langage de programmation proche du Basic. Le langage se révélant trop pauvre pour réaliser une application de la complexité de SAVAN T-3, nous avons dû développer une nouvelle version de SAVANT-3 sous formes de fonctions dynamiques (dll pour dynamic loadable library). Une application créée par le biais d’Authorware peut charger puis utiliser des fonctions dll. Cependant, il n’est pas possible de conserver des informations en mémoire du côté des fonctions. Nous avons dû repenser SAVANT-3 afin qu’il puisse être appelé pour calculer une unique réplique avant de rendre la main.
Les fonctionnalités de SAVANT-3 ont été alors coupées en deux. Une fonction de détection de saturation a été développée. Son rôle est d’indiquer à l’application principale si SAVANT-3 désire intervenir. Si c’est le cas, une seconde fonction peut-être appelée. Cette seconde fonction va calculer le prochain argument de SAVANT-3, accompagnée des réponses possibles de l’élève sous forme de QCM.
Une boucle simple permet alors de reconstituer les dialogues de SAVANT-3 (tant qu’une saturation est détectée, on appelle la fonction d’argumentation). Cependant, si l’auteur le décide, il est possible de retarder la critique (néanmoins, nous ne recommandons pas ce retard, puisque la critique sera d’autant mieux perçue qu’elle interviendra au moment de l’erreur de l’étudiant).
8.1.1.1 Les fonctions SAVANT-3
Cette nouvelle version de SAVANT-3 apporte une amélioration autre que technique par rapport à la version précédente. Celle-ci souffrait en effet de débuts de dialogues artificiels. SAVANT-3 ne se comporte correctement qu’à partir du moment où une problématique a été établie entre le système et l’apprenant. Une problématique étant pour nous définie par une règle saturée, il était nécessaire de forcer l’étudiant à prendre position sur la valeur de vérité de termes intervenant dans les règles de la base de connaissances. L’interaction débutait donc par une série de questions qui tenaient plus de l’interrogatoire de police que du dialogue socratique. En particulier, la pertinence des questions était loin d’être apparente, alors que SAVANT-3 était censé être un système critique toujours pertinent. Si l’apprenant maîtrisait le sujet de l’interaction, celle-ci pouvait se terminer sans qu’aucune problématique n’apparaisse jamais. L’apprenant répondait à une série de questions sans liens apparents, et voyait le système lui répondre «d’accord…» et terminer l’interaction.
Ces problèmes sont entièrement résolus dans cette nouvelle version de SAVANT-3, car la fonction visible (Argumente) n’est appelée que si Cohérence a détecté une contradiction. La partie initiale du dialogue est remplacée par l’exercice sur lequel portera la critique. On s’assure ainsi que les critiques de SAVANT-3 sont toujours pertinentes.
8.1.1.1.1 Représentation des connaissances
Le fait que l’application cliente de SAVANT-3 soit en charge de lui fournir la valeur de vérité de certains des termes qu’il manipule impose de définir un format permettant aux deux applications de communiquer. L’application cliente fournit à SAVANT-3 :
· Un nom de fichier dans lequel est contenue la base de connaissances logiques relative à l’exercice traité. Le nom du fichier contenant les chaînes de caractères utilisés par Argumente pour calculer ses réponses se déduit du nom de la base de connaissances logiques.
· Un vecteur d’état contenant les valeurs de vérités sur lesquelles l’apprenant a pris position.
Les termes intervenant dans les règles sont numérotés. La position au sein du vecteur d’état indique quel terme représente la coordonnée considérée. Pour chaque position, la valeur 0 indique que l’étudiant n’a pas pris position, la valeur 1 indique que l’étudiant à affirmé le terme et la valeur -1 indique qu’il l’a nié. Le vecteur (1 0 -1 0 1) signifie donc que l’étudiant a affirmé (1, vrai), (3, faux) et (5, vrai).
Les règles utilisées sont des règles sans menu, limitées à la modalité paradoxale. Une règle est représentée par la liste des termes qui la compose. La négation d’un terme est représentée par l’opposé de l’entier représentant ce terme. La règle [1, non 2, 3] Þ Paradoxe sera ainsi représenté par regle(1, [1, -2, 3]).
Le premier argument de la règle (1 dans notre exemple) est un booléen (0 : faux, 1 : vrai) qui indique si la règle est considérée comme une règle de bon sens. Une règle de bon sens est une règle que l’on considère connue par l’étudiant.
Afin de permettre à SAVANT-3 d’effectuer des déductions sur les déclarations de l’apprenant, des règles de déduction sont fournies dans la base. Ces règles ne doivent a priori pas intervenir dans la critique, puisque l’étudiant les connaît. Ce sont ces règles que nous appelons règle de bon sens.
Le lecteur aura noté que l’ensemble des connaissances présentées jusqu’à présent ne permettent pas de construire un dialogue, puisque SAVANT-3 ne dispose d’aucun vocabulaire. Ces connaissances permettent seulement à Cohérence et Argumente d’effectuer les manipulations symboliques nécessitées par leurs rôles respectifs. La représentation des connaissances nécessaire pour le calcul des répliques sera présentée dans le paragraphe consacré à Argumente.
8.1.1.1.2 La fonction Cohérence
Le rôle de la fonction Cohérence est de déterminer si la situation qui lui est fournie par le biais du vecteur d’état est problématique. Cohérence retourne un booléen valant faux (0) si la situation est problématique et vrai (1) sinon.
Considérant que la critique sera d’autant plus pertinente qu’elle interviendra tôt dans la résolution de l’exercice, nous avons essayé de supprimer tout retard à la détection de l’incohérence. Pour cela, nous définissons comme incohérente une situation où il n’est plus possible d’invalider l’ensemble des règles de la base. Cohérence génère donc un jeu de valeurs de vérité pour l’ensemble des termes intervenant dans les règles de la base, en utilisant les techniques de la propagation de contrainte. Si une telle génération est possible, la situation est cohérente. Si la génération échoue, la situation est déclarée incohérente.
Dans la suite de cette discussion, nous dirons qu’une règle «propage» si un des termes qui la compose n’est pas connu et que les autres termes sont connus pour vrais. A titre d’exemple, regle(1, [1, -2, 3]) propagera pour (1 : vrai, 2 : faux, 3 : inconnu), (1 : vrai, 2 : inconnu, 3 : vrai) et (1 : inconnu, 2 : faux, 3 : vrai). Quand une règle propage, il est possible de fixer la valeur de vérité du terme inconnu. Si ce terme était vrai, la règle serait saturée et la situation serait problématique.
Dans la suite de cette discussion, nous dirons qu’une règle est «cassée» si au moins un de ces termes est connu pour faux. Une règle qui vient de propager est donc cassée.
Par ailleurs, la fonction Cohérence ne calculant pas de réplique, la distinction entre les règles de bon sens et les autres est pour elle inutile. La procédure de génération est alors la suivante :
· Propager en cascade. Chacune des règles est examinée. Si une d’elle propage, on attribue au terme inconnu la valeur de vérité évitant la saturation de la règle. Quand une règle propage, il est nécessaire de réitérer la phase de propagation car la détermination du nouveau terme peut rendre propageante de nouvelles règles. A chaque propagation, on vérifie qu’aucune des règles n’est saturée. Si c’est le cas, on remonte au dernier point de choix (où l’on inverse ce choix). S’il n’existe pas de point de choix, la situation est paradoxale. La résolution s’arrête et Cohérence renvoie 0 (faux). Quand il n’existe plus de règle propageante, on vérifie si au moins une des règles n’est pas cassée. Dans le cas contraire, la situation n’est pas paradoxale. La résolution s’arrête et cohérence renvoie 1 (vrai). S’il existe au moins une règle non encore cassée, on effectue une phase de génération.
· Générer un terme. Pour cela, on considère une règle non saturée. On choisit alors un terme de valeur de vérité inconnue appartenant à cette règle. On choisit comme valeur de vérité la valeur cassant la règle en question, et on pose un point de choix pour un retour-arrière éventuel. On relance alors la propagation de contrainte.
Nous n’avons pas effectué d’optimisation pour le choix de la règle saturée. Comme l’existence d’une solution est suffisante, le déroulement de Cohérence est très rapide quand peu de valeurs de vérité sont connues, car l’on dispose d’un grand nombre de degrés de liberté. Si la situation est plus contrainte, il reste peu de valeur à affecter et la résolution reste rapide. Les situations qui nécessiteraient une optimisation sont des situations où la base de règle est très complexe et où la valeur d’un unique terme suffit à rendre la situation problématique, comme dans :
[-1, 6]
[1, 2, 3, 4, 5] [1, -2, 3, 4, 5]
[1, 2, 3, 4, -5] [1, -2, 3, 4, -5]
[1, 2, 3, -4, 5] [1, -2, 3, -4, 5]
[1, 2, 3, -4, -5] [1, -2, 3, -4, -5]
[1, 2, -3, 4, 5] [1, -2, -3, 4, 5]
[1, 2, -3, 4, -5] [1, -2, -3, 4, -5]
[1, 2, -3, -4, 5] [1, -2, -3, -4, 5]
[1, 2, -3, -4, -5] [1, -2, -3, -4, -5]
Ici, la résolution peut être très rapide (par 1 faux et 6 faux) ou relativement longue si elle débute par 1 vrai (qui est problématique, mais qui demande la pose d’un grand nombre de point de choix avant que la problématique ne soit détectée). Cependant, une telle situation est encore résolue instantanément compte tenu de la rapidité des machines modernes. Afin que le temps de réponse devienne inacceptable, il faut encore que des points de choix soit posés par d’autres règles n’interagissant pas avec les règles impliquées dans la détection problématique. Or, si l’on peut mettre en évidence deux ensembles de règles indépendants dans une base de connaissances de SAVANT-3, il est possible de créer deux bases contenant chacune un des deux ensembles de règles sans pour autant maintenir deux vecteurs d’états dans l’application cliente (deux ensembles de règles sont indépendants si aucun des termes apparaissant dans les règles d’un des ensembles n’apparaît dans une des règles de l’autre ensemble).
Les seules situations nécessitant une optimisation sont donc des situations d’une très grande richesse (un très grand nombre de règles toutes liées entre elles, avec une problématique apparaissant sur un nombre faible d’affectations). Les exercices utilisés dans les didacticiels CYBEL n’atteignant pas ce niveau de richesse, l’optimisation n’est pas nécessaire.
En outre, l’optimisation peut ralentir la résolution dans les situations où les choix par défaut (on choisit la première règle de la base) aboutissent à une résolution sans retour arrière. Dans ces situations, l’optimisation double approximativement le temps de calcul, puisque l’ensemble des règles non encore saturées sont visitées deux fois pour chaque affectation (au lieu d’une seule pour la version non optimisée). Ce type de situation est très fréquent en début de résolution d’un exercice. Optimiser revient alors à ralentir l’application cliente quand SAVANT-3 reste invisible pour l’utilisateur et à l’accélérer quand SAVANT-3 émet une critique. Il nous est apparu qu’un ralentissement de l’application serait plus acceptable quand une critique est émise, ce qui nous a convaincu d’éviter l’optimisation.
8.1.1.1.3 La fonction Argumente
Le rôle de la fonction Argumente est d’émettre une critique quand la situation est problématique. Argumente respecte un ensemble de priorités pour calculer sa critique, en commençant par les critiques les plus évidentes :
· Les déclarations de l’apprenant saturent une règle. La règle est rappelée à l’apprenant, et on lui demande de changer la valeur de vérité d’un des termes intervenant dans la règle saturée. Argumente vérifie dans un premier temps la saturation des règles de bon sens, puis dans un second temps la saturation des autres règles.
· Argumente propage, en deux passes et par le biais des règles, les déclarations de l’apprenant. La première passe est effectuée en n’utilisant que les règles de bon sens. La seconde passe est effectuée en utilisant la totalité des règles. A l’issue de chacune des propagations, Argumente vérifie si une des règles est saturée. Si c’est le cas, la règle saturée est présentée à l’apprenant et on lui demande de changer la valeur de vérité d’un des termes intervenant dans cette règle. Si la saturation intervient après la première passe, on présentera la problématique en considérant que l’apprenant a affirmé les termes déduits. Si la saturation intervient après la seconde passe, on présentera la problématique en précisant que les termes présentés sont déduits de ses affirmations.
· Argumente génère (comme le fait Cohérence) des valeurs de vérités pour les termes encore inconnus. Dès qu’une règle est saturée, Argumente demande à l’utilisateur de prendre position sur la valeur de vérité d’un des termes appartenant à la règle saturée et ayant été affecté au cours de la génération.
Le troisième type de critique ne permet pas à l’apprenant de sortir de la situation problématique. L’objectif est ici de se ramener à une des deux situations précédentes, afin de pouvoir émettre des critiques. Une fois que l’apprenant aura pris position sur un nombre suffisant de termes, il pourra sortir de la situation problématique en revenant sur les choix effectués avant le début de la critique.
On se retrouve donc dans une situation de dialogue Socratique. On va en effet amener, par le biais de questions, l’étudiant à se contredire, puis à lui faire réaliser que l’unique moyen dont il dispose pour sortir de la contradiction est de revenir sur des choix effectués avant la série de questions. Cette situation nous paraît particulièrement intéressante, puisqu’elle permet de démontrer à l’apprenant les conséquences négatives des choix qu’il a effectués, ce qui devrait lui permettre par la suite de mieux anticiper les conséquences des dits choix.
Les connaissances permettant de générer les critiques sont :
· La définition des termes, sous la forme terme(Nro, NroVerbe, NroSuj, NroCom) où Nro est le numéro du terme et où NroVerbe, NroSuj et NroCom sont des numéros identifiant des libellés, respectivement le verbe, le sujet et le complément.
· La définition des libellés, sous la forme libelle(Nro, StrLibelle) où Nro est le numéro du libellé et StrLibelle est la chaîne de caractères représentant le libellé. Les verbes doivent être conjugués. Si un verbe est constitué d’un auxiliaire et d’un participe, un point remplacera l’espace entre les deux mots. Ce point est l’endroit ou Argumente introduira une éventuelle marque de négation.
La critique fournie par Argumente dans le cas d’une détection de saturation prend la forme suivante :
Introduction
Liste des termes de
la règle saturée
Ce qui est impossible.
Que proposez-vous ?
Liste des négations
des termes
Si la saturation ne nécessite pas de propagation (ou si la propagation ne nécessite que l’utilisation des règles de bon sens) Introduction vaudra : «Attendez, vous m’avez dit :». Dans le cas contraire, Introduction vaudra : «D’après ce que j’ai compris :».
Les questions posées par Argumente dans le cas d’un dialogue Socratique seront de la forme :
Pensez-vous que :
Terme
Non Terme
Chacune des réponses possibles est accompagnée des modifications qu’apporte au vecteur d’état le choix de cette réponse. L’application cliente se contente donc de poser la question proposée par Argumente, apporte les modifications au vecteur d’état dues à la réponse de l’apprenant, puis relance la fonction Cohérence (puis Argumente, s’il y a lieu).
L’application cliente est par ailleurs en charge d’intégrer dans sa propre représentation les modifications induites sur l’état du problème par les réponses fournies à Argumente. Quand la situation est redevenue cohérente, l’exercice peut reprendre son déroulement normal.
8.1.1.2 Exemple d’exécution
Afin d’illustrer les mécanismes que nous venons de décrire, nous allons maintenant examiner un exemple d’exécution. L’exercice consiste à mettre en place divers éléments d’un moteur. La chambre à air doit notamment être située en amont de la chambre de combustion, afin que de l’oxygène soit présent dans cette chambre. L’apprenant vient de placer la chambre à air en aval de la chambre de combustion.
Les règles logiques utilisées sont les suivantes :
regle(0, [-1, 2])
regle(1, [-2, 3])
regle(0, [-3, 4])
regle(0, [-4])
Les termes ont la sémantique suivante (présentée ici sous une forme plus lisible que celle utilisée dans l’application) :
1 : La chambre à air est placée en
amont de la chambre de combustion
2 : La chambre de combustion contient
de l’oxygène
3 : La combustion est possible
4 : Le moteur fonctionne normalement
Le vecteur d’état, au moment de l’appel à Cohérence, est (-1,0,0,0). La propagation produit successivement -2, -3 et -4, ce qui sature la règle [-4]. Argumente est donc appelé, là encore avec le vecteur d’état (-1, 0, 0, 0).
Aucune des règles de la base n’est saturée, Argumente effectue donc une propagation sur les règles de bon sens, qui ne donne rien, puis sur l’ensemble des règles, qui produit à nouveau -2, -3 et -4. La règle [-4] est saturée, ce qui provoque la génération de la réponse :
D’après ce que j’ai compris :
Le moteur ne fonctionne pas normalement.
Ce qui est impossible.
Que proposez-vous ?
Le moteur fonctionne normalement. (4)
L’apprenant ne dispose ici que d’un seul choix, qui correspond d’ailleurs à l’objectif du problème qu’il est en train de résoudre. Après sa réponse, le vecteur d’état vaut (-1, 0, 0, 1). Après la détection de la saturation par Cohérence (production de -2 et -3 puis détection de la saturation sur la règle [-3, 4]), Argumente effectue une nouvelle propagation en utilisant des règles autres que celles de bon sens (aucune règle n’étant directement saturée) et répond :
D’après ce que j’ai compris :
La combustion n’est pas possible.
Le moteur fonctionne normalement.
Ce qui est impossible.
Que proposez-vous ?
La combustion est possible. (3)
Le moteur ne fonctionne pas normalement. (-4)
En supposant que l’apprenant ne revienne pas en arrière, le choix «La combustion est possible» est effectué. Le vecteur d’état vaut alors (-1,0,1,1). Cohérence détecte la saturation sur [-2, 3], puis Argumente, en n’utilisant cette fois que les règles de bon sens démontre 2, puis détecte que la règle [-1, 2] est saturée. Il répond alors :
Attendez, vous m’avez dit :
La chambre à air n’est pas placée en amont de la chambre de combustion.
La chambre de combustion contient de l’oxygène.
Ce qui est impossible.
Que proposez-vous ?
La chambre à air est placée en amont de la chambre de combustion. (1)
La chambre de combustion ne contient pas de l’oxygène. (-2)
L’apprenant peut finalement corriger son erreur. Si le lien entre ces réponses ne lui paraît pas évident, il peut également choisir la réponse -2, et dans ce cas, la règle de bon sens [-2, 3] lui est rappelé.
On constate que les règles de bon sens jouent bien le rôle pour lequel elles ont été créées, à savoir de permettre des déductions sans apparaître a priori dans la critique. On remarque également que l’absence de la modalité indésirable oblige l’auteur à exprimer l’objectif sous la forme d’une règle paradoxale. Ce choix a été effectué afin de ne pas rendre plus complexe la sémantique de l’application, les auteurs présumés des bases SAVANT-3 ne connaissant a priori pas le modèle présenté ici.
8.1.2 Aide à la création de la base logique : EDR
La création d’une base de règle pour SAVANT-3 est une tâche difficile. Le formalisme est au départ peu intuitif, même pour des sujets formés à la logique. Afin de permettre aux employés de CYBEL de réaliser des bases de connaissances logiques pour les didacticiels qu’ils développent, un système d’aide à la création à été développé : EDR (pour Editeur De Règle).
Développé pour Windows 95, EDR possède une ergonomie classique, accompagnés des fonctions que l’on s’attend à retrouver sur des logiciels modernes (fonction d’annulation et de rétablissement, aide en ligne…). Outre ces fonctionnalités, le langage d’expression a été enrichi pour faciliter le travail de création de bases de connaissance, notamment en le rapprochant de la présentation classique de la logique d’ordre 0.
Un compilateur permet de porter la base créée au format SAVANT-3. Le compilateur vérifie également que la base est cohérente (i.e. qu’il existe au moins un jeu d’affectation des termes intervenant dans les règles qui ne rende pas la base problématique), et supprime de la base compilée les règles inutiles. EDR permet également d’inclure une base dans une autre, sous la condition que les deux bases soient compatibles.
8.1.2.1 Le langage d’expression d’EDR
Le langage d'expression d’EDR se décompose en :
· Libellé : le libellé est l'élément constitutif des termes. Il est défini par un numéro unique et une chaîne de caractère, pouvant selon les cas représenter un verbe, un sujet ou un complément. On notera que le verbe doit être conjugué et accordé au sujet qui lui sera associé dans le termeClause > main . Si le verbe est en fait un groupe verbal, on pourra indiquer par un point (".") l'emplacement où devra se situer la négation. On notera que ce point remplace alors l'espace. Ainsi le verbe "est dérivable" sera noté "est.dérivable".
· Terme : les termes sont les éléments atomiques de la représentation d’EDR. Un terme est défini par un numéro de terme unique et un triplet de numéros de libellé. Le premier correspond au verbe, le deuxième au sujet et le troisième au complément.
· Fait : les faits sont le moyen d'indiquer à SAVANT-3 qu’un terme est juste ou faux (si, lors d'une interaction, l'étudiant indique qu'un fait est faux, SAVANT-3 refuse cette assertion et précise que ce fait n'est pas négociable). Les faits sont des règles de bon sens ne contenant qu’un seul terme.
· Expression : afin de faciliter le travail d’écriture, les auteurs peuvent utiliser des expressions (plutôt que des termes) au sein de l’ensemble des éléments du langage (à l’exception des faits, termes et libellés). La syntaxe autorisée pour écrire une expression est :
• "clause Nro" pour désigner un terme.
• "formule NomFormule" pour désigner une formule.
• "non(Expr)" pour désigner la négation d'une expression
• "et(Expr1 ; Expr2)" pour désigner la conjonction de 2 expressions.
• "ou(Expr1 ; Expr2)" pour désigner la disjonction de 2 expressions.
La correction des expressions est vérifiée au moment de leur saisie. Si une expression est incorrecte, EDR le signale à l’utilisateur et refuse de quitter la boîte de dialogue dans laquelle cette expression est saisie.
· Formule : une formule est une expression nommée. Il est possible d’utiliser le nom d’une formule à la place de la formule correspondante dans l’écriture de la base de règles. Deux formules différentes ne peuvent porter le même nom, bien que deux noms de formules différents puissent correspondre à la même expression. L'expression d'une formule peut contenir d'autres noms de formules. Cependant, l'expansion des formules se faisant à la précompilation, il est interdit de définir des formules récursives (ou des cycles au sein de la définition des formules). La génération des cycles est détectée (et refusée) par EDR au moment de la saisie des formules.
· Implication : il s’agit de l’implication matérielle. La première expression implique la seconde.
· Equivalence : les règles d’équivalence permettent d’indiquer que deux expressions sont équivalentes.
· Au moins un : une règle en «au moins un» est constituée d’une liste d’expression. Au sein d’une règle en «au moins un», au moins un des éléments de la liste est vrai.
· Exclusion Mutuelle : une règle en «Exclusion Mutuelle» est constituée d’une liste d’expressions. Au sein d’une règle en «Exclusion Mutuelle», il est impossible que deux éléments ou plus de la liste soient simultanément vrais.
· Hiérarchie : une règle en «Hiérarchie» est constituée d’une expression, appelée le «père», et d’une liste d’expression, appelée la «liste de fils». Les propriétés de la hiérarchie sont :
• Le père est faux si et seulement si tous les fils sont faux.
• Le père est vrai si et seulement si au moins un fils est vrai.
· Hiérarchie Exclusive : une règle en «Hiérarchie exclusive» est une hiérarchie où la liste des fils est en exclusion mutuelle. Les propriétés de la Hiérarchie Exclusive sont donc :
• Le père est faux si et seulement si tous les fils sont faux.
• Le père est vrai si et seulement si un fils est vrai.
• Il est impossible que deux fils ou plus soient vrais.
· Règle (de bon sens / sauf bon sens) : ces règles s’expriment sous la forme de listes d’expressions. Une règle indique qu’il est impossible que tous les éléments de la liste soient simultanément vrais. On notera qu’une règle au sens d’EDR peut générer plusieurs règle au sens SAVANT-3 du fait de l’utilisation des expressions au sein des règles EDR. Ainsi la règle regle_bon_sens([ou(1 ; 2), 3]) générera les deux règles de bon sens [1, 3] Þ Paradoxe et [2, 3] Þ Paradoxe.
Afin de faciliter le travail de création, nous avons développé un mécanisme de concaténation de base. Il est alors possible de découper le travail de création en morceaux, à condition de respecter un nombre minimal de contraintes que nous allons aborder maintenant.
8.1.2.2 La concaténation de deux bases
La concaténation de deux bases consiste à inclure dans la base présente en mémoire le contenu d’une base sauvegardée dans un fichier. Il est impossible d’effectuer une concaténation entre deux bases incompatibles. Si cette opération est essayée, EDR émet un message d’erreur et refuse de l’effectuer. Deux bases sont incompatibles si :
· Les fichiers contiennent deux termes différents de même numéro.
· Les fichiers contiennent deux libellés différents de même numéro.
· Les fichiers contiennent deux formules différentes de même nom.
· La concaténation des deux fichiers crée un cycle dans la définition des formules.
Afin de pouvoir détecter si la concaténation est possible, EDR l’effectue dans tous les cas, puis vérifie qu’aucune des conditions n’est violée. Si une erreur est détectée, la concaténation s’interrompt, et les opérations de concaténation précédant la détection de l’erreur sont annulées. La concaténation s’effectue en insérant dans la base cible les éléments de la base source. Un seul élément est ajouté à la fois, et les tests d’incompatibilité sont effectués à chaque insertion. La concaténation s'effectue en supprimant les doublons (i.e. il est possible d’effectuer la concaténation de deux bases contenant par exemple deux libellés identiques de même numéro ; la base résultante ne contiendra qu’une seule occurrence de ce libellé).
EDR ne vérifie pas la cohérence de la base au moment de la concaténation. Cette vérification s’effectue à l’issue de la compilation.
Une fois le travail de création effectué, l’auteur peut décider de compiler la base de connaissances. Il est possible de compiler soit vers la mémoire, soit vers un fichier. La seule différence entre ses deux compilations réside dans le fait que dans le premier cas, le résultat n’est pas sauvegardé. La compilation vers la mémoire permet à l’auteur de vérifier que celle-ci se déroule normalement (en particulier, EDR informera l’auteur d’une éventuelle incohérence dans la base à cette étape).
La compilation se déroule en deux phases : la précompilation et la compilation à proprement parler. Nous allons maintenant examiner les traitements effectués à la précompilation.
8.1.2.3 La précompilation
La précompilation effectue des transformations sur la base de connaissances qui doit être compilée. Ce travail permet de simplifier la compilation à proprement parler. EDR effectue les opérations de précompilation directement sur la base source. Cette base est donc sauvegardée, afin qu’elle puisse être restituée dans l’état voulu par l’auteur à l’issue de la précompilation. A la précompilation, EDR effectue les opérations suivantes, présentées ici dans l’ordre chronologique des traitements :
· EDR transforme les hiérarchies exclusives de père A et de liste de fils B en une hiérarchie de père A et de liste de fils B et une exclusion mutuelle de liste B.
· EDR transforme les hiérarchies de père A et de liste de fils B en une équivalence entre A et la disjonction des éléments de la liste B (la liste B est transformée en expression, en utilisant le fait que chaque élément de la liste est en disjonction avec les autres).
· EDR transforme les équivalences en doubles implications.
· EDR supprime les doubles négations et remplace les noms de formule intervenant dans la base par les formules associées.
Les définitions des libellés et des termes sont directement transmises à la base cible, sans modifications. Une fois la précompilation effectuée, EDR commence la compilation à proprement parler, que nous allons présenter maintenant.
8.1.2.4 La compilation
Compte tenu des éléments traités à la précompilation, la compilation consiste à transformer en règles d’incompatibilité les définitions de faits, d’implications, d’exclusions mutuelles, de règles en «au moins un» et de règles d’incompatibilité (de bon sens ou pas). Au début de la compilation, l’ensemble des définitions à transformer, à l’exception des faits, peut contenir des expressions construites à partir des connecteurs logiques et, ou et non qu’il conviendra de supprimer.
La compilation s’effectue en deux phases. Dans un premier temps, les définitions sont transformées en règles à saturation. Dans un second temps, la base de règles est mise en forme normale disjonctive négative (ce qui revient à supprimer les connecteurs intervenant dans les règles).
On pourrait s’étonner de voir apparaître certaines transformations de définition EDR à la compilation et d’autres à la précompilation. Rappelons pour clarifier ce point que la précompilation effectue des transformations de la base source vers la base source, alors que la compilation effectue des transformations de la base source vers la base cible.
A la première phase de la compilation, EDR effectue les opérations suivantes, présentées ici dans l’ordre chronologique des traitements :
· EDR transforme les faits en règles d’incompatibilité de bon sens à terme unique. Ainsi, le fait N sera transformé en regle(1, [-N]).
· EDR transforme les implications en règles d’incompatibilité de bon sens, en utilisant le fait que A Þ B et A Ú ØB ont les mêmes valeurs de vérité en fonction de A et B. La règle A Þ B devient donc regle(1, [A, ØB]). Ici, A et B sont encore des expressions.
· EDR transforme les règles en «au moins un» en règles d’incompatibilité de bon sens. Dire qu’au moins un des éléments d’une liste est vrai revient à dire qu’il est impossible que tous les éléments de la liste soient simultanément faux. Ainsi, la règle au_moins_un([A, B, C]) devient regle(1, [ØA, ØB, ØC]). Ici, A, B et C sont encore des expressions.
· EDR transforme les exclusions mutuelles en règles d’incompatibilité de bon sens. Pour cela, EDR créé une règle d’incompatibilité pour chaque couple construit à partir de deux éléments distincts de la liste en exclusion mutuelle. Ainsi, la règle exclusion_mutuelle([A, B, C]) permet de créer les règles regle(1, [A, B]), regle(1, [A, C]) et regle(1, [B, C]). Ici, A, B et C sont encore des expressions.
A ce stade de la compilation, la base ne contient plus que des règles d’incompatibilité. La compilation se termine par la mise en forme normale disjonctive négative de ces règles. Une règle est dite en forme normale disjonctive si elle s’exprime sous la forme d’une disjonction généralisée de conjonctions généralisées. Comme (A Ú B) Þ Incompatible équivaut à A Þ Incompatible et B Þ Incompatible, il convient de créer une règle d’incompatibilité pour chaque conjonction généralisée intervenant dans une règle en forme normale disjonctive. Une des conséquences de ce point est qu’une règle avant la mise en forme normale disjonctive peut en créer plusieurs après cette opération.
La mise en forme normale disjonctive d’une règle s’effectue par le biais de transformations. On cherche dans l’élément courant de la liste constituant la règle si une transformation s’applique. Si c’est le cas, on l’effectue, ce qui revient à détruire la règle traitée et à créer une ou deux nouvelles règles. On recommence alors l’opération de mise en forme normale disjonctive sur la première règle créée par la transformation. Si aucune transformation ne s’applique, on passe à l’élément suivant de la règle. Si l’élément courant de la liste était le dernier élément, la règle est en forme normale disjonctive. On passe alors à la règle suivante.
L’unique transformation unaire utilisée est la suppression de la double négation. Il existe deux types de transformations binaires, que nous nommerons «transformation a» et «transformation b». Les transformations a sont des transformations conjonctives. Quand une transformation a est utilisée, les deux éléments résultants de la transformation remplacent dans la même liste l’élément ayant été transformé. Une transformation a donne donc une unique règle résultante. Les transformations b sont des transformations disjonctives. Quand une transformation b est utilisée, chaque élément résultant de la transformation remplace dans une nouvelle règle l’élément transformé. Une transformation b fournit donc deux règles résultantes. Les transformations utilisées sont :
[…, et(A, B), …] a […, A, B, …]
[…, non(ou(A, B)), …] a […, non(A), non(B), …]
[…, ou(A, B), …] b […, A, …], […, B, …]
[…, non(et(A, B)), …] b […, non(A), …], […, non(B), …]
Une fois la mise en forme normale disjonctive effectuée, on supprime de la base les paradoxes inutiles. Un paradoxe P1 est inutile s’il existe un autre paradoxe P2 dans la base tel que P2 É P1 (en effet, à chaque fois que P1 sera saturé, P2 le sera aussi) ou si le paradoxe contient à la fois les termes X et –X (dans ce cas là, le paradoxe est toujours cassé). Toutefois, si un paradoxe non de bon sens est inclus dans un paradoxe de bon sens, on ne supprime pas le paradoxe de bon sens (SAVANT-3 traitant en premier les paradoxes de bon sens, ce paradoxe n’est pas inutile).
Enfin, on vérifie que la base est cohérente en générant un jeu d’affectations pour l’ensemble des termes intervenant dans les règles. Si la vérification de cohérence échoue, l’auteur en est averti est la base compilée est sauvegardée dans un fichier d’erreur. Si la compilation réussit, la base compilée est sauvegardée, et un fichier du vecteur d’état est créé. Ce fichier contient la liste des numéros des termes intervenant dans les règles, ainsi que la traduction de ces termes. Ce fichier n’est pas utilisé par SAVANT-3, mais permet à l’auteur d’avoir le vecteur d’état de manière explicite quand il réalise l’application cliente.
8.2 Analyse de l’exploitation industrielle
SAVANT-3 souffre encore, dans la version qui vient d’être présentée, de défauts qui compromettent son exploitation industrielle. D’une part, SAVANT-3 ne permet pas d’utiliser de variables. Cela rend par exemple impossible toute forme de raisonnement intégrant des calculs. Une simple comparaison entre deux variables du problème n’est pas a priori possible (de fait, la comparaison peut être effectuée du côté de l’application cliente, mais cela rend difficile la prise en compte dans cette application cliente des modifications apportées sur l’état du problème par le dialogue entre l’apprenant et Argumente).
Par ailleurs, malgré le développement d’EDR, la création d’une base de connaissances reste un processus difficile. En l’état, créer une base SAVANT-3 revient à anticiper les critiques possibles, puis à les traduire dans le formalisme d’EDR. Alors qu’EDR avait été développé dans l’espoir de créer les bases de connaissances de manière déclarative, on se retrouve dans une situation où l’on pense l’interaction en terme de dialogue dynamique puis où on cherche à traduire ce dialogue dans un formalisme statique.
8.2.1 La cause des problèmes
Les deux problèmes que nous venons de décrire ont une origine commune. Notre modélisation démontre que la résolution de problèmes met en jeu un couplage entre des connaissances logiques et des opérations de calculs. L’analyse du comportement de notre modèle montre d’autre part que la modalité paradoxale n’intervient quasiment jamais dans une résolution de problème. La seule étape de la résolution où cette modalité intervient (la production contre-factuelle) n’est pas programmée dans la version CYBEL de SAVANT-3. Par ailleurs, la modalité indésirable, si importante dans notre modèle puisqu’elle permet de représenter les objectifs, n’est pas elle non plus présente dans la version que nous venons de présenter. Enfin, les opérateurs, qui peuvent être considérés comme constituant la moitié de notre modélisation, sont totalement absents de cette application.
L’intégration des variables dans SAVANT-3 est techniquement possible (bien qu’avec difficulté), mais n’apporte pas d’amélioration au système. Il est possible de faire intervenir dans un raisonnement le fait qu’une variable soit plus grande qu’une autre. Mais il est inutile de prétendre que 2 est plus grand que 3. La comparaison entre deux variables doit être effectuée par un opérateur. Le résultat de la comparaison peut être pertinent au niveau logique, mais la valeur des variables comparées ne l’est pas.
Ceci ne signifie pas que les capacités logiques humaines ne soient pas capables de manipuler des variables. La contrainte de non-ubiquité ne dépend pas de l’entité que l’on considère. Ainsi, dans notre modélisation de la tour de Hanoï, l’ensemble des règles traduisant le fait qu’un disque ne puisse se trouver simultanément à deux endroits à la fois aurait pu se traduire en une seule règle :
[[Disque X est en Piton Y, Disque X est en Piton Z, Piton Y ¹ Piton Z], []] Þ Paradoxe
Cette règle pouvant d’ailleurs s’écrire de manière encore plus générale sous la forme :
[[X est en Y, X est en Z, Y ¹ Z], []] Þ Paradoxe
Intégrer dans SAVANT-3 de tels mécanismes de gestion de variables permettrait d’obtenir des bases plus concises, mais ne réglerait pas le problème de la prise en compte des quantités au niveau logique. L’expérience nous ayant montré que les bases SAVA NT-3 contenaient relativement peu de règles, l’intégration des variables dans le module logique ne nous paraît pas nécessaire.
Le second problème que nous avons évoqué est celui de la difficulté du développement des bases de connaissances. Le processus de création est un processus artificiel. En effet, les formalismes de SAVANT-3 et de l’application cliente sont différents. L’auteur doit donc développer la base en fonction de ces deux formalismes. Le développement de l’application cliente est donc rendu plus ardu par le fait que l’auteur doit y intégrer la gestion des connaissances logiques nécessaires à SAVANT-3. Réciproquement, le développement de la base de connaissances SAVANT-3 doit prendre en compte les contraintes issues de l’application cliente.
En outre, SAVANT-3 n’étant pas capable de résoudre le problème, il ne peut critiquer de manière naturelle les choix effectués par l’apprenant que si ce dernier viole des contraintes logiques. Il devient alors nécessaire d’exprimer sous forme de paradoxes logiques les règles permettant de critiquer la qualité de la solution proposée par l’apprenant. Ainsi, si l’on veut critiquer le fait que la solution retenue n’est pas optimale, on doit intégrer une règle de la forme :
[[non (la solution est optimale)], []] Þ Paradoxe
Cette règle n’est bien sûr pas intuitive pour l’auteur. Mais, en outre, elle rendra le dialogue peu compréhensible pour l’apprenant. En effet, chaque fois qu’elle sera saturée, et donc chaque fois qu’elle jouera un rôle visible pour l’apprenant, Argumente produira la critique :
Attendez, vous m’avez dit :
La solution n’est pas optimale.
Ce qui est impossible.
Que proposez-vous ?
La solution est optimale.
Le critique exprime donc le fait qu’il est impossible d’obtenir une critique sous-optimale, ce qui est faux, et il est en outre possible de comprendre la seule réponse possible comme signifiant que la solution retenue par l’apprenant est optimale, alors qu’elle ne l’est pas. On notera enfin que SAVANT-3 n’étant pas capable de calculer de solution, la responsabilité de la vérification de la qualité de la solution incombe à l’application cliente.
En conclusion de ceci, nous constatons qu’il est difficile d’exprimer la base de connaissances permettant la critique de la résolution parce que la modélisation du critique ne correspond pas à la modélisation de la résolution de problème telle que nous l’avons proposée au cours de la deuxième partie de ce document.
De fait, l’application cliente joue ici deux rôles. Elle est d’une part en charge de la représentation de l’état du problème, non seulement dans son formalisme mais également dans celui de SAVANT-3. D’autre part, elle joue du point de vue de SAVANT-3 le rôle (ou plus exactement une partie du rôle) des opérateurs, puisque c’est elle qui est en charge des transitions de l’état du problème.
Cette confusion entre ces deux rôles est la source des problèmes que nous venons de décrire. Le rôle de l’application cliente devrait se limiter au maintien de l’état du problème, alors que les capacités de calcul et de simulation devrait être introduite dans SAVAN T-3. Si on lui offre la possibilité de résoudre le problème par lui-même, il pourra plus facilement critiquer la qualité de la résolution de l’apprenant, par exemple en proposant une meilleure solution.
Il serait alors possible d’objecter que le développement de la base de connaissances SAVANT-3 perd d’un côté ce qu’il gagne de l’autre en termes de complexité puisque il faut alors fournir, en sus des connaissances nécessaires à la critique, celles nécessaires pour résoudre le problème posé. C’est oublier que les connaissances nécessaires à la résolution sont identiques aux connaissances nécessaires à la critique. Par ailleurs, le développement de l’application cliente se trouverait facilité puisque celle-ci n’aurait plus l’obligation de calculer la solution du problème traité.
Le lecteur pourrait s’étonner du fait que l’application développée ait été basée sur une mauvaise modélisation. Notre objectif au moment de la réalisation de SAVANT-3 était bien de rendre possible le couplage entre une application intégrant des calculs ou des simulations et un module logique. Cependant, le modèle que nous défendons aujourd’hui n’était alors pas prêt. C’est d’ailleurs le relatif échec de ce développement qui nous à conduit à développer notre modèle, en précisant les problèmes que nous n’avions pas résolus à l’époque.
Rétrospectivement, le développement de la version CYBEL de SAVANT-3 nous apprend un point important : notre modèle ne peut-être utilisé partiellement. Un système critique doit être au minimum capable de résoudre les problèmes qui vont être proposés à l’apprenant, afin de pouvoir interpréter la résolution que ce dernier propose.
Il est important de noter qu’un tel système critique ne nécessite pas un modèle de l’apprenant correct ou complet. Afin de rendre la critique de la résolution possible, il suffit au système de pouvoir représenter dans son formalisme la résolution suivie par l’apprenant, sans s’intéresser au pourquoi de son erreur. La discussion Socratique qui suivra permettra en effet à l’apprenant de corriger le problème ayant conduit à une mauvaise solution.
Nous allons examiner, en conclusion de ce chapitre, les modifications qu’il conviendrait d’apporter à SAVANT-3 afin de le rendre conforme à la modélisation que nous défendons.
8.2.2 Vers un nouveau SAVANT-3
La transformation de SAVANT-3 en une version conforme à la modélisation que nous avons présentée n’est pas une tâche simple. Comme nous l’avons vu, les connaissances logiques sont toutes mémorisées sous la même forme. Par contre, les connaissances opératoires sont spécifiques, et leur forme change d’une application à l’autre. L’auteur d’une base de connaissances devra donc définir les opérateurs, et les traductions entre le module logique et l’opérateur. Il est parfois possible de définir un opérateur de manière déclarative, en décrivant exhaustivement l’ensemble des triplets :
(état courant, opération légale, état résultant)
Cependant, il n’est possible de définir un opérateur de cette manière qu’à la condition d’avoir un ensemble d’états possibles fini. Un simple opérateur d’addition ne peut être défini de cette manière. Et même quand une telle définition est possible, elle est en général très longue à effectuer. Ainsi, pour le problème de la tour de Hanoï à cinq disques, il existe 35 = 243 états distincts du problème. Dans le cas où les cinq disques sont empilés, on dispose de deux coups légaux. Dans tous les autres cas, il existe trois opérations légales. Au total, la définition exhaustive de l’ensemble des opérations possibles nécessite la définition de 726 triplets distincts. Il est difficile de demander un tel travail à une personne que l’on prétend aider à construire une base de connaissances.
Une solution alternative est de définir par un jeu de contraintes ce que l’opérateur peut réaliser à partir d’une situation donnée. Une telle modélisation prendrait la forme :
1 est en A, 2 est en A déplacement de 2 interdit.
… …
4 est en C, 5 est en C déplacement de 5 interdit.
1 est en A déplacement de 2 vers A interdit.
Les opérations légales sont alors calculées en générant l’ensemble des opérations qui ne violent pas les contraintes. Une telle modélisation nécessite encore, dans le cas de notre exemple, la définition de 60 contraintes. Là encore, la solution envisagée n’est pas acceptable.
On pourrait objecter que la définition des contraintes peut se faire en utilisant des variables, ce qui limite alors à deux le nombre de contraintes nécessaires :
X est en Y, Z est en Y, Z > X déplacement de Z interdit.
X est en Y, Z se déplace, Z > X déplacement de Z vers Y interdit.
La solution semble alors être concise, mais la déclaration des contraintes a maintenant changé de forme. Les contraintes, telles qu’elles sont définies ici, nécessitent d’effectuer des tests à l’exécution de SAVANT-3. La définition de l’opérateur n’est donc plus déclarative, mais procédurale. En d’autres termes, on définit l’opérateur en développant un programme.
Cet écueil nous paraissant incontournable, nous en prenons notre parti, et nous acceptons l'idée de devoir imposer aux auteurs des bases de connaissance de programmer les opérateurs nécessaires à la résolution des problèmes traités. Ce point permet en outre aux auteurs de définir les préférences des opérateurs s’ils le désirent.
Une fois ce choix effectué, il apparaît nécessaire de fournir aux auteurs un langage de programmation permettant de réaliser les opérateurs. Ce langage doit permettre au minimum d’exprimer comment calculer :
· La liste des opérations légales dans une situation.
· L’ordre dans lequel ces opérations légales doivent être envisagées (les préférences).
· L’évolution induite sur la situation courante par une opération sélectionnée.
Une seconde modification doit être alors apportée. Coherence, dans sa version actuelle, vérifie qu’aucune règle paradoxale n’est violée. Ce comportement doit bien sûr être conservé, mais il ne peut être étendu aux règles d’indésirabilités. En effet, dans une situation de résolution de problème, il existe toujours au moins une règle d’indésirabilité saturée. Si Coherence détecte une incohérence dans une telle situation, Argumente prendra la main dès la première action de l’apprenant pour ne la restituer que quand le problème sera résolu. Finalement, Argumente résoudra seul le problème, et ce en indiquant à chaque étape que l’apprenant s’est trompé.
Afin de résoudre ce problème, on peut envisager que Coherence demande une intervention critique soit quand une règle paradoxale est saturée, soit quand il existe une suite d’actions permettant de résoudre la problématique courante et que l’apprenant effectue une action n’appartenant pas à cette suite d’actions. Si les sous-buts calculés par Coherence ne sont pas identiques aux sous-buts de l’apprenant, celui-ci niera vouloir résoudre ce sous-but, et un dialogue Socratique pourrait alors permettre de synchroniser à nouveau les dits sous-buts.
Apprendre nécessite de faire des erreurs. Si la méthode que nous venons de décrire était appliquée, le système critique résultant, par des interventions trop fréquentes, ne permettrait pas à l’apprenant d’explorer le problème. Il conviendrait donc d’introduire un délai, exprimé en nombre d’actions autorisées pour l’apprenant, avant l’intervention du critique. Le problème de la synchronisation entre les buts de l’élève et ceux d’Argumente risque cependant alors de s’amplifier car le système, ne pouvant intervenir quand il ne suit plus l’apprenant, aura des difficultés à calculer une critique pertinente. Un compromis reste donc à trouver entre un critique trop interventionniste et un critique dépassé par les actions de l’apprenant.
