Eric Jang – Building AlphaGo from scratch

AlphaGo and Go AI is one of those things that really got me into the field when I saw the kind of early breakthroughs breakthroughs on on AlphaGo off off ago in 2014, 2015, 2016, and so forth, it was just profound to see, you know, how smart AI systems could become and the the kind of computational complexity class that they could tackle with deep learning. This is a problem that has long been understood to be kind of intractable for search, and yet it was solved through deep learning. And so that was quite mysterious to me, and I've always wanted to understand that phenomena a little bit better.

My training is often in deep neural nets for robotics where it's the the decisions made by the neural networks are a bit more intuitive, but AlphaGo is a sort of problem where the the decisions are actually the result of a very, very deep search. And it's always been very mysterious to me how like a 10 layer network can sort of amortize the simulation of something so deep in game tree. Interesting.

So if you plot out how much compute it took to build various iterations of strong gobots over the years, you can see that in 2020, there was a open source project called Katago by David Wu from Jane Street who who basically achieved a 40 x reduction in compute needed to train a really strong gobot, Tabular Rasa. I'm not certain if it's stronger than AlphaGo zero or AlphaZeroMu zero, but it's very, very strong. And this is what most Go practitioners today train against when they're when they're playing an AI.

And thanks to LLM coding, what took a whole team of research scientists at DeepMind and, you know, millions of dollars of research and compute can now be done for, you know, a few thousand dollars of of rented compute.

quickly and easily in a computer. The the objective of the game is basically to put down black and white stones and try to occupy as much territory in the game as possible. So I might start by putting down a black stone.

Black always goes first. Just go ahead. And so the way you capture an opponent's stones is that for every intersection, if you can surround all four of its neighbors with with your stones, then then this one is sort of cut off from oxygen, if you will, and then it and it it it is a dead dead stone.

So so then now I control these four stones as well as this empty intersection here. So there's, like, slight variations between Chinese, Japanese, and what is called Trompe Taylor rules. Trump Taylor rules are designed to be completely unambiguous for Go.

So this is what all Go AIs train against and resolve against. So in typical Go, like when a humans play, you're actually not allowed to put this white stone down here. It would be instant suicide.

In Trump Taylor, it's actually fine. You put it down, and then it immediately resolves to death. So the outcome is sort of the same.

Let's go ahead and start over and and play play a few stones, and then I'll explain So some I'll just start there.

So this move basically exposes one empty neighbor for your white stone, and it's very akin to a check-in chess Mhmm. Where if you don't respond immediately by putting anyone here, then I can immediately capture this. I see.

Okay. Because it is it is sort of the diagonals that determine whether you're grounded in. The cross section, not the diagonals.

So so this one is surrounded on three sides. Yep. And so you're at threat of losing that stone if you don't play one immediately there.

Now you can see that I'm starting to pressure you because by putting a stone here, now you are forced to put one here. Otherwise, you would have this two block Yes. To yourself.

And then if you think think through, like, what happens if you were to respond here, you can probably, you know, search into the future and deduce what I'll do in response once you once you do that. You have lot of confidence in my abilities, but I'm guessing you'd put the black here. That's right.

And then I would capture all three of these stones. So I should just assume that this is gone. This little block is gone.

Yes. So in Go, it's actually okay to let a opponent capture some stones if, for example, it allows you to position to capture more stones in somewhere else on the board. Yeah.

And and this is what makes Go a very beautiful game is that you can kind of lose the battle but win the war. Interesting.

And so now I would capture this entire group. Okay. And this this would be mine.

Okay. There's one more case that I wanna demonstrate, which actually, I had a bug in my code recently, which is the following situation. So let's consider a formation like this.

Right? And then, you know, we have other pieces on the board in play or whatever. And so let let's talk a little bit about how the game ends.

Right? In this territory, who controls these these areas? Is it white or is it black?

White. It's actually black because I have actually surrounded this whole area. Yeah.

And it's very assuming I have, like, other black stones here, it's actually very hard for you to break this out of the control of these stones. So when the final score is tallied, would would these ones also count as being in Yeah. Great question.

So so this is where different rule sets have different ways of scoring, and so we should talk a little bit about how, like, you resolve scores between humans and how you resolve scores between computer code. Because there's actually some ambiguity in how humans eval evaluate this. So most humans would look at this board configuration and conclude that black has kind of totally surrounded white, and so white has no chance of life.

Yeah. We could play out more here, but then at the end, I would capture everything. Yeah.

However, if you have a way of breaking this formation and connecting y to something outside of it Yeah. Yeah. Then it can flip.

Right? And so this is where it's, you know, a little bit hard for a computer to decide these kind of things. Right?

So how do humans do it? Right? Like, it's it's worth thinking a little bit about how humans resolve this because this will actually map later to how we think about the deep neural network.

Humans basically say, I think the game is done, and then you you have to also say, I think the game is done. And then we'll say, like, I think these are these are milestones, and then you have to agree. If you don't agree, then we keep playing.

Yeah. So essentially, once two humans, their so called value function, agree on a consensus, then the the Chinese rules resolve that. Yeah.

Interesting. So in Trump Taylor scoring, it's perfectly unambiguous. So it can be decided, you know, algorithmically by a computer.

So if if let's say you you have this at the end end game, the way you score this is that you first count how many stones you control, and that's unambiguous. Then you count how many empty intersections that are not touched by your opponent's stones. So these intersections would not count for either player because both of all of these intersections are connected to both white stones and black stones.

Mhmm. Right? If this were like this Yeah.

Then white would get three points. Now this is a little odd because a human would know that white is actually losing these points. Yeah.

But Trump Taylor scoring would consider white to have all of these points as well as these points. Got it. Okay.

Right. So so that is a very big difference in how computer go scores things and how humans score things. How does the game end?

The game ends when either a player chooses to resign or both players pass consecutively. Cool. Yep.

So that's the rules. Nice.

search process used to make moves. And we'll layer on ideas from deep learning to make it much more efficient and tractable. So Go is a game where there's just two players.

We're going to draw a person here, and we're going to draw an AI here. And let's say this person is playing black, so they go first. So we're going to draw.

They go here. And then now the AI is going to make a move based on what it sees here. So there's a question of like how you encode these inputs into the AI.

Maybe you can use ones and zeros, but you want to represent, you know, black, white, and empty. So so you would need at least three different values here. Right?

So maybe you can use zero, ones, and twos or something. So so the AI might see something like, you know, zero zero zero zero one. Great.

So so this is the input to the AI on its turn. Yeah. So so the AI can choose let's just pick three possible random moves that can go, and I just drew these at random.

And so which which move is best here? Right? Well, we don't know until the game ends.

There's no Go does not have any kind of local reward of which move here is good. And this is what makes Go a very difficult game is that you don't actually know who won until you really get to the end of the game. So how deep is this tree?

Right? Well, in a 19 by 19 Go board, there are, you know, roughly to the order of 361 moves on any given move. And, course, as it fills up, you have less moves.

And and the the number of steps in the game can be somewhere from 250 to 300 moves. And maybe experts might decide to end the game well before that. But, you know, under Trump Taylor scoring, you actually have to play things all the way to the end.

So this could be like 300 moves or something. Right. So like 300, depth of the tree.

Yeah. So if you keep on expanding possible moves here so in in this move, the AI is going. And then, you know, here, the human would go.

And then, you know, there's there's some and so forth. You can find that, like, essentially, what you end up with is an enormous explosion in the possible game outcomes originating from just this one state. So this is something to the order of like, you know, 361 to 300 power of 300, which is far more than the number of atoms in the universe.

Right? Like, it's it's just it's just and and of course, actually, there are redundancies and symmetries. So it's not actually 300.

But but that's sort of the if you were to do a naive tree where there were no merging of children, then actually you end up with a tree about this big. What do mean by merging of children? Right.

Let me use this board here. So if we start here, and then you play here, and then I play here and then you play here, that is equivalent to I start here, you play here, I play here Yeah. And then you play here.

Right? Yeah. So so both of them arrived at the same spot but through different paths.

So this child node can be thought about as a shared access. Right. Yeah.

And I guess it's not three sixty it starts at three sixty one, but it decreases by one each time. And the branching factor decreases by one each time. Yeah.

Yes. Yes. But in in any case, this is a very, very, very large tree.

Yeah. And this is also why, you know, computer scientists for many years thought that Go was not a tractable problem this century because the amount of compute you would need to exhaustively search every possible possibility is just too large. No.

If you could, Go is actually deterministic game. So on any given state, you can actually compute what the best possible strategy you can make is in order to win the game. You can search all the possible futures where you win and then just make sure you always stay in that set of futures.

So, AlphaGo's kind of core conceptual breakthrough was using neural nets to make this search problem tractable. So, before we get into how neural networks are involved, let's talk a little bit about how we can, you know, assuming we have a powerful enough computer, search this tree to find the best move. Right?

So in the beginning, you're not gonna build out the whole tree because storing that tree would be very expensive. Instead, you might do something like interactively figure out which leaves of this tree are worthy of exploring and expanding into the future to see, you know, what else is there. So there are some early algorithms in bandit literature like, you know, UCB one, which is not exactly appropriate for a, you know, sequential game like Go, but very much inspired the action selection algorithm used in in AlphaGo.

So so UCB one looks like on on every move, we're gonna take the best action or, you know, the argmax over a that maximizes, you know, the q of a, and I'll explain what q of a is in a moment, plus some sort of exploration bonus. So on every node, we're going to track a few quantities. So so let's, you know, consider each of these a node.

This is this is the the root node where you're making decisions from. And these are the children of the root node. And we're going to say each node is basically a data structure that is it stores a visit count of this node, this this child node.

Is how often the parent visited this node? Yes. And we'll call this an act so so one thing that is easy to trip on is like if you come from, you know, robotics or other kinds of reinforcement learning is like, where are the actions?

Right? I'm only talking about nodes. Mhmm.

Nodes here represent states. And because this is a perfectly deterministic game with no randomness, you can actually just infer the action based on the child. I got it.

So so if I go here, that implies an action. Yep. And this is the state that we resolve.

Right? So so the LLMs, if you ask to, you know, vibe code a MCTS implementation, it'll most likely design the right data structure here. But, know, it's up it's sort of a chef's choice.

You can actually rewrite the the tree structure however you like. This was what Claude four point six wrote for me when I when I asked it, and it was a very reasonable choice. So then, you know, q represents the mean action value of this action.

And I'll use a subscript a to denote that this kind of corresponds to taking a specific action to to get here. Right? From from the from the root node.

So so, like, if if we have root, basically, taking a gets us to this this node here. Yeah. And then we're gonna also store the probability of taking this action.

Again, from the parent? From the parent. Yes.

Like like, what are the odds that we sample this one? Yeah. And and this will become relevant later.

You know, like, we've we've talked about a deterministic tree for now. So I'll I'll bring probabilities into this later. And then finally, we have a sort of a dictionary of children, which is just like, you know, more of these notes in a in a sort of classic linked list style reference tree.

So this is the basic data structure to implement a tree. And in AlphaGo, they use a slightly different action selection criteria called pucked, and it's short for predicted upper confidence with trees. And this is basically when you when you select which which child to take, you do argmax a of q of s a plus constant So the equation forms are actually pretty similar.

These are both scoring criteria. Right? Like, you want to argmax this quantity and you want to argmax this quantity to determine which action to take.

So let's break down the intuition of, like, how you select actions here. This is the mean action value. So how good is a given child on average?

