Why a simple baseline belongs in every ML project

A model predicts that seventeen people will attend a workshop. Is that good? The prediction alone cannot tell you. You need the observed outcome, an error measure, and an alternative that the model is supposed to improve.

One useful baseline predicts the average attendance from training events. It ignores registrations entirely. A learned line uses registrations to estimate attendance. Evaluate both on the same held-out events with the same metric, and you have a comparison you can explain.

Mean absolute error is a natural starting point for this example. If the actual attendance values are 4, 8, and 12, while predictions are 5, 6, and 15, the absolute errors are 1, 2, and 3. Their mean is 2 attendees. The unit matters because the organizer makes decisions about people and materials, not an abstract score.

Inspect individual errors too. A model may be useful for small events and poor for large ones. An average can conceal that pattern. Write a table containing the actual value, prediction, and residual for each test event.

Keep the comparison honest. Do not compare one model's training score with another's test score. Do not change the test split until your preferred model wins. If you tune choices against a set of examples, treat those examples as part of development and plan an independent final check.

The Applied ML course includes an actual least-squares regression lab. It learns coefficients from a synthetic table and reports its baseline comparison. The exercise teaches the method; it does not establish that those results transfer to real academy attendance.

A strong beginner project can be small. What makes it credible is the chain from question to data, baseline, evaluation, and limitations. A clear account of why a model failed can demonstrate more understanding than an unexplained winning score.