Context window suitcase
Evaluate with evidence
Measure the decision, not the demo: explain the context window by connecting a concrete decision to observable evidence.
Before you start
Why this matters
Imagine you own a contract-review assistant 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 the context window 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
Begin with the decision
Test exact evidence recall by position and context length, task success, contradiction rate, prompt tokens, time to first token, total latency, and cost. Include distractor-heavy and multilingual cases. Compare full context, retrieval, and summaries on the same questions. An evaluation is useful only if its result changes a choice: ship, hold, route, tune, collect data, or retire. Define that choice and its hard gates before selecting metrics.
For a contract-review assistant, create cases from real task distributions plus intentionally difficult boundaries. Keep a locked set for final comparison and a development set for iteration. Include slices by input type, language, risk, and consequence. Random sampling estimates common behavior; targeted challenge sets expose rare severe failures. You need both.
Read
Metric layers
Measure three layers separately:
- Component evidence asks whether retrieval, memory selection, ranking, encoding, or coordination worked.
- End-to-end quality asks whether the user’s task was completed correctly and safely.
- Operational outcome asks about latency, cost, availability, escalation, and downstream value.
Context is information available during one inference; memory is a product feature that selects and reintroduces information across inferences; model weights hold learned patterns, not a searchable transcript. Maximum context size is capacity, not proof of faithful use. A component improvement is valuable only when it preserves gates and helps the end-to-end decision.
Read
Scoring with uncertainty
Suppose 84 of 100 cases pass. The observed pass rate is 84%, but another sample would differ. Report a confidence interval or bootstrap distribution, not false precision. For rare severe errors, count and inspect every event; an average quality score must not wash out a security or privacy breach.
Use deterministic scoring for exact properties such as schema validity or known calculations. Use human rubrics for nuanced correctness and harm. Model judges can scale review, but calibrate them against blinded human labels, measure agreement by slice, and periodically recheck after model or prompt updates.
Read
Comparative protocol
Hold input cases, prompts, tools, timeouts, and scoring constant between candidates. Pair results case by case because the pattern of wins matters more than two independent averages. Record failures and adjudication notes. Reject contaminated cases that appeared in training only when the protocol says how contamination is detected.
A model has a 16,384-token limit. System and schema use 1,200, history 5,600, retrieved clauses 7,900, and requested output 2,000: total 16,700, so it cannot fit. Reducing top-k removes the governing clause. Instead compress stale history to 1,400 tokens, leaving 3,884 tokens of headroom and retaining all cited clauses. That trace demonstrates practical significance: a setting can raise one metric while violating a gate or harming a critical slice. The report should make that conflict visible.
Read
Release rule
Write a release rule such as: “Ship to 10% only if severe errors are zero on the challenge set, primary task success improves at least three points, every protected slice stays within two points, and p95 latency remains below the agreed budget.” After release, monitor the same constructs with production-appropriate proxies and delayed labels. Offline evaluation and online monitoring form a loop, not competing rituals.