Baking a Model
A mental model for how modern AI systems get constructed: product UI vs model proper, and pre‑training vs post‑training.
What we’ll cover
- What “model” can mean (and why it’s two parts)
- Why the model proper is “a bag of numbers”
- Pre‑training vs post‑training
- Why the baking analogy helps
How to use this mini‑deck
Use it as a compact mental model for model construction. It’s intentionally high‑level and process‑focused.
- Use the UI vs model split to avoid confusion
- Use pre‑ vs post‑training to explain iteration speed
- Use the baking analogy to remember the phases
What Do We Mean by “Model”?
In everyday talk, “model” often means the whole product. For understanding how it’s made, split it into two parts.
User interface / product layer
Formatting inputs/outputs, auth, sequencing, tool wiring, UX, policy, etc. Built with conventional software engineering.
The model proper
The artifact that produces probabilistic outputs from inputs. Built via training—radically different from writing code.
Why the split matters
People often attribute product behavior to “the model,” when some behavior lives in the UI/product layer.
A Model Is a Bag of Numbers
At a high level, the model is a large collection of numbers. Those numbers are what training produces and what behavior depends on.
What this means
- The “intelligence” is not hand-written rules
- Behavior comes from learned parameter values
- Changing the numbers changes behavior
What we’re not covering (today)
- The math inside attention/transformers
- Exact optimization algorithms
The focus is the construction process.
Training Isn’t Programming
Programming writes explicit steps. Training sets up conditions so the artifact adjusts itself based on data and objectives.
Programming
- Explicit instructions
- Small changes are cheap
- Fast compile/test cycles
Training
- Set data + initial conditions
- Long-running processes
- Iteration speed varies by phase
Pre‑Training and Post‑Training
Rather than one monolithic “training,” it helps to think of phases with very different rhythms and risks.
Pre‑training
Big batch run to get an approximately capable base model.
Mid‑training
Sometimes referenced; details vary (and are often not publicly described).
Post‑training
Many smaller, targeted batches to improve usability and weak spots.
Why this matters
Iteration speed, cost, and collaboration patterns differ drastically by phase.
Pre‑Training: Big Batch, Big Bet
Teams set initial conditions: data + a blank-ish model, then run enormous training jobs, monitoring and checkpointing along the way.
What happens
- Prepare data + model
- Run massive training loops
- Checkpoint / snapshot
- Monitor for divergence
Why it’s hard
- Very expensive and slow to iterate
- Failures cost time and money
- Restart decisions are high-stakes
Pre‑Training ≈ Cold Proofing
You mix ingredients, put them away, and let time do the work. You can’t constantly intervene without changing the process.
Cold proofing
- Mix ingredients
- Put it away
- Small early changes have big later effects
Pre‑training
- Set initial conditions
- Run long jobs
- Early choices echo later
Key insight
Pre‑training produces a base that isn’t necessarily “ready for humans”—it’s the precursor to later shaping.
Post‑Training: Many Small Batches
Post‑training is where teams address specific weaknesses: small experiments that improve the model’s behavior for real users.
What happens
- Find failure modes
- Design targeted tweaks
- Run small batches
- Keep the wins
Outcome
Lots of small code+data artifacts (surviving experiments) that supplement the base model.
- More helpful responses
- Better instruction following
- Reduced obvious failures
Post‑Training ≈ Shaping & Cooking
You take something with potential and make it useful for humans. This phase is iterative and collaborative.
Shaping & cooking
- Adjust texture and form
- Make it enjoyable to humans
- Iterate with feedback
Post‑training
- Target specific weaknesses
- Improve usability
- Refine behavior iteratively
One nuance
The analogy doesn’t capture how post‑training is often reversible and experiment-driven—but it captures the “make it usable for humans” intent.
Why This Framing Matters
It explains why model development has different teams, different rhythms, and different costs compared to conventional software.
Practical consequences
- Pre‑training is slow to iterate; choices are high-stakes
- Post‑training is faster; many targeted improvements
- Product behavior = UI layer + model behavior
Audience takeaway
Models are engineered through processes—more like baking than coding. Understanding the phases makes AI discussions clearer and less mystical.