让AI与人类研究员竞速：自动化AI科研的极限与真实瓶颈

Hello, uh, greetings to everyone. Thank you for being here. Yes, I'm really excited to talk about automated AI research today and, in particular, how all these advanced models are performing automated AI research tasks. So, I'm Amy. I work at Prime Intellect as a research engineer, and yes, I will talk about our work in this area.

So first I want to explain a little bit why we're doing this and why we think it's so important to do it openly. So, first of all, I think we all agree that we've heard from big labs about this dangerous thing called "recursive self-improvement," which is coming very soon. So, recursive self-improvement is when models train other models without human intervention, essentially. But we don't have any benchmark to quantify whether that's true or not, right? And even more so, we don't have an independent benchmark from small laboratories to understand whether to expect this in the near future.

The other part is that we think it's extremely important to understand how these models conduct research, because we believe that a significant portion of scientific research in the coming years will also be based on AI tools. So it's very important to understand how these models do research, not just AI research. So we're trying to create an environment to test the models' ability to do that.

It all started with Andrej Karpathy, who essentially had fun creating this video where he trained GPT-2 from scratch in about 90 minutes. Training GPT-2 takes weeks, and two years ago it seemed to only take 90 minutes. So what does it mean to recreate GPT-2 in 90 minutes? This means that in 90 minutes you have reached the target loss function, and yes, at this point, when you have the same loss rate as GPT-2, you consider your model to have roughly the same performance.

Then what happened was that the community took this repository, this GitHub repository, and created another one called "modded nano GPT," and this work was led by someone named Kyler Jordan. And it turns out that they cut that 90 minutes down to 45, and then — no, we can train a model with the GPT-2 validation loss rate in less than 2 minutes, which is, frankly, crazy. And it took about 2 years.

So, this is a very strong benchmark that many talented researchers have worked on. Um, yeah, that's why we decided to choose this environment for the speedrun. So, what do you see? It's a kind of game. So, the goal of the game is to reach this loss rate in the shortest amount of time. So, this is nano GPT-1. And you have almost no restrictions. The only limitation is that you have to use the same data for validation and training, right?

Um, there's a new speedrun called "optimizer speedrun" released a few months ago. And here the situation is a bit different, as you can only change the parameters related to the optimizer. So, for example, in NanoGPT you can change the architecture, do MOE, change the focus, etc. In the optimizer speedrun, you can just change, for example, Adam to new shampoo or any other of your favorite optimizers. Um, yeah, and it's a bit more like research, because it's not so much about optimizing the program for maximum speed, but about finding the best method, regardless of the time spent on the computer, right?

So, yes. Why choose Speedrun as an environment for automated artificial intelligence research? First, we think this is a good estimate, then we'll see why, and that's the main focus of this conversation. But we also think it's probably a good learning environment because it's a way to provide a reward to the model. So, the reward is positive if the model completed the speedrun and broke the previous record, sorry. And the reward is zero or negative if she fails. So, this is a good environment for training the model. It's also pretty fast, as you can see, the previous record for the optimizer was around 2 minutes. Each run takes approximately 15–20 minutes. And yes, there are, in fact, clear rules there. And we also think it's a good environment for making discoveries. That is, a kind of breakthrough in 2D research, because there are these clear rules that can be tested or refuted. Um, yes.

So, yes. Um, so what we did was: the release was about 2 months ago, and there was this "optimizer speedrun," so we decided to compete with the community by running two AI agents. So, Codex and Cloud Code. Codex was like GPT-5.5 with XAI, and Cloud Code was like Opus 4.8 with XAI. Um, and yeah, we decided to actually release an agent onto our cluster, uh, and, uh, just iterate over it. So we have versions V1, V2, V3—this is essentially us stopping the agent and then restarting it.

V3, uh, was about a day or two before the release, because we saw that our agents were no longer having the best results. So we're like, okay, take all the human, uh, records from the last few weeks and just try to beat them, in any task. Yes. And we also have a direction of novelty, where the goal is, uh, to break the record only thanks to new ideas. Um, and we see that it was more difficult for the models.

So our structure is very simple. Honestly, we could have just replaced it with /goal, but at that time, there was no /goal. So we created our own goal.md. It's funny that we chose the same name. And we had a goal.md and, like, agents.md that defines the rules, and we let the agent propose ideas, and then it can submit tasks via Sbatch to our Slurm cluster. And, actually, this is how it works: it can send tasks to available nodes, but only with a certain permission, which means if someone wants to use that node, uh, the model just cancels the task. This is called preemptible permission. So, yes.

Then he measured, essentially, the training logs and then decided whether it was a record or not. To confirm a record, you essentially have to pass a statistical threshold to make sure it's not just random number optimization and coincidence, right?

So, yes, some results from these experiments. The first thing that was honestly really painful to work with was that code-code-code-code kept stopping every 9 or 10 hours and basically saying, “Yeah, I can’t beat the record. It's too hard for me. There is no way to go beyond it." And then I just said, "Okay, keep exploring a new direction." And he worked for 10 hours again, and then he said, "Yeah, I can't break the record," and so on. So, essentially, a third of the time the code-code agent was on standby because I had no way to control it. And Codex is the complete opposite, it just worked all the time. And, yes, he almost never, ever asked questions, and, and, and was very impressive in that regard.

Um, we also give the model the ability to write down a bunch of things in a so-called "draft notebook", which is actually the model's active memory. We noticed that Codex mostly writes a lot to this notebook. So all the graphs I'll show are normalized by the number of active actions. This means that Codex doesn't just work harder, it's truly a different behavior model. So, yes, you see that he writes a lot more in the sketchbook, in this memory. And the tone of each file was also very different. For example, Claude was excited about setting new records, using a bunch of emojis and such. And Claude X behaved with restraint: "That's what I do." "Here is the decision I make." "What will I do next?" Very robotic.

