> “breakout game weights” always look the same regardless of training and model

The prompt told Astra what the input and output layers mean -- that is, how the current state of the game is turned into a vector for matrix multiplication, and how the result of those multiplications is turned into an action to take in-game.

Astra saw that the model was trained on a game where the player is at the bottom of the grid and moves left and right, reward objects live at the top, and there's some not-player-controlled thing moving around in the middle. Astra knows that this type of game is called "breakout."

A model that plays breakout will have meaningful weights for the player being in the bottom row, but not for the player being anywhere else, because the player can't go anywhere else. Astra saw that there were meaningful weights for the player in the bottom row, and nodes representing the player in any other row had low-magnitude noise, so the model had never been trained on the player being anywhere besides the bottom row.

Similarly, breakout has "reward" objects in the top rows, and "there is a reward object at [COORDINATE]" is part of the input layer. Astra saw that the model was trained on reward objects in the top few rows.

At this point it's either wrong or meaningless to call LLMs "next token predictors". Yes, pretraining involves predicting the next token. But after that you're in the world of RLHF, RLVR, and other post-training.

A model is _sort of_ designed to predict the next token in a string of text. But it's equally accurate to say it's designed to edit code until it passes a suite of unit tests.

Yes, they generate sequentially, so "next token predictor" isn't technically incorrect (which is why I chose the word "meaningless"). But it's pretty clear there's a mechanism inside them that allows them to "plan" what they generate. I might as well call you a next word predictor.

>I mean, an LLM is still fundamentally a next token predictor, right?

Yes, but everything, including the human brain, is "fundamentally" some underlying simpler primitives.

>E.g., “breakout game weights” always look the same regardless of training and model?

Wouldn't this be expected to be roughly the case, given NNs that share the same basic architecture to model the same quite simple thing like a breakout game?

It’s important to understand that it had pytorch to actually run subsets of the weights. So its more like a dedicated person running the model to find the token it shouldn’t generate, then following the weight chain back up while calculating the NN outputs to find a place where if it changes some weights (again with a lot of testing via pytorch) the result is better.

Its not natively reading the weights in the Matrix “symbols scrolling on a screen” sense. Still bloody impressive and not an outcome I would have bet on!

This implies that weights are a type of language. Neural networks are good at language because they are good at patterns. They can reason about it because their "reasoning" isn’t how we think. The same goes for how they encode images, their vision is entirely different from ours. That's why adversarial attacks work on them and not on us. We don't see anything change in the image, while the neural network now sees that the dog is a cat.

There's a long standing line of thinking that data compression has something to do with intelligence, or that intelligence may "just" be data compression in some sense.

In the case of models, the almost-theory (hypothesis with a good deal of evidence) is that once the amount of training data exceeds what the model can simply represent internally, the best way to keep improving is to start to "understand" the data. Understand in this case means to form internal control structures and decision systems that represent the data algorithmically rather than just memorizing it.

I put understand in quotes because we don't know how far this goes toward what we call understanding, or whether there's still a lot missing.

Maybe I'm missing something, but isn't training an LLM very well documented? Why wouldn't an LLM be able to read those docs just like it would read Java Spring docs?