And and and if you actually, you know, knew the whole tree, then this is all you need, right, to select the best action. You don't really need to do more than that. But if you're interactively building this tree as you're figuring out what the q values should be, then what you have to do is occasionally try some other actions, you know, as a sort of explore versus exploit trade off.

So, in both UCB and PUCT, there is this term here that basically rewards taking actions that you haven't taken before. So, as we mentioned before, each node stores the visit count of taking that specific action. Right?

So, everything is initialized to zero. And so, for a given action, let's just say, like call it n like, a, initially it's zero. And so as n is increasing, if if let's say we've already made ten ten action selections from that root node, but we haven't picked a yet, then this term actually starts to become quite large for a.

Yeah. Right. And conversely, if we have chosen a 10 times out of 10, then now this term is quite small.

Yep. It it diminishes very quickly. And the same thing is actually true here.

the motivation for UCB was to come up with an algorithm where if you don't know the payoff of the arms the the different actions you can select to begin with, this strategy, basically, with given some exploration term here Yep. Bounds your regret Yep. In terms of how wrong you can possibly be.

Yeah. I don't know the proof. I don't also know if this one is proved to have a logarithmically or or like, you know, square root bounded regret or anything.

But I think the algorithm was just derived to look something like this. And you can tell that these terms are they grow a little bit differently, and this is actually just to account for the fact that Go has many more actions Yeah. In every given move compared to your standard banded problem.

Yep. So one small clarification to make is that you talked a little about simulations on probabilities and forth. We should remember that Go fundamentally is a deterministic game.

So the notion of like, where does the notion of probability come from here? Right? If you had a very powerful computer, there is no probabilities.

You just you can just compute the true average of what the the mean action value is. So where does the probability come in? Well, it turns out that as in, you know, Computer Go before AlphaGo, we've always done some sort of Monte Carlo method where we have some we we take the expected q value averaged over a randomly selected tree.

And that randomly selected tree is where probabilities come in. So, the interpretation of Q is what is the expected action value under the random distribution induced by some random search process? Makes sense.

And so where does the random search process come in? That's where, you know, p of action comes in. Yeah.

So if we assume a very naive algorithm where you have a uniform probability of taking any valid action, then this would just be one over the number of valid moves in this setup. And you would be kind of taking this average over this very diffuse tree. Right?

And this is a valid interval you can take, but it's very slow because you're going to consider a lot of trees that have very low value. Yeah. And it's essentially almost like a importance sampling problem where you want to there's only a few actions and and and sort of paths that can contribute, you know, high value, and almost everything else is low value.

So so this is sort of a tricky problem here. Okay. So this is the action selection criteria for how you decide which moves to move down.

Now, as you move down in in tree search, you will eventually run into a node where it's quite clear you've won or lost. Right? At the at the very, very end of the game when when there are no valid moves to play left under under Trump Taylor scoring, you can decide whether you, like, you know, won or lost.

Right? So you you either win or you lost. And so this is basically, you know, the the final return of the whole game.

Right? And so the the question here is, like, we we can assign a a value, u, to a terminal leaf node of the tree. But how do we assign the values for nodes prior to that, the parents?

And it turns out, you know, what you simply do is you just take the your mean action value is essentially your average. So let's suppose these were leaf nodes. Sorry.

These were all leaf nodes. The the mean action value of this node, you know, this action here, is just the average of whether you won or lost at the leaf nodes. And correspondingly, you can kind of walk up the chain and say, like, well, the mean action value of this node, let's call this like q b, and this is action b, is just the average of a weighted average of these ones here.

Yep. Right. And and the weighted average is it could be dependent on if you have a different sampling distribution or not, but the the basic intuition is that you want to resolve the game where you have a deterministic win or lose, and then you can kind of go backwards.

This is called the backup step and assign values to these these these these nodes or actions corresponding to the averaged over over the final terminal. Yeah. Okay.

So if you were to do this without neural networks, it would still be intractable. You would you would have a trouble finding, you know, which actions to sample. A lot of the actions will contribute very low value, especially if you're like, you know, trying to fight your way out of a losing position and only a few actions give you high value.

So the search in practice is still very, very expensive. But but the the idea is that like if you can because Go follows a tree structure, you can actually, you know, inform a very good estimate of the value of this node based on the values of of downstream, assuming they're all correct and assuming you've searched deep enough. Mhmm.

you know, this u value being, you know, your final resolution of whether you won or lost. And this is a terminal leaf node condition. Now humans don't play all the way to the sort of edges of the the tree the leaves of the tree.

Right? They kind of stop, you know, some dozens of moves before, maybe maybe even 100 moves before in in sort of high level play. So how do they know?

Right? Like, you can think about humans as implicitly having a neural network called a value function that basically, you know, takes in a board state and then it kind of evaluates, you know, key win. And so the human glances at the board and they know like, I'm probably going to lose.

Right? And and they're essentially running a neural network that looks at a board and implicitly, they are amortizing a huge number of possible game playouts and and taking that average and then deciding whether the board is winnable or not and then whether they should concede or or, you know, keep playing or not. And this is remarkable.

If you think about, like, the the beauty of something like this, it's like a a neural network in a in a human can somehow do all of this simulation at a glance and then just know like within a few seconds without actually playing every single game logically based on just kind of like crystallized knowledge and experience that, like, they can do this. And so this gives us a hint that, like, in games like Go, there are ways to basically radically speed up the search process. And this is one of the fundamental intuitions behind why AlphaGo works, is that you can train a value function to look at a board and quickly resolve the game without playing out all of these trees into the you know, into a very deep search depth.

classically, for games like Go, you could build a tree, but we don't have computers powerful enough for that. Yeah. And estimating the value of every action that you could possibly take is also hard because you don't know until the end of the game.

Yep. You could take averages by playing them to the end, but that's also hard because you don't know which actions to take to sample these averages. So conceptually, there's kind of two problems.

There's the breadth of the tree, and then there's the depth of the tree. And AlphaGo gives us a way to basically shrink both of those to be very attractive. Yeah.

That's that's essentially the kind of core idea behind it. Okay. So we we take this idea that like, know, humans can glance at a board and instantly predict whether we win.

And maybe that gives us the opportunity to really truncate the how deep we we search. Yeah. And then, know, we also know that humans can look at a board and and decide, you know, what what boards, you know, like intuitively at a glance, what moves might be good on the board.

Right? So so these are kind of two things that we can use deep neural networks for to accelerate this search process. Let's go back.

Before we talk about neural nets, let's just go back to how this play out works. So we've only talked about making one move. Right?

So so the AI looks at this encoded Go board. It has a tree. It searches for, you know, deeply into the tree to find out which of its actions might be the best.

And then it takes that action. And then now, you know, it goes back to the human. So maybe now the human sees a Go board that looks like, you know, like this.

And and then they they make their move. So maybe they put they put their stone here. And then now we we go back to the AI, which now looks at a new encoded board.

So I've used two to denote the AIs playing as white and one to denote the human playing as black and zero as empty. And then now on the AI's turn, it does the MCTS tree search all over again from scratch. Right?

So so it throws away this old tree that it searched last round, and now there's a new root node, and it begins to search anew. And then so and so forth. So, MCTS is basically a you can think about it like a search algorithm that is deciding what moves to play best, aided by neural networks.

And and it's it's done on every every move.

Okay. So now we have a basic intuition of how moves are made with search. We're going to talk about how neural networks can speed this up by providing an analog to like the human intuition.

So there's two networks. There is the value network, which takes in a state and it predicts, you know, am I going to win or lose? It's a binary classification problem.

Then we're going to have a policy network which induces a distribution over good actions to take. Mhmm. So I'm gonna draw a one dimensional flattened move distribution, but this is really like, you know, a square kind of grid.

Right? So so maybe, like, it thinks actions are like these are the kind of probability distribution over good actions. And both of these are categorical classification problems.

Right? So you can train this like any classifier in with deep learning, you know, cross entropy loss, that kind of stuff. So the the specific architecture does not actually matter too much.

I I tried a few different architectures. Transformers work. Resonets work.

For small data regimes, my experience is that Resonets still kind of outperform transformers and and kind of give you more bang for the buck at at lower budgets, but this may not be true. Why is that? They they provide the inductive bias of, like, local convolutions.

Yeah. And generally, transformers start to outperform residual convolutional networks when you want more global context. I see.

Okay. So one interesting finding from the Katago paper was that they found it actually quite useful to pool together global features together and aggregate global features like throughout the network to kind of give the network a global sense of how to like connect value from one side of the board to another side of the board. Well, what does it mean to aggregate global features?

Yeah. So if you have a go a very large 19 by 19 Go board. Yeah.

And you you know, you've got some some sort of battles going on here, and you got some battles going on here. When you pass this through a convolutional neural network Yep. The receptive fields of the convolutional network are going to be good at computing local things and making that invariant.

But they won't be able to kind of connect these two features easily. Right? They need to sort of be pooled together and attend to each other somehow.

So the argument about, you know, why transformers are good for computer vision tasks like with, you know, vision transformers and so forth is that because they have a sort of global attention across the whole thing, they can more easily draw these. But you do need more data there so that you can kind of learn through data the the sort of invariant local local features. Got it.

I've tried very hard to make transformers work for this problem because I was kind of curious if transformers would present some sort of breakthrough in Go and just remove a lot of those tricks. But to try as I might, I actually haven't figured out a way to make transformers better than ResNet for for now. So one sorry.

One more tangential question.

there does exist a Nash equilibrium strategy for which you can do no worse than any other strategy. So, if you know that your opponent has a particular bias, like they they love to play aggressively, you can actually, in principle, counter that specific strategy better than a Nash Equilibrium policy. But to counter any given strategy, there does exist a single Nash equilibrium that can be decided solely using the current state.

So, is a design choice that most Go agents AlphaGo chose to do, which in hindsight turned out to work very well because the Nash equilibrium seems to be superhuman. Like like no human strategy seems to be able to beat it. Now, there are variations of this where you would actually need to consider temporal history.

So and and this is a very exciting research area that I I would encourage people to kind of fork my repo and try these things out, which is if you were to play, let's say, two v two Go, then you actually need to model your partner's behavior. And you like, you may not have information on how they play, so you need to aggregate some information on, like, how they play so that you can respond accordingly. Yeah.

Right? Like, are situations where it's no longer a perfect information game. Yeah.

And then in those cases in in games of imperfect information or partial observability, then you do need some context to build a model. Yeah. Yeah.

And and I think that's a place where things get very, very exciting in terms of, like, self play or diplomacy style. Yeah. Interesting.

Okay. So returning back to the neural network, the architecture, again, is not super important. You can get it to work with transformers.

You can get it to work with ResNets. I found that for low budget experiments, ResNets work a little better. You can also use kind of a Karpathy style auto research hyperparameter tuning to make make your architecture pretty good.

And so so you don't have to worry too much about that. You just need to sort of set up the problem so that you have a a sort of target optimization. Yeah.

Okay. So we're going to pick just a somewhat arbitrary architecture that worked for for, you know, what I did. But again, this part is not super important.

You have your encoded board state. And we're going to just choose to, let's say, do three three like, you know, similar to an RGB, we're gonna have three kind of channels. One channel to encode black, one channel to encode white, and then and then one channel maybe to encode, like, empties or maybe like a masked region if you want to train on multiple board sizes.

I'm actually not going to talk about multiple board sizes for now. That's a little bit too complicated. So we'll just say like, you know, we've got this two or three channel RGB like image, and then we go into a, you know, a ResNet.

