Sousladirectionde PierrePOMPIDORetEricBOURREAU Datedesoutenance: 20Juin2011 par GuillaumeTISSERANT L’intelligenceartificiellepourlejeudeGo MÉMOIREDESTAGEDEMASTERM2

41  Download (0)

Texte intégral

(1)

Académie de Montpellier

Université Montpellier II

Sciences et Techniques du Languedoc

MÉMOIRE DE STAGE DE MASTERM2

effectué au Laboratoire d’Informatique de Robotique et de Micro-électronique de Montpellier

Spécialité : Professionelle et Recherche unifiée en Informatique

L’intelligence artificielle pour le jeu de Go par Guillaume TISSERANT

Date de soutenance : 20 Juin 2011

Sous la direction de Pierre POMPIDOR et Eric

BOURREAU

(2)
(3)

Table des matières

1 Introduction 5

1.1 Résumé . . . . 5

1.2 Abstract . . . . 5

1.3 Le stage . . . . 5

1.3.1 Remerciements . . . . 5

1.3.2 Objectif du stage . . . . 6

2 Le jeu de Go et l’Intelligence Artificielle 7 2.1 Qu’est ce que le jeu de Go . . . . 7

2.1.1 Introduction . . . . 7

2.1.2 Les règles . . . . 7

2.1.3 Histoire du Go . . . . 10

2.2 Les difficultés des intelligences artificielles de Go . . . . 10

2.2.1 Historique . . . . 10

2.2.2 Vision des joueurs de Go . . . . 10

2.2.3 Le problème de l’espace des possibles . . . . 11

2.2.4 Le problème de la mise en algorithme . . . . 11

2.3 L’apport du Go aux intelligences artificielles . . . . 11

3 Les programmes jouant au Go 13 3.1 Mogo, le programme de référence . . . . 13

3.1.1 Comment marche Mogo . . . . 13

3.1.2 Les faiblesses de Mogo . . . . 14

3.2 Les autre programmes . . . . 14

3.2.1 Les autre programmes basés sur UCT . . . . 14

3.2.2 Les programmes basés sur d’autre méthodes . . . . 15

3.3 MachiaBot, le programme développé . . . . 15

3.3.1 Fonctionnement global . . . . 15

3.3.2 Protocole de test . . . . 15

4 UCT/RAVE 17 4.1 L’algorithme UCT . . . . 17

4.1.1 Monte Carlo . . . . 17

4.1.2 Bandit ou comment choisir les coups à explorer . . . . 18

4.1.3 UCT ou Bandit dans un arbre . . . . 18

4.1.4 Exemple de fonctionnement . . . . 19

4.2 Variantes et améliorations . . . . 20

4.2.1 RAVE . . . . 20

4.2.2 le choix des coups lors des parties . . . . 20

5 Détection de zones importantes grâce à UCT 23 5.1 Détection des zones de combat . . . . 23

5.1.1 L’idée originale . . . . 23

5.1.2 Les formules de détection . . . . 24

5.1.3 Comparatif . . . . 24

5.1.4 L’utilisation des zones détectées . . . . 24

5.1.5 Efficacité . . . . 24

5.2 Détection des zones neutres . . . . 26

(4)

5.2.1 Qu’est ce qu’une zone neutre ? . . . . 26

5.2.2 Comment les détecter ? . . . . 26

5.2.3 Comment les utiliser ? . . . . 26

5.2.4 Efficacité . . . . 27

6 Proposition de modifications du fonctionnement pour UCT/RAVE 29 6.1 Les défauts intrinsèques de RAVE . . . . 29

6.2 Améliorations mineurs de RAVE . . . . 29

6.2.1 Ordonner les coups . . . . 29

6.2.2 Aléatoiriser les coups . . . . 29

6.3 Amélioration pour les branches peu explorées . . . . 30

6.4 Amélioration hors de l’arbre . . . . 30

7 Comment guider UCT grâce à de la connaissance humaine ? 33 7.1 Le fonctionnement du dictionnaire . . . . 33

7.1.1 La reconnaissance d’une forme depuis le dictionnaire en arbre . . . . 33

7.1.2 Amélioration : pierres "importantes" . . . . 34

7.1.3 Le dictionnaire par base de données de parties . . . . 34

7.2 Utilisation des informations obtenues . . . . 35

7.2.1 Construction du haut de l’arbre . . . . 35

7.2.2 Préconstruction de RAVE . . . . 36

8 Conclusion 37 8.1 Résultats . . . . 37

8.2 perspectives . . . . 37

9 Documentation 39 9.1 Lexique . . . . 39

9.1.1 Vocabulaire sur le jeu de Go . . . . 39

9.1.2 Programmes . . . . 40

(5)

Chapitre 1

Introduction

Sommaire

1.1 Résumé . . . . 5

1.2 Abstract . . . . 5

1.3 Le stage . . . . 5

1.3.1 Remerciements . . . . 5

1.3.2 Objectif du stage . . . . 6

1.1 Résumé

Le rapport traite de l’amélioration d’un programme jouant au Go basé sur l’algorithme UCT.

UCT est un algorithme probabiliste, basé sur des simulations pseudos-aléatoires de parties. Les meilleurs programmes sont actuellement basés sur cet algorithme, et commencent à rivaliser avec des joueurs humains de bon niveau, mais ils connaissent plusieurs défauts dans certains types de situation. Des variations de l’algorithme sont proposées, tentant d’améliorer ses performances face aux problèmes face auxquels il réagit mal. Les modifications proposés sont de différentes natures et sont basés sur une amélioration de la qualité des parties pseudos-aléatoires grâce à :

– une détection des zones importantes du plateau, où chaque joueur a intérêt à jouer en priorité.

– de l’ajout de connaissances expertes, particulièrement de formes, permettant de faire des séries de coups à échelle locales plus réalistes.

– des modifications internes à l’algorithme, permettant de mieux utiliser l’information donné par les parties pseudos-aléatoires précédentes.

1.2 Abstract

This report tells about a program playing Go, based on UCT algorithm. UCT is a probabilist algorithm based on pseudorandom simulation of games. Best actual programs use this algorithm and begin to rival with good human players, but they have a lot of weakness in some particular situations. Some variations of the algorithm are proposed to improve his performance in a situation where he has a bad reaction. The proposed modifications are based on a quality amelioration of the simulation’s pseudorandomness :

– A detection of important areas on the Goban, to play inside first.

– Use of expert knowledge, particularly local patterns, to have more realistic local sequence of moves.

– Intern modifications of the algorithm, for a better use of informations given by the pseudo- randomness games.

1.3 Le stage

1.3.1 Remerciements

– Pierre Pompidor, enseignant encadrant du stage qui avait déjà accepté de lancer le projet à travers mon TER de Master 1 et qui a accepté de continuer à travailler dessus pendant le

(6)

stage de Master 2. Ses précieux conseils ont beaucoup aidé à l’avancement du projet.

– Eric Bourreau, enseignant encadrant du stage, qui a choisi de se joindre au projet. Sa moti- vation et sa capacité d’organisation ont été précieuses pour son bon déroulement.

– Yvan Serieye et Gaël Gonzalez, étudiants en Master 1 IC, qui ont choisi de se joindre au projet pour développer une interface web.

– L’ensemble des enseignants en informatique de l’Université Montpellier 2 dont la majorité des cours a été utile pour la réalisation de notre projet.

– Sikusiku, développeur japonais de Mugo, l’interface graphique qui a été utilisé pendant le développement du programme, pour avoir créé seul un programme libre et puissant.

1.3.2 Objectif du stage

