Combinaison de schémas

Grâce à l’étape de focalisation, le système peut exécuter un schéma de résolution en l'adaptant à la situation. Mais lorsque plusieurs schémas concurrents doivent être exécutés, le système doit également combiner les résultats obtenus. L'objectif est que chaque schéma apporte sa contribution dans la solution finale, selon ses capacités. Pour réaliser cette combinaison, il y a deux possibilités : soit on applique tous les schémas et on combine ensuite les solutions obtenues, soit on applique les schémas de manière séquentielle et on combine en temps réel les résultats. Dans le dernier cas, chaque nouvelle solution est combinée pendant sa construction avec la solution courante et le résultat devient la nouvelle solution courante. La première méthode a l'avantage d'être indépendante de l'ordre d'exécution des schémas mais pose de gros problèmes pour le calcul de la solution finale, notamment à cause du fait que les conséquences de deux choix ne sont souvent pas la somme des conséquences de chaque choix. Supposons par exemple que dans la solution 1, la pièce x1 cherche à se déplacer vers le point y1 et que dans la solution 2, la pièce x2 (x2 différent de x1) cherche à se déplacer vers le point y2. Dans chaque solution, les conséquences sont que chaque pièce atteindra son objectif. Si y1 est différent de y2, il n'y a pas de problème pour la solution globale. Mais si y1 et y2 sont identiques, les conséquences sont modifiées dans la situation globale car l'une des deux pièces ne pourra pas atteindre son objectif. Nous avons donc choisi la seconde possibilité qui consiste à combiner au fur et à mesure des exécutions des schémas. Cette solution a, en outre, l'avantage de faciliter les remises en question et de construire progressivement la solution. Pour cela, le système part d'une solution vide puis il exécute de manière séquentielle les schémas concurrents. Chaque exécution modifie la solution en lui apportant de nouveaux éléments.

Comme les champs d'action des schémas se recoupent la plupart du temps, le système doit gérer les conflits qui apparaissent entre les schémas. Par exemple, il est rare qu'une pièce appartienne à un seul schéma. Deux schémas peuvent donc donner des mouvements différents à la même pièce, ce qui est impossible. Il faut

alors décider quel chemin doit être conservé et annuler l'autre. Cela signifie qu'à chaque fois qu'un schéma veut ajouter une nouvelle décision, le système commence par déterminer si elle entre en conflit avec une décision existante. Pour cela, il dispose de bases de règles spéciales qui sont envoyées au moteur d'inférence et qui détectent tout conflit. En utilisant la trace du raisonnement, le système peut ensuite remonter aux décisions qui sont en cause.

Lorsqu'un conflit est détecté, le système doit le résoudre. Pour l'instant, la règle de décision utilisée est très simple : elle consiste à donner la priorité à la décision qui a le niveau d'utilité le plus haut. Pour chaque décision, le système calcule en effet une estimation de son utilité d’après une formule qui représente les causes de la décision. Cette utilité permet en fait d’évaluer le regret associé à la décision, c’est-à-dire le manque à gagner qu’occasionnerait l’abandon de cette décision. Par exemple, une attaque déclenchée à cause d’un manque global d’objectif sera plus utile qu’une attaque déclenchée simplement par une opportunité locale. Cette heuristique pourrait être complétée par un raisonnement plus profond. Il serait en effet intéressant que le système examine les arguments qui ont conduit à chaque décision pour les comparer et mener ainsi une investigation plus fine. Il faudrait aussi que le système soit capable d'envisager une autre décision qui aurait les avantages des deux décisions en conflit et les remplacerait avantageusement. Dans le domaine des jeux de stratégie, cela s'appelle un coup multi-buts. Lorsqu'une seule unité doit aller à deux endroits à la fois, elle peut se diriger vers un point médian pour se donner la possibilité de retarder la décision.

Le problème central de la combinaison réside dans la nécessité d'annuler l'une des deux décisions pour résoudre un conflit et de propager les modifications entraînées par cette annulation. Par exemple, si on annule un mouvement pour une pièce vers un objectif, il faudra peut-être remettre en question le mouvement d'une autre pièce pour l'envoyer sur cet objectif. Deux cas sont alors possibles selon que la décision annulée est la nouvelle ou l'ancienne décision. Le premier cas est le plus simple car il n'est pas nécessaire de remonter très loin dans le raisonnement puisque la décision vient d'être prise. Il suffit donc que l'interpréteur se repositionne à cet endroit et recommence la prise de décision en prenant bien soin de s'interdire la décision annulée (pour cela, le système dispose d'un mécanisme de contraintes sur ses choix qu'il ajoute en cours de raisonnement). Dans le second cas, cette méthode est impensable car la décision à annuler a été prise il y a longtemps et cela obligerait à reexécuter tout le raisonnement effectué jusque-là. Pour gérer ce cas, le système dispose donc d'un mécanisme de correction complexe en deux étapes. Au moment de la résolution du conflit, il se contente d'annuler la décision et les faits qui s'y rapportaient directement. Cette correction "légère" est très rapide et si l'on recommençait le raisonnement en prenant les mêmes décisions, la base finale serait identique (cohérence faible). Par contre, elle ne permet pas d'assurer une cohérence forte car si l'on recommençait le raisonnement, le système ne ferait plus forcément les mêmes choix. Pour pallier cette perte de cohérence, le système procède à une vérification générale lorsque tous les schémas concurrents ont été exécutés. Il passe en revue toute la partie du raisonnement concernant ces schémas et modifie les décisions qui doivent l'être.