And then we have two branching heads. One head predicts the the value function, and this is like a single logit. So this is like r one.

And then we have the policy, which is, you know, r three sixty one. So this is the architecture. And we're going to basically train this to predict the outcomes of games given the board state.

And we're also gonna train this to predict what are good moves. Yeah. Right.

So the OG AlphaGo paper or called AlphaGo Lee initialized this network with a supervised learning dataset of expert human play. Later, they removed this restriction by having the model teach itself how to play well. But I find it actually from a matter of like implementation for your audience, super super nice to always kind of initialize your your experiments to something that's easy and then like, you know, get the problem working before, you know, trying to bite off the whole thing and learn a Tableau recipe.

You you generally want to kind of initialize just as in deep learning, initial initialization is everything. Right? You always wanna initialize your research project to something as close to success as possible, especially if you're doing something new that you haven't done before.

Always pick something that works and then get it to do something better rather than start from something that doesn't work at all and then try to make it work. So under that philosophy, it's a great idea to start from something that has a good initialization. So we're gonna take human expert plays and train this model to predict, you know, good actions.

Right? So we're gonna take all of the winning games, all all the moves in which a human won and sorry, an expert won and then predict those actions. And then regardless of board state, like, you know, whether you won or lost, you're gonna predict the outcome.

Yeah. So you might be wondering like, okay. Well, some of the early boards, you know, where basically only one stone has been put down, how could you possibly know whether who who the winner of this game is?

Right? Well, if you have, you know, hundreds of thousands of games, then in on average, you'll probably see that boards that start like this have a sort of half of the games that branch off from this will win, and half of the games that branch off branch off of this will lose. So that'll actually be fine.

When you train this model to predict those, the logit will sort of converge to, you know, 0.5. And and so so for these for these things, it's it's sort of expected that once you train the model, a starting board state will look like point five.

And then as you progress towards the end of the game, it'll actually look something like you know, if this is point five, the the win probability will sort of either go like this or it'll it'll go like this. Right? And and this is sort of your move number.

Yep. And so as you, you know, get hundreds of steps into the game, it becomes much more clear, like, who's more likely to win or who's more more likely to lose under your expert data distribution. I I didn't understand the significance of why the this way of thinking about value is especially relevant to the expert data.

It is not relevant to the expert data. It's true for any data that you traded on. Yeah.

So if you were to learn a Tableau Rasa, you would also expect this to fall out. Yeah. So if you just do this, like so imagine, you know, you're vibe coding AlphaGo and you you you gather some expert datasets from, like, how to go online or you you know, you have a dataset of human players and you train this model.

Actually, it turns out this model is already a pretty good Go player. It'll most likely beat most human players. Right?

So if you just take this policy recommendation and take the argmax over its if this is the, you know, probabilities, if you take the arg max and you just take this action as your Go play, it'll be a very, very fast Go player that doesn't think in terms of, like, reasoning steps. It just kind of shoots from the hip, and it'll be a very strong Go player, which is already quite miraculous if you think about like, you know, 10 neural network layers, maybe under like 3,000,000 parameters can already do something that impressive. Yeah.

And so you can start this way. And it's important when implementing this to kind of just verify that this is probably true. It's good to verify that your Go rules are implemented correctly, that, like, you know, you can run these simulations relatively quickly.

And just as almost like a sort of checkpoint that, like, you wanna make sure that you can actually do this basic step before you try to layer on more complex things like search. Yeah. So but, yeah, we can do a lot better than taking the raw neural network and playing the moves.

And this is how we can apply it to Monte Carlo Tree Search. So let's apply the neural network to improve Monte Carlo Tree Search. So we start with our root node.

And we now have a four step iterative process to do MCTS. So this tripped me up when I was first reading the paper and trying to understand it. But, essentially, what we're going to do is we're going to choose a number of simulations.

So like, you know, num simulations. And this number varies. This can be, you know, somewhere between 200 to twenty forty eight.

I believe in, in the AlphaGo Lee match, they use tens of thousands of simulations per move because they really wanted to boost the strength of the model as much as possible. Yeah.

Well, like,

enough, modern Go bots don't need that much compute at test time. Yeah. Interesting.

And what we'll actually find out as we talk about how the MCTS policy improvement works is that over time, the raw network actually takes all of the burden of that big TPU pod and just push pushes it into the network. And and you can do all of that work with one, you know, neural network bypass. But but the TPU pod will always add the extra oomph on top.

And so that's what they wanted for the match. So so we're gonna pick this kind of like num simulations thing. And for every simulation, we're going to basically do several things simultaneously.

We're going to see which which moves are the best in the current tree. We're going to add extra leaves to the tree if we get to a point where we need to add a leaf, and we're gonna update the action values for for the tree. So that's that's what every every simulation involves these kind of like four step process.

So so the four step process is basically selection, expansion, evaluation, and backup. So so at the beginning of our Monte Carlo tree search, our tree is very basic. It only has the the root node or our current board that our AI wants to play at.

And so we're going to basically select the best action for this. So when this root node is created, we also know that we can evaluate this under our neural network and get the quantities, you know, v theta as well as our probability over actions. And I'm going to say root.

So for all of the actions here, we can create a bunch of children. Right? So so this one has well, in in this case, I'm drawing a three by three board with one one board missing.

So basically, there are, you know, eight possible children associated with this root node. So, like and each of these has an associated probability of taking that action. Right?

So so there's p eight, p one, p two, etcetera. Okay. So at the beginning of our Monte Carlo tree search, we have our root node and we can initialize it with some children.

Right? Because we know it's the the policy network evaluate on the root node gives us on a three by three board with one existing stone placed eight possible children that this AI could take. So with each of the children, their policy network also gives us the probability of selecting that child.

So the, first step is to do the selection of the tree. And again, this is a very shallow tree. All we have so far is a tree of depth one, essentially.

Right? So our our first move is to select by maximizing or argmaxing the pucked criteria, which is basically, you know, q q s a plus, you know, c pucked times p of a divided by n over one plus n a. So for each of these, we're going to you know, n a is zero for for all of the actions initially.

N is zero. And and so we're going to basically just, you know, pick according to this. Initially, what is going to be the, you know, chosen action here is most likely going to be biased towards, you know, the highest likelihood action here.

Right? Because these are sort of uniform for every node. So let's suppose p one was the highest probability node.

So you you you selected this one here. Now, you've got to this node and you realize that it's not a leaf node. Right?

There are more it's not a terminal game, so you cannot resolve Yeah. The the final resolution. So the next step that you do is expansion.

So you will then run this node, this board state, through the policy network. Note that this is the AI's move. Right?

Like, AI is making this move. And so when we expand this tree, we're now thinking about what the human might do or any opponent might do. Right?

So this is like, you know, your your your opponent. The tree expansion process actually is completely so so so when we evaluate the the node here, we're gonna now evaluate the the node from the perspective of this player. Yep.

So then this one has possible actions that we could take, and we we expand basically the the the leaf nodes here. So for each of these nodes that we could, you know, arrive at, we're gonna now check how good those nodes are. Right?

So so maybe from here, like, the human could play here, the human could play here, or human could play here. And we're gonna store essentially the v theta for each of these things. So v theta of, you know, node one or, like, node one prime, v theta node one prime.

And so we're we're basically using our neural network to make an intuitive guess of how good is this board from the perspective of this player. Yeah. And fortunately, because the it's a zero sum game, it's easy to deduce that, you know, the value for this player at this this step is just one minus the value for you know, from this perspective.

So it's easy to flip the search process depending on which player you're at. And so so this is the expansion step. You've taken a a a non leaf node and expanded it and evaluated the value.

And this is essentially a quick guess as to, like, if I were to play to the end, am I gonna win or not? Right? So you can almost think about the v theta as a shortcut for searching to the end of the tree for for any given simulation.

And then we're and this is this is essentially the evaluation step. We're we're evaluating the quality of each of these boards. In original AlphaGo lead, they actually did something kind of interesting, which is that they took this value and they averaged it with the value of a real Go playout.

So they actually played a real game from here all the way to the end. So so, like, I'm just gonna draw this squiggly line to indicate some path. And they kind of, like, play this all the way to res Trompe Taylor resolution of a full board.

And so this is like a zero or one. Right? And so they took this value and they just averaged it with with this one here.

So the the formula they did was like, you know, alpha times v theta of of, like, you know, some some node plus sort of, like, one minus alpha of a of a true randomly sampled playout. And you might be wondering, like, okay. Well, how do they play this out?

Right? Like, it would be very, very costly to do another search on on this playout, like, almost like a tree within a tree. So they don't do this.

Instead, they just take the policy network and play it against itself. So they just take this as both players, they just play it all the way to the end. And and, this is something that helps ground the, the estimates here in in reality because you can get a single sample estimate of, like, whether you win or not.

You can think about in the endgame where the board is almost resolved that this one actually becomes quite useful because the random the the the play according to the policy will most likely decide a pretty reasonable guess of the game. And so you're not, you know, facing a problem where this one kind of becomes untethered from from reality. It turns out this is totally unnecessary.

So in all subsequent papers after AlphaGo Lee, they just got rid of this. Yeah. And so in my implementation, also did the same, and it speeds things up a lot because you don't have to roll these games out on every single simulation.

Almost. So a simulation is easy to think about when the whole tree already exists. Right?

You just walk down the tree using the puck selection criteria, and you you and then and then you keep going. Yeah. In AlphaGo, the the data structure is such that we begin with a tree that has no, like, basically only depth one, which is its only children.

And you want to iteratively build out the tree Yep. As you're also selecting actions down the tree. So that's the kind of core thing here is that because Go is such a combinatorially complex game, you cannot afford to build the tree in advance and then search it.

You must search while building the tree. Right. Okay.

So let me just finish up with actually the last step, which is the backup. Right? So once you've scored these things, you basically take the mean the the value the the q value assigned to the node here for taking this action is now just the average across your evaluated values.

Yep. It's you take a running mean over over all of the the simulations that you've taken, and they average the values of the children nodes. Yep.

So so that's what is known as the backup step. And once you evaluate this, you can actually kind of recursively go back. So if you know the, you know, the action value of this node, you can then take the average on its parent and so on and so forth.

So so you have this kind of four step process where you are choosing the best action that you know of so far. Then you may run into a node where you you you haven't been to before, so you need to grow the tree a bit. And then you run it through the network to guess whether you're gonna win or not.

And then you walk all the way back up to the to the root node to update your values on what the best moves are. So as you do this iteratively, this selection criteria will cause you to visit the because you're always selecting according to this criteria, you're always gonna be selecting the best action you think at any given branch. Right?

So so the final visit counts of, like, how often you chose these things will reflect your correct policy distribution as induced through this search process. And so the visit count that we store in the node earlier actually becomes the sort of vote for like which way we should finally select an action here. Yep.

So, you know, as a sort of test of understanding, it's worth thinking a little bit about whether we could make this even simpler. Right? Like, could we actually maybe even get rid of this one and still make the thing work?

So recall that, you know, when you do an expansion and then an evaluation at, let's say, this node, you you are checking the sort of win probability of each of the child nodes. Right? And so if this one is, you know, like one and these are zero, you do kind of know something about which action might be better to take.

And so why would you need still need this? Right? Like, why not just, normalize this one into some distribution and call that your your policy distribution?

This is fine. You can do this. And this probably does work.