Le stage est la suite d’un TER fait en première année de Master. Le but du TER était de faire une intelligence artificielle jouant au Go. L’objectif a été atteint malgré un faible niveau du programme. Le premier objectif du stage fut d’abord de donner au programme un niveau plus fort, en cherchant de nouvelles idées pour faire évoluer les programmes joueurs de Go. Les deux axes de réflexion principaux ont porté sur une étude du fonctionnement du programme développé, pour mieux comprendre ses décisions, et une réflexion sur les faiblesses des autres programmes pour chercher en priorité des idées permettant de les compenser. L’autre objectif a été de mesurer la progression du programme, de façon à pouvoir valider les méthodes développées.

(7)

Chapitre 2

Le jeu de Go et l’Intelligence Artificielle

Sommaire

2.1 Qu’est ce que le jeu de Go . . . . 7

2.1.1 Introduction . . . . 7

2.1.2 Les règles . . . . 7

2.1.3 Histoire du Go . . . . 10

2.2 Les difficultés des intelligences artificielles de Go . . . . 10

2.2.1 Historique . . . . 10

2.2.2 Vision des joueurs de Go . . . . 10

2.2.3 Le problème de l’espace des possibles . . . . 11

2.2.4 Le problème de la mise en algorithme . . . . 11

2.3 L’apport du Go aux intelligences artificielles . . . . 11

2.1 Qu’est ce que le jeu de Go

2.1.1 Introduction

Le jeu de go est né en Chine il y a 4000 ans. Il se joue au Japon depuis 1200 ans, mais il ne s’est répandu que récemment en occident. Les règles, les plus simples de tous les jeux de stratégie, s’apprennent en quelques minutes. Mais ceux qui en exploreront les subtilités pourront constater que sous son apparente simplicité, le jeu de Go est d’une richesse inépuisable.

2.1.2 Les règles

Résumé

Chaque joueur possède des "pierres", l’un a les pierres noires, l’autre les pierres blanches.

Chacun son tour, les joueurs posent une de leur pierre sur le plateau. Si de cette façon, ils entourent une ou plusieurs pierres adverses, elles sont considérées comme prisonnières, et sont retirées du plateau. Le but du jeu est d’occuper le plus d’espace possible.

Version détaillée

Deux joueurs posent à tour de rôle une pierre de leur couleur sur une intersection inoccupée d’une grille. Des intersections sont voisines si elles sont reliées par une ligne de la grille et sans autre intersection entre elles. Les libertés d’une pierre sont les intersections inoccupées voisines de l’intersection sur laquelle est cette pierre. Des pierres de même couleur posées sur des intersections voisines partagent leurs libertés en commun.

(8)

Les libertés de la pierre blanche sont marquées par les ronds. Les deux pierres noires sont voisines et partagent donc leurs libertés, marquées par des carrés.

Capture

Si un joueur supprime la dernière liberté de pierres adverses, il les capture en les retirant de la grille. De plus, il ne doit pas supprimer la dernière liberté de ses propres pierres, sauf s’il capture au moins une pierres adverse.

Si Blanc joue sur l’intersection marquée par le triangle, il capturera les pierres noires.

Répétition, ou ko

Un joueur ne doit pas, en posant une pierre, ramener la grille dans un état iden- tique à l’un de ceux qu’il lui a lui-même déjà donné.

Partons de la figure 1, Blanc peut prendre la pierre noir marquée d’un rond. Cela nous mène à la figure 2.

Si la règle précédente n’était pas donnée, Noir pourrait reprendre la pierre blanche marqué d’un rond, et cela nous ramènerait à la figure 1.

Noir n’a donc pas le droit de prendre la pierre immédiatement, et devra jouer son prochain coup sur une

(9)

autre intersection.

Détermination du gagnant

Des intersections inoccupées sont entourées par un joueur s’il possède une pierre sur chacune des intersections leur étant voisines.

La partie s’arrête lorsque les deux joueurs passent consécutivement. Ils peuvent alors retirer de la grille toutes les pierres adverses qu’ils sont certains de pouvoir capturer. Puis ils comptent les points qui sont le nombre d’intersections qu’ils sont certains de pouvoir occuper ou entourer avec leurs pierres.

En cas de désaccord des joueurs sur le statut de certaines intersections, la partie reprend dans l’état où elle s’était arrêtée jusqu’à ce que les deux joueurs passent de nouveau consécutivement, sachant qu’ensuite, aucune des pierres encore sur la grille ne pourra être retirée. Les points des joueurs seront alors le nombre d’intersections qu’ils occupent ou entourent avec leurs pierres.

Si des intersections inoccupées ne sont entourées par aucun des joueurs, elles sont neutres, et ne donnent de point à personne.

Celui qui a eu le désavantage de ne pas commencer peut recevoir des points de compensation. Mais parfois, on donne volontairement un handicap à l’un des joueurs sous forme de points ou en laissant l’autre jouer plusieurs coups de suite en début de partie.

Le gagnant est celui qui a le plus de points.

Cette figure montre une partie terminée. Noir a fait deux prisonniers pendant la partie. Blanc également.

De plus, les pierres blanches F7, G7, G6 sont considérées comme mortes, car elles ne pourront échapper à une capture certaine.

Le score final est donc de 23 (nombre d’intersections dans le camp de Noir) + 5 (nombre de prisonniers faits par Noir) = 28 à 15 (nombre d’intersections dans le camp de Blanc) + 2 (nombre de prisonniers faits par blancs) + 6.5 (komi, points d’avance laissés à blanc pour compenser le désavantage de jouer en deuxième) = 23.5

Noir gagne donc de 4.5 points.

(10)

2.1.3 Histoire du Go

Le jeu de Go est probablement né au Tibet il y a près de 4000 ans. Il se dévelop- pera rapidement en Chine. Dès le IIème siècle de notre ère, des traités sont écrits sur le jeu, permettant l’affinement au cours des générations de la façon de jouer des grands joueurs. Il arrivera au Vème siècle de notre ère en Corée, puis au Japon, ou il connaîtra de grandes avancées. En 1603, le Go, soutenu par les militaires et le Shogunat, entre dans sa période classique et connaît un développement ininter- rompu pendant plus de deux siècles et demi. Grâce à la protection du shogun, le Go acquiert un statut officiel et devient une institution gouvernementale. Les joueurs professionnels, mécènes par la noblesse, ont donc pu étudier de manière approfondie toutes les subtilités du jeu. Le Go n’arrivera en Europe qu’au XVIIème siècle.

Au cours du XXème siècle, le Go se démocratise et le nombre de joueurs de tous les pays augmente d’année en année. De nouvelles ouvertures continuent à être découvertes et de nouveaux styles voient le jour. Le Go semble avoir de beaux jours devant lui.

2.2 Les difficultés des intelligences artificielles de Go

2.2.1 Historique

La création d’une intelligence artificielle de Go est un des grand défi de la création d’intelligences artificielles modernes. Depuis la défaite du meilleur joueur du monde d’échecs face à une machine (en 1997, Kasparov perd contre Deep Blue dans un tournoi en 6 manches), l’envie d’arriver à faire un programme capable de vaincre les meilleurs joueurs du monde au jeu de Go devient à la mode. Mais à cette époque, les intelligences artificielles de Go sont extrêmement mauvaises, et il est déjà dur de créer une intelligence artificielle capable de battre des amateurs moyens. Depuis ce temps, grâce au progrès des machines (en 13 ans, les machines grands publics comme les supercalculateurs sont de puissance largement supérieure), mais aussi des algorithmes de programmation, les programmes de Go ont beaucoup évolués et certains arrivent à battre des joueurs professionnels avec un certain nombre de pierres d’avance. En Juillet 2008, pour la première fois, un ordinateur sur lequel tourne le programme Mogo, basé sur l’algorithme UCT, bat un professionnel avec 9 pierres d’avance pour l’ordinateur. Depuis il a réussi plusieurs autre exploits, en battant un joueurs professionnel avec seulement 8 pierres d’avance. Mais l’algorithme utilisé atteint petit à petit ses limites. Il n’arrive toujours pas à bien jouer face à certaines situations simple pour un joueur humain et sa progression n’est pas directement proportionnelle à l’évolution des machines. De plus, il n’est pas évident à faire évoluer. Tout cela laisse penser qu’il faut maintenant aller plus loin, et trouver de nouvelles solutions pour contourner les défauts d’UCT, pour pouvoir un jour avoir une machine capable de battre un joueur de Go professionnel comme ça a été le cas pour les échecs il y a 14 ans.

