Applied GenAI Curriculum for AI PMs  ·  Depth Layer  ·  Optional Background

Unit 23 — Where Foundation Models Come From

Training-data realities and pre-training vs. post-training at a conceptual level — enough to explain to executives why models behave as they do, and why "just train it on our data" isn't one sentence.

Tags
vocab
Layer
DEPTH — pure curiosity / stakeholder-education tier
Objective
Explain to executives why models behave as they do — and why "just train it on our data" isn't a single sentence.
Depends on
Unit 01 (the vocabulary of foundation models and training).

Why a PM benefits from this background

This unit is optional — you can operate without it. But two conversations get much easier once you have it: explaining to a stakeholder why a model behaves the way it does (why it's confidently wrong, worse in some languages, or oddly moralistic), and gently correcting the executive who says "let's just train it on our data" as if that were a Tuesday task. Both trace back to where the model came from: the data it ate, and the two-stage process that shaped it.

1. The data reality: models are what they ate

Most foundation models are trained on Common Crawl — a massive scrape of the internet — or cleaned subsets of it. That means their raw diet includes "clickbait, misinformation, propaganda, conspiracy theories" and every sketchy corner of the web. Teams filter with heuristics (GPT-2 used only Reddit links with 3+ upvotes — hardly a bar for good taste), but the core truth holds: a model inherits the biases, gaps, and errors of its training data.

The "use what we have, not what we want" problem Models are trained on the data that exists and is cheap to get, not the data you'd ideally want. That's why a general model can be great at common web tasks and poor at yours. And more data isn't automatically better — a small amount of high-quality data can beat a large amount of low-quality data (a 1.3B model on curated code beat much larger models). This is the executive-friendly version of Unit 11.

Why models are worse in other languages

English dominates the internet — nearly 46% of Common Crawl, eight times the next language. "Low-resource" languages are badly under-represented, and it shows:

English
45.9%
Russian
6.0%
Chinese
4.9%
Bengali
0.09%
Punjabi
0.006%

The consequences compound: models perform worse (GPT-4 solved English math problems 3× more often than Armenian/Farsi), "just translate to English and back" loses information (Vietnamese pronouns encoding social relationships collapse into "I/you"), and non-English text is more expensive and slower — the same meaning takes ~10× more tokens in Burmese than English, so it costs ~10× more on a per-token API. Useful to know before promising global parity.

Why "train it on our domain" is a real project

General models are broad because their training data was broad — but they're unlikely to do well on tasks they never saw. Genuinely specialized domains (drug discovery on protein/DNA data, cancer screening on X-rays/fMRI) need curated, hard-to-acquire datasets that aren't on the public internet at all. That's why domain-specific models like AlphaFold (trained on ~100,000 protein structures) or Med-PaLM exist as distinct efforts. "Train it on our data" means acquiring, cleaning, and curating that data first — the expensive part.

2. The two-stage process: pre-training then post-training

A raw pre-trained model has two problems: it only knows how to complete text, not converse, and — fed the raw internet — its outputs "can be racist, sexist, rude, or just wrong." Post-training fixes both, in two steps. Read pre-training as reading to acquire knowledge, post-training as learning how to use it.

1

Pre-training~98% of the compute

Self-supervised learning on the raw internet. Produces a model that's knowledgeable but untamed — great at predicting the next token, with no sense of conversation or appropriateness.

2

Supervised finetuning (SFT)teach it to converse

Finetune on demonstration data — high-quality (prompt, response) pairs written by skilled humans — so the model learns to answer "how to make pizza" rather than continue the sentence. This is "behavior cloning": show good behavior, the model copies it.

3

Preference finetuningteach it what to say

Align outputs with human preference — via RLHF (train a reward model to score responses, then optimize for high scores), DPO, or RLAIF. SFT teaches it to have a conversation; this teaches it what conversations it should have.

The metaphor that lands with executives Picture the "Shoggoth with a smiley face." Pre-training creates an untamed monster from indiscriminate internet data. SFT makes it socially acceptable by training on higher-quality examples. Preference finetuning paints on the friendly face so it's customer-appropriate. The polished assistant you talk to is a thin, deliberate layer over something wild — which is why safety and alignment take real work, and why post-training "unlocks" capability the base model already had rather than adding new knowledge.

Why alignment is genuinely hard (not just careless)

Demonstration data teaches the model to converse but not what to say on contested questions — abortion, gun control, immigration. The goal of preference finetuning is to make models "behave according to human preference," which quietly assumes a universal human preference exists and can be embedded in a model. It can't, fully. Respond to a controversial issue and you upset some users; over-censor and the model gets boring and drives users away. This is why models feel cautious or inconsistent on hot topics — it's an unsolved balancing act, not an oversight.

Two facts for the "just train it on our data" conversation (1) It's expensive human work. Demonstration data needs skilled labelers — ~90% of InstructGPT's labelers had college degrees; one (prompt, response) pair can take 30 minutes; ~13,000 pairs ran ~$130,000, before design and QA. (2) Good data is running out. Public data is being fenced off (data restrictions rendered ~45% of one popular corpus off-limits), making proprietary data a real competitive advantage — which loops straight back to your data flywheel (Units 03, 11, 21).

What "good" looks like after this unit

You can now:

One optional-background unit remains: foundation-model evaluation concepts (Unit 24) — for parsing vendor benchmark claims when eval talk with researchers goes over your head.