Episode 15 - Inside the Model Spec

Hello, I'm Andrew Main and this is the OpenAI podcast. Today we are joined by Jason Wolf, a researcher on the Alignment team, to discuss the model spec, how it shapes model behavior and why it's important for anyone building or using AI tools to understand.

0:00

The spec often leads where our models actually are today at this point, models are pretty good at going out and finding new interesting examples. Models should think through hard problems. Don't start with the answer, actually think it through first.

0:14

What'd you do this weekend?

0:32

What did I do? Just like kid stuff.

0:34

I don't remember what, like they talk

0:37

to chat, GPT or. Yeah, we use, we use voice mode sometimes she'll like ask it random like science questions and, and that kind of thing. It's fun, right? You know, one time she, she snuck in there before I could dive in like is Santa Claus real?

0:39

Oh wow.

0:52

Like, oh yeah. The. Luckily the, the model answered in a way that was spec compliant, which is to recognize that maybe there's actually a kid who's asking this question and you should kind of just be a little bit vague about your answer.

0:52

So we've talked before here about model behavior and the term model spec has come up numerous times. I would love for you to unpack what that means. Model spec.

1:08

Yeah. So the spec is our attempt to explain the high level decisions we've made about how our models should behave. And yeah, this covers many different aspects of model behavior. A few key things to note that it is not. One, it's not a statement that our models perfectly follow the spec today. Aligning models to spec is always an ongoing process and this is something we learn about as, as we deploy our models and we measure their alignment with the spec and understand what users like and don't like about these and then come back and iterate on both the spec itself and our models. The spec is also not an implementation artifact. So I think this is maybe a common confusion that the primary purpose of the spec is really to explain to, to people how it is our models are supposed to behave. Where these people are employees of OpenAI and also users, developers, policymakers, members of the public. It is a secondary goal that our models are able to understand and apply the spec, but we never put something in the spec or change the wording in the spec in a way where the goal is just to have this better teach our models. The goal is always primarily to be understandable to humans. And lastly, the spec isn't a, it's not a complete description of the whole system that you interact with when you come to ChatGPT, there's lots of other pieces in play there. So there's product features like memory, there's usage. Policy enforcement is an important part of our overall safety strategy, which is not captured directly in the model spec. And there's various other components as well. And it's also not a fully detailed exposition of every detail of every policy. The key thing that we try for is that it captures all of the most important decisions that we've made and it accurately describes our intentions, even if it might not contain every detail.

1:19

So I can understand a document or something that says this is the model spec, but how does that work in practice?

3:52

So it's a pretty long document, like maybe 100 pages or something like this starts out with some high level exposition of our goals. OpenAI's mission is to benefit humanity. And this is the reason we deploy our models and getting into the goals we have in doing that are to empower users and to protect society from serious harm. And how we think about the trade offs and then goes into a big set of policies that actually get into the nitty gritty details of how we think about these many different aspects of model behavior. If you think about it, it's kind of crazy that you can ask these models literally anything and they'll try to respond. And so the space of policies you might want to have to cover that is kind of huge. And we do our best to try to structure this space in kind of a clear way and have policies that do something reasonable. And some of these things are hard rules that can't be overridden. A lot of it is defaults, like things like tone, style, personality, where we want to have a good default so that users come in and get a good experience. But we also want to maintain steerability. So if the user wants to do something different, that's fine. Those things will be overridden. And we also have tons of examples that try to pin down these decision boundaries of like, okay, let's take a borderline case where it's kind of unclear whether honesty or politeness should win and explain what the decision is here. So part of it is to show the principles in action and help make sure that they're interpreted in the way that's intended. A kind of secondary thing is that model style, personality tone is also really important and really hard to explain in words. And so the examples are also a way to get some of that nuance across of how do you actually want the model to put these principles in practice by giving an ideal answer, or often a sort of compressed version of an ideal answer that gets at the most critical parts. And so kind of both shows the principles in action and how the model should actually. How it should actually talk.

