Start with the simplest honest answer, then build on it.

The definition in one sentence

An AI model is a mathematical description of a pattern, learned from data, that takes some input and produces a useful output such as a prediction, a decision, a label, or a piece of generated content. The model is what you are left with after learning is finished. It is the thing you can save to a file, copy to a server, and ask questions.

Three parts every model has

Why we need models at all

Some problems cannot be solved by writing rules by hand. Try writing exact instructions for recognizing a cat in a photograph: pointy ears, whiskers, fur, but also cats curled up, cats half hidden behind a sofa, cats in bad light. The rules multiply without end. Instead of writing the rules, we show a learning system a large number of labeled examples and let it find the pattern itself. The result of that process is the model.

Model, algorithm, program, and data: untangling the words

These four words get mixed up constantly. They are related, but each means something different.

Models did not appear overnight. Each decade added a missing piece.

Learning sounds mysterious, but the core loop is simple enough to describe in four steps.

A model is a function with adjustable knobs

At its heart, a model is a function: a machine that turns an input into an output. A very simple model might be “price equals size times a number plus another number”. The two numbers are the knobs, or parameters. If the knobs are set badly, the predicted prices are nonsense. If they are set well, the predictions are close to real prices. Learning is the process of finding good knob settings.

The training loop

flowchart TD
    A["Training example: input and correct answer"] --> B["Model makes a prediction"]
    B --> C["Compare prediction with the correct answer"]
    C --> D["Calculate the error, called the loss"]
    D --> E["Adjust the parameters to reduce the error"]
    E --> F{"Good enough?"}
    F -->|"No"| A
    F -->|"Yes"| G["Save the trained model"]

Why the nudges are small

The size of each nudge is controlled by a setting called the learning rate. If it is too large, the model overshoots and bounces around like a ball thrown too hard down a hill. If it is too small, learning takes forever. Choosing it well is part of the craft of training.

A tiny worked example

Suppose you want a model that predicts the price of a flat from its size. You have three past sales: a 500 square foot flat sold for about 105 thousand dollars, a 1,000 square foot flat for about 195 thousand, and a 1,500 square foot flat for about 310 thousand. Your model is the simple formula “price equals size times a, plus b”. The two numbers a and b are the parameters.

At the start, a and b are both zero, so every prediction is zero and the error is huge. The training loop notices that predictions are too low and nudges a upward and b upward. After many rounds, a settles near 0.2 and b near 5. The model has found the line that best fits the sales. Now ask it about a 900 square foot flat: 0.2 times 900, plus 5, gives about 185 thousand dollars. That is a prediction for a flat the model never saw.

The model with two parameters and the language model with 175 billion parameters follow exactly the same principle. Only the size of the formula, the amount of data, and the amount of computing power are different. If you understand this small example, you understand the heart of machine learning.

Learning is not memorizing

The goal is not for the model to remember every training example. The goal is for it to capture the pattern behind the examples, so it can handle new inputs it has never seen. A model that does this well is said to generalize. Much of the rest of this guide is about achieving, measuring, and protecting that ability.

Models differ in what kind of feedback they get during training.

Two common tasks

In supervised learning, most problems fall into two kinds. Classification means choosing a category, such as “fraud” or “not fraud”, or “cat”, “dog”, or “rabbit”. Regression means predicting a number, such as tomorrow’s temperature, the price of a house, or the number of items that will sell next week.

“Model” is a broad word. Under it live many families, from a one-line formula to systems with hundreds of billions of numbers.

Inside a neural network

Neural networks deserve a closer look because they power most headline-grabbing AI. A neural network is built from layers of tiny units. Each unit multiplies its inputs by numbers, adds them, and passes the result forward. Early layers pick up simple features and later layers combine them into richer ideas. In an image model, the first layers might notice edges, the middle layers shapes, and the final layers whole objects.