2.2.2 Vision des joueurs de Go

Le Go est considéré par ses grands joueurs comme un jeu qui reflète la personnalité de celui qui y joue. Cela explique pourquoi dans le monde professionnel du Go, peu de gens croient en l’arrivée d’une intelligence artificielle capable un jour de les battre. De plus, ces joueurs sont censés faire évoluer le jeu et refusent de croire que ce sera finalement des ordinateurs qui arriveront à nous faire découvrir des

(11)

stratégies toujours plus proches des coups ultimes. Toutefois, même si on reste loin d’une intelligence artificielle capable de rivaliser avec eux, les progrès récents dans ce domaine risquent de finir par les forcer à remettre ce jugement en question.

2.2.3 Le problème de l’espace des possibles

Au Go, l’espace des possible est extrêmement grand. Tout d’abord, la taille du plateau est énorme. Le plateau possède 361 intersections. Cela en fait 6 fois plus que sur un plateau d’échecs. Ensuite, un coup consiste à poser une pierre sur n’importe laquelle des intersections libres. Soit au premier coup 361 possibilités contre 20 aux échecs. Une exploration des différentes évolutions possibles du plateau au Go sera donc beaucoup moins efficace qu’aux échecs, même en utilisant des algorithmes d’exploration partielle. Cela pose un premier gros problème aux programmeurs qui doivent réfléchir à de nouveaux types d’algorithmes.

2.2.4 Le problème de la mise en algorithme

Il est assez facile de faire une fonction d’estimation du score pour la plupart des jeux de stratégie. Sur tous ceux de la famille des échecs, cela dépend des pièces sur le plateau et de leurs emplacements. Au Go, il n’y a à ce jour aucun algorithme capable d’estimer une position de manière correcte avant la fin de partie. Cela est du au fait que l’estimation est basée à la fois sur un très grand nombre de paramètres, mais aussi sur le "ressenti" du joueur. Aucun joueur ne peut chiffrer de manière absolue une position de début de partie. Ils peuvent "préférer" la position de Noir ou celle de Blanc, mais sans donner de formule absolue permettant d’expliquer leur choix.

De la même façon, lorsqu’un joueur dira qu’un coup est meilleur qu’un autre, ce sera toujours basé sur des conditions trop floues pour être implémentées de manière algorithmique. Il est donc très difficile de faire un algorithme fonctionnant "comme un humain".

2.3 L’apport du Go aux intelligences artificielles

Le jeu de Go est intéressant d’un point de vue informatique parce qu’aucun algo- rithme connu n’est capable à ce jour de rivaliser avec un joueur professionnel sur une partie à égalité. Il stimule donc les programmeurs à trouver de nouveaux algorithmes pour atteindre cet objectif. Grâce à ces règles, son système de pierres d’avance, dites pierres de handicap pour le joueur le plus faible, et la fin de partie qui se finie par une différence de points entre les deux joueurs, il est facile de mesurer les progrès entre deux intelligences artificielles. De plus, les programmes tentant de fonctionner en prenant en compte les connaissances de l’humain sur le jeu n’étant pas les plus efficaces, on peut penser que les progrès en algorithmes créés pour ce défi seront cer- tainement utiles pour d’autre domaines de l’informatique. Les meilleurs programmes actuels ne sont d’ailleurs pas crées par de de grands joueurs de Go. Actuellement, les intelligences artificielles permettent de montrer l’efficacité d’algorithmes et com- ment ceux-ci peuvent être combinés. Ce sujet de recherche devrait donc rester encore longtemps ouvert et intéressant.

(12)
(13)

Chapitre 3

Les programmes jouant au Go

Sommaire

3.1 Mogo, le programme de référence . . . . 13

3.1.1 Comment marche Mogo . . . . 13

3.1.2 Les faiblesses de Mogo . . . . 14

3.2 Les autre programmes . . . . 14

3.2.1 Les autre programmes basés sur UCT . . . . 14

3.2.2 Les programmes basés sur d’autre méthodes . . . . 15

3.3 MachiaBot, le programme développé . . . . 15

3.3.1 Fonctionnement global . . . . 15

3.3.2 Protocole de test . . . . 15

3.1 Mogo, le programme de référence

Mogo1 est le programme de référence en matière d’intelligence artificielle dans le jeu de Go. Il a été crée par Sylvain Gelly2 et est développé par Olivier Teytaud3 au sein du LRI, dans l’équipe Apprentissage et Optimisation4. Il a été le premier à battre un joueur professionnel sur un plateau de taille 19x19. Le programme avait toutefois 9 pierres d’avance, mais cela représente tout de même une énorme avancée, car il aurait été impensable que cela arrive quelques années plus tôt. Il a aussi gagné de nombreuses compétitions de programmes de Go. Mais il garde toutefois plusieurs faiblesses.

3.1.1 Comment marche Mogo

UCT/RAVE

Mogo est basé sur l’algorithme UCT [CFC+08]. Il a été pensée à partir des algo- rithmes Bandit et Monte-Carlo.

L’idée initiale est de finir des parties aléatoirement et de regarder leur ratio de victoires pour essayer d’estimer la valeur d’un coup. Mais les parties aléatoires ne sont pas un indicateur assez précis : Les parties sont trop peu réalistes pour être représentatives. Les coups ne sont donc pas tirés de manière complètement aléatoires mais choisis en fonction de leur ratios précédents. Une définition plus précise de l’algorithme est donnée dans mon rapport de l’an dernier.

1. www.lri.fr/ gelly/MoGo.htm 2. www.lri.fr/ gelly

3. www.lri.fr/ teytaud/

4. http ://www.lri.fr/equipe.php ?eq=7

(14)

Une base de données de Patterns

Mogo est équipé d’un module de reconnaissances de Patterns de taille variable mais petite, utilisé dans le choix des coups de l’algorithme UCT. Les patterns ont été automatiquement récupérés à partir de bases de parties jouées par des joueurs professionnels. Cela permet à UCT d’avoir des parties encore plus réalistes et des probabilités de victoires pour les coups bien plus rapides. Cette base a grandement amélioré le jeu de Mogo.

3.1.2 Les faiblesses de Mogo

Les semiai

Les semiai sont des positions où deux groupes adverses proches sont en danger, et où la mort de l’un entraîne automatiquement la survie de l’autre. C’est donc souvent considéré comme un combat décisif, et bien le jouer est absolument nécessaire pour gagner la partie lorsque le cas se présente. Souvent, ce genre de situations contient un très grand nombre de coups à jouer, même si leur ordre n’est pas toujours impor- tant, mais il est souvent impératif de toujours jouer des coups concernant le semiai et de ne pas aller perdre un temps en allant jouer ailleurs sur le plateau. Mogo, même tournant sur une grosse machine a énormément de mal à gérer ce genre de situations[LWC+]. Mogo fait donc souvent des erreurs sur les grands semiai.

Les longues séquences

Il arrive parfois au Go qu’une assez longue séquence doive être joué dans un ordre précis pour être gagnante, et ou la moindre erreur peut être fatale. Mogo fait souvent des erreurs dans ce type de séquence dont il n’arrive pas à voir la fin. Ce type de séquence se produit moins souvent que les semiai, mais cette importante incapacité à isoler une séquence complète pousse Mogo à faire des erreurs dans certain combats.

