OnLawn

joined 1 week ago
 

One simple rule: the LLM plays chess with its own reasoning. No scores, no centipawn values, no engine evaluation or calculation. Just cold raw facts from the board.

I've found that the moment you give an LLM an engine to evaluate with, it abandons its own reasoning and just tries to game the numbers blindly. Any "centipawn" values for exchanges or positions and it completely forgets how to reason at all.

This is my attempt: github.com/mfnbc/chessdb.nu

Current state:

Lasts 20–30 moves against Fruit (a weak chess engine). Probably playing around 800 ELO. Plays very defensively, trying not to blunder. Early on it complained about what it couldn't see. Now when it does blunder, it goes back and checks and sees the problem was reported. Architecture (very simple):

Exposes Rust's Shakmaty for board facts. No scores, no evaluations (Shakmaty's scores are only hand-tuned and not battle-tested anyway). Information is structured Nuon (like JSON). Focus happens through Nushell's excellent structured language functions. The rest are skills and tools the LLM developed on its own for visualization. I coach it in between games and let it alter the skills and tools as it sees fit. That might sound lazy, but it's after many months of trying to impose my own opinion, which turned out to be the limiting factor. With my hand-written skills it only got to 10–20 moves (~400ELO; with its own skills it's doing noticeably better.

Open to:

Games by correspondence, Lichess, or ICC to test what works and what doesn't. Forking — the architecture has some cruft from earlier work, so it might be easier to start fresh. If you know of anyone else trying with similar constraints (raw facts, no eval), let's pit them against each other.

Feel free to read the Findings.md to see the journey.

One odd postscript, discussing chess with the computer has raised my ELO and consistency...

[–] OnLawn@programming.dev 2 points 4 days ago (1 children)

If your spec is really what your computer is, you should be able to run the models you need to.

Just slow down, have patience, and be opinionated on what you want it to look like, from code to architecture to user experience.

I hit more failure modes than when I use Claude, but there are always failure modes, and the answer is always slowing down, learning what it's doing, and having an opinion.

I will use, sometimes, free web search tools to architect, plan, and generally get ideas. Their ability to search the web directly helps. And to code, I sometimes build a cheap RAG with the language documentation (nushell needs help most of the time) and that helps.

Again, in general, just slow down and take your time. Like a jr dev, just cut it into bite-sized pieces with clear goals, all of which a more capable model can help with.

GLM worked well and did some impressive one-shots. Gemma can be more sophisticated in what it writes, but Qwen is less acrobatic and stable. Ornith looks interesting but I was never able to run it.

[–] OnLawn@programming.dev 2 points 4 days ago

As it happens I'm working on a chessdb.nu, which is supposed to be a set of tools and skills for llms to annotate, even Socratically coach chess positions and games.

Two observations, 1) I think the post is really just trying to explain that the LLM is not limited to the next token in its planning. It can have an idea of where it is going all the way to the last period and token prediction is just the step by step to get there. Even more interesting is that the LLM can change plans midstream (cf: seahorse emoji). And 2) without going so far as saying it is existentially making choices, it is showing complex reasoning and planning which is a few steps above a Markov Chain.

As for myself, I like the analogy of french curves and splines being fixed and added to with the LLMs internal reasoning and then walked token by token. But LLM's don't actually have to be that continuous and smooth, although in fairness when it isn't, it's usually a failure mode.