But in practice, having a single forward pass that gives you a pretty good guess is is how the the breadth is is is pruned out. The there is a sort of duality here. Like, it would be weird if, let's say, the policy recommended an action that disagreed with the value.

Right? If if, let's say, policy said this was very high probability, but this one said it was a, you know, low value, then there's actually something kind of fundamentally wrong between your policy head and your value head. So they are linked and you probably could get rid of this if you came up with a different way to recover this from just the value evaluations.

You can usually batch these somewhat efficiently. So it probably is not a huge computational burden in practice. But, yes, you would have to pass 361 board like, up to 361 boards into a single mini batch update to evaluate all the values here, then normalize them.

Now, there's actually a more important reason why we still do this, which is how Monte Carlo tree search is used to feedback on itself and and sort of recursively improve its own predictions and search capabilities. And that's where this this one, having this as an explicit entity you're modeling rather than an implicit normalize normalization over your value is is a is a good idea. Makes sense.

Okay. Okay. So so we we talked about the simulations.

And, basically, you know, what you end up with as you roll out the number of simulations is a tree that kind of looks like I'm I'm I'm drawing a very low dimensional version of this. Of course, it's in in in the real game. It's like it's much more high dimensional.

But, like, you'll end up with basically a tree structure that, like, has a lot of leaves that kind of terminate and are not visited again because their value is deemed to be too low. But then, you know, along one path, there will be a set of actions with very, very high visit counts that kind of gravitate towards that one set of decisions as you increase n. So so this is kind of like the the mental picture of what the tree in Monte Carlo tree search looks like.

And you should contrast this with, like, an exhaustive tree, like, in tic tac toe where you could say, like, you know, there's there's nine actions and then eight and then seven and six. And so it's a sort of, like, nine factorial sized tree. The Monte Carlo tree search in Go is very, very sparse.

Right? It only considers the paths that you've expanded children nodes on. Okay.

So now that we have the search algorithm that applies the value function as well as the policy function, we can now talk about how the Monte Carlo tree search algorithm can actually act as a improvement operator on top of these guys here.

we now talk about the RL part of, like, how this thing gets stronger by playing itself. Right? Let's say we play a game where at the AI so you make a move.

AI AI will will kind of compute the search, and then this is this sort of visit count distribution. Let's say this is your policy, your policy initial policy recommendation at the at the at this node. Mhmm.

And then after MCTS, it gets more confident about one of these actions. Right? And and so maybe the the distribution looks a bit more peaky like this based on the the search.

Now, of course, you can tune the search process so that it ends up more diffuse, but that's probably not a good idea. MCTS should get more confident about specific actions than others. But it, of course, might place a lot of weight on, you know, other actions initially.

And then as you increase the number of sims, it should converge to a very peaky distribution. So so this is your new let's call this like pi. Let's wrap this in like a MCTS operator of, you know, a given s.

Right? So after applying MCTS process, your policy recommended distribution looks like this. It's it's a bit more peaky than than the previous one.

And so then you take the argmax or maybe you just sample from this. It doesn't have to be argmax, and then you you make your move. And then and then you throw away the tree, and then you you begin anew on the next move.

Right? So, again, like, you, you know, you compute a new distribution. So initially, maybe your guess looks like this, and then you refine it through MCTS.

To something that looks like right. So so on every move, you have your initial guess from your policy network. And then the search process that combines your policy network and your value network arrives at a more confident action that you take.

And and then so and so forth. And then the game ends, and one person wins and one person loses. So a the way that the beauty of of how AlphaGo trains itself is that it actually can take this final search process, the outcome of the search process, and tell the policy network, hey.

Like, you know, instead of having MCTS do all this, you know, legwork to arrive here, why don't you just predict that from the get go? Right? Like, why don't you, like, you know, not use this guess and just predict this to begin with?

And if you have this guess to begin with in your policy network, then MCTS has to do a lot less work to to get things to work. And so if we draw like a sort of test time scaling plot, so so let's say like this is like number of simulations. Let's say, you know, at at zero simulations, your your sort of implicit win rate is like is like, I don't know, here.

And then and then without any sim if you just take this raw action that this is what your win rate is. And let's say as we increase the number of sims, maybe maybe you kind of have a win rate that looks like this. Right?

So when you search for, let's say, a thousand simulation steps, that gets you to a policy here that gets you to here, which is great. But if you were to distill this MCTS policy network back into your sort of shoot from the hip policy network, then you could actually, you know, start here. Like, if let's say this was, you know, zero for by by distillation, then if you spend another 1,000 SIM steps, then you actually kind of get to here.

It's almost like if you could just, you know, amortize the the first 1,000 steps actually into the policy network instead of the search process, then you can begin at a much better starting point and then get a much better result for for your for the number of SIEMs that you put.

To be honest, I actually don't know the test time scaling behavior of MCTS simulations, and I I believe it might actually be quite sensitive to how strong this one is in practice. I'm just drawing a monotonically increasing function that gets to one. Okay.

Cool. Yeah. So don't pay too much attention to the shape of the curve.

Just know that it's monotonic with respect to something. Okay. So so so the idea of MCTS is very brilliant, which is like we're gonna we got something better by applying search.

Yeah. And we're going to now, on our next iteration of updating this network, just train this to approximate the outcome of a thousand steps of search. And so instead of starting here, we get to now have our neural networks start here and then and then, you know, the the play gets stronger once we then apply another thousand steps on top of it.

And you can keep going. Right? So so the training algorithm for AlphaGo is to basically take the games where you've applied the search on every move that the policy encountered, whether you won or lost, and that's quite important.

And you're just gonna train the the model to imitate the search process. So there's an analogy to robotics actually, which is the dagger algorithm. First, I'm gonna draw like a schematic of like, let's say, you know, the states.

Right? So s zero, s one, s two, s three. So let's say, you know, we we took a series of actions in an MDP to to get a trajectory.

And these actions may be suboptimal. Right? Maybe we lost at the end of this game.

So there is a family of algorithms that basically take trajectories and relabel the actions to better trajectories. So maybe a better action here would have been to take, you know, a zero prime. A better action here would have been to take a one prime and then yet another one like a two prime, a three prime.

So, what MCTS is doing is basically saying, like, you play this game where you eventually lost. But on every single action, I'm gonna give you a strictly better action that you should take instead. It does not guarantee that you are going to win, but it does guarantee that, you know, if you take these tuples as training data so that you retrain your policy network to predict these ones instead of these ones, you're going to do better.

And this is very related to Dagger in robotics and imitation learning where you want to collect a intervention here. And even if you're in not great state, for example, like a self driving car that veers off the side of the road, there is still a valid action that kind of corrects you and brings you back. Yeah.

Okay.

and it does work in also in practice. But let me illustrate a example where MCTS can give you a worse distribution than your policy network. So and this can often happen if your self play algorithm has trained to a good point, but then somehow it's it it collapses because it's it's not trained on diverse data or something.

Right? So let's say we have a board state where the policy recommendations here are very good. So so, like, you know, pi of a s is, like, great.

But somehow, because maybe we're playing on a lot of games where the the bots just resign instead of playing all the way to the Trump Taylor resolution, they kind of forget how to evaluate those kind of late stage plans. Right? Like in the in the case that we showed with the corner play, maybe like a 100% of our training data in our replay buffer has lost examples of how to evaluate the value function at those states.

So you might end up in a scenario where your terminal value is, like, very bad. And if the terminal values of the leaves are not good, then this will actually propagate all the way up and cause your your your pucked selection criteria and your backups to be off. And then you end up visiting a very, very different distribution than what your policy initially recommended.

Also, if your number of SIEMs is low, then you might also have a variance issue where you just don't explore enough. Right? Like like a it's only guaranteed to converge when you kind of take n to infinity.

So so variance in, you know, your search process as well as inaccuracies in your evaluation can definitely screw with the quality of your policy network information. And so that's why it's not a guarantee to improve. And that is why I suspect why AlphaGo Lee had the playoffs to the end in their training algorithm so they could ground this thing in real plans.

Yeah. In practice, what you could also do is just like for 10% of the games, you you prevent the bots from resigning and you just say, like, resolve it to the end. Mhmm.

So you get some training data in your replay buffer to really resolve those kind of like late stage playouts that normal human players would would kind of not play to. Yeah. Yeah.

So this is why MCTS kind of if you assume that the value functions are correct, why it gives you a better policy is because yeah. And it's a very critical chain of assumptions. Assuming that this is accurate, then your search process should give you a better recommendation than your initial guess.

Right. Okay.

functionally, that's all that's happening. And later on, once that's well trained, now the policy is also improving. Correct.

Okay. One trick I did find to be pretty useful, and this is not a peer reviewed claim, so just like take this with a grain of salt. It's like, I I found it useful in my own implementation to do to do the following.

You wanna first make sure that this is good before you invest a lot of cycles doing MCTs. Right? Like like, it it doesn't really make a lot of sense to do search on garbage value predictions.

So so you wanna kind of start at a good place where this works. AlphaGo lead does a very good thing where it just takes human games and then you you, like, trade on it and it just works. Right?

Totally works. You can also take an open source GoBot, play it against itself, generate data, also works. So so if you have some, like, offline dataset that that has realistic good play, you can easily learn the late stage value functions pretty well.

And that's the that's what you kind of need to start the search process. Sorry. Can you just read this sentence more fast?

Sure. So so it it's quite easy to evaluate a late stage go go game. Like, when almost all the pieces are on the board, like, it's almost like a decidable problem.

Right? Because it's bit lower and lower uncertainty as to, like, the depth of the tree. So most games play to the end by reasonable people will be good training data to train a good value function at terminal parts of the tree.

Got it. Okay. Then as you play more games, the the search will back up good values into the the sort of intermediate nodes of the tree.

And then like as you increase the amount of data, your your value head gets a good intuition of like what is a healthy board state versus a not healthy board state. Yeah. That that those are much more subtle to judge in the mid game than the beginning or the end.

So the the most difficult part to score is like, not the beginning or the because the beginning is just like obviously 0.5, and then at the end, it's like pretty obvious who's winning. So so the hard part that you want to learn in the value function is like who is winning in the middle.

And so this this is actually very analogous to TD learning. Yes. And there's a beautiful connection to TD learning that we can, you know, talk about in a bit as opposed to, you know, contrasting with Monte Carlo research.

So so you first wanna get good value functions, and expert data can kind of give you a quick shortcut. I recommend for, you know, practitioners just do that first just to, you know, initialize to a good starting point. And then if you wanna do the alpha zero thing or or KataGo kind of Tableau Rasa learning, then what you can try to do is on a small board, play random games.

Just take a random agent. And if you play, like, you know, 50,000 games, you'll actually learn a pretty good value function as well. Because on a nine by nine board, there's actually you can see enough of the common patterns with random play.

And then if you train a model that kind of can train on both nine by nine and nineteen by nine data, and Katago was a proposed one of these architectures, then there's some pretty good transfer learning from the value value head evaluated at nine by nine to the 19 by nine. Right. Because this this, unlike other games, has much like, very much a sense of, like there's not, a new kind of piece that is introduced when you Yeah.

Increase the size or something. If if we take it to its limit and consider like a very tiny, like, four by four Go board Yeah. Like, if you play 50,000 games, you're gonna have a lot of end states that look like human Yeah.

Yeah. Play. Right?

Like, it's just like tic tac toe at that point. So so if you, like, broaden this a little bit to, nine by nine five by five or nine by nine, it's not unrealistic to imagine that like purely random play will actually generate pretty reasonable looking Yeah. Boards.

