This guide walks through the full process in Google Colab, from an empty notebook to a trained model you can run on images and video. As a running example I use my own car number plate detector: a labelled dataset from Roboflow, a free Colab T4 GPU and the Ultralytics YOLOv8 package. The final model reached 97.9% mAP@50 and 99.1% precision on its validation set, although, as you'll see below, it took me three training runs to get there.

What you need

• A Google account for Google Colab. The free tier is enough to start.
• Images of the object you want to detect, with bounding-box labels in YOLO format. I used a number plate dataset from Roboflow Universe, which exports straight to YOLOv8 format. CVAT and Label Studio work too if you label your own images.
• Time. A small dataset trains in under an hour; my final 50-epoch run took about 3.2 hours on a T4.

Step 1: Switch Colab to a GPU

Training on a CPU is painfully slow. In Colab, open Runtime → Change runtime type and pick a GPU, then check that it's there:

!nvidia-smi

You should see a table with the GPU name and memory. On the free tier I got an NVIDIA T4, which is plenty for a nano or small YOLO model. If you get an error, the runtime is still on CPU.

Step 2: Install Ultralytics

YOLOv8 is published by Ultralytics as a Python package:

!pip install ultralytics

import ultralytics
ultralytics.checks()

checks() prints the installed version, Python, PyTorch and whether CUDA (the GPU) is available.

Step 3: Prepare the dataset

YOLO expects one image folder and one label folder per split. Each image has a .txt file with the same name in the matching labels folder:

dataset/
├── data.yaml
├── train/
│   ├── images/   car_001.jpg, car_002.jpg, ...
│   └── labels/   car_001.txt, car_002.txt, ...
└── valid/
    ├── images/
    └── labels/

Each line in a label file describes one object:

0 0.512 0.634 0.180 0.062

The five numbers are the class index, then the box centre (x, y), width and height. All four box values are normalised to 0–1 by the image width and height, not in pixels. An image with no objects can have an empty label file; YOLO treats it as a background example, which helps reduce false positives.

The data.yaml file

data.yaml tells YOLO where the splits are and what each class index means. For a single-class detector like mine:

path: /content/dataset
train: train/images
val: valid/images

names:
  0: number_plate

For more classes, keep adding lines (1: helmet, 2: no_helmet, and so on). The indices must match the first number in your label files.

Getting the data into Colab

If your data is on Roboflow, open the dataset version, click Export, choose the YOLOv8 format and download the zip. It already has the folder layout above and a data.yaml.

The simplest way to get the zip into Colab is through Google Drive: upload it there, then unzip it onto the Colab machine. Reading thousands of small files directly from Drive is slow, so copy it to local disk first:

from google.colab import drive
drive.mount('/content/drive')

!unzip -q /content/drive/MyDrive/dataset.zip -d /content/

Check that /content/dataset/data.yaml exists before moving on, and open it once: exported files sometimes contain relative paths like ../train/images that don't match where you unzipped. A wrong path here causes the most common error at the next step: dataset not found.

Step 4: Train the model

Start from pretrained weights rather than from scratch. The model already understands edges, shapes and textures, so it only has to learn your object:

from ultralytics import YOLO

model = YOLO("yolov8n.pt")  # nano: smallest and fastest

results = model.train(
    data="/content/dataset/data.yaml",
    epochs=50,
    imgsz=640,
    batch=16,
)

These are exactly the settings I used for the number plate model. What each one means:

Ultralytics applies sensible augmentation by default: mosaic, horizontal flips, colour jitter, translation and scaling. It also switches mosaic off for the last 10 epochs (close_mosaic=10) so the model finishes on natural-looking images. You rarely need to change these for a first run.

Where the results go

Everything is saved to runs/detect/train/ (the next run goes to train2, and so on):

• weights/best.pt: the checkpoint with the best validation score. This is the one you use.
• weights/last.pt: the latest checkpoint, for resuming.
• results.csv and results.png: loss and metrics for every epoch.
• confusion_matrix.png, precision-recall and F1 curves, and sample predictions on validation images.

Save your work before Colab disconnects

Colab deletes the machine's files when the session ends. Copy the run folder to Drive as soon as training finishes:

!cp -r /content/runs/detect/train /content/drive/MyDrive/yolo_runs/

If the session drops in the middle of training, resume from the last checkpoint instead of starting over:

model = YOLO("/content/runs/detect/train/weights/last.pt")
model.train(resume=True)

This happened to me: on the free tier, my Colab session disconnected partway through a multi-hour run. Ultralytics saves last.pt after every epoch, so I resumed from it and training continued from the epoch where it stopped, with the same settings, instead of starting again from epoch 1. It only works if last.pt still exists, so on long runs copy the run folder to Drive regularly, not just at the end.