flowchart LR
    A["Input: pixels of a photo"] --> B["Layer 1: edges and colors"]
    B --> C["Layer 2: simple shapes"]
    C --> D["Layer 3: object parts such as ears and eyes"]
    D --> E["Output: cat with high confidence"]

Choosing a family

Bigger is not always better. For a table of customer records with a few dozen columns, a boosted tree model often beats a huge neural network, trains in minutes, and can be explained to a regulator. For photos, speech, and free-form text, neural networks are usually the clear winner. A good practitioner starts with the simplest model that could work and upgrades only when the results demand it.

A model can only learn what its data can teach it.

Features and labels

Data for a model is usually arranged as examples. Each example has features, which are the inputs describing it, and often a label, which is the correct answer. For a loan model, the features might be income, existing debts, and years in a job, and the label might be “repaid” or “defaulted”. Choosing and preparing good features, called feature engineering, can matter more than choosing a fancy model.

Splitting the data honestly

If you test a model on the same examples it studied, you learn nothing, because it may simply remember them. So the data is split into three groups before training begins.

flowchart TD
    A["All collected data"] --> B["Clean and prepare"]
    B --> C["Training set, about 70 percent"]
    B --> D["Validation set, about 15 percent"]
    B --> E["Test set, about 15 percent"]
    C --> F["Learn the parameters"]
    D --> G["Tune settings and compare models"]
    E --> H["Final honest score, used once at the end"]

Where data comes from and how it gets labels

Training data comes from many sources: records a company already keeps, such as sales and support tickets; sensors and cameras; public datasets released by universities; and text, images, and code collected from the web. Each source brings its own questions about quality, permission, and privacy, so teams document where every dataset came from and what they are allowed to do with it.

Labels are often the costliest part. A medical imaging model needs scans marked by trained doctors. A spam filter needs messages marked by users who click the report button. Some labels come free from the real world, such as whether a customer actually repaid a loan. Where people must create labels, teams write clear guidelines and have several people label the same examples, then check how often they agree. If humans disagree on the answer, a model cannot be expected to find a single correct one.

Common data problems

• Missing values: blank fields that must be filled sensibly or handled by the model.
• Wrong labels: mistakes in the answer key teach the model mistakes.
• Imbalance: if 99 out of 100 examples are normal and one is fraud, the model may learn to ignore the rare case.
• Leakage: accidentally including information in the features that would not be known at prediction time, which makes test scores look unrealistically good.
• Unrepresentative samples: data from one city, one age group, or one season that fails to reflect the real world.

A trained model is not magic. It is a recipe plus a very long list of numbers.

Two ingredients: architecture and parameters

If you open a saved model file, you find two things. The first is the architecture, which describes the shape of the model: how many layers, how they connect, what operations they perform. The second is the set of parameters, the learned numbers that fill that shape. Architecture is the blueprint of the building; parameters are the exact position of every brick.

Parameters versus hyperparameters

People often confuse these two. Parameters are learned automatically during training. Hyperparameters are settings chosen by humans before training starts, such as the learning rate, the number of layers, or how long to train.

How big is a model?

Models range enormously. A simple regression model may have a handful of numbers. A model that recognizes handwritten digits may have a few hundred thousand. Modern language models have billions. Because each number takes memory, often two bytes, a model with 70 billion parameters needs around 140 gigabytes just to store its numbers. That is why the largest models run on clusters of specialized chips, while small ones fit on a phone.

Pre-trained models, transfer learning, and fine-tuning

Training a large model from nothing is extremely expensive, so most teams do not do it. Instead they start from a pre-trained model, one that someone else has already trained on a huge, general dataset. That model has already learned broadly useful patterns, such as what edges and textures look like in images, or how sentences are structured in a language. Reusing those learned patterns for a new job is called transfer learning.

The most common way to do this is fine-tuning. You take the pre-trained model and continue training it for a short while on a small, specialized dataset, such as photos of your own factory parts or support tickets from your own company. The parameters shift slightly to fit your task, while the broad knowledge stays in place.

Model files and where they live

