Nous avons entraîné CUBE Backgammon à jouer comme GNU Backgammon, mais ses coups étaient moins bons

Quand vous demandez un indice au coach de CUBE Backgammon, il compare les positions que laisseraient les différents coups légaux. Un réseau de neurones l’aide à estimer les chances de gagner à partir de ces positions. Ce réseau apprend à partir d’exemples analysés par GNU Backgammon, un moteur de jeu reconnu, afin de fournir rapidement ses propres estimations sur votre téléphone.

Pendant le développement, nous avons essayé de lui donner davantage d’exemples pour apprendre. L’analyse obtenue proposait plus souvent le même coup que GNU Backgammon, ce qui nous a conduits à publier brièvement cette version. Mais lorsque nous avons vérifié les coups en simulant la suite des parties, les nouvelles versions ont donné de moins bons résultats dans l’ensemble. Nous sommes revenus à la version précédente.

Ce que mesure le score d’accord

Nous présentons cet apprentissage dans notre article sur le fonctionnement du coach. GNU Backgammon fournit des évaluations de positions, et un réseau de neurones plus léger apprend à reproduire ces évaluations. C’est en ce sens que GNU joue le rôle de professeur.

Pour vérifier le résultat, nous comptions les positions où l’analyse utilisant notre réseau préférait le même coup que GNU. Puisque GNU joue généralement bien, un score d’accord plus élevé semblait annoncer de meilleurs conseils.

Ce raisonnement a une limite : même un bon moteur peut se tromper. Apprendre à reproduire ses réponses plus fidèlement peut aussi reproduire ses erreurs. Le score d’accord ne distingue pas une bonne réponse d’une erreur partagée par les deux moteurs.

Le test qui nous a fait revenir à la version précédente

La version publiée avait gagné 2,2 points de pourcentage sur ce score d’accord. Nous avons ensuite comparé six versions entraînées au cours de cette expérience à la version déjà en place, sur un ensemble distinct de positions évaluées par rollout.

Un rollout compare les coups en jouant de nombreuses suites possibles à partir de chacun d’eux. Il prend davantage de temps et reste une estimation, puisqu’on ne joue qu’un nombre limité de suites. Nous pouvions alors mesurer à quelle fréquence chaque version testée choisissait le coup préféré par les rollouts.

Sur les six versions entraînées, l’accord moyen avec le coup préféré par les rollouts avait reculé de 2,6 à 3,4 points de pourcentage, selon la manière d’utiliser le réseau pour choisir les coups. Ces chiffres sont les moyennes des essais suivants ; ils sont distincts du gain de 2,2 points de la version publiée au départ. Les résultats individuels variaient, et une version progressait dans un des tests, mais l’ensemble ne justifiait pas de conserver le changement.

Score ayant motivé la publication+2,2

points d’accord avec GNU pour la version publiée

Comparaison distincte par rollout−2,6 / −3,4

points d’accord avec les rollouts en moyenne sur six versions, selon la configuration du test

Variations en points de pourcentage. Le premier chiffre concerne la version publiée, les autres la moyenne des essais suivants. Ce ne sont pas des classements de joueur.

La comparaison portait sur un nombre limité de positions. Elle ne pouvait pas prévoir le comportement du logiciel dans toutes les parties possibles, mais montrait pourquoi le meilleur score d’accord ne suffisait pas à justifier la publication.

L’accord ne mesure pas le coût des erreurs

Imaginez deux coups légaux de valeur presque identique. Notre analyse choisit le second et GNU le premier. Le score compte un désaccord, même si la différence est négligeable en pratique.

Dans une autre position, un coup laisse une frappe coûteuse et l’autre l’évite. Se tromper compte là aussi pour un désaccord. Le score traite de la même façon deux décisions pourtant très différentes.

Si le coup préféré par GNU est lui-même légèrement moins bon, le reproduire peut faire monter le score d’accord tout en abandonnant un meilleur choix. C’est une limite possible de l’apprentissage à partir d’un professeur ; notre expérience ne prouve pas qu’elle explique chacun des moins bons coups observés.

Pour le joueur qui demande un indice, le coût de l’erreur compte. Hésiter entre deux coups presque équivalents est très différent de conseiller un coup qui réduit nettement les chances de gagner. Un simple décompte de réponses identiques ne mesure pas ce coût. Dans notre test des conseils du coach sur 47 matchs de tournoi, nous avons vérifié si les corrections proposées par CUBE Backgammon amélioraient réellement les coups déjà joués.

Ce que nous avons changé dans nos tests

Nous avons cessé de considérer l’accord avec le moteur qui sert de professeur comme une preuve suffisante pour publier un changement. Il faut aussi comparer les coups à une référence distincte, estimer le coût des erreurs et vérifier le résultat face à la version déjà utilisée par les joueurs.

Les positions du test doivent rester séparées des exemples d’apprentissage. Comparer les nouvelles versions et l’ancienne dans les mêmes conditions évite aussi d’attribuer au réseau une différence qui viendrait du déroulement du test.

Notre expérience ne démontre pas que davantage de données d’apprentissage soit généralement nuisible. Elle montre que, dans ce cas précis, mieux reproduire les réponses de GNU n’a pas donné de meilleurs choix sur le test par rollout.

Ce que ces scores disent du niveau de jeu

Choisir plus souvent le coup préféré par les rollouts renseigne sur la qualité du jeu de pions. Cela ne suffit pas à attribuer un Elo à CUBE Backgammon ni à le comparer à des joueurs professionnels. Notre article sur le niveau du moteur explique ce que demanderaient ces comparaisons.

Le logiciel qui effectue la comparaison doit lui aussi être vérifié. Dans une autre expérience, nous avions indiqué au moteur de référence le mauvais joueur pour lancer les dés sur la moitié des positions. Corriger cette erreur a changé la version que le test donnait gagnante.