What Is a Model? Supermodeling and AI, Episode 1

In the first episode of Supermodeling and AI, Lonnie Chrisman asks a deceptively simple question: what is a model? Starting with balsa-wood airplanes and moving through resistors, mental models, a 1991 neural translation network, and today’s AI models, he shows that every useful model is a purposeful simplification. He then introduces RelayWorks, a fictional software company deciding whether to launch, pilot, or wait on a new AI feature, and four questions you can ask of any model.

Key takeaways

• A model is a purposeful representation that leaves things out so we can do something useful with it.
• A model is not simply true or false; the question is whether it is useful for its purpose and conditions.
• Implicit mental models drive most team decisions; making them explicit lets people inspect and improve them.
• Four questions for any model: What is it for? What does it tell us? Where is the boundary? What did we leave out?

Chapters

• 0:00 Introduction: building model airplanes
• 1:21 Deciding what to leave out
• 2:33 What an old dictionary says about “model”
• 4:15 A working definition of a model
• 5:16 Mental models: crossing the street
• 6:43 Resistors and V = IR
• 8:45 Same airplane, different questions
• 9:47 1991: a robot, a neural network, and translation
• 13:46 What today’s AI models are
• 15:44 RelayWorks: launch, pilot, or wait?
• 18:50 Making the model explicit
• 20:24 Four questions to ask of any model
• 21:56 Try it: frame one of your own decisions
• 24:10 Wrap-up and what’s next

Full transcript

Introduction: building model airplanes

Welcome to this first episode of Supermodeling and AI. I’m excited to kick off the series today with what I think will be a great episode. I’m Lonnie Chrisman. In this series, we’ll be bringing together three powerful disciplines: decision intelligence, modeling, and artificial intelligence. In this new age of AI, I believe modeling is becoming ever more important. And with a combination of these three disciplines, we’re embarking on a new era of supermodeling. And what could be a better place to start than with the question of what exactly is a model?

When I was a kid, I used to build models. And when I said model, there wasn’t much ambiguity about what it meant. I built model airplanes out of balsa wood. I’d build up this delicate skeleton of ribs and spars and cover it with this incredibly thin onion paper and end up with a miniature airplane. It looked like an airplane, but of course it really wasn’t an airplane. There were no passengers, no hydraulics, no radio, no flight attendants serving peanuts. Most of the things in an actual airplane weren’t there. And that wasn’t a defect. That was the whole point, because a good model leaves things out. A lot of things.

Deciding what to leave out

In fact, one of the most important choices we make when we build a model is deciding what not to put in it. The word model means a lot of bewildering things. There’s a model airplane, a weather model, a financial model, the model of an electrical circuit, a business model, a mental model, a decision model, and of course, an AI model. Spend any time around artificial intelligence today and you’ll hear the word constantly. Which model are you using? Is it a better model? Did you train your own model? Does your application support multiple models? Sometimes people even use the word model to mean essentially the entire AI system: the chatbot, the agent, the application, everything.

So what exactly is it that all of these very different things have in common? That’s what I want to talk about today. By the end, I want to give you a very simple way to look at almost anything somebody calls a model and ask: what is this model actually for?

What an old dictionary says about “model”

I have this old dictionary. It’s more than a hundred years old. Out of curiosity, I looked up the word model, and I was struck by the definitions I found. One was essentially the model airplane, meaning a small physical representation of something larger. Another was a person who poses for an artist. What I didn’t find is the meaning that dominates much of my professional life: a conceptual model, a mathematical model, a computational model, a decision model.

Now, an old dictionary isn’t a rigorous history of the English language. An unabridged dictionary leaves things out, too, which, come to think of it, makes it a model of the language. But I became curious, and there really has been an evolution in the way we use the word. The English word goes back centuries and originally centered on things like physical representations, patterns, and designs. Scientists and mathematicians gradually extended the idea to representations that weren’t necessarily physical at all. By the 20th century, the abstract mathematical meaning had become much more recognizable as the meaning we use today.

I think that evolution tells us something important. A model doesn’t have to look like the thing it represents. A model airplane does. An equation doesn’t. But both can be models. So resemblance can’t be the essential idea.

A working definition of a model

So here’s the definition I’d like to use. A model is a purposeful representation of something that leaves out some of its complexity so that we can do something useful with it. There are three pieces of that definition that matter.