And then so you can score those pretty easily. And so that is what gives you the bootstrapping to be able to then improve your policy Yeah. With search.

But it's very, very critical that MCTS has accurate value estimates. Yep. And you need to ground the value.

they they merged them into two heads. And presumably, this saves compute. But answering that question in a very rigorous scientific way is actually it's a simple question, but in practice actually takes like, you really want to chase that question down to its limit, it takes quite a bit of work to really resolve that.

Intuitively, But yes, they share a lot of representations. So so and, you know, as we mentioned, is there is a sort of like your your policy network and your value network when doing evaluation should kind of agree. Right?

So there there really should be this sort of consistency between them. Yeah. Tell me this is the wrong way to think about it.

I I personally disagree. I I think they're profound for different reasons. And I don't understand the LMRL like enough to like kind of comment on your podcast about it.

But I think AlphaGo so so yeah. Why is it a profound accomplishment? I think maybe it's worth stepping back a little bit and just like, it is different than modern RL, and we can talk a little bit about like some of the algorithmic choices there.

But I think the most profound thing here is that a a 10 layer neural network pass. So basically, 10 steps of 10 steps of reasoning. Yeah.

And of course, the reasoning is not just one trail of thought. It could be like the distributed representations and a lot of thoughts going on at the same time. But by construction, let's say, 10 layer neural network can only do 10 sequential steps of thinking.

Yeah. Right? 10 steps of neural network paralyzed distributed representation thinking is able to amortize and approximate to a very very high fidelity a nearly intractable search problem.

Yeah. So so this was a breakthrough that I think most people don't even understand today, like fully comprehend, like how profound that accomplishment is. And then this is what also girds like AlphaFold, for example.

Right? Like, where you have a very, very difficult physical simulation process that you would need to roll out so many microscale simulations. And yet, like, 10 steps of a somewhat small neural network can somehow capture what feels like a, you know, NP class problem into a single problem.

And and so I I it it actually makes me wonder if, you know, our understanding of problems like p equals NP or these very fundamental computational hardness problems are incomplete. Right? Like, it's not like obviously, this is not a proof of p equals NP or anything, but there's something to it that kind of is very disturbing where like what felt like a very hard problem can fall to a very, very simple macroscopic solution.

the kind of question we should be asking ourselves is like, we've been formulating solutions to NP hard problems as in the kind of worst case complexity. And I wouldn't say this solves Go, right? It doesn't give us an exact solution of the optimum.

But in practice, like, it is extremely useful. Yeah. And the same thing has been shown in like alpha tensor, alpha fold, where like, yes, there is a very hard problem that in the worst case seems intractable.

Yeah. And yet we're able to make like almost arbitrary amounts of progress. So here's a sort of like in the limit, what might this look like?

Well, if you want to simulate something very complex like weather or predict the future, like do we live in a simulation or not, The computing resources you need to build a very complex simulation might be much smaller than you think based on our ability to amortize a lot of that computation into the forward pass of a single network. Interesting. So to me, yeah, AlphaGo was the first paper that kind of like really showed this like profound level of, you know, simulation being compressed into a small amount of code.

the problem of, like, you know, here's our current board state. Yeah. Given what we know about both players, what is the board state in the future?

Yeah. What is the exact board state in the future? Yeah.

Right? This is this is extremely sensitive to initial conditions. Like, a single stone place here can kind of disrupt the entire prediction.

Yeah. Right? So this is hard.

This is kind of intuitively the chaotic problem. And yet somehow so this is this is hard. Somehow, we can predict who's gonna win.

Yeah. Like, and this captures a lot of possibilities here. And so that there's this more macroscopic quantity that we really care about, which is the average or expectation or some sort of global macro structure over a lot of, like, you know, possible futures.

Interesting way to think about it. And so so and and whether it could be the same thing. Right?

Like, we don't exactly care, like, what the, you know, velocity of wind 6,000 feet above a specific latitude, longitude is. We kind of care, like, where's the hurricane or, you know, know, things like that. And and I would say like in chaos, you know, there's a classic like Lorenz attractor, which kind of looks like this.

Right? Yes. You you don't if you start anywhere on the Lorenz attractor, you don't know where you're gonna end up.

But you you do know that the thing looks like this. Yeah. Yeah.

Right. And and so there's this kind of beauty of like, sometimes we don't necessarily care about the microscale things. We actually care about the macroscopic structure.

That's interesting. And and these things can be predictable.

Yes. Intuitively, that seems correct. I I and then, again, this is also out of my my area of expertise, but I I find it interesting that, like, cryptography has not been able to like, the tools of cryptography and, you know, hashing have also not been able to prove that, like, you cannot come up with fast approximation.

Like, you cannot come up with fast approximations. If that if they were able to do that, then you could prove p is not equal to NP. Yeah.

Yeah.

you similarly want everything to be dependent on all the information because you want to process all the information and consider how it relates to itself. Yeah. You have the maximum power of a neural network at the edge of chaos.

I think there's some, like, research papers from, Joshua Stroldick's team on on on this. Yeah. Yeah.

Like like, there's something kind of quite fundamental about, like, chaos that is it's not just like hopeless noise. It's like there's something kind of useful, right, in in in chaotic systems Yeah. At least at that boundary.

But, yeah, this is just my think about this as a philosophy. I don't I don't actually know the math well enough to comment on it. Anyway, if we go back to we'll talk about LMRL a little bit because there's some connections there.

Let let's just go back to, like, the MCTS. Like, what is it doing? It is not crucially, it is not saying we're going to increase the probability of winning directly.

It's not gonna say, like, we're gonna upweight all actions that won and downweight all actions that didn't win. Importantly, what it is doing is saying for every action we took, we did a pretty exhaustive search on MCTS to see if we could do better. We're And just gonna make every action that we took better by predict like having the policy network predict that outcome instead.

And and so this is a very, very nice idea because you have one supervision target for every single action. Yeah. So the the variance of your your learning signal is very low compared to the alternative naive RL thing.

So so let's actually consider what let let's consider a very naive algorithm that looks a lot more like, you know, modern LMRL today, where where we do something like, let's take the winner of a self play game and encourage it to do more of that. Okay. So it's worth kind of thinking a little bit about like, okay, what are some alternatives that we could do to train self play agents instead of MCTS?

Right? Like, you know, we we use a lot of LM style RL these days. Like, is that relevant?

Could we do that instead? So so let let's think through this a little bit. Let's suppose we have a very naive algorithm where we take a league of agents of different checkpoints and we play them against each other.

And for the for the games where a single player wins, we're gonna reinforce those actions up and then and then and and retrain the policy network to imitate those those guys instead of instead of the MCTS objective. So what ends up happening is, let's say you have a chain of actions that led to a win. And you have a matchup between two agents that are basically the same.

So in fact, let's just assume that like, know, policy A and policy B are like evenly matched. Right? So their true their true win rate is is, like, 50%.

So let's say you play a 100 games. And then, each game, let's say, lasts, you know, 300, moves. And you're doing some sort of, like, evolution strategy or some way to perturb these things to get them get them to do different things.

Or maybe you don't, and you just play them against each other. And you see, like, occasionally, this one might actually have a better strategy than this one. Right?

And so so let's say, you know, 51 games, policy a wins. And then 49 games, policy b wins. And this is just due to random luck or maybe you perturbed policy a in some way that let it do this.

And just to have a very, very simple model, let's pretend that for for, like, 49 of the games, they played exactly equally. I'm sorry. For for 50 of the games, they they have to play it exactly equally.

Right? And on that one game where this one won, it it played slightly differently. It made, like, one critical move that, like, normally it would have done differently, but due to some exploration or some random noise, it just happened to make a smarter move than it did previously.

So you have one supervision signal, like one true supervision signal for your policy network. And then you have 99 games times 300 moves for which imitating those actions gives you exactly the same policy you had before. And so the scale of your variance is actually very bad because it's like you only have one label out of this enormous data set of actions, of supervision actions where you want Actually, sorry, let clarify a little bit.

and so, yeah, it's interesting that this, like, this thing you're saying which would be intractable and prevents you from actually getting beyond a certain level in Go is just by default how LLMs are trained, question mark? Right. So in this case, this is not to say it doesn't work.

Right? Like, if you imagine increasing the number of games to, like, you know, millions of samples, you actually can get some meaningful supervision, like, samples so long as you find a way to sort of mask out the supervision from these guys. And then this is where things start to get pretty related to RL in terms of advantage and baselines and so forth.

So so let's let's look at the, you know, the gradient variants of a very naive approach like this where I'm just gonna call it like gradient RL. And it's basically the, you know, sum of rewards. Mhmm.

So so the sum of rewards is the return. Right? So so, like, in in our naive setup here, we only have a indicator variable for the return where either you won or lost.

So so in the case where you lost, well, you just don't train on your gradient is zero. You don't train on those examples. And when you won, you try to predict those those things.

Right? So so you can think about this setup as a as a special case of this general formula here. The the trouble here is that this is very high variance because when you multiply these terms out, when you take when you try to compute the variance of this, and so so variance of the gradient is equal to expectation of squared minus and just for simplicity, we can pretend this is like, know, on average zero or something.

We if if you're centering it at at, you know, no signal. And the variance here basically means that you're, you know, taking the square of this product term. And so you end up with a term that kind of grows quadratically with the with t.

So so variance when you have a setup like this, this thing acts as a coupling effect on top of of these terms here. So let's actually map this to an LLM case. And we can answer, like, why do LLMs only do one step RL instead of a multi step RL scenario?

In LLMs, you have a decoder that might, you know, predict some words like hello world. And so in current LMRL, they treat this entire sequence as a single action, just a t, and big t is just one. Right?

And so, yes, it is true that, you know, because of how, you know, transformers are formulated through the sort of product of conditional probabilities, we do have, you know, probability of this sequence is equal to the sort of sum of log probability of the whole sequence is equal to the sum of the probabilities of, like, you know, individual tokens. Right? So so in this case, I would I would say something like, you know, log l plus log low plus log world.

So, this is true. And if this term were one, then they would be the same thing. However, in sampling things, if you have a reward term assigned to every specific token, now you have these interaction effects between the cross multiplication of these terms and these terms.

Right.

You could imagine a reward that says like, I'm gonna give you some process supervision Yeah. Where you get a reward for each of these actions on every step. Okay.

rewards? So so the the thing that's a little bit hidden here in the math is that we're assuming that when you decompose the problem to a multistep problem, that you're now introducing kind of correlations between your actions through the computation of this guy. And so if separate these things out, then there will be this this will magnify the variance of of this one.

So in in the case where you don't separate it out, if you just have t equals equals one, you just have a single estimate of logprob Right. And a single estimate of reward. Now, there are this this term still shows up in l so in LMs, it looks a little bit more like the the naive reinforced estimator looks a bit like return of the single action plus so times, you know.

It looks kind of like this. This is sort of the very basic form here, but this is still a contributor to variance. So you want to make sure that like you don't similar to how in this case we were training on a lot of neutral labels.

You want to make sure that you're subtract you're you're sort of penalizing the labels that don't help and only rewarding the ones that actually make you better. Right. Right?

Actually, the optimal case is to pull out, discard all of these moves and only get a gradient on that single move that you got better. Yeah. But how would you do that?

Right. So this is a pretty tricky problem in practice. And so this is where advantage estimation happens in reinforcement learning.

So you want to subtract, you know, a term from from from your your multiplier instead of an indicator function of like one and zero. You want something that kind of behaves like a zero for all of these guys. Yep.

