What is AI

Artificial intelligence is not one technology. The label has been attached to at least three unrelated families of software over the past seventy years, and most public confusion comes from people arguing across those families without noticing they are doing it.

The first family is symbolic AI. A human writes the rules, and the machine searches over states, applies logic, and reports a conclusion. Chess engines of the 1990s, expert systems, and the routing logic in a lot of enterprise software all sit here. Nothing is learned. The intelligence, such as it is, was typed in by a person.

The second family is statistical machine learning. Instead of writing rules, you collect examples with known answers and fit a function that maps inputs to outputs. Linear and logistic regression, decision trees and gradient-boosted ensembles, support vector machines, k-means clustering, principal component analysis. This family remains in heavy production use at banks, insurers and retailers, because the data is tabular, the models are auditable, and they train quickly on ordinary hardware.

The third family is deep learning, where a network of simple units learns its own internal representation of the data rather than being handed features chosen by an engineer. Everything the general public now calls AI — image generators, speech recognition, large language models — is in this family.

There is also a definitional trap worth naming early. The observation usually attributed to Larry Tesler is that AI is whatever has not been done yet: once a capability becomes reliable, people stop calling it AI and start calling it spell check, or search, or spam filtering. That is why the field can simultaneously feel like it is advancing at an alarming rate and like nothing has been solved. Both impressions are artifacts of a moving definition.

The practical consequence for a beginner is that "learn AI" is not a coherent goal until you decide which family you mean. A foundations course has to walk all three, because the vocabulary is shared, the failure modes are not, and choosing the wrong family for a problem is one of the most expensive mistakes a team can make. Fitting a transformer to a thousand rows of tabular sales data is not a sophisticated choice. It is usually a worse choice than a decision tree that a domain expert can read.

Most people who feel stuck on AI are not missing maths. They are missing three distinctions, and once those land, a large amount of otherwise baffling behavior becomes predictable.

Training and inference are different activities

Training is the process that produces a set of numbers — the weights. It happens once, costs a great deal, and requires very different hardware from what you use afterward. Inference is what happens when you type a prompt: the weights are frozen, the model does arithmetic, text comes out. The model is not learning from your conversation. When people say "I taught it to do X in the chat", they mean they put instructions in the context window, which is discarded when the session ends. Actually changing the weights is fine-tuning, and it is a separate operation with its own dataset, cost and risks.

Knowledge in the weights is not the same as knowledge in the context

A model has two sources of information. Whatever was compressed into its parameters during training, which it cannot cite, update or verify, and whatever you put in front of it right now. These behave completely differently. Parametric knowledge is fluent, fast and confidently wrong at the edges. Context knowledge is accurate to whatever you pasted and disappears when the window fills. Retrieval-augmented generation exists entirely to move facts from the first category into the second, and understanding why that helps is the difference between using a model and engineering with one.

Capability and reliability are separate axes

A model that solves a task nine times out of ten is not ninety percent of a product. It is a demo. Most of the engineering work in real AI systems is not making the model smarter; it is constraining the output format, checking the result, catching the failure and deciding what happens next. Beginners consistently overestimate how much of a system is the model and underestimate how much is plumbing around it.

Hold these three apart and the rest of the field stops feeling arbitrary. Conflate them and you will keep being surprised.

The mechanical description of a language model is short, and it is worth learning properly because every strange behavior you have noticed follows from it.

Your text is first split into tokens — chunks that are usually somewhere between a character and a word, chosen by an algorithm that was fit to a training corpus. This is why models are oddly bad at counting letters in a word and why some languages consume far more of the context budget than English for the same meaning. The model does not see letters. It sees token identifiers.

Each token is then mapped to a vector, an embedding, which places it in a high-dimensional space where proximity encodes something like relatedness. Those vectors flow through a stack of transformer blocks. Inside each block, the attention mechanism lets every position look at every other position and decide how much to weigh it. This is the idea introduced in the 2017 paper "Attention Is All You Need" by researchers at Google, and it is the reason the architecture parallelizes so well on GPUs: unlike a recurrent network, positions do not have to be processed one after another.

Multiple attention heads run in parallel, each free to specialize — one may track syntactic agreement, another may follow a referent across a long passage. Nobody assigns those roles; they emerge from training. At the end of the stack, the model produces a score for every token in its vocabulary, which is turned into a probability distribution over what comes next.

Then comes the part beginners rarely see: sampling. The model does not output the answer. It outputs a distribution, and a decoding strategy picks from it. Temperature flattens or sharpens that distribution; top-k and top-p truncate its tail. This is why the same prompt gives different answers, why lowering temperature makes a model more repetitive rather than more correct, and why "the model made that up" is a slightly misleading description of hallucination. The model produced a plausible continuation, which is exactly what it was trained to do. Nothing in that pipeline checks whether the continuation corresponds to reality.

Once the next token is chosen it is appended to the input and the whole process repeats. That autoregressive loop explains generation speed, why long outputs cost more than long inputs, and why a model that has drifted off course early rarely recovers on its own.

There are three classical learning paradigms and one modern pipeline that stitches them together.

Supervised learning uses labeled examples: input, correct answer, repeat. It is the most reliable paradigm and the most expensive, because somebody has to produce the labels. Supervised projects fail at the labeling stage far more often than at the modeling stage — inconsistent labels put a hard ceiling on accuracy that no architecture change will lift.

Unsupervised learning finds structure without labels: clustering customers, reducing dimensionality, detecting anomalies. It is cheap on data and hard to evaluate, because there is no ground truth to score against. Two clusterings can both be defensible and lead to opposite business decisions.

