I don’t play go, but I do play some chess (I especially enjoy chess puzzles), and whenever I don’t “get” the proposed solution to a puzzle I spin up the engine and poke around until the situation resolves into something that makes sense to me. Why didn’t my line work? Oh, there’s a bishop block, etc. etc.
Back to the example of AlphaGo justifying itself to me, there are ways other than tree search that AlphaGo can make a legible argument in favor of a particular line of play. For instance, it could ask “what would you play instead?” and then play against itself starting from my proposed alternative play. In some sense, this means that the answer to all questions of this form are “because when I play that way, I lose.”
You correctly identify that this takes much more computation than simply playing go well, since it opens up the algorithm to explore as many positions as I want it to. Heck, even a single question from me can take a long time to resolve (it requires an entire game!). Even that game may not be sufficient justification for me, since it is likely to generate even more questions, “okay, sure, if you play like that my line is bad, but what about if you follow it up with this?” [several lines of play] “oh.”
Nonetheless, with this way of communicating between engine and human it is the human who generalizes. The engine is simply giving its expert opinion in the form of “this play is better than that play”, and it can demonstrate that it is probably true but it doesn’t really ever say why. The engine being able to generate correct lines of play makes it a useful tool in teaching, but doesn’t make it a good teacher. It’s still up to me to figure out what concepts I’m missing that are leading to poor play.
Now, the Go example has unusually fast and clear feedback. Many arguments do not work this way since they make predictions about things that will not happen for years (or may not happen at all!) or are about hidden bits of information. The fact that the engine can demonstrate that its model of the game is better than mine is very unusual.
Go is different from Chess. The fact that Chess was solved so much earlier than Go is because the feedback isn’t as fast. While you get fast and clear problems for Life and Death problems most moves played in a game don’t have fast feedback. It frequently takes a hundred moves to see why a particular move is good or bad and a move that provides two points more than an alternative move can be a very good move, without looking like much over the space of 100 moves.
I disagree with your claim that Chess is a solved game. AIs play much better chess than humans, but AIs continue to improve. The AIs of today would trounce the AIs from a few years ago, and “solved” means to me that there is a known best strategy. I do agree that Go is a harder game, but I believe they are very much in kind with one another.
I’m suspicious that when you say that “game x is easier than game y because the feedback isn’t as fast”, you will end up needing to define “fast feedback” in a way that depends on the difficulty or complexity of the game. As a result, the statement “game x is easier than game y” would mean approximately the same thing as “game x has a faster feedback loop than game y” by definition. Here are some ways you might define the speed of feedback so that the statement could be made, along with some problems they run into:
Time in seconds between making a move and the end of the game. Well, chess and go both take about as long as each other, so this seems like the wrong axis already.
Number of moves between making a move and the end of the game. It seems easy to imagine a game that has many moves, and where individual moves can be very strong or very weak, but is nonetheless very easy. For instance, we could modify the game of 21 to instead count to ten trillion; the feedback from move one to your win or loss is long and yet the game is just as easy as 21.
The amount of compute required to determine how good a move is[1]. This would be my definition of the difficulty of a game.
Chess frequently has far-reaching consequences of relatively quiet moves. This video of AlphaZero versus Stockfish is my personal favorite example of this. Stockfish is up in material for the majority of the game (and thinks it is winning handily for most of this time), but loses convincingly by the end of the game. An AI that is far superior to me at chess failed to see the long-reaching consequences of its plays; it was not obvious to it that it had played a bad move for quite a while.
When I think of the speed of feedback, I think of the amount of time in seconds that elapses between making a decision and receiving new information from the outside world that would be meaningfully different if I had made a different decision. I expect that definition to have problems, since I don’t know how to define “meaningfully different information”, but it’s the best I can do right now.
For example, after I post this I could re-read my own post, and evaluate it on its merits according to me, but I would not consider that feedback since that is information that was largely internal. In contrast, if/when I get a response from you, or upvotes/downvotes from the community, that is feedback I can use to update my models of the world. That time lag that’s out of my control[2] is what I think of as the speed of feedback.
The amount of compute will depend on the method being used to convert a board-state into a move, and so a game could be hard for some players but easy for others. As a fairly extreme example, we could compare an already-trained stockfish against the code that would allow you to train stockfish; the first will require much less compute to decide why (and whether) a given move is good or bad.
Great post! Strong upvoted.
I don’t play go, but I do play some chess (I especially enjoy chess puzzles), and whenever I don’t “get” the proposed solution to a puzzle I spin up the engine and poke around until the situation resolves into something that makes sense to me. Why didn’t my line work? Oh, there’s a bishop block, etc. etc.
Back to the example of AlphaGo justifying itself to me, there are ways other than tree search that AlphaGo can make a legible argument in favor of a particular line of play. For instance, it could ask “what would you play instead?” and then play against itself starting from my proposed alternative play. In some sense, this means that the answer to all questions of this form are “because when I play that way, I lose.”
You correctly identify that this takes much more computation than simply playing go well, since it opens up the algorithm to explore as many positions as I want it to. Heck, even a single question from me can take a long time to resolve (it requires an entire game!). Even that game may not be sufficient justification for me, since it is likely to generate even more questions, “okay, sure, if you play like that my line is bad, but what about if you follow it up with this?” [several lines of play] “oh.”
Nonetheless, with this way of communicating between engine and human it is the human who generalizes. The engine is simply giving its expert opinion in the form of “this play is better than that play”, and it can demonstrate that it is probably true but it doesn’t really ever say why. The engine being able to generate correct lines of play makes it a useful tool in teaching, but doesn’t make it a good teacher. It’s still up to me to figure out what concepts I’m missing that are leading to poor play.
Now, the Go example has unusually fast and clear feedback. Many arguments do not work this way since they make predictions about things that will not happen for years (or may not happen at all!) or are about hidden bits of information. The fact that the engine can demonstrate that its model of the game is better than mine is very unusual.
Go is different from Chess. The fact that Chess was solved so much earlier than Go is because the feedback isn’t as fast. While you get fast and clear problems for Life and Death problems most moves played in a game don’t have fast feedback. It frequently takes a hundred moves to see why a particular move is good or bad and a move that provides two points more than an alternative move can be a very good move, without looking like much over the space of 100 moves.
A couple of things:
I disagree with your claim that Chess is a solved game. AIs play much better chess than humans, but AIs continue to improve. The AIs of today would trounce the AIs from a few years ago, and “solved” means to me that there is a known best strategy. I do agree that Go is a harder game, but I believe they are very much in kind with one another.
I’m suspicious that when you say that “game x is easier than game y because the feedback isn’t as fast”, you will end up needing to define “fast feedback” in a way that depends on the difficulty or complexity of the game. As a result, the statement “game x is easier than game y” would mean approximately the same thing as “game x has a faster feedback loop than game y” by definition. Here are some ways you might define the speed of feedback so that the statement could be made, along with some problems they run into:
Time in seconds between making a move and the end of the game. Well, chess and go both take about as long as each other, so this seems like the wrong axis already.
Number of moves between making a move and the end of the game. It seems easy to imagine a game that has many moves, and where individual moves can be very strong or very weak, but is nonetheless very easy. For instance, we could modify the game of 21 to instead count to ten trillion; the feedback from move one to your win or loss is long and yet the game is just as easy as 21.
The amount of compute required to determine how good a move is[1]. This would be my definition of the difficulty of a game.
Chess frequently has far-reaching consequences of relatively quiet moves. This video of AlphaZero versus Stockfish is my personal favorite example of this. Stockfish is up in material for the majority of the game (and thinks it is winning handily for most of this time), but loses convincingly by the end of the game. An AI that is far superior to me at chess failed to see the long-reaching consequences of its plays; it was not obvious to it that it had played a bad move for quite a while.
When I think of the speed of feedback, I think of the amount of time in seconds that elapses between making a decision and receiving new information from the outside world that would be meaningfully different if I had made a different decision. I expect that definition to have problems, since I don’t know how to define “meaningfully different information”, but it’s the best I can do right now.
For example, after I post this I could re-read my own post, and evaluate it on its merits according to me, but I would not consider that feedback since that is information that was largely internal. In contrast, if/when I get a response from you, or upvotes/downvotes from the community, that is feedback I can use to update my models of the world. That time lag that’s out of my control[2] is what I think of as the speed of feedback.
The amount of compute will depend on the method being used to convert a board-state into a move, and so a game could be hard for some players but easy for others. As a fairly extreme example, we could compare an already-trained stockfish against the code that would allow you to train stockfish; the first will require much less compute to decide why (and whether) a given move is good or bad.
I suppose I could DM random people and ask them to read the post, but that would be very weird.