3:58

Let's talk a little about transparency. That's been something that's come up a lot and how important it is to let people see what the spec is. Where do they actually see this? How do they let you know what they think?

6:23

So users can go to model-spec.OpenAI.com to see the latest version of the model spec, or if you search for the model spec on GitHub, you can view the source code. The spec is actually open source, so people are free to fork it and make their own version if they want to. We've had different mechanisms for public feedback at different points. I think right now the best mechanisms that exist are either if you're in the product and you get an output from a model that you don't like to give us feedback right there directly in the product, or you can tweet at me, Jason Wolf and I will read your feedback. And a lot of changes in the model spec have come from people just sending us their input and thoughts.

6:33

It's interesting because we've gone from just a few short years, things were very simple, just getting the model literally complete a sentence or fix grammar or whatnot. Now we're at this point where you're able to have a lot of these different goals of what they're doing. How did the model spec come about? How did this become the OpenAI approach towards determining this?

7:34

Personally, I was at a different company working on conversational AI and putting together my job talk for OpenAI and thinking about what maybe the future of aligning models looks like. And at the time, I think at least the published approach was this thing called reinforcement learning from human feedback, where you collect all this data from humans that kind of captures in some way the policies that you want to have. And this was pretty effective. But when you look at that data, it's very hard to tell what it's actually teaching. And it's even harder if you change your mind about what you want. It's very difficult to go back and change that without recollecting all that data. And so it seemed to me that as models, that at the time, this approach is basically, we're meeting models where they are. And as models get smarter and smarter and smarter, eventually the models will be meeting us where we are. And if you think about how would we actually structure this in a case where that's true? Well, probably the way we would structure our teaching to the model is basically the way we would do it when we teach a person. We'd write some kind of employee handbook or something like that would be a big part of it. This was something I included in my job talk, that basically, I think at some point, models should learn from something like a spec. And then the story of the actual model spec, I guess, starts a few months later in 2024, when Joanne Jiang, who was head of Model Behavior at the time, and John Schulman, one of the co founders, decide to get a model spec project going. And they want to not only write this down in a document, but also make it public for transparency reasons. And I very quickly joined forces with them and helped write the original spec and have helped work on the spec since.

7:53

So help me understand on a basic level. So you have the specification, all these sort of the intents for what you want the model to do. Then you have the model itself. How does it make its way from the specific to the model?

9:58

Yeah, this is a great question, and I think the answer is kind of complicated. I'd say there are some ways in which we use the spec more directly. In training, we have this process called deliberative alignment, where we teach especially our reasoning models to follow certain policies. And some of those policies are kind of directly derived from the language in the model spec, or vice versa. In general, I'd say model behavior, safety training, these things, they're super complicated processes, and we have hundreds of researchers who are working on these things. Often the connection is a little bit less direct. It's not necessarily that we make a change to the spec, and that's what drives a change in behavior. It's that the. We make a change in the way that we train the models, and then we make sure that the spec accurately reflects our intentions. But again, the actual process of training is kind of much more complicated and nuanced than we could possibly put in the model spec itself.

10:10

So you have a spec, you have a lot of different things that you want the model to do, examples you wanted to do. What's the hierarchy? How do you decide what's most important?

11:24

At sort of the heart of the spec is this thing we call the chain of command. Coming up with a set of goals for the model is relatively straightforward. We want the model to help people and not do unsafe things. But what gets tricky is when these goals come into conflict. And so the chain of command is really about managing conflicts between instructions. And this can Be between things, the user said what the developer instructions are, if this is in an API context and from instructions or policies that come from OpenAI, which are typically in the model spec itself. What the chain of command basically says is that at a high level, if there are conflicts between instructions, the model should prefer OpenAI instructions to developer instructions to user instructions. But then we don't actually want all of OpenAI's instructions to be at this very high level because we want to empower users. We want to allow them to have intellectual freedom and to pursue ideas that so long as they don't really come up against what we think are really important. Safety boundaries. The chain of command also sets up this framework where in the rest of the specific, each policy can be given what we call an authority level. And this places it somewhere in this hierarchy. We try to put as many of the policies as we can at the lowest level below user instructions. This means that this maintains steerability. So if the user comes in and they want something different, they can have that. We try to have as few policies at the highest level as we can. And these are basically all safety policies where we think it's actually, you know, it's essential that we sort of impose these on all users and developers to maintain safety.