Step 5: Read the metrics

After training, validate the best checkpoint:

model = YOLO("/content/runs/detect/train/weights/best.pt")
metrics = model.val()

print(f"Precision: {metrics.box.mp:.3f}")
print(f"Recall:    {metrics.box.mr:.3f}")
print(f"mAP@50:    {metrics.box.map50:.3f}")
print(f"mAP@50-95: {metrics.box.map:.3f}")

What the four numbers mean:

• Precision: of the boxes the model drew, how many were correct. Low precision means false alarms.
• Recall: of the real objects, how many the model found. Low recall means missed objects.
• mAP@50: average precision when a box only needs to overlap the true box by 50%. A good "did it find the object" score.
• mAP@50-95: the same, averaged over stricter overlaps from 50% to 95%. This measures how tight the boxes are.

For a deeper explanation of each metric, with training curves from four of my models and what to do when a number is low, see YOLOv8 Metrics Explained: Precision, Recall and mAP.

Here is how those numbers developed on my number plate model:

Two things stand out. First, transfer learning does the heavy lifting: after a single epoch the model already scored 88.9% mAP@50. Second, after epoch 20, mAP@50 barely moves, but mAP@50-95 keeps climbing. The later epochs are making the boxes tighter, which matters if you crop the detection for another step, like reading the plate with OCR.

Step 6: Run the model on images and video

Use best.pt for predictions. The same call works for a single image, a folder, a video file or a webcam:

model = YOLO("/content/runs/detect/train/weights/best.pt")

results = model.predict(source="test_car.jpg", conf=0.5, save=True)
model.predict(source="traffic.mp4", conf=0.5, save=True)

conf=0.5 hides detections below 50% confidence. Raise it if you see false positives, lower it if the model misses objects. Annotated images and videos are saved under runs/detect/predict/.

Here is a frame from my model running on a highway test video:

Output of my trained model on a test clip: the plates of the two nearest vehicles are detected with 0.79 and 0.77 confidence.

The frame also shows something the validation numbers don't. The model reliably finds plates close to the camera, but plates further back are only a few pixels tall in this 852×480 clip, and it doesn't detect them. Validation images look like the training set; real footage is a different test. For a real ANPR camera, higher resolution or a camera closer to the lane matters as much as the model. You can watch the full demo video on LinkedIn.

To use the detections in your own code, read the boxes from the results:

for box in results[0].boxes:
    x1, y1, x2, y2 = box.xyxy[0].tolist()
    print(f"class={int(box.cls)} conf={float(box.conf):.2f} box=({x1:.0f}, {y1:.0f}, {x2:.0f}, {y2:.0f})")

Step 7: Export for deployment

For production, export the model to a format your target runtime understands:

model.export(format="onnx")

ONNX runs almost anywhere, including CPU servers. Other options include engine (TensorRT, for NVIDIA GPUs and Jetson boards), tflite (mobile) and openvino (Intel CPUs).

What went wrong in my training

The numbers in this post come from my third training run. Ultralytics names each new run folder train, train2, train3, so the history is right there in runs/detect/.

• Colab disconnected mid-training. Free Colab sessions don't last forever, and a 50-epoch run takes hours. Resuming from last.pt (see Step 4) saved me from restarting from scratch.
• The first results weren't good enough. My first run didn't reach the accuracy I wanted, so I changed the training settings and trained again. The final run used the settings shown in Step 4.

What I'd tell myself before starting: save to Drive from the beginning, and when a run disappoints, change one setting at a time and compare the results.csv files. Otherwise you can't tell which change actually helped.

Common problems and fixes

• "Dataset not found": the paths in data.yaml are wrong. Use an absolute path: like /content/dataset and check the folder names match (valid vs val is a classic).
• CUDA out of memory: lower batch (16 → 8) or use batch=-1.
• Zero or very low mAP: usually a labelling problem. Check that label files have the same names as the images, that coordinates are normalised to 0–1, and that class indices match data.yaml.
• Good validation scores, poor results on real footage: the training images don't look like the real camera. Add images from the actual setting: same angle, lighting and resolution.
• Training is slow: confirm the GPU is active (Step 1), and keep the dataset on Colab's local disk rather than reading it from Drive.

Where to go next

• Compare model sizes: train yolov8s.pt with the same data and see whether the accuracy gain is worth the extra size and latency.
• The same workflow works for newer Ultralytics models such as YOLO11: change the weights file (for example yolo11n.pt) and keep everything else.
• Check the licence before commercial use: Ultralytics models are released under AGPL-3.0, with a separate enterprise licence for closed-source products.

