The Four Shapes a Learning Problem Can Take

Where the answer comes from

Everything here turns on one question: once you accept that a machine's behavior is learned from data rather than hand-coded, what does that data actually give you to check the model against? That single question splits machine learning into four distinct situations.

In the first, someone has already written the answer down next to each example — a column in a spreadsheet marking whether a customer cancelled, say — so error can be measured one row at a time. Point at a different column and the same data becomes a different problem: predicting a category is classification, predicting a quantity is regression.

Delete that answer column entirely and you're in the second situation: nothing to predict, only structure to find. Clustering groups rows that resemble each other; dimensionality reduction squashes redundant columns into fewer, denser ones. Both are real, and both come with a catch — there's no score to check against, only judgment calls about whether the structure found is actually useful.

The third situation drops the spreadsheet altogether. An agent acts in a world, and feedback — a reward — arrives only sometimes, often long after the choices that earned it. This is what makes reinforcement learning hard: the agent's own actions shape what data it ever sees, a single verdict has to be traced back across many earlier decisions (credit assignment), and the agent must sometimes choose a worse-looking action just to learn something (the explore-exploit tradeoff). None of this needs a labeled file — it needs an environment cheap enough to fail in millions of times.

The fourth situation manufactures its own answer key: hide a word in a sentence, or a patch in an image, and ask the model to recover it. There's a real, checkable answer, but no human wrote it down — which is why this approach could scale on raw data in a way hand-labeling never could, and why it underlies the huge models trained on more text than any team could ever mark up by hand.

The chapter closes by mapping where the actual hours in a machine learning job go: mostly to figuring out which of these four situations you're even in, wrangling data into usable shape, and deciding what "good" means before training anything — with model-fitting itself taking up a surprisingly small share.

Current models, money, and rules

A quick tour of where things stand: OpenAI's new flagship family launched in three pricing tiers with million-token context windows, while Anthropic's fifth-generation models posted strong software-engineering benchmark scores, and Google's releases traded latency against context length across the spring and summer. Every one of these systems is built on the self-supervised trick described above, then tuned afterward with reinforcement-style feedback on whole outputs.

The money kept pace: OpenAI closed a round near the $122 billion mark, and Safe Superintelligence took a five-billion-dollar investment from Nvidia with dedicated compute access. On the regulatory side, the EU AI Act hit a fresh implementation milestone, and the United States issued a new executive order on advanced AI innovation and security.

We have agreed on one thing so far, and it is the thing everything else in this course hangs from: behaviour can come from hand-written rules, or it can come from data. Chapter one drew that line, and chapter two walked seventy years along it. So the axis is settled. What we have not asked yet is the question that comes immediately after you accept it.

Here it is. You have accepted that the machine's behaviour will be learned from data. Fine. What does your data actually look like?

That question is not a detail. It is the question that carves machine learning into four kinds of problem, and those four kinds are the four words you have heard thrown around without much explanation: supervised, unsupervised, reinforcement, and self-supervised learning. People often present those as four families of algorithm, or as four rungs on a difficulty ladder, and both framings will confuse you later. They are neither. They are four answers to a single question, and the question is this: where does the thing I score the model against come from?

Hold onto that phrasing, because I am going to come back to it at every turn in this chapter. The thing I score the model against. The answer. The target. Whatever you want to call it — the value the model is supposed to produce, so that we can compare what it produced to what it should have produced, and push it in the right direction. Every one of the four names is a different story about where that value comes from.

Supervised learning: a human, or some process, already wrote the answer down next to each example.

Unsupervised learning: nobody wrote anything down, so the only thing there is to find is structure the data already has.

Reinforcement learning: nobody writes the answer down at all. The world just reports back later on whether a whole sequence of choices went well.

Self-supervised learning: the answer is manufactured out of the data itself, by hiding part of it and asking the model to put it back.

That is the whole map. Now let us earn each one.

Picture a spreadsheet. Not a big one — a few hundred rows. It is a table of past customers from some business, and one row is one customer. The columns are unremarkable: how many months they have been a customer, how much they spent last month, how many times they contacted support, which plan they are on, whether they are on a monthly or a yearly contract. Nothing exotic. You could open this file on a laptop and read it.

Now, there is one more column, over at the right, and it says whether that customer cancelled within the following three months. Yes or no. Somebody knows that, because it already happened. Those months are in the past. Nobody predicted anything to fill that column in; they just looked at what occurred and wrote it down.

