chess-net

Écrire un deuxième moteur n’a d’intérêt que s’il n’est pas le premier en mieux. Celui-ci prend le problème par l’autre bout : là où opti_chess évalue une position avec des termes écrits à la main et relisibles, celui-ci l’évalue avec un réseau entraîné, d’abord en supervisé, ensuite contre lui-même.

L’objectif n’est pas le gain de force, mais deux réponses indépendantes au même problème, sur un jeu assez connu pour juger laquelle se trompe et où. Le Rust est venu avec, parce qu’un moteur est le genre de programme où l’absence de ramasse-miettes se sent.

La partie classique est terminée et vérifiée : bitboards, génération magique des coups, zobrist, recherche à variation principale avec table de transposition, killers, historique, coup nul et quiescence, le tout piloté en UCI. Un moteur d’échecs a la politesse d’être testable : la suite de perft, du départ à kiwipete, est verte, ce qui établit que la génération de coups est juste et pas seulement plausible.

La partie apprise existe des deux côtés : un format binaire de réseau maison, lu par l’inférence en Rust et écrit par l’outillage d’entraînement en Python, avec la contrainte dure que les encodeurs de traits soient identiques dans les deux langages. Un décalage d’un seul indice ne casse rien, il rend simplement le réseau silencieusement faux. Les deux voies d’entraînement sont écrites, supervisée sur des positions étiquetées et par auto-apprentissage avec une recherche de Monte-Carlo ; quelques cycles ont tourné et laissé leurs points de reprise.

Ce qui manque est la seule chose qui rendrait cette page concluante : le duel avec opti_chess. Il n’a pas eu lieu, et tant qu’il n’a pas eu lieu, ce dépôt est une architecture qui tient, pas une réponse à la question qu’il pose.