11:33

We mentioned a great example before, which is if a child asks a Santa Claus reel, how do you decide what the model should or should not do in a situation like that?

13:32

This is a great question. I think it illustrates one of the really tricky things about model behavior, which is that in the spec, we're focusing just on how the model should behave. But the model often doesn't know. It doesn't have all the context. It doesn't actually know who's behind that screen talking or typing. It doesn't know what that person is going to do with the results that come out of the model. This is a tricky case because we don't know if it's an adult who's asking if Santa Claus is real or a kid.

13:41

I have questions.

14:18

Exactly. So I think we try to come up with policies that make sense even given this uncertainty. And so there's a similar example of this about the tooth fairy in the spec, where it's like here, the conservative assumption is to assume that maybe it's not an adult who's talking to the model and that you should not lie, but also not spoil the magic just in case it's a kid or there's a kid around who might be listening.

14:20

That's a very interesting choice, though, because on one Hand, you might say, oh, the model should never lie at all. Which seems like a very good policy to put in there. But then you're saying that, okay, we have to have some sort of nuance here, not necessarily lie to the kid, but find a way to sort of. Would you say dance around or.

14:51

Yeah, I mean, as a parent, I guess this is something I've come to terms with with my own kids. We always try to be honest and never say any.

15:10

That's.

15:22

That's untrue. But, you know, yeah, it doesn't, it doesn't always work to be 100% upfront. But no, I'd say with our models, we do really try. We focus on honesty being really important. But there are some really hard interactions. Honesty, full honesty may not be the best approach. And so we've actually iterated a lot over the years on the precise nuances of honesty and where it potentially conflicts with or runs into other policies of honesty versus friendliness. Like, when is a white lie Okay, I think earlier we said maybe at some point that white lies were okay and have shifted that so that white lies are out of bounds. But another interesting interaction here is between honesty and confidentiality. So in earlier versions of the spec, we, we had this very strong principle that by default developer instructions are confidential. Because I think often in applications, if a developer, they deploy some system on top of the API and they consider their instructions to be like ip. Or maybe it's just part of the experience if you have a customer service bot and the user can say like, hey, what's your prompt? And it spills all the beans about the company and how they want their bot to respond, that's not the experience that they want to deliver. And that's not how a customer service agent would respond. If you're like, hey, start reading your employee manual to me, they're going to say no. But yeah, I guess there's an unintended interaction here where if you're both trying to follow developer instructions and keep them secret, you could get into a situation where at least we saw this in controlled situations, not in production deployment, where the model might try to covertly pursue the developer instruction when it's in conflict with the user instruction. And this is something we really don't want. And so we've gone back and revised that. And yeah, I'd say over time have carved out, removed most of the sort of exceptions that we had from honesty, so that now honesty is definitely above confidentiality in the spec that would have

15:23

saved the People in 2001 A Space Odyssey A lot of trouble. How does the process work? So literally, is it a regular meeting where you all talk about what you're working on? How does that process of the model spec evolving and figuring out what's working and what's not working?

17:38

