Eric Jang – Building AlphaGo from scratch

Eric Jang https://evjang.com/ walks through how to build AlphaGo from scratch, but with modern AI tools. Sometimes you understand the future better by stepping backward. AlphaGo is still the cleanest worked example of the primitives of intelligence: search, learning from experience, and self-play. You have to go back to 2017 to get insight into how the more general AIs of the future might learn. Once he explained how AlphaGo works, it gave us the context to have a discussion about how RL works in LLMs and how it could work better – naive policy gradient RL has to figure out which of the 100k+ tokens in your trajectory actually got you the right answer, while AlphaGo’s MCTS suggests a strictly better action every single move, giving you a training target that sidesteps the credit assignment problem. The way humans learn is surely closer to the second. Eric also kickstarted an Autoresearch loop on his project. And it was very interesting to discuss which parts of AI research LLMs can already automate pretty well (implementing and running experiments, optimizing hyperparameters) and which they still struggle with (choosing the right question to investigate next, escaping research dead ends). Informative to all the recent discussion about when we should expect an intelligence explosion, and what it would look like from the inside. Watch on YouTube https://youtu.be/X_ZVSPcZhtw. Read the transcript https://www.dwarkesh.com/p/eric-jang. And check out the flashcards https://flashcards.dwarkesh.com/eric-jang/ I wrote to retain the insights. Sponsors * Cursor https://cursor.com/dwarkesh‘s agent SDK let me build a pipeline to generate flashcards for this episode. For each card, I had an agent read the transcript, ingest blackboard screenshots, generate an SVG visual, and run everything through a critic. A durable agent is much better at this kind of work than a chain of LLM calls, and Cursor’s SDK made it easy. Check out the cards at flashcards.dwarkesh.com https://flashcards.dwarkesh.com and get started with the SDK at cursor.com/dwarkesh https://cursor.com/dwarkesh * Jane Street https://janestreet.com/dwarkesh gave me a real deep-dive tour of one of their datacenters. I got to ask a bunch of questions to Ron Minsky, who co-leads Jane Street’s tech group, and Dan Pontecorvo, who runs Jane Street’s physical engineering team. They were willing to literally pull up the floorboards and take out racks to explain how everything works. Check out the full tour at janestreet.com/dwarkesh https://janestreet.com/dwarkesh Timestamps (00:00:00) – Basics of Go (00:08:17) – Monte Carlo Tree Search (00:32:04) – What the neural network does (01:00:33) – Self-play (01:25:38) – Alternative RL approaches (01:45:47) – Why doesn't MCTS work for LLMs (02:01:09) – Off-policy training (02:12:02) – RL is even more information inefficient than you thought (02:22:16) – Automated AI researchers This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.dwarkesh.com https://www.dwarkesh.com?utm_medium=podcast&utm_campaign=CTA_1

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Dwarkesh Patel?

  Today I'm here with Eric Zheng, who was most recently Vice President of AI at One X Technologies, before that Senior Research Scientist at what is now Google DeepMind Robotics. And you've been on Sabbatical for the last few months. One of the things you've been doing is rebuilding and improving and hacking on AlphaGo. And so today what we're going to do is you're going to explain building AlphaGo from scratch and what it tells us about the future of AI research and development. But before we get to that, why is AlphaGo interesting? Why is this the project you decided to do on Sabbatical rather than just hanging out at the beach?

• 0:33Speaker 01

  Sure, yeah. I like making things. And AlphaGo and Go AI is one of those things that really got me into the field. When I saw the kind of early breakthroughs on AlphaGo in 2014, 2015, 2016 and so forth, it was just profound to see how smart AI systems could become and the computational complexity class that they could tackle with deep learning. This is a problem that has long been understood to be 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 phenomenon a little bit better. My training is often in deep neural nets for robotics,

• 1:14Speaker 01

  where the decisions made by the neural networks are a bit more intuitive. But AlphaGo is a sort of problem where 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 the game tree.

• 1:34Dwarkesh Patel?

  Yeah, interesting.

• 1:35Speaker 01

  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 an open source project called Katago by David Wu from Jane Street, who basically achieved a 40x reduction in compute needed to train a really strong GoBot, Tableraza. I'm not certain if it's stronger than AlphaGo 0 or Alpha 0 Mu 0, but it's very, very strong. And this is what most Go practitioners today train against when they're playing in AI. And thanks to L M coding, what took a whole team of research scientists at DeepMind and millions of dollars of research and compute can now be done for a few thousand dollars of rented compute.

• 2:14Dwarkesh Patel?

  By the way, if you're listening to this on an audio platform, this is a blackboard lecture, so I highly recommend switching over to a video platform like YouTube, if you can, to look at the math and the graphs and the Go board.

• 2:26Speaker 01

  OK, I guess we should first discuss how Go works. Great. So yeah, how does the game work? So the game of Go is a very simple one that can be implemented quickly and easily in a computer. 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, so go ahead. And so the way you capture and opponent's stones is that for every intersection, if you can surround all four of its neighbors with your stones, then this one is sort of cut off from oxygen, if you will, and then it is a dead stone. So then now I control these four stones as well as this empty intersection here.

• 3:09Speaker 01

  So there's like slight variations between Chinese, Japanese, and what is called Trump-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 the 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 play a few stones, and then I'll explain some more. So I'll just start there.

• 3:44Speaker 01

  All right, I'm like basically playing randomly here, but I'm trying to get around your stones and see if I can close with them.

• 3:57Speaker 01

  So this move basically exposes one empty neighbor for your white stone, and it's very akin to a check in chess, where if you don't respond immediately by putting in one here, then I can immediately capture this. I see, OK. Because it is sort of the diagonals that determine whether you want it in. The cross-section, not the diagonals. 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.

• 4:23Speaker 01

  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 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 do that. You have a 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 an opponent capture some stones if, for example, it allows you to position to capture more stones in somewhere else on the board. And this is what makes Go a very beautiful game is that you can kind of lose the battle but win the war. Interesting.

• 5:08Speaker 01

  And as the board size increases, the complexity of these kind of like micro versus macro dynamics gets more interesting. Presumably, you'd put one here. Mm-hmm.

• 5:18Speaker 01

  And so now I would capture this entire group. Okay. And this would be mine. Okay, there's one more case that I want to 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.

• 5:38Speaker 01

  And so

• 5:40Speaker 01

  let's talk a little bit about how the game ends, right?

• 5:44Speaker 01

  In this territory, who controls 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 these ones also count as being in? Yeah, great question. 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 evaluate this. So most humans would look at this board configuration and conclude that like black has kind of totally surrounded white, and so white has no chance of life.

• 6:28Speaker 01

  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 white to something outside of it, 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 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.

• 6:52Speaker 01

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

• 7:03Dwarkesh Patel?

  Yeah.

• 7:04Speaker 01

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

• 7:13Dwarkesh Patel?

  Yeah, interesting.

• 7:13Speaker 01

  So in Trump-Taylor scoring, it's perfectly unambiguous, so it can be decided, you know, algorithmically by a computer. So if, let's say you have this at the 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, right? If this were like this, then white would get three points. Now, this is a little odd, because a human would know that white is actually losing these points.

• 7:53Dwarkesh Patel?

  Yeah.

• 7:54Speaker 01

  But Trump-Taylor scoring would consider white to have all of these points, as well as these points.

• 7:58Dwarkesh Patel?

  Got it, okay.

• 7:59Speaker 01

  So that is a very big difference in how computer Go scores things and how humans score things.

• 8:06Dwarkesh Patel?

  How does the game end?

• 8:07Speaker 01

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

• 8:13Dwarkesh Patel?

  Cool.

• 8:13Speaker 01

  Yep, so that's the rules.

• 8:14Dwarkesh Patel?

  Nice. All right, now help me correct this with AI.

• 8:17Speaker 01

  Great, okay.

• 8:18Dwarkesh Patel?

  Let's understand how AlphaGo actually works and how somebody in the audience might be able to implement it.

• 8:25Speaker 01

  Great, yeah. Let's start with kind of an intuition about the underlying, you know, 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 gonna draw a person here, and we're gonna draw an AI here. And let's say this person is playing black, so they go first. So we're gonna draw.

• 8:56Speaker 01

  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 could use ones and zeros, but you want to represent, you know, black, white, and empty. So you would need at least three different values here, right? So maybe you could use zero, ones, and twos or something. So the AI might see something like, you know, zero, zero, zero, zero.

• 9:25Speaker 01

  One.

• 9:34Speaker 01

  Great. So this is the input to the AI on its turn. Yeah. So the AI can choose, let's just pick three possible random moves that I can go. And I just drew these at random. And so 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 of course, as it fills up, you have less moves. And the number of steps in the game can be somewhere from 250 to 300 moves.

• 10:17Speaker 01

  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, like depth of the tree. Yeah. So if you keep on expanding possible moves here. So in this move, the AI is going. And then, you know, here the human would go. And then, you know, there's some.

• 10:47Speaker 01

  And so forth. You can find that 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. Like, it's just, uh, it's just... And of course, actually, there are redundancies and symmetries, so it's not actually 300, 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.

• 11:21Dwarkesh Patel?

  What do you mean by merging of children?

• 11:22Speaker 01

  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.

• 11:37Dwarkesh Patel?

  Yeah.

• 11:38Speaker 01

  And then you play here, right?

• 11:39Dwarkesh Patel?

  Yeah.

• 11:39Speaker 01

  So both of them arrived at the same spot, but through different paths. So this child node can be thought about as a shared ancestor.

• 11:46Dwarkesh Patel?

  And I guess it's not 361, it starts at 361, but it decreases by one each time.

• 11:50Speaker 01

  And the branching factor decreases by one each time.

• 11:51Dwarkesh Patel?

  Yeah.

• 11:52Speaker 01

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

• 11:55Dwarkesh Patel?

  Yeah.

• 11:55Speaker 01

  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.

• 12:08Dwarkesh Patel?

  No.

• 12:09Speaker 01

  If you could, Go is actually a 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.

• 12:27Speaker 01

  So AlphaGo's kind of core conceptual breakthrough was using neural nets to make this search problem tractable. So before we get into, you know, how neural networks are involved, let's talk a little bit about how we can, you know, assuming we had a very powerful enough computer, search this tree to find the best move, right? So in the beginning, you're not going to 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 UCB1,

• 13:10Speaker 01

  which is not exactly appropriate for a sequential game like Go, but very much inspired the action selection algorithm used in AlphaGo. So UCB1 looks like on every move, we're going to take the best action, or the argmax over A that maximizes

• 13:32Speaker 01

  the Q of A, and I'll explain what Q of A is in a moment, plus some sort of exploration bonus.

• 13:46Speaker 01

  So on every node, we're going to track a few quantities. So let's consider each of these a node. This is the root node,

• 13:55Speaker 01

  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

• 14:11Speaker 01

  of this node, this child node. Is how often the parent visited this node? Yes, and we'll call this an action. So one thing that is easy to trip on is like if you come from robotics or other kinds of reinforcement learning is like, where are the actions, right? I'm only talking about nodes. 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. So if I go here, that implies an action. And this is the state that we resolve in. So the LLMs, if you ask to vibe code an MCTS implementation, it'll most likely design the right data structure here. But it's sort of a chef's choice. You can actually rewrite the tree structure however you like.

• 14:56Speaker 01

  This was what Claude 4.6 wrote for me when I asked it, and it was a very reasonable choice. So then Q represents the mean.

• 15:08Speaker 01

  Action value of this action.

• 15:14Speaker 01

  And I'll use a subscript a to denote that this kind of corresponds to taking a specific action to get here, right, from the root node. So like, if we have root, basically, taking a gets us to this node here. And then we're going to also store the probability of taking this action.

• 15:35Dwarkesh Patel?

  Again, from the parent.

• 15:36Speaker 01

  From the parent, yes. Like, what are the odds that we sampled this one? And this will become relevant later, you know, like, we've talked about a deterministic tree for now, so I'll bring probabilities into this later. And then finally, we have a sort of dictionary of children,

• 15:51Speaker 01

  which is just like, you know, more of these nodes, you know, 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 PUCT, and it's short for Predicted Upper Confidence with Trees. And this is basically, when you select which child to take, you do argmax a of

• 16:23Speaker 01

  q of s a plus a constant.