First, it’s a representation. It’s standing in for something else: a physical system, a business, a proposed design, a decision, a language, perhaps even our understanding of another person. Second, it’s purposeful. We’re making the representation for some reason: to understand something, to explain something, to predict what might happen, to design something that doesn’t exist yet, or, and this is where we’ll spend a lot of time in this series, to make a decision. And third, it leaves things out. That last part is crucial. The world contains essentially infinite detail. A useful model doesn’t.

Mental models: crossing the street

If you’re thinking, “Well, I’m not a modeler,” I have some bad news for you. You’ve probably been modeling since you woke up this morning. Suppose you’re about to cross the street. A car is coming. You look at the car. You estimate roughly how far away it is, how fast it’s moving, whether it’s accelerating, whether the driver sees you. You don’t solve equations. You don’t create a spreadsheet. But somewhere in your head, you’re making a prediction: if I walk now, will that car reach me before I reach the other side? That’s a model.

And notice what your mental model leaves out. You probably don’t care what color the car is. You don’t care how many cylinders the engine has. You don’t know the driver’s blood pressure. You don’t even know the current price of the car. All those things are part of reality. They’re simply irrelevant to the question you’re trying to answer.

Now imagine that the driver is someone you know. You see your friend sitting there and think, he’ll stop, he always stops for pedestrians. You’ve just added another variable to your model. Not because somebody taught you a formal modeling technique, but because human beings can’t function without models. Mental models are how we make sense of the world. We notice a tiny fraction of what’s around us. We infer relationships. We anticipate what happens next. And then we act. Much of this happens so automatically we don’t even recognize it as modeling.

Resistors and V = IR

For me, the meaning of model changed pretty dramatically as I got older. As a kid, I was also fascinated by electronics. I built circuits. Eventually, I studied electrical engineering at Berkeley, and electrical engineering is full of models.

Here’s a resistor. It’s a physical object. Inside it, at the microscopic level, there are enormously complicated physical processes taking place. But in an ordinary electrical engineering class, we might replace all of that with one little zigzag symbol and one number, R. And then we say V = IR, voltage equals current times resistance. That’s our model, and it’s astonishingly useful.

The equation doesn’t resemble the resistor in the slightest. It doesn’t tell us what color the resistor is. In fact, here are two resistors. Both are 22 kilohms, but they’re different sizes and different colors. They look very different, yet in the circuit they are identified in exactly the same way. The equation doesn’t tell us where the resistor was manufactured. It doesn’t even capture all the electrical behavior of a resistor. Change the temperature enough, push it beyond its operating range, go to sufficiently high frequencies, and that simple model stops being adequate. But within its intended boundary, it’s enormously powerful.

That introduces another important idea. A model isn’t simply true or false. A better question is: is it useful for the purpose and conditions for which we’re using it?

Same airplane, different questions

Consider again a model airplane like the one I used to build as a kid. Suppose I wanted to paint an accurate picture of a Spitfire. A detailed scale model might be extremely useful. But suppose I’m an aeronautical engineer trying to predict lift. Now the paint scheme probably doesn’t matter at all. I might care about the shape of the wing, air density, velocity, the angle of attack.

Now suppose I’m an airline executive trying to decide whether to add a new route from San Francisco to Tokyo. Now the precise shape of the wing may disappear from the model entirely. I care about passenger demand, ticket prices, fuel costs, aircraft availability, and competition. Same airplane, different questions, different models.

That’s why asking whether a model is accurate without asking what it’s for can be misleading. There’s no universally correct amount of detail. The purpose determines the model.

1991: a robot, a neural network, and translation

I’ve actually been building AI models for a long time, and one of my earliest ones illustrates this idea of purpose in a way I didn’t appreciate at the time. Go back to 1991. I was in graduate school at Carnegie Mellon, working in artificial intelligence and machine learning, and what I was really interested in was robotics. For those who are just listening, the screen is showing the actual robot I was working with.

Like all robots, it had a fundamental problem. It could only perceive a tiny fraction of the world around it at any one moment. Imagine a robot moving down a hallway. It sees something, it turns around, now it sees something else. But the first thing hasn’t ceased to exist just because the robot can’t see it anymore. So the robot needs an internal state so it can remember things, but it can’t remember everything. The question I was struggling with was: how can the robot learn what it needs to remember?

Notice how much that sounds like the problem we’ve been discussing. Reality contains vastly more information than the model can retain, so the model needs some compressed internal representation that preserves what matters. I started experimenting with neural networks that could learn distributed internal representations of structured sequences. Originally I imagined the inputs and outputs as things like sensor readings and robot actions. But when it came time to demonstrate the architecture in a journal paper, I used something quite different: language. I trained the network on English and Spanish sentences.