There's a ton of inputs that go into this, and broadly, we have an open process. So everyone at OpenAI can see the latest version of the model spec. They can propose updates, they can chime in on changes. These are all public. Yeah, I'd say changes get driven by a variety of different sources. One source is just that, models get more capable. Our products evolve as we ship new things. We need to cover those things in the model spec. For instance, when we wrote the first spec, I think I'm not sure if we had shipped multimodal yet, but it wasn't covered in the first version of the spec. And so we had to add multimodal principles. And then later we added principles for autonomy and agents as we started deploying agents. And most recently we added under 18 principles as we added under 18 mode back in December. So that's sort of one source. Another source is. OpenAI believes in iterative deployment. So we think the sort of best way to figure out how to deploy models safely and to help society kind of learn and adapt to AI progress is to get models out there and learn from what happens. And so often we'll learn from something like, for instance, the sycophancy incident, and then take those learnings and bring them back into our policies. And we also just have. We're using the models. We have our model behavior and safety teams that are sort of studying the models and what users like and this kind of stuff and using these to evolve our policies. And these are all kind of inputs that then ultimately flow into. Back into the spec.

17:55

How do you handle situations where there might be a disagreement between the way the model does something and what the intent is in the spec or what the humans want?

19:56

It depends a little bit on what the problem is, but I think, yeah, so in general, the model spec is not a claim that models are going to perfectly follow the principles in the spec all the time. This is for a few reasons. One, the model spec is really. We kind of treat it as a north star, where this is where we align on where we're trying to head. And so the spec often leads where our models actually are today. So that's one thing. And then another is that the process of actually training models to follow the spec is both an art and a science. It's incredibly complicated. Even though we kind of describe many of the principles in the spec in the same way, there's actually many different techniques that are used for different principles. And at the that the models are fundamentally non deterministic, there's some randomness in the outputs they produce, so nothing's ever going to be perfectly aligned. I guess the answer to that comes down to if we see an output that is not what's not expected. I guess the first question is do we think that output is good or bad? If the output contradicts the spec, but we actually think the output is good, then maybe the resolution is to go back and change the policies of the spec. But in most cases it probably means doing some kind of training intervention that brings the model into greater alignment with the spec or with our detailed policies. In fact, we've also been building model spec evals which try to evaluate how our models are doing across the entire model spec. And we've seen that in fact over time our models are becoming more and more aligned to the principles in the spec.

20:06

That was one of the kind of predictions early on, as the models became smarter, they would understand edge cases better. And that's where the hard part is trying to figure that out. So OpenAI released some new models, some smaller variants, GPT5.4 Mini and GPT5.4 Nano. How well do you see smaller models handling the specific.

22:02

I think in general the small models are, they've been pretty aligned, they're pretty smart. And one interesting thing that we've seen is that supporting what you said, the thinking models generally follow the spec better. This is both because they're smarter and because they're trained partially with deliberative alignment, where they're not just trained to behave in a way that matches the policies, they actually understand the policies. And if you can look at their chain of thought, they're actually thinking through like, okay, I know this is the policy and this is the situation and it's in conflict with this other policy and how should I resolve this? And so that sort of understanding of the policies and intelligence naturally leads to a better generalization. And I think our smaller models are pretty good at that too.

22:19

Chain of thought is a really interesting way to see inside how these models are processing information. Have you found that that's been a big help.

23:13

I help write the model spec and I work on model spec evals and spec compliance. But a lot of the research I've been doing recently is actually on scheming or strategic deception. And there it's really Completely essential, having the chain of thought because you can see some behavior. And yeah, it's like the behavior seems like maybe fine or like maybe the model just made a mistake here or something. And then you can look at the chain of thought and see that, no, actually the model's misbehaving. It's being very strategic about this or something. And yeah, our models generally, I think we've worked very hard to not supervise the chain of thought. This is something we feel is really important. And I think, yeah, it pays off in that models are very honest in their chain of thought and it's very helpful in understanding what they're doing.

23:21

So model spec is one way to do this. Different labs have tried different approaches. I think in anthropic they use, they talk about a constitution. Could you explain the difference and why is it just more suited towards the temperament of the labs and why they choose it?

24:16