Les erreurs stratégiques

Mogo a une nette tendance à joueur un jeu fortement orienté vers l’influence.

Ce style de jeu est lié à UCT qui donne souvent de meilleures probabilités pour les pierres défendant des territoires centraux. Cette stratégie d’influence est souvent mal équilibrée et semble défavoriser Mogo. Toutefois, pour l’instant, aucune solution n’a été trouvée pour corriger cette tendance sans que Mogo ne baisse de niveau.

3.2 Les autre programmes

3.2.1 Les autre programmes basés sur UCT

Beaucoup de programmes sont actuellement basés sur UCT, et réutilisent plus ou moins les mêmes idées que celles développées sur Mogo. On peut citer entre autres CrazyStone développé par Rémi Coulom à l’INRIA5, Fuego, développé par le “Computer Go Group“ l’université à l’Université d’Alberta6, Pachi, développé par Petr Baudis et Jean-loup Gailly qui est une réimplémentation de toutes les idées de Mogo7 et Zen, un programme commercial développé par un programmeur indépendant : Ojima Yoji8.

5. http ://remi.coulom.free.fr/CrazyStone/ [Cou06]

6. http ://fuego.sourceforge.net/ [EAS10]

7. http ://pachi.or.cz/

8. http ://soft.mycom.co.jp/pcigo/tencho2/index.html

(15)

3.2.2 Les programmes basés sur d’autre méthodes

Avant l’arrivée d’UCT, beaucoup de programmes utilisaient différentes techniques pour tenter d’avoir un programme jouant le mieux possible. Le plus connu est sans doute GnuGo, dont le développement a commencé en 1989, et qui a remporté plu- sieurs tournois jusqu’en 2006.

3.3 MachiaBot, le programme développé

MachiaBot est un programme que j’avais développé avec Guillaume Maurin en Master 1 dans le cadre de notre TER. Bien que peu puissant, sa structure permet de faire facilement des tests d’algorithmes.

3.3.1 Fonctionnement global

MachiaBot est basé sur trois modules : Un outil de reconnaissance de formes capable de reconnaître dans la partie des formes données précédemment par un expert, un gestionnaire de règles capable de transformer en code C++ des règles logiques données par un expert, et un module UCT/RAVE. Les trois modules ne sont pas indépendants mais travaillent en synergie. Le fonctionnement initial est détaillé dans le rapport de Master 1. Le module du dictionnaire de formes ainsi que le module UCT sont détaillés dans ce rapport, car ils ont servi au travail de recherche pendant le master 2. Le système expert ne sera par contre pas détaillé car il n’a que peu servi pendant les expérimentations menées ce semestre. Toutes les modifications qui ont été faites sur le programme pendant le stage sont détaillés dans les parties qui leurs correspondent.

3.3.2 Protocole de test

En plus des modifications internes au programme, un certain nombre d’outils ont dû être développés pour analyser le comportement du programme.

L’outil de traçage

Un outil permettant de voir graphiquement quels poids sont donnés par quel module pendant les parties a été créé. Il sert aussi à explorer le haut de l’arbre. Cela permet de vite comprendre d’où viennent les erreurs de MachiaBot et de mieux voir comment les algorithmes réagissent.

Le chargement de positions

Une fonctionnalité permettant à MachiaBot de démarrer sur une position donnée a été créée de façon à pouvoir le tester dans des cas particulier pour regarder sa réaction. Un jeu de test a aussi été mis en place pour vérifier après chaque change- ment quels étaient les types de situations dans lesquels le programme a progressé, et dans lesquels il a éventuellement régressé.

Les parties automatiques contre GnuGo

Le programme a la capacité de jouer à travers des interfaces graphiques, ce qui lui permet d’être utilisé de manière ludique par des joueurs humains. Toutefois, il est souvent plus simple pour le tester de le faire jouer contre un autre programme

(16)

de façon à avoir un adversaire de niveau constant toujours disponible. Un petit programme a été fait permettant de lancer MachiaBot contre GnuGo en boucle, et d’enregistrer les parties ainsi que les résultats.

(17)

Chapitre 4

UCT/RAVE

Sommaire

4.1 L’algorithme UCT . . . . 17

4.1.1 Monte Carlo . . . . 17

4.1.2 Bandit ou comment choisir les coups à explorer . . . . 18

4.1.3 UCT ou Bandit dans un arbre . . . . 18

4.1.4 Exemple de fonctionnement . . . . 19

4.2 Variantes et améliorations . . . . 20

4.2.1 RAVE . . . . 20

4.2.2 le choix des coups lors des parties . . . . 20

Le duo d’algorithmes UCT/RAVE est celui sur lequel sont basés tout les pro- grammes modernes jouant au Go. Nous allons dans un premier temps développer le fonctionnement d’UCT, puis nous verrons comment fonctionne son amélioration RAVE, et comment faut il envisager d’autres améliorations de l’algorithme.

4.1 L’algorithme UCT

UCT est basé sur deux algorithmes : Monte Carlo et Bandit. Nous allons dans un premier temps voir leurs fonctionnements indépendants, puis nous verrons comment ils se combinent pour donner l’algorithme UCT.

4.1.1 Monte Carlo

L’algorithme de Monte Carlo au Go pourrait se résumer de cette façon : on joue "au hasard" un grand nombre de parties, en commençant chaque partie par chacune des intersections jouables du Goban, et on comptabilise la proportion de parties gagnés. Puis on joue sur l’intersection ayant eu le meilleur ratio de victoires.

Quelques programmes ont tenté sans trop de succès d’utiliser Monte-Carlo pour le jeu de Go. Cela n’a pas du tout marché : il suffisait qu’un coup soit très mauvais si l’adversaire répondait bien, mais très bon dans les autre cas, pour que Monte-Carlo le considère comme probablement bon. Du fait que la réponse choisie par l’adversaire soit aléatoire, elle sera peu testée avec le bon coup adverse. D’une manière générale, finir les parties de manière complètement aléatoire ne donnait pas une indication fiable sur la qualité du coup.

L’algorithme UCT est extrêmement puissant, car il est polyvalent, et nécessite extrêmement peu de connaissances a priori sur le domaine sur lequel on va l’utiliser.

Par exemple, il peut être codé pour le jeu de Go juste en ayant lu les règles. Son but est d’explorer partiellement les branches de l’"arbre des possibles", en essayant de se

(18)

concentrer sur les plus intéressantes. Après avoir exploré une partie "suffisante" de l’arbre, il choisit la branche qui semble donner statistiquement les meilleurs résultats.

4.1.2 Bandit ou comment choisir les coups à explorer

UCT est basé sur l’algorithme de Bandit. C’est un algorithme utilisé dans des domaines très variés, demandant une fonction d’estimation des risques, ou de maxi- misation du profit. Un exemple d’utilisation, dont l’algorithme tire son nom, est celui du jeu optimal face à une série de machines à sous. Un joueur se trouve face à n machines à sous, il possède x jetons (un nombre de jetons très supérieur au nombre de machines à sous), et il veut optimiser son gain. On part du principe que les machines à sous ont toute une probabilité différente de gagner qui n’évolue pas au cours du temps. Le but est donc de trouver la machine qui a la meilleure probabilité de gagner pour y jouer un maximum de jetons.

L’idée de base est, comme pour Monte Carlo, de tester avec un certain nombre de jetons équivalent toutes les machines, et de jouer sur celle ayant offert le plus de victoires pendant la période de test. Bandit propose quelque chose de plus fin : L’idée est de jouer en priorité sur les machines ayant le plus de chances d’être la machine offrant le meilleur gain, pour affiner leurs statistiques, et petit à petit trouver la machine ultime. L’algorithme indique donc qu’il faut commencer par tester toutes les machines, puis se concentrer petit à petit sur celles qui nous ont offert jusque-là les ratio les plus intéressants, tout en jouant de temps en temps sur les machines sur lesquels on a très peu joué, pour ne pas risquer de sous-estimer une machine à cause d’une statistique trop floue due au manque de tests. Pour avoir le risque le plus faible dans le pire des cas, il faut prendre la machine m ayant le meilleur résultat à la formule :