English goes in, and English and Spanish come out. Part of what it learned came from examples of translations: Spanish goes in, English and Spanish come out. That’s the supervised part of the problem. But it could also learn simply by reconstructing sentences in the same language. It would take English, compress it, and decompress it, essentially learning useful internal representations without needing every example to come with a translation. Same with Spanish. And the network learned to translate between English and Spanish. This became my first journal paper, published in Connection Science in 1991.

What I like about this story now is that I wasn’t sitting there saying, “I want to build an early neural network translation system.” I was thinking about a robot. I was trying to figure out how a learning system could form useful internal representations of more information than it could explicitly hold on to. Language became a particularly good way to explore that idea. And more than 30 years later, neural machine translation became one of the most important areas in which modern neural network architectures, including the transformer, developed.

I’m certainly not suggesting a straight line from that little network to today’s systems. There were enormous advances in between. But it’s the same broad family of questions. What information should the system represent? How should it represent structure? How does information from earlier in the sequence affect what happens later? How can a learned internal representation support a useful task? These are modeling questions. And in 1991, we called the thing I built a neural network model, too, which brings us right back to the meaning that’s suddenly everywhere: the AI model.

What today’s AI models are

So what about today’s AI models? A modern language model works quite differently from that old translation network. At its core, though, a language model is still a mathematical model that has learned structure from enormous amounts of language. Given some context, it represents the relationships that allow it to generate what comes next. Modern systems build remarkable capabilities on top of that.

So why do we call it a model? For exactly the same fundamental reason. It captures some structure in something vastly more complicated, in this case patterns in language and the information expressed through that language, and it gives us a representation we can compute with.

But there’s a useful distinction here that often gets blurred. An AI model is not necessarily the entire AI system. An application may include a language model, databases, search tools, business rules, software for managing a conversation, interfaces to other systems, and human decisions about how all those pieces work together. Calling that entire thing the model is a convenient shorthand sometimes. But if we’re trying to reason clearly about a system, it’s useful to know which piece we actually mean.

There’s another connection I find fascinating. We started with mental models, mostly implicit models that exist in our heads. Then we created explicit diagrams, equations, and computer models. Then we learned how to build models that learn their own internal representations. And now we have AI models that can actually help us build other models. That’s one of the ideas we’re going to explore throughout this series.

RelayWorks: launch, pilot, or wait?

Mental models are indispensable, but they have a weakness. You can’t see mine. I can’t see yours. So let’s make this concrete. I’m going to introduce a company that we’ll come back to throughout this series. The company is fictional, but the situation isn’t unusual at all.

Let’s call the company RelayWorks. RelayWorks makes software used by industrial maintenance teams. A technician standing next to a piece of equipment can pull up manuals, maintenance history, service bulletins, and previous repair records. The company has about 180 corporate customers, and the product team has been working on a new AI feature called TechAssist. Instead of searching through manuals, a technician can type, “This pump started vibrating after yesterday’s seal replacement. What should I check first?” TechAssist reads the relevant manuals and service history and suggests troubleshooting steps. Potentially very valuable, and potentially very dangerous if it confidently gives the wrong answer.

Now imagine it’s Monday morning. The CEO, the head of product, the engineering lead, and the head of sales are in a conference room. They have to make a decision, and there are three alternatives on the table. Launch now, meaning release TechAssist to all 180 customers next month. Pilot, meaning release it to 10 selected customers. Or wait: keep developing and testing it before putting it in customers’ hands.

Sales wants to launch. A competitor has just announced something similar, and three important customers are already asking when TechAssist will be available. Engineering is less comfortable. Internal testing looks good, but there have been a handful of answers that sounded completely convincing and were simply wrong. Legal is concerned about liability and how customer data flows through the AI system. Product is worried that if they wait too long, they’ll surrender the market to competitors. So: launch, pilot, or wait?

Here’s the interesting part. Before anybody opens a spreadsheet, before anybody draws an influence diagram, before anybody calculates a probability, there are already models in that room. The head of sales has a model: customers are asking for this, and if we don’t move quickly, we’ll lose deals. The engineering lead has a model: a convincing wrong answer in an industrial setting could do enormous damage. The CEO has another: the biggest strategic danger may be letting competitors define this category before we do.

Those are models. They’re just implicit. And because they’re implicit, people can argue about the conclusion without ever discovering where they’re actually making different assumptions about how the world works.

