What is Machine Learning?

This cover signals the shift from explanation to execution. The earlier posts built the conceptual and mechanical model; this one is a copyable recipe that takes a real dataset all the way from raw arrays to an honestly evaluated, trained classifier using scikit-learn.

The goal is muscle memory for the loop you'll repeat on nearly every supervised problem: load features and labels, hold out a test set, fit a model, predict on unseen data, and score the result with metrics you can trust. By the end you should be able to start a fresh classification problem and move confidently through these stages without reaching for documentation at every step.

The first step in any supervised project is to get your data into features and labels. This slide loads the classic Iris dataset bundled with scikit-learn: 150 flower samples, each described by four measurements (the features, X) and tagged with one of three species (the labels, y). Printing the shapes confirms the structure — 150 rows by 4 feature columns, and 150 corresponding labels.

Using a built-in dataset removes friction so you can focus on the workflow rather than data cleaning. The mental model to carry forward is universal: X is a matrix of samples-by-features and y is a vector of one label per sample. Almost every scikit-learn model expects data in exactly this shape, so recognizing it on sight is foundational.

This slide performs the most important hygiene step in the whole workflow: holding out a test set before any training happens. train_test_split carves off 20% of the data for testing and leaves 80% for training. random_state=42 makes the split reproducible so your results don't change run to run. stratify=y ensures each class appears in the same proportion in both halves, which matters when classes are imbalanced.

The slide reinforces the discipline from the mechanics post in code form. The test set must be set aside now, before the model sees anything, so that the final score reflects performance on genuinely unseen data. Doing the split first is the single habit that most reliably separates trustworthy evaluations from self-deceiving ones.

This slide trains the model, and notably it's the shortest of the code slides — because in scikit-learn the actual learning is a single call. A RandomForestClassifier is created with 100 trees and a fixed random_state for reproducibility, and model.fit(X_train, y_train) does the work of learning from the training data.

The brevity is the point. All the conceptual machinery from the previous post — the iterative fitting, the internal parameter tuning — is hidden behind one method. RandomForest is a strong, forgiving default that works well out of the box on many tabular problems, which makes it an excellent first model to reach for before considering anything more elaborate.

This slide closes the loop by making predictions and scoring them. model.predict(X_test) runs the held-out samples through the trained forest to produce predicted species. accuracy_score then compares those predictions to the true labels and reports the fraction correct, here a high 96-100% because Iris is an easy dataset.

The crucial detail is that the score is computed on X_test — data the model never saw during fit. That's what makes the number meaningful. The slide demonstrates the payoff of the earlier split: only by evaluating on unseen data do you learn how the model will actually perform, rather than how well it memorized its training examples.

This slide pulls back the curtain on what that one fit call actually did. A random forest builds many decision trees — 100 here — each trained on a random subset of the rows and a random subset of the features. To make a prediction, every tree casts a vote and the majority class wins. fit ran the entire forest-construction process; predict simply runs new samples down the finished trees and tallies the votes.

Understanding this removes the black-box feeling. The single method call hides genuine machinery, and knowing roughly what it is helps you reason about behavior: why random forests resist overfitting (averaging many decorrelated trees), why they handle mixed feature types well, and why they give you feature-importance scores almost for free.

This slide explains why accuracy alone is a dangerous metric, setting up the deeper evaluation that follows. On imbalanced data accuracy can be high and meaningless: if 99% of emails are legitimate, a model that blindly predicts 'not spam' every time scores 99% accuracy while catching exactly zero spam. The single number conceals total failure on the class you actually care about.

That's why the classification report adds precision and recall. Precision asks: of the items I flagged, how many were truly positive? Recall asks: of all the truly positive items, how many did I catch? These two answer different and complementary questions, and reading them together — rather than trusting a lone accuracy figure — is what separates an honest evaluation from a misleading one.

This slide reads the errors with a confusion matrix and a full classification report. The confusion matrix is a grid where rows are the actual classes and columns are the predicted ones; correct predictions land on the diagonal and every mistake appears off-diagonal, showing you precisely which classes get confused for which. The classification report then computes precision, recall, and F1 for each class.

The value of looking at the matrix is diagnostic specificity. A single accuracy number tells you how often you're wrong but not how. The matrix shows the pattern of errors — maybe two similar species are mutually confused while the third is always right — which points you toward what to fix, whether that's more data for a hard class or better features to separate it.

This trace diagram explains the structure of a binary confusion matrix and the metrics derived from it. The four cells are true negatives, false positives, false negatives, and true positives. Predictions on the diagonal (TN and TP) are correct; the off-diagonal cells (FP and FN) are the two distinct ways the model can err. The diagram then shows that precision is TP divided by all predicted positives, while recall is TP divided by all actual positives.

Laying it out this way clarifies the trade-off that dominates real classification work. Reducing false positives raises precision but often costs recall, and vice versa. Which error matters more is a domain decision — a cancer screen prioritizes recall, a spam filter that must never block real mail prioritizes precision — and the confusion matrix is where you see that balance concretely.

This pipeline diagram zooms back out to the whole workflow, tying the code slides into one shape. Load produces X features and y labels. Split separates train and test sets. Fit trains the model on the training data. Evaluate scores it on the held-out test set. Each stage feeds the next, left to right.

Seeing the four stages as a pipeline reinforces that this same skeleton underlies essentially every supervised ML project, no matter the model or domain. Swap Iris for your own data and RandomForest for any other estimator, and the load-split-fit-evaluate flow is unchanged. Internalizing this pipeline means you carry a reliable structure into any new problem rather than improvising each time.

These bullets distill the entire walkthrough into the loop you'll actually repeat: load X (features) and y (labels), call train_test_split before doing anything else, fit the model on the training data, predict on the test data, and score with a metric appropriate to the problem.

If you keep this five-step rhythm in mind, you have a dependable scaffold for almost any supervised task. The specifics change per dataset and per model, but the sequence — load, split, fit, predict, score — is remarkably stable across the ML work you'll do day to day, which is exactly why it's worth committing to memory.

This closes the hands-on post and previews the final angle. You can now train and honestly evaluate a classifier end to end. The last post catalogs the common mistakes — the traps that don't crash your code but instead hand you a beautiful score that's secretly a lie — so you can recognize and avoid them before they cost you a model that fails the moment it meets real data.