Moyenne empirique pour m+

log(nombre de jetons total déjà joués)

nombre d’essais avec m

Ainsi, sans avoir aucune information a priori lorsque l’on commence à jouer les jetons, on joue statistiquement de manière de plus en plus optimale au fur et à mesure des jetons joués.

L’algorithme fonctionne de la même manière dans la plupart de ses applications : Le but est toujours de faire des tirages aléatoires d’événements après avoir modifié une ou plusieurs variables initiales, et de trouver quelles valeurs donner aux variables initiales pour maximiser le gain statistique, en orientant les tirages aléatoires pour avoir le résultat le plus précis possible sur les variables a priori les plus intéressantes.

4.1.3 UCT ou Bandit dans un arbre

Monte-Carlo peut trouver des coups corrects au niveau stratégique, mais est incapable de jouer correctement au niveau tactique, dès qu’il faut lire une série de coups. Le fait de choisir au hasard les coup pour finir les parties empêchent de regarder des séquences de combat cohérentes. UCT est beaucoup plus puissant car il utilise Bandit à chaque étage de l’arbre. Les coups de l’adversaire ne sont plus aléatoires, car lui même explore en priorité les branches qu’il a peu explorées ou celles qui lui donnent le plus de victoires possibles. Ainsi, les parties jouées sont plus réalistes, et les statistiques plus justes. De plus, les coups qui ont un meilleur ratio pendant que tourne l’algorithme sont plus explorés, le programme a donc plus d’informations sur eux, et une probabilité plus juste des chances de victoire.

(19)

Figure4.1 – Exemple d’un arbre UCT après 8 parties

4.1.4 Exemple de fonctionnement

L’arbre des possibles est l’arbre de toutes les parties possibles depuis une position donnée. Chaque noeud représente un coup, dans une position donnée (sauf le noeud racine). Chaque noeud connaît son coup, son nombre de passages et son nombre de victoires. Chaque descente vers un prochain noeud est choisi en fonction de la fonction donnée par Bandit. Une fois descendu sur un noeud, on met le goban à jour.

Une fois arrivé en bas, on regarde le score, on remonte la branche en incrémentant le nombre de victoire des coups de la couleur gagnante, et le nombre de passages de toutes les pierres. Puis on réinitialise le Goban à sa position initiale. A la suite d’un grand nombre de passages, on choisit le noeud ayant le meilleur ratio dans l’arbre, et on joue le coup qui lui correspond.

(20)

4.2 Variantes et améliorations

4.2.1 RAVE

RAVE est une grande amélioration pour UCT, surtout dans les cas ou l’on arrive sur des noeuds encore non ouverts, ce qui représente la majorité des descentes que l’on fait. Il part du principe que si un coup est très bon dans les autre branches, il l’est aussi dans celle que l’on est en train d’explorer. Il permet d’explorer en priorité le coup jouable ayant le meilleur ratio toutes branches confondues, lorsque l’on n’a aucun a priori sur les noeuds. Il peut aussi être utilisé comme un complément à l’estimation donnée par bandit : Le score d’un noeud n peut être donné comme (a x Bandit ?(n)) + ((1 - a) x Rave(n)))

4.2.2 le choix des coups lors des parties

Une question extrêmement difficile à régler est de savoir si il faut ou non orienter l’algorithme durant les parties aléatoires. Il est effectivement assez facile d’augmen- ter la qualité des parties aléatoires sans que cela soit trop coûteux en ressources.

De plus, il semble extrêmement important de le faire, car de mauvaises parties aléa- toires poussent le programme à rater un grand nombre de séquences. Pour autant, il arrive que certaines techniques qui augmentent la qualité des descentes fassent pa- radoxalement baisser le niveau d’UCT. La question reste donc de toujours trouver des techniques qui améliorent la qualité des descentes mais qui n’empêchent jamais de jouer un bon coup et qui restent assez floues pour que le programme ne se bloque pas sur un style de jeu. Les deux prochains chapitres proposent des solutions pour obtenir des parties plus réalistes pour UCT/RAVE.

(21)

copie.png

Figure4.2 – Exemple d’un arbre UCT après 7 parties. RAVE indique que le coup G4 est un bon coup car il a obtenu de bons résultats dans d’autres parties.

(22)
(23)

Chapitre 5

Détection de zones importantes grâce à UCT

Sommaire

5.1 Détection des zones de combat . . . . 23

5.1.1 L’idée originale . . . . 23

5.1.2 Les formules de détection . . . . 24

5.1.3 Comparatif . . . . 24

5.1.4 L’utilisation des zones détectées . . . . 24

5.1.5 Efficacité . . . . 24

5.2 Détection des zones neutres . . . . 26

5.2.1 Qu’est ce qu’une zone neutre ? . . . . 26

5.2.2 Comment les détecter ? . . . . 26

5.2.3 Comment les utiliser ? . . . . 26

5.2.4 Efficacité . . . . 27

Les problèmes tactiques d’UCT viennent d’un problème de dispersion de la part d’UCT : incapable de se concentrer dans une zone, ses coups se dispersent sur tout le Goban et il a énormément de mal à se concentrer sur les endroits du Goban à gérer en priorité.

5.1 Détection des zones de combat

Une information qui peut être capitale pour le choix d’un coup est d’arriver à définir la zone dans laquelle le combat le plus important a lieu. Souvent, lorsqu’un combat se déroule pendant une partie, le vainqueur du combat prend un avantage décisif pour la suite de la partie. Hors il arrive que des programmes basés sur UCT n’arrivent pas à percevoir de coups décisifs sur le combat et jouent à un autre endroit du Goban, permettant au joueur adverse de gagner le combat. Détecter une zone de combat et forcer le programme à jouer à l’intérieur semble une bonne solution pour obtenir une forte progression pour les programmes basés sur UCT. Des travaux autour de ces idées ont déjà été fait à l’université de Lille.

5.1.1 L’idée originale

Une zone de combat est une zone dont le contrôle va définir le joueur victorieux.

Une idée simple pour les détecter consiste à utiliser les parties finies par UCT/RAVE et de regarder en moyenne quelle case est contrôlé lors d’une victoire. Si des cases sont détectés comme apportant très régulièrement la victoire à celui qui les contrôle, c’est qu’elles sont très probablement sur une zone de combat.

(24)

5.1.2 Les formules de détection

Une formule pour détecter ce type de zone existe. Elle a été proposé par Rémi Coulom dans [Cou10]

c(x) = v(x)N −(w(x)N × WN + b(x)N ×NB) avec :

– N : nombre de parties ;

– N/B : parties gagnés par Noir/Blancs ;

– n(x)/b(x): partie ou l’intersection x est contrôlée par Noir/Blancs ; – v(x) : partie ou l’intersection x est contrôlée par le vainqueur.

C’est une formule assez efficace mais qui peut être prise en défaut par certaines si- tuations. J’ai essayé de trouver un algorithme permettant une détection plus précise de ces zones. L’idée est de reprendre la formule initiale mais en modifiant légèrement son fonctionnement. Les cases voisines des cases à contrôler sont considérées comme à contrôler aussi, car le besoin de contrôler une case indique souvent la nécessité de jouer sur une case voisine. Cela augmente le poids des intersections entourées d’in- tersections ayant un gros poids. Lorsqu’une intersection sur laquelle il y a une pierre dans la position initiale est contrôlée par le camp adverse, les intersections voisines sont incrémentées deux fois, car elles indiquent un endroit ou une capture peut être faite. Cela permet de détecter plus fortement les zones contenant de nombreuses pierres que les zones n’en contenant pas.

