Choosing a model
Mastery: connect the pieces
Turn understanding into a design: explain choosing a model by connecting a concrete decision to observable evidence.
Before you start
Why this matters
Imagine you own an invoice-extraction service and must explain one decision to a teammate who knows basic AI vocabulary but has never operated this feature. Write two sentences: what problem does choosing a model solve, and what evidence would show it is solving that problem? Do not name a vendor or model yet. This separates the enduring idea from one implementation.
1Learn the idea
Read
Synthesize the system
A complete explanation of choosing a model now has four connected claims. Model choice is a constrained engineering decision, not a leaderboard shopping trip. The best model is the smallest, cheapest, fastest option that meets the task’s quality and risk requirements in the environment where it will run. Turn representative tasks into an evaluation set, define hard gates, run candidate models with the same prompt and tools, then compare quality, latency, cost, reliability, privacy, and operational fit. Route difficult cases upward only if the routing policy improves total utility. A benchmark estimates capability under a test setup; a deployment decision includes your prompts, data, traffic, risk, and operations. Parameter count is not quality, context limit is not effective recall, and a low token price is not a low cost per completed task.
Turn those claims into a design for an invoice-extraction service. State the user job, data boundary, uncertain model contribution, deterministic controls, evaluation set, release gate, production signal, and failure response. If any item is missing, the concept is not yet operational.
Read
Architecture review
Use this spoken diagram:
authorized input -> scoped evidence -> learned operation
-> deterministic validation -> bounded action
-> outcome + trace -> evaluation and improvement
At every arrow ask: what representation crosses, who owns it, what can be lost, and how is it versioned? Control candidate family and size, quantization, context limit, structured-output support, tool calling, temperature, batch and concurrency settings, region and retention policy, fallback chain, and confidence threshold. Freeze prompt and decoding settings during a fair comparison. The controls should be few enough to understand and complete enough to constrain the severe failures.
Read
Defend a tradeoff
Larger models often improve difficult reasoning but cost more and respond slower. Hosted APIs reduce operations work but add dependency and data-governance concerns; local models offer control but require capacity planning. Long context is useful only if the model can reliably use it. Choose one tradeoff and defend it quantitatively. Name a hard constraint, a primary metric, and the cost you accept. Then name evidence that would reverse your decision. This last step protects the design from becoming identity or vendor loyalty.
A defensible statement sounds like: “We choose configuration B because it passes the privacy and severe-error gates, improves task success on the target slice, and stays within the p95 latency budget. We will reconsider if traffic or review cost crosses the recorded threshold.”
Read
Diagnose under pressure
Teams benchmark toy prompts, compare vendors with different prompts, ignore tail latency, price only input tokens, or optimize an aggregate score that hides critical fields. A routing cascade can cost more than one strong model when retries and duplicate context are counted. Pick the most consequential failure and walk through trigger, earliest signal, containment, owner, recovery, and prevention. Use task-level exactness or rubric scores, severe-error rate, schema validity, p50/p95 latency under expected concurrency, availability, and dollars per successful request. Report by document type and language. Apply hard gates first, then compare utility such as quality minus weighted cost and latency. Monitoring should reuse the evaluation construct where possible, while acknowledging that production labels may arrive late.
Read
Mastery questions
Answer without notes:
- What does this concept change: evidence, learned behavior, runtime state, coordination, or measurement?
- Which neighboring concept is commonly confused with it?
- Which intermediate artifact would you inspect first?
- Which knob has the largest quality/resource interaction?
- What hard gate cannot be traded for average quality?
- What baseline could disprove the need for the complex design?
- How would you detect harm hidden by an aggregate metric?
- What is the safe state during uncertainty?
Now explain the worked evidence: Three invoice models score 94%, 96%, and 97% field accuracy. The 97% model costs $0.018/request and misses VAT IDs; the 96% model costs $0.006 and passes every critical-field gate. At one million requests, the difference is $12,000 monthly. Choose the middle model and route low-confidence handwritten invoices to the larger one. If you can identify the causal chain, calculate the consequential change, propose an alternative hypothesis, and choose a reversible response, you have moved from vocabulary to engineering judgment.
Read
A reusable decision record
End with one page containing: context, alternatives, assumptions, case-set version, configuration IDs, metric table, gates, selected option, rejected options, owner, rollout, rollback, and review date. This artifact makes future disagreement productive because teammates can challenge evidence or weights instead of reconstructing hidden reasoning.