And then a one for all these ones. Yeah.

Well, you won on a lot of games. Exactly. But but you don't know which ones let you win because they were truly better Right.

Versus winning on accident. How would you design a baseline where it's truly better? Yeah.

So this is where in RL, people use things like TD learning to better approximate the quality function, the queue that we mentioned earlier. So you can try to subtract that from your your return. I see.

So ideally, what you really want to do is, in RL, you want to push up the actions that make you better than the average. Yep. And push down the actions that make you worse than the average.

And they call this advantage. There are multiple ways to compute it. I highly recommend John Schulman's general advantage estimation paper as like a good, you know, treatment on how to to like think about various ways to compute it.

is trying to solve a credit assignment problem where you don't know which actions were actually good and which ones were bad. Monte Carlo TreeSearch is doing something very fundamentally different, which is it's not trying to do credit assignment on wins. It's trying to improve the label for any given action you took.

And so we can actually think about a completely different algorithm called neural fictitious self play, which was used to great effect in systems like AlphaStar and and OpenAI's DOTA. So so let me talk a little bit about how how you can kind of unify some of these RL ideas in the model free setting as well as the self play setting. Mhmm.

Okay. So what happens if you don't have the ability to easily search a tree? Right?

Like, in Go, it's a perfectly observable game. You can easily construct a pretty deep tree that completely captures the game state. In a game like StarCraft where you don't have really complete control over the binary, it's it's a little bit hard to do this, and I'm not even sure if it's a it's a deterministic game.

Right? So so that makes this kind of difficult from a data structures perspective. So what is done instead is that the basic idea of supervising your actions with a better teacher is still there.

Right? So so if if you know, given neural fictitious so we're gonna talk a little bit about how neural fictitious self play works. Same idea.

We're gonna, like, come up with better labels for each of the actions we took, just like an MCTS. But how do we derive the better labels? In MCTS, we perform search to and assuming we have a good value function, the search will kind of give us a better result than our initial guess.

In a game where you can easily simulate a search process, what they do instead is train what is known as a best response policy. So you fix your opponent. So let's say you're you're currently training pi a against a strong opponent, pi b.

In Starcraft, maybe, like, you know, these are the Zergs and you're playing Protoss or something. So you fix your opponent, and you treat this as a classic model free RL algorithm where your goal is just to beat this guy. And so here, you use your standard TD learning style tricks or use PPO or any, actually, like, you know, model free RL algorithm to try to hill climb against winning this player.

And so you train you train basically, you you you have a reward function that's like, you know, return is like, you know, one if wins against IB. So this is no longer a self play kind of problem. Right?

This is just like a fixed opponent, and you're just solving trying to maximize a score against against that. And then, know, zero otherwise. And so you have a sort of fixed environment where all you care about is just beating this guy.

And once you have a good policy that you train with, pick your favorite model free R algorithm PPO or SAC or any kind of mixture of the or VMP or whatever, you now have a good policy that gives you a good label for what this one should do when playing against that player. And when you train multiple best response policies, you can basically then distill the RL algorithms into the labels for a given opponent. So you might have, let's say, a best response policy against PyB, and then maybe you have a collect a league of opponents like PyB, PyC, PyD, and you're gonna take the best response policy that you train against each of these fixed opponents.

And for this one, you're going to supervise them with the label that this one would provide. So it is kind of like this is almost like a proxy for your MCTS teacher. Right?

Instead of MCTS teacher, you use a model free RL algorithm to find the best search action that you could do to to kind of beat your opponent. And then you're finally you're distilling the policy here into what is known as like a a mixed strategy where it's trying to basically average across all possible opponents you could play against. And this is what gives you something that can do no bet no worse than, like, you know, an averagely average selected opponent from the league.

And and so this gets around the problem of having to derive a teaching signal from MCTS, but it still fundamentally is about relabeling your your your states with better actions so that they improve your policy.

on that trajectory. Yes. So here you can use a number of algorithms like PPO, VNPO, Q learning even if you want.

The specific algorithm here can be, you know, it's usually a model free thing because you don't have search. But it is an interesting connection from MCTS and Q learning that I want to, you know, bring up. So in MCTS, you do something where you have a tree.

And through the resolution of your value function at leaves of the tree or, you know, your approximate leaves of the tree, you can kind of back up through the, you know, sequence of many sequences and then obtain some sort of mean value estimate. Right? Like, your q is kind of derived from the average of a bunch of simulations.

In model free algorithms, there's often a component of estimating a q value. And so and q q values are often learned through TD learning. Although in PPO, the the way that they do advantage estimation is not necessarily through a Bellman backup.

But but in q learning, there's this kind of a very cool trick where you do, you know, q s a is backed up as r plus, you know, some discount factor times the max a q of your next step. So intuitively, how this works is like if you have a MDP, and then this is like, you know, terminal. What this is sort of saying is that, like, the best action you can take at this state is equal to the reward you take for, you know, taking this action plus the best that you can do at the next state.

So there's a sort of recursive and dynamic programming property of MDPs. And you can train neural networks to basically try to enforce this consistency. Right?

So you can say like, well, once I know the queue value of this action, I can then use that to kind of compute something about the queue value support. So when earlier I was like, hey, why are we training policy? Why don't we just train the value alone?

That is what this is. This is a algorithm for recovering value estimates of intermediate steps when you don't have the ability to do forward search. So you must collect a trajectory first of, like, n steps before you're able to do this trick.

But the intuition is kind of the same, which is that like knowing something about the q value here can tell you something about the q value here. And indeed, you can recover a policy from a q value. Right?

So so the you don't need to explicitly model the policy distribution. You can actually recover the policy distribution by doing argmax over your your queue values. Right.

Yep. So so q q learning or, you know, this kind of like approximate dynamic programming kind of propagates what you know about the future queues backward like this. Right?

And you can see that there's a sort of similar structure that goes on here where, in in this case, you you're planning over trajectories your agent hasn't actually been to yet, whereas in this case, you're planning over trajectories your your agent has visited. Yeah. So so importantly, why does Q learning why was Q learning a big deal?

It's because historically, we just haven't had the ability to do search on fairly high dimensional problems like robotics or whatever. So for a long time, we kind of make the assumption that like, okay.

having to unfold all these trajectories. So there was some research, I think, from Google in 2030 2023, 2024 where they did try to apply tree structures to reasoning. Yeah.

And I think it's, you know, the jury is still out as to whether this can ever work. So I I would say like, it we probably will see like, you know, revisiting of this idea of forward search in in the future. But there's two things that make MCTS very simple for Go, which is that value estimation is kind of concrete and you can determine it for real.

And then you can kind of sort of use it to truncate depth, as you said. Yeah. And then the breadth is also determined.

And what's kind of critical is that the action selection algorithm where you iteratively visit and grow the tree is well suited for the size of problem that Go is and the depth of the problem. But for something like LLM reasoning, pucked might actually not be a good enough heuristic. It might be too greedy with local tokens, and it might do something like, oh, only give you sort of obvious thoughts that are correct, but not really solve your final problem.

Yeah. So I I would say the jury is probably still out on how, like, what the final instantiation of reasoning for LLMs would look like. And I wouldn't rule out that, like, this stuff could, you know, come back, but it's been hard.

Yeah. Certainly, I think that LLMs manage to do something that looks like real human reasoning without having to do an explicit tree structure. Yeah.

That being said, I think the idea of doing forward search and simulation to get a better sense of what is valuable might make a comeback even though not exactly in the same instantiation as as Okay. AlphaGo.

So here's an example where LMs break down. The CPAC rule involves, you know, square root of n over one plus n a. In an LLM, like, you're most likely never gonna sample the same child more than once.

Right? So if you have, let's say, multi steps of thinking, because language is so broad and open ended, it's a sort of discrete set of actions is not really an appropriate choice for an LLM Yeah. Even though they're discrete tokens.

Yeah. It's just such a large number that this type of exploration heuristic is probably not the right thing to do to guide how to search down a tree. Right.

your next move in a way that doesn't result in in a way that's independent of actually, like, solving the problem? No way is a strong word. I think lots of people have thought about how to try to apply MCTS or its kind of successors like New Zero to continuous control spaces.

And I'm sure, you know, very cool research work is still ongoing to try to crack that problem. But, yes, the the seeming challenge right now is that, like, most problems in much higher dimensional, you know, action spaces or something that's combinatorially much bigger like language, they they don't seem as amenable to the kind of discrete action selection heuristics as well as kind of game evaluation type stuff that Go does. But that's not to say the idea of, like, you know, thinking into the future along multiple parallel tracks might not give you some information about, like, which way to search.

Right? Like, if you think about mathematics, I think mathematics often occupies a a little bit more of, a logical search kind of procedure where you kind of can back up. You can kind of see like which path seemed good or not.

There's more of a rigid structure there. Whereas maybe like in a, you know, business negotiation or something, it's less of a tree and maybe, you know, something a bit different.

and how it interacts with model size are quite profound when it comes to like how much needs to be actually done as explicit search versus how much can be packed into the forward pass of a neural network. Right? And and how does a forward pass of a neural network sort of learn how to do something that should be a sort of sequential and, you know, recursive step?

That's quite interesting. Yeah. So the yeah.

The Andy Jones scaling loss for board games paper is quite cool. There's another really nice result from that paper where they where he showed that not only can you predict scaling loss of, like, you know, the sort of LLM variety where as you increase parameters, you can decrease the amount of compute for search or vice versa. He also showed that you can actually predict how much compute is needed to solve a larger version of the board game, for example.

And and so with Go, you know, which can scale from, you know, three by three to infinitely sized, you know, Go board, might you actually be able to sort of revisit this question and try to reproduce whether this shows up. I actually started this project with this sort of a motivation that, like, does the bitter lesson or does our knowledge of scaling laws allow us to kind of execute a lot better on a sort of compute optimal Go bot? And can we can we kind of build a strong Go bot without all of the KataGo tricks, right, just just by really focusing on the bitter less than the scaling loss.

I have not been successful so far, but I think it's it's sort of a a fact that, like, usually when you want scaling loss to work, you want to be in the regime where the the recipe already works and the datasets are good rather than trying to kind of figure out how to do scaling while also trying to figure out what the the right dataset are. Okay. So so this is on like, the scientific understanding component in research often follows a step where you get something to work first.

Mhmm. And then you use that system to collect data that then helps you build a mental model of how things work, such as scaling laws. Right?

And and so usually, actually, if you wanna build a strong go bot using scaling laws, you you actually have to make a strong go bot first and then use the scaling laws to kind of extrapolate a bit farther into the future. Say more.

would collect a bunch of data with an expert policy and then treat it as a supervised learning problem and try to identify scaling laws with expert datasets. You can indeed plot things that look kind of like this. But if you're in a regime where your policy is not working well, you might be just studying scaling laws on bad data.

Right? So so just like one important implementation detail is that if you wanna study a scaling laws problem, you kind of have to have a problem for which the data is good, the architecture is good, and there's no bugs. And then you you solve it there.

Ex ante, I wasn't able to apply scaling laws to direct to look at until, you know, I had the rest of the system working. And and this sounds obvious. Like, to to to researchers, of course, you want to have, like, a working bug free system before you study scaling.

But just just as a sort of advice for practitioners on, like, where I actually tripped up when I started this project was you don't necessarily want to kind of jump into the science of studying your man made artifact before your man made artifact is like interesting enough to be studied.

I spent maybe the first 4 k doing kind of exploratory research. Yeah. And then about 3 k on the kind of final run.