5.1.3 Comparatif

Il est assez difficile d’obtenir un jugement objectif des formules, puisque leur efficacité va dépendre de la façon dont l’information obtenue va être utilisée, et sur la façon dont l’algorithme UCT est implémenté. Les tests ont donc été faits sur des positions de combat où une séquence permet à noir de gagner le combat, et où tout autre séquence le fait perdre. Le programme est lancé et à la fin, les deux zones détectées par les deux formules sont comparées. Le critère de qualité est le nombre de coups de la séquence gagnante pour noir présent dans la zone.

Sur plusieurs jeux de tests en situation de combat, plusieurs coups appartenant à la séquence optimale du combat n’appartenaient pas à la zone détectée par la première formule et étaient détectés par la version modifiée. Par contre, il n’y a eu aucun cas ou l’inverse s’est produit. Toutefois, il arrive que l’algorithme modifié proposé considère plus facilement certaines cases comme sensibles alors qu’elles ne le sont pas.

5.1.4 L’utilisation des zones détectées

Une fois une zone détectée, il faut arriver à trouver la séquence optimale pour gérer le combat. L’idée logique est de forcer UCT à explorer ces zones en priorité.

Cela lui permet théoriquement d’être plus réaliste sur la façon dont la partie va se dérouler.

5.1.5 Efficacité

L’algorithme modifié arrive bien à montrer les zones de combat importantes lors- qu’il y en a. Toutefois, dans des parties plutôt calmes, il lui arrive de considérer certaines zones comme importantes sans raison logique.

(25)

Figure5.1 – zones de combat détectées. En haut, la zone dans laquelle les séquences de combats réalistes peuvent avoir lieu. A gauche, la détection des zones avec la première formule. A droite, la détection des zones avec la formule proposée.

Figure 5.2 – zones de combat détectées dans une position ou il n’y a pas de combats. A gauche, la détection des zones avec la première formule. A droite, la détection des zones avec la formule proposée. La formule modifié détecte des zones de manière plus formelle que la première alors que l’objectif serait qu’elle ne détecte rien.

(26)

5.2 Détection des zones neutres

5.2.1 Qu’est ce qu’une zone neutre ?

Assez rapidement, dans une partie de Go, un joueur est capable de dire quel territoire semble être à lui et quel territoire semble appartenir à son adversaire. Dans une partie équilibrée, l’objectif est de prendre le contrôle du territoire le plus neutre possible. En effet, jouer au milieu du territoire clairement contrôlé par l’adversaire est une mauvaise idée puisque la pierre qu’on y met est clairement condamnée à mourir, et jouer dans son propre territoire est un coup lent qui ne permet pas d’agrandir son potentiel de points.

5.2.2 Comment les détecter ?

Idée initiale

Au moment du choix d’un coup, que ce soit pendant les descentes d’UCT ou au moment du choix final d’un coup pendant une partie, le programme dispose d’un certain nombre de parties aléatoirement finies par UCT. En regardant quelles intersections sont en moyenne contrôlées par un joueur spécifique, on peut facilement avoir une idée du contrôle des zones par chaque joueur. Les intersections qui sont contrôlées 50% des parties par un joueur et 50% par l’autre sont les plus neutres.

Enfin, plus elles sont proches de cette répartition, plus elles sont neutres.

Amélioration

Lors d’une partie déséquilibrée, il ne faut pas forcement tenter de jouer dans les zones neutres, mais chercher à renverser la position si on est en retard, ou alors à stabiliser son territoire si on est en avance. En fonction du nombre de parties gagnés en moyenne, la zone neutre se déplace. Si le programme est en avance, il va placer la zone neutre sur des cases qu’il a plutôt tendance à contrôler, mais qui restent relativement instables, si il est en retard, il va la placer vers les cases qui sont en moyenne plutôt contrôlées par son adversaire.

Formule

La neutralité de chaque case est calculé par cette formule :

N−abs((n(x)−b(x))+(N−B)) N

avec :

– N : nombre de parties ;

– N/B : parties gagnés par Noir/Blancs ;

– n(x)/b(x): partie ou l’intersection x est contrôlée par Noir/Blancs ;

5.2.3 Comment les utiliser ?

Une fois les zones neutres détectés, elles permettent deux choses : D’abord de pousser le programme à jouer plutôt sur les intersections marquées comme neutres, mais aussi de pousser UCT à jouer en priorité sur ces cases pour avoir des parties plus réalistes lors des descentes.

(27)

Figure5.3 – zone neutres détectée

5.2.4 Efficacité

De la même façon que pour les zones de combat, la détection des zones neutres est très fonctionnelle dans certains cas et absolument pas dans d’autres. Dans les cas ou la partie est principalement stratégique et ou il n’y a pas de combats, les zones neutres sont bien détectées, et elles offrent une bonne estimation des endroits ou il est intéressant de jouer. Mais contrairement à la détection des zones de combat, l’algorithme des zones neutres, même dans les situations ou il est le moins efficace, ne donne jamais une information qui pourrait induire le programme en erreur.

(28)
(29)

Chapitre 6

Proposition de modifications du fonctionnement pour UCT/RAVE

Sommaire

6.1 Les défauts intrinsèques de RAVE . . . . 29

6.2 Améliorations mineurs de RAVE . . . . 29

6.2.1 Ordonner les coups . . . . 29

6.2.2 Aléatoiriser les coups . . . . 29

6.3 Amélioration pour les branches peu explorées . . . . 30

6.4 Amélioration hors de l’arbre . . . . 30

6.1 Les défauts intrinsèques de RAVE

Le principal défaut de RAVE est qu’il ne tiens pas compte des coups précédem- ment joués pour proposer un coup. Les coups proposés sont donc souvent bons lorsque la partie est calme et qu’il y a besoin de trouver des coups stratégiques importants, mais sont très mauvais dans des situations de combat où chaque coup joué va changer complètement la façon dont il faut réfléchir à la suite de la partie.

6.2 Améliorations mineurs de RAVE

6.2.1 Ordonner les coups

L’idée de RAVE est de se dire que chaque coup est potentiellement responsable du score de la partie (que ce soit une victoire ou une défaite). Le but est d’estimer la probabilité de l’utilité d’un coup en fonction de cela. Mais la question de savoir si tous les coups ont la même probabilité d’être un responsable important du score de la partie se pose. La nouvelle idée proposée part du principe qu’un coup joué au début a une responsabilité plus grande sur le score qu’un coup joué à la fin. Cela se traduit par un changement plus rapide des poids des coups joués au début par rapport aux poids des coups joués à la fin.

6.2.2 Aléatoiriser les coups

Assez vite, les parties guidées par RAVE ont une nette tendance à se ressembler, tant au niveau du déroulement qu’au niveau du score. Cela a un coté logique du fait que RAVE permet de générer une liste ordonnée des meilleurs coups possibles, mais la liste n’étant pas toujours parfaite (sinon le problème de la construction

(30)

d’une Intelligence Artificielle jouant parfaitement au Go serait résolu), il est mauvais que les parties se ressemblent trop. Le changement proposé est de faire des sauts aléatoires lors du parcours de la liste triée, pour ne pas forcement jouer le premier coup disponible de la liste.

6.3 Amélioration pour les branches peu explorées