• 16:42Speaker 01

  So the equation and forms are actually pretty similar.

• 16:46Speaker 01

  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 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 explanation. Or versus exploit trade off. So in both UCB and Pucked, there is this term here that basically rewards taking actions that you haven't taken before.

• 17:28Speaker 01

  So as we mentioned before, each node stores the visit count of taking that specific action. So everything is initialized to zero. And so for a given action, let's just say like call it like action A. Initially, it's zero. And and so as N is increasing, if let's say we've already made 10 10 action selections from that root node. But we haven't picked A yet, then this term actually starts to become quite large for A.

• 17:55Dwarkesh Patel?

  Yeah.

• 17:55Speaker 01

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

• 18:01Dwarkesh Patel?

  Yeah.

• 18:01Speaker 01

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

• 18:05Dwarkesh Patel?

  Just make sure I'm understanding it. Maybe I can

• 18:10Dwarkesh Patel?

  put it in my own words. Let's just focus on UCB. What we're saying here. You can think of it conceptually as two different things. The queue and then this exploration term. Let's just be clear about what queue is. Queue is basically saying, hey, once we do these rollouts. So you're actually running all these simulations, you go down the tree. And then you figure out, OK, if I end up at the terminal value of this tree, do I win this game or not? And then you do this, you average whether I win this game or not across all the, you know, the leaves of this tree. Starting from this node, that average you put in queue.

• 18:45Speaker 01

  Correct.

• 18:45Dwarkesh Patel?

  And so you're saying the queue is basically representing, will I win this game or not? What is probability they'll win this game starting at this node? That's your sort of, that is your sort of exploit. That is like saying, I've run these simulations, I think this is a good move or not. And then this other term is saying, have I explored this branch enough yet relative to the other actions I could be exploring? Or I have already explored. If I haven't explored this branch yet, you know, maybe I think it has a low score, but I just haven't explored that many leaves of this down this. Leaves down this node in this tree. So I should maybe like try this even though the Q, this sort of exploit is telling me that this is not that valuable. And because L N of N grows slower than N.

• 19:28Dwarkesh Patel?

  Basically, as over time, you will move from the argmax being dominated by this exploration term, which is the second term here, to the argmax being dominated by the Q term, which is like, OK, I've done enough simulations. I'm quite confident that like this is the branch to go down.

• 19:45Speaker 01

  Yes, that's right. So the motivation for UCB was to come up with an algorithm where if you don't know the payoff of the arms, the different actions you can select to begin with, this strategy, basically with given some exploration term here, bounds your regret in terms of how wrong you can possibly be. I don't know the proof. I don't also know if this one is proved to have logarithmically 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 in every given move compared to your standard bounded problem. So one small clarification to make is that you talked a little bit about simulations on probabilities and forth.

• 20:30Speaker 01

  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 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 take the expected Q value averaged over a randomly selected tree. And that randomly selected tree is where probabilities come in.

• 21:10Speaker 01

  So the interpretation of Q is what is the expected action value under the, under the random distribution induced by some random search process?

• 21:21Dwarkesh Patel?

  Makes sense.

• 21:22Speaker 01

  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, you know, 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, this is a valid integral you can take, but it's very slow because you're going to consider a lot of trees that have very low value. And it's essentially almost like an important sampling problem where you want to, there's only a few actions and sort of paths that can contribute, you know, high value. And almost everything else is low value. So that's a sort of a tricky problem here. Okay.

• 22:06Speaker 01

  So this is the action selection criteria for how you decide which moves to move down. Now, as you move down in tree search, you will eventually run into a node where it's quite clear you've won or lost, right? At the very, very end of the game, when there are no valid moves to play left under Trump-Taylor scoring, you can decide whether you like, you know, won or lost, right? So you either win or you lost. And so this is basically, you know, the final return of the whole game, right? And so the question here is like, we can assign a value u to a terminal leaf node of the tree,

• 22:50Speaker 01

  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 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 QB, and this is action B, is just the average of, a weighted average of these ones here. Yeah. And the weighted average is...

• 23:34Speaker 01

  It could be dependent on if you have a different sampling distribution or not, but 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 nodes or actions corresponding to the averaged over the final terminal leaf. Okay, so if you were to do this without neural networks, it would still be intractable. You would have trouble finding which actions to sample. A lot of the actions would 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.

• 24:17Speaker 01

  But 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 downstream, assuming they're all correct and assuming you've searched deep enough.

• 24:34Dwarkesh Patel?

  Your explanation earlier about the sorts of states where it's obvious to a human who's going to win, but it's not obvious to, or like deterministically you still had to play it out, actually drove from the intuition of why the value function both is trainable and to why it's necessary in order to actually be able to learn this game effectively. And maybe it's we're defining value in the first place.

• 24:58Speaker 01

  Sounds good. Yeah. So we talked about, you know, this U-value being, you know, your final resolution of whether you won or lost. And this is the terminal leaf node condition. Now, humans don't play all the way to the sort of edges of the leaves of the tree, right? They kind of stop, you know, some dozens of moves before, maybe even 100 moves before, 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...

• 25:35Speaker 01

  He win. And so the human glances at the board and they know like, I'm probably gonna lose, right? 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 taking that average and then deciding whether the board is winnable or not. And then whether they should concede or keep playing or not. And this is remarkable. If you think about like the beauty of something like this, it's like a neural network 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.

• 26:18Speaker 01

  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.

• 26:41Dwarkesh Patel?

  Yep, makes sense. I will say for the audience, I sort of found

• 26:48Dwarkesh Patel?

  for previous episodes when I was prepping and it seemed somewhat relevant to understand how AlphaGo works. I would find it very, very confusing. And but it's the kind of thing where once you understand the problem in this way and then you'll build the next few pieces. It is actually much more understandable and it will make a lot of sense. And it's okay to be confused right now. But it's probably simpler to understand by the end of this lecture than you anticipate. So I'll just make that note for the audience.

• 27:12Speaker 01

  Yeah, the important intuition at a high level, just to, you know, step back about where we're going with all this is that

• 27:19Speaker 01

  classically, for games like Go, you could build a tree, but we don't have computers powerful enough for that.

• 27:24Dwarkesh Patel?

  Yeah.

• 27:24Speaker 01

  And

• 27:27Speaker 01

  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. 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 tractable. That's essentially the kind of core idea behind it. Okay, so we take this idea that, like, you know, humans can glance at a board and instantly predict whether we win, and maybe that gives us the opportunity to really truncate how deep we search. And then, you know, we also know that humans can look at a board and

• 28:12Speaker 01

  and decide, you know,

• 28:15Speaker 01

  what boards, you know, like intuitively, at a glance, what moves might be good on a good 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.

• 29:01Speaker 01

  And then now we, we go back to the AI, which now looks at a new encoded board.

• 29:19Speaker 01

  So I've used two to denote the AI's 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 is searched last round, and now there's a new root node, and it begins to search anew.

• 29:39Speaker 01

  And then so on and so forth. So MCTS is basically, you can think about it like a search algorithm that is deciding what moves to play best, aided by neural networks.

• 29:51Speaker 01

  And it's done on every move. Okay, great. So let's talk about the neural network part of this.

• 29:58Dwarkesh Patel?

  And while you're erasing, another sort of thing that was important for me to understand was this MCTS data structure with nodes and childrens of nodes and whatever.

• 30:08Dwarkesh Patel?

  This is done per move and re-instantiated once a move is made. So a human makes a move, then the AI looks at this and is trying to basically run a bunch of simulations to figure out, okay, what move should I make next? And those simulations, a simulation is basically like exploring one more node in this MCTS tree. And at the end, once all these, you know, you run 1,000 simulations, that informs then this, I guess as you will explain, this probability of what move to make next. That's what you store. You choose the best move, given those probabilities. You discard all of that, then the next player makes a move, and you restart this process at the beginning of every move.

• 30:52Speaker 01

  Correct. One small addendum, you don't discard all of that. You keep one thing behind that we'll use later.

• 30:58Dwarkesh Patel?

  Yeah. Just like I did for Reiner, I wanted to make flashcards for this episode so that people could retain these concepts. And ideally, an LLM could generate some candidates for me to then refine. But to actually get high-quality suggestions, I needed to design a whole pipeline where the AI could take and ingest screenshots of the blackboard at the right timestamps, and then make SVG diagrams in case visuals were helpful, and then run their writing and drawing through a critic, and then revise the card in response to this feedback. It's very hard to accomplish this just by sacking LLM calls. This sort of step-by-step recipe works much better if you have a durable agent that's been engaging with the task across all the previous stages. So I use the Cursor SDK to spin up an agent for each card. The Cursor hardware saved me a bunch of work in designing

• 31:41Dwarkesh Patel?

  some custom context scaffold, or figuring out how to design tool calls for taking screenshots or making animations. These agents all run in the cloud, so I don't have to worry about leaving my laptop open. I just get an email when I have candidates to review. You can check out my cards at flashcards.thwarkesh.com. You can start building with the Agents SDK at cursor.com/thwarkesh.

• 32:05Speaker 01

  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.

• 32:29Speaker 01

  Then we're gonna have a policy network, which induces a distribution over good actions to take. So I'm going to draw a one-dimensional flattened move distribution, but this is really like, you know, a square kind of grid, right? 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 specific architecture does not actually matter too much. I tried a few different architectures. Transformers work, ResNets work.

• 33:13Speaker 01

  For small data regimes, my experience is that ResNets still kind of outperform Transformers and it kind of gave you more bang for the buck at lower budgets, but this may not be true.

• 33:22Dwarkesh Patel?

  Why is that?

• 33:23Speaker 01

  They provide the inductive bias of like local convolutions. And generally, Transformers start to outperform residual convolutional networks when you want more global context.

• 33:33Dwarkesh Patel?

  I see.

• 33:34Speaker 01

  So one interesting finding from the Cottigo 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.

• 33:52Dwarkesh Patel?

  What does it mean to aggregate global features?

• 33:54Speaker 01

  Yeah, so if you have a very large 19 by 19 Go board and you know, you've got some sort of battles going on here and you've got some battles going on here. When you pass this through a convolutional neural network, the receptive fields of the convolutional network are going to be good at computing local things and making that invariant.

• 34:17Speaker 01

  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 connections. But you do need more data there so that you can kind of learn through data the sort of invariant local, local features.

• 34:47Dwarkesh Patel?

  Got it.

• 34:48Speaker 01

  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 Resonance for now.

• 35:01Dwarkesh Patel?

  So one, sorry, one more tangential question. It makes sense why transformers with their like global pooling of information would be better if you need to consider information that is not just spatially. Or yeah, CNNs give you a sort of bias that the things that are next to you are especially irrelevant.

• 35:21Speaker 01

  And then they're sort of aggregated up.

• 35:22Dwarkesh Patel?

  Yeah, exactly.

• 35:23Speaker 01

  Yes.

• 35:23Dwarkesh Patel?

  But okay, so for games where it isn't that relevant, what is happening locally, you just kind of have to consider the whole thing. You're saying transformers would work better. How about games where, so we're talking about the spatial dimension. How about the temporal dimension where right now we're only considering the previous move because it is a deterministic, full information game where. But what if it was something like poker or diplomacy where really a bluff they made a while back is sort of relevant to understanding now and isolating to decide to make your next move. And so you need to consider all those previous states. Would that then change the consideration of what inductive bias is most relevant and which architecture is most relevant?

• 36:01Speaker 01

  Right, great question. So Go is a perfect information game. And in perfect information games, 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 that 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,

• 36:47Speaker 01

  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 this is a very exciting research area that 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, 2v2 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, these are situations where it's no longer a perfect information game. Yeah. And then in those cases, in games of imperfect information or partial observability, then you do need some context to build a model. Yeah. And I think that's a place where things get very, very exciting in terms of like self-play or, you know, diplomacy style. Yeah, interesting.

• 37:32Speaker 01

  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 your architecture pretty good. And 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 sort of target optimization. Yeah. Okay, so we're going to pick just a somewhat arbitrary architecture that worked 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, like, you know, similar to an RGB, we're going to have three kind of channels.

• 38:15Speaker 01

  One channel to encode black, one channel to encode white, and then and then one channel maybe to encode like empties or.

• 38:26Speaker 01

  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.