Reinforcement learning learns from a reward signal rather than from answers. An agent acts, the environment responds, and the policy is nudged toward actions that scored well. It is powerful where you can simulate the environment and brutal where you cannot, because it needs a great many trials and it will happily exploit any flaw in your reward definition rather than solve the problem you meant.

Modern language models use all three in sequence. Pretraining is self-supervised: the corpus provides its own labels because the next token is always known. Supervised fine-tuning then shows the model examples of the behavior you want, in the format you want. Finally, preference optimization — the family that includes reinforcement learning from human feedback, along with newer direct-preference variants — shapes the model using comparisons between candidate outputs rather than a single correct answer.

That last stage is the one that turned a text predictor into something that answers questions and refuses harmful requests. It is also the least understood by users, and it explains behaviors that look like personality: the hedging, the structured lists, the apology reflex. Those are not properties of transformers. They are properties of what the preference data rewarded.

The trade-off running through all of it: the further you move from labeled examples toward preferences and rewards, the cheaper the supervision and the harder it becomes to say exactly what you optimized for.

You can learn a lot from a hosted chat interface, but it hides the variables that matter. An API call has no visible model size, no quantization format, no context limit you can feel, no memory ceiling. Everything is smoothed over. That is excellent for shipping and poor for understanding.

Pulling a model onto your own hardware forces the trade-offs into the open. You immediately confront parameter count, which sets how much memory the weights occupy. You confront quantization, the practice of storing weights at reduced numeric precision so that a model that would not otherwise fit does fit, at some cost to output quality that varies by model and by task. You confront context length, because you can set it, and setting it too high will exhaust memory in front of you rather than silently degrade somewhere else. You confront the difference between a model held in GPU memory and one spilling into system RAM, because the speed difference is impossible to miss.

None of these concepts are hard. They are simply invisible until you own the machine. The same is true of latency: time to first token and tokens per second are separate quantities with separate causes, and you cannot develop intuition for either from a chat box.

There is an honest counterpoint. Local models are generally smaller than the frontier hosted ones, and for the hardest reasoning tasks the gap is real. The sensible position is not local-versus-cloud tribalism but knowing which jobs are size-limited and which are not. Summarization, classification, extraction, drafting and most retrieval-grounded work are frequently well served by a model that runs on consumer hardware. Long-horizon reasoning and specialist code generation often are not.

Privacy is the other axis. If the data cannot leave the building for legal reasons — patient records, legal discovery, unreleased financials — then the question of which model is marginally better is secondary to the question of which models can run where the data already is.

Any honest foundations course spends real time on what these systems get wrong, because the failure modes are structural rather than incidental.

Hallucination is not a bug that will be patched. A generative model produces plausible continuations; plausibility and truth diverge, particularly on specifics such as citations, statutes, dates and figures. Grounding the model in retrieved documents reduces the problem substantially but does not eliminate it, because the model can still misread or over-extend the source. The engineering answer is verification, not trust.

Bias is more subtle than the usual examples suggest. A model reflects the statistical regularities of its training data, including regularities that encode historical discrimination. But bias also enters through problem framing, through the choice of proxy variable, through who was available to label the data, and through the deployment context. This matters because fairness is not one metric. Demographic parity, equal opportunity and calibration are different, defensible definitions, and there are well-known results showing you cannot generally satisfy all of them at once. Choosing among them is a policy decision wearing a technical costume, and it should be made explicitly rather than defaulted into.

Environmental cost is a real consideration and one where the public discussion is unusually noisy. Training a frontier model consumes substantial energy; so does serving it at scale, which over a model's lifetime can dominate the training cost. The useful skill is knowing which lever you actually control — model size, quantization, batching, caching, and whether you needed a generative model for that step at all.

On regulation, the landscape stopped being hypothetical. The European Union's AI Act takes a risk-tiered approach, imposing obligations that scale with the application's potential for harm and placing separate duties on general-purpose model providers. The United States National Institute of Standards and Technology publishes an AI Risk Management Framework that many organizations have adopted voluntarily as an internal structure. Sector rules — health privacy, financial advice, employment screening — frequently bind before any AI-specific statute does. If you are deploying anything that touches a protected decision, the compliance question is not a footnote you handle later.

Foundations material has a natural exit point, and recognizing it saves months.

You are ready to move on when you can do the following without reaching for a search engine: explain why a model gave two different answers to the same prompt; predict roughly what will happen if you double the context length on a memory-limited machine; say why a retrieval system might return the wrong passage and what you would change first; describe the difference between fine-tuning and prompting in terms of where the information lives; and look at a proposed AI feature and identify which part is the model and which part is ordinary software.

If those are comfortable, the branches ahead diverge sharply and the choice matters more than the order.

The engineering branch is retrieval systems, evaluation harnesses, tool-calling agents, and the operational work of keeping a model-backed service healthy. It rewards software instincts and pays quickly. You do not need much mathematics to be effective here, and you do need discipline about testing things that are non-deterministic.

The modeling branch is linear algebra, calculus, optimization, and building networks rather than calling them. It is slower to pay off and it is what lets you read a paper and know whether the result is interesting. Skip it and you will always be downstream of somebody else's judgment about which model to use.

The applied branch is domain depth: healthcare, law, education, small business operations. This is where most of the actual value gets created, and it is the branch most often skipped by technical people who then wonder why their pilot never reached production. Knowing what a clinician or a paralegal does all day is not softer knowledge than knowing what a transformer block does. It is frequently the constraint.

A reasonable plan picks one branch, goes deep enough to ship something real, and only then widens. The failure pattern is sampling all three at the introductory level for a year and finishing with vocabulary rather than capability.