A fraud analyst and a copywriter can both type "machine learning" into a job description and mean two very different things. One wants a model that scores every transaction as risky or safe. The other wants something that drafts the next product description. Both fall under machine learning, but only one is generative — and picking the wrong one can cost a team weeks of work.

The short version: traditional machine learning predicts something you can define in advance — a number, a category, a ranking. Generative models produce new content: text, images, audio, code, even synthetic rows of tabular data. The rest of this piece is about telling them apart in practice and knowing which one a given problem actually calls for.

The core split: prediction versus production

Predictive models are trained against a fixed target. You decide before training begins that the output will be one of five risk bands, or a dollar amount, or a yes/no flag. The model's whole job is to map inputs onto that pre-defined answer space, and its quality is measured against known correct answers.

Generative models are trained to learn the structure of the data itself, so they can produce new samples that resemble it. Ask a churn model about a customer and you get a probability, say 0.72. Ask a generative model to write a re-engagement email for that same customer and you get a paragraph in your brand voice that mentions their last order. One narrows uncertainty into a label. The other expands a prompt into content.

How they learn differently

Predictive models

Most classic machine learning is supervised: you assemble examples with labels, split them into training and validation sets, and optimise until the model's predictions match the labels closely enough. Feature engineering still matters. A well-chosen feature — days since last purchase, average order value over ninety days — often beats a fancier algorithm. Evaluation is straightforward and numeric: precision, recall, mean absolute error, ranking metrics.

Generative models

Generative systems learn patterns from enormous amounts of unlabelled data — how words follow each other, how pixels cluster into shapes. You then steer them with a prompt, a few examples, or a round of fine-tuning on your own material. Evaluation is messier. There is rarely a single correct output, so you judge on rubrics, human review, and task-specific checks such as "does this summary contain only facts present in the source?"

Two practical consequences follow. Predictive models are usually cheap, fast and repeatable — the same input gives the same output. Generative models are typically slower and pricier per call, and their answers vary between runs, which is either a feature or a bug depending on the task.

What each approach does best

• Use predictive machine learning when the answer space is closed, you have labelled examples, and consistency matters. Demand forecasting, delivery-time estimates, fraud scoring, spam filtering, churn risk, recommending the next best product, sorting support tickets into queues.
• Use generative models when the output is open-ended, the volume of possible answers is effectively unlimited, or the work is creative or conversational. Drafting copy, summarising long documents, translating, writing and explaining code, extracting structured fields from messy text, building a chat interface, generating training data.
• Use neither when a rule or a spreadsheet lookup solves the problem. A hard-coded threshold on refunds above a set amount is more reliable and easier to audit than any model.

Where the boundary gets blurry

The two families overlap more than the marketing suggests. A generative model can classify perfectly well — ask it to label a review as positive, neutral or negative and it usually manages. But it does so at a higher cost per item and with more variance than a small classifier trained on the same task. Conversely, older sequence models and embedding techniques borrowed from predictive work now sit quietly inside recommendation and search systems everywhere.

The most useful pattern in production is often hybrid. Generate once, predict many: use a generative model to label a few thousand examples cheaply, then train a small, fast classifier on those labels and serve that to users. Or run a retrieval step to fetch relevant documents, then generate an answer grounded in them. Extraction is another good fit — pull line items off an invoice with a generative model, then validate the totals with arithmetic code.

A five-question checklist before you build

1. What exactly is the output? If you can write down every valid answer, lean predictive. If the output is a paragraph, an image or a conversation, lean generative.
2. Do you have labelled data? Yes, and it's clean? A supervised model will likely be accurate and cheap. No labels, but plenty of raw text or documents? Generative is the faster route.
3. How much does one wrong answer cost? For a typo-tolerant draft, variance is fine. For a credit decision or a safety check, you want a deterministic model you can test and explain.
4. What is the volume and latency budget? Millions of calls a day at low latency usually favours a compact predictive model. Hundreds of calls a day where a two-second wait is acceptable suits a generative one.
5. How will you measure success? If you cannot state the metric before building, you will end up arguing about vibes rather than results.

Mistakes worth avoiding

The classic error is reaching for a large generative model on a task a small classifier handles better and cheaper. The mirror error is forcing a predictive model onto an open-ended problem and then blaming the algorithm for bland output. Two smaller traps: scoring generative output with accuracy, which tells you almost nothing about quality, and expecting identical replies to identical prompts, which is not how these systems work.

Set expectations with stakeholders early. Generative features need review workflows, guardrails and someone accountable for what goes out the door. Predictive features need monitoring for drift, because the world moves and a model trained last spring quietly decays.

Start with the output, not the model

Write one sentence describing the deliverable: "a risk score for each application" or "a first draft of each product listing." That sentence usually chooses the architecture for you. Then build the smallest version that could plausibly work, put it in front of real users, and compare it against the dumbest reasonable baseline — a rule, a template, or the current manual process.

If a compact predictive model gets you ninety percent of the way, ship it and keep the generative option in reserve for the parts that genuinely need language. If the task is open-ended and your labelled data is thin, start generative, add checks, and plan to distil the output into something faster later. The question is never which technology is more impressive. It is which one earns its cost on this problem, this month.

Photo: Sóc Năng Động / Pexels