Le premier endroit où RAVE sert énormément est lorsque UCT arrive dans les branches les plus éloignées où tout les fils n’ont pas été visités, ou très peu. A ce moment la, il doit théoriquement se fier à RAVE alors que celui ci ne tient absolument pas compte de la branche dans laquelle il se trouve. L’idée est alors d’utiliser le grand père du noeud dans lequel on se trouve pour lui demander les ratios de ses fils. Cela donne une information extrêmement précieuse puisque l’on a ainsi une probabilité assez précise (le grand père d’un noeud a environ(nombre d’intersection du goban)2 fois plus de passages que son petit fils) de la qualité des coups à deux pierres près posées sur le goban. En multipliant le quotient de diversification d’un coup par sa valeur en tant que fils pour son grand père, on obtient une première valeur pour les noeuds peu explorés qui est souvent assez réaliste.

6.4 Amélioration hors de l’arbre

Une fois arrivé hors de l’arbre, la version classique UCT/RAVE n’offre plus au- cune information de la qualité d’un coup par rapport à la position donnée. L’es- timation de RAVE ne dépend absolument pas de la façon dont la partie faite par UCT a évolué depuis la situation initiale. L’objectif serait de trouver un algorithme semblable à RAVE, mais dont les valeurs proposées dépendent de la position. Une idée intuitive est alors de donner la valeur de chaque coup possible par rapport à un unique coup précédemment joué. Par exemple, pour une pierre noire posée en C3, quel que soit le moment où elle est posée depuis la position initiale, on possède un tableau qui contient tout les poids des coups blancs potentiels si il y a une pierre Noir en C3, ainsi qu’un tableau pour tout les coups noirs potentiels dans ce même cas. Ensuite, lors de l’estimation d’un coup d’une couleur dans une position donnée, il suffit de faire la somme de tout les tableaux concernant cette couleur et dont le coup correspondant a été joué, pour avoir des estimations des coups dépendants de la situation, et indépendants de l’ordre dans lequel les coups précédents ont été joués. Ces tableaux sont ensuite mis à jour comme RAVE l’était, en fonction de la victoire ou de la défaite des parties dans lesquelles les coups ont été joués. Par exemple, si noir a joué C3 au troisième coup et qu’il a remporté la victoire, tout les coups noirs après le troisième coup vont voir leur probabilité d’être un bon coup dans le tableau de C3 augmenter, et tout les coups blancs leur probabilité baisser.

Cet algorithme est compatible avec l’idée développé dans la partie ”Ordonner les coups“ : On peut faire évoluer de manière plus forte le poids des coups étant joués juste après un coup que ceux joués longtemps après.

(31)

Figure6.1 – A gauche une partie jouée par UCT depuis une position initiale contenant 4 pierres, à droite les poids des coups blancs en considérant la pierre jouée dans la partie UCT. L’estimation d’un coup est donnée par la somme des estimations des tableaux correspondants aux coups joués avant.

(32)
(33)

Chapitre 7

Comment guider UCT grâce à de la connaissance humaine ?

Sommaire

7.1 Le fonctionnement du dictionnaire . . . . 33

7.1.1 La reconnaissance d’une forme depuis le dictionnaire en arbre . . . . 33

7.1.2 Amélioration : pierres "importantes" . . . . 34

7.1.3 Le dictionnaire par base de données de parties . . . . 34

7.2 Utilisation des informations obtenues . . . . 35

7.2.1 Construction du haut de l’arbre . . . . 35

7.2.2 Préconstruction de RAVE . . . . 36

Dans des situations compliquées, UCT, à cause du gigantesque espace des pos- sible, a du mal à converger vers une séquence réaliste. Il rate donc par exemple certains coups qui ne sont bon que dans le cas ou la séquence qui suit est jouée cor- rectement, et mauvais sinon. Lorsqu’un être humain va lire une séquence de coups au Go, il va regarder en priorité des coups qu’il reconnaît grâce à des connaissances conscientes et inconscientes, et ne lire que les coups qui lui semblent crédibles. C’est un énorme avantage par rapport à UCT. La principale information consciente qu’uti- lise un être humain à ce moment là, est la reconnaissance de formes. Il est capable de reconnaître des patterns, plus ou moins simples, et de savoir grâce à eux si un coup semble bon ou non. Si UCT était capable de choisir tout ces coups avec la connais- sance humaine des formes, il deviendrait sûrement extrêmement fort. Le programme utilise un dictionnaire de formes. Nous verrons d’abord comment il fonctionne, puis comment il est utilisé pour guider UCT.

7.1 Le fonctionnement du dictionnaire

La reconnaissance de formes par notre programme est basée sur une série de dictionnaires de forme. Les formes sont stockées au format SGF. A la base destiné à être utilisé pour stocker les parties de tous types de jeux, ce format est principalement utilisé pour le jeu de Go. Il enregistre les parties et leurs variations sous forme d’arbres, et permet d’ajouter des symboles et commentaires à chaque position de la partie. Il existe plusieurs éditeurs, dont certains open source. L’éditeur Mugo a principalement été utilisé pour remplir le dictionnaire.

7.1.1 La reconnaissance d’une forme depuis le dictionnaire en arbre L’algorithme implémenté permet de reconnaître des formes même si celles-ci ne sont pas entrées dans le bon ordre, et peut reconnaître plusieurs formes pour une

(34)

même intersection. L’idée est de regarder le coup proposé par chaque branche, et de voir si il est dans la liste de l’intersection sélectionnée. Une fois cela fait, tous les noeuds par lesquels la recherche est passée et où la dernière pierre posée est de la couleur demandée (blanche si on lit une forme appartenant à la couleur du programme, noire sinon) sont considérées comme des formes reconnues.

La forme de la pierre noire marquée d’un cercle contient les autres pierres dans sa liste de voisins.

Toutes les pierres filles par lesquelles l’algorithme de recherche est passé, et qui sont entourées, renvoient le poids de leurs noeuds fils.

Ainsi l’intersection entre les deux pierres noires (-1 ;0) vaut 55 car un noeud l’incrémente de 50 et l’autre de 5.

L’arbre complet passe dans cette situation par un nombre de noeuds très supérieur et renvoie un nombre de poids beaucoup plus important.

Les poids posés sur des pierres seront par la suite annulés par le système qui gère les dictionnaires.

7.1.2 Amélioration : pierres "importantes"

Dans certaines situations, il arrive que des pierres soient considérées comme non- importantes, et qu’elles ne doivent pas être prises en compte lorsque l’on fait une recherche dans une zone. Pour cela, la personne remplissant le dictionnaire peut indiquer une "zone d’importance". Lorsque l’on arrive au bout d’une branche (plus aucune sous branche ne correspond à un des coups de la forme donnée), on regarde les pierres voisines restantes. Si elles sont hors de la zone d’importance dans la position courante de la branche, la position reste validée comme une forme dont il faut tenir compte.

7.1.3 Le dictionnaire par base de données de parties

Une idée développée par beaucoup d’autres programmeurs a été de faire une base de données géante contenant des milliers de parties professionnelles, puis d’extraire des positions locales de ces parties, ressemblant à des positions locales de la partie

(35)

jouée par le programme. Ce système a pour avantage de ne pas avoir à faire remplir manuellement des dictionnaires, et possède donc un dictionnaire beaucoup plus étoffé que le système implémenté. Mais ce système a deux défauts : Le premier est qu’il est impossible lorsque le programme fait un mauvais coup de "corriger" la base de données. Le deuxième est que lorsque le programme se retrouve face à un joueur faible, sa base de données qui ne contient que des "bonnes formes" ne trouve aucune forme et ne pourra pas "punir" les erreurs de son adversaire.

7.2 Utilisation des informations obtenues

7.2.1 Construction du haut de l’arbre

idée

L’objectif du dictionnaire n’est absolument pas d’obtenir des informations sur une position fixe du goban, mais d’arriver à prévoir à l’avance le déroulement de séquences. Avant de lancer UCT, le programme construit donc les premiers étages de l’arbre en fonction de l’information, de façon à ce qu’UCT sache quelles séquences explorer en priorité, et lesquelles ignorer. Cela va donner des séquences beaucoup plus réalistes dans les premiers coups lors des premières descentes, et permettre à UCT de faire une exploration plus complète sur les branches les plus crédibles.

