2.1 — Machine Learning Basics

1. What is it?

Machine learning is the practice of building systems that improve at a task from data/experience rather than from explicitly programmed rules. This chapter covers the conceptual core you actually need as an AI FDE: what "learning" means mathematically, supervised vs. unsupervised vs. reinforcement learning, overfitting/generalization, and the evaluation mindset — not a from-scratch derivation of every classical algorithm.

2. Why does it exist?

Traditional software requires a human to write every rule (if total > 10000: flag_for_review). Many real problems don't have rules that are practical to hand-write (what does spam "look like," precisely, in a way that covers every case and adapts as spammers adapt?). ML exists to let a system infer the rule from labeled examples instead of a human enumerating it.

3. What problem does it solve?

For an AI FDE, understanding ML fundamentals matters less for building classical ML models yourself (LLMs have absorbed much of that work) and more for diagnosing behavior and setting expectations correctly with customers: understanding why a model generalizes or fails to, why more data sometimes helps and sometimes doesn't, why a model that's 95% accurate can still be useless (class imbalance), and why "the AI is wrong sometimes" isn't a bug to be fixed to zero, it's a property to be measured and managed.

4. How does it work internally?

The learning objective

Almost all ML reduces to: define a loss function (a number that's small when the model is right and large when it's wrong), and adjust the model's parameters to make that number smaller, using an optimization algorithm (gradient descent and its variants, for the vast majority of modern ML including every LLM). The model doesn't "understand" anything in a human sense — it's parameters tuned to minimize a mathematical objective over the training data it saw.

Data

Modelparams θ, updated via gradient descent

Prediction

Lossvs. true label

The loss feeds back into θ every training step — not drawn as a loop here, but it repeats until convergence.

Supervised, unsupervised, reinforcement — and where LLMs fit

• Supervised learning: learn a mapping from inputs to known correct outputs (classification, regression). Most classical business ML (fraud detection, churn prediction) is supervised.
• Unsupervised learning: find structure in data without labels (clustering, dimensionality reduction). Embeddings (Part 2.5) are a form of unsupervised/self-supervised representation learning.
• Reinforcement learning (RL): learn by taking actions and receiving rewards, optimizing for cumulative reward over time. Modern LLM training pipelines use RL-derived techniques (RLHF/RLAIF-style approaches) as part of the "alignment" phase, on top of a base model trained with a different, self-supervised objective (predicting the next token) — worth knowing this distinction because customers sometimes conflate "an LLM" with "one kind of learning" when it's actually a pipeline of several.

Overfitting, underfitting, and generalization

A model that memorizes the training data (fits noise, not signal) performs great on data it's seen and poorly on new data — overfitting. A model too simple to capture the real pattern performs poorly on both — underfitting. This is why you always evaluate on held-out data (a validation/test set) the model never trained on — training accuracy alone tells you almost nothing about real-world performance.

Error
  │      training error (keeps dropping)
  │  ╲___
  │      ╲___________________________
  │
  │      validation error (drops, then rises — overfitting starts here)
  │  ╲___╱‾‾‾‾‾‾‾‾‾‾╲___________________
  └──────────────────────────────────► model complexity / training time

5. Simple mental model

Think of ML training as a student cramming for an exam using only practice questions: if they memorize the exact practice questions (overfitting), they'll fail a real exam with different questions. If they study too little or too simplistically (underfitting), they'll fail both. Good learning means extracting the underlying pattern from the practice questions, which is exactly what a held-out validation set is designed to check for.

6. Real-world example

A bank builds a fraud-detection classifier. On their training data it's 99.5% accurate — but fraud is rare (0.5% of transactions), so a model that always predicts "not fraud" is also 99.5% accurate and catches zero fraud. This is why accuracy alone is a misleading metric under class imbalance, and why precision/recall/F1 (and the specific business cost of false positives vs. false negatives) matter far more than a single accuracy number — a distinction that comes up constantly when a customer asks "how accurate is the AI" and the honest answer requires unpacking what "accurate" should even mean for their specific problem.

7. Architecture diagram

Raw datalabeled

Feature engineeringpreprocessing

Model trainingminimize loss

Evaluationheld-out data · generalization check

The standard supervised-learning pipeline, end to end.

8. Production considerations

• Data drift: the distribution of real-world input data shifts over time (customer behavior changes, new fraud patterns emerge) — a model trained once and never re-evaluated degrades silently. This concept transfers directly to LLM-based systems: the documents your RAG system retrieves over, or the kinds of questions users ask, drift too, and need monitoring (Part 8).
• Held-out evaluation discipline applies directly to prompt/agent evaluation: never judge a prompt change only against the examples you used to write it — evaluate against a separate held-out set (Part 8).
• Class imbalance and its metric implications (precision/recall trade-offs) recur directly in LLM evaluation — e.g., a hallucination-detection classifier facing a low base rate of actual hallucinations has the same accuracy-is-misleading problem as the fraud example above.

9. Common mistakes

• Reporting or accepting a single accuracy number without asking about class balance and the actual cost of each error type.
• Evaluating a model (or a prompt/agent) only on the examples used to develop it, never on a genuinely held-out set.
• Assuming "more data always helps" — more data doesn't fix a fundamentally wrong feature set, a mismatched objective, or a fundamentally different real-world distribution than what was collected.

10. Security considerations

• Training data can leak into model behavior (memorization) — a classical ML concern that has a much more acute analogue in LLMs (Part 2.6, and Part 9 on data leakage): a model can reproduce sensitive information it was trained or fine-tuned on.
• Adversarial examples (inputs deliberately crafted to fool a model) are a real classical-ML security concern and a direct conceptual ancestor of prompt injection (Part 9.1) — both exploit the gap between "what the model actually optimized for" and "what a human assumes it's doing."