Au final, on obtient donc une solution pour un cas général à partir de l'utilisation de schémas dédiés à des cas spécifiques. Sur l'exemple de la Figure 31, le système MARECHAL joue les blancs. On peut y distinguer trois types de mouvements provenant chacun d'un schéma de résolution différent. Les mouvements blancs ont été obtenus par le schéma tactique offensif et visent à détruire la pièce noire n°7 pour libérer l'objectif central (7,5) (les objectifs sont repérés par des drapeaux en haut à gauche de la case). Les mouvements gris proviennent du schéma tactique défensif. L'unité 35 (étoile) se replie car elle n'a pas de capacité de combat (elle représente une pièce de commandement) et la pièce 41 (triangle) choisit une position défensive intéressante car elle possède une capacité de tir à distance. Enfin, les mouvements noirs sont les résultats du schéma de début de partie. Les pièces 45 et 47 se déploient pour aller occuper l'objectif situé en (15,7), sur le bord Est du terrain. Au total, le système a effectué deux combinaisons : il a tout d'abord exécuté le schéma tactique car globalement beaucoup de pièces sont à proximité des pièces adverses. Il a donc combiné le schéma offensif et le schéma défensif en commençant par le premier car il a estimé avoir plus d'unités menaçantes que menacées. Il a ensuite combiné le résultat obtenu avec le schéma stratégique.

Figure 31: Exemple de combinaison

5. Résultats

L'utilisation du mécanisme de gestion des stratégies de résolution améliore nettement le niveau de jeu de l'ordinateur par rapport à une simple sélection des schémas concurrents. Des tests effectués sur plusieurs dizaines de parties ont révélé une amélioration de l'ordre de 50%, mais ce nombre n'est qu'indicatif car le niveau actuel du système est surtout limité par son manque de connaissances, ce qui peut biaiser les résultats. La Figure 32 présente quelques exemples de confrontations entre le système jouant avec gestion des stratégies spécialisées et le système jouant par simple sélection. Pour chaque partie, le tableau indique les scores obtenus. Ces parties n’étant pas forcément équilibrées, elles sont jouées deux fois avec échange des camps.

Partie #1 #2 #3 #4

Avec gestion 17 20 14 14 15 23 22 11

Sans gestion 11 12 10 6 14 12 7 15

Figure 32: Quelques exemples de confrontations "avec gestion" contre "sans gestion"

6. Conclusion

Grâce à son mécanisme d’adaptation et de combinaison, le système MARECHAL est capable d'utiliser des exemples de résolution sur des cas simples pour résoudre des cas généraux complexes. La complexité émergente de son raisonnement est ainsi obtenue par la confrontation avec la situation, mais des améliorations dans la résolution des conflits sont encore nécessaires. De part sa vision mono-contextuelle, le système ne gère en permanence qu’un seul ensemble d’hypothèses, ce qui lui permet de limiter fortement ses besoins en espace mémoire et donc de traiter des problèmes volumineux.

Le but du mécanisme proposé est avant tout de simplifier l'acquisition des méthodes de résolution. Au lieu de chercher une méthode très complexe qui marche dans tous les cas anormaux, l'expert se contente de définir des méthodes simples dont il délimite ensuite les conditions d'application. Malgré cela il faut toujours des méthodes pour chaque extrémité d'une composante de l'espace des problèmes. Or, bien souvent, l'une des extrémités correspond à une situation normale et les autres à des cas particuliers et il n'est pas possible de fournir des méthodes pour tous les cas particuliers. Les perspectives d'amélioration à long terme du système seraient donc de le rendre capable de se suffire des cas normaux. Le système devrait alors analyser la situation pour détecter les anormalités et y adapter ses connaissances au moment du raisonnement.

7. Bibliographie

[Clayton 85] Clayton B. D. : A First Look at Viewpoints. Inference Corporation, 1985. [Corkill 91] Corkill D. D. : Blackboard Systems – AI Expert 6 (9), p. 40-47, 1991.

[Davis 80] Davis R. : Report on the Workshop on Distributed Artificial Intelligence - SIGART Newsletter, n°73, p. 42-52, 1980.

[De Kleer 86] De Kleer J. : An Assumbtion-based TMS. Artificial Intelligence 28, p. 127-162, 1986.

[Engelmore et al. 88] Engelmore R. et Morgan T. : Blackboard Systems – Addisson-Wesley, Reading, Massachussets, 1988.

[Erman et al. 80] Erman L. D., Hayes-Roth F., Lesser V. R. et Reddy D. R. : The HearSay-II

Speech-Understanding System : Integrating Knowledge to Resolve Uncertainty - ACM computing Surveys 12 (2),

p. 213-53, 1980.

[Jagannathan et al. 89] Jagannathan V., Dodhiawala R. et Baum L. S. : Blackboard Architectures and

Applications – Academic Press, New-York, 1989.

[Lâasri et al. 88] Lâasri H., Maître B., Mondot T., Chapillet F. et Haton J.P. : ATOME : A Blackboard

Architecture with Temporal and Hypothetical Reasoning – Proceedings of the 8^th ECAI, Munich, p. 1-5, 1988.

[Lesser et al. 77] Lesser V. R. et Erman L. D. : A Retrospective view of the HearSay-II Architecture. In Proceedings of IJCAI-77, p790-800, 1977.

[Nii et al. 82] Nii H. P., Feigenbaum E. A. Anton J. J. et Rockmore A. J. : Signal-to-Symbol

Transformation : HASP/SIAP Case Study – AI Magazine 3 (2), p. 23-35, AAAI Press, 1982.

[Nii 86] Nii H. P. : Blackboard Systems : The Blackboard Model of Problem Solving and the Evolution of

Blackboard Architectures – AI Magazine 7 (2), AAAI press, 1986.

[Terry 83] Terry A. : The CRYSALIS Project : Hierarchical Control of Production Systems – Tech. Report HPP-83-19, Université de Standford, Califonie, 1983.