Yeah. And then some some of it remaining for serving the model for Cool.

The compute required to be the first to do something is always, like, much larger than the compute it takes to catch up. And it's the same story playing out in LMs. Right?

Like, once someone else has done it, you could use tricks like distillation. You could use all sorts of crutches to kind of bootstrap your way to success. So with my own bot that I've hosted online, I actually used sort of best response training against the Katago models to kind of get a strong level performance.

And, you know, as as a time of recording, I'm I'm validating whether this can be I can kind of do that first step, which is to do the tabular Rasa. Right? But importantly, for research, you often wanna start from a good init.

Right? So so the kind of simple thing I did first was train best response agents against Katago. Yeah.

AlphaZero team, they did not have any policy that they could train against, right, because they were trying to do everything Tableau And being the first to do it means that you're prioritizing getting the thing working rather than, let's say, the most compute efficient possible implementation. So this actually plays out in robotics as well. Like, if you look at the kind of frontier of large models trained for robotics, there the scatter plot is all over the place, and there isn't a very clean line the way that there is for frontier LMs.

And and that is because the folks training these models often are not at the scale where every FLOP counts, and they need to, like, kind of squeeze out the performance of every single FLOP as the dominating decision deciding factor in pretraining. Right? Instead, their focus is more like, we want a certain capability to to show up, so we optimize the training setup to kind of make it easy to derive that capability.

And once you have that capability, well, invariably, if you scale up the compute, you are forced to kind of make it compute efficient because this is like hundreds of millions of dollars we're talking about. But in the past, when compute for experiments was kind of more plentiful or not accounted in a way that the researcher was really responsible for, then you kind of end up with people optimizing for things besides kind of being on the compute optimal Pareto frontier. I see.

Like speed or something. Yeah, like time to result or just getting to work. I think the first AlphaGo, like probably they had lots of compute and they didn't to worry too much about making it the most compute optimal Yeah.

things which they could have been in 2017, but Yeah. Great question. So going into this project, I kind of knew in the back of my mind that things always get easier to do over time, and I wanted to see where is Go at given that it didn't seem like there has been any major open source, you know Right.

Strong bot just after Kadago in 2020. And then, you know, reading the Kadago paper, there's a lot of clever ideas. I was kind of wondering, okay.

Let's let's see if the bitter lesson has happened where, like, a lot of these kind of tricks just sort of go away because the NVIDIA made faster GPUs. Right? And and so roughly, where are we on that?

So, again, this is not a peer reviewed claim. So this is just my preliminary, you know, vibe guess on, like, what I've seen based on my own experiments. But it seems like, you know, architecture choices don't matter that much, you know, transformer versus ResNet.

We're we're at the sort of speed of GPU where the size of the model is not so big that this really matters. You can actually simplify this setup quite a lot. So instead of doing a distributed asynchronous RL setup with replay buffers and pushers and collectors, you can kind of do a dumb synchronous thing where you'd collect, you just train a supervised learning model, and then you collect again.

And so there's opportunities to simplify infrastructure. NVIDIA GPUs have indeed got faster. So whereas Katago was trained on v one hundreds, you can train on half the number of desktop Blackwell GPUs, and it still works.

And some of the kind of auxiliary supervision objectives that KataGo developed aren't really necessary if you have a strong initialization. Right? So if you're initializing against best response training against Katago itself, then your own model actually needs none of the tricks that Katago needs.

Yeah. Yeah. So then the core thing is like, how can you get as quickly as possible to some strong opponents?

And that matters a lot more than the specific architectural innovations. But there are still some nice compute multipliers. So I found that training on nine by nine boards was very nice for resolving end game value functions.

And then like if you can co train that on a architecture that can transfer between nine by nine and nineteen by 19, then you can really cut down the warm start time to learn that from scratch. I think AlphaGo Zero, their plot was first thirty hours or so are spent basically catching up to the supervised learning baseline. And you can cut down that time a lot by kind of pre training on a small board and then and then, like, you know, warm starting that into your, you know, 19 by 19 board play.

There were some other stuff like, you know, varying the number of sims between episodes. This turns out to be not that sensitive, actually. Like, you can kind of, you know, fix it or increase it.

Doesn't matter too much.

off policy versus on policy reinforcement learning kind of questions. So as you recall in MCTS, you take actions that you took and you relabel them to take different actions on the same states. Right?

So so the off policy part here comes where what if you're relabeling states that your new policy would never visit? Right? Like, what's the point?

You're kind of wasting capacity. And in the extreme limit, imagine your distribution of states in your training buffer are all states that you would never visit. Then you're basically supervising them to take good actions on states you would never achieve, and therefore your policy can get really bad.

Right? So this is where off policy can really hurt AlphaGo. However, if you interpret this sort of from like the dagger perspective, which is basically saying like a way to kind of correct yourself back to the optimal trajectory given some some data, What you kind of want in an algorithm like this is to have mostly states that you would visit, but then you have a small percentage or maybe a reasonable percentage of states in this kind of high dimensional tube around your optimal trajectories.

And any of those states are given a supervision target to kind of sort of funnel you back into your optimal trajectory. So maybe I can just draw quickly here. Great.

So in sort of a Dagger style setup, what your kind of optimal training data distribution is, is that here is your optimal states and actions. So, this is like, want to be in this state, you want to be in this state, you want to be in this state, and then you win here. And then these are your optimal policy actions.

So, these are the things that you definitely want to train on. But to make it robust to disturbances, you want to make sure that if you happen to drift off into some other states, you can kind of funnel yourself back into But why isn't this a fully general argument for off policy training? This is actually why you want to do off policy training sometimes.

Is that like, you you don't want to have a compounding error where if you make a mistake, you don't have the data of how to return back to your optimal distribution. Yeah. And so optimal control does not really say too much about how to not accidentally get here because it's sort of making the assumption that once you learn the policy, you're going to get here.

But in applications like robotics, right, like like, I don't know, a gust of wind blows you slightly off and then now you need to like correct. Right? The friction on one of your tires is kind of a little bit like lower than the other wheel and then now now your your car is drifting and you gotta kinda like correct it.

So so these kind of things in in like more real environments often happen where like actually, there was a funny quote about chess and and also Go. It's like, the problem with the the the problem with Go and chess is that the other player is always trying to do some Right? Like so so, like, you know, things can kind of drift off.

Yeah. And you always wanna be able to correct back to your back to your waiting condition. So so your replay buffer really should have, like, your you know, the states that your policy would visit plus some distribution of states that you might drift to and then how to return back to your optimal states.

Yeah. Now, if you take this to the extreme and you say like, well, let's we don't have any of this data. And we're gonna just, like, be labeling with MCTS, you know, states that are so far away from our optimal behavior, like this this bag of states over here.

Well, like now yeah. I mean, like each of them gets a MCTS label, and your policy learns how to do to take sort of the best possible action here, but you never get here. So, like, you're training your model on states you would never reach.

This is not there. So then this is a problem. And this is where off policy can really hurt.

So actually, part of this project, I did try an experiment where I took a bunch of trajectories. And to try to saturate the GPU as much as possible, what I did was I took random states from the dataset and reran MCTS on just those states. Right?

So instead of playing a whole game where I'm doing MCTS on every move, I just ignore the sort of causality of moves and just pick random board states, and I just label those with my current network. And I might revisit old states that I've labeled before and relabel them again with my current network. And so in practice, this actually does work.

You can actually say, like, let's take some states that are reasonable and constantly be relabeling them while we're training. And so this actually starts to converge on a very robotics like setup, which is very common, which is you have your data set of trajectories. And then you have something like a replay buffer pusher.

And and these are off policy offline trajectories. Right? So your replay buffer pusher pushes transition tuples to to to the replay buffer.

And then you have some job that's kind of continuously, replanning what the best action you should have done instead of taking this action is. Right? And so in robotics, it's actually very common to use a a that sort of minimized TD error.

So, like, your Bellman updater Constantly is pulling things from here and trying to satisfy, you know, the QSA. So so, and then and then from here, have your trainer, which is trying to fit the s to a or or or, fit the, you know, queue to the queue target. So so here, you can think about this as a sort of planner.

Right? You revisit old states that you've been to, and you take your current model and you rethink, like, what could I have done better if I visited this? And and so this is actually how, like, kind of off policy robotic learning systems are usually trained.

These days, there's a sort of simpler recipe, but but, like, you know, in the Google QT op days, we kind of did did things like this. So what is the trainer? Oh, yeah.

The trainer is you try to you try to minimize QSA and QTarget. Richard, can you explain the whole setup again? Like at the high level?

Yep. So you have your off policy data that came from various policies. Yep.

You're constantly pushing transitions that you saw before to a replay buffer. And then you've got this thing called a Bellman updater, which basically replans instead of this action, what action should I have taken at s to have a better value? And the way you enforce that is you try to minimize the TD error.

So so actually, you given this, you have s prime. Right? You you compute q of s prime, and you find the action that should go with s prime that makes this q value as high as possible.

And then you add that to the reward here, and that gives you your actual target. Right? So for this current SNA, your queue target is this.

So now you have a now now you send back the queue target to to this this transition. So so with this tuple, you pair with that a a queue target. And then here on the trainer, you simply just use supervised learning and you minimize your current network's QSA with its target.

Got it. Okay. So in the background, you're just like, hey, let me let me basically think through how valuable were all these actions actually?

Yeah. In a in a more optimal policy where you're trying to maximize this, what is the cue target of this transition? It's sort of like basically daydreaming.

Exactly. Yeah. You can think about it's like you're kind of going back in hindsight and being like like like given what I've seen in historical buffer, like, was there a better action I could have taken?

Yep. Now the connection to Go here that I I tried and it was, you know, moderately successful, but too complex to kind of like open source was you replace this with like a MCTS relabeler where instead of doing this kind of target network computation, you run MCTS on your transition. Right?

So in in this case, you have your state, your action, and then whether you want or not at the game. And, actually, you can just toss these two. You don't you don't care about these ones.

You just take your state, and you just plan MCTS Mhmm. To get your best policy, you know, pi on your current network. Right?

Not not the network that took this action, but your current best policy network. You just rerun your search offline on these transitions. And if these are transitions that your policy can get to, then this actually acts as a very nice stabilizing effect.

And also, one other benefit is that you can fully saturate your GPU better because you're not blocking on the Go game to give you board states. You just simply search across all board states at any depth in peril. Yep.

So and then here the trainer would be just, know, predict the MCTS label as possible. So so, again, like, this kind of works, and this is quite relevant in robotics where you're really, you just have a lot of offline data and you can't simulate things like MCTS. But in practice, like it does run into the problem where, you know, like if the current model is looking at states that it would never reach, then it's kind of wasting capacity.

And so you have to be a little bit careful here. So the on policy thing and then also much of RL has kind of converged to a much more on policy setup where they don't really try to directly train on off policy data. At best, they use off policy data as a way to reduce variance but not directly influence the objective.

Sorry. I'm Why have they converged to that? It's just more stable.

Oh, yeah. Yeah. So so, like, you you might use the off policy q as a way to do, like, you know, advantage computation, like, you know, q minus, like, sum of q.

That's kind of like your or sorry, like, there's n actions and then yeah. So this is your value and then this is your current q values. Your advantage for that action is the average value minus your current one.

So so, like, people can try to estimate queue in an off policy way and then, like, just use advantage here. And then and then the the sort of if there's a problem in these dynamics, the it doesn't, like, blow up your loss as much. And so in robotics, there's a kind of convergence towards more like a using off policy data to just shape your rewards, but not actually be directly here.