Uh, yes. We also have this graph where we see that Claude X created significantly more subagents than Claude. We saw that Claude X spent significantly more tokens than Claude. I think overall it was somewhere around billions of tokens. But of course there is caching of input tokens, so it's not exactly 1 billion output tokens. So, yes. We also see that Claude X was doing a lot of compression because he only had a context window of 250k. And Claude only did it once an hour. And Claude X more often. No, even less than once an hour, I mean, once during the entire launch for Claude, and for Claude X it was about 20 times an hour. So, yes.

And here are the main results. This graph shows the progress of human results—that's the white line. And in red you see Claude. Although it should be orange, it doesn't matter. And in blue you see Claude X, right? You see that almost always Claude and Claude X are better than the human record, and Claude is very accurate at the start, achieving high results very quickly.

And something else very important: the model has the ability to get human results at any time, and that's exactly what Codex did... sorry, Claude, because when I restarted it, it got a new human record and improved it. Um, so here's the result: I think the best record at that time was about 2,990 steps, and we beat it by 50 or 60 steps for Claude, and Codex was 20 steps ahead. So I think that's both impressive and, well, yeah.

Um, so we...it's not released yet. This is what we are working on now. And basically the idea is that it's a cool experiment, but it lacks structure, you know? If you want to do a real benchmark, you need to use multiple initialization options, do everything properly, where you put all the models in the same conditions, right? So that's what we're working on right now, and the idea is to do three different directions. One without any access to really measure the models' ability to conduct AI research based only on knowledge of the model's weights, one with only access to articles from the archive, and one with full access. So, he also has access to the latest developments of people. And for this, we plan to conduct both a nano GPT track, which is original, and an optimizer speedrun, where we limit the optimizer to only the novelty, essentially.

Um, yeah, so I'll present some results on the optimizer speedrun. This is, in fact, what we got. We let the agent iterate for almost 6 days, let's say 5 days, and we see that Codex, Kimi, and Claude are very efficient. So, it's not a complete launch for GLM, right? The model is actually still continuing to iterate on our cluster. But we see that Claude is showing a very good result again. And we see that, surprisingly, Kimi is also very competitive. He kind of made a breakthrough around day four when he surpassed Codex with a new record, right?

It's also interesting to see that Claude is more progressive in how he improves the record, and Kimi has a real step function where he makes a breakthrough and so on. So, this is an interesting timeline, because 6 days is quite a long time to evaluate. But you can change this axis to the number of output tokens, and then the story will be different, because Claude consumes much more tokens in max mode than Codex and Kimi. And you also see that Kimi is actually very efficient in terms of the number of tokens she uses. So, this is Kimi K 2.7 code.

Hmm, well, yes. We also see that they have different approaches to using literature and scientific articles. For example, Claude performs a lot of article searches, and in fact, Claude found an article that no other model found, and this resulted in the best result. So it's pretty funny.

And, uh, yes. One of the main problems with all of this is that when I ran these agents—and I think it's important for you to remember this for this talk—when I ran these different agents, I expected them to come up with some crazy ideas for the optimizer that no one had discovered before. But, to be honest, that wasn't the case. They used some clever tricks, where they basically combined different articles. They made a kind of "plus one" improvement to many methods, but no new optimizer or mechanism came from these models. And I think it's quite telling that even for something that's not simple, but, I would say, accessible to people, right? For human researchers who spend days and weeks, the model cannot find new optimizers and mechanisms.

So we think there's a way to make this better for discovery, not just for evaluation. And it's very inspired by Google's Alpha Evolve work, as well as a bunch of articles that have been published since then. It's a kind of multi-agent system that interacts together—a bunch of generators. You have closed-source models, but you also have open-source models that are extremely cost-effective, right? They can suggest ideas, then you run a quick run, get a reward, and then you have a judge who provides quality feedback. It could also be that the judge has a certain taste. You can make it so that the judge has his own vision of whether this method is good or not if it is outside the main loop.

And then you can decide which method you want to scale to more parameters and tokens. So, this is kind of the scalable part of the rapid run, because a lot of people in the development community often say that their methods don't work at scale. So, I think it's very important to also add scaling elements to this cycle. Uh, and I think the people here are also extremely helpful in evaluating agents' ideas, steering them in the right direction, etc.

Um, yeah, we haven't tried that yet. That is, we are trying to do this now, and we hope that it will at least lead to new discoveries in artificial intelligence research. And there is also a way to define multiple speedruns. So this is the next slide. Uh, if you want, it's from the SoftBank slides, but if you don't know that link, that's okay. This means that you don't spend too much time online. But the idea is that by changing the goals and constraints of the speedrun, you can create a lot of variety and make the model move in a certain direction. And, uh, yes, making these discoveries.

So, at Hummingbird, we're doing a lot in that direction. There's a lot of stuff here that we, well, most of it we haven't released yet, but we're working on a GPU sandbox to allow models to iterate in the sandbox, because that's what you need a GPU sandbox for. We are working on our own agents that are very efficient for the LLM infrastructure. This means you have a file system, you can write and read information, and you can run software coding tools. We train the model to be good at this based on open source models.

What we have already released is a set of libraries and a product called "verify primary" or "state training" where you can train and evaluate any environments and the model that can be trained can be, for example, GNM 5.2, which is very large, and yes, we are working hard to make these libraries very efficient to provide the best quality to our customers.

Yes? I mean, yes, I'm very passionate about this field. Again, I think it's extremely important that some of this recursive self-improvement happens openly, because in reality, a lot of people don't work in big labs. So, we need to make it easy for people to understand how all these models work, to conduct research, etc. So that's our goal, and thank you very much.