11. Performance considerations

• Model complexity vs. inference latency/cost is a real trade-off in classical ML (a deep ensemble is more accurate but slower) that maps directly onto LLM model selection (Part 3.11): a bigger model is often more capable but slower and more expensive per call.

12. Cost considerations

• Data labeling, feature engineering, and training compute are the classical ML cost centers; in the LLM era, most of that cost has shifted to prompt/context engineering and API usage — but the underlying trade-off (invest more in the input pipeline vs. accept lower quality) is structurally the same conversation with a customer.

13. When to use it

Classical supervised ML remains the right tool for well-defined, structured-data prediction problems with clear labels and enough historical data (credit scoring, demand forecasting, churn prediction) — often cheaper, faster, and more interpretable than reaching for an LLM.

14. When NOT to use it

• Don't reach for classical ML (or an LLM) when a deterministic rule actually captures the business logic correctly and completely — simpler is more maintainable and more explainable to auditors/regulators.
• Don't assume every prediction problem needs a custom-trained model today — many tasks that used to require training a bespoke classifier (sentiment, basic classification, extraction) are now often better served by a well-prompted LLM with far less data/engineering investment, especially early in a project (Part 3.1).

15. Alternatives and trade-offs

Approach	Good for	Weak point
Rule-based system	Fully deterministic, explainable, auditable logic	Doesn't scale to fuzzy/complex patterns; brittle to edge cases
Classical ML (trained on your data)	Structured, well-labeled, high-volume prediction problems	Needs labeled data, retraining pipeline, MLOps investment
LLM (prompted, zero/few-shot)	Fast to prototype, no training data needed, handles unstructured/fuzzy input	Higher per-inference cost/latency, less predictable, harder to audit exactly why it decided something

16. Practical Python/code example

from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import precision_score, recall_score, f1_score

X_train, X_test, y_train, y_test = train_test_split(
    features, labels, test_size=0.2, stratify=labels, random_state=42
)

model = LogisticRegression(class_weight="balanced")
model.fit(X_train, y_train)

predictions = model.predict(X_test)
print(
    f"precision={precision_score(y_test, predictions):.3f} "
    f"recall={recall_score(y_test, predictions):.3f} "
    f"f1={f1_score(y_test, predictions):.3f}"
)

Note stratify=labels (preserves class balance across the split) and class_weight="balanced" (compensates for imbalance during training) — both directly address the fraud-example problem in section 6.

17. Production-quality example

A minimal, honest evaluation report generator — the kind of artifact an FDE should produce when a customer asks "how good is this model," forcing the imbalance/cost conversation explicitly rather than hiding behind one number:

from dataclasses import dataclass
from sklearn.metrics import confusion_matrix, precision_score, recall_score, f1_score


@dataclass
class EvaluationReport:
    """A structured evaluation summary that resists being reduced to one misleading number."""
    accuracy: float
    precision: float
    recall: float
    f1: float
    true_positives: int
    false_positives: int
    false_negatives: int
    class_balance: dict[str, float]


def build_evaluation_report(y_true, y_pred, positive_label=1) -> EvaluationReport:
    """
    Builds a full evaluation report that surfaces class imbalance and error types
    explicitly, rather than a single accuracy figure.

    Args:
        y_true: Ground-truth labels for the held-out set.
        y_pred: Model predictions for the same set.
        positive_label: The label considered "positive" (e.g., fraud=1).

    Returns:
        EvaluationReport: A structured report suitable for a customer-facing summary.
    """
    tn, fp, fn, tp = confusion_matrix(y_true, y_pred, labels=[0, 1]).ravel()
    total = tn + fp + fn + tp
    return EvaluationReport(
        accuracy=(tp + tn) / total,
        precision=precision_score(y_true, y_pred, pos_label=positive_label),
        recall=recall_score(y_true, y_pred, pos_label=positive_label),
        f1=f1_score(y_true, y_pred, pos_label=positive_label),
        true_positives=tp,
        false_positives=fp,
        false_negatives=fn,
        class_balance={"positive_rate": sum(y_true) / total},
    )

18. Short exercise

A customer shows you a model with "99.2% accuracy" for detecting a rare equipment failure that occurs in 0.5% of readings. Write out the three questions you'd ask before accepting that number as evidence the model is good.

19. Interview questions

• Why is accuracy a misleading metric under class imbalance, and what would you use instead?
• Explain overfitting vs. underfitting and how a held-out validation set detects each.
• How does the concept of data drift in classical ML apply to a production RAG or agent system?

20. FDE/customer scenario

Customer: "We built an in-house model last year for X and it's not performing well anymore, can your AI replace it?"

Before proposing anything, an FDE would ask: has the underlying data distribution shifted since it was trained (drift)? Was it ever validated properly on held-out data, or just on training performance? What's the actual cost of the errors it makes today (false positives vs. false negatives), and does the customer's real complaint match that cost profile, or something else entirely (e.g., the model is fine but the surrounding process/UI is the actual problem)? This diagnostic instinct — check the fundamentals before proposing a new solution — is the through-line of the entire FDE layer (Part 12).

---

Key takeaways

• ML reduces to optimizing a loss function over training data; generalization (not training performance) is what matters.
• Class imbalance makes accuracy alone a dangerous metric — precision/recall/F1 and business cost of errors matter more.
• Data drift and held-out evaluation discipline apply directly to LLM/agent systems, not just classical ML.

Things you should be able to explain

• Overfitting vs. underfitting and why held-out evaluation catches both.
• Why a high accuracy number can hide a useless model.

Things you should be able to build

• An evaluation report that surfaces class imbalance and error types rather than one summary number.

Common mistakes

• Trusting accuracy alone under class imbalance.
• Evaluating only on training/development examples.

Recommended next chapter

02-dl-basics.md