What is AI? & Machine Learning Fundamentals
Start here with zero AI knowledge assumed. This note builds your mental model of what Artificial Intelligence is, how it differs from the software you already know, and how Machine Learning — its most important subset — actually works under the hood. These concepts underpin every chapter of the CT-AI syllabus.
Why AI Exists — History & Motivation
Before any technical definition, understand the problem AI is trying to solve. Traditional software works by a programmer writing explicit rules: if this happens, do that. This works brilliantly for problems where the rules are known and finite — calculating tax, sorting a list, processing a payment. But many real-world problems have rules that are too complex, too numerous, or simply unknown to write by hand.
Consider teaching a computer to recognise a cat in a photo. You could try writing rules: "it has pointy ears, whiskers, fur…" — but cats appear in every lighting condition, angle, size, breed, and pose. You would need millions of rules, and you'd still miss cases. The rules approach breaks down.
Instead of telling the computer the rules, what if we showed it thousands of examples and let it figure out the rules itself? That shift in thinking is the origin of Machine Learning — and it is the most important sentence in this entire note.
A Brief Timeline (So You Have Context)
Understanding the era matters because the CT-AI exam references AI technologies across generations:
AI-Based vs Conventional Software — The Key Difference
This comparison is directly examinable in CT-AI. You must be able to identify which properties belong to which type of system, and explain why AI-based systems need a different testing approach.
- Deterministic — same input always produces same output, every single time
- Explicit rules — logic is written by a developer and is readable
- Explainable by design — you can trace exactly which line of code made a decision
- Static behaviour — doesn't change after deployment unless you redeploy
- Binary correctness — output is either right or wrong
- Reproducible — run the same test 1000 times, get the same result
- Probabilistic — same input can produce different outputs in different runs
- Learned behaviour — the "logic" is encoded in millions of numerical weights, not code
- Black box — often impossible to trace exactly why a decision was made
- Can adapt — some AI systems update themselves after deployment (adaptive)
- Statistical correctness — correctness is measured over a distribution of inputs
- Non-reproducible — the same prompt to an LLM might return different wording each time
Traditional testing assumes: write a test, run it, get a definitive pass or fail. That contract breaks with AI. You can't write a traditional test oracle (the thing that says "this output is correct") for a system whose output is inherently probabilistic. This is the test oracle problem — a major topic in CT-AI Chapter 4. Everything you learn here is the foundation for understanding why AI needs its own testing discipline.
The Java Analogy — If-Else vs Model
Imagine building a loan approval system. Here's how the two paradigms differ in code:
// CONVENTIONAL: Rules explicitly written by a developer // Every decision path is readable, traceable, reproducible public class LoanApprovalConventional { public boolean approve(Applicant applicant) { // Rule 1: minimum credit score if (applicant.getCreditScore() < 650) { return false; // ALWAYS false for score < 650 } // Rule 2: debt-to-income ratio must be under 40% double dti = applicant.getMonthlyDebt() / applicant.getMonthlyIncome(); if (dti > 0.40) { return false; } // Rule 3: employment history if (applicant.getYearsEmployed() < 2) { return false; } return true; // Testing this is straightforward: // Input: creditScore=700, dti=0.30, years=3 → ALWAYS approves // Input: creditScore=600 → ALWAYS rejects // Same test, same result, every single time. } }
// AI-BASED: The "rules" are not written — they are LEARNED // from 10 million historical loan decisions public class LoanApprovalML { private MLModel model; // loaded trained model (thousands of weights) public Prediction approve(Applicant applicant) { // Features extracted from applicant data // The model was trained to understand which combinations // of these features historically led to repayment vs default double[] features = { applicant.getCreditScore(), applicant.getMonthlyIncome(), applicant.getMonthlyDebt(), applicant.getYearsEmployed(), applicant.getLoanAmount(), applicant.getAge() // ... potentially 50+ more features }; // The model outputs a PROBABILITY (0.0 to 1.0) // NOT a hard yes/no — a confidence score double approvalProbability = model.predict(features); // Testing challenge: // Same applicant data → model might give 0.73 one run, 0.71 next // (due to non-determinism in some model types) // // WHY did it approve? You can't read the reason from the code. // The "reason" is distributed across thousands of weights. // This is the BLACK BOX problem. // // Is 0.73 correct? Who decides the threshold? What if the // training data had historical bias against certain demographics? return new Prediction(approvalProbability > 0.7, approvalProbability); } }
With the conventional system, you can enumerate all paths and achieve 100% branch coverage. With the ML system, you're testing statistical behaviour across a distribution of inputs. "Correct" is no longer binary. The entire CT-AI certification exists because of this gap.
The AI → ML → Deep Learning Nesting
These three terms are used interchangeably in everyday conversation, but in the exam they have precise, distinct meanings with a specific containment relationship.
Any technique that enables machines to mimic human intelligence — including rule-based systems, search algorithms, expert systems, and learning systems. The broadest possible umbrella.
The subset of AI where systems learn patterns from data without being explicitly programmed. The rules are inferred, not written. Includes SVMs, decision trees, random forests, neural networks, and more.
The subset of ML using multi-layered neural networks (deep = many layers). Powers image recognition, speech, LLMs. Requires large data and GPU compute. Tends to be the "black box" due to its complexity. Examples: CNNs, RNNs, Transformers.
Not all AI is ML. An expert system with 10,000 hand-coded rules is AI, but it is not ML — it doesn't learn from data. Not all ML is Deep Learning. A logistic regression model (simple linear ML) is ML but not DL. The exam will test these distinctions.
| Term | Definition | Learns from data? | Needs neural nets? | Example |
|---|---|---|---|---|
| AI | Any system simulating human-like intelligence | Not necessarily | Not necessarily | Chess engine (rule-based search) |
| ML | AI that learns patterns from data without explicit rules | Yes — required | Not necessarily | Decision tree for spam detection |
| Deep Learning | ML using deep multi-layer neural networks | Yes — required | Yes — required | GPT-4, image classifiers, AlphaGo |
Narrow AI / General AI / Super AI
The CT-AI syllabus explicitly requires you to distinguish these three categories. They describe scope of capability, not the underlying technique.
CT-AI is entirely about Narrow AI in practice. Every testing technique, every quality characteristic, every dataset consideration in the syllabus applies to real-world Narrow AI systems. AGI and ASI appear only as definitional K1 knowledge — you need to define them, not test them.
AI Technology Types — The Landscape
The CT-AI syllabus lists specific AI technology categories. You need to recognise each, understand what it does, and map it to a real-world example. The table below is your reference:
| Technology | What it does | Real-world example | Exam relevance |
|---|---|---|---|
| Supervised ML | Learns from labelled examples (input→output pairs) | Spam filter, loan approval, image classifier | High — core of Ch.3 |
| Unsupervised ML | Finds hidden patterns in unlabelled data | Customer segmentation, anomaly detection | Medium |
| Reinforcement Learning | Agent learns by trial-and-error via rewards/penalties | AlphaGo, robotics, ad bidding systems | Medium |
| Deep Learning / Neural Networks | Multi-layer networks learning complex representations | Image recognition, speech-to-text | High — Ch.3 neural network testing |
| Natural Language Processing (NLP) | Understanding and generating human language | Chatbots, sentiment analysis, translation | Medium |
| Computer Vision | Extracting meaning from images and video | Medical imaging, autonomous vehicles, facial recognition | Medium |
| Fuzzy Logic | Handles imprecision and vague rules (degrees of truth) | Washing machine cycles, HVAC systems | Low — definitional K1 |
| Expert Systems | Encodes human expert knowledge as IF-THEN rules | Medical diagnosis support (1980s MYCIN) | Low — historical context |
| Generative AI (GenAI) | Creates new content — text, images, code, audio | ChatGPT, DALL-E, Midjourney, GitHub Copilot | Very High — Ch.4 dedicated section |
| Agentic AI | AI that takes actions autonomously towards a goal, often using tools | AI agents that browse web, run code, call APIs | Medium — growing topic in v2.0 |
GenAI Sub-technologies (CT-AI v2.0 Specific)
CT-AI v2.0 added dedicated GenAI coverage. Know these three sub-types:
Real-World AI Decoded — What's Actually Happening
Before moving to ML mechanics, ground your understanding in everyday AI systems. For each, identify what type it is, what it learned, and why it's hard to test.
| System | AI Type | What the model learned | Testing challenge |
|---|---|---|---|
| Gmail spam filter | Supervised ML (classification) | Patterns in email headers, links, language that correlate with spam vs not-spam labels | Spam evolves — what was spam yesterday might not trigger today; false positives lose legitimate emails |
| Netflix recommendations | Unsupervised + Supervised ML | Viewing patterns of millions of users; which users are similar; which content correlates with satisfaction | No single "correct" recommendation; success measured statistically by watch-time and ratings |
| Siri / Alexa | Deep Learning (NLP + Speech) | Audio → text (speech recognition model) + text → intent (NLP model) | Accents, background noise, ambiguity — "play songs by rocks" vs "play songs by The Rock" |
| Credit card fraud detection | Supervised ML (binary classification) | Historical transaction patterns that were labelled as fraud or legitimate | Class imbalance — fraud is rare, so a model that always says "not fraud" is 99.9% accurate but useless; precision vs recall tradeoff |
| ChatGPT / Claude | Deep Learning (LLM, GenAI) | Next-token prediction across trillions of internet text tokens | No ground truth for most responses; hallucinations; safety testing; prompt injection; non-determinism |
What is a Model? — The Central Object
The word "model" appears hundreds of times in the CT-AI syllabus. You need a precise mental picture of what it actually is — not "an AI thing," but a specific mathematical object.
Think of it this way: in Java, you write a function like
double predictPrice(double size, double bedrooms).
The body of that function — the actual math — was learned from thousands of house sales.
You don't write the body. The training algorithm writes it for you by adjusting the weights until
predictions match the training examples.
// A simple linear model (most basic form) for house price prediction // y = w1*x1 + w2*x2 + b // // x1 = house size (sq ft) // x2 = number of bedrooms // w1, w2 = WEIGHTS — numbers the training process determines // b = BIAS — a constant offset term, also learned // y = predicted price public class LinearModel { // These values were NOT written by a programmer. // They were found by the training algorithm after seeing // thousands of (size, bedrooms, actual_price) examples. private double w1 = 150.5; // weight for house size private double w2 = 8200.0; // weight for bedrooms private double b = -12000.0; // bias public double predict(double sizeSqFt, double bedrooms) { return w1 * sizeSqFt + w2 * bedrooms + b; // For a 1500 sqft, 3-bedroom house: // = 150.5 * 1500 + 8200 * 3 + (-12000) // = 225750 + 24600 - 12000 // = $238,350 predicted price } } // A real model might have MILLIONS of weights instead of 2. // The math is the same — just vastly more dimensions. // The key insight: the weights ARE the model.
- Weight — a learnable number that determines how much influence one input has on the output
- Bias — a learnable offset constant that shifts the output independently of inputs
- Parameter — collective term for all weights and biases in a model (GPT-4 has ~1.7 trillion parameters)
- Inference / Prediction — using the trained model to produce an output for a new input (production use)
Features & Labels — The Language of Training Data
Every ML training dataset has the same structure: a set of features (input columns) and a label (the answer column). The model's job is to learn the mapping from features to label.
approved or
rejected. For house prices: the actual sale price. Labels in the training dataset are
provided by humans (or derived from historical data). Label quality is critical:
wrong labels teach the model wrong things — a major focus of CT-AI Chapter 5 (Input Data Testing).
// A training example for spam classification public class EmailTrainingExample { // ── FEATURES (inputs) ──────────────────────────────────── int wordCount; // total words in email double freqOfWord_FREE; // how often "FREE" appears (per 100 words) double freqOfWord_CLICK; // how often "CLICK" appears int numLinks; // number of hyperlinks in email boolean hasAttachment; // does it have an attachment? String senderDomain; // domain of sender email address // ── LABEL (the correct answer for training) ────────────── boolean isSpam; // This was determined by a human labeller who read the email // and marked it spam=true or spam=false. // Quality of this label is critical — CT-AI Ch.5 covers label // correctness testing and inter-annotator agreement. } // Training dataset = List<EmailTrainingExample> with 500,000 rows // Model learns: which feature combinations correlate with isSpam=true?
Supervised Learning — Learning with a Teacher
Supervised learning is the most common ML paradigm and the primary focus of CT-AI testing. The word "supervised" means the training data includes the correct answers (labels) — the model is supervised by this ground truth during training.
The Two Tasks of Supervised Learning
- Output: a discrete category / class
- Examples: spam / not-spam, cat / dog / bird, approve / reject
- Binary classification: exactly 2 output classes (most common in exam examples)
- Multi-class: 3+ classes (e.g., digit recognition: 0–9)
- Key metrics: Accuracy, Precision, Recall, F1-score (Ch.3 deep dive)
- Tester focus: confusion matrix, threshold selection, class imbalance
- Output: a continuous numerical value
- Examples: house price ($238,350), tomorrow's temperature (22.3°C), stock return (3.7%)
- Key metrics: MAE, MSE, RMSE
- Tester focus: error tolerance ranges, outlier predictions, distribution of errors
- CT-AI focus: regression metrics are less emphasised than classification metrics in the exam
// CLASSIFICATION — output is a CLASS (category) public enum SpamLabel { SPAM, NOT_SPAM } public SpamLabel classifyEmail(double[] features) { double spamProbability = model.predict(features); // e.g., 0.87 return spamProbability > 0.5 ? SpamLabel.SPAM : SpamLabel.NOT_SPAM; // The threshold (0.5) is a design decision. // Changing it affects Precision vs Recall tradeoff (CT-AI Ch.3). } // REGRESSION — output is a NUMBER (continuous) public double predictHousePrice(double[] features) { return model.predict(features); // e.g., 238350.72 (dollars) // There's no threshold decision here. // Correctness is measured by how far off the prediction is // from the actual sale price (MAE, RMSE etc.) }
Unsupervised Learning — Finding Hidden Structure
Unsupervised learning operates on data with no labels. There is no "correct answer" to learn from. Instead, the algorithm discovers hidden structure or patterns in the raw feature space.
Supervised: "I'll show you 10,000 labelled cat photos and dog photos — you learn the difference."
Unsupervised: "Here are 10,000 photos with no labels — you tell me what groups or patterns you see."
The algorithm finds structure humans didn't pre-specify.
Common Unsupervised Tasks
Testing challenge: No ground truth labels mean you can't use a confusion matrix. Quality is measured by internal metrics like silhouette score — subjective and domain-dependent.
Reinforcement Learning — Learning by Doing
Reinforcement Learning (RL) is fundamentally different from both supervised and unsupervised learning. There is no dataset of examples. Instead, an agent learns by interacting with an environment, taking actions, and receiving feedback in the form of rewards or penalties.
The agent's goal: learn a policy (strategy) that maximises cumulative reward over time
Real examples: AlphaGo (played millions of Go games against itself), OpenAI Five (Dota 2 game-playing), robotics arm control, dynamic ad bidding systems, and — increasingly relevant — RLHF used to align LLMs like ChatGPT and Claude to human preferences.
RL appears in the syllabus as a category to recognise (K1/K2). You won't be asked to implement RL algorithms. Focus on: the agent-environment-reward loop concept, and why RL systems are particularly hard to test — emergent behaviour in novel environments, reward function quality, and the fact that you may not know the optimal policy to compare against.
The Training Process — Step by Step
This is the core mechanical process of ML. Understanding it is essential for CT-AI because many testing concepts (overfitting, hyperparameter tuning, dataset splits) only make sense once you understand what training actually does.
The Big Picture
Training is fundamentally an optimisation problem. You have a model with many weights. You want those weights to be set to values that make the model's predictions as accurate as possible. Training is the iterative process of finding those values.
spamProbability = 0.3 for an email that is actually spam (label = 1.0).
The prediction is far off — but that's expected at the start.
new_weight = old_weight − α × gradient
Imagine a ball rolling down a hill — gradient descent finds the valley (minimum loss).
The learning rate controls the step size: too large and the ball overshoots the valley
and bounces around, too small and it takes forever to reach the bottom.
// The Training Loop — conceptual skeleton // Real ML frameworks (TensorFlow, PyTorch) hide most of this, // but understanding it is essential for CT-AI public void train( List<TrainingExample> dataset, int numEpochs, double learningRate // α — a HYPERPARAMETER you set before training ) { // Step 1: initialise weights randomly model.initializeWeightsRandomly(); for (int epoch = 0; epoch < numEpochs; epoch++) { double totalLoss = 0.0; for (TrainingExample example : dataset) { // Step 2: forward pass — predict double prediction = model.predict(example.features); // Step 3: calculate loss (how wrong was the prediction?) double loss = lossFunction.compute(prediction, example.label); totalLoss += loss; // Step 4: backward pass — compute gradients (which direction // to nudge each weight to reduce the loss?) double[] gradients = model.computeGradients(loss); // Step 5: update weights — gradient descent // new_weight = old_weight - (learningRate * gradient) model.updateWeights(gradients, learningRate); } // Log progress — we want loss to decrease each epoch System.out.printf("Epoch %d | Loss: %.4f%n", epoch, totalLoss / dataset.size()); } // After training: model.weights now contain the learned values. // The model is ready for inference (making predictions on new data). }
Training vs Inference — Two Very Different Phases
These two phases of an ML system's life are fundamentally different in purpose, resource requirements, and testing implications. CT-AI has separate testing considerations for each.
- Purpose: Find optimal weights by minimising loss over training data
- When: Done once (or periodically for model updates) — before deployment
- Speed: Slow — hours, days, or months for large models
- Compute: Massive GPU clusters; training GPT-4 cost ~$100M
- Data needed: The full labelled training dataset
- Testing focus: Dataset quality, bias, train/val/test split, overfitting detection, algorithm selection, hyperparameter tuning
- Who does it: ML engineers, data scientists — but testers review the process
- Purpose: Use trained model to make predictions on new, unseen data
- When: Continuously in production, for every user request
- Speed: Fast — milliseconds per prediction (the whole point)
- Compute: Much smaller — often a single server or even a mobile device
- Data needed: Just the current input features
- Testing focus: Functional correctness, performance, adversarial inputs, drift detection, integration with surrounding system
- Who does it: The deployed model serving user requests
A model can perform well on the training and test datasets but behave unexpectedly in production. This happens when the production data distribution differs from what the model saw during training. For example: a fraud detection model trained on 2022 transaction data may struggle with 2024 fraud patterns that didn't exist during training. This is called distribution shift or drift — a major CT-AI topic in Chapters 5 and 6 (data testing and model testing respectively).
Hyperparameters — Settings You Choose Before Training
A hyperparameter is a configuration setting that you (or the ML engineer) choose before training begins. Hyperparameters are not learned from data — they control how the learning process itself works.
Parameters (weights, biases) — learned FROM the training data automatically.
Hyperparameters — set BY the developer BEFORE training. They control the training process itself.
| Hyperparameter | What it controls | Too high → | Too low → | Typical range |
|---|---|---|---|---|
| Learning Rate (α) | Size of each weight update step during gradient descent | Overshoots, diverges — loss explodes | Learns too slowly, might get stuck | 0.0001 to 0.1 |
| Number of Epochs | How many full passes through the training data | Overfitting — memorises training data | Underfitting — hasn't learned enough | 10 to 1000+ |
| Batch Size | How many examples are processed before each weight update | Stable but slow; needs more memory | Noisy updates; might not converge well | 16 to 512 |
| Number of Layers / Neurons | Architecture depth and width — model capacity | Overfit on small data; slower inference | Underfit — can't learn complex patterns | Domain-specific |
| Regularisation (λ) | Penalty for large weights — prevents overfitting | Underfitting — model too constrained | Overfitting — no regularisation effect | 0.0001 to 0.1 |
Hyperparameter Tuning — Finding the Right Values
Finding good hyperparameters is itself a process that requires running multiple training experiments. Common strategies: Grid Search, Random Search, and Bayesian Optimisation. The validation dataset (separate from training and test) is used to evaluate performance during hyperparameter tuning — this is why you need three separate datasets, which CT-AI Chapter 3 and 5 cover in depth.
Java: Full ML Pipeline — Putting It All Together
Here is a complete conceptual ML pipeline in Java pseudocode — from raw data to deployed inference. This ties together every concept from Part 2: features, training loop, evaluation, and inference. Real ML is done in Python with frameworks, but the structure is identical.
// ══════════════════════════════════════════════════════════════ // FULL ML PIPELINE — Spam Classification Example // This illustrates the complete lifecycle that CT-AI tests at // each stage (data testing, model testing, deployment testing) // ══════════════════════════════════════════════════════════════ public class MLPipeline { public static void main(String[] args) { // ── STEP 1: Load raw data ───────────────────────────────── // CT-AI Ch.5 (Input Data Testing) tests this stage: // - Is the data biased? // - Are labels correct? // - Is the data representative of production? List<Email> rawEmails = dataLoader.load("emails.csv"); // ── STEP 2: Feature extraction ──────────────────────────── // Convert raw emails into numerical feature vectors the model can process List<double[]> features = rawEmails.stream() .map(FeatureExtractor::extract) // word freq, link count, sender domain etc. .collect(Collectors.toList()); double[] labels = rawEmails.stream() .mapToDouble(e -> e.isSpam ? 1.0 : 0.0) .toArray(); // ── STEP 3: Split dataset into 3 sets ──────────────────── // Training set: 80% — used to train the model // Validation set: 10% — used for hyperparameter tuning // Test set: 10% — used ONCE for final evaluation // // CT-AI Ch.3 and Ch.5 cover why all 3 sets are needed. // The test set must NEVER be seen during training or tuning — // using it for tuning would give falsely optimistic results. DataSplit split = DataSplitter.split(features, labels, /*trainRatio=*/ 0.80, /*valRatio=*/ 0.10, /*testRatio=*/ 0.10, /*shuffle=*/ true // always shuffle to avoid ordering bias ); // ── STEP 4: Define model and hyperparameters ────────────── // These are chosen BEFORE training — not learned from data HyperParameters hp = new HyperParameters(); hp.learningRate = 0.001; // step size for gradient descent hp.numEpochs = 50; // training passes through the data hp.batchSize = 32; // examples per weight update hp.hiddenLayers = 2; // neural network depth NeuralNetworkModel model = new NeuralNetworkModel(hp); // ── STEP 5: TRAINING ────────────────────────────────────── // Forward pass → compute loss → backprop → update weights // Repeated for numEpochs passes over the TRAINING set model.train(split.trainFeatures, split.trainLabels); // ── STEP 6: Evaluate on VALIDATION set ─────────────────── // Used to detect overfitting and tune hyperparameters. // If training accuracy is 99% but validation is 70%, // the model is OVERFITTING (memorising, not generalising). Metrics valMetrics = model.evaluate(split.valFeatures, split.valLabels); System.out.printf("Validation Accuracy: %.2f%%%n", valMetrics.accuracy * 100); // ── STEP 7: Final evaluation on TEST set ───────────────── // The test set is used EXACTLY ONCE for the honest final score. // CT-AI Ch.3 covers the full confusion matrix metrics computed here. Metrics testMetrics = model.evaluate(split.testFeatures, split.testLabels); System.out.printf("Test Accuracy: %.2f%%%n", testMetrics.accuracy * 100); System.out.printf("Test Precision: %.2f%%%n", testMetrics.precision * 100); System.out.printf("Test Recall: %.2f%%%n", testMetrics.recall * 100); System.out.printf("Test F1-Score: %.2f%%%n", testMetrics.f1 * 100); // ── STEP 8: Save and deploy model ──────────────────────── // CT-AI Ch.7 covers deployment testing: // - Model format conversion (ONNX, TensorFlow SavedModel) // - Model compression / quantisation (reduces size for edge devices) // - Re-testing is required after format/compression changes // - Monitoring after deployment: performance drift, data drift model.save("spam_model_v1.onnx"); // ── STEP 9: INFERENCE — using the deployed model ────────── // Completely separate from training. Just uses learned weights. Email newEmail = emailService.receive(); double[] newFeatures = FeatureExtractor.extract(newEmail); double spamProb = model.predict(newFeatures); boolean isSpam = spamProb > 0.5; // classification threshold System.out.printf("Email '%s' → spam probability: %.2f → %s%n", newEmail.subject, spamProb, isSpam ? "SPAM" : "NOT SPAM"); } }
Tester Takeaways — Why This All Matters
Everything in Part 1 and Part 2 directly maps to testing challenges you'll encounter in the CT-AI syllabus chapters. Here's the connection bridge:
| Concept learned here | CT-AI chapter where it matters | Why it creates a testing challenge |
|---|---|---|
| AI outputs are probabilistic | Ch.4 — Testing AI Systems | Traditional pass/fail test oracles don't work; need statistical approaches |
| Model is a black box | Ch.2 — Quality Characteristics | Explainability and transparency become quality requirements to test for |
| Labels might be wrong | Ch.5 — Input Data Testing | A model trained on wrong labels produces wrong learned behaviour; label correctness must be tested |
| Data distribution matters | Ch.5 — Input Data Testing | Biased or unrepresentative data produces biased models; data must be tested before training |
| Overfitting — too many epochs | Ch.6 — Model Testing | A model that memorises training data fails on real-world inputs; overfitting is a model defect |
| Training vs test dataset split | Ch.3 — Machine Learning | Contaminating test data with training info gives falsely optimistic evaluation metrics |
| Drift — distribution changes over time | Ch.6 — Model Testing | A model accurate at deployment may degrade as the world changes; requires monitoring and re-testing |
| Hyperparameters affect behaviour | Ch.3 — ML Workflow | Hyperparameter selection is a design decision with testing implications (reproducibility, fairness) |
Exam Insights for This Prerequisite Material
Phase 0 is prerequisite material — it doesn't appear as standalone exam questions. However, every question in CT-AI chapters 1–7 assumes this knowledge. If you can't picture what training data is, or why the test oracle problem exists, you'll misread scenario questions. These concepts are the vocabulary the exam questions are written in.
Quick Reference Card — AI-PRE-01 in One View
| Term | One-line definition | Exam trap to avoid |
|---|---|---|
| Feature | Input variable fed into the model | Features ≠ labels; features are inputs, labels are answers |
| Label | The correct answer in the training dataset | Labels can be wrong — that's why Ch.5 tests them |
| Weight / Parameter | Learnable number inside the model, determined by training | Parameters are LEARNED; hyperparameters are SET |
| Hyperparameter | Configuration set before training (learning rate, epochs) | Not learned from data — set by the developer |
| Loss Function | Measures how wrong the model's predictions are | Minimising training loss ≠ good generalisation (overfitting) |
| Epoch | One complete pass through the training dataset | Too many epochs → overfitting; too few → underfitting |
| Training | The process of finding optimal weights by minimising loss | Training the model ≠ testing the model |
| Inference | Using the trained model to make predictions on new data | Inference is what happens in production — this is what users experience |
| Supervised ML | Learns from labelled examples (features + labels) | Supervised ≠ always classification; regression is also supervised |
| Unsupervised ML | Finds structure in unlabelled data | No labels means no confusion matrix; evaluation is harder |
| Reinforcement Learning | Agent learns by trial-and-error via rewards | RL has no dataset — it learns from environment interactions |
| Overfitting | Model memorises training data but fails on new data | High training accuracy + low validation accuracy = overfitting |
| Drift | Production data distribution shifts away from training data over time | Drift doesn't mean the model broke — the world changed |
You now have the mental model needed to understand how neural networks compute their outputs (the forward pass in detail), what activation functions do, how LLMs generate text token by token, why outputs are probabilistic, and what the "black box" problem really means at an architecture level. That's exactly what AI-PRE-02 covers.