Évaluation empirique - : Charactérisation d'une technique de diagnostic

Chapitre 3 : Charactérisation d'une technique de diagnostic

A. Évaluation empirique

Premièrement, de façon empirique, nous pouvons démontrer que plusieurs modèles de diagnostics génériques publiés dans la littérature sont des instances de la formalisation FMD. Pour chaque modèle de diagnostic générique, nous rappelons succinctement son principe, donnons l’instance de FMD et la représentation sous forme de graphe orienté pondéré de l’instance. On pourra se référer à l’état de l’art pour les détails sur chaque diagnostic.

Knowledge tracing

Le Knowledge tracing (Corbett et Anderson, 1995) représente les problèmes comme une succession d’étapes, chaque étape étant liée à une et une seule connaissance nommée Knowledge Component. Le diagnostic comportemental, nommé Outcome, est binaire et exprime si l’apprenant a fait une réponse ou une action correcte ou incorrecte à chaque étape.

- O = { Problem ; Step ; Outcome } - K = { Knowledge Component } - OtoO = { PtoS : Problem -> Step }

- OtoK = { StoK : Step -> Knowledge Component ; OtoK : Outcome -> Knowledge Component}

- KtoK = {}

- C = { C1: Card(StoK)=*->1 ; C2: Card(OtoK)=1->1 } - BD = { Outcome }

Figure 8 : Représentation graphique du modèle de diagnostic Knowledge tracing. Légende : cercle continu noir=observable, cercle pointillé rouge=connaissance, cercle continu avec fond vert=résultat du diagnostic comportemental.

Constraint-based

Le Constraint-based (Ohlsson, 1994) représente les connaissances comme des contraintes (Cr, Cs). Cr décrit les situations où la contrainte est applicable et Cs l’état du problème qui doit être obtenu si Cr est vrai. Le diagnostic comportemental est inclus dans Cr.

- O = { Problem, Cr } - K = { Cs }

- OtoO = { fPtoCr : Problem -> Cr } - OtoK = { gCrtoCs : Cr -> Cs } - KtoK = {}

- C = { C1: Card(gCrtoCs) = 1->1} - BD = { Cr }

Figure 9 : Représentation graphique du modèle de diagnostic Constraint-based. Légende : cercle continu noir=observable, cercle pointillé rouge=connaissance, cercle continu avec fond vert=résultat du diagnostic comportemental.

Control-based

Le Control-based (Minh Chieu et al., 2010) décrit les problèmes, les opérateurs que l’apprenant peut mobiliser pour résoudre chaque problème, les registres de représentations des problèmes et des opérateurs, ainsi que les connaissances, nommées contrôles, que l’apprenant doit mettre en jeu pour valider l’utilisation de chaque opérateur en fonction des problèmes et des registres. Le diagnostic comportemental est représenté par les variables de situations associées à chaque contrôle.

- O = { Problem ; Operator ; Register ; Situation Variable } - K = { Control }

- OtoO = { PtoOp : Problem -> Operator}

- OtoK = { OptoC : Operator -> Control ; RtoC : Register -> Control ; PtoC : Problem -> Control ; SVtoC : Situation Variable -> Control }

- KtoK = {} - C = {}

- BD = { Situation Variable }

Figure 10 : Représentation graphique du modèle de diagnostic Control-based. Légende : cercle continu noir=observable, cercle pointillé rouge=connaissance, cercle continu avec fond vert=résultat du diagnostic comportemental.

Item response theory

L’Item response theory (Johns et al., 2006) décrit un ensemble de connaissances dite cachées ou latentes. Chaque connaissance est associée à un ou plusieurs items (éléments observables du domaine, généralement les questions d’un exercice) indépendants. Le diagnostic comportemental est la réponse de l’apprenant à chaque item.

- O = { Item, Response } - K = { Skill }

- OtoO = { RtoI : Response -> Item } - OtoK = { ItoS : Item -> Skill } - KtoK = {}

- C = { C1: Card(ItoS)=*->1 ; C2: Card(RtoI)=1->1 } - BD = { Response }

Figure 11 : Représentation graphique du modèle de diagnostic Item response theory. Légende : cercle continu noir=observable, cercle pointillé rouge=connaissance, cercle continu avec fond vert=résultat du diagnostic comportemental.

LR-DBN et Conjunctive Knowledge tracing

LR-DBN (Xu et Mostow, 2011) et le Conjunctive Knowledge tracing (Koedinger et al., 2011) dérivent du Knowledge tracing. La différence est qu’un Knowledge Component, ici appelé Skill, peut être associé à une ou plusieurs sous-connaissances (Subskills).

- O = { Problem ; Step ; Outcome } - K = { Skill, Subskill }

- OtoO = { PtoS : Problem -> Step ; OtoS : Step -> Outcome } - OtoK = { StoK : Step -> Skill }

- KtoK = { SubtoS: Subskill -> Skill }

- C = { C1: Card(StoK)=1->1 ; C2: Card(SubtoS)=*->1 ; C3: Card(OtoS)=1->1 } - BD = { Outcome }

Figure 12 : Représentation graphique des modèles de diagnostic LR-DBN et Cnjunctive Knowledge tracing. Légende : cercle continu noir=observable, cercle pointillé

rouge=connaissance, cercle continu avec fond vert=résultat du diagnostic comportemental. B. Évaluation du champ d’application

Empiriquement, nous avons montré que la formalisation permet de représenter différents diagnostics génériques classiques dans la littérature. Toutefois, nous nous posons la question de la systématisation de ce procédé. Le problème est de pouvoir définir le champ d’application de FMD, i.e. de pouvoir répondre à la question : un diagnostic générique quelconque est-il une instance de notre formalisation ?