That last column changes everything about what you can do with this file. Because now you can point at it and say: that one. That is the answer. Every other column is what I get to look at, and that column is what I am supposed to produce. Which means that for any given row, I can run my model on the other columns, get an output, compare it to what is actually in the answer column, and say — flatly, numerically, with no argument — whether the model was right about that customer.

That is supervised learning, and I want to be honest about how humble the definition is. It is not a technique. It is a situation. The situation is: a target exists. Somebody designated one column as the thing being predicted, and that column is filled in for the examples you are learning from. Because it is filled in, "right answer" is a well-defined phrase, and error becomes measurable one example at a time. You can add up the errors, and now you have a number that goes down when the model gets better. Almost everything in the first half of this course is built on the existence of that number.

The word "supervised" is a little unfortunate, by the way, because it makes people picture someone standing over the training process correcting it in real time. Nothing like that happens. The supervision was done in advance, once, when the answers were written down. Sometimes a person did it — a doctor labelling scans, an annotator tagging sentences. Sometimes it happened for free because the world logged the outcome: the customer cancelled or did not, the loan defaulted or did not, the delivery arrived late or on time. Those are equally supervised. The label's origin story does not matter to the algorithm. Its existence does.

Now, stay in that same spreadsheet, and notice that we can change the problem completely without touching a single number, just by pointing at a different column.

Point at the cancellation column: the answer is yes or no. Two options, and the model has to pick one. Now instead point at the amount-spent-last-month column, and cover it up, and ask the model to produce it from everything else. The answer is a quantity. It could be eleven dollars, or eleven dollars and forty cents, or two hundred, and being off by a little is not the same kind of wrong as being off by a lot.

Those two are genuinely different problems, even on identical data, and the field gives them different names. Predicting a quantity is regression. Predicting which category something falls into is classification. That is the distinction, and for now that is all I want you to take from it — not the algorithms, not the loss functions, not how you measure success in each case. Those get real attention when we start fitting models to real data, which is the next stretch of this course. Right now you only need the fork in the road: is the answer a number on a scale, or is it one of a fixed set of options?

Good. Now let us do something more interesting to that spreadsheet. Let us delete the answer column.

Take it out. Now you have a few hundred customers, described by their tenure and spend and support contacts and plan, and no outcome attached to any of them. Nothing to predict, because nothing was designated. What can you possibly do?

Two things, mainly, and they are both real.

The first is grouping. You can ask: do these customers fall into a handful of recognisable kinds? Not kinds you defined in advance — kinds the data suggests, in that some rows sit close to each other and far from others. Maybe there is a clump of long-tenured, low-spend, never-contacts-support customers. Maybe there is a clump of brand-new heavy spenders who contact support constantly. Nobody wrote "segment three" next to anybody. The grouping is something you extract by looking at how the rows sit relative to each other. That family of methods is called clustering.

The second is compression. Suppose the table had not five columns but two hundred, which happens constantly in real work. Many of those columns will be saying nearly the same thing in slightly different words. Total spend, average spend, and spend last month all move together. You can ask whether two hundred columns can be squashed down into, say, six new made-up columns that carry most of what varies across your customers. Not by throwing columns away, but by combining them. That is dimensionality reduction, and it is enormously useful — for drawing pictures of data you cannot otherwise see, for making later models faster, for stripping out noise.

Both of those are unsupervised learning, and again the name describes a situation rather than a method. The situation is: no answer column. So the only thing available to find is structure that was already sitting in the data, whether anybody noticed it or not.

Now I have to tell you the hard part, and I would rather tell you now than let you discover it on a project.

With no answer key, there is no obvious score.

Think about what we had a minute ago. With the cancellation column, I could say: the model was right for four hundred and twelve of five hundred customers. That statement is not up for debate. Someone who dislikes my model has to argue with the number.

Now I hand you a clustering. I say: your customers fall into four groups, here they are. What is the score? There is no column to check against. Nobody ever wrote down the true number of customer types, and there probably isn't one. I can compute measures of how tight and well-separated the groups are, and we will, and they help. But those measures are asking whether the grouping is internally neat, not whether it is true or useful, and a beautifully tight grouping can be completely uninteresting to the business while a messy one turns out to be the thing that explains everything.

So "did it work?" becomes a judgement call. That is not a flaw in the methods, and it is not something better tooling fixes. It follows directly from the absence of the answer column. And it is why unsupervised results get argued about in meetings in a way supervised results do not. When someone shows a classifier at ninety-one percent accuracy, the argument is about whether ninety-one is good enough. When someone shows five customer segments, the argument is about whether those are the segments. Those are different kinds of conversation, and knowing in advance which one you have signed up for will save you a lot of grief. Clustering and dimensionality reduction both get proper treatment later, once we have the linear algebra to see what they are actually doing.

