Skip to main content

02 · ML and LLM foundations

Machine learning in one lesson

How a program learns from examples instead of rules, and the handful of words everything else in the course builds on.

10 minCase study: Adapta (opens in new window)

In traditional software, a person writes the rules: "if the payment is over 1,000, send it for review." In machine learning (ML), nobody writes the rules; the system works them out from examples. So its behavior depends on its data, on how its mistakes were measured, and on whether anyone checked it on cases it has never seen.

This lesson covers the ideas the rest of the course builds on: how a model learns from examples, what does, why training and answering requests are separate jobs, how to tell learning from memorizing, and what a language model is underneath. Adapta is the case study because it keeps these pieces visibly separate.

Learning from examples

Think of a spam filter. Instead of writing rules, you collect thousands of messages already marked "spam" or "not spam" and let the system find the patterns.

The thing that learns is a model: picture a machine with a huge number of adjustable knobs. The knobs are its parameters, or weights, plain numbers, sometimes billions of them.

Each example pairs an input, such as a support ticket, with the correct answer, its label, such as "billing". A collection of pairs is a dataset. When every example comes with its answer, this is supervised learning, the case this lesson covers. Language models learn in a similar way, but nobody writes their labels: the "answer" at each point is simply the next piece of the text.

Training: measuring mistakes and correcting them

Training means finding knob settings that make the model's answers match the labels. First, it needs a score for mistakes. The loss is one number that says how badly the model did: lower is better. The usual loss for classifiers and language models punishes confident mistakes hardest: being "90% sure" of the wrong answer costs far more than a hesitant wrong guess.

Second, it needs a way to improve. Gradient descent is like walking downhill in fog: you can't see the valley, but you can feel the slope. For each knob, the math says which direction lowers the loss, and the model takes a small step that way, over and over. The step size is the learning rate; one full pass over the data is an epoch.

  1. Examplean input and its label
  2. Predictionthe model's current answer
  3. Lossone number for how wrong it was
  4. Adjusta small step downhill for every weight

next example, epoch after epoch

Training is this loop repeated many times. Each pass nudges the weights so the next answer is a little less wrong.

Training is not serving

When training ends, the knobs are frozen and the model starts answering requests. That phase is , or serving. The two phases look very different:

Training Serving
What it does adjusts the parameters uses them, fixed, to answer
How often occasionally continuously, per request
Hardware almost always a GPU sometimes a regular CPU
Typical failure out of memory, no improvement too slow, wrong answer

In Adapta

  1. Training requestthe app queues it and moves on
  2. Workertakes the job and trains on the GPU
  3. Evaluation gatescores data the model never trained on
  4. Servingthe base model plus the new adapter
The app that answers requests never trains. A new model only reaches serving after it passes the check described below. Source: Architecture

Serving has its own lesson: Serving models.

Learning versus memorizing

A student who memorizes last year's exam can ace it and fail a new one. Models do the same. What matters is : being right on new data of the same kind. So the data is split, and each part has one job:

  • Training set: adjusts the parameters.
  • Validation set: compares settings and decides when to stop.
  • Test set: used once, at the end, to estimate real performance. If it keeps influencing decisions, the system slowly gets tuned to it and it stops being a test.

is memorizing instead of learning: the loss on training data keeps falling while the loss on validation data starts rising. Underfitting is the opposite: the model hasn't even learned the training data. In the sketch below, look at where the two lines part ways.

loss
 |\
 | \        ___ validation
 |  \______/
 |   \
 |    \______ training
 +------------------ time spent training
        ^ stop around here

Metrics and comparisons are covered in Evaluating models.

Neural networks and transformers

A neural network is a model built from layers. Each layer does a simple calculation and passes the result on. Stacked, simple layers can capture very complex patterns, and gradient descent tunes them all at once.

A is the kind of network behind today's large language models (). Its key idea is : for each word it processes, the model weighs how much every earlier word matters. That is how it links "it" back to the right noun. An LLM is a transformer trained to predict the next , a word or piece of a word. Generating text is repeating that prediction, one token at a time.

Pretraining means training a model from scratch on a huge amount of text; it takes GPU clusters and few organizations have, and produces a base model. continues training a base model on a small dataset to change its behavior: format, tone, or how it classifies. Almost no product team pretrains. The realistic options are good , handing the model knowledge when a question arrives (Embeddings and RAG), or efficient fine-tuning (Fine-tuning, LoRA and QLoRA).

Base modelpretrained by a few organizations
  • Promptsdescribe the task
  • RAGhand it knowledge per question
  • Fine-tuningchange its behavior
Almost every team starts from a base model someone else pretrained. The real choice is how to adapt it.

Putting it into practice

  • Decide who owns the evaluation data. If the people who train also pick and reuse the test set, results inflate without anyone lying.
  • Keep a versioned held-out set, never used for training or tuning, and measure the unchanged model on it as a .
  • Write the pass criterion before training, not after seeing the numbers.

Go deeper

Adapta's own documentation covers these foundations with its code as the example:

  • Learning the system explains from first principles what a language model is, why training runs in a separate worker, and how the evaluation gate decides whether a new model may serve.
  • Architecture maps Adapta's containers and follows a training job step by step, from the queue to a live endpoint.
  • Stack and decisions explains why each component was chosen, including the training libraries, the job queue and the evaluation gate.

Key takeaways

  • A model is a set of parameters fitted to examples; its behavior depends on the data as much as on the code.
  • Training lowers a loss step by step; serving uses the frozen result. They differ in hardware, cost and how they fail.
  • Only performance on data the model never trained on shows whether it generalizes.
  • An LLM is a transformer trained to predict the next token; it aims for plausible, not true.
  • Almost nobody pretrains: the choice is between prompting, RAG and fine-tuning a base model.

Check yourself

Why is a low loss on the training data not enough?

A model can memorize its training examples and score well on them without learning anything that transfers. Only performance on data that played no part in training shows how it will handle new inputs.

Training loss keeps falling while validation loss rises. What is happening, and what can you do?

That is overfitting: the model is learning quirks of the training data. The usual responses are to stop earlier, get more or more varied data, or limit how much the model or the fine-tuning can change.

Why run training separately from the part that answers requests?

Training is long, needs a GPU and can run out of memory. Keeping it apart stops it from slowing or blocking live requests, and lets serving keep running on a machine with no GPU.