And what's also tough here is that actually the distribution that you're sampling under is your policy's distribution. So it's like if your policy has no chance of sampling blue, then you will never get a signal. Exactly.

Right.

it would look like that. Yeah. And arguably, you spend all your time here.

Exactly. Potentially, never even getting a single success. Right?

Exactly. So it's a sort of depressing plot in the sense that like once you're here, it's not at all obvious how you get to here. Yeah.

Once you're here, you have something. But like you actually, in many RL problems, spend all the time here. So there's a sort of question of like how do you initialize so you're at least not at zero but like at a non zero pass rate.

One more thing I'd like to add about bits per sample that's very relevant to any kind of machine learning problem is that it and there's a connection to soft targets and distillation where if you have access to the logits, right, not just the one hot like, this this is a sort of one hot token answer. Yeah. If you have access to the soft targets, the entropy of this distribution is far, far higher than the one hot.

So there's actually way more information and bits per sample in a soft label. Yeah. So that's why distillation is so effective per sample is that it's actually giving you way more information per sample.

Yeah.

The entropy of this is zero. Yeah. The entropy of this is like the entropy equation.

And this is also why AlphaGo is quite beautiful. In AlphaGo, you don't train the policy network to imitate the MCTS action. You train it to imitate the MCTS distribution.

Interesting. But both of these are actually valid. And if you wanted to do a scientific experiment of how important are this kind of soft label, dark knowledge distillation, you can run an experiment where you you retrain the policy network on the action MCTS selected rather than the software.

Interesting.

major reason is that you never have to initialize at a 0% success rate and solve the exploration problem of how to get a non zero success rate. And and this is what allows you to hill climb this beautiful supervised learning signal where and if you look at the actual implementation of AlphaGo, every step of the way, there's no there's actually no, you know, TD error learning or dynamic programming, at least explicitly. It's just supervised learning on a value classification as well as a policy, you know, KL minimization.

So, it's just a supervised learning problem on improved labels. And so the training is very stable. Right?

You can train like as big of a network as you want. You can kind of retrain this on the dataset. Everything will just go stably.

The infrastructure is very simple to implement as well. You don't need a complex distributed system to kind of keep everything on policy. Yeah.

At the end of the day, you're just saying like, I have some improved labels. Let's retrain my supervised model on these targets. And so you're always in this beautiful regime where you're just trying to improve the policy rather than escape this kind of local minima where every signal is flat all around Yeah.

So so one way to draw the the curve is like, if you draw the sort of win rate of an MCTS policy versus the raw network, let's say this dotted line is the raw network, the MCTS policy kind of looks like like this. And so every step of the way, this supervision signal is very clean. Right.

You're never in a situation where the MCTS is kind of like giving you no signal. Yeah. Unless your MCTS distribution converges to exactly what your policy number predicts.

Yeah. Yeah.

what thoughts you have about this in general? For sure. Yeah.

I think automated scientific research is one of the most exciting skills that, you know, the frontier labs are developing right now. And I think it's important for everyone who's doing any kind of research to get a good intuition of, like, what it can do now and what it can't and how might the sort of science process work in the future once we're having AIs automating a lot of this this investigation. So in brief, I mostly use Opus four point six and four point seven throughout the working on this.

And what works is that the models can do a very good job of doing hyperparameter optimization. So in the past, people would kind of come up with a search base of hyperparameters like learning rate and weight decay and maybe how many layers are in your network. And, they would just kind of do a grid search or a sort of Bayesian hyperparameter optimization, approach, and then it would find some tuned parameters.

The kind of really cool thing that automated, you know, coding can do now is that it can search a much more open ended set of problems. Right? It can say like, well, I've identified that, like, the gradients are kind of small in this layer, so let me change it up here.

Let me rewrite the code so the data later data loader has a new augmentation I came up with. Let's let's sort of try to find the the best way to kinda fit the constraints of the optimization problem. And and you end up with this much more flexible and kind of high level, almost like grad student like ability to just, you know, grind a performance metric.

And and so this can squeeze out quite a lot of performance. You can know, on a fixed dataset with a fixed time budget, perplexity by quite a lot on on a sort of classification problem like LMs or or Go. And it is also fantastic now at basically executing any experiment.

Right? So I have a a Claude skill that I wrote called experiment where I give it a description of what I wanted to plot. And like I just described, here's the x axis I want.

Here's the y axis. Answer this question for me. And it'll go run off and do all the experiments, compile the plot, make a report, and suggest, like, you know, what might have caused it or or so forth.

So so that's what works quite well today, and I think we can expect that these abilities get better in the future. But it's also kind of useful to know, you know, what what is it not doing so well today? So on my blog version of this tutorial, I have a a plot of basically all the kind of experiments I did grouped in a sort of tree where, you know, every node kind of represents a failed, successful, or sort of mixed experimental result.

And then from there, it branches off into a child where it's like the follow on experiment. Occasionally, I'll kind of rabbit hole down a track like this off policy MCTS relabeling, do a few experiments, and then realize it's probably not worth it. So then I'll kind of jump to a completely different track.

Right? And I call these kind of things like rows. Right?

So so what what I find is that current, you know, closed models that we can access the public can access today, they don't seem to be that great at selecting what the next experiment should be in a given track, And they don't seem to be able to kind of step back and do the lateral thinking of, wait a minute. This track doesn't really make sense. Like, let's go back to sort of first principles and and think about, you know, what the bottleneck might be or, like, what are we trying to achieve?

Right? And and so often, had to catch infra bugs myself by prompting the right question to Claude to investigate what is causing this discrepancy, and then it'll answer the question. I think with Methos class models or Methos plus plus models coming online, maybe this just completely changes, these these problems just fall to to just improve scaling.

But at the same time, I think there's a lot of, like, rich opportunity to develop our own environments that might incentivize this kind of lateral thinking. And and so one of the motivations for setting up this Go environment was that I think that Go captures a lot of very interesting research problems, often overlapping with LMs or robotics. And yet it's, like, very quick to verify.

The outer loop is ultimately like, does the agent do what I think it does? And you can kind of check the outcome of a Go game quite easily. And then the inner loop involves all this kind of research engineering around distributed systems, predicting whether an idea is going to work or not, predicting the difference a particular modification to your training algorithm might make.

That's one of them. I think there's a lot of deeper questions that one could tackle. Right?

So for example, let's say you have an idea on how to improve a scaling law compute multiplier. Yeah. The outcome isn't necessarily like, I I achieved the best go bot ever.

The outcome might just be like, can I predict what the win rate of my go bot will be? Yeah. Yeah.

Or can I predict the scaling law plots that emerge from my idea? But then you can verify that you haven't kind of reward hacked anything by using a very verifiable game like Go on the outer loop. I think there's a couple of interesting follow on questions.

Yeah. I think as in the case of the success story for deep learning, you can think about this as like a decades long idea that took like took a lot of faith to get it to work. And so this presents a very challenging long horizon, you know, RL problem where, every step of the way you have a committee telling you that this is a bad idea, and then ultimately you break it through.

Right? And so how do you design RL environments that maybe give you some feedback earlier? And and I think this is a very tough open question that I don't have an answer to.

But but, you know, ultimately, to play a very strong go bot, you probably did need to discover deep learning. Yeah. Right?

And so I think that having a challenging game that cannot be cheated easily on the outer loop could be used as a sort of outer loop signal for something like discovering the principles of deep learning. Now, of course, to make it tractable, and this is where research tastes really matters, you have to come up with ways to initialize your problem so that you don't solve a very intractable problem. Maybe you can leverage LLMs as a universal grammar in the middle to kind of give give you some sort of local feedback.

The the the fact that LLMs are universal grammar means that they can kind of move at almost any level of the stack. Right? They can think very locally as well as step back and think, like, in very broad steps.

I think that's where a lot of the lateral thinking ability of humans kind of come from. How to know if the track that you're pursuing or the objective that you're pursuing is not right and you should be asking a different question.

AI AI innovation is? Yeah. Great question.

I think the research taste for executing well on, you know, the bitter lesson is that you need to know how much the bitter lesson can buy you and how much is too much to ask for at any given moment. Right? Like, of course, in the fullness of time, compute kind of is the single most important determinant on how things work.

And and and it's almost like inevitable that as you scale up energy and compute and parameters, intelligence will just fall out of that. And that's super super beautiful, super profound. No algorithmic detail really matters beyond that.

But in present day, we don't have infinite compute and parameters and an arbitrarily good initialization. So we have to come up with, like, heuristics that kind of give us that. But these heuristics are probably somewhat redundant.

So that's probably why you see this effect where, like, a lot of these compute multipliers necessarily stack is that, like, they they might have some correlated benefit. And then and then, you know, three years down the line when the NVIDIA GPUs have gotten even stronger, maybe maybe they stack even less well. Right?

Like, maybe, like, at any given point in time, the the the sort of benefit of any given compute multiplier is transitory, which is what I sort of suspected with the Katago paper. Like, there was many algorithmic ideas kind of applied. And then you can see that, like, with, you know, modern Blackwell GPUs and Ada class GPUs that are much better than the sort of v 100 grade GPUs that that paper used.

You can see that like some of these algorithmic tricks to speed up convergence just don't matter so much compared to something else. And I think that's a matter of taste in a in in the present time. Yeah.

Interesting.

gonna give a non rigorous argument, but one that I kind of intuitively believe, which is that, you know, DeepMind, the AI research lab, they started as a sort of focus on games. Right? Like, they kind of use games as their outer loop.

And then the researchers learned from experience of solving games. And then, like, now they're working on LMs. And presumably, was some positive transfer from their time working on games and, like, Atari and Go and and Starcraft that, like, now helps them make good LMs.

Like, I assume that there's, like, positive transfer in some regard, whether it's coding or general research ability or project management. Right? Like, all these things kind of, like, probably help them do well.

And so if that's the case, why wouldn't it also be true for automated AI researchers?

So, it's actually not obvious to me that there's like The jury's still out, right? Like, I I think like who knows if the you know, let's let's say currently Google's doing quite well. Who knows if the initialization on training on games is ultimately gonna hobble their ability to be the winner in the long term.

Right? Like like, it's it's hard to say for sure. Yeah.

And, you know, likewise, who knows if the late seeming late start was really just them kind of pre training for longer on how how how to, like, scale up TPUs. Or they they invested all their tech tree in, like, getting TPUs to be good, which seemed not that useful in the short term, but then in the long term, it becomes maybe like so it's it's even hard for humans to reason about what the optimal research strategy should be. Right?

Even with the data we have today. Yeah. Yeah.

Cool.

Where do people go next? Great. Yeah.

So my my website is evjang.com. The there's a blog post that kind of links to a interactive version of this tutorial.

thinking as a primitive in Computer science. Exactly. Right.

And so I highly recommend people check out that blog post as well. Yeah. And I encourage the audience to you know, think about the relationship between thinking and Go, you know, via MCTS and search and how it relates to LMs.

I think there's something quite, like, profound there and probably underexplored just because Go has been relatively underexplored compared to, you know, the boom in LMs. Yeah. It's not to say that I think we should have trees in our in our LMs, but but but there is some very interesting duality between them.

And you can actually do a lot of research on Go, MCTS, and and reasoning with, you know, very small budgets. So that's very exciting. Cool.

Awesome, Eric. Thanks for doing this. It's an honor to be on the podcast.