Introduction Stakeholders use “AI”, “machine learning”, “deep learning”, “generative AI”, and “LLMs” as if they were synonyms. They are not. The terms nest, they overlap at the edges, and each one carries its own assumptions about data, hardware, and the failure modes a production team will eventually have to debug. When a scoping conversation spends an hour deciding whether a project is “GenAI” or “just ML”, what is actually being negotiated is the architecture, the budget, and the team composition — the label is a proxy for all of that. This article lays out a working taxonomy that engineering teams can actually use. ML is the broadest discipline. Deep learning is a subset of ML. LLMs are a specific deep-learning family. Generative AI is an application category that overlaps deep learning heavily but is defined by what the system produces, not how it is built. We map each family to the kinds of problems it solves, the data it needs, and the way it tends to break — so a project conversation can start at the problem rather than at the label. What machine learning actually covers Machine learning is any algorithm that learns a function from data rather than being hand-coded. The category includes decision trees, support vector machines, k-nearest neighbours, linear and logistic regression, random forests, and the gradient-boosting family (XGBoost, LightGBM, CatBoost). Neural networks are also ML — they just happen to be the subset that gets disproportionate attention. The defining feature of classical ML, in our experience working with production teams, is that the model is small enough to train on a single machine in minutes to hours, the features are usually engineered by humans, and the resulting model is either fully interpretable (decision trees, linear models) or interpretable enough through tooling like SHAP. This makes classical ML the default choice for tabular problems — fraud scoring, churn prediction, demand forecasting, credit risk — where the input is a structured row of numbers and categories, and the output is a class or a number. Classical ML is also where the operational economics are friendliest. An XGBoost model trained on a few million rows runs on CPU at sub-millisecond latency. There is no GPU, no inference server, no quantisation step. The MLOps stack collapses to a model registry and a batch scoring job. Deep learning: where the architecture earns the cost Deep learning is the subset of ML built on multi-layer neural networks. The “deep” refers to the stack of layers, not to anything semantic about the problem. What distinguishes deep learning from classical ML is that the network learns its own feature representations from raw input — pixels, waveforms, tokens — rather than relying on hand-crafted features. This is the property that makes deep learning indispensable for perception. Image classification, object detection, semantic segmentation, speech-to-text, and machine translation all moved from classical pipelines to deep networks once the data volumes and GPU capacity made it viable. Frameworks like PyTorch and TensorFlow, with CUDA and cuDNN underneath, made the training side tractable; TensorRT, ONNX Runtime, and similar inference stacks made deployment viable. The cost is real. A non-trivial vision model takes hours to days on a multi-GPU node to train, and the deployed model needs GPU inference to hit useful latencies. The interpretability story is worse — deep networks are often called “black boxes” because the learned features rarely map to anything a human can label. Tools like Grad-CAM and integrated gradients exist, but they explain individual predictions, not the model as a whole. The practical rule we apply on engagements: if the input is structured tabular data with modest volume, start with gradient boosting and only move to deep learning if the leaderboard says you should. If the input is unstructured perception data, start with a pretrained deep model. LLMs: a specific deep-learning family with its own constraints Large language models are a particular kind of deep network — transformer-based architectures, trained on text at very large scale, with parameter counts now ranging from a few hundred million (small open models) to hundreds of billions (frontier closed models). The transformer architecture, with its attention mechanism, is what made it possible to train language models that capture long-range context across thousands of tokens. LLMs are deep learning, but the engineering profile is different enough that they deserve their own category. Training a frontier LLM is a multi-month multi-thousand-GPU exercise that almost no team outside a handful of labs will undertake. What teams actually do is use pretrained LLMs via API, or take an open-weights model (the Llama, Mistral, or Qwen families) and fine-tune it for a domain. Fine-tuning techniques like LoRA and QLoRA have made adaptation tractable on a single GPU node. The other defining property of LLMs is that they are scaled enough to exhibit emergent capabilities — in-context learning, instruction following, multi-step reasoning — that smaller models do not. This is what makes the “prompt engineering plus retrieval augmentation” pattern work as a fast path from zero to a useful prototype. It is also what makes evaluation hard: an LLM’s output space is open-ended, so the kinds of accuracy metrics that work for classical ML (precision, recall, F1) only partly apply. We cover the small-versus-large tradeoff and where each fits in small and large language models. Generative AI: the application category, not the architecture Generative AI is the category of systems that produce new content — text, images, audio, video, code, 3D — rather than classifying or predicting. It is an application label, not an architecture label. LLMs are one important generative family. Diffusion models (Stable Diffusion, the SDXL family, Flux) are another, dominant for image and increasingly video synthesis. Autoregressive audio models, GANs, and variational autoencoders all sit inside the GenAI umbrella too. This is the key feature that separates generative AI from classical ML for a production team: the output is a sample from a learned distribution, not a point estimate. That changes everything about how the system is evaluated, monitored, and made safe. A classification model’s failures are wrong labels; a generative model’s failures include hallucination, mode collapse, copyright leakage, and outputs that are subtly wrong in ways the user cannot detect without domain expertise. The QA story for GenAI is closer to product testing than to ML metrics. The taxonomy nests cleanly: GenAI is an application category, most of whose useful systems are deep-learning models, most of which are ML. LLMs are one important deep-learning family, much of whose use is generative. Drawing the relationship as four disjoint circles, as a lot of vendor material does, gets the structure wrong. A working taxonomy at a glance The table below is the version we hand to clients in the first scoping call. It is deliberately compact — the goal is to make the distinctions operational, not exhaustive. Family Typical input Typical output Hardware floor Interpretability Failure mode that bites Classical ML Structured tabular rows Class or number CPU High to medium Distribution shift on inputs Deep learning (non-generative) Images, audio, text Class, region, transcript GPU (training and often inference) Low Out-of-distribution inputs; spurious features LLMs Text or multimodal tokens Text, structured output GPU for self-hosted; API otherwise Low Hallucination; prompt-injection; context drift GenAI (image, audio, video, 3D) Prompt, conditioning data New media sample GPU (often high-end) Very low Mode collapse; copyright leakage; subtle artefacts Evidence class for the rows above: this is an observed-pattern summary across our engagements, not a benchmark — it reflects the choices teams keep making in scoping conversations, not a controlled study. How to choose between them on a real project Start from the task and the constraints, not from the technology. The decision is largely determined by three questions, in this order: Is the input structured tabular data? If yes, and the volume is anything from thousands to tens of millions of rows, try gradient boosting first. XGBoost, LightGBM, or CatBoost will train in minutes, run on CPU, and produce a model you can actually explain. If the leaderboard says a deep tabular model wins, escalate then — not before. Is the input perception data — images, audio, raw signals? If yes, start with a pretrained deep model and fine-tune. The cost of training from scratch is almost never justified outside research. Is the task understanding or producing natural language? If yes, an LLM with retrieval augmentation (RAG) is usually the fastest path to a useful prototype. Whether you self-host an open model or use an API is a separate decision driven by data sensitivity and unit economics. Is the task producing new images, audio, or video? Use a diffusion or audio generative model. Almost never train one from scratch; fine-tune or use LoRA adapters on top of an existing base. The meta-rule we follow: pick the smallest, simplest model that clears the quality bar. The cost of running a 70B-parameter LLM for a task that an XGBoost classifier solves is not just monetary; it is the cost of all the operational complexity that follows the model into production. We develop the generative-versus-classical contrast further in generative AI vs traditional machine learning, and the architectural lineage from symbolic systems to today’s models in symbolic AI vs generative AI. Where the families overlap — and why that matters The clean taxonomy above is useful, but in production the families combine. A modern document-understanding pipeline often runs an OCR step (deep vision model), feeds the extracted text into an LLM for structured extraction, and routes the result into a classical ML scoring model for downstream classification. A chatbot might use an LLM for understanding and generation, a classical ML model for intent classification at the front, and a retrieval system using sentence embeddings (deep learning) in the middle. This is the operational reality we see most often: the question is rarely “which family”, it is “which family for which sub-task in the pipeline”. A hybrid architecture lets each component do what it is good at — the LLM handles the open-ended language work, the classical model handles the high-volume scoring, the deep vision model handles the perception step — and keeps each component small enough to debug. The overlap also matters for cost. If a team labels the whole project “GenAI” because one sub-task uses an LLM, they tend to inherit the cost structure of a fully generative system. The right framing is component-by-component: the LLM step has its own latency and unit economics, and the classical scoring step has different ones. What changes once you move from prototype to production Each family has a characteristic shape to its production failure modes, and naming them up front saves the team weeks of debugging later. Classical ML in production fails most often through silent distribution shift — the input data drifts, the model keeps producing confident predictions, and no one notices until the downstream metric (revenue, fraud loss, churn) moves. The fix is monitoring on input distributions and on calibration, not just on accuracy. Deep perception models fail through out-of-distribution inputs and spurious features. A vision model trained on daytime data fails at night; a model that learned to use the hospital watermark as a feature for “diseased” fails when deployed in a different hospital. The fix is aggressive data-augmentation discipline at training time and strong OOD detection at inference time. LLMs fail through hallucination, prompt-injection, and slow context drift as the model is updated by the provider. Production LLM systems need evaluation harnesses that run continuously, retrieval pipelines that limit what the model can confabulate, and version pinning where possible. Generative image and video systems fail through mode collapse, copyright leakage, and subtle artefacts that only domain experts catch. Production GenAI needs human-in-the-loop review for any output that becomes external content, and provenance tooling (watermarking, C2PA) for any output that may circulate. FAQ What is the difference between machine learning, deep learning, LLMs, and generative AI? Machine learning is the broad discipline of algorithms that learn from data (decision trees, SVMs, gradient boosting, neural networks all count). Deep learning is the subset using multi-layer neural networks. LLMs (large language models) are a specific deep-learning architecture — transformer-based, trained on text at very large scale — used for language tasks. Generative AI is the application category: models (LLMs, diffusion models, audio models) that produce new content rather than just classify or predict. The terms nest: GenAI ⊂ DL applications ⊂ ML applications, with LLMs being one important DL family inside GenAI. When should you use classical ML instead of deep learning or an LLM? Tabular data with limited samples, low-latency low-cost inference requirements, regulated environments that need fully-interpretable models, and any problem where gradient boosting (XGBoost, LightGBM, CatBoost) actually wins on the leaderboard — which it still does for many structured-data tasks. Deep learning dominates perception (vision, audio, language); classical ML dominates structured tabular problems with modest data. Are LLMs replacing traditional machine learning models? In some places, no; in others, yes. For text classification, entity extraction, and many NLP tasks, an LLM with a well-engineered prompt often beats a hand-crafted classical pipeline at much lower engineering cost. For high-volume, low-latency, well-defined classification tasks (fraud scoring, churn prediction, ad ranking), purpose-built ML models remain cheaper and faster. The current reality is hybrid: LLMs handle the long-tail and the natural-language interface; classical ML handles the high-volume scoring. How do you choose between ML, DL, LLMs, and GenAI for a new project? Start from the task and the constraints, not the technology. If the input is structured and the output is a number or a class, try gradient boosting first. If the input is unstructured perception data, try a pretrained deep model. If the task involves understanding or producing natural language, an LLM with retrieval augmentation is usually the fastest path to a useful prototype. If the task involves producing new images, audio, or video, use a diffusion or audio generative model. Pick the smallest model that meets the quality bar. Where to take this next The taxonomy here is the baseline that the rest of our generative-AI writing builds on. For the deeper history of how today’s systems emerged from earlier symbolic approaches, read symbolic AI vs generative AI: how they shape technology. For the production-engineering contrast between generative systems and classical ML pipelines, see generative AI vs traditional machine learning. For what specifically makes a generative system different from a classifier in operational terms, see what is the key feature of generative AI. Image credits: Freepik.