• 38:45Speaker 01

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

• 38:55Speaker 01

  So this is like R1. And then we have the policy, which is, you know, R361.

• 39:04Speaker 01

  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 going to 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 data set 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 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 tabular lesson.

• 39:47Speaker 01

  You generally want to kind of initialize, just as in deep learning, initialization is everything, right? You always want to initialize your research project to something as close to success as possible. Especially if you're, you know, doing something new that you haven't done before. Like 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, you know, try to make it work. So under that philosophy, it's a great idea to start from something that like, you know, has a good initialization. So we're going to take human expert plays and train this model to predict, you know, good actions. Right? So we're going to take all of the winning games, all the moves in which a human won. And, oh, sorry, an expert won and then predict those actions. And then regardless of board state, like, you know, whether you won or lost,

• 40:32Speaker 01

  you're going to 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 the winner of this game is? Right? Well, if you have, you know, hundreds of thousands of games, then 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 from 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 so for these, for these things, it's sort of expected that once you train the model, a starting board state will look like 0.5. And then as you progress towards the end of the game, it'll actually look something like, you know, if this is 0.5,

• 41:16Speaker 01

  the win probability will sort of either go like this or it'll go like this. And this is sort of your move number.

• 41:25Dwarkesh Patel?

  Yep.

• 41:27Speaker 01

  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 likely to lose under your expert data distribution.

• 41:36Dwarkesh Patel?

  I didn't understand the significance of why this way of thinking about values is especially relevant to the expert data.

• 41:42Speaker 01

  It is not relevant to the expert data. It's true for any data that you train it on. Yeah, so if you were to learn a tabular Raza, you would also expect this to follow. Yep. So if you just do this, like, so imagine, you know, you're vibe coding AlphaGo and you gather some expert data sets from like KadoGo online, or you, you know, you have a data set 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, so like, if you just take this policy recommendation and take the argmax over, you know, it's a...

• 42:19Speaker 01

  If this is the, you know, probabilities, if you take the argmax 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 million parameters, can already do something that impressive.

• 42:43Dwarkesh Patel?

  Yeah.

• 42:46Speaker 01

  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 a checkpoint that like you want to 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.

• 43:30Speaker 01

  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.

• 43:51Speaker 01

  And this number varies. This can be, you know, somewhere between 200 to 2048. I believe in the AlphaGo Lee match, they used tens of thousands of simulations per move because they really wanted to boost the strength of the model as much as possible. Yeah. But in training, you don't actually need too many. And Katago, I think, uses something on this order as well. Do you know if they used, if you watch the documentary, they had a laptop out during the game? Yeah. They didn't use a laptop itself. It was like on some... It was on some TPU pod, I think. Yeah. But now... Honestly, kind of unfair. Well... Lee is not using like 1E22 flops to do a move, you know? Fair enough. Interestingly enough, modern Go bots don't need that much compute at test time. Yeah, interesting.

• 44:33Speaker 01

  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 pushes it into the network. And you can do all of that work with one, you know, neural network for one pass. But the TPU pod will always add the extra move on top. And so that's what they wanted for the match. So we're going to 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 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 going to update the action values for the tree.

• 45:18Speaker 01

  So that's what every simulation involves these kind of like four step process. So the four step process is basically selection, expansion, evaluation, and backup.

• 45:37Speaker 01

  So at the beginning of our Monte Carlo tree search, our tree is very basic. It only has 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.

• 46:09Speaker 01

  And I'm going to say root. So for all of the actions here, we can create a bunch of children, right?

• 46:18Speaker 01

  So this one has, well, in this case, I'm drawing a three by three board with one board missing. So basically, there are, you know, eight possible children associated with this root node.

• 46:44Speaker 01

  And each of these has an associated probability of taking that action, right? So there's P eight, P one, P two, et cetera.

• 46:54Speaker 01

  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 policy network evaluated 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 first move is to select by maximizing or argmaxing the puck criteria, which is basically, you know, Q, Q, S, A, plus, you know, C puck times P of A

• 47:40Speaker 01

  divided by N over one plus N A.

• 47:48Speaker 01

  So for each of these, we're going to, you know, N A is zero for all the actions initially. N is zero. And, and so we're going to basically just, you know, pick according to this.

• 48:04Speaker 01

  Initially,

• 48:07Speaker 01

  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 everybody. So let's suppose P1 was the highest probability node. So you selected this one here. Now you 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 the final resolution. So the next step that you do is expansion. So you, 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

• 48:51Speaker 01

  or any opponent might do, right? So this is like, you know, your, your opponent.

• 48:59Speaker 01

  The tree expansion process actually is completely... So when we evaluate the node here, we're going to now evaluate the node from the perspective of this player.

• 49:11Speaker 01

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

• 49:30Speaker 01

  from here, like the human could play here, the human could play here, or a human could play here. And we're going to store essentially the V theta for each of these things. So V theta of node 1, or like node 1 prime, V theta node 1.

• 49:57Speaker 01

  And so we're basically using our neural network to make an intuitive guess of how good is this board from the perspective of this player. And fortunately, because it's a zero-sum game, it's easy to deduce that the value for this player at this step is just 1 minus the value from this perspective. So it's easy to flip the search process depending on which player you're at.

• 50:23Speaker 01

  And so this is the expansion step. You've taken 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 going to win or not? So you can almost think about the V theta as a shortcut for searching to the end of the tree for any given simulation.

• 50:44Speaker 01

  And then this is essentially the evaluation step. We're evaluating the quality of each of these boards. In original AlphaGo Lee, 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 play out. So they actually played a real game from here all the way to the end. So like, I'm just going to draw this squiggly line to indicate some path. And they kind of like play this all the way to Trump-Taylor resolution

• 51:17Speaker 01

  of a full board. And so this is like a 0 or 1, right?

• 51:25Speaker 01

  And so they took this value and they just averaged it with this one here. So the formula they did was like, you know, alpha times v theta of like, you know, some node plus sort of like 1 minus alpha of a true randomly sampled play out.

• 51:47Speaker 01

  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 this play out, 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 and they just play it all the way to the end. And this is something that helps ground the estimates here in reality, because you can get a single sample estimate of like whether you win or not. You can think about in the end game where the board is almost resolved, that this one actually becomes quite useful, because 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 reality. It turns out, this is totally unnecessary.

• 52:32Speaker 01

  So in all subsequent papers after AlphaGo Lee, they just got rid of this.

• 52:36Dwarkesh Patel?

  Yeah.

• 52:36Speaker 01

  And so in my implementation, I 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.

• 52:42Dwarkesh Patel?

  Yeah, yeah. Okay, so again, just to reinforce my own understanding and just to re-explain it. For the items, by the way, in case it's not obvious, the p there in this select, that is the probability coming from the network, in this case.

• 52:56Speaker 01

  Correct, the policy network here.

• 52:58Dwarkesh Patel?

  Yeah. Okay, so fundamentally, a simulation, just think of it as like rolling out one more node in the search process.

• 53:09Speaker 01

  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 then you keep going.

• 53:23Dwarkesh Patel?

  Yeah.

• 53:25Speaker 01

  In AlphaGo, the data structure is such that we begin with a tree that has no, like, basically only depth 1, which is its only children. And you want to iteratively build out the tree 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 value, the Q value assigned to the node here for taking this action is now just the average across your evaluated values here.

• 54:07Speaker 01

  You take a running mean over all of the simulations that you've taken, and they average the values of the children nodes. 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 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 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 going to win or not. And then you walk all the way back up to the root node to update your values on what the best moves are. So as you do this iteratively,

• 54:52Speaker 01

  this selection criteria will cause you to visit the... But because you're always selecting according to this criteria, you're always going to be selecting the best action you think at any given branch, right? 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. So as a sort of test of understanding, it's worth thinking a little bit about whether we could make this even simpler. Like, could we actually maybe even get rid of this one and still make the thing work?

• 55:35Speaker 01

  So recall that when you do an expansion and then an evaluation at, let's say, this node, you are checking the sort of win probability of each of the child nodes, right? And so if this one is like 1 and these are 0, you do kind of know something about which action might be better to take. And so why would you still need this? Like, why not just normalize this one into some distribution and call that 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 how the breadth is pruned out.

• 56:19Speaker 01

  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, let's say, the policy said this was very high probability, but this one said it was a low value, then there's actually something 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.

• 56:44Dwarkesh Patel?

  Right. But just to make sure I understand, the reason you don't do that is so that you don't have to do 360 independent forward passes to like, okay, here's the value of everything. Let's argmax over it, right? Instead, you can just do one forward pass and get like the probabilities of all of them.

• 56:59Speaker 01

  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, 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 feed back on itself and sort of recursively improve its own predictions and search capabilities. And that's where this one, having this as an explicit entity you're modeling rather than an implicit normalization over your value is a good idea.

• 57:38Dwarkesh Patel?

  Makes sense, okay.

• 57:39Speaker 01

  Okay. So we talked about the simulations. And basically, what you end up with as you roll out the number of simulations is a tree that kind of looks like...

• 57:51Speaker 01

  I'm drawing a very low dimensional version of this. Of course, in the real game, it's much more high dimensional. But you'll end up with basically a tree structure that has

• 58:03Speaker 01

  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.

• 58:21Speaker 01

  So this is kind of like 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 nine actions and then eight and then seven and six. And so it's a sort of like nine factorial sized tree.

• 58:39Speaker 01

  The Monte Carlo Tree Search in Go is very, very sparse. 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.

• 59:06Dwarkesh Patel?

  20 years ago, Jane Street's data center fit in the corner of an office. Ron Minsky, who co-leads the tech group there, told me about how it all got started.

• 59:14Speaker 02

  One of our compute clusters, we called the Hive. And I remember the first version of the Hive was literally like six Dell boxes stacked on top of each other at the end of the row. And the trading systems themselves, we also had there because we actually wanted the ability to make sure we could turn the damn thing off. I mean, there were ups and downs, like literally at some point, you know, one of the people who was cleaning the office unplugged one of the trading systems in the middle of the day as they were vacuuming. So, you know, in the end, it is in fact better to have it all in a data center.

• 59:42Dwarkesh Patel?

  Jane Street's data centers have come a long way since those six Dells. And I got to tour one of them in Texas with Ron and Dan Fontacorvo, who leads Jane Street's Physical Engineering team.

• 59:50Speaker 03

  You know, these cabinets, these GP300 cabinets, consume at peak about 140 KWE. Compare that to traditional air cool, you're talking about 10 to 40 KW. It's a lot more.

• 59:59Dwarkesh Patel?

  We got deep in the details of running one of these data centers, things that I had never considered before.

• 1:00:04Speaker 03

  It's filled with a liquid, a mix of distilled or deionized water and propylene glycol, 25% of propylene glycol. That's to inhibit any bacteria or algae growth. I don't love the world where we have to worry about bacteria growing in our servers.

• 1:00:18Dwarkesh Patel?

  I got to see way more of what actually happens in the data center than I've ever seen before. Jane Street was willing to literally pull up the floorboards and take out the racks and take me to the back where all the chillers are. You can check all of this out at janestreet.com/twarkesh, where we posted the full tour.

• 1:00:34Speaker 01

  Okay, so 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 the AI, so you make a move.

• 1:00:51Speaker 01

  AI 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 this node. And then after MCTS, it gets more confident about one of these actions, right? And so maybe the distribution looks a bit more peaky like this based on 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 this is your new, let's call this like pi.

• 1:01:37Speaker 01

  Let's wrap this in like an MCTS operator

• 1:01:42Speaker 01

  of, you know, A given S, right? So after applying MCTS process, your, your policy recommended distribution looks like this. It's a bit more peaky 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 make your move. And then, and then you throw away the tree and then you begin anew on the next move, right? So

• 1:02:08Speaker 01

  again, like you, you know, you compute a new distribution.

• 1:02:20Speaker 01

  So initially, maybe your guess looks like this, and then you refine it through MCTS.

• 1:02:28Dwarkesh Patel?

  There should be one more X on the board, right?

• 1:02:30Speaker 01

  I'm sorry. That's correct, yes.

• 1:02:34Speaker 01

  To something that looks like...

• 1:02:38Speaker 01

  Right? 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 then so on and so forth. And then the game ends. And one person wins and one person loses. So the beauty 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 legwork to arrive here, why don't you just predict that from the get-go? Right? Like, why don't you not use this guess and just predict this to begin with? And if you have this guess to begin with in your policy network,