Pour ce faire, nous reformulons notre formalisation FMD en logique de description AL :

O ≡ ¬ K BD ⊑_O relationOtoK ⊑⊤ r relationKtoO ⊑⊤ r Kobs ≡ K ⊓ relationKtoO Ok ≡ O ⊓_relationOtoK

Avec O signifiant observables et K signifiant connaissances. Nous nommons cette formulation FMD-AL. La logique de description AL est une généralisation des réseaux sémantiques qui permet de représenter des connaissances et des concepts (Baader, 2003). Or, notre formalisation FMD est, comme nous l’avons noté, proche des réseaux sémantiques. De plus, AL permet de résoudre les problèmes de subsomption, satisfiabilité, équivalence et disjonction avec une complexité polynomiale.

Or, nous pouvons définir que l’ensemble des diagnostics génériques modélisés par notre formulation est l’ensemble des diagnostics génériques formalisés en logique descriptive qui sont subsumés par FMD-AL. Par corollaire, un diagnostic donné est une instance de la formulation FMD s’il est possible d’en donner une formalisation en logique de description qui est subsumée par FMD-AL.

5. Opérationnalisation

La formalisation que nous avons présentée plus haut, qui est en fait un graphe sémantique, peut être opérationnalisée en logique descriptive AL comme montré ci-dessus (l’inférence de AL ayant une complexité polynomiale), ou bien sous forme d’ontologie au format RDF/OWL. Nous avons retenu cette seconde option, du fait du grand nombre d’outils et de librairies qui supportent RDF/OWL.

Le vocabulaire du modèle étant déjà posé, nous donnons directement l’ontologie, formée de :

- trois classes : Observable, Knowledge et Comportement - trois relations : OtoO, OtoK, KtoK

58 <ObjectPropertyDomain> <ObjectProperty IRI="#KtoK"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="#KtoK"/> <Class IRI="#Knowledge"/> </ObjectSomeValuesFrom> </ObjectPropertyDomain> <ObjectPropertyDomain> <ObjectProperty IRI="#OtoK"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="#OtoK"/> <Class IRI="#Observable"/> </ObjectSomeValuesFrom> </ObjectPropertyDomain> <ObjectPropertyDomain> <ObjectProperty IRI="#OtoO"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="#OtoO"/> <Class IRI="#Observable"/> </ObjectSomeValuesFrom> </ObjectPropertyDomain> <ObjectPropertyRange> <ObjectProperty IRI="#KtoK"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="#KtoK"/> <Class IRI="#Knowledge"/> </ObjectSomeValuesFrom> </ObjectPropertyRange> <ObjectPropertyRange> <ObjectProperty IRI="#OtoK"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="#OtoK"/> <Class IRI="#Knowledge"/> </ObjectSomeValuesFrom> </ObjectPropertyRange> <ObjectPropertyRange> <ObjectProperty IRI="#OtoO"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="#OtoO"/> <Class IRI="#Observable"/> </ObjectSomeValuesFrom> </ObjectPropertyRange> </Ontology>

L’ontologie est composée de trois parties : premièrement la déclaration des variables, via les balises <Declaration></ Declaration>, puis la déclaration des relations d’héritage via les balises <SubClassOf></ SubClassOf>, et enfin la déclaration des relations via les balises <ObjectPropertyRange></ ObjectPropertyRange>.

L’ontologie est de plus capable de modéliser les contraintes des modèles de diagnostics sur les cardinalités des relations via plusieurs opérateurs. Soit une cardinalité c, les opérateurs sont : « il existe » (c>0), « un et un seul » (c=1), max (c<=x), min (c>=x), égal à (c=x), x étant un nombre entier.

6. Implémentation

A. Définition

Nous avons défini plus haut une technique comme l’association entre un modèle de diagnostic et une implémentation. Les sections précédentes s’attachent à définir le modèle de diagnostic, et nous allons à présent définir la notion d’implémentation.

Définition

L’implémentation d’un modèle de diagnostic consiste à transposer le modèle de diagnostic instancié au domaine dans un formalisme calculable.

Nous pouvons noter que cette définition induit une limite : toute implémentation ne permet pas d’implémenter tous les modèles de diagnostic. Prenons par exemple le modèle de diagnostic Control-based présenté plus haut : il s’agit d’un graphe qui ne peut être implémenté via un modèle de Markov caché. En effet, un modèle de Markov caché est défini comme suit :

Définition

Un modèle de Markov caché est un automate décrivant un système par le quadruplet {S, O, P, A, B} avec S l’ensemble des états de l’automate, O l’ensemble des symboles d’observations du système, pi∈P la probabilité que l’état initial de l’automate soit si , aij∈A la probabilité de transition de l’état si à sj et bjk∈B la probabilité d’observer l’observation k dans l’état j. (Baum et Petrie, 1966)

Selon cette définition, un modèle de Markov caché ne peut représenter que deux et seulement deux ensembles de variables (les états et les observations), et les relations entre ces deux ensembles. Le Control-based possède en revanche cinq ensembles de variables et des relations entre ces ensembles, donc ne peut être implémenté via un modèle de Markov caché.

La transposition d’un modèle de diagnostic vers une implémentation requiert les tâches suivantes :

- La déclaration de l’ensemble des variables - La déclaration de l’ensemble des relations

- La déclaration d’une structure d’adjacence entre les variables et les relations - La déclaration d’accesseurs pour les cardinalités des ensembles et des relations

Dans le document Assistance à la construction et à la comparaison de techniques de diagnostic des connaissances (Page 55-62)