Scaling Laws, Capabilities & Limits
- State what scaling laws claim: loss falls as a power law in parameters, data, and compute
- Explain the Chinchilla result and the roughly 20-tokens-per-parameter rule of thumb
- Argue both sides of the emergent-capabilities debate
- Explain why hallucination is structural to next-token prediction, not a bug to be patched
- Define the capability-vs-reliability gap and its consequences for production systems
| Spaced-rep warm-up: due cards (pipeline, training) | 10 min |
| ELI5 + tech read; scaling-curve visual | 25 min |
| Guided: read the papers + Chinchilla arithmetic | 20 min |
| Guided: probe the limits protocol | 20 min |
| Practice: brief the CTO | 20 min |
| Project: limits matrix + quiz + flashcards | 25 min |
Builds on: Day 100 — The LLM training pipeline · Day 99 — Training the tiny GPT · Day 94 — Attention mechanics
Your Day-99 model has about a million parameters and writes Shakespeare-flavored gibberish. What happens if you make it ten times bigger, feed it ten times more text, and give it ten times more compute? Remarkably, the improvement is predictable — like a law of nature. Plot loss against scale on log-log paper and you get a straight line: every 10× of scale buys a similar-sized drop in loss. That regularity is why labs could bet hundreds of millions of dollars on a training run and forecast, before starting, roughly how good the model would be.
But "bigger brains" come with "sharper edges." A model that predicts text superbly is still just predicting text: when it does not know something, the most plausible continuation is often a confident-sounding invention. And skills seem to arrive unevenly — a model may suddenly do three-digit arithmetic where a slightly smaller one could not, which is either a real emergent jump or an artifact of how we score it, depending on whom you ask. Scale buys capability on a smooth curve; it does not buy reliability on the same curve. That gap is where your job as an AI engineer lives.
Scaling laws explain the last five years of the industry — why context windows, model sizes, and training corpora keep growing, and why compute is the strategic resource. For you specifically: the capability-reliability gap is the business case for everything in Phases 6-7. A model that is right 90% of the time is a demo; making the failure modes detectable and contained (evals, retrieval grounding, guardrails) is what customers pay AI engineers for. Being able to say "hallucination is structural, so we design around it" — and defend it — is a mark of seniority in interviews and customer rooms.
Bigger brains, sharper edges — loss falls on a power law
step 1 / 5Plot loss against compute on log-log axes and something eerie appears: a straight line. Multiply compute by 10, loss drops by a predictable slice — for many orders of magnitude.
Guided practice
Read the curves like an economist
20 min- Open the Kaplan paper (abstract + Figure 1) and the Chinchilla paper (abstract + the compute-optimal table).
- In your notes, state each paper's headline claim in one sentence of your own words.
- Apply the 20-tokens-per-parameter rule: for models of 7B, 70B, and 400B parameters, compute the roughly compute-optimal token counts. Show the arithmetic.
- Now the business twist: explain in three sentences why a company might deliberately train a 7B model on 10× the "optimal" tokens (hint: training cost is paid once; inference cost is paid per request forever).
- Sanity-check against your Day-99 run: with ~1M characters of data, was your tiny GPT data-starved or parameter-starved by the Chinchilla lens?
Provoke the limits, on purpose
20 min- Using any assistant model you have access to (claude.ai or an API), run this 4-probe protocol and log verbatim outputs.
- Probe A (cutoff): ask about a verifiable event from last month. Note whether the model states its knowledge cutoff.
- Probe B (hallucination trigger): ask for a detailed biography of a plausible-sounding but fictitious person, e.g. "the economist Harold Vintner-Krauss". Note whether it invents or declines.
- Probe C (calibration): ask the same fictitious question but append "If you are not confident this person exists, say so." Compare.
- Probe D (tokenization limit): ask it to count the letter r in a long invented word. Connect any failure to Day 96.
- For each probe, write one line: which structural limit did this exercise, and which mitigation (retrieval, uncertainty prompting, tool use) addresses it?
On your own
Brief the CTO
20 minA CTO asks: "Model releases keep beating benchmarks. Why can't we just wait for the next model instead of building your proposed evaluation and retrieval infrastructure?"
Write a 200-word answer using today's concepts: what scaling reliably buys (capability on a smooth curve), what it does not (worst-case reliability, fresh knowledge, calibrated uncertainty), and name the two pieces of infrastructure that address the residual gap.
Hints: cite the capability-reliability gap explicitly; knowledge cutoff is a treadmill, not a one-off; "the demo works" vs "the p99 case works" framing lands well with executives.
Limits & mitigations matrix
Create llm-limits-matrix.md: a table with one row per structural limit — frozen knowledge cutoff, hallucination, context-window cost, tokenization blind spots, unreliable arithmetic/logic — and columns for: why it is structural (one sentence rooted in the training objective or architecture), evidence you personally collected today (probe results), and the engineering mitigation with the curriculum day where you will build it (RAG D113, evals D134, tool use D111, guardrails D132). Commit it. This matrix becomes your checklist when you architect the capstone on Day 119.
Common mistakes & misconceptions
- Reading scaling laws as "scale fixes everything." They predict average loss, not worst-case behavior, freshness, or calibration — the things production incidents are made of.
- Treating hallucination as a bug the next release will patch. It is a property of the objective: plausible continuation of unknown facts is a confident guess. Mitigate with grounding and verification, not hope.
- Quoting "emergent abilities" uncritically. Know the metric-artifact critique; say "task-level usefulness can switch on abruptly even if competence scales smoothly."
- Forgetting the Chinchilla trade-off direction: for fixed compute, a smaller model on more tokens beat a bigger model on fewer. And modern overtraining goes further because inference cost dominates.
- Assuming a bigger context window means the model uses all of it equally well — Day 104 shows retrieval quality degrades for content buried in the middle.
- Confusing knowledge cutoff with API version. The endpoint may be updated monthly while its knowledge still ends at the training cutoff.
Q1. Chinchilla's core finding for a fixed compute budget was…
Q2. Why is hallucination described as structural rather than a bug?
Q3. The "capability-reliability gap" means…
Go deeper — curated resources
- Are Emergent Abilities a Mirage? (Schaeffer et al. 2023) ↗ — The metric-artifact side of the emergence debate, worth skimming to argue both positions honestly.
- Both papers' claims restated in your own words with the token arithmetic done
- All four probes run with transcripts saved
- CTO brief written within the word limit and naming the gap
- Limits & mitigations matrix committed
- Quiz ≥ 2/3
← Back: Day 99 gave you the smallest point on the scaling curve — your own run. Day 100 explained the pipeline being scaled; Day 94's attention math is why context length costs O(n²), the same growth-shape reasoning as Day 22.
Forward →: Day 104 deep-dives the context and hallucination rows of your matrix. Day 113 builds the retrieval mitigation, Day 134 the evals mitigation, and Day 160's AI system design interviews expect you to reason from exactly this capability-reliability framing.