So that is two of the four. In one, the answer was written down. In the other, nothing was. Now here comes a case where the framing changes shape entirely, and this is the one people most reliably misunderstand, so it gets room.

Forget the spreadsheet. There is no file.

Instead, picture something acting in a world. It could be a program controlling a character in a game, or a system deciding what to show a user, or a robot arm, or a piece of software managing a warehouse. Call the acting thing the agent and everything else the environment. The loop is simple enough to hold in your head. The agent observes the situation it is in. It takes an action. The environment changes as a result. And sometimes — sometimes, not always — a number arrives. Good, or bad, or a lot of either. That number is the reward.

That loop is all reinforcement learning is structurally. Observe, act, occasionally get a number. But three things follow from it that make it a genuinely different animal from anything we have discussed, and I want to build them up one at a time, because each one has consequences.

The first: the agent's own actions determine what data it ever sees.

In the customer table, the data was just there. Five hundred rows, fixed, sitting in a file, the same whether your model was brilliant or terrible. In the loop, that is not true. If the agent always turns left, it will only ever see what is to the left. It will accumulate an enormous amount of experience about turning left and know nothing whatsoever about the right-hand side of its world. Its data is a consequence of its behaviour, and its behaviour is a consequence of its data. That circle has no equivalent in supervised learning, and it means a bad early policy can starve the agent of the very experience that would fix it.

The second: the reward can arrive long after the choice that earned it.

This is the one that really bites. Suppose the agent plays a game of chess, makes forty moves, and loses. One number arrives at the end: you lost. Now, which move lost it? Possibly move eleven, quietly, and moves twelve through forty were fine play in a position that was already gone. Possibly move thirty-six. Possibly no single move, but a pattern. Nobody tells you. The reward is a single verdict on a whole sequence, and if you want to improve, you have to work backwards and assign some share of blame or credit to individual choices made long before the verdict landed.

Compare that to the customer table again. There, every single row came with its own private verdict. Row two hundred and eight was wrong, in exactly that way, by exactly that much. You did not have to figure out which of your decisions caused the error, because there was one decision per example. In the loop there are forty decisions and one number, and connecting them is most of the difficulty. That problem has a name — credit assignment — and it is not a wrinkle. It is the central engineering problem of the whole area.

The third: the agent must sometimes deliberately take an action that looks worse, purely to learn something.

Here is why. Suppose the agent has tried two actions. The first gave a reward of three, the second gave a reward of one. There are eight other actions it has never tried. What should it do next? If it always takes the best-known action, it takes the first one forever, and it will never discover that the seventh action was worth fifty. But if it keeps trying random things, it spends its life sampling and never cashes in on what it knows.

There is no clean solution to that, only management of it. Take the known-good action and you exploit what you have learned. Take an untested one and you explore. You need both, the balance shifts as the agent learns more, and getting it wrong in either direction ruins the whole enterprise. That tension is called the explore-exploit tradeoff, and once you have seen it you will notice it everywhere outside machine learning too, which is a decent sign that it is a real idea rather than jargon.

Now, put those three together and one very practical consequence falls out, which is the thing I actually want you to leave with.

Reinforcement learning does not primarily need a big labelled file. It needs an environment.

Because the agent learns by acting and seeing what happens, it needs something to act in, and it needs to act in that thing an enormous number of times — often millions of episodes, most of them incompetent. If your environment is the real world, and each attempt costs money, or breaks a physical arm, or annoys an actual customer, you cannot afford that. So the practical prerequisite is a simulator, or some environment that is cheap and fast and safe to fail in, or logged interactions rich enough to substitute for one. When you hear that a system was trained by reinforcement learning to do something impressive in a game, part of what you are hearing is that games are perfect for it: perfectly simulable, endlessly repeatable, free to lose. When you hear that reinforcement learning is hard to apply to some real physical process, the reason is usually not the mathematics. It is that nobody has a good enough simulator.

Which brings me to a correction I want to make explicitly, because I have watched this misconception cost people interviews. Reinforcement learning is not harder supervised learning. It is not the advanced version, the thing you graduate to. It is a different problem shape, chosen because of what your feedback looks like. If someone hands you a labelled file and you reach for reinforcement learning, you have not been ambitious, you have made an error — you have thrown away per-example answers you already had, and replaced them with the credit assignment problem for no reason. The choice between the two is a diagnosis, not an ambition.

