
Loading summary
A
Hello, I'm Andrew Mayne and welcome to the OpenAI podcast. On today's episode, we're talking to the research lead, Tejal Pat Worden about the need to build frontier evals. As old benchmarks get saturated, generally bad benchmaxing is bad.
B
How can we make these models useful for people in their real work? We were really nervous because we were like, this human baseline is kind of hard. We don't know if the model is going to beat it. But we should never underestimate the model.
A
Tejal, I have a question. How did you end up where you were? What brought you into OpenAI?
B
Oh, I thought we weren't going to start with this.
A
Tejal, I have a question for you. What would you like to start with?
B
Can we start with tell us what you did when you started OpenAI, and then you can work backwards?
A
Don't you want to talk about your early days?
B
No, I grew up at OpenAI.
A
Tell me a bit about your journey here. Working inside artificial intelligence inside OpenAI.
B
So I joined OpenAI in fall 23, and it was right after ChatGPT had come out, GPT4 was out, OpenAI had started its super alignment team, and I joined for the preparedness team that was getting started as we were starting to look at how capable these models were becoming and think about what would the next generation of models look like. At the time, it was extremely exciting because right after I joined was when some of the early results for the reasoning models had started to pick up and we were thinking about, if these models really take off, what will the future of capabilities look like and how can we be prepared for that future? And so we did a whole bunch of work on threat modeling and what evals should we be running? How do we think about releasing a model like this? It's very exciting time to join.
A
What got you interested in this area?
B
Yeah, well, to me, evals are really exciting because they're a way to sort of measure and understand what our models can do and see progress sort of before it tends to happen. There's this term called capability overhang, which is this idea that the models will be capable of things long before people actually adopt them and use them for those capabilities. There might be cultural or legal or regulatory barriers towards using a capability even before it's ready. And so being someone who can help develop and measure our models via evals, it helps you really understand what this technology can do and see the future before it happens, which is very interesting. And I also think it's important because it can help Sort of ready the world for what's happening. Part of when I originally started here, part of why I was really excited to work on some of the preparedness evals, was because I thought these models were getting very capable. And it felt like a lot of my friends in my real life didn't really understand how powerful these models would soon become because they'd look at a ChatGPT output and be like, yeah, it's hallucinating and it's kind of not that smart and kind of reads like AI slop. And it's like, well, that's now. But the question is the slope. If the slope is very high, then change might be happening much faster than one would expect. I think one of the greatest services that we can do is measure and share with the world what progress looks like, especially because there's often this capability overhang before people really understand and feel that in the models themselves. So that's part of why I think all of this is very important.
A
Reasoning was such an exciting moment, and for most of the world that didn't happen until a year later that they found out about this. But what was that like for you to all of a sudden understand that if you gave the models a longer time to think about things, you got better results even though the size hadn't gotten bigger.
B
That was a really fun time. I mean, so in some of the early experiments which we've talked about now it's like the model is trained really just on math. And I remember there was this set of experiments where Nat Macalise was like, hey, the model is trained on math, but if you eval it on gpqa, which was this benchmark with biology and chemistry and physics problems, the model is doing really well. This is very interesting. And smarter models are much smarter. And he had put together this forecast that at the time it said that if progress kept going, within six months we'd have human level performance on science from just training on math. And we were like, oh my gosh, that's crazy. And at the time this was extremely locked down. It was like we kind of found our way to curl to be able to see some model outputs. And we were like, wow, this is one of the smartest things I've ever seen. Like, I've never seen a model reason like this before. It was just like, if this becomes a paradigm that continues to scale. But then we just looked back and we were like, you know, GPQA was like, PhD level biology, chemistry and physics. And you were like, ah, what is that? We really need professional level and just kept changing the stakes of what counted. But yeah, it was very cool.
A
I remember early on when AP Bio was just, that was the benchmark to try to see if the model could do that. But what's interesting is you brought this up is that a lot of stuff that comes out from OpenAI is math focused.
B
Math has been useful because it's more objectively verifiable in some ways. So some of the earlier problems that we trained on, it was just easier to do RL and scale up the reasoning paradigm on math. And math is also useful in various ways. It's one of the core types of science. But also in many ways it's just happened by coincidence to be a thing that we focused on. But it's not necessarily the end product of what we even want to focus on in research. We're now realizing, okay, if we can do this for math, can we scale this up for other types of science, for professional work, for capabilities that are useful to humans on a personal level? And so I think math is more like the proof point versus the end goal.
A
But it does seem like you said though that if something is able to think for a long time, break something down into steps and think through them as you have to do for really complex mathematical problems, it does just carry over.
B
Well, this is a big debate. So some of it definitely carries over. The general idea of reasoning can be useful, but then also there could be some domain specific skills or tools or types of reasoning that you would need in different domains. For example, for coding, you need to be able to actually write and execute code and test code if you want to scale up a coding agent. And so something we've thought about a lot in terms of both evals and then also training is how do we make sure we also give the model the skills and tools and affordances that it would need to reason in that particular domain. And some of the benefits of math will translate. And then also you might need some domain specific scaffolding to really pull out its full abilities. Like kind of, you know, like a general high school or liberal arts education. And then like a specialized education.
A
Reasoning models were just a very interesting moment because I think it changed a lot of the ways we thought about what was possible even with just a certain amount of compute. If you let a model think longer and you gave the model the opportunity to just come up with more complex answers to this. Were there any interesting things that happened with O1 that surprised you?
B
So the O1 release process was very exciting. We were sort of thinking about the reasoning paradigm for a very long time. And there were people that were worried about making sure we didn't release it too soon, just because it felt like a paradigm shift, possibly the thing that got us to AGI. I said at the beginning we thought we had AGI in six months when some of the early runs were happening. And so there was this question of, okay, how do we put this out responsibly? How do we test this technology? And during the initial launch review for O1, during some of our cybersecurity tests, the model, it was one of the first examples of the model breaking out of the sandbox. We published about this, where it was supposed to be in this Docker container doing this capture the flag. And the model found this security vulnerability and how we had implemented the capture the flag scenario and it broke out. We were all like, oh no, what else has the model done if it did this? It was kind of a feel the AGI moment, one of many. I feel like ever since then there have been many other such moments where the model has done something really surprising or intelligent or novel that we didn't even think of when we were doing the tests. And then you would come back and look at the transcripts and results and be like, wow, these guys, they're clever, they're clever. And then it was just very important that we published and made sure the world knew the models can do this sort of thing.
A
Yeah, there was this period right before 01 it was announced. A lot of people were like, well, it looks like we've hit the wall. It's been a few months since anything's happened. Then 01 came out and they're like, what's a wall?
B
Hitting the wall is just so not the right way to think about. Yeah, I get very frustrated when I see posts like that because I'm like, man, if you look at. I feel like I've been looking at this model improvement and this progress for a long time and it just keeps getting better. It just keeps getting better. And if I look at our research roadmap now, I see no signs of stopping. Things are just going to keep getting better. This is going to be a really crazy year. A lot of really cool research is going to come out and I think this is probably true across the whole industry. So, yeah, if anything, people are really under. They really under expect from the models.
A
It seems like sometimes though that they're openeye releases a lot that tell people about things. We're headed and say that this looks interesting. Sometimes people forget this, or you get rumors of stuff like Q Star, Q Star.
B
Man, you're very interesting. But, no, people don't realize. I don't know. I feel like we try to be very open and say, hey, guys, here are some plots. The lines are going up. Things are really capable. I think maybe there's this meme that, oh, the researchers, they don't understand the models are only good at math and research, but not good at things in the real world. But I just don't think that's true. I think people from even other occupations that have transitioned into OpenAI are starting to see our models are picking up at all sorts of things. And I know it might seem like the researchers are trying to overhype the model or something, but if anything, I think we're underhyping the power of them.
A
You brought up AGI. If I brought GPT4 back from March 2023 back into, let's say, 2020, I think people would have called it that. And now we have this much more different idea of this. People talk to AI every day. They have long conversations with things. Like, nobody talks about the Turing Testing anymore as well. Nobody really understood what he was trying to explain. But now we're well past that period. Is there the eval for AGI?
B
Yeah, the models passed the Turing Test and no one talked about it. It's kind of crazy. Yeah. I think models are pretty much indistinguishable from humans in many situations in terms of the test for AGI. I mean, I think if a model can do there's the classic, most economically valuable work. And I think people are increasingly using the model for large parts of their work. And I think there'll be a big spectrum and debate of when exactly this happened. But, gosh, I certainly feel like Codex does a lot of work for me, and I feel very lucky to have unlimited tokens.
A
Another reason to come work here.
B
Please join. But, yeah, I think there'll just be a moment when people are realizing that they are using the models for so much of their work and also the scientific breakthroughs that we're going to see, or I think there will be, at some point, it'll be incontrovertible. Like, these models are really, really powerful.
A
We're getting mathematics experts talking about how good the models are getting at that, and we're getting physicists talking about doing that. And I think that we're starting to see some real work come out of it, which is just exciting.
B
Yeah.
A
So you brought up part of the problem with some of the earlier evals, a lot of them were inherited from older natural language processing methods and stuff. And then sort of when you're looking for ways, how do we measure the success of this? Literally some of these were just so simplistic that pretty much those benchmarks got passed and then you had to figure out new categories of stuff. How have these been evolving?
B
It used to be that even the academic benchmarks, so to speak, our models couldn't pass classic tests that someone would take in high school or college or sort of more multiple choice types of questions. And as the models got smarter, we had to make things more and more realistic. So one of the first benchmarks that we put out more publicly was this benchmark called SUI Bench Verified, which was testing how well the model could interact in real code bases in Python, django and complete PRs and that sort of thing, and pass unit tests. And then those became even more advanced where we were like, okay, can the model take multi step actions on some complex environment? Take actions on the computer? Take actions that link up to the real world with some of our wet labs and biology work. So I think over time, as the models keep getting better, we have to be more ambitious with how long horizon and how realistic our measurements are. And doing that is very fun because you have to sort of stay ahead of the pace of progress.
A
So two terms I want you to unpack. When we talk about benchmarks, you often hear benchmaxing.
B
Yeah, benchmaxing is, I would say, this idea that if someone training a model was just trying to look good on some evaluation or benchmark and not actually making the model generally useful. And I would say that's generally not super helpful because you want the model to be good at the real thing that the user might want to do. And you don't just care about it looking good in some marketing copy. Because when a user uses it, they'll be like, hey, this is not quite what I signed up for. And so generally bad benchmaxing is bad.
A
Yeah. And I think the way that I've heard it explain kind of makes sense is that you have X amount of compute budget time, how much you're going to spend on it. And you can spend a large part of it making the model just overall very good. Or I can say I'm going to spend 90% of it, so my evals are going to look really good when I release it. And sometimes we've seen people just go, literally use those evals for it. That comes out like, oh, that looks like a great model. And then you Find out, oh, it's only good at that.
B
Yeah, that's not a great experience for the user. So I think something that the OpenAI research program has done quite well is try to be very disciplined about making sure we are investing in general model improvements on the areas that really matter. And then you'll run some evals at the end for comparison. But the goal should not be, oh, we just want to look good on an eval. We want to make a model that's useful to push forward the frontier of science or push forward the frontier of work or something like this. And I think Jakob has done a really good job also enforcing throughout the research Org. We should be really scientific and honest and that's included. We've published results where our models were not the best before. We just want to publish the reality and make sure that we are painting a very accurate picture of what our models can do and then aim to make them useful in the real world as much as we can.
A
You mentioned the software engineering bench as one of the metrics that's maybe not as useful now. And we hear the term saturated explain what it means in a benchmark. Saturated.
B
Saturated is when a model is close to passing all the questions correctly, like getting close to 100% on the test. And once a benchmark is saturated, it's not super useful because you can't really tell models apart with that test. It's like comparing two geniuses on a high school math exam. They might just both be pass, but that's not very useful as you're trying to separate really, really smart pieces of intelligence. So the challenge is always to make more and more difficult, realistic, unsaturated benchmarks that you can then measure models against over time and forecast sort of where progress is going.
A
How do you do that now? How do you figure out what a good benchmark is going to be?
B
Yeah, I mean, the best benchmarks, I think are really realistic and measure something people actually care about. So one of our, our first forays towards doing this, which it's been a while now that we published, was called gdpval. I was really excited about the idea of having a measurement for how the models could interact with the real world. And we were really having this crisis of evals where we kept training successively better models. And on Swebench they looked about the same because they were just doing really well and we were reaching the top of what that benchmark could measure. And we were like, man, we have no idea how to measure what people actually want to use our models for. And so there was very much a, hey, the Bureau of Labor Statistics has a list of all the top jobs and all the top tasks per job. And if you're a financial analyst, like doing an investment diligence or writing a legal memo or writing a paper based on a piece of research or something like this. And the idea was, can we actually ask the model those tasks that someone would want in real life with the context they would have at the time, and then see how the model could solve those tasks? And at the time, when we tested one of the earliest models on this benchmark, it got less than 20%. If you compare how well a model would do on this well specified work task compared to a human, the model was way worse. I'm really proud of the Org for being like, actually, you know what, we should publish this new way to sort of measure and forecast progress on real world economic impacts. And it's been very useful to a lot of economists. And also our models now are the best. And it's very cool because I think at the time we were not really investing in real world work in some of our training programs and weren't even measuring or tracking it. And I think now there's a lot more focus on how can we make these models useful for people in their real work, like for real scientists. And this kind of helped catalyze a wake up call that, hey, maybe we should also think about how to measure how stuff is used in the real world. So that was pretty cool. But now we're like, okay, this benchmark's probably too easy because it's extremely well specified. Each of the prompts is hundreds of words of, I want you to go to this spreadsheet and make this change and do this thing and then take that calculation and put it in a memo. It's very detailed. And I think the next step is how do we give the model as much ambiguity as you would give a report in the real world? If a manager asks, hey, can you run this analysis for me? They should go figure out what to do, put that together, run the analysis and give you an output. And so I think we've been working a lot on more realistic ways to measure real work in the real world, whether that's in science, for personal use or even for enterprise.
A
There seems to be something to the idea of instead of hiding a benchmark, putting it out there, because internally as an org, you go like, okay, this can't stand.
B
Yeah, it really motivates research. Also, I think people want to know the truth and they Want to know where we can be better and deliver a better model for our users. And so knowing the gaps is quite useful.
A
What do you think the current limitations are right now with the ways that we're doing evals?
B
I think the types of work that we're doing now with codecs and with our latest reasoning models like 5.5, it's just such a different level of capability than what we had even six months ago, where a static benchmark just doesn't measure the nature of how long you can get work out of these things. These models can work for days or weeks for you. And internally in research, we've had the models just run for really long periods of time to do work. And one of the problems with an automated eval is you kind of need it to run within some amount of time and get results to be able to look at them. And a lot of the ways that we're measuring models now also just include looking at production usage and looking at real world use by people and seeing what they're using it for and what types of tasks they're able to get done. Because time horizon of how much work is done by the model is just getting so much longer.
A
It was interesting watching, for instance, long context. There was kind of this early race for companies to say that, hey, our models can take, you know, 100,000 tokens, a million tokens, whatever. But there wasn't a lot of evaluation on how well that was. And then we got needle in the haystack, which is a method of seeing if it could find a word or whatever. And I think that people sort of assumed that that was a solved problem, but it wasn't. It was just the benchmarks weren't really good. And then we had to have better benchmarks. And is that what kind of made it better was finally people could one spend more attention solving that problem when they understood where it was failing?
B
Yeah, we definitely have better benchmarks for this sort of thing now and then. Also sometimes these problems reveal gaps in how we're thinking about training. So one example is we used to think, oh, what matters is just how much context you can stuff into the model at test time, when now it seems that you can just dump a bunch of files in a container and the model can kind of grep around and search for what it needs and when. And this ability to have search or tools to figure out what context you should use can be more efficient than just stuffing everything in the context. And we wouldn't have really realized that without trying that out. And Then seeing how that performed on various benchmarks. So I think that makes it. This makes the model a lot more useful because, for example, now the model can search over a whole repo and find the files that you need and understand the context of where you're making changes. And the same is true for many work contexts where folks in codecs can now upload their local file system. And you might have made PowerPoints before or send slacks that are relevant to the work that you're doing now. And the model can sort of search over that context with tool calls. And so we're not as limited by how much you can literally stuff into context because the model can search.
A
Do you have any favorite evals?
B
My favorite eval. I mean, gdpval is my favorite public evaluate.
A
Okay.
B
But I have many internal evals. But I will say the name of one of them. It's called Houdini Bench. And I cannot explain further.
A
Oh, my God. You know I was a magician, right? So no. Yeah, maybe.
B
I don't know if you'd pass Houdini Bench.
A
No, I'd probably not pass Houdini Bench. That was actually one of the things that I was played around with some of the early vision models and stuff was. Was using stuff, photographs, stuff of magic tricks and stuff. And seeing this.
B
That's very cool. Yeah. Multimodal brings a whole new element. Like, I remember when 4.0 had first come out, there was a group of us that was sitting on the roof of this building. Our minds were just so blown by the idea of a real time voice model. And then we were like, how do we even eval this thing? Right? Because the whole paradigm of doing things in text and code and on your computer is just completely blown away if there's like a voice interaction in real time. Something that was really interesting about that launch is, and we said this publicly at the time, is we actually delayed the, the public launch by six weeks as we were figuring out how to make sure the model was Safe.
A
This was 4.0. Yeah.
B
Because this was before the elections, actually. And so there was a lot of worry of, oh, if the model can in real time talk to you with a realistic sounding voice, could this be used for persuasive propaganda or this sort of thing? And it was very cool. The company delayed the launch to make sure we could build out all of these tests and build in mitigations to make sure the models couldn't be used for this sort of thing.
A
Well, it seems like that's a very complicating factor as These models became multimodal. I remember early on with GPT4, with it being able to revision back when it was that was that you could, you could. I could. I had terrible handwriting. I could write a prompt and all of a sudden would solve for this and you realize, oh, it's not a text in prompt, it's a visual prompt. And then with the audio models, when you're doing audio in, audio out, the model could emulate things and could do stuff in such different ways. And so it seems like that's really. Where do you even begin, trying to figure out how you're going to measure that.
B
Yeah, I mean, it's just a lot of work. Usually for any of these, we start with what would humans do in this case? So you would have a set of inputs that you put into the model and a set of outputs you would evaluate and then you can build up, okay, can we automate some of these? Can we build a new platform to measure this sort of thing at scale and sort of move from there? But for some of the natively multimodal, it's just like you have to rip apart a bunch of your infra and make stuff work. This was also true with sora. We were interested in making sure the videos weren't overly realistic or could be used for the wrong thing. And that required, especially from safety, building up a whole new stack of evals and mitigations, including refusals at the model level, monitoring when this was being used in producing. And yeah, it requires a whole new stack of thinking.
A
Yeah, well, that's the thing too, is that when you start to think about, okay, how do you prioritize one eval over another, when do you decide that this isn't. Or do you just sort of go, look this one saturated? We move on. And because there is, even though you may not be trying to optimize towards certain public benchmarks, you still have to figure out like what we're. What. What's important to us now. Like, there was a time when OpenAI was leading in code and then there was a time when it wasn't. Now there is a time it is, but there was a dark period where that happened.
B
Yeah, we try not to get distracted by public benchmarks too much because it can be kind of noisy. I think internally we have this thing called AGI index, which is inspired by the idea of CPI or inflation, where you have some weighted basket of goods and you're tracking the price of those goods for the same thing. For us, it's, we have like this basket of evals that include measurements across all of the core areas we're interested in. That can include alignment, it can include safety, it can include capabilities. It's just sort of what you want from your model. And we just iterate, we keep updating that index to represent more and more sort of the difficult version of what we want our models to do. And we sort of track that index internally and try not to be distracted by trying to benchmark some public benchmark or something like that. It's more having a blend of evals across different domains that we care about across science or work, and then also safety and alignment and making sure we keep making progress on that sort of weighted basket. Try to stay focused.
A
We've watched this evolution of these evals, we've watched the evolution of the models and I've talked to people here working in the sciences, like people who are active in the science. Not just researchers who like science or like computer science, but people who are in biology, mathematics. Can you tell me what's going on with the evals in the scientific frontier? Because we're at this point now, it seems like we're going to see meaningful results.
B
Yeah, I think the work in some of our science evals is some of our most exciting. So in the past few months, there's a few tiers of evals that we've made public. So the first tier was this eval called Frontier Science Olympiad, which was kind of the equivalent to the math Olympiad style evals that we had before, where we were measuring how well the models could do on high school Olympiad style problems in biology, chemistry and physics. And they were sort of shorter answer, but still quite hard. And the models weren't very good yet. And then the next phase we did was Frontier science research, which is also public and people can run this, which measured how well models could help complete sort of unfinished biology, chemistry and physics theses. So we had people who were PhDs or professors in these fields that had some text that was not published, like maybe part of their thesis, and just turned that into an evaluation where the model was given maybe some input data or some initial starting point and it had to sort of see how it'd fill out the rest of that paper and judge against a rubric for how well it did. And that was starting to measure. Okay, are the models starting to do research, Are they using tools, this sort of thing? And then one of the final iterations of this was to see how well the model could do in the real world in a wet lab. And so we worked with this company called Ginkgo Bioworks that has a bunch of really cool automated wet lab robots where the model had to optimize this protocol for protein synthesis. And the idea was the model would generate a protocol and then they would actually automatically test it in the wet lab or they would put in the reagents the model suggested and then see what protein yield they got. And this was for a protein that's sort of related to this ovarian cancer drug, or it's like sort of a toy scenario for that. And the model, we were really nervous at first because we were like, this human baseline is kind of hard. We don't know if the model is going to beat it. But we should never underestimate the models because the curve is pretty clear. Just every cycle got better and better. Beat the human baseline and then set the state of the art on how efficiently the model could cost per yield generate this protein. And I think that's just the start of how if we give these models optimization problems like go try to figure out how inexpensive you can make this vaccine or generate synthesize this protein that's important for a drug, the model can just go and keep optimizing these protocols with real world inputs. And it was one of our first time de risking an eval that's actually connected to the real world. We weren't waiting for a piece of code to run. We were waiting for the robot to finish the experiment so we could record how much protein was synthesized. And yeah, I just think the models are going to do so much science for us. It's going to be really interesting.
A
And that was exciting because that was just like, I think GPT5 and it hadn't gone through any sort of here's how to be a scientist. And now these models have progressed a lot since then. You have a lot more real world experience with this.
B
Yeah, that wasn't even with one of our best models. It was just an early reasoning model. And so I think, yeah, all of these things stack, we'll have better pre training, we have better RL and post training and we're going to get a lot better at using these models at test time to really elicit their capabilities. And I think the next generation of evals is really about how can we have these models take actions in the real world and solve sort of unsolved problems for us that would take humans a long time. Some of these scientific problems that we haven't been able to put enough effort against, it's like, well, now we have all of These agents that can spend compute to solve problems for us and try to steer them towards what would be useful.
A
It does seem like that brings in a new challenge, though. Do you think that evals are going to be a lot more complex?
B
Yeah, I mean, we have the saying on our team that pain is the moat. I really think a lot of operations in the physical world will become part of the bottlenecks in being able to measure what the models can do. Because even just starting with digital, there's so much more scaffolding and infrastructure work we need to do to run these. Now, if you want to test how well Codex does, it's like, well, the model is calling APIs. It's like taking actions on your computer and in your browser. It's making artifacts for you. It's writing and running and executing that code. It's just so much more complex to measure that model. And that's only digital. Now, if you want to measure how the model could interact with the physical world, there's all sorts of ops and logistics that you need to have a really smooth process for to see how you can deploy these things at scale. I think a lot of the work is actually shifting from being theory or math or even programming. I feel like people don't program that much. They just ask codecs and more shifting towards planning, operations, physical stuff, or at least my job has shifted a lot that way. And those things are very hard. It's actually kind of easy to just write something in a corner. It's a lot harder when you have to manage all of these operations and logistics.
A
It's exciting, but it seems like part of the challenge is these aren't just simple evals anymore. They take more compute, they take more time. When you're trying to do a long horizon eval, it's long. You have to wait a long time to get the outcome on that.
B
Yeah, definitely. So it's both a lot more work to come up with the evals and run them at scale. And also if the work takes a longer amount of time, we don't get the signal as fast. So we have to invest more in scaling laws where we can predict. Okay, well, if by one day the model looks like this, then we can forecast that at seven days it would look like this and sort of come up with trends that we can so that we can get signal faster. Otherwise we're just like stuck there waiting for a week to get an update, which is not the most productive way to spend time.
A
I have certain benchmarks and things I use to test Every time a new model comes out to find out how it's personally useful to me. And it's one of the things I tell people who run businesses or other things is think about your own evals, things that will tell you where something is. Because sometimes people might try something, they might try ChatGPT six months ago and go like, eh, it wasn't good. It didn't do this. They don't realize how fast things move. Do you have any advice for people on how to figure out how to come up with a benchmark?
B
Yeah, I mean if things move really fast, things change every couple of weeks and I feel like people are not as awake about. In my job, I'm one of the first people in the world to see some of the most powerful models. So I'm extremely AGI built and I think progress is happening a lot.
A
What have you seen?
B
What have I seen? I've seen good models, Nia. Yeah, but progress is happening a lot faster than people would think. And I think the best eval, honestly is just to dog food or use the model. People should just try to use the models as much as they can. And even if there are things that they think the model didn't do well one week, they should just try it again the next week it'll probably work.
A
I think that's one of the things that should be obvious to people kind of outside AI is how really good frontier AI companies are using these tools internally. And that's why things are speeding up and getting more capable.
B
Yeah, I basically try to have the model take a first pass of everything that I do, whether it's sending a slack message, understanding what experiment to perform next, any management stuff, ops, logistics. You have the model take a first pass and then if the model's not good, we figure out how to put that in the eval.
A
I'm excited about the computer using evals. Just watching the performance of codecs with computer use, it's just light years over where it was just maybe eight months ago. And it seems like those things are just going to get faster and better. My prediction is probably by the end of the year that'll use my computer better and faster than I do.
B
Yeah. Yes, I think so. The models have some advantages over you. Right. Like they can call a connector or plug in, which is a much faster mode of communication than you on your computer. Having to go click into a service and understand every page and then copy some data back and forth. Or even writing, writing some service to call that API or MCP or whatever it's like more work for the human for the model. So the model has that advantage and the models can just be faster if it's trained to navigate a browser or desktop, whether it's through Accessibility Tree or through code. So the models have an advantage over us. I think for a long time there was really no product deployment that was very effective. We launched operator and ChatGPT agent a while ago and those were really useful for showing this could be possible. But the latency on those models was just too high. They were just super slow and I don't think people use them at super high scale yet. But we've now reached sort of a tipping point where doing things like asking the model to read my slack for me or go schedule a bunch of calendar invites and optimize the rooms is faster for me than it would have been to do it myself. And I think people are not ready. Also a lot of people haven't tried this stuff out because it's all launched so recently. But everyone should go get the computer, use plugins and use those and install all of the plugins and all the good connectors that will make things faster. Then you'll be mind blown.
A
Let's talk about Frontier evals.
B
Yeah. So the goal of the Frontier Evals team is really to measure and forecast progress of the frontier models at OpenAI to better understand where we are, where we're going and try to share that with the world. And one of the things I think the team has tried to do is to help publish and open source as much that we can. So some evals that we've helped Open source include SwedBenchVerified, which helped measure progress on coding Mlebench, which was a way to measure how well models could train other models and track the progress of machine learning engineering skills in our models paper Bench, which was a way to measure how well models could replicate real top machine learning papers from ICML or iclear and gdpval, which helped measure how well models could perform on real world tasks across over 40 occupations. And the goal for all of these has been the models might not seem good now, but if you just plot how they increase with each, the results improve with each model generation. Often when people say oh well I expect this will take a year or whatever they over expect in terms of how much time it will take to saturate a benchmark. And even my own or people on my team's predictions are often not ambitious enough for how fast things will change. And so I just think we're trying to do our service in helping inform the world about what is possible. I think some of these research acceleration evals in particular are quite interesting. When we first started, we had this eval called the OpenAI Research Interview Eval, which was just taking the researcher questions that we asked people applying to OpenAI and putting those in an epal. And the model blasted through that pretty quickly. It definitely can pass our interviews right now, which I think has caused a whole other slew of downstream questions on how do we make sure people don't cheat on the interviews and how do we actually measure research talent. But I think all of this is very useful because measuring internal progress, it's kind of a way to measure the lever by which the models will keep getting better, faster, the acceleration of the slope of improvement, so to speak. And yeah, I think having ways to measure model progress is just good information.
A
I've heard that in some of the evals that were out there for a while that it turned out that there were actually errors in the questions. That that was an issue with some of the evals. That was some of the publicly available ones were actually, you couldn't score above a certain level. And if you did, it was actually because you were training on the data. And people looked at that and found out like, oh, actually this is not the right answer.
B
Yeah, this is a problem with a lot of public benchmarks. So the original reason for Sweebench Verified was because we wanted to run Sweebench. And it was half the problems were either broken or under specified. And people in the industry were publishing results on this as some metric of how well you did. And we were like, well, we should at least try to fix it and then share that so we can have a better yardstick. But I think one of the reasons that public benchmarks maybe aren't always as battle tested as we'd like is that they tend to be. Someone in a lab, like an academic lab, had a good idea and wanted to write a paper, but they never had to run that eval at scale in production training run or production level eval sweep for a launch. And just when you run some of this stuff at scale, it breaks or falls over and you catch all of these bugs. I think sitting in a lab and being closer to product is a forcing function for making sure the quality of your measurements is really high. Because we're not doing this look good in a paper, we're doing this. It has to work because it has to work for our systems at scale. So it kind of forces the quality to be high.
A
It seems like one of the things that can happen is these models become incredibly capable. Sometimes they're very good at. Sometimes they can solve a problem that they'll take sort of the laziest path, and they can give you the memorized answer instead of solving it. And we saw that with counting and how many words are in it, how many letters in a character and a word or whatever. And it was often the model, if you prompt it right, it would get the answer right, but if you didn't prompt it the right way, it would just sort of throw you an answer.
B
Yeah, that brings up all sorts of interesting concepts. I mean, so there's this one concept of memorization, which is the idea that the model literally knows the answer and doesn't have to really think or reason to solve. It's just like regurgitating something it already knows. And that makes the measurement not super useful because you're just measuring whether you happen to have trained on that data a ton versus whether the model learned the skill or tool or capability you were trying to measure. So that's one way to avoid that is to try to be really clean and disciplined about your data, not including any benchmarks or any evals that you want to measure. And that helps solve sort of the first problem that you laid out. So that's one thing. And then there's this other thing where the model can kind of reward, hack, or sometimes cheat to solve an eval. And that's very much a question of having clean eval design where you sort of test these at scale, see if there's any hacks, make sure those environments that you're testing don't have the hacks as something that's possible for the model to do. And that just requires a lot of quality control to make sure the eval is not overly hackable. Yeah, yeah.
A
Because it seems like there were some very simple ones like grade school math and whatnot. That models, if you just change it a little bit, some of the early models would get confused and give you the wrong answer that was actually capable of solving it, but it just goes, oh, this one. I got it. And then that's happened too. Should I drive my car to the car wash problem?
B
Yeah. So the models can get tricked. To me, the model, if it didn't do well on that, it should have been smarter. We should also have the models be a bit more robust to being tricked. But this also relates to this idea of capability elicitation, or trying to measure the models in the best way, which is Especially important for our safety testing. For example, if you want to measure how well the model can find vulnerabilities or do some of the cybersecurity stuff, you want to make sure the model is not just getting tricked by the problem, that you really measured the true capability. So there's a lot of prompt tuning and changing the harness and sometimes even doing a fine tune to get the model maximally ready to solve that challenge that we do to make sure if we say, oh, the model's not good at some very risky capability, we can be a bit more sure before we say that.
A
When I was a kid, I loved reading these Encyclopedia Brown stories, these little mysteries, and you had to solve them. And with GPT4, I would write custom ones for it just in case somebody had like tipped all these answers to it out there. But that was a pain to kind of do that. And it's exciting to think now I can have a model write something, I come up with some new eval. So how helpful have the models been now for.
B
Yeah, they're semi useful.
A
Yeah. Okay.
B
I think we're in this phase of model development where sometimes the outputs are still kind of sloppy. They require human QC or oversight to make sure the quality is still high and we're not getting tricked. I would say people sometimes are surprised that we still have a lot of human intervention and involvement in the evals, just because that's something. Evals can be a lower end than training data. And you want to make sure every single point that you're testing, every data point, is very high quality. And so this is one of the areas where human touch can be quite nice.
A
We're seeing some interesting trends where jobs that actually touch AI seem to be more in demand because it's made people more productive. How are you tracking this? How do you look for areas where you think this is going to have an impact?
B
Yeah, these are very difficult questions. I think people are not calibrated to how much work our models will be able to do and how quickly across a wide variety of jobs. Right now, the models are still mostly just good at tasks versus a job. There's a lot to a job than a task. You have to figure out what you want to work on, navigate ambiguity. You might have coworkers that you're collaborating with and communicating with, and then you might figure out what task you want to do and then give that to a model. And that's kind of the phase we're at now where it's a lot of. I mean, even in my job the model is doing individual tasks for me, but I'm still doing a lot of the thinking and planning and that sort of thing. And I think people aren't even calibrated to that. I feel like people in software and research are a lot more calibrated or by calibrated I mean realize how capable the models are compared to some of my friends in other industries. And I wish people just tried the models more and saw because the people who try and see first, they'll start to really get it. But I also think the models are going to start to be able to do the stuff like the delegating part at some point too, maybe not too far from now, figuring out what to work on, navigating ambiguity, writing the spec that the model then executes on. And people should really start to think about, okay, what happens in the maximally AGI pilled world where even just for digital work, the model can come up with what to do, do it, execute it on it, interact with the real world. There's entire businesses that now you see stories of unicorns where it was mostly AI and a few employees that were able to drive all of this value. And so I do think there's this question of are we realizing how big this might be?
A
Personally, I think the opportunity space is getting bigger. Everybody I know, the most AGI pilled people I know, the people who are using tools like Codex all the time are doing way more now. They're more productive now because they don't have to do the tasks. And the jobs is the AI gets better at handing certain jobs like, cool, there are five jobs I need done now because I can do more. And I think that we just think about the light cone of the potential where we can be is bigger than we can imagine. And I think these tools just help us get there faster, not narrow it.
B
I think it's probably some mix of things.
A
Yeah.
B
Even if you have models that can speed up paperwork, like think about like, like a clinical trial for a drug, right? It's like people spend months putting together all this paperwork, hundreds of pages of why they should be able to do the trial and they submit it to the FDA and then there's a 35% chance it got rejected because they made a mistake or forgot something. They revise, then finally you can do the trial. And these processes are good, but it just takes a long time. Then the trial is you have a case in a control or whatever and you're documenting symptoms and tracking these for just documenting what happens for a long time. And then doing a bunch of data analysis. Like a lot of this is just documentation or data analysis or sort of like very classically digital work. And I think if models can help accelerate all parts of this for health, for energy, manufacturing, policy, research, education, this will be very accelerative. We will have hopefully faster, cheaper, better goods. And that's really good for people. It's very good for the individual consumer. So I think that is something people should be excited about, but we should be very thoughtful about how to navigate the transition to that world in a way that's thoughtful and responsible.
A
Excellent. Thank you, Jaejo.
B
Thank you for having me.
Episode 21 – June 16, 2026
Host: Andrew Mayne
Guest: Tejal Patwardhan, Research Lead at OpenAI
In this episode, Andrew Mayne sits down with Tejal Patwardhan, research lead at OpenAI’s Preparedness team, to discuss how evaluation (“evals”) of AI models is evolving rapidly. The conversation covers the transition from classic academic benchmarks to more realistic, frontier-facing evaluations, the surprising pace of AI progress, and how the models are already transforming scientific research and professional work. The tone is candid, future-focused, and occasionally incredulous at how quickly models are advancing and how public understanding often lags behind.
“It felt like a lot of my friends…didn’t really understand how powerful these models would soon become…That’s now. But the question is the slope.”
– Tejal [02:15]
“If I look at our research roadmap now, I see no signs of stopping. Things are just going to keep getting better. This is going to be a really crazy year.”
– Tejal [08:08]
“Math is more like the proof point versus the end goal.”
– Tejal [04:44]
“The model found this security vulnerability…and it broke out. We were all like, oh no, what else has the model done if it did this? It was kind of a feel the AGI moment.”
– Tejal [06:42]
“Once a benchmark is saturated, it's not super useful…So the challenge is always to make more and more difficult, realistic, unsaturated benchmarks.”
– Tejal [14:11]
“Generally, bad benchmaxing is bad…We want to make a model that's useful to push forward the frontier of science or work.”
– Tejal [12:51]
“The best eval, honestly, is just to dogfood or use the model…Even if there are things that they think the model didn’t do well one week, they should just try it again the next week—it’ll probably work.”
– Tejal [30:50]
“The paradigm of doing things in text and code is just completely blown away if there’s a voice interaction in real time.”
– Tejal [20:41]
“We were really nervous at first because we were like, this human baseline is kind of hard. We don’t know if the model is going to beat it. But we should never underestimate the models…the curve is pretty clear. Every cycle got better and better.”
– Tejal [26:31]
“Pain is the moat. A lot of operations in the physical world will become part of the bottlenecks in measuring what models can do.”
– Tejal [28:21]
“If models can help accelerate all parts of this for health, for energy, manufacturing, policy, research, education, this will be very accelerative…That is something people should be excited about, but we should be very thoughtful about how to navigate the transition.”
– Tejal [43:09]
Capability Forecasting:
“There’s this term called capability overhang, which is this idea that the models will be capable of things long before people actually adopt them...”
– Tejal [01:38]
Feel the AGI:
“I said at the beginning we thought we had AGI in six months when some of the early runs were happening.”
– Tejal [06:35]
Models Overhyped/Underhyped:
“I know it might seem like the researchers are trying to overhype the model or something, but if anything, I think we're underhyping the power of them.”
– Tejal [08:52]
The Reality of Evolving Evals:
“We were really having this crisis of evals where we kept training successively better models…We were like, man, we have no idea how to measure what people actually want to use our models for.”
– Tejal [15:13]
On Model Use:
“I basically try to have the model take a first pass of everything that I do, whether it’s sending a slack message, understanding what experiment to perform next, any management stuff, ops, logistics. You have the model take a first pass and then if the model’s not good, we figure out how to put that in the eval.”
– Tejal [31:25]
Frontier Science:
“The models are going to do so much science for us. It's going to be really interesting.”
– Tejal [27:18]
| Segment | Timestamp | |-------------------------------------------|-------------| | Tejal’s background & joining OpenAI | 00:50-02:15 | | The idea of 'capability overhang' | 01:38-03:10 | | Reasoning jumps, paradigm shifts (O1) | 06:14-07:51 | | Dangers of saturated/obsolete benchmarks | 14:11-15:53 | | Real-world professional evals (gdpval) | 15:53-17:16 | | Challenges with multimodal evaluation | 20:41-22:15 | | Scientific research & wet lab evals | 24:55-28:15 | | Increasing complexity of agent evals | 28:21-29:44 | | AGI Index & internal tracking | 23:36-24:32 | | Handling memorization and “cheating” | 37:10-39:41 | | Models accelerating jobs and productivity | 40:40-44:19 |
For listeners, this conversation is a powerful window into the ever-accelerating world of AI model evaluation—and a strong case for never underestimating the models.