Making the model explicit

So let’s make just a tiny piece explicit. We’ll start with the decision: the release strategy, launch now, pilot, or wait. What does the decision affect? One thing we probably care about is customer value. Another might be competitive position. Another might be the risk from incorrect AI answers. Eventually those contribute to something like the overall value to RelayWorks.

That is a model, an extraordinarily crude model. It has no numbers. It hasn’t captured most of the things that matter. And that’s okay, because we’ve already accomplished something. We’ve taken part of the reasoning that was hiding in people’s heads and put it someplace where everyone can see it.

Now somebody can say, “Customer value isn’t the same thing as revenue.” We’ve discovered an ambiguity. Let’s add it. Someone else can say, “Wait, you left out what we’ll learn in a pilot.” Excellent, let’s add that too. And someone else can say, “The chance of a bad answer depends on how customers actually use this.” Now we’ve discovered a relationship that may matter. That’s modeling. The value isn’t that the diagram magically contains the answer. The value is that it gives us something we can inspect, criticize, and improve.

Four questions to ask of any model

I want to give you four questions you can use whenever you encounter a model, whether it’s a climate model, a spreadsheet, a business case, an AI model, a diagram someone drew on a whiteboard, or even the model you currently have in your own head.

First: what is it for? What question are we trying to answer, what decision are we trying to make? For RelayWorks, it’s whether to launch TechAssist now, pilot it, or wait.

Second: what does the model tell us? What comes out of the model: a forecast, a probability, a ranking, a financial result, a recommended alternative? For RelayWorks, we eventually want to understand the consequences of those three alternatives well enough to choose between them.

Third: where is the boundary? What part of the world are we modeling? Maybe we include customer adoption, competitive effects, and the risk of errors. Maybe we don’t model the entire economy, or what competitors will be doing 10 years from now. Every model has a boundary, whether its creator acknowledges it or not. We call this its scope.

Fourth: what did we deliberately leave out? This may be the most revealing question of all, because every useful model leaves things out. The question isn’t whether it does. The question is whether it left out the right things.

Try it: frame one of your own decisions

I’d like you to try this yourself. Think of one actual decision you’re facing. Not something broad like “what should I do with my career.” Make it specific. Maybe it’s a yes or no decision: should I accept this particular job offer? But decisions don’t have to be yes or no. They might be choices among several alternatives: which of these three cities should we choose for our next distribution center? They might be integer quantities: how many salespeople should we hire next quarter? Or they might be continuous quantities: how much should we spend on advertising this year? Those are all decisions.

Notice that making the question specific is already part of modeling. In decision analysis, we call this framing the decision. Framing means deciding what problem we’re actually trying to solve, what decision is in scope, what objectives matter, what time horizon we’re considering, and where we’re going to draw the boundary around the problem. We’ll spend much more time on framing later in the series. For now, just recognize that it happens before the equations, before the spreadsheet, before the AI.

So take one real decision and write down four lines. First, the decision: what is it, specifically, that I am deciding? Next, the output: what do I need to know from the model to help me make that decision? Next, the boundary: what part of reality am I going to include? And finally, omissions: what am I deliberately going to ignore? Don’t worry about equations. Don’t worry about software. Don’t even worry about whether it’s a good model. You’ve just begun to frame the problem, and you’ve taken the first step towards making your model visible.

Wrap-up and what’s next

I started this episode with a model airplane, and in one sense we’ve traveled a long way from there. We’ve gone from balsa wood and paper to electrical circuits, to the models inside our heads, to an early neural network trying to learn what information to preserve, to decision models, to today’s artificial intelligence. But maybe we haven’t traveled as far as it first appears, because all of these models do something fundamentally similar. They take something too complicated or too inaccessible to work with directly and create a representation that is simpler, for a purpose. A model is useful not because it contains everything. It’s useful because it contains what matters for the thing we’re trying to do.

That leads to a particularly interesting question, because today I can take the RelayWorks problem, open up a generative AI system, and simply ask: should RelayWorks launch TechAssist, run a pilot, or wait? And I’ll get an answer, maybe an intelligent-sounding answer. So why bother constructing a decision model at all? If AI can reason about the problem for us, do explicit models still matter? That’s where we’ll go next week. Thank you. See you then.

More from the series: watch all episodes of Supermodeling and AI. In the next episode, Lonnie asks whether explicit decision models still matter when a generative AI system can reason about the problem for us.