VBBrainBox : un système expert d'ordre 0+ en VB .NET
Version 1.01 du 15/03/2015
https://codes-sources.commentcamarche.net/source/6949
Table des matières
Caractéristiques de VBBrainBox
La base de données de VBBrainBox
L'archivage
de base de données avec DBToFile
Exportation
en fichiers textes compatibles avec Turbo-Expert 1.2
Comparaison
entre les modes MDB, Texte et XML
La version
compilée VBBrainBox.mde
Le package
d'installation .msi
Le modus
ponens et le modus tollens
Chaînage
avant et chaînage arrière
Le régime
révocable et le régime irrévocable
Complexité et stratégie en régime révocable
Indécidabilité
et intelligence artificielle
Algorithmes
de moteurs d'inférence
Comparaison entre systèmes experts et réseaux de neurones
Vérification
de la base de règles
Modifications
de VBBrainBox par rapport à Turbo-Expert 1.2
Astuce pour
Turbo-Expert : utilisez la base de données VBBrainBox !
Téléchargement
du Microsoft .NET Framework
VBBrainBox est issu de Turbo-Expert 1.2 en Visual Basic 6 de Philippe LARVET (également l'auteur du mini système expert à vocation ludique dont est issu IAVB).
Un système expert (SE) est un logiciel qui, à partir d'une base de règles (BR) et d'une base de faits (BF), cherche à établir des conclusions grâce à son moteur d'inférence (MI). Le principe du MI de VBBrainBox est simplement de chercher à appliquer chaque règle une fois seulement. C'est un véritable système de programmation déclarative, où les données sont séparées du code de l'application (le MI), et traitées dans un ordre quelconque, contrairement à la programmation procédurale.
Exemple du fameux syllogisme avec Socrate (logique d'ordre 1), qui illustre le classique modus ponens :
TOUT HOMME EST MORTEL
OR SOCRATE EST UN HOMME
DONC ?
DONC SOCRATE EST MORTEL
VBBrainBox est capable de manipuler des expressions logiques d'ordre 0+, c'est-à-dire du type :
Si Distance < 2 km Alors AllerAPied.
Les variables et les règles constituent la base de connaissance (BC), laquelle représente la mémoire à long terme du SE, tandis que les sessions forment la base de faits (BF), ou la mémoire à court terme (par exemple, la session "Socrate" contient bHomme = Vrai). Voici un exemple plus compliqué de rapport d'expertise qui est généré à la fin : RapportExemple.txt (si aucune session n'est sélectionnée, un rapport sur les faits initiaux de l'ensemble des sessions peut aussi être généré).
J'ai converti le programme VB6 (inclus dans le fichier .zip sur vbfrance.com) en VB .NET et j'y ai ajouté un calcul de logique floue, du type de celui de MYCIN conçu en... 1975 !!! Selon la configuration, la logique floue ne modifie pas le déroulement du programme, on ajoute seulement un degré de fiabilité aux règles et aux faits initiaux, et on en déduit des indices de vraisemblance pour les conclusions obtenues. Il y a cependant un mode de fonctionnement plus cohérent dans lequel l'interprétation de la logique floue peut changer le déroulement de l'expertise.
J'ai aussi conçu une base de données pour simplifier la création d'application, et on peut échanger des applications en exportant des petits fichiers textes de la base.
En somme, VBBrainBox = Turbo-Expert + Logique Floue + Base de données.
Pré-requis pour les logiciels .NET : comme tout logiciel .NET, VBBrainBox requiert l'installation de la plate-forme .NET, elle est disponible gratuitement pour tous les systèmes d'exploitation Windows de bureau >= 98.
Lorsque Visual Studio .NET n'est pas installé sur la machine, MDAC 2.7 (composants d'accès aux données, version .NET) doit alors être installé pour que VBBrainBox puisse lire la base de données :
- Le principe du moteur d'inférence (MI) est de chercher à appliquer chaque règle une fois seulement. Il fonctionne en mode saturation : toute conclusion possible est déclanchée, la condition d'arrêt étant qu'il ne reste plus de conclusion à déclancher ;
- La progression du raisonnement se fait en chaînage avant (son principe est : "quelle conclusion tirer des faits ?") ;
- Le MI travaille en régime irrévocable : une fois qu'un nouveau fait est déduit, il n'y a pas de retour en arrière possible sur la règle déclanchée (système de "backtrack") ;
- Le MI est d'ordre 0+ ; dans cette version, il peut traiter des comparaisons portant sur des entiers seulement (ainsi que des dates), mais pas sur des nombres réels (décimaux) ;
- Il y a deux types de variable, les variables initiales et les variables intermédiaires. Les variables initiales permettent de décrire l'état initial d'une session (ensemble des faits initiaux), tandis que les variables intermédiaires (ou alors conclusions finales) sont déduites au cours de l'expertise grâce à l'application d'une ou plusieurs règles. Les variables intermédiaires ne peuvent être initialisées dans les sessions comme les faits initiaux, mais elles peuvent être initialisées par défaut pour toutes les sessions dans la table des variables (cette distinction sert seulement à clarifier la création d'une session) ;
- Le système gère la logique monotone et la logique non monotone, c'est configurable :
* En logique monotone, une variable définie, par défaut ou bien dans une session, ne peut pas changer de valeur : si une règle tente de changer sa valeur, un message d'erreur est affichée, invitant ou bien à ne pas initialiser cette variable, ou bien à passer en logique non monotone :
* En logique non monotone, une variable peut changer de valeur par l'application d'une règle (un message d'avertissement est toutefois affiché). Si une autre règle tente de modifier à nouveau cette variable, alors le comportement du logiciel dépend de la configuration concernant les règles contradictoires :
* Si les règles contradictoires ne sont pas autorisées, un message d'erreur est affiché ; sinon, un simple message d'avertissement est affiché, et l'expertise continue. Cependant, tous les faits déductibles ne sont pas forcément obtenus dans ce cas, voir les limitations du chaînage avant en régime irrévocable.
- Par défaut, La logique de VBBrainBox respecte l'hypothèse du monde ouvert (tout ce qu'on ne sait pas est indéfini au départ), il suffit de ne pas initialiser les variables avec des valeurs par défaut, ni dans les sessions. L'hypothèse du monde fermé (tout ce qu'on ne sait pas est faux) peut également être appliquée, il suffit de mettre des valeur par défaut, le plus souvent Faux, pour toutes les variables, ou bien d'initialiser les variables dans chaque session ;
- Pour configurer le logiciel avec le mode Logique non monotone, il faut définir Config_bLogiqueNonMonotone dans les variables, de même pour Config_bAutoriserReglesContradictoires et Config_bLogiqueFloue.
Remarques :
- Les conclusions portant sur les faits initiaux déjà vérifiés (cas où la variable est initialisée dans la session ou bien par défaut) ne sont pas affichées, et la détection d'une éventuelle contradiction ne fonctionnera pas dans ce cas. Remède : ne pas initialiser la variable. Cela n'est pas le cas en logique floue : toutes les conclusions sont affichées, afin de suivre l'évolution de la fiabilité des faits (indices de vraisemblance).
- Les noms de variable ne doivent pas contenir d'espace.
VBBrainBox possède une interface de type frontale de base de données, ce qui simplifie beaucoup l'écriture, la cohérence et la maintenance des applications (nom des variables, base de règles, sessions) : voir la rubrique suivante.
En plus de la base de données, le mode fichiers textes de Turbo-Expert est conservé (une exportation est prévue), et un 3ème mode XML sera proposé à l'avenir.
Voici le plan de la base de données :
Si vous n'avez pas Access, consultez la rubrique Logiciel Runtime Access. Sinon vous pouvez aussi éditer la base de données directement depuis Visual Studio .NET, grâce à l'explorateur de serveur (créez une nouvelle connexion MS.Jet.OLEBD.4.0 : Password="", User ID=Admin). Mais ce n'est pas pratique, car vous n'avez pas accès aux formulaires Access : ils contiennent un peu de code pour que la saisie respecte la logique "métier" afin de rendre la création d'une application simplissime. Je n'ai pas encore fait de formulaire sous .NET, car après tout, le runtime d'Access est gratuit, il n'y a pas de franche urgence ! (vous avez cependant tous les éléments en main...)
L'utilisation de la base de données est simple, commencez par regarder comment sont faites les applications fournies d'origine avant d'en modifier une ou d'en créer de nouvelles. Une fois que vous serez parvenu à créer vos propres applications d'expertise, vous voudrez peut-être les partager avec les autres utilisateurs de VBBrainBox, n'est-ce pas ?
Plutôt que d'échanger le fichier de base de données VBBrainBox.mdb en entier, j'ai prévu un système d'échange de fichier d'application de VBBrainBox. Les applications peuvent être exportées puis importées de la base de données, sous forme de petits fichiers textes qui respectent les contraintes d'intégrité référentielle de la base, lorsqu'ils sont chargés grâce à l'utilitaire DBToFile. Il suffit de choisir un nom unique pour votre application.
Pour installer cette option, il faut d'abord télécharger l'utilitaire DBToFile, spécialement configuré pour VBBrainBox (ou sinon utiliser la version packagée) :
http://patrice.dargenton.free.fr/ia/vbbrainbox/dbtofile.zip (159 Ko)
Il suffit ensuite de décompresser ce fichier dans le répertoire \Applications, puis de cliquer sur le bouton Archivage du logiciel. Pour ceux qui veulent en savoir plus sur cet utilitaire DBTofile, l'archiveur générique de base de données Access, une description technique complète est disponible ici (DBToFile a légèrement évolué depuis cette documentation) :
http://patrice.dargenton.free.fr/dbtofile/index.html
Et voici le rapport de base de données de VBBrainBox.mdb généré par DBToFile :
Une utilisation possible et pratique du système d'archivage consiste à faire une copie d'une application, pour tester l'effet du changement d'une règle par exemple. Pour cela, archiver une application, puis renommer cette application dans la base de donnée VBBrainBox.mdb. Ensuite, il suffit de recharger l'application archivée (ce sont les étapes 1 et 3 de la démo de l'archivage) : elle est maintenant présente en deux exemplaires distincts.
Sélectionnez une application dans l'onglet base de données, puis cliquez sur le bouton Exporter : trois fichiers sont alors créés (<application>.dic, ~.brg et ~.bfa) pour faire une expertise avec Turbo-Expert 1.21, ou bien avec Turbo-Expert 1.2 en renommant le fichier <application>.dic en DicoVar.txt.
Cette exportation est à peu près équivalente à ce que fait DBToFile, sauf que dans ce dernier cas, le fichier n'est pas destiné à être édité ou expertisé directement, mais à être réincorporé dans une base de donnée VBBrainBox.mdb : il respecte les contraintes d'intégrité référentielle (je ne pense pas que l'on puisse faire la même chose via une procédure merge avec des fichiers xml, car la logique de fusion des données est une véritable programmation SQL déclarée dans DBToFile.mdb).
XML est naturellement le format dédié à l'échange de données. Je suivrai donc l'évolution du projet RuleML, qui concerne l'échange de donnée pour les systèmes experts, mais qui possède semble-t-il une portée beaucoup plus générale et est en cours de développement, voici la page d'accueil de RuleML :
Propriétés / mode : |
VBBrainBox.MDB |
Texte (.dic, .brg et .bfa) |
XML (à venir) |
Mode d'édition |
Access XP ou 2000 ou Runtime Access 2000 (XP ?) |
Bloc-notes |
Bloc-notes ou éditeur XML |
Maintenance |
Facile |
Difficile |
Assez difficile |
Intégrité référentielle |
Oui (on ne peut pas concevoir d'incohérence dans le vocabulaire) |
Non (il faut vérifier manuellement la cohérence des règles et des faits avec le dictionnaire, ne serait-ce que pour renommer une variable, par exemple. De plus, il faut choisir 3 fichiers compatibles) |
Possible ? (peut être en validant le document XML selon son schéma DTD) |
Mise à jour partielle d'une application (fusion) |
Oui |
Non, remplacement complet |
Possible ? |
Exportation |
Oui : en fichiers textes |
Non |
à faire |
Utilisation de constantes pour faciliter la maintenance des règles |
Oui |
Oui, mais ce n'est pas pratique |
à faire |
Format standard |
Format standard de type Access (2000) |
Non, format propriétaire (il faut connaître ce format pour modifier les fichiers) |
Format standard de type XML, il suffit de respecter le schéma DTD de l'application XML |
Logique floue |
Oui |
Non |
à faire |
Valeur par défaut pour les variables (pour toutes les sessions) |
Oui |
Non, il faut initialiser chaque variable initiale de chaque session |
à faire |
Bilan des 3 modes possibles : |
Pratique mais requiert Access (ou son runtime, qui est gratuit) |
Peu pratique, mais les applications sont modifiables avec le bloc-notes (Turbo-Expert en VB6 ne fonctionne qu'avec ce mode) |
Format standard (utile pour partager des applications, à supposer qu'il existe un schéma adéquat), mais verbeux ; à faire |
Bon, si vous n'avez que VB6, ou bien si vous voulez travaillez qu'avec Turbo-Expert, vous pouvez quand même utiliser la base de données de VBBrainBox, il y a une astuce !
Pour ceux qui n'ont pas Access et qui veulent utiliser la base de données de VBBrainBox, pour modifier les données ou créer de nouvelles applications, il existe une version compilée en .mde Access 2000 (donc sans les sources), car le runtime d'Access 2000 ne marche probablement pas avec la version .mdb. Cette version .mde est identique, excepté le fait que les boutons de bascule des sous-formulaires en mode feuille de données ou en mode formulaire ne sont pas disponibles, car je crois que la commande correspondante du menu n'est apparue qu'avec Access XP ; et pour le moment, le runtime d'Access 2000 est plus facile à trouver sur le web que celui d'XP. Cette version VBBrainBox.mde (renommée en .mdb) peut être téléchargée ici :
http://patrice.dargenton.free.fr/ia/vbbrainbox/vbbrainboxmde2000.zip (120 Ko)
Sinon, elle est également incluse dans le package d'installation :
Il regroupe et configure toutes les options (sauf le runtime Access et la plate-forme .NET). Il contient VBBrainBox.exe + VBBrainBox.mde (renommé en .mdb) + DBToFile.ocx + les sources en VB .NET et est disponible ici :
http://patrice.dargenton.free.fr/ia/vbbrainbox/vbbrainboxinst.msi (793 Ko)
Le runtime d'Access 2000 (l'équivalent pour Access de la visionneuse PowerPoint ou Word, mais avec la possibilité de modifier ou ajouter des données stockées dans la base), est disponible gratuitement ici :
http://ors1.chez.tiscali.fr/a2krt/index.html (36 Mo)
Pour situer un peu VBBrainBox parmi les SE existants, voici un petit rappel de Logique, suivi d'une présentation des moteurs d'inférence.
- Logique d'ordre 0 : c'est la logique des propositions.
Par exemple, Distance=384_km représente un et un seul mot insécable.
- Logique d'ordre 0+ : elle contient des opérateurs de comparaison (>, <, =, >=, <= et <> dans VBBrainBox), des valeurs comparables, des constantes (par exemple, la constante Distance peut être assignée à la valeur 384 km).
- Logique d'ordre 1 : c'est la logique du calcul des prédicats.
Définition du prédicat : Expression logique dont la valeur peut être vraie ou fausse selon la valeur des arguments, c'est-à-dire une fonction qui renvoie "vrai" ou "faux".
La logique d'ordre 1 contient :
* des variables substituables = variables d'individu,
* des quantificateurs : Pour tout, Quelque soit, ...
Exemples :
- Tout homme est mortel : homme(x) -> mortel(x) pour tout x ;
- Quelque soit x, d(x) < 2 km implique aller_à_pied(x) ;
- On peut aussi utiliser des fonctions : inférieure(distance(x), 2 km) implique aller_à_pied(x).
En logique d'ordre 1, on doit choisir des instances pour les variables substituables : le x de distance(x).
Pour pouvoir programmer l'exemple du syllogisme de Socrate avec VBBrainBox, on doit descendre en logique d'ordre 0+ en définissant une session "Socrate", dans laquelle bHomme est Vrai, avec la règle Si bHomme Alors bMortel.
- Logique d'ordre 2 : c'est la logique des variables de prédicats.
Elle permet d'écrire des méta-règles, c'est-à-dire des règles portant sur des règles.
* Exemple de méta-règle n°1 : Si R1 est plus spécifique que R2, appliquer R1.
* Exemple de méta-règle n°2 : la relation de transitivité :
Quelque soit R {Quelque soit x, y, z (R(x, y) et R(y, z)) implique R(x, z)} implique Transitive(R).
Variable de prédicat : ici, on instancie une règle par une relation.
Limitations : voir les méta-systèmes.
- Hypothèse du monde fermé : tout ce qu'on ne sait pas est faux (les règles peuvent être appliquées en conséquence) ;
- Hypothèse du monde ouvert : tout ce qu'on ne sait pas est indéfini au départ (les règles portant sur des prémisses de valeur indéfinie ne peuvent pas être appliquées tant que cette valeur reste indéfinie).
- Logique bivaluée : oui, non (hypothèse du monde fermé) ;
- Logique trivaluée : oui, non, indéfini (hypothèse du monde ouvert) ;
- Logique multivaluée : vrai, probable, indéfini, improbable, faux ;
- Logique continue : [0, 1] ou [-1, 1] ;
- Logique monotone : si la variable A a une valeur, c'est définitif (elle ne peut plus en changer) ;
- Logique non monotone : une variable peut changer de valeur ; par exemple imaginons le programme d'un robot cuisinier : casserole_pleine et vider_casserole implique non casserole_pleine ;
- Logique modale : elle est utilisée pour décrire le comportement des systèmes qui sont donnés comme des relations de transition d'états (donc c'est une logique non monotone) ;
- Logique temporelle : une variable peut être vraie pendant un certain laps de temps, par exemple : faire_cuire(oeuf) pendant 3 mn ;
- Logique floue : voir le paragraphe suivant :
Définition : la logique floue peut être considérée comme une interprétation pseudo-probabiliste de la logique continue.
C'est la meilleure formule du genre : elle permet de retrouver une cause potentielle à un effet, ce qui est très utile en diagnostique. Cependant elle requiert la connaissance exhaustive des probabilités conditionnelles, ce qui est rare en pratique. Dans le fond, une bonne part de l'expertise humaine réside dans la connaissance intuitive par assimilation statistique de ces probabilités, un bon gage de la mesure du risque lié à la décision en quelque sorte. Par exemple, la maîtrise des langues réside beaucoup dans le fait de savoir rapidement, lorsque l'on s'apprête à dire quelque chose dans une situation donnée, qu'il n'y a pas de meilleures façons de s'exprimer.
Documentation :
www.maths-express.com/maths-express/BAC-EXO/BAC-S/cour-S/cours-proba/bayes.htm
www.sciences-en-ligne.com/momo/chronomath/chrono1/Bayes.html
MYCIN est un des premiers systèmes experts à mettre en oeuvre de la logique floue ; il fut utilisé pour le diagnostic médical de façon opérationnel dès 1975, documentation en français :
www.cert.fr/fr/dcsd/PUB/THESES/fabiani/manuscrit_fabiani/node334.html
www.computing.surrey.ac.uk/research/ai/PROFILE/mycin.html (documentation complète en anglais)
L'abréviation fiab vaux pour fiabilité, c'est une sorte d'indice ou coefficient de vraisemblance :
- Une fiabilité de 0.1 correspond à : "il se peut", 0.9 : "presque sûr", 0.6 : "probable" ;
- Si la fiabilité est nulle, c'est une rumeur par excellence, une rumeur sans aucun fondement, qui a autant de chance d'être juste que fausse, une pure hypothèse en quelque sorte ;
- Si la fiabilité devient négative (voir le paragraphe suivant), c'est une intox, un "hoax", un mensonge, un résultat douteux... ;
- Si la fiabilité est inférieure à 0.2 à la fin de l'expertise, alors c'est une conclusion peu crédible.
Dans le logiciel, la logique floue est calculée en parallèle avec la logique d'ordre 0+ ; par défaut, ce calcul ne change en rien le déroulement d'une expertise, excepté le fait qu'en logique floue, on affiche toutes les conclusions, même celles portant sur des faits déjà établis afin de préciser la mise à jour de leur fiabilité.
Lorsqu'un fait reçoit plusieurs fiabilités, du fait du déclenchement de plusieurs règles successives, les fiabilités sont combinées (voir plus bas les formules associatives). Cependant, pour que ce système de combinaison soit cohérent, il faut bien sûr interpréter que Faux est le contraire de Vrai : un fait de type booléen qui vaut "Faux" avec une fiabilité de 0.5 est équivalent à "Vrai" avec une fiabilité de -0.5. Mais alors cela signifie que tout le déroulement de l'expertise peut changer, la logique floue n'est plus calculée en parallèle de l'expertise mais elle y est totalement intégrée. L'activation de ce mécanisme est configurable grâce à la variable Config_bLogiqueFloueInterpretee qu'il faut déclarer dans les variables initiales ou bien éventuellement dans une session. Cela fonctionne bien pour les booléens, mais pour les autres types de données, il faudra aller plus loin.
Note : la fiabilité est toujours positive au départ de l'expertise (c'est imposé dans la saisie du champ dans les tables de VBBrainBox.mdb). Seuls les booléens peuvent être inversés en cas de fiabilité négative issue d'une combinaison, et dans ce cas, la fiabilité redevient positive. Pour l'examen des prémisses de règle, on a donc toujours des fiabilités positives. Si la logique floue n'est pas interprétée, les fiabilités peuvent être négatives, mais le déroulement de l'expertise sera inchangé en ce qui concerne la valeur des faits (ce qui peut conduire à un véritable raisonnement par l'absurde !).
Formule de MYCIN :
Si on déduit un fait par une règle de fiabilité R à partir des faits de fiabilité Fi alors la fiabilité F de ce nouveau fait est le produit de R par le min. des Fi (en valeur absolue) :
F = R * Min(Abs(Fi))
Formules associatives de MYCIN :
Si un fait reçoit plusieurs fiabilités (rAncienneFiabilité et rNouvelleFiabilité), on les combine :
Si rAncFiab >= 0 et rNouvFiab >= 0 Alors
rFiab = rAncFiab + rNouvFiab - rAncFiab * rNouvFiab
Sinon si rAncFiab < 0 et rNouvFiab < 0 Alors
Note : ce cas ne se produit pas car fiab. règle >= 0 et min. fiab. >= 0 donc rNouvFiab >= 0
rFiab = rAncFiab + rNouvFiab + rAncFiab * rNouvFiab
Sinon
rFiab = (rAncFiab + rNouvFiab) / (1 - Min(Abs(rAncFiab), Abs(rNouvFiab)))
Fin de Si
Pour comprendre comment saisir une règle, inspirez vous de celles déjà programmées dans la base de données VBBrainBox.mdb.
- Pour faire un "ou" dans les hypothèses, il suffit d'écrire deux règles distinctes ;
- Si on a besoin d'écrire des règles plus complexes, avec des parenthèses, on peut définir des variables intermédiaires ;
- Il y a la possibilité d'utiliser plusieurs fois la même variable dans une règle, par exemple pour indiquer durée > 4 et durée < 8. Dans ce cas, il faut incrémenter le compteur CompteurOccVar du nombre d'occurrences d'une variable dans les prémisses d'une règle (ce compteur garanti l'unicité d'une prémisse dans le cas de mise à jour de règle lors d'un échange de fichier d'application).
Les faits ou les règles ?
En logique d'ordre 1, on peut toujours écrire un fait sous forme d'une règle et vice-versa :
Fait : Le fer est un métal
Règle : si X est en fer alors X est en métal
Cela a un lien avec le parallèle établi entre réseau de neurones (RN) et SE : d'une manière générale, il y a une certaine complémentarité entre une BR et un ensemble de BF (sessions), cf. RN/SE.
- Modus ponens : si A et (A implique B) alors B (par exemple, Socrate est un homme, donc Mortel) ;
- Modus tollens : si non B et (A implique B) alors non A (par exemple, du fait que Zeus est immortel alors Zeus n'est pas un homme, car sinon on l'aurait déduit mortel).
Le moteur d'inférence (MI, ou système de contrôle) cherche à appliquer les règles et à déduire de nouveaux faits dans la base de connaissance (BC), ou sinon à vérifier si un fait peut être déduit d'une BC.
- Chaînage avant (on dit également raisonnement guidée par les données) : chaque étape consiste à établir de nouveaux faits à partir des faits connus. On se pose la question : quelle conclusion tirer des faits ?
Le principe est : Pour toute règle, examiner les prémisses : dès qu'une règle est déclanchée, le fait est ajouté à la BF, la règle est retirée de la BR (ce qui garanti l'absence de boucle infinie) et on recommence.
L'inconvénient du chaînage avant, surtout en logique non monotone, c'est qu'il est facilement explosif (en ce qui concerne le nombre de faits déduits), même avec une petite base. Si, au lieu de chercher à prouver un maximum de choses, on cherche plutôt à répondre à une question précise, alors le chaînage arrière est plus indiqué :
- Chaînage arrière (on dit également raisonnement guidé par les buts) :
On part d'un objectif, par exemple dans le diagnostique : quels sont les faits ayant produits ces symptômes ? autrement dit, quel est la maladie caractérisée par ces symptômes ? (l'identification de la maladie permettra d'établir un traitement du patient).
Au lieu de chercher les règles qui peuvent s'appliquer, on part d'un but fixé, et on cherche à savoir comment ce but pourrait être atteint, en recherchant les règles dont ce but figure en conclusion. Chaque étape consiste alors à remplacer un but cherché par une conjonction ou une disjonction de sous-buts (oui, c'est sensiblement plus compliqué que le chaînage avant).
Le chaînage arrière n'a de sens que si l'on connaît le but, il peut s'appliquer en principe à tous les ensembles de buts finis. Lorsque l'ensemble des résultats est infini, on ne peut pas connaître le but. Par exemple, pour le calcul formel d'intégrales, l'ensemble des résultats d'intégrales est infinis.
- Chaînage mixte : c'est une combinaison du chaînage avant et arrière : pour se rapprocher d'un but, on peut générer dans un premier temps des hypothèses grâce au chaînage avant, et ensuite chacune de ces hypothèses constitueront des sous-buts à prouver en chaînage arrière.
Le chaînage arrière ou mixte concerne les systèmes à régime révocable :
Régime révocable : possibilité de revenir sur la valeur des faits, pour permettre le chaînage arrière. On doit pouvoir maintenir un arbre des états dépendant de l'ordre des règles appliquées. La recherche peut s'orientée en largeur ou bien en profondeur, selon que l'on considère l'ensemble des règles qui peuvent s'appliquées à un moment donnée, ou sinon, l'ensemble des règles que l'on peut appliquer successivement depuis une situation donnée.
Régime irrévocable : les faits obtenus changent l'état courant de manière définitive, il n'y a pas de retour en arrière possible (système de "backtrack"). Chaque règle ne peut s'appliquer qu'une seule fois. En conséquence, les concepts de recherche en largeur ou en profondeur ne sont pas pertinents dans ce régime, car on ne stocke pas l'espace de recherche, seulement l'état courant de la base de faits. Le régime irrévocable convient dans le cas où la plupart des chemins mènent à la solution (c'est le cas de la logique monotone), ce qui est rare : en pratique, on a souvent affaire à des systèmes qui doivent être modélisé en logique non monotone, notamment en présence des cas suivant (tous les 2 en logique d'ordre 1) :
- Cas où il existe des transitions non permutables (paires critiques) :
Par exemple la règle R1 indique que : Sin(u) Cos(u) -> (Sin(2u))/2
et la règle R2 : Log(uv) -> Log(u) + Log(v)
Si on veut traiter Log(Sin(x) Cos(x)), on peut appliquer R1 : Log((Sin(2x))/2) puis R2 : Log(1/2) + Log(Sin(2x))
Mais si on applique d'abord R2 : Log(Sin(x) Cos(x)) : Log(Sin(x)) + Log(Cos(x)) alors R1 n'est plus applicable.
R1 et R2 forment une paire critique car elles sont toutes les deux applicables mais dans un ordre seulement.
- Cas où il existe des transitions irréversibles : une fois la valeur du fait changé, on ne peut revenir en arrière : par exemple, vider la casserole pour un robot cuisinier.
Le chaînage avant en régime irrévocable utilisé dans VBBrainBox (en logique non monotone) peut donc être insuffisant pour trouver tous les faits déductibles dans ces deux cas de figure (même en logique d'ordre 0+ seulement).
Le principe du modus tollens avec le chaînage mixte permet d'augmenter sensiblement la puissance du SE ; cependant, il faut voir ce que l'on perd en contre partie de chaque propriété : en logique non monotone, on perd la certitude de trouver tous les faits déductibles en simple chaînage avant, tandis qu'en chaînage arrière ou mixte, du fait de l'augmentation de la complexité, on perd la certitude de terminer l'expertise en temps fini et ce, quelque soit l'ordre de la logique (voir www710.univ-lyon1.fr/~fouet/DEA/chap2.html#2.3.4). Cela nous amène à aborder la question de la complexité des moteurs d'inférence en général, ce qui sera utile lorsque j'aurai l'opportunité de faire une version plus puissante de VBBrainBox.
Cette partie ne concerne pas cette version 1.0 de VBBrainBox, qui risque de ne pas trouver tous les faits déductibles en logique non monotone, son MI étant limité au simple chaînage avant en régime irrévocable. C'est pour cette raison que VBBrainBox est assez simple. Pour aller plus loin, on s'expose en contre partie à des problèmes de complexité qui sont l'apanage des SE qui travaillent en régime révocable. Je vais maintenant tenter d'expliquer cela en évitant d'être trop réducteur.
La complexité d'un problème est l'ordre de grandeur de la complexité du meilleur algorithme connu pour le résoudre. Elle se mesure avec la notation O(combinatoire de l'algorithme).
Exemples de complexités d'algorithme :
- Somme de 1 à n : algorithme de complexité en O(n), car il y a une boucle jusqu'à n ;
- n*(n+1)/2 : complexité en O(1) : une seule instruction, alors que le résultat est le même que le précédent !
- Trie d'un vecteur : l'algorithme le plus simple (2 boucles imbriquées) est de complexité : O(n2), tandis que la complexité du problème est en O(n Log n), ce qui correspond au meilleur algorithme possible ;
- Jeu d'échecs = l'algorithme de base est de complexité O(2n), c'est donc un algo. de complexité exponentielle ;
- Problème du voyageur de commerce : c'est un problème NP-complet : il n'existe pas d'algo. pour le résoudre en temps polynomial. Concrètement, cela veut dire que lorsque le nombre de ville augmente, ça explose ! le temps de calcul devient rédhibitoire. Cependant, certains réseaux de neurones, du type Machine de Boltzmann selon la technique du "recuit simulé", sont capables de trouver des solutions, certes non optimales, mais rapidement compte tenu de la complexité du problème (il faut aussi considérer les ordinateurs optiques ou quantiques, qui peuvent réaliser instantanément des opérations sur des matrices, qui sont connues pour être complexes en algorithmie standard ; cependant, ce type d'ordinateur reste encore largement du domaine théorique). En fait, les réseaux de neurones n'appartiennent pas à la catégorie des algorithmes de type procéduraux proprement dit (je ne sais pas si la complexité est bien définie dans ce cas). Voir les explications du cours de DEA de Lyon 1 :
www710.univ-lyon1.fr/~fouet/DEA/chap1.html#1.1
- SE : déterminer si une expression logique peut être vérifiée à partir d'une BF en appliquant une BR :
L'arbre "de recherche" contient l'ensemble des solutions possibles, une branche de cet arbre représente une éventuelle solution. Chaque noeud de l'arbre correspond à un point de choix pour une variable. Il faut bien faire la distinction entre parcourir l'arbre, qui est une procédure exponentielle, et vérifier une expression logique dans cet arbre de solutions : est-ce que l'on pourra déduire de la BF que la valeur de telle variable sera vérifiée (par exemple vérifier qu'un booléen est à vrai ou alors faux, ou bien vérifier qu'une variable vaux telle valeur), c'est ce qu'on appelle la "satisfaisabilité" d'une expression logique : c'est un problème NP-Complet.
En fonction de la complexité des algorithmes pour les résoudre, on classe donc les problèmes de la façon suivante :
- Les problème de classe P
La classe P ("Polynomial time") contient tous les problèmes relativement faciles, c’est-à-dire ceux pour lesquels on connaît des algorithmes efficaces. Plus formellement, ce sont les problèmes pour lesquels on peut construire une machine déterministe (une machine de Turing) dont le temps d’exécution est de complexité polynomiale : O(n2), O(n3), ... (un polynôme étant une fonction de la forme f(x) = anxn + an-1xn-1... avec les an réels et n le degré du polynôme).
- Les problème de classe E
La classe E ("Exponential time") contient les problèmes très combinatoires, qui impliquent des algo. de complexité exponentielle (tels que les échecs) : O(en).
- Les problèmes de classe NP :
Les problèmes de la classe NP ("Nondeterministic Polynomial time") sont ceux pour lesquels on peut construire une machine de Turing non déterministe dont le temps d’exécution est de complexité polynomiale.
En gros, tout ce qui est calculable automatiquement peut être ramené à une machine de Turing. Pour comprendre ce concept de déterminisme, s'il y a plusieurs choix à chaque étape (choix du nouvel état, du déplacement de la tête, de la donnée écrite, pour une même donnée lue), la machine de Turing est dite non-déterministe. S'il n'y a qu'un seul choix, elle est dite déterministe. Les machines non déterministes sont des machines purement abstraites qui, par définition, choisissent toujours la meilleure séquence d'instructions qui mène à la bonne réponse lorsque celle-ci existe. Il s'agit d'un concept certes théorique mais utile à la NP-Complétude (voir ci dessous) dont l'enjeu est important en IA au sens large.
La classe P est incluse dans la classe NP, car si l’on peut construire une machine déterministe pour résoudre efficacement un problème, on peut certainement en construire une non déterministe qui résout aussi efficacement le même problème.
- Les problèmes NP-Complet :
La classe NP-Complet est une sous-classe des problèmes NP. Un problème est NP-Complet quand tous les problèmes appartenant à NP lui sont réductibles. Si l’on trouve un jour un algorithme de complexité polynomiale pour un seul de ces problèmes vraiment difficiles que sont les problèmes NP-complet, alors d’un seul coup NP devient égal à P et tous les problèmes difficiles deviennent faciles ! Un problème NP-complet est donc complet en ce sens qu’il contient l’essentiel de la complexité des problèmes appartenant à NP.
Documentation : Introduction à la NP-complétude :
http://19968.gel.ulaval.ca/notes/NP-completude.pdf
Les SE ne sont pas des systèmes formels (SF) à proprement parler, car ceux-ci suivent une définition précise :
www710.univ-lyon1.fr/~fouet/DEA/chap2.html (voir aussi les sections suivantes à ce lien pour en savoir plus sur l'interprétation d'un SF, pour savoir comment faire un SE avec un SF : systèmes à règles de production ou système de ré-écriture, avec des exemples de tels SE d'ordre 0 et d'ordre 1)
Cependant les SF modélisent le fonctionnement des SE, ce qui permet d'en comprendre les limites en terme de complexité et de décidabilité, ce qui nous amène aux méta-systèmes.
Si le niveau tactique consiste par exemple à déterminer quelle prémisse évaluer en premier, le niveau stratégique s'occupe de déterminer quelle règle ou méta-règle choisir, et le problème de la stratégie peut être traité dans un méta-système expert. Mais une méta-règle peut aussi bien s'appliquer à une règle qu'à une méta-règle. Jusqu'où on peut aller comme ça ? Il faut faire attention à l'instanciation des variables de prédicat : si on veut manipuler les méta-règles du SE par les méta-règles elles-mêmes, on risque l'indécidabilité liée au théorème de Gödel :
Interprétation du théorème de Gödel (1933) : Tout système qui est son propre méta-système contient des propositions indécidables (il existe alors au moins un énoncé E tel que E est un théorème et non E aussi). Exemples :
"Cette phrase contient quatre fois la consonne C"
"Celle-ci contient cinq fois la consonne C" (non "six", heu... non "cinq", non "six"... : indécidable)
Le langage écrit ou oral est son propre méta-système, de même, l'arithmétique formelle est son propre méta-système. Ces méta-systèmes contiennent donc des propositions indécidables.
Exemple de la conjecture de Fermat : il existe A, B, C et n > 2 tels que An + Bn = Cn : ce n'est pas un théorème, c'est cependant vrai pour tous ceux que l'on a vérifié ; mais ce n'est pas un non-théorème non plus car l'arithmétique formelle est indécidable.
Un exemple de méta-règle indécidable pourrait être : "Ne pas appliquer les règles dont l'auteur est le même que le mien", ce qui ressemble au fameux : "Je suis un menteur".
Plus généralement, la décidabilité des problèmes est définie de la façon suivante :
- S'il existe une procédure de décision, c'est-à-dire un algorithme qui, en temps fini, répond à toute question, le problème est décidable ;
- S'il existe un algorithme qui répond oui en temps fini : le problème est semi-décidable (voir www710.univ-lyon1.fr/~fouet/DEA/chap1.html#2.1.3) ;
- Système indécidable : on ne peut dire ni oui ni non en temps fini. Ce genre de problème constitue en soit une cinquième classe de problème, les plus difficiles de tous (ils n'appartiennent pas à la classe NP).
Remarque : Tous les systèmes formels intéressants sont indécidables !
Si l'informatique concerne surtout les problèmes polynomiaux en général, l'intelligence artificielle (IA) concerne avant tout les problèmes non polynomiaux que des humains savent résoudre. On a souvent tendance à n'inclure dans l'IA seulement des algorithmes capables d'obtenir des performances supérieures (en temps de calculs, mais avec éventuellement des solutions approchées) aux meilleurs algorithmes connus pour ces problèmes (qui trouvent des solutions exactes, mais souvent avec des temps rédhibitoires). On pense notamment aux réseaux de neurones ainsi qu'à d'autres types d'algo. de l'IA : fourmis, algo. génétique...
On peut cependant surmonter l'interminable débat sur la définition de l'IA en se basant sur une des définitions les plus larges de l'intelligence : "Possibilité de faire des choix meilleurs que des choix aléatoires", de laquelle en découle simplement une définition pratique et imparable de l'IA : est-ce que mon logiciel fait mieux que le hasard ?
Bon, si vous êtes arrivés à lire cette doc théorique jusqu'à ce stade, vous serez peut être intéressé par quelques algos de moteurs d'inférence, notamment en régime révocable, que j'ai récupéré dans mes cours d'IA :
VBBrainBox ne contient pas encore d'applications vraiment intéressantes et complètes, mais si vous avez de bonnes idées d'application, vos réalisations seront partageables entre les utilisateurs. Alors n'hésitez pas à m'envoyer les vôtres.
Je n'ai pas beaucoup d'application mais j'ai quand même réalisé un truc assez délirant, mon plus sérieux fumage de moquette à ce jour (et croyez moi, ce n'est pas peu dire :-). Bien sûr, pour le moment, il ne s'agit que d'une ébauche, la version actuelle (0.5) est sans nul doute sujette à caution, alors ne prenez pas ses résultats au pied de la lettre. Seulement à partir de la version 1.0, cette application sera totalement fiable et vous pourrez alors vous en y remettre en toute confiance.
Venons en au fait, cette application va vous permettre de faire des expertises en épistémologie des sciences, c'est-à-dire estimer ce qui relève d'une démarche scientifique, ou bien sinon de ce que j'appelle une pipeaulogie, à savoir une théorie communément admise dans le milieu scientifique, théorie que l'on a oublié de prouver !
Prenez un exemple de troll le plus banal possible : vous apprenez sur le net que les vaches sont des extra-terrestres : info ou intox ? jusqu'à présent, vous auriez tout naturellement pris pour argent comptant cette info sans présumer qu'elle puisse être une intox. Hé bien après une expertise VBBrainBox en épistémologie des sciences, vous en arrivez à la conclusion logique que cette info provient d'un troll (un petit plaisantin, ou plaisanterie selon les cas) simplement en répondant à un petit nombre de questions pratiques au sujet de cette théorie : Commencez par vous demander si cette nouvelle théorie est prouvable. Après information, vous trouvez que : "Non, car les E.T. ont un système empêchant leur détection". Hou la la attention ! c'est typiquement un argument de type Blurg (Baliverne Lamentable à l'Usage Réservé des Gogos selon la définition de Science & Vie. Est-ce que cette théorie est réfutable (y a-t-il un moyen de la vérifier : confirmer ou infirmer ?) : "Non, car les E.T. se comportent en tout point comme des vaches !" (même si on cherchait à disséquer une vache E.T., on ne trouverait rien).
Une fois les informations complétées au sujet de cette théorie, l'expertise donne principalement :
Selon la règle Intox (0.7) : (min. fiab. faits : 0.7 : minimum de fiabilité des faits requis pour l'application de cette règle) :
si bRéfutable = "FAUX" (0.9)
et bThéorieCohérente = "FAUX"
et Fiabilité < 30 (0.7)
alors bIntox = "VRAI" (0.49)
Remarque : fiabilité 0.7 de la Fiabilité = méta-connaissance sur la fiabilité = méta-méta-connaissance !
On obtient également le fait qu'il s'agit probablement d'un Blurg, que cela reste une pure théorie, et qu'elle est peu vraisemblable. Bon, c'est sûr que c'est un peu trivial comme déduction dans ce cas, mais il existe d'autres théories bien plus difficiles à classer comme plaisanterie, et qui pourtant ne possèdent pas plus d'arguments en leur faveur que celle-ci !
Inversement, plusieurs théories taboues voire carrément "maudites" en sciences s'avèrent indiscutablement inclues dans le domaine d'investigation scientifique. Pourquoi ? non seulement elles sont prouvables, mais elles sont surtout réfutables : prouvables fausses (quoique peu vraisemblable quand même :-), voir le rapport sur l'astrologie : RapportAstrologie.txt
Il existe également des projets liés à des théories qui ne pourront jamais être réfutées : la recherche de signaux E.T. (projet SETI) : on pourra toujours justifier que la recherche doit être poursuivie, il n'existe pas d'arguments objectifs pour démontrer son impossibilité, c'est un peu comme par exemple rechercher des suites logiques dans la succession des tirages de la loterie nationale ; mais cela ne veut pas dire que ces théories soit fausses, elles sont simplement en marge de la démarche scientifique (car irréfutables), mais par contre, en plein dans la démarche philosophique ! Certaines théories ne sont prouvables que par expériences individuelles, et probablement pas partageables collectivement ! Existe-t-il alors une science personnelle ? (ou plutôt : comment assimiler scientifiquement son expérience perso. ?)
Il y a des liens entre ces théories : par exemple, si on réfute la théorie de l'Evolution - créatrice de nouvelles espèces, alors la théorie de l'Origine évolutive de la vie ne sert plus à rien ! il y a d'autre liens de dépendance assez intéressants, notamment vis-à-vis du hasard (à rapprocher également de la définition de l'intelligence). Mon objectif, à terme, est de parvenir à modéliser par exemple la chaîne de causalité suivante : Evolution -> Origine de la vie -> E.T. -> 4è Dimension (Voyages supra-luminiques) -> Télépathie -> Dieu -> Scénarisation -> Astrologie -> Rêve prémonitoires...
Selon ce que l'on appelle le principe holistique, tout est interdépendant ; mais on ne peut pas vraiment modéliser ces liens en logique d'ordre 0+, peut être dans une version plus puissante du logiciel !
Vous voulez que votre SE fonctionne sans base de règles ? c'est possible ! il suffit de trouver suffisamment de sessions représentatives des résultats à obtenir et... de remplacer le SE par un réseau de neurones (RN) !
Sans aller jusqu'à remplacer un SE, un RN pourrait éventuellement faire des inférences de règles intéressantes, fondées sur des exemples assimilés statistiquement : on tire des configurations de faits au hasard, on en déduit des conclusions avec le SE, on compare avec le RN ; si le résultat est différent, alors on infère des sous-buts en chaînage arrière à partir des faits trouvés par le RN et on cherche pourquoi le SE n'a pas trouvé cette solution : on exploite ainsi la capacité de généralisation des RN pour faire de l'inférence de règles.
Les RN requièrent un ensemble de sessions représentatives pour leur apprentissage, tandis que les SE requièrent la construction de la base de règle selon les indications des experts du domaine. Ils peuvent alors fonctionner parfaitement dès la première session.
Les SE peuvent, en général, expliquer la solution, pas les RN (qui peuvent seulement rendre compte d'un taux d'apprentissage de leur base). En revanche, les RN trouvent rapidement la solution une fois l'apprentissage terminé (mais l'apprentissage est long et sa convergence n'est pas garantie).
Les RN peuvent proposer des solutions même lorsque les faits sont incomplets. C'est possible également avec certains SE en chaînage arrière qui peuvent alors poser des questions à l'utilisateur sur des faits manquants susceptibles d'aider à la solution (ce sont les faits manquants à certaines règles impliquées dans le but recherché), dans le cas du diagnostique par exemple.
Pour faire une analogie un peu anthropomorphique, on pourrait dire que l'apprentissage des SE relève plutôt de la théorie (BR), tandis que celui des RN est plutôt fondé sur la pratique (jeu d'apprentissage). Le fait d'utiliser la logique floue pour les fiabilités des règles, c'est un peu comme si on tentait de prendre en compte un peu de pratique (probabilités issues de la pratique du domaine) dans l'aspect théorique d'une BR. Réciproquement, pour les RN, le fait de corriger la représentativité de l'apprentissage (comme cela ce fait avec les sondages), éventuellement en choisissant certains échantillons plutôt que d'autres, cela revient à prendre en compte un peu de théorie dans l'aspect pratique de l'apprentissage (mais il s'agit toujours des probabilités issues du domaine).
En logique non monotone, l'espace de recherche peut contenir de nombreuses solutions distinctes que le SE risque de ne pas trouver. Dans ce cas de figure, on s'éloigne sensiblement des RN, qui ne peuvent faire correspondre qu'une seule sortie à une entrée donnée, c'est-à-dire un ensemble de faits initiaux.
IA : Intelligence artificielle
- Opérateurs de logique floue à traiter : >>, << ;
- Traiter les comparaisons sur les nombres réels, et pas seulement sur des entiers ;
- Idée : priorité d'une règle ? (l'inconvénient, c'est qu'on sort du domaine purement déclaratif). On peut déjà utiliser la fiabilité en logique floue et simplement classer les règles par fiabilité ;
- Possibilité d'interroger les indices de fiabilité en tant que faits accessibles dans les règles (il faut d'abord traiter les réels) ;
- Moteur d'inférence en régime révocable ;
- Compiler le moteur d'inférence en tant que service web capable de faire une expertise sur un fichier xml passé en entrée.
- Projet : Table Reglementation : plusieurs bases de règles possibles pour une application ?
Inconvénient : comme la config est dans la table Variable, on sera quand même obligé de dupliquer l'application pour changer de config (ou sinon faire la configuration dans les sessions ou bien alors il faudra une table de configuration en plus, car la configuration doit être liée à la réglementation).
Pour le moment, il suffit de dupliquer une application : cf. DBToFile, qui est utile aussi pour l'archivage ;
- Type de Donnée (TypeDonnee) : Booléen, Entier, Réel, Taux, Date, Chaîne : utile pour initialiser les valeurs par défaut ?
- Frontale de BD pour la version .NET ? (ce n'est pas très utile car le runtime d'Access est gratuit et on peut utiliser une version compilée en .mde de la base de données, voir VBBrainBox.MDB) ;
- Possibilité de choisir une base de données (pour le moment, il faut la renommer en VBBrainBox.mdb) ;
- Ajouter un contrôle splitter entre les 2 onglets et un autre dans l'onglet expertise.
- Importation et exportation en XML via un dataset.
- Au lieu d'attendre de détecter une contradiction, on pourrait tester toutes les règles : analyser la cohérence des règles (règles contradictoires), dans les prémisses (est-ce que les prémisses sont cohérentes entre elles ?) et dans les conclusions ;
- Si une variable n'apparaît que dans les conclusions : proposer bIntermediaire, et avertir si elle est présente dans la session, ce qui est inutile ;
- Si une variable n'apparaît jamais dans les faits initiaux, indiquer qu'elle peut être classée comme intermédiaire ;
- Vérifier que les opérateurs >, <, >= et <= ne sont pas utilisés avec des booléens, car cela n'a pas de sens ;
- Compilation de BC : seulement pour optimisation, car cela complique l'explication de la solution, ex : Si A implique C et B implique C et que A implique non B, alors ce n'est pas cohérent, on peut éliminer d'emblé B implique C avant de commencer l'expertise, voir :
www710.univ-lyon1.fr/~fouet/DEA/chap7.html.
- L'interprétation de la logique floue fonctionne bien pour les booléens, cependant, pour les autres types de données, il faudrait créer une liste de couples associant une valeur à une fiabilité, et traiter la mise à jour des fiabilités de faits de même valeur ; logique ! non ? Autre solution : étendre le principe de la complémentarité à d'autres grandeurs qui pourraient se comporter comme des "booléens flous", par exemple Froid et Chaud : Si la fiabilité associée à Chaud est négative, alors c'est Froid avec la fiabilité opposé ;
- Raisonnement par l'absurde : on pourrait autoriser la saisie de fiabilité négative pour les règles, mais ce n'est pas très utile car il suffit d'inverser chaque conclusion (sauf peut être pour les variables non booléennes qui n'ont pas de complémentaire ?). Sinon, les fiabilités négatives pour les faits initiaux n'ont pas beaucoup d'intérêt non plus, car il suffit d'inverser leur valeur avant de début de l'expertise (là encore il reste le cas variables non-inversables). Enfin, au lieu d'inverser effectivement les faits, on pourrait aussi chercher à appliquer des règles en considérant les booléens contraires avec une fiabilité négative, ce qui revient à peu près au même (sauf que dans ce cas l'inversion serait hypothétique et non effective comme pour les faits inversés).
- Compilation avec Visual Studio 2013 : forçage du mode 32 bits, et légère correction du code pour les avertissements concernant le retour des fonctions.
Voici les principales différences entre Turbo-Expert 1.2 et VBBrainBox qui résument les fonctionnalités que j'y ai ajouté :
- Turbo-Expert est en VB6 ;
- Turbo-Expert n'utilise pas de base de données, il faut donc veiller à la cohérence du fichier de dictionnaire, du fichier de base de règles, ainsi que du fichier de base de faits (vive les bases de données relationnelles :-). Cependant, on peut très bien concevoir une application grâce à la base de données de VBBrainBox, puis exporter en fichiers textes pour expertiser avec la version en VB6, voir l'astuce plus bas ;
- Turbo-Expert n'utilise pas de nom de constante pour simplifier l'écriture et la maintenance des règles (on peut toutefois définir des variables pour cela) ;
- Turbo-Expert n'utilise pas d'allocation dynamique de mémoire, les tableaux sont limités par des constantes à la compilation ;
- Turbo-Expert n'utilise pas la logique floue ;
- Turbo-Expert fonctionne selon l'hypothèse du monde fermé pour les faits initiaux, qui sont tous initialisés par défaut (ou presque tous, voir le paragraphe suivant). L'inconvénient, c'est que si une variable initiale apparaît en tant que conclusion d'une règle, on est donc obligé de travailler en logique non monotone. Ainsi, beaucoup de règles se déclanchent sur la base des faits initiaux définis par obligation, au détriment des faits déduits logiquement (car il n'y a pas de redéclanchement). Turbo-Expert trouve donc potentiellement moins de conclusions que VBBrainBox ;
- En fait, la gestion des faits initiaux indéfinis est partiellement implémentée (on peut mettre ;; dans la base de fait pour laisser un fait à indéfini, mais j'ai dû corriger le traitement pour que cela fonctionne normalement, cf. version 1.21). A l'inverse, la modification d'un fait n'est pas traitée dans Turbo-Expert :
- La gestion de la logique non monotone n'est pas correctement traitée dans Turbo-Expert 1.2 : des faits contradictoires (qui portent sur les mêmes n° de variable) sont ajoutés à la base de faits, au lieu de vérifier si la valeur d'un fait déjà existant devrait être modifiée, comme cela est fait dans la fonction bMAJFait de VBBrainBox, voir l'exemple Immortalité2 : la règle R3_CondHum est déclanchée par erreur alors que le fait bMortel vient d'être mis à Faux ;
- La condition d'arrêt de Turbo-Expert porte sur le nombre de faits déduits, alors que VBBrainBox teste toutes les règles applicables au moins une fois. Ainsi, le chaînage avant s'arrête alors même qu'il y aurait encore des règles applicables. Exemple de non déclanchement de règle dans Turbo-Expert 1.2 : Application "Aide au voyageur", Session1 : la règle R4 n'est pas déclanchée car la condition d'arrêt est activée trop tôt ;
- En logique floue, VBBrainBox affiche des conclusions portant sur des faits déjà établis, afin de préciser la mise à jour de la fiabilité du fait, tandis que dans Turbo-Expert, ces conclusions redondantes ne sont pas affichées.
Dans la version 1.21 en VB6, je n'ai apporté que des corrections mineures avant de migrer en VB .NET :
- Option explicit ;
- Public, Private précisé ;
- Correction des variants fantômes de VB6 : Dim a, b, c as Integer : a et b sont des variants ;
- Changement des ByRef implicites en ByVal explicites ;
- Correction de la gestion des dates, notamment les dates > 2002 (mais l'initialisation par défaut des dates ne marche pas toujours dans Turbo-Expert : certaines comparaisons sont vraies quand elles ne le devraient pas) ;
- Correction des faits initiaux indéfinis, mais les valeurs par défauts ne sont pas précisées : "" ou 0 selon les cas (?) ;
- Au lieu du chargement de Dicovar.txt à l'initiation du logiciel, c'est un fichier .dic qui est chargé juste avant une BR de même nom.
Si vous installez le runtime .NET et le runtime Access (ou Access lui-même), alors vous pouvez très bien concevoir votre application pour Turbo-Expert dans la base de données VBBrainBox.mdb, puis exporter l'application en fichiers compatibles Turbo-Expert via l'exécutable VBBrainBox !
- Le code source de VBBrainBox en VB .NET sur VBFrance.com (ainsi que Turbo-Expert 1.21 en VB6) :
https://codes-sources.commentcamarche.net/source/6949
- Le code source de VBBrainBox en VB .NET, version html :
http://patrice.dargenton.free.fr/ia/vbbrainbox/VBBrainBoxSrc.html
- Package d'installation : il contient VBBrainBox.exe + VBBrainBox.mde (renommé en .mdb) + DBToFile.ocx + les sources en VB .NET :
http://patrice.dargenton.free.fr/ia/vbbrainbox/vbbrainboxinst.msi (793 Ko)
- Pour ceux qui n'ont pas Access et qui veulent utiliser la base de données VBBrainBox.mdb, pour modifier les données ou créer de nouvelles applications, une version compilée en .mde Access 2000 peut être téléchargée ici :
http://patrice.dargenton.free.fr/ia/vbbrainbox/vbbrainboxmde2000.zip (120 Ko)
et le runtime d'Access 2000 est disponible gratuitement ici :
http://ors1.chez.tiscali.fr/a2krt/index.html (36 Mo)
- Pour échanger des applications VBBrainBox via DBToFile sans envoyer la base de données en entier :
http://patrice.dargenton.free.fr/ia/vbbrainbox/dbtofile.zip (159 Ko)
- Package d'installation de DBToFile :
http://patrice.dargenton.free.fr/dbtofile/DBToFile2Inst.zip (4 Mo, dernière m.a.j.: le 21/6/2003, version 2.0.0.6)
- DBToFile, un système d'archivage et de réplication asynchrone de bases de données Access (DBToFile a légèrement évolué depuis cette documentation) :
http://patrice.dargenton.free.fr/dbtofile/index.html
- Cours de DEA de Jean-Marc Fouet (Lyon 1) : DEA ECD : Extraction - validation des connaissances :
www710.univ-lyon1.fr/~fouet/DEA/main.html
- FAQ sur les systèmes experts en anglais :
www-2.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/faqs/ai/expert/part1/faq.html
- Forum IA en français : www.foorum.fr/news/redirect/consult.asp?group=fr.comp.ia
- Mini système expert avec une synthèse vocale en français :
IAVB2 : Intelligence Artificielle en Visual Basic, version 2 : maintenant, ça parle !!!
http://patrice.dargenton.free.fr/ia/iavb/index.html
www.vbfrance.com/code.aspx?id=1860
- Le Perceptron (RN) en VB .NET :
http://patrice.dargenton.free.fr/ia/ialab/perceptron.html
- Projet IALib du IALab : "IA : le Laboratoire virtuel" (reprise du projet lorsque la conversion du Perceptron en VB .NET sera complète) :
www.vbfrance.com/projetcommun.asp?ID=20
- Machine de Boltzmann pour résoudre le problème du voyageur de commerce (technique du "recuit simulé" dans les réseaux de neurones : Boltzmann Machine with Simulated Annealing : Traveling Salesman Problem) :
www.geocities.com/CapeCanaveral/1624/boltzman.html
www.geocities.com/CapeCanaveral/1624/nn.zip (sources en langage C)
www.geocities.com/CapeCanaveral/1624/
- Comparaison de tous les algorithmes d'IA pour le problème du voyageur de commerce :
www.dil.univ-mrs.fr/~vancan/mait/documents/cours4_8.pdf
- Documentation sur la formule de Bayes (probabilités conditionnelles pour la logique floue) :
www.maths-express.com/maths-express/BAC-EXO/BAC-S/cour-S/cours-proba/bayes.htm
www.sciences-en-ligne.com/momo/chronomath/chrono1/Bayes.html
- Documentation sur MYCIN (système expert dans le diagnostic médical utilisant la logique floue) :
www.cert.fr/fr/dcsd/PUB/THESES/fabiani/manuscrit_fabiani/node334.html
www.computing.surrey.ac.uk/research/ai/PROFILE/mycin.html (documentation complète en anglais)
Pré-requis pour les logiciels .NET :
Comme tout logiciel .NET, VBBrainBox requiert l'installation de la plate-forme .NET (le .NET Framework : 20 Mo, c'est en quelque sorte le runtime .NET, ou plus précisément la machine virtuelle .NET, l'équivalent multi-langage de Microsoft de la machine virtuelle Java), elle est disponible gratuitement pour tous les systèmes d'exploitation Windows de bureau de version plus récente que Windows 95 (la compilation du logiciel VBBrainBox n'est toutefois possible que sous les systèmes de type NT : NT4, NT2000 et XP). Voici où on peut la télécharger :
Configuration requise du Microsoft .NET Framework :
www.microsoft.com/France/msdn/technologies/technos/framework/configuration.asp
Runtime .NET (la partie redistribuable du Framework .NET) :
Service pack 2 Fr du Framework .NET :
Service pack 2 Us du Framework .NET (version Us requise pour ceux qui ont VS .NET ?) :
Vérifiez également les mises à jour via votre menu Démarrer : Windows Update.
Lorsque Visual Studio .NET n'est pas installé sur la machine, MDAC 2.7 (composants d'accès aux données, version .NET) doit alors être installé pour que VBBrainBox puisse lire la base de données :
Par Patrice Dargenton : patrice.dargenton@free.fr
www.vbfrance.com/code.aspx?ID=6949
http://patrice.dargenton.free.fr/ia/vbbrainbox/index.html
http://patrice.dargenton.free.fr/index.html
www.vbfrance.com/listeauteur2.aspx?Val=1124
Mots clés : Intelligence Artificielle, Système expert, Logique d'ordre 0+, Logique floue, VB .NET, Visual Basic .NET, DOTNET, Open source.