Trained models are saved in files and often shared through public hubs such as Hugging Face, or kept in a private model registry inside a company. A registry stores each version of a model with notes about its training data and scores, so teams can roll back if something goes wrong. Files come in several formats, and as Chapter 13 explains, some formats are safer to open than others.

The central balancing act of machine learning: learn enough, but not too much.

Underfitting: too simple

An underfit model is too simple to capture the pattern. It performs poorly on the training data and on new data alike. Using a straight line to predict something that curves is a typical cause. It is like a student who skimmed the textbook and understood nothing.

Overfitting: too eager

An overfit model learns the training data so closely that it picks up noise and coincidences as if they were real patterns. It scores brilliantly on the examples it studied and badly on anything new. It has memorized instead of understood.

How practitioners fight overfitting

“It seems to work” is not good enough. Numbers tell the truth, if you pick the right ones.

Accuracy and why it can fool you

Accuracy is the share of predictions that were correct. It is simple, and sometimes dangerously misleading. Suppose only one transaction in a hundred is fraud. A lazy model that always answers “not fraud” is correct 99 percent of the time, and catches zero fraud. Its accuracy looks superb while its usefulness is nil. This is called the accuracy paradox.

Better questions: precision and recall

For tasks where one outcome is rare or costly, two other measures give a clearer picture. Precision asks: when the model raises an alarm, how often is it right? Recall asks: of all the real cases, how many did the model catch?

The confusion matrix

A confusion matrix is a small grid that counts four outcomes for a yes-or-no model: true positives (correctly flagged), true negatives (correctly passed), false positives (flagged by mistake), and false negatives (missed). Nearly every metric above is calculated from these four counts, so looking at the grid itself shows exactly where the model goes wrong.

Judging models that generate content

Models that write text or create images are harder to score, because there is often no single correct answer. Teams combine several approaches: automatic checks for facts and format, benchmark question sets with known answers, ratings from human reviewers who compare outputs side by side, and tracking how real users respond, for example whether they accept a suggestion or edit it heavily. No single score tells the whole story, so careful teams look at several together.

Beyond the numbers

A good evaluation also checks performance across different groups of people, across seasons or regions, and on hard edge cases. A model with a strong overall score can still fail badly for one group, and that failure is hidden by the average.

Training a model is only a small part of the job. Most of the work comes before and after.

The lifecycle

flowchart TD
    A["Define the problem and success measure"] --> B["Collect and label data"]
    B --> C["Prepare features"]
    C --> D["Train candidate models"]
    D --> E["Evaluate on unseen data"]
    E --> F{"Good enough?"}
    F -->|"No"| C
    F -->|"Yes"| G["Deploy to production"]
    G --> H["Monitor performance and drift"]
    H --> I{"Performance dropping?"}
    I -->|"Yes"| B
    I -->|"No"| H

The diagram is a loop on purpose. A model is not finished when it is deployed. The world changes, new data arrives, and the model must be watched and refreshed. Teams that treat a model as a one-time project usually end up with one that quietly decays.

Training versus inference

Training builds the model and is heavy: many GPUs, hours to months, large datasets. Inference uses the model to answer one request and is light by comparison, but it happens constantly, so its total cost can exceed training over time. Many companies spend far more computing on inference than on training because millions of users trigger it every day.

Serving a model to millions of users

To make a model useful, it is wrapped in a service that applications can call over the network. A typical production setup looks like this.

flowchart TD
    A["Mobile app or website"] --> B["API gateway"]
    B --> C["Load balancer"]
    C --> D["Model server 1"]
    C --> E["Model server 2"]
    C --> F["Model server N"]
    G["Feature store"] --> D
    G --> E
    G --> F
    H["Model registry with versions"] --> D
    H --> E
    H --> F
    D --> I["Prediction returned to the app"]
    E --> I
    F --> I
    D --> J["Logs and metrics"]
    E --> J
    F --> J
    J --> K["Monitoring and alerts"]

Making models fast and affordable

