Buckets:
| Name | Size | Uploaded | Xet hash |
|---|---|---|---|
| data | 2 items | ||
| model | 14 items | ||
| results | 18 items | ||
| README.md | 11.6 kB xet | 835b6dfb | |
| evaluation.ipynb | 519 kB xet | fc035ae5 | |
| model_reference.json | 93 Bytes xet | 00c50a98 | |
| requirements.txt | 98 Bytes xet | ec782264 | |
| run_config.json | 214 Bytes xet | 669ed41d | |
| save_model.py | 2.19 kB xet | d04e2ca9 |
Does next-token prediction mean having a basic world understanding?
Ahmed Nasr · Fatima Fellowship technical challenge: frontier model blind spots
Model: Qwen/Qwen3.5-4B · text inputs only
Blind spot: fluent prediction without a stable model of the world it describes. Qwen3.5-4B can state the right physics and still choose an answer that contradicts it. Tell the same events in a different order and it loses track of where an object is. It treats a clock reading as a duration, and misses that a velocity changes sign. Its answers depend on how a situation is worded, even when the situation itself is the same.
Summary
The challenge asks for a simple evaluation of a frontier model that finds a blind spot. I chose a blind spot connected to a question I keep returning to: does learning to predict the next token give a model a basic understanding of the world?
If a model's training has given it a working representation of the world behind the text, it should track physical state as events unfold. It should treat 1.10 s, 1100 ms and "one point one seconds" as the same quantity, and apply concepts like force, acceleration and momentum correctly however the situation is phrased. If what it has learned is mostly surface patterns, its answers will shift when the wording shifts.
I tested this on Qwen3.5-4B with 15 multiple-choice questions about object locations, event order, time and basic mechanics. Some questions describe the same situation in different words, which shouldn't change the answer. Others change one relevant condition, which should. A behavioral test like this can't reveal what the model represents internally, but it can show where its answers stop following the world being described.
The model scored 9/15 (60.0%). Adding an instruction to track states and events gave 8/15 (53.3%). The specific failures:
- The reason and the selected option disagree. The model often picked one option and then wrote a correct calculation that supports a different one.
- Clock readings get confused with durations. In one case it used a timestamp as the elapsed time.
- Out-of-order narration breaks state tracking. When the steps of a story were listed out of chronological order, it put the coin in the wrong room.
- Velocity reversal is missed. Under a constant opposing acceleration, it said the cart stops, when it actually reverses direction.
A broader 93-question exploratory set (75.3%) is included as supplementary context.
Motivation
My interest in ML for physical modeling is why I focused on motion, quantities, space, and time. The experiment is text-only, but the same questions matter for VLMs interpreting physical scenes and for video generators keeping object identity and causal continuity.
Evaluation design
| Group | Questions | Example |
|---|---|---|
| Object-state tracking | 3 | Where is a coin after its box is moved and emptied? |
| Numerical time and motion | 5 | Does changing timestamp notation change the answer? |
| Basic mechanics | 3 | Does the model distinguish force from acceleration? |
| Dataset-adapted temporal examples | 4 | Clock arithmetic, before/after relations, and missing information |
Some questions describe the same situation in different ways. Others change one condition so that the answer should change.
For example, a cart starts at rest and accelerates at 2 m/s² from 1.10 s to 1.90 s, then coasts. Its velocity is 1.60 m/s. Writing the timestamps in milliseconds or in words, or shifting the clock origin by 100 s, preserves that answer. Moving the switch-off time to 2.90 s (accelerating from 1.10 s to 2.90 s, queried at 3.50 s) changes it to 3.60 m/s.
Four questions are adapted from TimeBench (TimeX-NLI examples) and TRAM (temporal arithmetic examples). Source locations and changes are recorded in data/curated_eval.csv. Results on these adaptations are not comparable to official benchmark scores.
Model and settings
Qwen/Qwen3.5-4B was run in Colab on an NVIDIA L4 GPU, in bfloat16. The checkpoint includes a vision encoder, but only text inputs were used.
- Greedy decoding:
do_sample=False. - Thinking disabled:
enable_thinking=False. - Output limit:
max_new_tokens=256. - Response format: JSON with an answer letter and a one-sentence reason.
- Options are shuffled deterministically per question family (seed 42), so matched variants and both prompt conditions see the same option order.
I compared the baseline prompt with an added instruction to track states and events. Scoring uses the options actually shown to the model. The exported results keep the prompts, raw responses, expected answers, and flags for invalid and truncated outputs.
Results
| Group | Correct | Accuracy |
|---|---|---|
| Object-state tracking | 2/3 | 66.7% |
| Numerical time and motion | 1/5 | 20.0% |
| Basic mechanics | 2/3 | 66.7% |
| Dataset-adapted temporal examples | 4/4 | 100.0% |
| Total | 9/15 | 60.0% |
Neither run had invalid or truncated outputs. Reading the reasons alongside the selected answers separates the failures into the kinds below.
The reason and the selected option disagree. In N_cart_decimal, the model selected the 3.60 m/s option, but its reason computes the correct 0.80 s duration and 1.60 m/s velocity. The millisecond and shifted-clock variants show the same mismatch. The JSON format puts answer before reason, and thinking is disabled, so the letter is generated before any calculation. The reason therefore can't have informed the choice. It reads more like a separate attempt at the problem than a justification of the selected letter.
A clock reading is used as a duration. In N_cart_words, the reason uses 1.9 s as the acceleration duration, although the motor started at 1.1 s. It gives 3.8 m/s, which also doesn't match the selected 3.60 m/s option.
All five cart variants selected the 3.60 m/s option, which was listed as option A. That is correct only for the longer-interval variant, so the 1/5 score mixes reasoning errors with answer-selection errors. Whether this reflects a bias toward the first option would need re-shuffled options to check.
Out-of-order narration. In T_coin_retold, the same coin steps are given with timestamps (10:00, 10:01, 10:02) but listed in reverse order. The model said the box was emptied in the kitchen. The same question narrated in order was answered correctly.
Velocity reversal. In P_negative_acceleration, a cart moving right at 2 m/s has a constant 1 m/s² leftward acceleration for 5 s. Its speed falls to zero at 2 s and then increases as the cart moves left. The model answered that the speed decreases throughout, until the cart "stops".
Prompt comparison
| Prompt | Correct | Accuracy |
|---|---|---|
| Baseline | 9/15 | 60.0% |
| State tracking | 8/15 | 53.3% |
The state-tracking instruction fixed no answers and introduced one regression. In the regressed coin question, the reason still said the coin was on the bedroom floor, but the selected option placed it on the kitchen floor. Prompting alone did not close these gaps.
What could address these gaps
These are proposed follow-ups. This is pure analysis; I haven't tried any of these methods.
Data. The most direct step is a larger set of generated scenarios, such as object transfers, clock arithmetic, and one-dimensional kinematics. Each scenario would have its answer computed by a program and its intermediate states recorded. Each one would also come in several meaning-preserving rewrites (units, number formats, narration order, option order) and controlled changes that alter the answer. Scenario families should be kept separate between training and evaluation, so that the test measures generalization, not recall of near-duplicates.
Supervising intermediate steps. Since the answers are computed by a program, intermediate steps can be checked: event order, object location after each step, elapsed time, and velocity. This makes process supervision possible. Preference pairs for DPO can contrast correct responses with ones that contain a specific error, including a correct reason paired with the wrong option. RL with programmatic checks as the reward is a further option.
Scale and inference. Running the same scenario families on larger checkpoints and with thinking enabled would show how much of the gap comes from model size and inference settings.
My first follow-up would be the scenario dataset with verified intermediate states. It provides a baseline that fine-tuning, DPO, or RL can then be compared against.
Supplementary: 93-question exploratory set
I also ran a broader exploratory collection covering everyday science, event sequences, ML concepts, PDEs, scientific assumptions, and technical language. It helped me choose the focused set. Most of its items were drafted with assistant help, as recorded in the origin column.
| Group | Correct | Accuracy |
|---|---|---|
| Dataset examples | 7/8 | 87.5% |
| Everyday science | 16/20 | 80.0% |
| ML concepts | 5/10 | 50.0% |
| PDE concepts | 6/9 | 66.7% |
| Scientific assumptions | 3/3 | 100.0% |
| Technical language | 9/10 | 90.0% |
| Temporal physics | 24/33 | 72.7% |
| Total | 70/93 | 75.3% |
This run had one output that was both invalid and truncated (ML_units_equal_mse). The two collections share some scenarios but use different wording and conditions, so I report them separately. The same reason/option mismatch appears here too. For example, the reason for T_coin_paraphrase says "bedroom floor", but the selected option is "Inside the box in the kitchen".
Limitations
This is a small exploratory study of one checkpoint. I designed the focused set after seeing the exploratory results, and related variants are not independent observations.
The outputs don't reveal the model's internal representations or show what it does or doesn't understand. They show specific inconsistencies under the tested settings. I also can't establish whether similar questions appeared in its training data.
Files and reproduction
| Path | Contents |
|---|---|
evaluation.ipynb |
Notebook with displayed outputs |
data/curated_eval.csv |
The 15 questions, gold answers, and source metadata |
data/questions.csv |
The 93-question exploratory set |
results/baseline_15.*, results/curated_baseline.jsonl |
Baseline run on the 15 questions: prompts, raw responses, scores |
results/state_df_15.*, results/curated_state_tracking.jsonl |
State-tracking run on the 15 questions |
results/comparison_15.*, results/comparison.csv |
Per-question baseline vs. state-tracking outcome |
results/content_eval_20261021_232844_183727/ |
93-question run: inputs, responses, review table, summary, settings |
run_config.json |
Generation settings |
requirements.txt |
Package versions |
save_model.py |
Downloads the checkpoint at a pinned revision; --verify loads it on CPU |
model/, model_reference.json |
Local copy of the checkpoint and its model ID and revision |
results_df_15.* and evaluation_15.* are identical to baseline_15.*.
To reproduce, open the notebook in Colab with a GPU, install the dependencies, and upload curated_eval.csv and questions.csv to /content/. Then run the cells in order.
- Total size
- 9.34 GB
- Files
- 40
- Last updated
- Oct 22
- Pre-warmed CDN
- US EU US EU