• 1:03:22Speaker 01

  then MCTS has to do a lot less work to get things to work. And so if we draw like a sort of test time scaling plot, so let's say this is like number of simulations.

• 1:03:34Speaker 01

  Let's say, you know, at zero simulations, your implicit win rate is like, I don't know, here. And then, without any simulation, if you just take this raw action, this is what your winning rate is. And let's say as we increase the number of sims, maybe you kind of have a win rate that looks like this. Right? So when you search for, let's say, 1,000 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,

• 1:04:16Speaker 01

  then you could actually, you know, start here. Like, if, let's say, this was, you know, zero 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 amortize 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 the number of sims that you put in.

• 1:04:46Dwarkesh Patel?

  The Sagemore-type nature of test time scaling as the number of simulations increases, the increase in win rate is smaller, is that true even for the distilled network? That is to say, is there some gain of like, okay, we start from the distilled, we get these early gains again, or is that just inherent to the nature of MCTS?

• 1:05:02Speaker 01

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

• 1:05:15Dwarkesh Patel?

  Okay, cool.

• 1:05:15Speaker 01

  So don't pay too much attention to the shape of the curve, just know that it's monotonic with respect to sim.

• 1:05:22Speaker 01

  Okay, so the idea of MCTS is very brilliant, which is like, we got something better by applying search. And we're going to now, on our next iteration of updating this network, just train this to approximate the outcome of 1,000 steps of search. And so instead of starting here, we get to now have a neural network start here, and then the play gets stronger once we then apply another 1,000 steps on top of it. And you can keep going, right? 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 going to train the model to imitate the search process.

• 1:06:05Speaker 01

  So there's an analogy to robotics, actually, which is the dagger algorithm. First, I'm going to draw like a schematic of like, let's say, you know, the states, right? So S0, S1, S2, S3. So let's say, you know, we took a series of actions in an MDP to get a trajectory. And these actions may be suboptimal, right? Maybe we lost at the end of this game.

• 1:06:36Speaker 01

  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, A0 prime. A better action here would have been to take A1 prime, and yet another one like A2 prime, A3 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 going to 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

• 1:07:20Speaker 01

  so that you retrain your policy network to predict these ones instead of these ones, you're going to do better.

• 1:07:27Speaker 01

  And this is very related to dagger in robotics and imitation learning, where you want to collect an intervention here. And even if you're in a 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.

• 1:07:42Dwarkesh Patel?

  Yeah, okay. So put it in a question. But is there a guarantee that MCTS must be better than the policy? For example, you could imagine early on in training, because MCTS is informed by the value network. Early on in training, when the value network hasn't been well-trained on finished games, that like MCTS is worse than sort of randomly choice policy. So is it just like a heuristic that MCTS is better than the policy? Or is that like, is there some guarantee?

• 1:08:10Speaker 01

  Right. In practice, it is a heuristic. And it does work also in practice. But let me illustrate an 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 collapses because 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 like, you know, pi of AS is like, great.

• 1:08:42Speaker 01

  But somehow, because maybe we're playing on a lot of games where 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 playouts. Like, in the case that we showed with the corner play, maybe like 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 puck selection criteria and your backups to be off. And then you end up visiting a very, very different distribution

• 1:09:27Speaker 01

  than what your policy initially recommended. Also, if your number of sims is low, then you might also have a variance issue where you just don't explore enough. Like, it's only guaranteed to converge when you kind of take n to infinity. So variance in your search process, as well as inaccuracies in your evaluation, can definitely screw with the quality of your policy network recommendation. And so that's why it's not a guarantee to improve. And that is why I suspect why AlphaGo Lee had the playouts to the end in their training algorithm, so they could ground this thing in real playouts. In practice, what you could also do is just like, for 10% of the games, you prevent the bots from resigning and you just say like, "Resolve it to the end." So you get some training data in your replay buffer

• 1:10:11Speaker 01

  to really resolve those kind of like late-stage playouts that normal human players would not play to.

• 1:10:18Dwarkesh Patel?

  Yeah, yeah.

• 1:10:19Speaker 01

  So this is why MCTS, if you assume that the value functions are correct, why it gives you a better policy is because, 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.

• 1:10:35Dwarkesh Patel?

  Right. Okay, so if you have a cold-started policy, if you have an AlphaZero-type thing, really what's happening for the first few epochs is the policy is kind of useless and what you're really just doing is, "Hey, but let's play full games." And once we have played full games, for the preceding moves, we'll have labeled...

• 1:10:56Dwarkesh Patel?

  Who won, who didn't win? And the loss for AlphaZero has two components, which is like, how good is the policy relative to MCTS? And how good is the value prediction relative to who actually won the game from this move? And this is, this sort of like, you can think of this being applied to every single action or every single move.

• 1:11:13Speaker 01

  Correct.

• 1:11:14Dwarkesh Patel?

  And really, what's happening in the beginning of AlphaZero training is just like, we're trying to get the value function to actually predict who will win the game. If you're, if you find yourself in this state and you're this player, and functionally, that's all that's happening. And later on, once that's well-trained, now the policy is also improving.

• 1:11:31Speaker 01

  Correct.

• 1:11:31Dwarkesh Patel?

  Okay.

• 1:11:32Speaker 01

  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, is like, I found it useful in my own implementation to do the following. You want to first make sure that this is good before you invest a lot of cycles doing MCTS, right? Like, it doesn't really make a lot of sense to do search on garbage value predictions. So you want to kind of start at a good place where this works. AlphaGo Lee does a very good thing where it just takes human games and then you like, train 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 if you have some like offline dataset that has realistic, good play,

• 1:12:14Speaker 01

  you can easily learn the late-stage value functions pretty well. And that's what you kind of need to start the search process.

• 1:12:21Dwarkesh Patel?

  Sorry, can you just read this sentence another time?

• 1:12:22Speaker 01

  Sure. So it's quite easy to evaluate a late-stage Go game. Like, when almost all the pieces are on the board, like, it's almost like a decidable problem, right? Because it's the lower and lower uncertainty as to like the depth of the tree. So, most games played to the end by reasonable people will be good training data to train a good value function at terminal parts of the tree.

• 1:12:43Dwarkesh Patel?

  Got it, okay.

• 1:12:44Speaker 01

  Then, as you play more games, the search will back up good values into the sort of intermediate nodes of the tree. And then like, as you increase the amount of data, your value head gets a good intuition of like, what is a healthy board state versus a not healthy board state?

• 1:12:59Dwarkesh Patel?

  Yeah.

• 1:13:00Speaker 01

  That, those are much more subtle to judge in the mid-game than the beginning or the end. So 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 the hard part that you want to learn in the value function is like, who is winning in the middle?

• 1:13:15Dwarkesh Patel?

  And so this is actually very analogous to TD learning.

• 1:13:18Speaker 01

  Yes, and there's a beautiful connection to TD learning that we can talk about in a bit, as opposed to contrasting with Monte Carlo tree search. So you first want to get good value functions, and expert data can give you a quick shortcut. I recommend for practitioners, just do that first, just to initialize to a good starting point. And then if you want to do the AlphaZero thing, or Krago, kind of tabular Raza 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 50,000 games, you'll actually learn a pretty good value function as well. Because on a 9x9 board, you can see enough of the common patterns with random play. And then if you train a model that can train on both 9x9 and 19x9 data,

• 1:14:02Speaker 01

  and Krago was a proposed one of these architectures, then there's some pretty good transfer learning from the value head evaluated at 9x9 to the 19x9.

• 1:14:12Dwarkesh Patel?

  Right, because this, unlike other games, has very much a sense of like, there's not like a new kind of piece that is introduced when you increase the size or something.

• 1:14:20Speaker 01

  If we take it to its limit and consider like a very tiny 4x4 Go board, if you play 50,000 games, you're going to have a lot of end states that look like human play, right? It's just like tic-tac-toe at that point. So if you broaden this a little bit to like 5x5 or 9x9, it's not unrealistic to imagine that purely random play will actually generate pretty reasonable-looking boards, and so you can score those pretty easily. And so that is what gives you the bootstrapping to be able to then improve your policy with search. But it's very, very critical that MCTS has accurate value estimates. And you need to ground the value. Ultimately, MCTS will fall apart if you don't have a grounding function for the value.

• 1:14:59Dwarkesh Patel?

  I'd be curious how much compute you save by training the value and policy on the same network, because they share the same representations, how much more efficient learning is? Because that would be interesting if they're basically kind of... We've just talked about how they're kind of making similar predictions, or they shouldn't be in line with each other. And so I'd be curious if like, actually, you're like halving the amount of compute you had to do by keeping them on the same network.

• 1:15:21Speaker 01

  Right. AlphaGo Lee, the original AlphaGo paper, had two separate networks. And then in all subsequent papers, 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, if you really want to chase that question down to its limit, it takes quite a bit of work to really resolve that. But intuitively, yes, they share a lot of representations. So, and you know, as we mentioned, there 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.

• 1:15:57Dwarkesh Patel?

  Yeah, probably this is the wrong way to think about it. I feel like when I learn how an LLM works and how simple RLVR is, at least as an algorithm, how simple it is, I'm sort of stunned by the kinds of things it can do, that it can learn how to build very complicated code repositories and whatever, simply for them getting like a yes, no. And here, I feel like the, if you understand it more deeply of like just predicting MCTS and it actually seems, AlphaGo seems less impressive in retrospect, the more you understand it, because you're like, oh, you're putting in a lot of bias by just saying how much you do. You're like telling it how we should titrate exploration as things go on. You're building this very explicit tree search for it.

• 1:16:42Dwarkesh Patel?

  And so, I don't know if you share that intuition, or it actually, the more you understand it, the less impressive the accomplishment in 2017 seems.

• 1:16:50Speaker 01

  I, I personally disagree. I, I think they're profound for different reasons. And I don't understand the L M R L 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. 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.

• 1:17:32Speaker 01

  But by construction, let's say a 10-layer neural network can only do 10 sequential steps of thinking, 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. 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.

• 1:18:13Speaker 01

  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 so it actually makes me wonder if, you know, our understanding of problems like P equals NP or, you know, these very fundamental like computational hardness problems are incomplete, right? Like, it's not like, you know, obviously, this is not a proof of like P equals NP or anything. But there's something to it that like kind of is very disturbing. Where like what felt like a very hard problem can fall to a very, very simple macroscopic simulation.

• 1:18:52Dwarkesh Patel?

  That is a very interesting insight that a lot of problems which are proven to be NP-hard, like, I don't know if Go is proven to be NP-hard, but, okay, protein folding, et cetera, have been, like, neural networks can solve them because they're NP-hard in the worst case, but we're not dealing with the worst. We're usually not concerned with the worst case. We're, you know, like, these problems have a lot of structure to them, usually.

• 1:19:13Speaker 01

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

• 1:19:28Dwarkesh Patel?

  Yeah.

• 1:19:28Speaker 01

  But in practice, like, it is extremely useful. 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. And yet, we're able to make like almost arbitrary amounts of progress. So here's a sort of like, you know, in the limit, what might this look like, right? Well, if you want to simulate, you know, something very complex like weather or predict the future, like, you know, 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, you know, our ability to amortize a lot of that computation into the forward pass of a single network.

• 1:20:09Dwarkesh Patel?

  Interesting.

• 1:20:09Speaker 01

  So to me, 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.

• 1:20:19Dwarkesh Patel?

  I feel totally not at all qualified on the computational complexity of the math to comment on this. But I wonder if there's an important role of chaos here where.

• 1:20:31Dwarkesh Patel?

  What is the problem with weather? And why does it take 10x amount of resources to predict weather a day out? And continually so for every more day out? It's because it's a chaotic system, and so small perturbations can totally change the final estimate as time goes on. And I guess it's interesting. Well, I guess you'd expect that for Go and protein folding as well.

• 1:20:54Speaker 01

  So here's an analogy to weather that might be relevant in Go. So the problem of like, you know, here's our current board state.

• 1:21:01Dwarkesh Patel?

  Yeah.

• 1:21:07Speaker 01

  Given what we know about both players, what is the board state in the future?

• 1:21:11Dwarkesh Patel?

  Yeah.