Algorithme

L’idée globale est de construire le premier étage de l’arbre en fonction des poids proposés par le dictionnaire de formes, puis les fils des coups estimés comme ceux qui auront le plus de chance d’être joués au premier étage, et ainsi de suite, tout en réduisant le nombre de fils créés à chaque coup pour éviter que l’algorithme soit trop gourmand en temps.

(36)

PreConstruireArbre(Goban g, int nombre , noeudUCT * n){

Detecter les formes sur le Goban g;

Pour toutes les coups de formes détéctés sur le Goban { Si le noeud fils correspondant n’a pas encore été crée {

Creer un noeud fils à n correspondant au coup de forme

avec un poid égal à l’importance du coup de forme / nombre;

Si importance du coup de forme > nombre { Goban g2 = g;

jouer le coup de forme sur g2

preConstruireArbre avec pour parametre g2,

nombre x Coefficient / (importance du coup de forme), fils de n construit;

} }

} sinon {

modifier le noeud fils correspondant au coup de forme en fonction de l’importance du coup de forme / nombre;

} }

7.2.2 Préconstruction de RAVE

Dans la version classique de RAVE, le guidage peut se construire par l’augmen- tation du poids des coups qui sont considérés comme étant de bonnes formes. Dans la version modifiée proposée, les formes offrent une information beaucoup plus im- portante. En effet, en regardant tous les coups de forme existants après chaque coup possible, tout les tableaux donnant la valeur d’un coup après un certain coup joué peuvent être préremplis. Cette préconstruction est extrêmement intéressante car la version de RAVE proposée met plus de temps à converger.

(37)

Chapitre 8

Conclusion

8.1 Résultats

Programme Résultats

M (Version fin du Master 1) 0 %

M + détection des Zones 5 %

M + détection des Zones + préconstruction de l’arbre 15.5 %

M + détection des Zones + préconstruction de l’arbre + Nouvelle version de RAVE 26 % M + préconstruction de l’arbre + Nouvelle version de RAVE 24 %

M + détection des Zones + Nouvelle version de RAVE 20 %

Les résultats sont des tests de MachiaBot contre le programme GnuGo dans sa dernière version, sur des plateaux de taille 9x9. Ils sont réalisés avec 50.000 descentes pour Machiabot. Les quatre premiers résultats sont basés sur 200 parties. Les deux derniers ne sont basés que sur 50 parties. Avec des paramètres identiques, Mogo fait autour de 90 % de victoires (testé sur 20 parties).

8.2 perspectives

Le programme dans sa version actuel a connu de grandes améliorations par rap- port à son état à la fin du master 1. Cela démontre la qualité des algorithmes proposés tout au long de ce rapport. De plus, chaque algorithme semble offrir une amélioration au programme quel que soit les autre modifications qu’il ai recut. Tou- tefois, pour des raisons de manque de temps, plusieurs améliorations implémentées sur Mogo n’ont pas été implémentées sur le programme développé, ce qui fait que le programme test reste à ce jour à un niveau inférieur à celui des meilleurs programmes actuels. Cependant, les améliorations proposées dans ce rapport et celles développés sur Mogo n’étant pas incompatibles, il semble assez probable que l’implémentation des idées proposées sur un programme dont la conception serait similaire à celle de Mogo permettent une amélioration du programme.

(38)
(39)

Chapitre 9

Documentation

Sommaire

9.1 Lexique . . . . 39 9.1.1 Vocabulaire sur le jeu de Go . . . . 39 9.1.2 Programmes . . . . 40

9.1 Lexique

9.1.1 Vocabulaire sur le jeu de Go

Vocabulaire de "phases" dans une partie :

Fuseki: début de partie, ou ouverture Chuban: milieu de partie

Yose: fin de partie

Joseki(séquence théorique) : séquence de début classique dans un coin ou sur un bord, amenant à une bonne situation pour les deux joueurs

Vocabulaire de base

Goban : Plateau de jeu.

Intersection : Le Go se joue sur les intersections entre les lignes du goban.

Pierre : Nom donné aux "pions" que posent les joueurs, chacun à leur tour sur le goban.

Groupe : Un groupe est un regroupement de pierres directement reliées entre elles. Un groupe est dit "mort" lorsqu’il n’a plus aucune chance de faire deux yeux.

Il n’est pas enlevé du plateau tant qu’il lui reste des libertés, mais sera considéré comme mort à la fin de la partie. Un groupe qui a deux yeux est dit "vivant".

Oeil: Un oeil est une intersection entourée par quatre pierres appartenant à un même groupe.

Atari : une pierre ou un groupe de pierres est en Atari lorsqu’il n’a plus qu’une liberté, et est donc en position d’être capturé au coup suivant.

Liberté: Une liberté d’un groupe est une intersection libre à côté de ce groupe.

Un groupe qui n’a plus aucune liberté est mort et retiré du plateau.

Tsume-go : étude de vie et de mort des groupes

Te-nuki : coup ignorant la dernière menace de l’adversaire pour jouer ailleurs Sente : un coup " Sente " permet de prendre ou de conserver l’initiative Gote : un coup " Gote " fait perdre l’initiative

(40)

Shisho : Un shisho ("Chemin à une liberté") est une situation ou pendant toute une séquence de coups, un groupe va tenter de s’enfuir, mais ne pourra jamais avoir plus de deux libertés. Un shisho peut finir par une connexion avec une pierre du groupe qui tente de se sauver, ou par la mort du groupe.

Ko : Un ko ("Eternité") est un point du goban où une pierre est en prise, mais où sa prise créerait une répétition de position, ce qui pourrait amener une partie sans fin, la position pouvant revenir éternellement. La pierre ne peut donc être prise immédiatement.

Menace de Ko : Coup senté sur le plateau, pour tenter de forcer l’adversaire à répondre, pour pouvoir ensuite reprendre une pierre de Ko, ou récpuérer des points si l’adversaire n’a pas répondu.

Influence: Les pierres qui font de l’influence sont les pierres donnant de la force à un joueur sur une grande zone du goban. Les zones d’influence sont plus vastes mais moins solides que les zones de territoires. Les zones d’influence peuvent servir à être transformées en territoire ou à pousser l’adversaire à les attaquer pour lancer des combats favorables.

Territoire: Des pierres qui font du territoire sont des pierres qui défendent une partie du goban de manière solide de façon à garantir des points en fin de partie.

Ces pierres sont en générales plus proches les unes des autres, et plus proches du bord que les pierres faisant de l’influence.

Tengen : Intersection centrale du goban.

Vocabulaire de base pour les coins

Hoshi (étoile) : point 4-4 dans un coin San-san : point 3-3 dans un coin

Ko-moku : point 3-4 dans un coin

9.1.2 Programmes

Many faces of Go : Une des plus anciennes intelligence artificielle de Go. Pro- gramme commercial.

Mugo : Editeur de fichiers SGF pouvant servir d’interface graphique grâce au protocole GTP. Programme Open-Source.

Mogo : Intelligence artificielle de Go française, créée à l’institut universitaire Paris-Sud 11, basée sur UCT/Rave.

Zen : Intelligence artificielle de Go récente. Programme commercial.

Gnugo : Une des premières intelligences artificielles de Go.

CrazyStone : Un programme développé par Rémi Coulom à l’INRIA

fuego : Un programme développé par le “Computer Go Group“ l’université à l’Université d’Alberta.

Pachi : Un programme récent développé par Petr Baudis et Jean-loup Gailly qui est une réimplémentation de toutes les idées de Mogo dans une version open-source.

Zen : un programme commercial développé par Ojima Yoji.

Figure

Updating...

Références

Sujets connexes :