Validation des connaissances

La validation des connaissances permet de s’assurer que les connaissances contenues dans une base de cas ou un modèle sont valides (au sens présenté en sections 1.2.2.3 page 18 et 1.2.3.3 page 21). Deux raisons peuvent mener à une vérification des connaissances. Cela peut être dû à l’import de nouvelles connaissances extérieures, il s’agit alors d’utiliser les connaissances déjà contenues dans le système pour vérifier que la nouvelle connaissance ne va pas entrainer des dysfonctionnements. L’autre raison est la mise à jour des connaissances, cela signifie que l’on souhaite vérifier une connaissance que l’on estime vieillissante en la confrontant à une connaissance à laquelle on apporte plus de confiance.

Dans les deux sections à venir, nous nous placerons dans une situation extrême de confiance totale dans l’un ou l’autre des deux formalismes. Il est évident que dans la réalité, cette hypothèse forte n’est pas vérifiée. Le processus de validation de la connaissance est donc souvent un aller-retour entre la validation de la connaissance contextuelle 2.2.1.1 page suivante et la validation de la connaissance générale 2.2.1.2 page 44.

invalidation de contrainte ? Expert CSP Modèle cas à vérifier Base de cas à vérifier Base de cas valides oui non modification Rejet

Figure 2.2 : La connaissance générale permet de valider la connaissance contextuelle Cas ... cst pay ... 1 ... A France ... 2 ... A Suède ... 3 ... B Suède ... 4 ... B Tunisie ... 5 ... B France ...

Table 2.3 : Cas à confronter à la connaissance générale

2.2.1.1 Validation de la connaissance contextuelle

Dans cette partie, nous nous situons dans le cas où la confiance accordée au modèle est totale. Nous cherchons à valider ou invalider de la connaissance contextuelle.

Il s’agit, dans cette situation, de valider la totalité d’une base cas. Les cas sont alors confrontés un à un au modèle auquel on accorde confiance. Tous les cas qui respectent l’ensemble des contraintes du modèle sont alors enregistrés dans une base de cas valides. Les cas non validés par le modèle de contraintes sont soumis à un expert qui devra définir la cause de cette invalidation (erreur de saisie, capteur mal positionné, etc.) et les modifier ou les rejeter au besoin. La figure 2.2 schématise ce processus.

Dans notre exemple, il s’agit de vérifier que les cas représentés table 2.3

sont bien valides par rapport au modèle de connaissance générale décrit en section 2.1 page 36. Cette table comporte les constructeurs et pays de vol de 5 moteurs qui viennent d’être livrés. Il s’agit alors de vérifier la bonne concordance entre les cas et le modèle de contraintes.

Violation de contrainte ? Expert CSP Modèle à vérifier Base de cas Modèle validé oui non modification

Figure 2.3 : La connaissance contextuelle permet de valider la connaissance générale

En utilisant la contrainte C2 représentée en table 2.1b page 40, on remarque que les cas 1, 2 et 5 de la base de cas sont valides, alors que les cas 3 et 4 ne le sont pas. Il s’agit alors de soumettre les cas 3 et 4 à un expert afin qu’il en vérifie la cohérence. Il peut ici s’agir d’une erreur de saisie dans la colonne constructeur ou pays. Considérons que le problème du cas 3 est dû à une erreur de saisie concernant le constructeur. L’expert peut alors le modifier. L’origine du problème du cas 4 n’est quant à elle pas décelable, l’expert va alors rejeter ce cas de la base de cas exploitable par le système à base de connaissances. Exemple

À notre connaissance, il n’existe pas de travaux portant sur ce couplage.

2.2.1.2 Validation de la connaissance générale

Dans cette partie, nous nous situons dans le cas où la confiance donnée à la base de cas est totale. Nous cherchons à valider ou invalider la connaissance générale.

Il s’agit, dans cette situation, de confronter l’ensemble des cas de la base de cas aux contraintes du modèle. Si aucun cas n’entre en contradiction avec les contraintes, alors on estime que le modèle est valide. Sinon, le modèle doit être modifiée par un expert afin qu’il devienne cohérent avec l’ensemble des cas de la base de cas (modification ou suppression de contraintes). Le processus est alors réitéré.

La figure 2.3 schématise ce processus.

Considérons la contrainte C1 présentée en table 2.1a page 40 à laquelle on a retiré le premier tuple. Cela signifie que les hélicoptères blindés sont nécessairement militaires. Cette contrainte C1’ est repré- Exemple

Table 2.4 : Tables utilisées dans l’exemple de la section 2.2.1.2 page précédente (a) Contrainte C1’ bli uti Oui Militaire Non Civil

(b) Base de cas de l’exemple

Cas ... bli uti ...

1 ... Oui Militaire ...

2 ... Non Civil ...

3 ... Non Civil ...

4 ... Oui Civil ...

5 ... Oui Militaire ...

sentée en table 2.4a. On dispose d’une base de 5 cas d’hélicoptères, telle que représentée en table 2.4b. Les cas 1, 2, 3 et 5 ne violent aucunement la contrainte C1’, le cas 4 quant à lui vient en contradic- tion avec la contrainte C1’ du fait qu’il autorise le couple Blindage = Oui avec Utilisation = Civil. Cette erreur est soumise à l’expert afin qu’il fasse évoluer le modèle. Dans ce cas simple, nous voyons alors qu’il suffit d’ajouter un tuple à la table de compatibilité pour que cela fonctionne. La contrainte redevient alors telle que présentée en table 2.1a page 40.

On trouve des applications de ce type de couplage dans la littérature. Par exemple, [Felfernig et al. 2007] présente un système qui permet d’invalider des contraintes d’un CSP grâce à des cas passés.