• 1:21:11Speaker 01

  What is the exact board state in the future?

• 1:21:13Dwarkesh Patel?

  Yeah.

• 1:21:14Speaker 01

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

• 1:21:21Dwarkesh Patel?

  Yeah.

• 1:21:21Speaker 01

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

• 1:21:33Dwarkesh Patel?

  Yeah.

• 1:21:33Speaker 01

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

• 1:21:48Dwarkesh Patel?

  Yeah, that's an interesting way to think about it.

• 1:21:49Speaker 01

  And so in weather, 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, things like that. 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 don't... If you start anywhere on the Lorenz attractor, you don't know where you're gonna end up. But you do know that the thing looks like this.

• 1:22:16Dwarkesh Patel?

  Yeah, yeah.

• 1:22:16Speaker 01

  Right? 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.

• 1:22:24Dwarkesh Patel?

  That's interesting.

• 1:22:24Speaker 01

  And these things can be predictable.

• 1:22:26Dwarkesh Patel?

  And contrast that, say, to something like a hash function, which is also incredibly dependent on initial conditions, but doesn't have a macrostructure. Or at least, hopefully, if like the algorithms work.

• 1:22:36Speaker 01

  Yes, one would hope.

• 1:22:38Dwarkesh Patel?

  And so there's like no equivalent of a value function, or like broadly, how's the weather gonna be? That is interesting there. It's really just about what is the move... What is a board gonna look like 100 moves from now exactly?

• 1:22:50Speaker 01

  Yes, intuitively, that seems correct. And then again, this is also out of my area of expertise, but... I find it interesting that cryptography has not been able to like the tools of cryptography and hashing have also not been able to prove that you cannot come up with fast approximation like you cannot come up with fast approximations, right? If they were able to do that, then you could prove P is not equal to NP.

• 1:23:17Dwarkesh Patel?

  Yeah, in fact, we know that there's structure in many cryptographic protocols, obviously, like RSA cryptography. There is structure, and that structure is what quantum computers exploit to break them, right?

• 1:23:27Speaker 01

  I see.

• 1:23:29Dwarkesh Patel?

  Reiner has a very interesting blog post, which we've talked about in the episode, where he talks about how if you look at a high level, what cryptographic protocols look like and what neural networks look like, it's extremely similar, where you have sequential layers of jumbling information together. And it's because there's this convergent devolution in the algorithms, where in cryptography, you want the final state to be incredibly sensitive to initial conditions, so that it can come out sort of looking jumbled based on if you change anything. And then neural networks, 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.

• 1:24:08Speaker 01

  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 Shuldick on this.

• 1:24:16Dwarkesh Patel?

  Yeah.

• 1:24:17Speaker 01

  Yeah, like there's something kind of quite fundamental about chaos that is it's not just like hopeless noise, it's like there's something kind of useful, right? In chaotic systems, at least at that boundary. But yeah, this is just my thing about this is philosophy. I don't actually know the math well enough to comment on it. Anyway, if we go back to, we'll talk about L M R L a little bit, because there's some connections there, but 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

• 1:24:48Speaker 01

  Increase the probability of winning directly. It's not going to say like, we're gonna up weight all actions that won and down weight all actions that didn't win. Yeah. 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. And we're just going to make every action that we took better by predict, like having the policy network predict that outcome instead. And so this is a very, very nice idea because you have one supervision target for every single action. Yeah. So the variance of your learning signal is very low compared to the alternative naive RL thing. So let's actually consider what, let's consider a very naive algorithm

• 1:25:29Speaker 01

  that looks a lot more like, you know, modern LLM RL today, 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 use a lot of LLM-style RL these days, like, is that relevant? Could we do that instead? So 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 games where a single player wins, we're going to reinforce those actions up and then, and then,

• 1:26:09Speaker 01

  and retrain the policy network to imitate 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, you know, Policy A and Policy B are like evenly matched, right? So their true, their true win rate is like 50%. So let's say you play 100 games. And then each game, let's say lasts, you know, 300 moves.

• 1:26:58Speaker 01

  And you're doing some sort of like evolution strategy or some way to perturb these things to 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. And so, so let's say, you know, 51 games, Policy A wins.

• 1:27:21Speaker 01

  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 like 49 of the games, they played exactly equally. I'm sorry, for 50 of the games, they played exactly equally, right? And on that one game where this one won, it played slightly differently. It made like one critical move that like, you know, 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.

• 1:28:06Speaker 01

  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, 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, of actions, of supervision actions where you want, actually, sorry, let me, let me clarify a little bit.

• 1:28:31Dwarkesh Patel?

  Okay, so we're just talking about how the good move, data distribution move is a small fraction of all the moves that are played across all the games, on which you'd want to train. And this, of course, reminds me of how LLMs are trained with policy gradient methods. Karpathy, when he was on the podcast, called it like sucking supervision through a straw. And, 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?

• 1:29:03Speaker 01

  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 let's look at the gradient variance of a very naive approach like this, where I'm just going to call it like gradient RL. And it's basically the sum of rewards.

• 1:29:50Dwarkesh Patel?

  I see what you're saying.

• 1:30:04Speaker 01

  So the sum of rewards is the return, right? So like in our naive setup here, we only have an indicator variable for the return, where either you won or lost. 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 things, right? So you can think about this setup as a special case of this general formula here.

• 1:30:31Speaker 01

  The trouble here is that this is very high variance because when you multiply these terms out, when you try to compute the variance of this, and so variance of the gradient

• 1:30:46Speaker 01

  is equal to expectation of squared minus...

• 1:30:54Speaker 01

  And just for simplicity, we can pretend this is like, you know, on average zero or something if you're centering at, you know, no signal.

• 1:31:02Speaker 01

  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 t. So variance, when you have a setup like this, this thing acts as a coupling effect on top 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?

• 1:31:38Speaker 01

  In LLMs, you have a decoder that might predict some words like "hello, world."

• 1:31:45Speaker 01

  And so in current L M R L, 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, the, because of how 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 in this case, I would,

• 1:32:21Speaker 01

  I would say something like, you know, log L plus log low plus log world. So this is true.

• 1:32:37Speaker 01

  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.

• 1:32:54Dwarkesh Patel?

  Right.

• 1:32:54Speaker 01

  And so the problem becomes, how do you ascribe the credit associated with every episode to all these different terms here?

• 1:33:02Dwarkesh Patel?

  I guess the thing I'm confused on is what would that even look like to do it that way in?

• 1:33:07Speaker 01

  In L L M's?

• 1:33:08Dwarkesh Patel?

  In L L M's, because you do, you only do get a reward at the end of the episode, so.

• 1:33:13Speaker 01

  You could imagine a reward that says like, I'm going to give you some process supervision,

• 1:33:18Dwarkesh Patel?

  Yeah.

• 1:33:19Speaker 01

  where you get a reward for each of these actions on every step.

• 1:33:23Dwarkesh Patel?

  Okay, so you're saying, if, instead of doing it that way where you,

• 1:33:28Dwarkesh Patel?

  well, I guess the way you've written it, it would be a sum at the end anyways, so it wouldn't have to be multiplied. But you're saying, instead of doing it that way, you would just add up this process rewards at the end and then treat that as one single reward signal?

• 1:33:39Speaker 01

  Correct, for one single log action.

• 1:33:41Dwarkesh Patel?

  But isn't that how it's written to begin with anyways? Like the sum of the rewards?

• 1:33:47Speaker 01

  So 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 multi-step problem, that you're now introducing kind of correlations between your actions through the computation of this guy.

• 1:34:00Speaker 01

  And so if you separate these things out, then there will be this will magnify the variance of this one. So in the case where you don't separate it out, if you just have t equals 1, you just have a single estimate of log prob and a single estimate of reward. Now, there are, this term still shows up in so in LLMs, it looks a little bit more like, the naive reinforced estimator looks a bit like return of the single action plus times, you know.

• 1:34:38Speaker 01

  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 sort of penalizing the labels that don't help and only rewarding the ones that actually make you better.

• 1:34:59Dwarkesh Patel?

  Right.

• 1:34:59Speaker 01

  So intuitively, the analogy here is like, can we find a term in our training objectives such that it's actually kind of discouraged from doing this, or you know, these don't have any effect on the gradient? And this has an effect on the gradient.

• 1:35:12Dwarkesh Patel?

  Right. I guess if you apply that there, the only thing you could do is eliminate 49 of the games. So at least the way you have it written there, it would be 51 times.

• 1:35:26Speaker 01

  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.

• 1:35:34Dwarkesh Patel?

  Yeah, but how would you do that?

• 1:35:36Speaker 01

  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

• 1:35:47Speaker 01

  you know, a term from

• 1:35:51Speaker 01

  From your multiplier, instead of an indicator function of like 1 and 0, you want something that kind of behaves like a 0 for all of these guys,

• 1:36:02Dwarkesh Patel?

  and then a 1 for all of these ones. Yeah, but you could do that if they're... If you can say, "Hey, I won this game, so this is slightly above baseline performance."

• 1:36:12Speaker 01

  Well, you won on a lot of games.

• 1:36:14Dwarkesh Patel?

  Exactly.

• 1:36:15Speaker 01

  But you don't know which ones let you win because they were truly better versus winning on accident.

• 1:36:19Dwarkesh Patel?

  How would you design a baseline where it's truly better?

• 1:36:22Speaker 01

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

• 1:36:35Dwarkesh Patel?

  I see.

• 1:36:35Speaker 01

  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 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 Scholman's General Advantage Estimation paper as like a good treatment on how to think about various ways to compute it. But at the end of the day, you want to reduce variance by trying to make this smaller and so that it doesn't magnify the variance of this one.

• 1:37:08Dwarkesh Patel?

  Right, makes sense. But this requires you to have a very good estimate of what average performance from a state would look like. And this gets us back to the value function thing we were talking about earlier.

• 1:37:19Speaker 01

  Right, and so this... Keep in mind that in this case, this model-free RL setting 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 Tree Search 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 OpenAI's Dota. So let me talk a little bit about how you can kind of unify some of these RL ideas in the model-free setting as well as the self-play setting. Okay, so...

• 1:38:03Speaker 01

  What happens if you don't have the ability to easily search a tree? 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 a little bit hard to do this. And I'm not even sure if it's a deterministic game. 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. So if, you know, given neural fictitious... So we're going to talk a little bit about how neural fictitious self-play works.

• 1:38:52Speaker 01

  Same idea, we're going to like come up with better labels for each of the actions we took, just like in MCTS. But how do we derive the better labels?

• 1:39:08Speaker 01

  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.

• 1:39:30Speaker 01

  So you fix your opponent. So let's say you're currently training PiA against a strong opponent PiB. In StarCraft, maybe like, you know, these are the zergs and you're playing Protoss or something.

• 1:39:46Speaker 01

  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 have a reward function that's like, you know, return is like, you know...

• 1:40:13Speaker 01

  One if wins against pi B. 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 that. And then, you 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 trained with, you know, pick your favorite model-free or algorithm, PPO or SAC or, you know, any kind of mixture of the, or, you know, VMPO 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,

• 1:40:58Speaker 01

  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 pi B. And then maybe you have a league of, you know, of opponents like pi B, pi C, pi D. And you're going to 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 MCS 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.

• 1:41:37Speaker 01

  And then you're finally, you're distilling the, 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 worse than like, you know, an 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's still fundamentally is about relabeling your, your, your states with better actions so that they improve your policy.

• 1:42:06Dwarkesh Patel?

  And just make sure I understand this is like, if you win against, win a game against this other policy, you sort of reinforce all the actions

• 1:42:13Speaker 01

  Yes.

• 1:42:14Dwarkesh Patel?

  on that trajectory.

• 1:42:15Speaker 01

  Yes. So here you can use a number of algorithms like PPO, VMPO, you know, Q learning, even if you want, like, 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.

• 1:42:41Speaker 01

  And through the resolution of your value function at the leaves of the tree, or your approximate leaves of the tree, you can kind of back up through the sequence of many sequences and then obtain some sort of mean value estimate. Your Q is kind of derived from the average of a bunch of simulations. In model-free algorithms,