So: answer written down, answer absent, answer arriving late as a verdict on a sequence. One shape left, and it is the one that quietly made the last several years of this field possible.

Take a sentence. Any sentence. "The customer cancelled her subscription after the price increase." Now cover up one word — say, "cancelled" — and hand the mutilated sentence to a model, and ask it what the covered word was.

Stop and look at what just happened, because it is a small trick with a large consequence.

There is a right answer. It is "cancelled". It is not a matter of opinion, not a judgement call, and the model's output can be scored against it exactly as strictly as we scored predictions against that cancellation column. But no human being wrote that answer down. Nobody was paid to annotate anything. The answer was already sitting in the data, in the ordinary sense that the sentence had a word there; we covered it up ourselves and then asked for it back.

That is self-supervised learning. The label is manufactured out of the data by hiding part of it. You will also see the same idea in the form of: here are the first nine words, predict the tenth. Or: here is an image with a patch blanked out, restore the patch. Same move every time. Withhold something the data already contains, then score the model on recovering it.

Now the payoff, and it is worth stating as plainly as possible.

If your training answers have to be written by people, your supply of training examples is bounded by how many people you can pay and how fast they work. Labelling is slow, it is expensive, and it is inconsistent — two annotators disagree, and now the answer column itself has noise in it. That ceiling was one of the real, practical limits on the field for a long time.

If your training answers are manufactured by hiding parts of the data, then your supply of training examples is your supply of raw data. Any sentence anyone has ever written is thousands of training examples, because you can hide any word in it, or predict every word from the ones before. No annotation, no cost per example, no annotators disagreeing. The supply is effectively the volume of text or images you can gather, and that is a vastly larger number than the volume anyone could label. That is why this framing scaled where labelling could not, and if you have ever wondered how a model could possibly be trained on more text than any team could ever have marked up by hand — that is the answer. Nobody marked it up. The answers were already in there.

And here is the misconception I most want to head off, because it is extremely common and it is a clean tell in conversation. Self-supervised learning is not unsupervised learning. It sounds like it should be, because in both cases nobody wrote any labels. But go back to our one question — where does the thing I score against come from? — and the two are not remotely the same. In unsupervised learning there is no right answer at all, which is exactly why judging the result is a judgement call. In self-supervised learning there is a right answer, it is specific, and the model is scored against it example by example, with all the same clean machinery supervised learning gets. The difference from supervised learning is not the absence of an answer. It is that the answer cost nothing to produce. Mechanically, self-supervised learning is much closer to supervised learning than to unsupervised — it is supervised learning that generates its own answer key.

Four shapes, then, and one question underneath all of them. Now let me tell you where the hours actually go, because if you picture this work as choosing among these four and then choosing an algorithm, you will be surprised by your first real job in an unpleasant way.

The first chunk of time goes to something that does not look like machine learning at all. Somebody asks for something vague. "Can we do something about churn." "Can AI look at these support tickets." Nothing in that request tells you which of the four shapes you are in, and figuring that out is the first real piece of work. Is there an outcome column somewhere, already filled in by history? Then you may have a supervised problem, and you should find out what exactly the column says. Is there nothing to predict and the actual want is "help me understand who these people are"? That is closer to the unsupervised situation, with the argument-about-results property that comes with it. Is the thing being asked for a sequence of decisions where feedback only arrives at the end? Now you need to know whether an environment exists to practise in. Getting this wrong is not recoverable by better modelling later. It is the whole thing.

The second chunk, and honestly often the largest, goes to getting data into a state where it can be used at all. Not cleaning it in some cosmetic sense — making it exist as the table you assumed you had. The columns you want live in three different systems with three different customer identifiers. Dates are stored four ways. Half the rows are missing the field that matters most. Somebody changed the definition of a column eighteen months ago and did not tell anyone, so the same number means two things depending on the row. None of this is glamorous and all of it is load-bearing, because every model downstream inherits whatever is wrong here.

The third chunk goes to deciding what "good" means, and deciding it before you train anything. What number will you look at? What number would make this worth deploying? Deciding that afterwards is how people fool themselves, because once you have results you can always find a measure that flatters them. Decide first, write it down, then train.

Then the fourth: many small experiments, most of which do not work. This is the part nobody advertises. You try a thing, it fails, you learn something small, you try the next thing. It is closer to debugging than to invention, and being calm about a long run of failures is a genuine professional skill.

