The Idea in One Paragraph
Pick a machine learning research paper on a topic we covered in class. Figure out the one central claim the paper is making, and look hard at the experiments it uses to back that claim up. Then play detective: come up with a different explanation (an alternative hypothesis) that could produce the same experimental results even if the paper's claim were wrong. Design a small experiment where the paper's explanation and yours predict different outcomes, run it, and report what you find in a 4-page report.
That is the whole project. You are not being asked to invent a new method or beat the state of the art. You are being asked to do something more useful and more fundamental: to read a piece of research carefully and ask "how do we actually know this is true?" This is the core skill of doing science, and of being an informed consumer of ML research in a field where new claims appear every day.
Timeline
| Date | Milestone | What you should have by then |
|---|---|---|
| Fri, Oct 9 | Topic and team due | Your group of 4, the paper you chose, and 2-3 sentences on which course topic it relates to and what you think its central claim is. Submitted on Gradescope. |
| Fri, Oct 30 (discussion section) | Project check-in | You have read the paper closely. You can state the central claim in one sentence, describe the key experiments, and have a draft alternative hypothesis. You have run (or at least located and set up) the paper's code. Bring a one-page summary to discuss with the TAs. |
| Fri, Nov 20 (discussion section) | Report review | A full draft of your report with the experiment designed and at least preliminary results. TAs will give feedback on the argument and the experimental design. |
| ~Thu, Dec 17 | Final report due | The final 4-page report, plus appendix and a link to your code. Submitted on Gradescope. |
Start early. The hardest part of this project is thinking, not coding, and thinking takes calendar time. Groups that pick a paper in the first week and read it twice before the check-in tend to do very well. Groups that start the week before the deadline do not.
Step by Step
Step 1: Choose a paper
The paper must be relevant to a topic covered in the course. Roughly, anything that touches on: generalization and evaluation (including LLM benchmarks and contamination), optimization (SGD, momentum, Adam), linear models and regularization, kernels, bias-variance and double descent, SVMs, PCA and clustering, neural networks and their training, ensembles and boosting, self-supervised learning, transformers, scaling laws, in-context learning, emergent abilities, reinforcement learning and RLHF, alignment and safety, or interpretability. If you are unsure whether your paper counts, ask on Piazza.
Where to look: the proceedings of NeurIPS, ICML, and ICLR (all free online, via OpenReview or PMLR), arXiv cs.LG, and the "further reading" pointers in lecture slides. Papers from the last 3-4 years are easiest to work with because their code and data are usually still available.
What makes a paper a good choice for this project:
- It makes a clear empirical claim. "Method X improves Y because of Z", "phenomenon P happens whenever Q", "benchmark B is measuring C". Papers that are mostly theory (proofs, no experiments) are a poor fit, since there is no experimental evidence to examine.
- The main experiments are reproducible at your scale. You will need to run something yourself. If every experiment in the paper needs 64 GPUs for a week, you will have to shrink it dramatically, and that is risky. Look for papers with released code and experiments on small-to-medium datasets (MNIST, CIFAR, small language models, tabular data, synthetic data). Free Colab or a single GPU should be enough.
- It is not too long or too broad. A focused 8-page conference paper is ideal. A 100-page technical report with twenty claims is not.
- You find it interesting. You are going to spend two months with this paper.
Two extra hints. First, papers that challenge a common belief ("X is not actually needed", "Y is a measurement artifact") are often especially good subjects, since they usually make one sharp claim. Second, well-known, highly cited papers are fair game: fame is not evidence, and famous papers have been overturned before.
Step 2: Read the paper (properly)
If this is your first research paper, know that nobody reads a paper front to back in one sitting and understands it. Researchers read in passes:
- First pass (15 minutes): Read the title, abstract, introduction, section headings, all figures and their captions, and the conclusion. Skip everything else. Goal: what problem is this about, and what does it claim to have found?
- Second pass (1-2 hours): Read the whole paper, but skip proofs and skim the fine details of the method. Pay close attention to the experimental section: what datasets, what baselines, what metrics, what is on each axis of each plot. Write down every claim you find and every question you have. Look up terms you do not know.
- Third pass (as long as it takes): Re-read the experiments and the appendix with a critical eye, trying to mentally re-derive what they did and why. This is where you find that a baseline was tuned less carefully than the method, or that a result is only reported on one dataset, or that a plot has no error bars.
Do this as a group but have each person read independently first. Then meet and compare notes: if four of you came away with four different ideas of what the central claim is, that is itself informative.
Step 3: State the central claim
Every paper says many things, but almost every paper has one claim that everything else is in service of. Write it down in one or two plain sentences, in your own words, without jargon from the paper. A good test: if this one sentence turned out to be false, would the paper collapse? If yes, you have found the central claim.
Be careful to separate the claim from the method and from the evidence:
- Method: "We propose optimizer X, which rescales gradients by ..."
- Claim: "X trains transformers faster than Adam because it handles the heavy-tailed gradient noise better."
- Evidence: "On these 3 models and 2 datasets, X reaches the same loss in 30% fewer steps."
Note that the claim usually has two parts: a what (X is faster than Adam) and a why (because of heavy-tailed noise). Both are fair targets for your project.
Step 4: Critically examine the evidence
Now ask: does the evidence actually support the claim, or does it support something weaker? Here is a checklist of questions researchers ask of every experimental section. You do not need to answer all of them, but you should go through them all:
- Baselines. Is the method compared against the strongest reasonable alternative? Was the baseline tuned as carefully as the proposed method (same hyperparameter search budget, same tricks)? A very common failure: the new method gets a careful sweep, the baseline gets default settings.
- Randomness. How many random seeds? Are there error bars or confidence intervals? A 1% improvement from a single run may be noise. If the paper reports a single number per setting, be suspicious.
- Datasets and settings. How many datasets, model sizes, or tasks? Does the effect hold in all of them or only some? Were the datasets chosen before or after seeing results? Are the settings ones where you would expect the method to shine by construction?
- Metrics. Is the metric the right one for the claim? (Recall the lecture on why some "emergent abilities" disappear when you switch from accuracy to a smoother metric.) Is it measured on held-out data? Could the test data overlap with training data (contamination)?
- Ablations. If the paper says the improvement is due to component Z, did they remove Z and show the improvement disappears? Did they check that it is not due to some other change they made at the same time (more parameters, longer training, better data)?
- Scale and compute. Are comparisons fair in terms of compute, parameters, and data? Many "better architecture" results become "more compute" results on closer inspection.
- The gap between evidence and claim. Does the evidence show the what but not the why? Showing X beats Adam does not show it is because of heavy-tailed noise.
Write down the two or three weakest points you find. These are the seeds of your alternative hypothesis. You are not trying to be mean to the authors; every paper, including good ones, has limitations, and the authors would usually agree with you about most of them.
Step 5: Propose an alternative hypothesis
An alternative hypothesis is a different story that explains the same data. The key requirement is that it is consistent with everything the paper reports but disagrees with the paper's explanation. "The paper is wrong" is not a hypothesis; "the improvement comes from the larger learning rate they used for their method, not from the method itself" is.
Some common families of alternative hypotheses in ML, to get you thinking:
- Confound: the method changed two things at once, and the credit belongs to the other one (more parameters, more training steps, a different learning-rate schedule, extra data augmentation).
- Tuning asymmetry: the baseline would match the method if tuned equally well.
- Selection effect: the effect appears on the datasets or model sizes shown but not on others; the shown ones were chosen because it worked there.
- Measurement artifact: the effect is created by the metric, the evaluation protocol, or data contamination rather than by the model.
- Noise: the effect is within seed-to-seed variation.
- Different mechanism: the what is real, but the why is different (it works, but not for the reason given).
Example A. A paper claims a new data augmentation improves image classification accuracy by 2 points on CIFAR-10 because it teaches the network to be invariant to a particular kind of distortion. You notice that models trained with the augmentation were trained for twice as many epochs "to convergence". Alternative hypothesis: the gain comes from the longer training, not the augmentation. Discriminating experiment: train the baseline for the same number of epochs as the augmented model, across 5 seeds each. If the paper is right, the gap stays. If you are right, it shrinks to near zero.
Example B. A paper claims a language model "suddenly" acquires an arithmetic ability at a certain scale, i.e., the ability is emergent. All results use exact-match accuracy. Alternative hypothesis: the underlying ability improves smoothly with scale, and the sharp jump is created by the all-or-nothing metric. Discriminating experiment: re-evaluate the same models with a partial-credit metric (e.g., per-digit accuracy or log-likelihood of the correct answer). If the paper is right, the jump persists under every reasonable metric. If you are right, the curve becomes smooth.
Example C (a paper from Lecture 1). Recht et al. (2019), Do ImageNet Classifiers Generalize to ImageNet?, build fresh CIFAR-10 and ImageNet test sets following the original collection procedure and find that every model loses accuracy on the new set (about 3-15 points on CIFAR-10), with the drop following a tight linear fit. One of the paper's candidate explanations is a distribution shift: despite best efforts, the new images are slightly harder or subtly different from the originals. Alternative hypothesis: the drop is mostly adaptive overfitting to the original test set, i.e., years of the community selecting architectures and hyperparameters by their original-test-set accuracy inflated those numbers. The two stories predict different things for a model that has never been tuned on the original test set. Discriminating experiment: on CIFAR-10, train a handful of models from scratch while choosing every hyperparameter using only a held-out split of the training data, never touching the original test set; then evaluate on both the original and the new test set (both are public). If the shift story is right, your untuned-on-test models should show the same gap as the published ones. If the overfitting story is right, the gap should be noticeably smaller for your models. (The authors do report evidence on this question; part of your job would be to check whether their evidence and yours agree.)
Your alternative does not have to be one you believe. It has to be plausible enough that a careful reader would want it ruled out.
Step 6: Design a discriminating experiment
This is the heart of the project. A good experiment has one property: the paper's hypothesis and your alternative predict different results. Before you run anything, write down in a table what each hypothesis predicts. If both predict the same outcome, the experiment cannot tell them apart and you need a different one.
| If the paper's explanation is right | If our alternative is right | |
|---|---|---|
| Result we expect to see | ... | ... |
Practical advice:
- Reuse the paper's code whenever it exists. Your job is not to reimplement the method; it is to change one thing and see what happens. If there is no code, look for a well-maintained third-party implementation, or choose a different paper.
- Reproduce first. Before your own experiment, try to reproduce one of the paper's key numbers, even at reduced scale. If you cannot get close, that is important (and reportable) information, and it also tells you your setup is not yet trustworthy.
- Shrink deliberately. You will probably run at smaller scale than the paper (smaller model, smaller dataset, fewer steps). That is fine, but state it clearly and think about whether the effect should still be visible at your scale. Synthetic data is often a great tool: you can build a toy setting where you control exactly what is going on.
- Change one thing at a time. Your experiment should differ from the paper's in exactly the way your hypothesis requires, and nothing else.
- Use multiple seeds and report variability. At minimum 3 seeds, preferably 5. Report mean and standard deviation or a confidence interval. Do not let your own experiment have the flaw you criticized in the paper.
- Budget. Everything should run on free Colab, a laptop, or a single GPU within a few hours total. Ask the TAs if you need more.
Step 7: Run it and report what actually happened
There are three possible outcomes and all three are equally good for your grade:
- The results favor the paper's explanation. Great: you have strengthened the evidence for a published claim by ruling out an alternative, which is genuinely useful work.
- The results favor your alternative. Great: you have found a limitation in a published paper.
- The results are inconclusive (noisy, mixed, or the effect did not reproduce at your scale). Also fine, as long as you explain clearly why, and what experiment would settle the question given more resources.
You are graded on the quality of your reasoning and the honesty of your reporting, not on the direction of the outcome. Do not tweak the experiment after the fact until it says what you want, and do not hide runs that did not fit the story. If you changed the plan midway, say so and say why.
The Report
4 pages, not counting references and appendix. Use a standard conference template (the NeurIPS or ICML LaTeX template, single column, 10-11 pt font) or an equivalent. Four pages is short; the constraint is deliberate. Clear thinking fits in four pages, and cutting is part of the exercise.
A suggested structure, with rough page budgets:
| Section | Length | Content |
|---|---|---|
| 1. The paper and its central claim | ~0.5 page | Which paper, which course topic it connects to, and the central claim in your own words. Separate the what from the why. A reader who has not seen the paper should understand what is being claimed. |
| 2. The evidence and its weak points | ~1 page | Describe the key experiments the paper uses to support the claim (not all of them, the load-bearing ones). Then your critical examination: what is convincing, what is not, and why. Be specific: name the figure or table. |
| 3. Alternative hypothesis | ~0.5 page | Your alternative explanation, stated precisely, and why it is consistent with the paper's reported results. |
| 4. Experimental design | ~0.75 page | The experiment, the prediction table (what each hypothesis predicts), and what you changed relative to the paper's setup and why. Enough detail that another group could redo it. |
| 5. Results | ~0.75 page | What happened, with a figure or table including variability across seeds. Which hypothesis do the results favor, and how strongly? |
| 6. Discussion and limitations | ~0.5 page | What you conclude, what you are still unsure about, what you would do with more time or compute. What you learned about reading papers. |
| References | not counted | Cite the paper and anything else you used. |
| Appendix | not counted | Extra plots, hyperparameters, failed attempts, and a link to your code (GitHub or Colab). A short statement of who did what in the group. |
Writing tips for first-time authors: use plain language, prefer short sentences, and put the most important point first in every section. Every figure needs labeled axes, a legend, and a caption that says what the reader should take away. Read your draft aloud; if a sentence is hard to say, it is hard to read.
Grading
The project is 20% of the course grade. Roughly, the report is assessed on:
| Component | Weight | What we look for |
|---|---|---|
| Understanding of the paper and its claim | 20% | The central claim is identified correctly and stated clearly. The paper is summarized accurately and in your own words. |
| Critical examination of the evidence | 25% | Specific, well-reasoned observations about the strength of the experimental evidence. Not just a list of complaints: an argument about what the evidence does and does not show. |
| Alternative hypothesis | 15% | Plausible, precisely stated, and genuinely consistent with the paper's results. |
| Experimental design | 20% | The experiment actually discriminates between the two hypotheses. One thing changed at a time. Sensible use of seeds, baselines, and scale. |
| Execution and reporting of results | 15% | The experiment was run, results are reported honestly with variability, and conclusions match the evidence. |
| Clarity of writing | 5% | Readable, well organized, within the page limit, good figures. |
The check-in and report review milestones are not separately graded, but showing up prepared is how you get feedback that raises your final grade, and groups that skip them rarely do well.
FAQ
Can two groups pick the same paper? Yes, as long as they work independently. You will likely come up with different alternative hypotheses, which is interesting in itself.
What if we cannot reproduce the paper's result at all? Say so, describe what you tried, and think about why (scale? missing details? a bug in your setup? a problem in the paper?). A careful failed reproduction with a clear analysis is a legitimate project outcome. Talk to the TAs early if this happens.
What if our experiment agrees with the paper? That is a perfectly good outcome. See Step 7.
Can we use ChatGPT / Claude / Copilot? You may use AI tools to help understand the paper, debug code, and polish writing. You may not use them to generate the report's analysis or conclusions for you, and you are fully responsible for the correctness of everything you submit. State in the appendix how you used them. If the TAs ask you about your report and you cannot explain it, that is a problem.
Can we pick a paper we have already worked with (in research, an internship, another class)? Only if you tell us, and only if your critical analysis and experiment are new work done for this course.
We are stuck choosing between two papers. Pick the one with working code and smaller experiments.
How much compute is expected? Very little. If your plan needs more than a few GPU-hours in total, simplify it. The thinking is what we are grading.
Where do we ask questions? Piazza, or the Friday discussion section.