• 1:43:04Speaker 01

  there is often a component of estimating a Q value. And so Q values are often learned through TD learning, although in PPO, the way that they do advantage estimation is not necessarily through a Bellman backup. But in Q learning, there's this kind of very cool trick where you do, you know, QSA is backed up as R plus some discount factor times the max AQ of your next step. So intuitively, how this works is like, if you have an MDP,

• 1:43:44Speaker 01

  and then this is like terminal.

• 1:43:50Speaker 01

  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 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. So you can say like, well, once I know the Q value of this action, I can then use that to kind of compute something about the Q value.

• 1:44:20Dwarkesh Patel?

  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.

• 1:44:27Speaker 01

  This is an 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.

• 1:44:51Dwarkesh Patel?

  Yep.

• 1:44:51Speaker 01

  So you don't need to explicitly model the policy distribution. You can actually recover the policy distribution by doing argmax over your Q values. So Q learning, or you know, this kind of like approximate dynamic programming kind of propagates what you know about the future Qs backward like this, right? And you can see that there's a sort of similar structure that goes on here where in this case, you're planning over trajectories your agent hasn't actually been to yet, whereas in this case, you're planning over trajectories your agent has visited. So importantly, why does Q learning, you know, why was Q learning a big deal, right? Like it's because historically, we just haven't had the ability to do search on fairly high dimensional problems like robotics or whatever.

• 1:45:35Speaker 01

  So for a long time, we kind of make the assumption that like, okay, well, if we can't model the dynamics with like a world model or something, we're going to instead just collect trajectories and then plan with respect to the only number that really matters, which is reward.

• 1:45:48Dwarkesh Patel?

  Okay, so this is very interesting. And then to unify this with our discussion of LLMs. So with LLMs, you're doing something, you don't have Q values, but you're doing this sort of backwards learning where, hey, let's find the trajectories which pass some unit test in some coding environment, and then let's reinforce those trajectories. And then there's a huge difference between that and this forward approach with MCTS. And the reason you can do MCTS, and it's much more preferable to do MCTS because you can do it per move and make each move better rather than having to learn per trajectory and hope, you know, as Karpathy said, hope to learn this like-

• 1:46:23Speaker 01

  Through a straw.

• 1:46:24Dwarkesh Patel?

  Yeah, so you get this supervision through a straw, basically just upgrade all the tokens in a trajectory that might or might not have been relevant to getting the answer right. The reason you can do this much more sort of sample efficient, much more favorable thing with Go is that because MCTS works in Go, you basically know that, hey, if I just do search locally here, and this search is sort of truncated at the end by this value function that works even if I haven't unfolded my whole trajectory, I can just say, this is my new policy, and I can improve in a more iterative, like local way rather than having to-

• 1:47:04Dwarkesh Patel?

  Having to unfold all these trajectories.

• 1:47:06Speaker 01

  So there was some research, I think from Google in 2023, 2024, where they did try to apply tree structures to reasoning.

• 1:47:15Dwarkesh Patel?

  Yeah.

• 1:47:15Speaker 01

  And I think it's, you know, the jury is still out as to whether this can ever work. So I would say like,

• 1:47:23Speaker 01

  we probably will see like, you know, revisiting of this idea of forward search 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.

• 1:47:42Dwarkesh Patel?

  Yeah.

• 1:47:42Speaker 01

  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, you know, 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, you know, sort of obvious thoughts that are correct, but not really solve your final problem.

• 1:48:11Dwarkesh Patel?

  Yeah.

• 1:48:11Speaker 01

  So 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.

• 1:48:21Dwarkesh Patel?

  Don't LLMs sort of natively learn to do MCTS? Where they'll try an approach and be like, oh, that doesn't work. Let's back up. Let's try this other thing. And then go in the direction that proves to be more fruitful.

• 1:48:34Speaker 01

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

• 1:48:41Dwarkesh Patel?

  Yeah.

• 1:48:42Speaker 01

  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 Alfgo.

• 1:48:54Dwarkesh Patel?

  But just to make sure, I understand the crux of it. Like the breadth from the number of legal actions being wider and the depth from being able to, not being able to train a value function as easily. Because.

• 1:49:09Speaker 01

  So here's an example where LLMs break down. The C-Pucked rule involves, you know, square root of n over 1 plus n a. In an LLM, like you're most likely never going to 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, even though they're discrete tokens. 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.

• 1:49:42Dwarkesh Patel?

  Right, but I guess the crux comes down to the fact that in Go, you know that the MCTS is almost certainly better than your current policy, even though you haven't gotten, even though you haven't explored the end of any trajectory.

• 1:49:55Speaker 01

  Correct.

• 1:49:55Dwarkesh Patel?

  And then in a, in normal reasoning for LLMs or robotics, there's no way to just locally evaluate and improve your next move in a way that doesn't result in, in a way that's independent of actually like solving the problem.

• 1:50:10Speaker 01

  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 Mu0 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 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 a 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?

• 1:50:53Speaker 01

  Like if you think about mathematics, I think mathematics often occupies a little bit more of like a logical search kind of procedure where you kind of can back up, you can kind of see like which paths seem 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.

• 1:51:15Dwarkesh Patel?

  Okay, so we're now seated, so I can ask you some more questions about AlphaGo and about AI research more generally.

• 1:51:22Dwarkesh Patel?

  In 2021, Andy Jones had a paper called "Scaling Scaling Loss for Board Games", and he basically anticipated inference compute, or inference scaling, by showing that you can trade off test time compute and training compute. That is to say that you can spend more compute on the searching through the MCTS, and if you do that, you can get the equivalent performance as having spent more time training the model. And so if you see this pattern, you might think, "Okay, well, with LLMs, you might do something like that in the future", and in fact, that's what had ended up happening. Okay, so what is a kind of fun exploration one could do now to explore other axes of scaling in toy settings, which will be important to understanding what AI development might be like in a few years?

• 1:52:06Speaker 01

  Sure, yeah. I think that indeed, test time scaling and reasoning 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. 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 recursive step? That's quite interesting. So the Andy Jones Scaling Loss for Board Games paper is quite cool. There's another really nice result from that paper where he showed that not only can you predict scaling loss of like the sort of LLM variety, where as you increase parameters,

• 1:52:49Speaker 01

  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 so with Go, which can scale from 3x3 to infinitely sized Go board, you might actually be able to 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 kind of build a strong Go bot without all the kata-go tricks? Just by really focusing on the bitter lesson and the scaling laws. I have not been successful so far, but I think it's sort of a fact that like,

• 1:53:33Speaker 01

  usually when you want scaling loss to work, you want to be in the regime where the recipe already works and the data sets are good, rather than trying to kind of figure out how to do scaling while also trying to figure out what the right data set are. So this is like the scientific understanding component in research often follows a step where you get something to work first. 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. And so usually, actually, if you want to build a strong Gobot using scaling laws, you actually have to make a strong Gobot first and then use the scaling laws to kind of extrapolate a bit farther into the future.

• 1:54:08Dwarkesh Patel?

  Say more, just so I understand. First of all, you're saying scaling laws did not work or you could not, there was no scaling loss pattern that you could see in your Gobot?

• 1:54:16Speaker 01

  Yeah, so a mistake I made initially, when I had some bugs around how MCTS labeling was working, was I would, I 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 data sets. You can indeed plot things that look kind of like this, but if you're in a regime where, you know, your policy's not working well, you might be just studying scaling laws on like bad data, right? So, so just like one important implementation detail is that if you want to study a scaling laws problem, you kind of have to have a problem for which like the data is good, the architecture is good, and there's no bugs, and then like you solve it there. X and T, I wasn't able to like apply scaling laws to direct what to look at, until, you

• 1:55:00Speaker 01

  know, I had the rest of the system working. And this sounds obvious, like to researchers, of course, you want to have like a working bug-free system before you study scaling. But 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.

• 1:55:20Dwarkesh Patel?

  Speaking of compute, so if you can look at these charts of compute used to train the best AI model in the world over time, going back 10 years, and it's a very smooth line in log space that is exponentially growing year over year, except there's this huge aberration, and that aberration is AlphaGo Zero, which is trained on way more compute than any other AI model at the time. It was like three E23 flops. It's sort of comparable to like a Frontier LLM. I mean, orders of magnitude off, but still.

• 1:55:56Dwarkesh Patel?

  And so, yeah, the question is, especially with you being able to get something off. And did you train it on your own?

• 1:56:01Speaker 01

  I got a donation from Prime Intellect.

• 1:56:03Dwarkesh Patel?

  Okay.

• 1:56:03Speaker 01

  For like about 10K and then I spent. I spent maybe the first 4K doing kind of exploratory research. And then about 3K on the kind of final run.

• 1:56:13Dwarkesh Patel?

  Yeah.

• 1:56:14Speaker 01

  And then some of it remaining for serving the model.

• 1:56:17Dwarkesh Patel?

  Cool. Yeah, is your sense that they were just to badge up training it if you can do it in 10K now?

• 1:56:23Speaker 01

  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 LLMs, right? Like, once someone else has done it, you could use tricks like distillation. You could use all sorts of like kind 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 Cottigo models to kind of get a strong level of performance. And, you know, as a time of recording, I'm validating whether this can be, I can kind of do that first step, which is to do the tabular Raza play. But importantly for research, you often want to start from a good init, right? So the kind of simple thing I did first was train best response agents against Cottigo.

• 1:57:03Dwarkesh Patel?

  Yeah.

• 1:57:04Speaker 01

  AlphaZero team, they did not have any policy that they could train against, right? Because they were trying to do everything tabular Raza. So, and being the first to do it means that you're prioritizing getting the thing working rather than like, 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, the scatter plot is all over the place and there isn't a very clean line, the way that there is for Frontier LLMs. And that is because the folks training these models often are not, you know, 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 deciding factor in pre-training, right? Instead, their focus is more like, we want a certain capability to show up, so we optimize

• 1:57:47Speaker 01

  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.

• 1:58:15Dwarkesh Patel?

  I see, like speed or something.

• 1:58:16Speaker 01

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

• 1:58:27Dwarkesh Patel?

  And how much of the improvements in compute efficiency are methods that did not exist as of 2017 versus things which they could have done in 2017?

• 1:58:35Speaker 01

  Yeah, great question. So going into this project, I kind of knew in the back of my mind that like things always get easier to do over time and I wanted to see like where is Go at, given that like it didn't seem like there has been any major open-source, you know, strong bot after Katago in 2020. And then, you know, reading the Katago paper, there's a lot of clever ideas. I was kind of wondering like, okay, let's see if the bitter lesson has happened, where like a lot of these kind of tricks just sort of go away because Nvidia made faster GPUs, right? 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,

• 1:59:18Speaker 01

  you know, transformer versus ResNet. We're at the sort of speed of GPU where the size of the model is not so big that this really matters.

• 1:59:27Speaker 01

  You can actually simplify the 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 like collect, you just train a supervised learning model and then you collect again. And so there's like opportunities to simplify infrastructure. Nvidia GPUs have indeed got faster. So whereas Katago was trained on V100s, you can train on like half the number of, you know, desktop Blackwell GPUs and it still works. And some of the auxiliary supervision objectives that CatoGo developed aren't really necessary if you have a strong initialization. So if you're initializing best response training against CatoGo itself, then your own model actually needs none of the tricks that CatoGo needs.

• 2:00:12Speaker 01

  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 9x9 boards was very nice for resolving endgame value functions. And then if you can co-train that on an architecture that can transfer between 9x9 and 19x19, then you can really cut down the warm start time to learn that from scratch. I think AlphaGo Zero, their plot was first 30 hours or so are spent basically catching up to the supervised learning baseline. And you can cut down that time a lot by pre-training on a small board and then warm-starting that into your 19x19 board play.

• 2:00:54Speaker 01

  There were some other stuff, like varying the number of sims between episodes. This turns out to be not that sensitive, actually. You can fix it or increase it, doesn't matter too much. But so anyways, it's just nice from a scientific perspective, just revisiting an old paper and seeing what really matters.

• 2:01:11Dwarkesh Patel?

  This is a sort of tangential question, but why is it okay to have a buffer in AlphaGo? Because every time I talk to any researcher here, they're telling me about how bad it is to be off-policy. But then the way an naive implementation of AlphaGo Zero would work is that most of the moves in a given backward step or in a batch of backward steps would be not among the ones that were made by the most recently trained model. So why is that okay?

