Module 10 · Lesson 2 of 2

What fine-tuning takes

Tune, test apart, roll out small

Trust a tuned model only after unseen tickets score it well, and even then give it a small share of traffic first.

Scene 1 of 5 · Gather marked examples

The team collects 3,500 tickets, each tagged by a person with the label it should get.

Your examplesYour examples3,500 tagged ticketsSplitSplitFine-tuneFine-tuneTest set checkTest set checkSmall rolloutSmall rollout
  • Your examples — healthy — 3,500 tagged tickets
  • Split — healthy
  • Fine-tune — healthy
  • Test set check — healthy
  • Small rollout — healthy
  1. Gather marked examples. The team collects 3,500 tickets, each tagged by a person with the label it should get.
  2. Set 500 aside. 500 tickets go to the test check and never take part in training.
  3. Tune on the rest. The other 3,000 train the model further, often through a small set of added numbers.
  4. Score unseen tickets. The tuned model labels the 500 it never saw, and that score is the honest one.
  5. Roll out small. Next, one user in twenty is served by it for a week, and it scores 87 there.
  6. Now you try. Pick how the tuned model was tested, and compare its test score with real use. For example: Test set: 99 in 100. Real use: 87 in 100. The model had seen the answers, so the test measured memory: a form of data leakage.

Scene 1 of 5: Gather marked examples. The team collects 3,500 tickets, each tagged by a person with the label it should get.

Key points

  1. Split the examples before training, and never test on training data.
  2. An honest test score sits close to the score in real use.
  3. A test that overlaps training data reports a score nobody will see.
  4. Release a tuned model to a small share of users first.

starts from a trained model and trains it a little more on your own examples: pairs of an input and the output you want. Clean, checked examples matter more than a large pile of noisy ones.

Keep some examples out of , as a test set. If the same examples are in both, the test score looks great and means nothing. This is one form of .

Parameter-efficient methods, such as , train a small set of added numbers instead of every . They need less memory, and the result is a small file used together with its base model.

Treat each tuned model as a release. Record which data and settings made it, and compare it with the current model on the same test set. Then send it a small share of traffic first.

Example. Illustrative: a team tunes a small model on 3,000 tagged tickets and keeps 500 apart for testing. It beats the current model on those 500, so it gets 5% of real traffic for a week before a wider rollout.

In system design: A tuned model is tied to its base model. When a better base model comes out, you tune again and run the same tests.

Check yourself

A tuned model scores 99 on a test set that overlaps its training data. What does that score tell you?