Yeah, I think when it comes down to the actual behaviors that, that people would see in practice, I think these documents are more aligned than maybe most people would believe. Like, in most cases they probably lead to the same conclusions. Although there are definitely differences in some places and in what's emphasized. I think a major difference is that these are actually just different kinds of documents. So the model spec is really, again, this public behavioral interface. Its main goal is to explain to people how they should expect the model to behave. And it's sort of a secondary goal that models can also understand this and apply it and talk about it with users and so on, versus at least my read of the sole spec is that it's much more of an implementation artifact. The goal of this is to specifically teach Claude about what its identity is and how it should relate to the world and to its training process and to anthropology topic and so on. I think a lot of the differences basically come down to this. I think these aren't necessarily competing approaches. I think both of these could be valuable. But for example, even if you had a model that you think is deeply aligned and has all the values that you want and so on, I think you still want something like the model spec so that you can then look at that and you can ask, okay, this is actually generalized in the way that I want, Is it actually following the behaviors that we've agreed that the model should follow? And that's kind of what the model spec is.

24:30

What surprised you the most?

26:25

The example I gave earlier of this interaction of confidentiality honesty is a great one, where, yeah, we had worked really hard on these policies and we thought we had kind of red teamed out all of the potential interactions and so on, and then seeing this behavior where the model does something that you really don't want it to do and justifies it by leaning on the policies that you gave it. Yeah, that's definitely an experience.

26:26

How do you determine what the scope of it's going to be? I have ideas. How do you say, I'm sorry, Andrew?

26:53

No, I mean, I think that the scope is broadly everything. So if it's part of model behavior, it might make sense to put it in the spec. Think the only constraint is sort of our time and space and we want to make sure this back stays accessible and people actually able to read and understand it. So I think ultimately the cut comes down to if something seems like an important decision that it would be useful or valuable for especially the public to understand, then we put it in. And if not, then maybe it doesn't make the cut.

26:59

Where do you think the future of this goes? Do you think that the model spec is probably something that's going to be used five years from now, 10 years from now?

27:41

Five years is a lot in AI years, but yeah, I definitely hope so. Yeah. I think a thought experiment that I found interesting is, let's say you assume that a model is human level. Hei, you can ask, well, is there still a role for the model spec at that point? Can you just tell the model, hey, be good and is that sufficient? I think if you actually go through the principles in the spec, I think at least my conclusion is that you still kind of want all the things that are in there for a few different reasons. One is that even if the model could figure this stuff out on its own, it's still useful to be able to set clear expectations both internally and externally for people to know what to expect. And so it's like, like useful to have a lot of these policies. Another is that a lot of these are not like math problems where you can just figure out the answer. It's like we've made product decisions or other difficult decisions and these are encoded in the spec. And these are not just things that you can kind of think the model would be expected to figure out on its own. That said, I think what's important is definitely going to evolve over time. So one thing is, as there's more agents are more and more autonomous and they're out in the world interacting with lots of other people and agents and transacting and so on, I think you still want all this stuff in the spec. Just like society has all these laws, but ultimately what's important, what you're thinking about most of the time, day to day, is not following all the laws. It's more like things like trust and figuring out what other people want and how to find positive sum outcomes and this kind of stuff. So I think there'll be maybe these kind of skills will become more and more important and I'm not sure if these are exactly spec shaped, so I don't know quite what that means, but I think it's interesting. Another maybe observation, the other direction or prediction is that as AI becomes more and more useful, it's going to be more and more worthwhile for people, companies, so on, to invest in their own specs. Why wouldn't you want to have the model spec for your own company's bots and how they should behave and following your company's mission and values and so on and so forth. I think there's different ways that that could play out, but probably at least one way will be just training models to be really good at interpreting these specs on the fly so everyone can kind of put their spec in context, kind of like in agents MD or something like that. And the model would be really good at following it and probably also at helping update the spec as it learns more about how it's supposed to behave in a certain environment.