• 2:01:38Speaker 01

  Great question, yeah. And this gets into the fundamental off-policy versus on-policy reinforcement learning 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. So the off-policy part here comes where, what if you're relabeling states that your new policy would never visit? Like, what's the point? You're 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. So this is where off-policy can really hurt AlphaGo.

• 2:02:24Speaker 01

  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 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 funnel you back into your optimal trajectory. So maybe I can just draw it quickly here. 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.

• 2:03:08Speaker 01

  So this is like, you know, you 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.

• 2:03:29Dwarkesh Patel?

  But why isn't this a fully general argument for off-policy training?

• 2:03:32Speaker 01

  This is actually why you want to do off-policy training sometimes. Is that like, 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.

• 2:03:42Dwarkesh Patel?

  Yeah.

• 2:03:43Speaker 01

  And so optimal control does not really say too much about like, you know, how to, you know, not accidentally get here, because it's sort of making the assumption that like, once you learn the policy, you're gonna get here. But in applications like robotics, right? Like, I don't know, a gust of wind blows you slightly off, and then now you need to like correct, right? Or the friction on one of your tires is kind of a little bit like lower than the other wheel, and then now your car is drifting, and you gotta like correct it. So these kind of things in like more real environments often happen where like, actually, there's a funny quote about chess and also Go. It's like, the problem with Go and chess is that the other player is always trying to do some shit. So like, you know, things can kind of drift off.

• 2:04:25Dwarkesh Patel?

  Yeah.

• 2:04:26Speaker 01

  And you always want to be able to correct back to your winning condition. 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.

• 2:04:42Dwarkesh Patel?

  Yeah.

• 2:04:43Speaker 01

  Now, if you take this to the extreme, and you say like, well, let's, we don't have any of this data.

• 2:04:53Speaker 01

  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, 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. Like, like this is, this is not there. So then this is a problem, right? And this is where off-policy can really hurt. Yeah. So actually, as 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, you know, random states from the data set.

• 2:05:37Speaker 01

  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, and I might revisit old states that I've labeled before and relabel them again with my current network. Yeah. 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 in, in, 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, your data set of trajectories. And then you have something like a replay buffer pusher.

• 2:06:22Speaker 01

  And these are off-policy offline trajectories, right? So your replay buffer pusher pushes transition tuples

• 2:06:31Speaker 01

  to, to, to the replay buffer.

• 2:06:37Speaker 01

  And then you have some job that's kind of continuously

• 2:06:42Speaker 01

  replanning

• 2:06:45Speaker 01

  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, the sort of minimize TD error. So like your Bellman updater

• 2:06:57Speaker 01

  constantly is pulling things from here and trying to satisfy, you know, the QSA.

• 2:07:11Speaker 01

  So and then from here you have your trainer, which is trying to fit the S to A or fit the, you know, Q to the Q target. 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 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 like, you know, in the Google QT op days, we kind of did things like this.

• 2:07:47Dwarkesh Patel?

  So what is the trainer?

• 2:07:48Speaker 01

  Oh, yeah, the trainer is you try to minimize Q, S, A, and Q target.

• 2:07:57Dwarkesh Patel?

  Mr. Can you explain the whole setup again, like at the high level?

• 2:08:00Speaker 01

  Yep. So you have your off-policy data that came from various policies. You're constantly pushing transitions that you saw before to a replay buffer.

• 2:08:08Dwarkesh Patel?

  Yeah.

• 2:08:08Speaker 01

  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, you know, value? And the way you enforce that is you try to minimize the TD error. So actually, given this, you have S prime, right? 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 S and A, your Q target is this.

• 2:08:43Speaker 01

  So now you have a, now you send back the Q target to this transition. So with this tuple, you pair with that a Q target.

• 2:08:53Speaker 01

  And then here on the trainer, you simply just you supervise learning and you minimize your current network's QSA with its target.

• 2:09:00Dwarkesh Patel?

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

• 2:09:07Speaker 01

  Yeah. In a more optimal policy where you're trying to maximize this, what is the cue target of this transition?

• 2:09:13Dwarkesh Patel?

  It's sort of like basically daydreaming.

• 2:09:14Speaker 01

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

• 2:09:24Dwarkesh Patel?

  Yeah.

• 2:09:25Speaker 01

  Now, the connection to Go here that I tried and it was moderately successful, but too complex to kind of like open source, was you replace this with like a MCTS relabeler,

• 2:09:38Speaker 01

  where instead of doing this kind of target network computation, you run MCTS on your transition, right? So 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 care about these ones. You just take your state and you just plan MCTS to get your best policy, you know, pi

• 2:10:04Speaker 01

  on your current network, right? 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, the one other benefit is that you can like kind of fully saturate your GPU better, because you're not like blocking on the Go game to kind of like give you board states. You just simply search across all board states at any depth in parallel.

• 2:10:34Dwarkesh Patel?

  Yeah.

• 2:10:35Speaker 01

  So, and then here the trainer would be just, you know, predict the MCTS label as possible. 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.

• 2:10:57Dwarkesh Patel?

  Yeah.

• 2:10:57Speaker 01

  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 like 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.

• 2:11:14Dwarkesh Patel?

  I'm sorry, do I have the converse of that?

• 2:11:15Speaker 01

  It's just more stable. So like you might use the off-policy Q as a way to do like, you know, advantage computation.

• 2:11:24Speaker 01

  Like, you know, Q minus like sum of Q. That's kind of like your, or sorry, like, you know, sum of, like, if there's N actions and then, yeah. So like, so like, this is your value and then this is your kind of current Q values. Your advantage for that action is like the average value minus your current one. So like, people can try to estimate Q in an off-policy way and then like just use advantage here. And then, and then the sort of, if there's a problem in these dynamics, that it doesn't like blow up your loss as much. And so in robotics, there's a kind of convergence towards more like using off-policy data to just shape your rewards, but not actually be directly here.

• 2:12:03Dwarkesh Patel?

  I'm reminded now of our earlier conversation of why MCTS is so favorable as compared to the kind of, you know, reinforce a policy gradient kind of thing LLMs do. And this might be totally wrong, but I wrote a blog post a few months ago about how RL, at least policy gradient RL, is even more inefficient than you might think. And so the inefficiency one thinks about naively is the fact that you have to roll out a whole trajectory in order to get any learning signal at all. And so as these trajectories become longer and longer, as an agent has to, instead of just previously like complete the next word in the sentence, it has to go instead to, hey, so do two days worth of work to figure out even if you even did this project correctly.

• 2:12:45Dwarkesh Patel?

  The amount of information per flop has been decreasing. As you had to unroll two days worth of thinking in order to see if you even did something correctly to like, did I implement this feature, the amount of samples per flop has been decreasing. But so you can think of, you're trying to maximize as you're learning bits per flop, right?

• 2:13:09Dwarkesh Patel?

  And this is, you can think of bits per flop as

• 2:13:14Dwarkesh Patel?

  samples per flop

• 2:13:19Dwarkesh Patel?

  times

• 2:13:22Dwarkesh Patel?

  bits per sample.

• 2:13:26Dwarkesh Patel?

  And what I just mentioned a second ago is that the samples per flop go down as RL becomes more and more long horizon. But at least this kind of naive RL is also terrible from a bits per sample perspective. And here's what I mean, at least compared to supervised learning. So, early on in training, let's say you have a vocabulary size for an LLM that is 100K long. So there's 100K possible tokens that one could answer. And you have a totally untrained model and you have a prompt like "The sky is..."

• 2:14:03Dwarkesh Patel?

  With supervised learning, what would happen is that the model would have some probability distribution over all the things it could say. There's a label that says actually the term here is "blue", and it would learn basically through cross-entropy loss exactly how far its distribution is from correctly saying "blue". Now, if you were doing this through RL,

• 2:14:23Dwarkesh Patel?

  you would say, the model would try "The sky is..." Halicon. Nope, that's wrong. "The sky is..." "Told". Nope, that's wrong. This is a totally untrained model, right? And so you would have to do this on the order of 100,000 times in order to just stumble on "blue", then get some learning signal off of that. So if you're in the supervised learning regime and you have your distribution of probabilities, you get told that it's "blue" and you figure out how far off you are, the amount you learn is a function of your pass rate. So like, the further away you are from "blue", the more you've learned to go towards "blue", using cross-entropy loss. And so you can think of it as like your pass rate, your prior probability of having said "blue",

• 2:15:06Dwarkesh Patel?

  and as a function of that, like in supervised learning, through cross-entropy loss, you would learn negative log p, p being pass rate bits once you get this label. Whereas in RL,

• 2:15:23Dwarkesh Patel?

  if you're just randomly guessing shit and seeing if it works or not, that's just basically going to be the entropy of a binary random variable, which is...

• 2:15:37Speaker 01

  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.

• 2:15:49Dwarkesh Patel?

  Exactly, very, right. So that's being modeled by the fact that your probability of sampling blue is extremely low. If you do sample it, you do learn as much as you would have learned in a supervised learning. In all other cases, like, you know, 99.99% of in an untrained model, you're just learning incredibly little from like seeing halicon is not the correct word or told is not the correct word. And that's what happens most of the time. So you're just like, learn very little. So if you try to graph,

• 2:16:18Dwarkesh Patel?

  if you put on the x-axis your pass rate,

• 2:16:23Dwarkesh Patel?

  and here you put the like sort of the bits you bits you're learning from a sample. If you have like 0% here, 50% here, and 100% here. So the end of training, you're here.

• 2:16:40Dwarkesh Patel?

  If you have supervised learning, negative log pass rate would look something like this. And then the binary random variable would look like this. And this is depending on whether you're doing nots or bits. Oh yeah, if you do bits, it's like one right here at the peak. This is like a coin flip. You learn the most from a coin flip. This is supervised learning. This is RL. However, the problem is you spend most of training in this regime, right? Like in the in the low pass rate regime. And in fact, if how fast your learning

• 2:17:25Dwarkesh Patel?

  is a function of how many bits per sample you're getting. And you're getting very little signal here. If you chart the pass rate on a log scale. So you put the x-axis on a log scale where like at the beginning of training with a vocab size of 100K, the pass rate is 1 over 100,000, then 1 over 10,000, 1 over 1,000,

• 2:17:51Dwarkesh Patel?

  1 over 100. And then, okay. What this graph looks like here, where supervised learning would look like this. And

• 2:18:04Dwarkesh Patel?

  And then RL, if you just basically crunch what I just showed there, it would look like that.

• 2:18:11Speaker 01

  Yeah, and arguably, you spend all your time here. Potentially never even getting a single success, right?

• 2:18:17Dwarkesh Patel?

  Exactly.

• 2:18:18Speaker 01

  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.

• 2:18:24Dwarkesh Patel?

  Yeah.

• 2:18:25Speaker 01

  You know, once you're here, you have something, but like, you actually, in many RL problems, spend all the time here.

• 2:18:30Dwarkesh Patel?

  Yeah.

• 2:18:30Speaker 01

  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?

• 2:18:36Dwarkesh Patel?

  Yeah.

• 2:18:37Speaker 01

  One more thing I'd like to add about bits per sample that's very relevant to, you know, any kind of machine learning problem is that,

• 2:18:46Speaker 01

  and there's a connection to soft targets and distillation, where if you have access to the low jets, right? Not just the one hot, like this is a sort of one hot token answer.

• 2:18:54Dwarkesh Patel?

  Yeah.

• 2:18:55Speaker 01

  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, there's way more information in bits per sample in a soft label.

• 2:19:10Dwarkesh Patel?

  Yeah.

• 2:19:10Speaker 01

  So that's why distillation is so effective.

• 2:19:12Dwarkesh Patel?

  Yeah.

• 2:19:12Speaker 01

  Per sample, is that it's actually giving you way more information per sample.

• 2:19:16Dwarkesh Patel?

  Yeah, well, I wonder what the equation would be, but obviously it's...

• 2:19:19Speaker 01

  It would just be the entropy of this distribution. So the entropy of this is zero.

• 2:19:22Dwarkesh Patel?

  Yeah.

• 2:19:23Speaker 01

  The entropy of this is like, you know, the entropy equation. And this is also why like, you know, 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.

• 2:19:37Dwarkesh Patel?

  Interesting.

• 2:19:37Speaker 01

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