The trained weights (best.pt) and detection script for this guide are on GitHub, and the full design decisions, training curve and next steps are in the car number plate detection case study.

Most explanations stop at the definitions. In this post I explain each metric with real training results from four models I trained with Ultralytics YOLOv8: a number plate detector, an office activity tracker, a plant disease detector and a fire and smoke detector. They are very different tasks, and their numbers tell very different stories.

If you haven't trained a model yet, start with my step-by-step guide: Train YOLOv8 on a Custom Dataset in Google Colab.

The four models in this post

And their final validation results, taken from the metrics Ultralytics saves inside each model's best.pt:

Keep this table in mind. By the end of the post, you'll be able to read it like a diagnosis.

Where these numbers come from

Every number in this post is measured on the validation split: the images listed under val: in your data.yaml, which the model never trains on. After each epoch, Ultralytics runs the model on those images, compares its boxes with the labels and logs the results to runs/detect/train/results.csv.

You'll see the metrics written as metrics/precision(B) or metrics/mAP50-95(B). The (B) means box. Segmentation models also log a second set marked (M) for mask, measured on the pixel masks instead of the boxes.

IoU: how YOLO decides a box is "correct"

Every metric depends on one question: did the predicted box land on the object? YOLO answers it with IoU, Intersection over Union:

IoU = area where the two boxes overlap / area covered by both boxes together

• IoU = 1.0: the predicted box matches the labelled box exactly.
• IoU = 0.5: they overlap by about half.
• IoU = 0: they don't touch.

A prediction counts as a true positive if it has the right class and its IoU with a labelled box is above a threshold. Everything else is a false positive. A labelled object that no prediction matched is a false negative, a miss.

Hold on to the threshold: it's the whole difference between mAP50 and mAP50-95.

Precision: when the model says "plate", is it right?

Precision = true positives / everything the model detected

Precision answers: of the boxes the model drew, how many were real objects? Low precision means false alarms: boxes on things that aren't there.

My number plate model has 99.1% precision: almost every box it draws is a real plate. That matters, because in a number plate recognition system every false box triggers an OCR read and can create a wrong record.

Recall: of the real objects, how many did it find?

Recall = true positives / all objects in the labels

Recall answers: of everything that was really there, how much did the model find? Low recall means misses.

The same number plate model has 94.7% recall: it finds about 95 of every 100 plates. Very good, but notice it's lower than its precision. The model is slightly conservative: it would rather skip a plate than draw a wrong box.

Precision and recall pull against each other

Each detection comes with a confidence score, and the threshold you choose moves the balance. A high threshold keeps only confident boxes: precision goes up, recall goes down. A low threshold catches more objects, along with more false alarms.

One detail that confuses many people: the P and R that Ultralytics prints are not measured at your conf=0.5. They're reported at the confidence threshold that gives the best F1 score (the balance of precision and recall) on the validation set. In deployment you pick your own threshold, so your real-world precision and recall will be different. Use the printed P and R to compare models, and the precision-recall and F1 curves in the run folder to choose your threshold.

A real example: a model that was too cautious

My fire and smoke detector is the clearest example of precision and recall telling different stories.

Precision and recall of my fire and smoke model after every epoch of training.

At epoch 10, precision was 73.8% but recall only 30.7%. Precision even peaked at 80.0% at epoch 23, while recall was just 43.3%. If you only looked at precision, you'd think the model was nearly done. It wasn't: it only fired on the most obvious flames and missed most of the fire and smoke in the images.

From epoch 10 to epoch 100, recall more than doubled, from 30.7% to 63.8%, while precision settled in the 60s. The final model is less precise than at epoch 23, and far more useful, because it actually finds the fire. A fire alarm that misses most fires is worse than one with a few false alarms you can filter out.

The lesson: never judge a model on precision alone, or recall alone. Look at both, and decide which mistake costs more in your application.

AP and mAP: one number for the whole curve

Since precision and recall depend on the threshold, we want one number that covers every threshold. That's Average Precision (AP): sort all detections by confidence, trace precision against recall, and measure the area under that curve. A perfect model scores 1.0 (100%).

AP is calculated per class. mAP, mean Average Precision, is the average across all classes. For my 29-class plant model, mAP is the average of 29 separate AP scores, so a few weak classes can pull the total down even if most classes are good.

mAP50 vs mAP50-95: the difference that matters most

• mAP@50 (also written mAP50 or mAP@0.5) counts a detection as correct if its IoU is at least 0.5. It asks: did the model find the object?
• mAP@50-95 calculates mAP at ten IoU thresholds, 0.50, 0.55, 0.60 … 0.95, and averages them. At 0.95, the box has to be almost pixel-perfect. It asks: how precisely did the model outline the object?

