A few months ago, while looking at OGS rank deflation, I mentioned that I was experimenting with the problem of choosing the right moves to review. I’ve continued working on that and have collected a few related experiments in a small web app called go git gud.
It’s still early. I’m sharing it mainly because I’m interested in whether these ideas make sense to other Go players.
Review before AI analysis
When we open a game in KataGo right after it ends, it’s easy to feel like we’re learning from the engine. But getting the answers immediately can stop us from thinking actively about the game and our own moves.
The app therefore asks the player to review the game first: identify possible mistakes, leave notes, and try alternative moves. When the review is submitted, the engine reveals its analysis and scores the proposed alternatives.
The idea is not to test whether the player can guess KataGo’s move. It is to make the player commit to their own reading before seeing the answer.
I’m curious whether this extra step produces better reflection or merely adds friction.
AI tutor
A major problem with reviewing a game in KataGo is that we don’t always know what to focus on.
The biggest point losses are often blunders, lapses in focus, or difficult tsumego-style positions. Those moves matter, but they don’t always tell us what would be useful to study. The AI also finds problems with almost every move, while ideal “blue moves” may depend on ideas far beyond our current understanding.
I’m experimenting with KataGo’s HumanSL network to find mistakes that:
-
are not simple blunders or lapses in focus;
-
have an understandable alternative; and
-
are appropriate to the player’s current level.
I don’t want an AI tutor to list every imperfect move. I want it to find a small number of moves that the player might realistically learn from.
Estimated ranks
To choose an appropriate HumanSL level, the app does not use the player’s stated rank—or require one.
Instead, it makes a rough KGS-style rank estimate from the probability of each move, conditioned on the player’s move history and candidate rank. This uses the same basic method as my earlier OGS rank analysis.
The estimate is meant to select an appropriate model profile. It is not meant to claim that KGS ranks are the “correct” ranks.
Urgent before big
I’ve also been experimenting with a different type of problem generated from OGS games.
These problems try to capture a familiar uncertainty: should I respond locally because the position is urgent, or tenuki for a big move elsewhere?
Each problem presents a position and first asks whether it is urgent or tenukiable. If it is urgent, the player must find the best local move. If it is tenukiable, the player must find several good places to play elsewhere.
The Urgent section is available now, but it does not have a rating system yet, so the difficulty varies wildly. The Tenuki section is still under development.
Here’s an Urgent problem that has some teaching value imo:
I’d be especially interested in people’s thoughts on three questions:
-
Does reviewing before seeing the engine analysis help?
-
What makes an engine-identified mistake genuinely teachable?
-
Does the urgent-versus-tenuki format sound useful?
Critical feedback is very welcome. These are experiments, and I’m still working out which parts are actually helpful.