• 2:19:51Dwarkesh Patel?

  Interesting. Earlier, I was sort of stumbling around. This intuitively, why is this ability to do?

• 2:20:02Dwarkesh Patel?

  Iterative search where you don't necessarily need to be able to win the game in the beginning. You just need to be able to improve your current policy. Why is that so powerful capability in learning as compared to how LLMs currently run RL? And yeah, it's exactly this thing of, this is considering your pass rate of the entire trajectory. I actually don't know a formal way to think about this. Maybe you should help me out here.

• 2:20:26Speaker 01

  Why is AlphaGo an elegant RL algorithm? Yeah. So the 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 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 TD error learning or dynamic programming, at least explicitly. It's just supervised learning on a value classification as well as a policy 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.

• 2:21:10Speaker 01

  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. 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 like sort of local minima where every signal is flat all around you. So one way to draw the curve is like, if you draw the sort of win rate of an MCTS policy versus the raw network, let's say that dotted line is the raw network. The MCTS policy kind of looks like this. And so every step of the way, this supervision signal is very clean.

• 2:21:55Dwarkesh Patel?

  Right.

• 2:21:56Speaker 01

  You're never in a situation where, you know, the MCTS is kind of like giving you no signal.

• 2:22:01Dwarkesh Patel?

  Yeah.

• 2:22:01Speaker 01

  Unless your MCTS distribution converges to exactly what your policy network predicts.

• 2:22:06Dwarkesh Patel?

  Yeah, yeah, yeah. Okay, that's a great way to explain it.

• 2:22:13Dwarkesh Patel?

  Cool. Okay, maybe we sit down and I ask some questions about automated research.

• 2:22:17Speaker 01

  Sounds good.

• 2:22:18Dwarkesh Patel?

  One thing I really wanted to talk to you about is that you did a bunch of the research for this project through this kind of automated LLM coding assistant loop. And there's an idea that if you fully automated AI research, you could have some sort of singularity. Obviously, we're not there yet, but to the extent that we have early indications of what this process might look like, I am curious what your observations about what the AI is good at, what it's not good at, what you think about this scenario, its likelihood eventually, what thoughts you have about this in general.

• 2:22:54Speaker 01

  For sure, yeah. I think automated scientific research is one of the most exciting skills that 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 investigation. So in brief, I mostly use OPUS 4.6 and 4.7 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.

• 2:23:35Speaker 01

  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 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 loader has a new augmentation I came up with. Let's sort of try to find the best way to kind of fit the constraints of the optimization problem. And you end up with this much more flexible and kind of high-level, almost like grad student-like ability to just grind a performance metric. And so this can squeeze out quite a lot of performance.

• 2:24:17Speaker 01

  You can, on a fixed dataset with a fixed time budget, improve perplexity by quite a lot on a sort of classification problem like LLMs or Go.

• 2:24:28Speaker 01

  And it is also fantastic now at basically executing any experiment, right? So I have 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 so forth. 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 is it not doing so well today? So on my blog version of this tutorial, I have 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.

• 2:25:11Speaker 01

  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 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 like, wait a minute, this track doesn't really make sense. Like, let's go back to sort of first principles and think about, you know, what the bottleneck might be, or like, what are we trying to achieve, right?

• 2:25:53Speaker 01

  And so often, I had to catch infrabugs myself by prompting the right question to Claude to like investigate, you know, what is causing this discrepancy? And then it'll answer the question. I think with like, you know, Mythos-class models or Mythos++ models coming online, maybe this just completely changes and these problems just fall to just improve scaling. But at the same time, I think there's a lot of like rich opportunity to develop RL environments that might incentivize this kind of lateral thinking. And so one of the motivations for setting up this Go environment was that I think that, you know, Go captures a lot of very interesting research problems, often overlapping with, you know, LLMs 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

• 2:26:36Speaker 01

  And you can kind of check the outcome of a Go game quite easily. And then the inner loop involves all this kind of like, you know, research engineering around distributed systems, predicting whether an idea is going to work or not, predicting the, you know, the difference a particular modification to your training algorithm might make. And I think there's a rich library of subtasks and sub environments that you can kind of train an automated scientist to work on. With Go as a sort of outer verification loop, that then, once you acquire these skills, maybe you can apply them to like other domains like, you know, biosciences or robotics.

• 2:27:08Dwarkesh Patel?

  Or automating AI research.

• 2:27:09Speaker 01

  Or automating AI research.

• 2:27:09Dwarkesh Patel?

  Which is, which is the real crux or the scary slash incredible thing of just making, AIs making future versions of AIs. And you're suggesting the outer loop here could just be your win rate against Katagoo, basically?

• 2:27:23Speaker 01

  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.

• 2:27:34Dwarkesh Patel?

  Yeah.

• 2:27:35Speaker 01

  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?

• 2:27:44Dwarkesh Patel?

  Yeah, yeah.

• 2:27:45Speaker 01

  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.

• 2:27:53Dwarkesh Patel?

  I, I think there's a couple of interesting follow on questions. There's questions on the inner loop and the outer loop. On the inner loop, there's a question of how locally verifiable any modification you might make is. That is to say, would you know whether something is actually improvement or degradation, some idea you try out? Would you know that if something isn't working as a result of a bug or is it the result of the idea itself being wrong? Ilya was talking about why having, one of the reasons he thinks he's a good researcher is, he is a good researcher. One of the things he thinks makes him a good researcher is that he has intuition about, he has strong belief in what the correct idea is.

• 2:28:38Dwarkesh Patel?

  And he is able to persevere through bugs and know which things are bugs versus mistakes in the fundamental idea based on his high level belief about this idea should work, so therefore it's, there has to be bug versus the other way around. Why don't we start with that question, actually? Yeah. How locally verifiable are things which are good ideas?

• 2:28:56Speaker 01

  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 a lot of faith to get it to work. And so this presents a very challenging long-horizon RL problem, where every step of the way, you have like a committee telling you that this is a bad idea, and then ultimately you break it through, right? And so like, how do you design RL environments that maybe give you some feedback earlier? And I think this is a very tough, open question that I don't have an answer to. But ultimately, to play a very strong GOL bot, you probably did need to discover deep learning.

• 2:29:34Dwarkesh Patel?

  Yeah.

• 2:29:34Speaker 01

  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 taste really matters, like, you have to come up with ways to initialize your problem so that you don't solve a sort of very intractable problem, right? Like, maybe you can leverage LLMs as a sort of a universal grammar in the middle to kind of give you some sort of local feedback.

• 2:30:09Speaker 01

  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. And I think that's where a lot of the lateral thinking ability of humans kind of come from.

• 2:30:23Dwarkesh Patel?

  Yeah.

• 2:30:24Speaker 01

  Like, 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.

• 2:30:29Dwarkesh Patel?

  The other question is how stackable local improvements are in the attempt to get to a better result on the outer loop. I've heard rumors that at some AI labs, the thing that has gone wrong is that people will individually pursue good ideas. But those don't end up stacking well, and so the training run falls because of some weird interaction between two seemingly good ideas. And having a single top-down vision of how things should work is very important. Having worked at different AI labs and also playing around with, I guess, parallel agents trying different ideas, what is your sense of how parallelizable AI innovation is?

• 2:31:07Speaker 01

  Yeah, great question.

• 2:31:11Speaker 01

  I think the research taste for executing well on 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. Of course, in the fullness of time, compute is the single most important determinant on how things work. And it's almost inevitable that as you scale up energy and compute and parameters, intelligence will just fall out of that. And that's super beautiful, super profound. No algorithmic detail really matters beyond that. But in present day, we don't have infinite compute and parameters and arbitrarily good initialization, so we have to come up with heuristics that give us that. But these heuristics are probably somewhat redundant.

• 2:31:56Speaker 01

  So that's probably why you see this effect where a lot of these compute multipliers don't necessarily stack. They might have some correlated benefit. And then, you know, three years down the line, when the NVIDIA GPUs have gotten even stronger, maybe they stack even less well. Maybe at any given point in time, the benefit of any given compute multiplier is transitory, which is what I suspected with the Cottigo paper. There was many algorithmic ideas applied. And then you can see that with modern Blackwell GPUs and Ada-class GPUs that are much better than the V100-grade GPUs that that paper used, you can see that 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 the present time.

• 2:32:41Dwarkesh Patel?

  Yeah, interesting. How about the outer loop? How verifiable for making AI smarter? With Go, you do have this outer loop of win rate against the best open source model out there. And even there, as you were saying, there are other outer loops of, did you discover a new phenomenon, which is actually very hard to... If you didn't know scaling laws were important, if you're back in, when was Chinchilla or Kaplan's scaling laws released, like 2019? Yeah, so if you're back in 2015, would you, there's not an automated procedure one can easily imagine of knowing which paper is the scaling loss paper versus which is just like another random plot. And so that, even in the Go case, is a hard to verify outer loop.

• 2:33:25Dwarkesh Patel?

  And the whole idea of an outer loop is to have like some backstop on improvement. But let alone for general AGI, where of course we have a bunch of these benchmarks, but there's a problem that like, we know the things we can measure, and we improve on the things we can measure, but we care about this broader ability to do economically useful work, which is, at least until you automate everything, not super easy to measure.

• 2:33:54Dwarkesh Patel?

  So yeah, there's a question of, okay, how good is the outer verification loop for AI self-improvement, and does that matter?

• 2:34:01Speaker 01

  Yeah. I'm going to 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 LLMs. And presumably, there was some positive transfer from their time working on games, and like Atari, and Go, and StarCraft, that like now helps them make good LLMs. 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.

• 2:34:42Speaker 01

  And so if that's the case, why wouldn't it also be true for automated AI researchers? Like, they should be able to positively transfer experience tackling, quick to verify, quick to iterate on environments, to something more ambitious and economically useful, like, you know, automating drug discovery or so forth.

• 2:35:00Dwarkesh Patel?

  I mean, I don't know. Isn't the issue with, historically, until Gemini 3 or whatever, been, a couple of years ago, people were saying, look, Google hasn't, isn't catching up in LLMs because they're too tied to the old approach. And yeah, there's gains, but there's also, there's ways in it which actively hinders you. So it's actually not obvious to me that there's like...

• 2:35:27Speaker 01

  The jury's still out, right? I think like, who knows if the, you know, let's say currently, Google's doing quite well. Who knows if the initialization on training on games is ultimately going to hobble their ability to be the winner in the long term, right? Like, it's hard to say for sure. And, you know, likewise, who knows if the seeming late start was really just them kind of pre-training for longer on how to like, scale up TPUs. 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 a... So it's even hard for humans to reason about what the optimal research strategy should be, even with the data we have today.

• 2:36:07Dwarkesh Patel?

  Yeah, yeah, cool. Okay, we should let people know how they can find out more about this project, whether to fork it themselves, whether to check out your blog, because you're doing an excellent job explaining many of these ideas. Where do people go next?

• 2:36:20Speaker 01

  Great, yeah. So my website is evjang.com. There's a blog post that kind of links to an interactive version of this tutorial. And on my GitHub, which is, the username is just EricJang, there's an auto-go repo that people can fork and reproduce the training.

• 2:36:36Dwarkesh Patel?

  And I also highly recommend people check out this blog post, As Rocks May Think, which, we touched on some of the ideas in this conversation, but it's this grander, you know, thesis of what happens when you have thinking as a primitive in...

• 2:36:50Speaker 01

  Computer science.

• 2:36:51Dwarkesh Patel?

  Exactly.

• 2:36:51Speaker 01

  Right.

• 2:36:52Dwarkesh Patel?

  And so I highly recommend people check out that blog post as well.

• 2:36:54Speaker 01

  Yeah, and I encourage the, you know, the audience to, you know, think about the relationship between thinking and Go, you know, via MCTS and search, and how it relates to LLMs. I think there's something quite profound there, and probably under-explored, just because Go has been relatively under-explored compared to, you know, the boom in LLMs. It's not to say that I think we should have trees in our LLMs, but there is some very interesting duality between them, and you can actually do a lot of research on Go, MCTS, and reasoning with, you know, very small budgets. So that's very exciting.

• 2:37:25Dwarkesh Patel?

  Cool, awesome, Eric. Thanks for doing this.

• 2:37:27Speaker 01

  It's an honor to be on the podcast.