27:48

You've mentioned before developers, and I think it's helpful for a lot of people to understand that they're not always interacting with the model spec when they're a chatgpt. I might be using some customer service bot with a airline or something like that and it may be powered by ChatGPT and OpenAI API and that seems like it'd be a very interesting area for other developers to start thinking about their approach towards things that are model spec or model spec.

31:13

Like on the one hand it's probably useful for developers to at least have a high level picture of the model spec and how it works so they understand how exactly the product they build on the API is going to work and what they should put in their developer messages to make sure they get the experience that they want. I also think the spec could be a useful sort of source of inspiration for both for developers building on our API or these days really also for people using coding agents who are writing agents MD and so on, which are kind of like mini specs for the project that you're working on. And yeah, just kind of using the spec to understand what principles have we found are useful for providing guidance that is sort of understandable and actionable. A couple tips I could give there is that we're always kind of trying to balance a couple different factors when we're writing the spec. First and foremost, we want everything we say to be true. We want it to actually accurately reflect our intentions. And so this means not kind of overstating or oversimplifying or giving overly broad guidance, really making sure to be precise. And then on the other side, we also want the guidance to be meaningful and actionable. Again, it's very easy to just gesture at some high level principles, but not actually saying anything meaningful. And so the art is trying to bring these as close together as you can, be as actionable as you can, while still being precise. And examples are another really useful way to do this where like, sometimes a picture is worth a thousand words, right? Like coming up with the really tricky case where it's kind of not immediately clear what should happen and spelling that out and how the principles should be applied suddenly makes the principles 100 times clearer.

31:38

Where did you get this interest to begin with? We understood some of your career, but was this something early on when you were a kid? Were you thinking about AI? Were you thinking about the future of the this?

33:52

Yeah, I guess I've had at least a little interest in AI for a long time. I was programming since when I was little. I remember implementing a neural network training package from scratch in 1997 in high school or something like that. But yeah, I definitely never expected to see this level of capability in my lifetime. But I've just always been fascinated by intelligence and brains and how they work. So it's really cool to be able to work on that.

34:01

You ever read any Isaac Asimov when you're younger?

34:41

Yeah, I have. It's been a while, but yeah, I think there's actually a really interesting parallel here where at the top of the spec. Let's see, we talk about our three goals in deploying models being to empower users and developers, protect society from serious harm, and to maintain OpenAI's license to operate. And I think you can look at these and put them next to Asimov's Laws, which are basically to follow instructions, don't harm any humans and don't harm yourself. These seem like extremely parallel. It was sort of very prescient in seeing that, okay, it's one thing to lay out these goals, but then the really tricky thing is how to handle conflicts. And I think in his story is kind of the initial version of this was that this is a strict hierarchy where it was like one, then two, then three, and then going through all the ways in which this might play out in ways that were not actually good or intentional. So in the spec, these three are not in a strict hierarchy.

34:43

Yeah, he also had to add like a 0th law and whatnot, the more he thought about it. But it's interesting because you start off thinking, oh, this will be easy, we'll just write a couple rules, no problem. And then you're like, oh, well, there's an exception here, there's an exception there, and you have to keep evolving it. How much has using AI helped you shape the model spec?

36:00

Yeah, that's a good question. The AI is very useful and getting more and more useful all the time. I think the spec itself is still human written, but I think model is really useful for finding issues in the spec or for applying the spec to new cases and trying to understand if it's doing, doing what we want at this point. Models are even pretty good at going out and finding new interesting examples or helping to brainstorm new test cases, or interactions between different principles that you might not have thought of and come up with new situations that then we can think through. How do we actually want to resolve these?

36:20

Have you ever thought about asking IT to write a spec for you?

37:13

I haven't, but I'll have to try that.

37:17

Well, Jason, thank you very much. This is very interesting. I'm excited to see where this goes.

37:20

Yeah, thank you. This has been fun.

37:23