That's why mAP@50-95 is always lower than mAP@50, and why the gap between them is so informative. Here is how both developed while training my number plate model:

mAP@50 and mAP@50-95 of my number plate model after every epoch.

Two things stand out:

1. mAP@50 was high almost immediately. Thanks to the pretrained weights, the model hit 88.9% after a single epoch and was close to its final level by epoch 20. Finding plates was easy.
2. mAP@50-95 kept climbing long after mAP@50 had flattened, from 77.3% at epoch 20 to 79.8% at its best. The later epochs weren't teaching the model to find more plates; they were teaching it to draw tighter boxes. For a plate that gets cropped and passed to OCR, that is exactly the improvement you want.

The gap tells you how well-defined your objects are

Now look at the gap between mAP@50 and mAP@50-95 across all four models:

People and number plates have clear edges: everyone would draw roughly the same box around them, so the model can match the labels closely and the gap stays small.

Smoke has no edges at all. Where does a cloud of smoke end? Two people labelling the same image would draw different boxes, so even a perfect model can't hit IoU 0.95 consistently. Leaves in the plant dataset overlap, curl and fade into the background, which creates the same problem.

So a low mAP@50-95 is not always the model's fault. When the gap is large, check your labels before you blame the model.

Why more classes means lower numbers

My plant disease model has the lowest mAP@50 of the three nano models, 79.6%, and it's arguably the most impressive. It has to tell apart 29 classes, many of which look almost identical: tomato early blight vs tomato late blight vs tomato septoria leaf spot. The number plate model has one class and nothing to confuse it with.

Never compare mAP across different datasets as if it were the same test. 79.6% on 29 look-alike classes and 97.9% on one distinctive class are both good results.

Reading the training curve: is the model done?

The curves above answer another important question: should you train longer?

• The curve has flattened (number plate, after about epoch 40): more epochs won't help much. Improve the data or try a bigger model instead.
• The curve is still rising at the last epoch (plant disease and fire & smoke both had their best mAP@50-95 at their final epoch, 70 and 100): the run ended too early. Train longer.
• Training loss keeps falling but validation loss starts rising: the model is memorising the training images (overfitting). Stop earlier, add more data or augmentation.

Which epoch does best.pt come from?

Ultralytics saves the epoch with the best fitness score as best.pt. In all four of my runs, the fitness value stored in best.pt is exactly the mAP@50-95 score, so best.pt is the epoch with the highest mAP@50-95. For the number plate model that was epoch 42 of 50, which is why its final best.pt numbers (97.9% mAP@50) are slightly different from the last epoch's (98.1%).

You can find the best epoch yourself from results.csv:

import pandas as pd

df = pd.read_csv("runs/detect/train/results.csv")
df.columns = df.columns.str.strip()  # older versions pad the column names with spaces

best = df.loc[df["metrics/mAP50-95(B)"].idxmax()]
print(best[["epoch", "metrics/precision(B)", "metrics/recall(B)",
            "metrics/mAP50(B)", "metrics/mAP50-95(B)"]])

Look at every class, not just the average

For multi-class models, the overall mAP hides your weakest classes. Validate best.pt and print the score per class:

from ultralytics import YOLO

model = YOLO("runs/detect/train/weights/best.pt")
metrics = model.val()

for i, score in enumerate(metrics.box.maps):  # mAP@50-95 per class
    print(f"{model.names[i]:<35} {score:.3f}")

The classes at the bottom of that list tell you exactly where to collect more images.

What to do when a number is low

Which metric should you report?

There is no single right answer; it depends on what a mistake costs:

• Number plate recognition: the detection is cropped for OCR, so tight boxes matter. Report mAP@50-95 alongside precision.
• Fire and safety alarms: a missed fire is the worst outcome. Report recall, and precision at the threshold you deploy with.
• Counting and analytics (office activity, livestock): missing people skews the totals, so recall matters, while mAP@50 is a fair summary of detection quality.
• Comparing two models on the same dataset: mAP@50-95 is the most complete single number, and it's what COCO benchmarks use.

Whatever you report, say which split it's measured on and at what confidence threshold. "97.9% mAP@50 on the validation set" is a result; "97.9% accuracy" is not.

Cheat sheet

• IoU: how much a predicted box overlaps the real one.
• Precision: of the boxes drawn, how many were right. Low = false alarms.
• Recall: of the real objects, how many were found. Low = misses.
• mAP@50: did the model find the objects?
• mAP@50-95: did it outline them precisely?
• A big gap between the two: fuzzy objects or inconsistent labels.
• Best epoch is the last epoch: train longer.

The full training details behind each model are in the case studies: number plate, office activity, plant disease and fire & smoke detection.