When millions of people use a product, even a small saving per prediction adds up to a large amount. Engineers therefore use several techniques to make models cheaper and faster without losing much quality.

Teams also scale horizontally, which means adding more identical model servers behind the load balancer as traffic grows, and removing them when traffic falls. This keeps response times steady during busy hours without paying for idle machines overnight.

Batch or real time?

You already depend on dozens of models every day.

Models are powerful, but they are not oracles. Knowing their weak spots is part of using them well.

A model only knows its training world

A model learns from the data it was shown. Ask it about situations that look nothing like that data and it will still answer, often with confidence, but the answer may be meaningless. A weather model trained only on tropical climates has nothing sensible to say about blizzards. This failure on unfamiliar inputs is one of the most important limits to remember.

Bias in, bias out

Data reflects the society that produced it, including its unfairness. In 2018 it was widely reported that Amazon had abandoned an experimental recruiting tool after finding that it favored male candidates, because it had learned from past hiring data dominated by men. The model did exactly what it was trained to do, and that was the problem.

Accuracy versus explainability

Simple models such as decision trees can be read by a person: you can trace why a loan was refused. Large neural networks are often more accurate but behave like sealed boxes, so explaining a single decision is hard. In areas such as lending, hiring, and healthcare, where people deserve reasons and regulators ask for them, this trade-off becomes critical. Explanation tools exist, but they give approximations, not full transparency.

Using models responsibly

Responsible use starts with asking whether a model should be used at all for a given decision. When a model affects a person’s job, loan, health, or freedom, the standard of care must be higher, because errors harm real lives. Good teams follow a few habits.

• Check fairness on purpose. Measure results separately for different groups, and investigate any large gap instead of trusting the average.
• Keep a person in the loop. For important decisions, let the model advise and let a trained human decide, with the ability to override it.
• Be open about limits. Document what data the model learned from, what it is meant for, and what it should not be used for.
• Offer a way to appeal. People affected by a model’s decision should be able to ask for a review.
• Respect privacy. Collect only the data needed, protect it, and follow the laws that apply to personal information.

Common trade-offs

Models are software assets and they hold information, so they attract attackers.

Defense in layers

A model that worked on launch day will not keep working forever without attention.

Why models decay

The world changes and models do not. Customer habits shift, new products appear, fraudsters invent new tricks, and a pandemic can scramble every pattern at once. A model trained on last year’s reality slowly drifts out of date. This silent decay is called model drift.

What to track

Logging with care

Good logs record the model version, the time, the inputs, the output, and an identifier that ties the pieces of one request together. That makes it possible to investigate a complaint months later. Because inputs may contain personal data, logs should be redacted where possible, access should be restricted, and a retention period should be set.

Closing the loop

Monitoring is only useful if it triggers action. Teams set alerts on key metrics, review samples of real predictions regularly, collect fresh labeled data, and retrain on a schedule or when drift is detected. New versions are often tested first on a small slice of traffic, in what is called a canary release, with a fast path to roll back if the numbers worsen.

The same mistakes appear in project after project. Avoid them and you are already ahead.

Best practices

Common mistakes

• Choosing a fancy model when a simple one would do, and then being unable to explain or maintain it.
• Reporting accuracy on imbalanced data without checking precision and recall.
• Letting information from the future or from the test set leak into training.
• Training on convenient data instead of data that represents real users.
• Treating deployment as the finish line and never looking at the model again.

Short answers to questions that come up again and again.

The whole picture, from one idea to a living production system.

An AI model is a learned pattern captured as architecture plus numbers. It is created when a learning algorithm adjusts those numbers against data, and it is used when applications feed it new inputs and read back predictions. Models come in many families, from a short decision tree to a Transformer with billions of parameters, and the right one depends on the problem, the data, and the need to explain decisions. A model is judged by how well it handles examples it has never seen, using metrics that match the real cost of errors. It lives inside a larger system of data pipelines, servers, registries, and monitors, and it needs protection from attackers and attention from its owners long after launch.