And then, yes, the modelling. Choosing the algorithm, fitting it, tuning it. It matters and we will spend a great deal of this course on it, because you cannot do the rest without it. But as a share of the hours it is a small slice. The framing and the evaluation are most of the work.

Which is exactly why a portfolio project persuades people and a certificate does not. Anyone can call a function that fits a model; the function is one line and its documentation is free. What is hard to fake is a project where you clearly decided what shape the problem was, wrangled data that did not want to be wrangled, chose a measure of success and defended it, and reported an honest result including what failed. That is evidence of the framing, and framing is the thing being hired.

So, on the map. This chapter rests directly on the axis we set in chapter one — behaviour learned from data rather than written by hand — and it takes the next step by asking what your data actually looks like, which is what determines the shape of your problem. It is what makes the workflow episodes ahead legible, because you will now recognise which shape each of them is teaching. And the immediate next step is a practical one: getting the tools installed on your machine, so that from here you are running code rather than watching me describe it.

Now, the perishable layer, and remember why it lives out here rather than in the lesson. Everything above will be true in five years. Nothing below will be.

Start with the frontier, and take all of these as current as of late August of this year, because these numbers move constantly. OpenAI shipped a new flagship family on the ninth of July, restructured into three tiers, with a context window a little over a million tokens and output capped at a hundred and twenty-eight thousand. The pricing is the interesting part for anyone building: the top tier is on a promotional rate of four dollars per million input tokens and twenty per million output through late November, after which it steps up to five and thirty, the middle tier sits at two and twelve, and the cheapest at twenty cents and a dollar twenty. The practitioner's takeaway is the spread, not the ranking. Roughly flagship-grade work at about a third of the task cost of earlier top-tier models changes what projects are affordable, and cost per task is a thing you should be estimating before you build.

Anthropic rolled out its fifth-generation line across June and July, finishing with its largest model on the twenty-fourth of July, with million-token contexts, the mid-tier at two dollars and ten dollars per million and the top at five and twenty-five. The reported numbers on that generation are ninety-five and a half percent on a verified software-engineering benchmark and fifty-nine percent on a very hard broad-knowledge exam. Hold the first one against the older baseline of around sixty-four percent agentic coding accuracy, and you can see why agent work suddenly became a product category rather than a demo.

Google's releases came in May, July, and mid-August, with the newest fast model gaining about four points of task intelligence over its predecessor while lowering latency, and the larger models in that generation carrying up to two-million-token contexts with multimodal input. Open weights kept pace: releases from Alibaba and Zhipu in late August, one of them at nearly ninety-two percent on a graduate-level science benchmark, plus xAI's mid-August update and a DeepSeek release at the end of July. Meta's open-weight pair run a half-million and a full million tokens of context at ten to twenty cents per million input. The pattern worth internalising is that open weights now match or beat the proprietary models of a year or two ago at well under thirty cents per million tokens — which means "can I self-host this" is a real question on real projects now.

Tie all of that back to what we just covered. Every one of these models is a self-supervised model at its foundation — trained by hiding part of an enormous pile of text and asking for it back — and then shaped afterwards by feedback-driven tuning that is reinforcement-style: no per-token answer key, just a later verdict on whole outputs. The two shapes you learned today are, structurally, the whole recipe.

The money moved just as hard. OpenAI closed a hundred and twenty-two billion dollar round at the end of March at an eight hundred and fifty-two billion valuation, led by Amazon, Nvidia, and SoftBank. Anthropic closed sixty-five billion in late May, months after a thirty-billion round in February, and reported an annualised revenue run rate of forty-seven billion in May, largely from enterprise API use and coding deployments. Safe Superintelligence took five billion from Nvidia in late July along with dedicated compute access. On the structural side, SpaceX acquired xAI in February and went public in June, and Nvidia's finance chief confirmed more than fifty billion in sector commitments including a pending acquisition of Hugging Face — which, given how much of this course uses that ecosystem, is one to watch. Infrastructure spending across the big platforms is projected around six hundred and fifty billion for the year, and enterprise generative-AI spending tripled to thirty-seven billion last year. That last figure is the one to quote in an interview, because it is the reason the jobs exist.

On policy: the European Union's AI Act hit an implementation milestone on the second of August, bringing in mandatory national regulatory sandboxes and broader obligations for operators of high-risk models. The United States issued an executive order on advanced AI innovation and security on the second of June, following last year's federal action plan. The United Kingdom launched a five-hundred-million-pound sovereign AI fund. If you want a concrete next action from all of this, it is the smallest one: read the high-risk classification section of the European rules once. Knowing whether your system is in scope is fast becoming part of the job.