Show HN: I trained a chess engine to play like humans
3 comments
very interesting project! I'm a chess aficionado and playing vs stockfish does always feel a bit clunky at ~1,700-1,900 ELO. How are the 100-point buckets calibrated? Would the ~1,800 ELO truly win ~50% of the times against humans with a similar rating?
The 100-point buckets are fine-tuned on blitz games from users at that Lichess rating. Lichess ratings tend to be a bit high compared to FIDE/USDF/chess.com ratings. There's a good post at https://chessgoals.com/rating-comparison/ comparing them
This is cool! Would you be interested in speaking further over a call?
Live demo: https://1e4.ai Code: https://github.com/thomasj02/1e4_ai
A few things that might be interesting:
- Trained on almost a full year of Lichess blitz games, around 1B total games
- Architecture is an a small (~9MM parameters) transformer-based network that takes the board, recent move history, the player's rating, and remaining clock time as input. Three separate models per rating bucket: move, clock-usage, and win probability. The clock model is what makes the bots feel humanish under time pressure rather than instant. Because the move model takes the clock as one input parameter, it also learns to blunder under time pressure like a human might.
- Because the network is so tiny, no GPU is needed for inference - it runs easily on a local CPU
- Downside of the tiny network is that it's a bit weak as you turn up the rating past around 1700. It can spot short tactics but not long multi-move combinations.
- Initial training on a rented 8xH100 cluster, then fine-tunes on my local GPU for different rating ranges
- Inspired by Maia-2 and DeepMind's "Grandmaster-Level Chess Without Search". On a held-out Lichess blitz benchmark, the it beats Maia-2 blitz on top-1 move prediction (56.7% vs 52.7%) and pretty substantially on win-probability calibration (Brier 0.176 vs 0.272). Numbers and code in https://github.com/thomasj02/1e4_ai/tree/master/experiments/...
- The data pipeline is C++ via nanobind, then training with Pytorch. Getting this right was actually the thing I spent the most time on. Pre-shuffling the dataset and then being able to read the shuffled dataset sequentially at training time kept the GPU utilization high. Without this it spent a huge percentage of time on I/O while the GPU sat idle.
Happy to answer questions about the rating-conditioning, the clock model, or the data pipeline.