Reproducing a result
The best way to truly understand a paper is to make its result appear on your own computer. Start small, match one number, and log every difference.
In 60 seconds
Reproducing a result
The best way to truly understand a paper is to make its result appear on your own computer. Start small, match one number, and log every difference.
Step 1: pick the right paper
- Small: the main experiment trains or runs in hours on one GPU or a laptop, not weeks on many GPUs.
- Open: the data is public, and ideally the authors shared code.
- Clear: it reports a specific number you can aim for, such as accuracy on a named dataset.
- Interesting to you: you will spend many hours with it.
Step 2: find the code and data
Step 3: start tiny, then grow
- 1
Run it at all
Install, then run on 100 examples for one step. Fix every error before going bigger. - 2
Overfit a tiny batch
Train on a few examples until the loss is near zero. If it can't, something is broken. - 3
Check the evaluation code
Score the authors' released model or predictions, if they shared any, and compare with the paper. - 4
Run a small version
A fraction of the data or steps, to check the trend looks right. - 5
Run the target setting
Now spend the real compute, with more than one seed if you can.
Step 4: log everything
2026-02-14 run 07
Goal: match Table 2, row 3 (paper reports accuracy 84.1)
Code: authors' repo, commit abc1234
Changes from paper: batch size 16 (paper: 64) because of GPU memory,
used gradient accumulation x4 to keep the same effective batch
Seeds: 0, 1, 2
Result: 82.6, 83.3, 82.9 (mean 82.9)
Gap: about 1.2 below the paper
Next: check tokenizer version; paper footnote mentions lowercasingWhen the number doesn't match
| Possible cause | What to check |
|---|---|
| Random seed variation | Run several seeds. Is the paper's number inside your spread? |
| Different data version or split | Same dataset version, same preprocessing, same test split? |
| Different evaluation | Same metric code? Case, punctuation or tokenisation handled the same way? |
| Hidden settings | Learning rate schedule, warm-up, weight decay, early stopping. Check the appendix and the code's default config. |
| Library versions | A new library version can change defaults. Try the versions the authors list. |
| Hardware and precision | Different GPUs and lower precision can change results slightly. |
| Your own bug | Compare your code with theirs line by line on one small example. |
- Starting with the full, largest run
- Changing five things, then rerunning
- Keeping results only in your memory
- Saying "the paper is wrong" after one failed run
- Starting with 100 examples and one step
- Changing one thing at a time
- Logging every run with its settings
- Reporting the gap, what you tried, and what you're still unsure of
Watch and read more
Lab
A reproducibility checklist for one real paper, with a verdict on whether you could reproduce it and a first-step plan.
The problem
Take the paper from the previous lab, or any small AI paper with a clear number to match.
- Copy the checklist below and answer every line with yes, no or unclear, plus where you found it (section, table, appendix, code file).
- Choose one target number: which table, which row, what value.
- Estimate the compute: can it run on a laptop or a free GPU? If not, what smaller setting in the paper could you try?
- Write your first three steps (for example "run eval on authors' released model", "overfit 10 examples").
- If you have time, do step 1 and write a lab notebook entry for it.
REPRODUCIBILITY CHECKLIST
Paper:
Target number (table/row/value):
Code released? yes / no / unclear - where:
Exact data and version named? yes / no / unclear - where:
Train / validation / test split given? yes / no / unclear - where:
Preprocessing described? yes / no / unclear - where:
All hyperparameters listed? yes / no / unclear - where:
How settings were chosen (val set)? yes / no / unclear - where:
Number of seeds and spread reported? yes / no / unclear - where:
Evaluation metric code available? yes / no / unclear - where:
Library versions listed? yes / no / unclear - where:
Compute used (hardware, hours)? yes / no / unclear - where:
Licence allows my use? yes / no / unclear - where:
Can I run it on my compute?
Smaller setting if not:
First three steps:
1.
2.
3.You are done when
Hard questions
Try to answer before you reveal. If you can answer these, you understood the lesson.
Q1You get a result above the paper's number. Is that good news?Reveal
Be careful. It could be seed luck, a different data version, or a bug such as test data leaking into training. Treat an unexpectedly good result with the same care as a bad one: check the evaluation, the split and several seeds before you believe it.
Q2The paper lists no library versions and the code fails with today's versions. What do you do?Reveal
Look at the date of the code's last commit and try library versions from around that time, in a separate environment so you don't break other projects. Record every version you end up with in your log and in a requirements file. This detail is useful to share, because others will hit the same problem.
Questions people ask
Is reproducing a paper "real research"?
Yes. Checking whether results hold is a core part of science. It also builds exactly the skills you need for original work. Many researchers find their first original idea while reproducing someone else's result, because they notice something the paper missed.
How close is "close enough"?
There is no fixed rule. A useful test: run several seeds and see whether the paper's number falls inside the range you get. If it does, you have likely reproduced it. If it is far outside, look for a cause, and report the gap honestly.
Can I use the authors' code, or must I write my own?
Both are useful and they answer different questions. Running their code checks that the reported number can be reached. Writing your own checks that the paper describes the method fully. Say clearly which one you did.
What if the authors don't reply?
That is common, as people are busy. Write up what you found anyway, with your log, settings and code. State the gap and your best guess of the cause, marked as a guess.
Lesson test
5 questions. Get 3 right (60%) to pass and complete this lesson.