AI Problem-Solving Map

Start with the decision the system must support

AI is a broad field concerned with systems performing tasks such as perception, prediction, search, planning and language processing. Machine learning fits behaviour from data. Deep learning uses layered neural networks. An LLM is one kind of learned model, particularly useful for working with language, but it is not the default answer to every prediction or automation problem.

This course develops local language-model systems in depth. The map below supplies the broader problem-solving context: when to use rules, statistical models, retrieval, generative models or an agent, and how to judge the result. Image generation, robotics and classical computer vision are adjacent disciplines; their specialised training pipelines are beyond this course’s labs.

Write a problem contract before installing an engine. It should identify the input available at decision time, the desired output, a baseline, the cost of errors, acceptable latency and who acts when the system cannot answer. “Use AI on support tickets” is an ambition. “Assign an incoming ticket to a permitted team, with uncertain cases sent to review” is an implementable contract.

Map the task to an output and a baseline

Task	Output	First comparison	What to inspect
Classification	A category or category probabilities	Majority class, rules, simple classifier	Confusion between classes, rare-class misses
Regression	A numeric prediction	Constant, linear model or historical average	Error distribution and large costly errors
Forecasting	Future values given past observations	Last value or seasonal baseline	Performance on later periods, leakage from the future
Clustering	Groups without provided labels	Simple distance-based grouping	Stability and whether groups support a useful action
Retrieval	Ranked records or passages	Keyword search	Whether relevant evidence appears in the candidates
Generation	New text, code, audio or images	Template or existing workflow	Correctness, usefulness, provenance and failure handling
Sequential decisions	Actions that change subsequent observations	Fixed workflow	Final outcome, action cost and unintended effects

The scikit-learn estimator map groups methods by task and available data. Use that framing to choose a comparison; the diagram is not evidence that one algorithm wins on your dataset.

A deterministic parser can be the right choice for a fixed machine-readable format. A database query can count exact records. A language model may translate a question into a proposed query, but permissions and execution still belong to the application. Give each component a responsibility you can test independently.

Recognise the different sources of supervision

Supervised learning uses examples with targets, such as tickets paired with correct teams. The labels may be wrong or inconsistent, so inspect their provenance and the labelling policy. The model learns the relationship represented by those examples, including accidental shortcuts.

Self-supervised learning constructs a target from the data itself. Predicting the next token uses the following token as the target. This enables training on text without someone labelling every sentence, but it does not make the text true or free of bias.

Unsupervised learning looks for structure without supplied task labels. A cluster is a description of the chosen representation and similarity rule. It is not automatically a natural category, a causal explanation or a recommendation to take action.

Reinforcement learning evaluates actions through reward and subsequent interaction. The reward is a proxy for the intended outcome. A policy can exploit a verifier’s weakness or optimise one measured behaviour at the expense of another. Parts 14 and 27 show why reward design and held-out evaluation must be separate from optimisation.

Transfer learning starts from a model trained previously. Fine-tuning changes its parameters; prompting changes the input; retrieval supplies evidence at request time. These are distinct operations, and a deployment can combine them. Diagnose the missing capability before choosing one.

Use the right baseline for the information available

Consider an assistant answering questions about a frequently updated operations manual. A base LLM may produce fluent text from older training information. A keyword search can locate the current passage without generating an answer. A retrieval-plus-generation system can combine passage selection with a readable response. Fine-tuning may teach the desired format but does not create a reliable update channel for tomorrow’s manual.

Compare all three on a fixed question set, including questions absent from the manual. Label the supporting passages before inspecting generated answers. If keyword search already finds the correct text and users prefer reading it directly, generation must justify its added latency and error surface. If retrieval misses the passage, improve ingestion and search before training the generator.

The RAG paper motivates combining parametric and retrieved information. The operational workflow above is an application design exercise; its quality must be measured on the corpus you deploy.

Learn enough mathematics to inspect the result

You need shapes, units, proportions, logarithms and gradients more often than advanced proofs. A vector is an ordered set of numbers. A matrix maps one vector space to another. A tensor extends the same shape-and-index idea to more axes. Check shapes before interpreting a model computation.

A probability distribution assigns non-negative mass that sums to one. Conditional probability describes uncertainty after observing an input. A model’s output distribution is an estimate learned from data; it is not a certificate that the most likely output is correct.

A loss turns prediction error into an optimisation target. A gradient describes local sensitivity to parameters. Lower training loss means the model fits that training objective better; deployment quality depends on held-out data and the actual decision rule. The worked gradient in Part 1 connects these definitions to a calculation you can check by hand.

Track units throughout. Bytes measure storage, tokens count model-specific symbols, seconds measure time and requests count application work. Dividing bytes by bytes per second yields seconds. Dividing generated tokens by wall time yields throughput only for the interval and workload you actually measured. Unit mistakes often reveal an invalid performance prediction before a lab runs.

Design evaluation around mistakes and decisions

For classification, count true positives, false positives, false negatives and true negatives. Precision asks how many predicted positives were correct; recall asks how many actual positives were found. A threshold changes the trade between them. For regression, absolute and squared error penalise mistakes differently. Choose a metric that reflects the decision, not merely the library’s default score. The scikit-learn metrics reference documents these distinctions.

For an illustrative urgent-ticket test, suppose the model flags ten tickets, six of which are urgent, while four urgent tickets were missed. Precision is 6/10; recall is 6/(6+4). The same values happen to result here, but they answer different questions. A service that misses no urgent tickets by flagging everything has high recall and creates a potentially unusable review burden.

Separate a model score from an action threshold. A calibrated probability near 0.8 means that, among comparable cases receiving that estimate, the event should occur roughly that fraction of the time. It does not mean every individual case is correct with a verifiable confidence label. Calibration must be checked on representative outcomes, especially after data or task changes.

For generated answers, use deterministic checks where possible and a rubric where judgement is necessary. Report syntax validity separately from semantic correctness. Evaluate citations against source passages, code against independent tests and arithmetic against a computation. Inspect judge disagreement and avoid giving a model credit merely for writing a longer answer.

Split data by the boundary you expect to cross

Train on one partition, choose configurations using a validation partition and evaluate the final choice on a test partition. Split by customer, document family, repository or time when that matches deployment. Randomly separating near-duplicate rows can produce an optimistic test without testing the intended generalisation.

Fit transformations on training data: normalisation, feature selection and vocabulary construction can leak test information. For an LLM dataset, keep paraphrases and generated variants of the same source task together. Remove evaluation examples before generating teacher demonstrations.

After deployment, distinguish distribution shift from a software regression. A changed language mix or new customer workflow can degrade quality without any model update. Keep slices of evaluation by meaningful category and track input changes, with privacy-conscious retention. A single global average can conceal a serious failure for a small but important group.

Plan for uncertainty and operation

A model can abstain, ask for clarification or hand off to a person. Design those outputs into the application contract and test them with missing and contradictory evidence. A system forced to produce a filled field every time has no honest representation for an unavailable fact.

Separate proposed actions from authorised actions. Tool calls, generated SQL and shell commands are data until the application validates their schema, scope and permissions. For consequential actions, show the concrete proposed change before approval. Test retries and timeouts so one request cannot accidentally produce duplicate effects.

Your final decision should answer: does the system improve the task compared with the baseline, under the actual latency, memory, cost, privacy and maintenance constraints? Keep the evidence, failed cases and rollback path. The rest of the course develops each of those responsibilities into an executable local workflow.