The models behind modern AI, in plain language.

Every AI system you have used, a chatbot, a photo filter, a translation app, a spam filter, a music generator, is built from the same basic recipe: take a lot of examples of the thing you want the system to learn, choose a mathematical shape (an architecture) with millions or billions of adjustable knobs (its parameters), and slowly turn those knobs until the system’s guesses match the examples closely enough to be useful. That turning process is called training, and the resulting knob-settings are called a model.

The interesting part, and the part decision-makers actually need to understand, is that the choice of shape matters enormously. A shape built for recognizing shapes in photographs is a poor fit for understanding sentences, and a shape built for generating fluent sentences is a poor fit for painting a photorealistic image from scratch. Most of what has changed in AI over the past decade is not “more intelligence appearing from nowhere,” it is a sequence of better shapes, each one unlocking a new category of task.

This page walks through that sequence in the order it actually happened: plain neural networks, then convolutional networks for vision, then recurrent networks for sequences, then the Transformer that now underlies almost every large language model, and finally diffusion models, the technique behind most modern image, video, and audio generators. By the end, you should be able to look at almost any AI product and have a rough, correct sense of which of these ideas, or which combination of them, is doing the work underneath.

A photograph is a grid of millions of pixels, and a plain neural network that looked at every pixel independently would need an impractical number of weights, and would have no idea that a cat’s ear in the top-left corner of a photo is the same kind of shape as a cat’s ear in the bottom-right. Convolutional Neural Networks, or CNNs, fix both problems at once with a single idea: slide the same small pattern-detector (a filter) across the whole image, looking for the same edges, textures, and shapes wherever they appear. Stack several layers of these filters, each one combining the simple shapes the previous layer found into more complex ones, and the network builds up from edges, to textures, to eyes and ears, to whole faces or objects.

Where CNNs are applied today. CNNs remain the workhorse of computer vision: photo classification and search, quality control on factory production lines, satellite and aerial image analysis for agriculture and disaster response, face recognition and video surveillance, self-driving car perception, and medical imaging, where a CNN-based architecture called the U-Net is the standard tool for outlining tumors, organs, and lesions in X-rays, CT scans, and MRIs.

Current status. A newer architecture, the Vision Transformer, now matches or beats CNNs on many large-scale benchmarks, and the two are increasingly combined in the same system. But CNNs have not been retired: they need far less compute and far less training data to reach strong performance, which is exactly why they still run inside phones, cameras, drones, and other devices where power and memory are limited. For most everyday vision tasks running on small hardware, a CNN is still the practical default.

A little history, briefly.The 2012 ImageNet competition, won decisively by a CNN called AlexNet, is usually the moment historians point to as the start of the modern deep learning era: it beat every hand-engineered vision system that came before it by a wide margin. The architectures that followed, VGGNet, GoogLeNet, and ResNet (which introduced the “skip connection” trick that let networks grow far deeper without losing their training signal), are the direct ancestors of the vision systems in today’s phones, cars, and hospitals.

The single architectural idea most responsible for the AI systems dominating the news since 2022, ChatGPT, Claude, Gemini, and the rest, is the Transformer, introduced in 2017. Its core mechanism, called attention, lets a model look at an entire sequence all at once and directly learn which other words in that sequence matter most to understanding any given word, rather than reading one word at a time and hoping a running memory captures everything important. That single change had an outsized consequence: because every position can be processed simultaneously instead of one after another, Transformers train dramatically faster on modern chips, and they turned out to keep getting better, predictably, the more data and compute were poured into them.

Variants you will encounter.The “decoder-only” Transformer, which generates text one word at a time based on everything written so far, is the shape behind essentially every modern chat assistant and coding copilot. “Encoder-only” Transformers, the BERT family, are tuned instead for understanding rather than generating, and quietly power search engines and document-classification systems. “Encoder-decoder” Transformers read an entire input before generating an output and remain the standard for translation and summarization. Vision Transformers apply the same attention idea to patches of an image instead of words in a sentence, and Diffusion Transformers, described in the next section, use it as the backbone for generating images and video. Increasingly, multimodal Transformers read and write text, images, audio, and video together, all within one model.

Where they are applied. Conversational assistants, coding tools, search and retrieval, machine translation, document summarization and analysis, customer support, and, increasingly, autonomous agents that chain several steps of reasoning and tool use together to complete a multi-step task on their own, sometimes as a whole team of specialized models working together rather than one model alone.

Under the hood, quietly.Much of the recent progress in making these models fast and affordable to run has nothing to do with making them “smarter” in any obvious sense: techniques with names like grouped-query attention, rotary position embeddings, and mixture-of-experts let a model be effectively enormous while only activating a fraction of itself for any single question, which is a large part of why today’s assistants can respond in a second or two instead of a minute.

The family, briefly.OpenAI’s GPT series, Anthropic’s Claude, Google’s Gemini, Meta’s LLaMA, and the openly released DeepSeek and Qwen models are all, underneath their branding, decoder-only Transformers of the kind described above, differing mainly in scale, training data, and the fine-tuning and alignment work layered on top, the subject of another chapter of the full text. What makes any one of them feel different to use is rarely the base architecture; it is almost always this later layer of tuning.

For a decision-maker, the most consequential choices rarely come down to the four families above in the abstract; they come down to scale, cost, openness, and where the computing happens. All four matter more, in practice, than which architecture is technically “best.”

Bigger is not always better. A larger model, with more layers and more parameters, is usually more capable on hard, open-ended tasks, but it is also slower, more expensive to run, and often unnecessary for a narrow, well-defined job. A small CNN running on a factory camera, or a compact language model running entirely on a phone, is frequently the more sensible engineering choice than routing every request to the largest available model.

Open versus closed. Some model families, LLaMA, DeepSeek, and Qwen among the large language models, are released with their weights available to download and run yourself; others, like GPT, Claude, and Gemini, are accessed only through an API run by their maker. Open weights give you control over cost, data privacy, and customization, at the price of needing your own infrastructure and expertise; closed, API-based models trade that control for convenience and typically the very latest capability.

Cloud versus on-device. Running a model in the cloud gives access to the largest, most capable versions, but sends data outside your organization and depends on a network connection. Running a smaller model on-device, a phone, a laptop, a piece of factory equipment, keeps data local and works offline, at the cost of using a less capable model. Many production systems today use both: a small, fast, on-device model handles routine cases, and a large cloud model is called in only for the harder ones.

None of these trade-offs are visible from a product’s marketing page, but all of them are visible once you know which model family, and roughly which scale, sits underneath it, which is precisely the judgment this page is meant to build.