Une première comparaison indiquait qu’une version de développement de CUBE Backgammon choisissait de meilleurs coups que la version qui lui servait de référence. Nous avons demandé au moteur de backgammon Open Sage d’évaluer les mêmes décisions. Il ne confirmait pas le progrès observé ; nous avons donc écarté le changement.
Nous avons ensuite trouvé une erreur dans le code qui transmettait les positions à Open Sage : sur la moitié des cas, il indiquait le mauvais joueur pour le prochain jet. Le moteur évaluait donc une situation différente de celle que nous voulions comparer.
La position ne se limite pas aux pions
Une capture d’écran montre où se trouvent les pions, sans forcément indiquer qui joue ensuite. Cette information peut changer considérablement la valeur d’une position, même si le plateau est parfaitement symétrique.
Prenons un exemple volontairement réduit. Chaque joueur a sorti 14 pions et en conserve un sur son propre point 4. Leur compte de course est identique : quatre pips de la sortie. L’exemple se joue sans videau, et il n’y a plus de gammon possible.
Qui lance les dés ?
Ivoire et Rouge ont chacun un pion à quatre pips de la sortie.
Lire la position en texte
Ivoire, point : nombre de pions. 4: 1. Rouge : 21: 1. À la barre : ivoire 0, rouge 0. Sortis : ivoire 14, rouge 14.
Ivoire lance les dés en premier.
Victoire d’Ivoire94,8 %
Victoire de Rouge5,2 %
Calcul exact : 307/324 pour le premier joueur, 17/324 pour l’autre. Le plateau reste identique.
Le joueur qui lance les dés en premier a environ 94,8 % de chances de gagner, contre 5,2 % pour l’autre. Changer le joueur au trait modifie la réponse de près de 90 points de pourcentage, sans déplacer le moindre pion.
Pourquoi le premier joueur est autant favori
Seuls deux jets ordonnés ne permettent pas de sortir immédiatement un pion du point 4 : 1–2 et 2–1. Tous les autres suffisent. Même 1–1 permet de sortir, puisqu’un double donne quatre déplacements.
Le premier joueur gagne donc immédiatement sur 34 des 36 jets. Sur chacun des deux autres, son pion arrive au point 1. L’adversaire gagne à son tour sur 34 jets ; s’il échoue lui aussi, le premier joueur sort sur n’importe quel jet suivant.
La chance de gagner du premier joueur vaut donc 34/36 + (2/36 × 2/36), soit 307/324. Les 17/324 restants reviennent à l’autre joueur. C’est un décompte exact des possibilités des dés, pas l’estimation d’un réseau de neurones.
Nous avons construit cette position pour l’article ; elle ne provient pas du test de comparaison. Elle permet d’isoler l’effet du joueur au trait, avec des chances de victoire que l’on peut calculer exactement.
La question que posait réellement notre outil
Notre comparaison prenait le plateau après un coup candidat et demandait à un moteur indépendant d’évaluer la suite. Le code chargé de lui transmettre la position indiquait toujours que l’adversaire allait lancer les dés.
C’était juste lorsque le coup venait du joueur que notre code appelait « vous ». Mais l’échantillon contenait aussi des décisions de l’autre joueur. Après celles-ci, c’était à « vous » de jouer. Sur la moitié des positions, le mauvais joueur était donc au trait. Le traitement des parties déjà terminées comportait une erreur apparentée de point de vue.
Ce n’était pas simplement un signe moins qui aurait transformé les gains en pertes. La moitié des évaluations répondaient à une autre question. Leur mélange avec les évaluations correctes rendait les différences réelles plus difficiles à voir et faussait la comparaison.
Une course simple a révélé le problème
Ce sont les résultats de courses simples qui nous ont fait retourner dans le code. Dans une position compliquée, comprendre pourquoi deux moteurs ne sont pas d’accord peut prendre du temps. Ces courses étaient plus faciles à vérifier, et en suivant leurs résultats, nous avons trouvé notre erreur : nous indiquions au moteur de référence le mauvais joueur pour le prochain lancer.
Après correction du joueur au trait et du traitement des parties terminées, Open Sage évaluait lui aussi la nouvelle version mieux que l’ancienne sur cet ensemble de décisions. Le premier test et la vérification indépendante allaient désormais dans le même sens.
Cela ne signifiait pas pour autant que nous avions trouvé une amélioration certaine par rapport à toutes les versions publiées ensuite. Une comparaison ultérieure avec une version plus récente n’a pas établi de gain supplémentaire. La correction explique le résultat de l’ancien essai ; elle ne constitue pas une nouvelle affirmation sur le niveau actuel de l’application.
L’outil de mesure doit lui aussi être testé
Pour comparer deux versions de CUBE Backgammon avec un moteur indépendant, nous devons lui transmettre chaque position sans en changer le sens : le joueur qui lance les dés, celui dont on mesure les chances et le fait que la partie soit terminée ou non.
Un cas simple comme la course ci-dessus permet de contrôler cette transmission. Nous connaissons les chances exactes de chaque camp selon le joueur au trait ; nous pouvons donc repérer une inversion sans analyser tout un match.
Dans l’expérience où notre coach imitait mieux GNU Backgammon mais choisissait de moins bons coups, le problème était différent : nous comptions les accords avec GNU Backgammon. Ici, nous transmettions au moteur chargé de vérifier les coups une information incorrecte sur la partie.
Quand on lit une affirmation sur le niveau d’un moteur, il est utile de regarder comment la comparaison a été construite et contrôlée. Une référence reconnue donne du poids à un test, mais ne peut pas corriger une position mal décrite.
Ce récit suit les notes de développement corrigées, y compris la rétractation de la conclusion initiale. Nous créditons Open Sage et GNU Backgammon, les projets de référence indépendants utilisés. Le plateau d’exemple et son calcul exact ont été créés pour cet article, puis vérifiés séparément avec les règles de déplacement de CUBE Backgammon.