Reading papers

More is published each week than anyone can read, so the skill is not reading papers but deciding which ones to read, and how far. This section covers a three-pass method that gets you the contribution of most papers in about fifteen minutes, the claims worth being sceptical about, and a way of keeping up that does not eat every evening. Reproducing a paper is the deepest read available, and worth doing occasionally.

Most papers deserve fifteen minutes#

The machine-learning categories on arXiv take several hundred new submissions on a working day, and the share of those that will change anything you do is small enough that reading them properly is not a plan. Triage is the response: a fixed shallow look at many, a longer look at a few, and the full read reserved for the handful you will build on.

The part that takes discipline is that the shallow read has to be deliberate. Opening a paper, reading the introduction, losing interest on page four and closing the tab is also a shallow read, and it leaves you holding the motivation rather than the result. The three passes below differ from that mainly in having a defined output: each one ends in a written note and a decision about what to do next.

Three passes#

1. 1.Five minutes: title, abstract, figures, conclusion. What do they claim and does it matter to you? Most papers stop here.
2. 2.Thirty minutes: method and results. How did they do it, what did they compare against, how large is the effect?
3. 3.Several hours: full detail, and ideally reimplementation. Reserve this for papers you will build on.

Pass one, performed#

Here is a pass one done rather than described. The paper is a composite of the sort of thing that appears on a Tuesday: the title and the numbers are invented so the reasoning is visible, and no real work is being characterised. What matters is the note at the end, because the note is the only thing pass one produces.

PASS ONE  (5 minutes)
"Curriculum ordering improves instruction tuning for small language models"

CLAIM       sorting the supervised fine-tuning set easy-to-hard beats
            random order. Headline: +2.1 on a judged benchmark score.
SETUP       one model family (7B), one instruction set (52k), scored
            by a larger model acting as judge.
FIGURES     Fig 1 is a pipeline diagram and carries no information.
            Fig 2 is the result: two bars, no error bars.
CONCLUSION  claims the effect is general; future work is other sizes.

DOES IT TOUCH MY WORK?   yes - we shuffle our SFT set at random
COST IF TRUE             about a day: score and reorder an existing set
BIGGEST DOUBT            two bars and no error bars implies one run each
DECISION                 pass two. Cheap to act on if true, cheap to
                         check if not. Both halves of that matter.

The decision rule is not whether the paper is interesting. Almost all of them are interesting. It is whether the claim being true would change what you do, and what it would cost you to find out. A paper that would change nothing goes into the category of things you have heard of, which is a real and useful category to have, and you stop there without guilt.

The same five minutes on a paper you cannot check works the same way. The 2017 transformer paper claims an architecture built from attention alone, with the recurrence removed, reaching translation quality comparable to the recurrent systems of the time while training far faster because the computation parallelises. That is the whole of pass one on it: a claim, a setting, and the consequence if true. Everything anyone remembers about that paper is downstream of a sentence you can extract in five minutes.

Pass two, performed#

Thirty minutes, and now you read the experimental setup, the tables, and the paragraph underneath each table. You are not trying to understand the method well enough to implement it. You are answering one question — is the comparison fair — because everything else in the paper is downstream of the answer.

PASS TWO  (30 minutes, same paper)

METHOD      score all 52k instructions for difficulty with a small
            judge model, train in that order, same number of steps
            as the baseline.
BASELINE    random order, same steps, same hyperparameters. Fair on
            budget - which is the usual failure, and is not this one.
NUMBERS     random 6.31, curriculum 6.52. Delta +0.21. The abstract's
            "+2.1" is the same delta on a rescaled axis.
SEEDS       three seeds for the method. ONE for the baseline.
SPREAD      method seeds 6.44 / 6.52 / 6.61, so a spread of 0.17.
ABLATION    none on the difficulty score itself.
MISSING     no hard-to-easy arm. That is the control separating
            "ordering matters" from "this ordering matters", and it
            costs exactly one more training run.

VERDICT     the effect (0.21) is about the size of the method's own
            seed spread (0.17), and the baseline's spread is unknown
            because it was run once. Not established either way.
ACTION      not worth a pass three. Worth an afternoon of my own:
            reorder our set, three seeds each way, on our eval. That
            answers it for the only setup I care about.

That is the ordinary result of a pass two and it is worth sitting with. Nothing in the paper is dishonest and no number is fabricated. But the effect is the same size as the noise the paper itself discloses, the baseline was run once so its noise is unmeasured, and the one extra run that would distinguish the two explanations was not done. None of that was visible from the abstract. All of it was visible in half an hour, and the half hour converted an interesting claim into a specific experiment you can run on your own data.

Pass three is reimplementation#

The third pass is not slower reading. It is rebuilding the result, or one figure of it, from the description. Reserve it for work you will actually build on, which for most people is a few papers a year rather than a few a month, and scope it to a single figure rather than to the paper.

What it teaches is mostly the size of the gap between a paper and a working system. The things that are reliably missing, and that you will have to guess:

• The learning rate schedule, warmup length and optimiser epsilon, of which typically one of the three is stated.
• The exact prompt template, when the result depends on a model being prompted.
• Which version of the evaluation harness, which for judged benchmarks can move a score by more than the paper's effect.
• Whether numbers are the best checkpoint, the last checkpoint, or an average, and what the selection was made on.
• The preprocessing: deduplication, truncation length, how examples that exceed it were handled.
• The failed variants, which are never in the paper and are half of what the authors know.

Having guessed at that list once, you read differently afterwards and permanently. A sentence like 'we follow standard practice for training' stops reading as background and starts reading as three unreported decisions.

Where to be sceptical, and the sentence that triggers it#

Scepticism is not a mood, it is a small set of phrases that should make you stop and look something up. Most of them are not attempts to mislead; they are the ordinary compressions of a paper written to a page limit by people who know what they left out.

YOU READ                          IT OFTEN MEANS        WHAT TO CHECK

"we use the default               the baseline was      whether the method got a
 settings for the baseline"       not tuned             sweep the baseline did not

"results are averaged             the count is          how many seeds, and the
 over multiple runs"              unstated              spread, not just the mean

"we report the best               selection may have    whether selection used a
 checkpoint"                      used the test set     validation split at all

"due to space we omit             the component did     whether they claim credit
 the full ablation"               not help              for that component anyway

"our method is                    it lost               the table row where it
 competitive with X"                                    lost, and by how much

"qualitative examples             these are the best    how many were generated
 are shown in Figure 4"           of many               to obtain four

"we evaluate on a new             standard benchmarks   whether any established
 benchmark we introduce"          did not show it       benchmark appears at all

"the improvement is               it is small           the absolute numbers, and
 substantial"                                           the seed spread beside them

Two more that are structural rather than verbal. First, an effect reported only as a percentage improvement hides its own size: a 40% reduction in error can be 0.5 points, and you cannot tell without the absolute numbers, so find them. Second, the baseline is where most disputes actually live — a comparison against an undertuned baseline measures your tuning, and it is the first thing a reviewer or an interviewer will press on.

The inverse signal is worth naming too, because it is rare and it should raise your estimate of a paper sharply. A paper that reports a variant of its own method that did not work, or a setting where the effect disappears, is telling you the authors looked for the failure themselves. That is much more informative about whether the result will survive than any of its headline numbers.

Keeping up, with actual numbers#

Trying to read everything fails, and failing at it quietly costs more than not trying, because it comes with a permanent sense of being behind. A budget works better than an intention. Here is one that survives a full-time job, written out so that you can argue with the numbers rather than with the idea.

NINETY MINUTES, ONCE A WEEK, THE SAME SLOT EVERY WEEK

  40 titles    scanned from two category feeds, filtered to the
               four or five terms that touch my work          ~15 min
   8 abstracts read properly, drawn from those 40             ~20 min
   2 pass ones written out, drawn from those 8                ~15 min
   1 pass two at most, and often none                         ~30 min
     the rest  filing the notes where I will find them again  ~10 min

  PER MONTH    one pass two that turns into an experiment of my own
  PER QUARTER  one pass three: a single figure from a single paper,
               reimplemented until the number comes out or does not

  NOT IN THE BUDGET: reading anything the day it appears, unless it
  is directly in the way of what I am building this week.

Where the forty titles come from decides the quality of the whole exercise, and it matters more than the number. In descending order of value:

1. 1.Five to ten researchers whose judgement you trust, watched for what they say is worth reading rather than for what they publish. This is the highest-yield source by a wide margin, and it is the one that takes the longest to assemble.
2. 2.One or two curated digests, chosen because a named person selects for them rather than an engagement metric.
3. 3.The arXiv listing for one or two categories, filtered to a short keyword list. Scan titles only. Ten minutes, not thirty.
4. 4.One conference proceedings a year, read as an index of what the field decided was good, not as a reading list.
5. 5.Your own reading: papers that keep appearing in the related-work sections of things you already read are being pointed at by people who have read more than you.

The failure mode to watch for is a feed with no budget attached. Saving papers is not reading them, and a folder of 300 unread PDFs is a record of intentions rather than a library. If a paper has sat unread for a month, it lost to everything else you did that month, and deleting it costs you nothing you had.

Reproduce something#

Reimplementing one result teaches more than reading twenty papers, and the reason is specific: reading tells you what someone concluded, while reproducing tells you how much had to be decided that nobody wrote down. Scope it ruthlessly. Not the paper — one figure, at the smallest scale where the claimed effect should still appear, with your own baseline run first so you have a number to compare against before you have anything to defend.

Two outcomes, both worth the weekend. Either the number comes out, in which case you now own a working implementation of something and you know the six details the paper omitted; or it does not, and you have to decide whether the gap is your bug or the paper's. Resolving that question honestly is the same skill the rest of this topic is about, and it is far easier to practise on somebody else's claim than on your own.

The results section is where a paper is most carefully written and where you should read most slowly. Nobody fabricates numbers; what happens instead is that the honest ones get arranged so the best reading is the obvious one. This section is about the specific things to check — whether a gap is larger than its uncertainty, what a missing error bar means, why the choice of benchmark is itself a claim, and how to recognise a result that will not survive contact with your own data.

Is the gap bigger than the noise?#

This one question settles most tables, and the arithmetic takes a minute. A benchmark score is a proportion measured on a finite number of questions, so it carries the uncertainty of any proportion: roughly the square root of p times one minus p over n. Here is a plausible leaderboard on a thousand-question benchmark.

from math import sqrt

n = 1000                                  # questions in the benchmark
for name, p in [("A", 0.742), ("B", 0.731), ("C", 0.728), ("D", 0.699)]:
    se = sqrt(p * (1 - p) / n)
    print(f"{name}  {p*100:.1f}%   95% CI [{(p-1.96*se)*100:.1f}, {(p+1.96*se)*100:.1f}]")

# A  74.2%   95% CI [71.5, 76.9]
# B  73.1%   95% CI [70.4, 75.8]
# C  72.8%   95% CI [70.0, 75.6]
# D  69.9%   95% CI [67.1, 72.7]

And the gap between the top two, taken directly: 1.1 points, with a standard error of 2.0 and an interval running from minus 2.8 to plus 5.0. It comfortably contains zero, and it contains B beating A by more than A beats B. To resolve a gap that size you would need roughly twelve thousand questions rather than one thousand, because the precision improves only with the square root of the sample.

Missing error bars#

An absent error bar is not a neutral omission. Producing one costs a few more runs, everyone knows it is expected, and the papers that report them are not a random sample. Read a bare number as a single run until told otherwise, and check the appendix before assuming the worst — it is often there, and it is often wider than the gap being claimed in the abstract.

what it says                        how to read it
"84.2"                              one run, probably
"84.2 +/- 0.3"                      over what? seeds, or test examples, or folds?
"84.2 +/- 0.3 (3 seeds)"            good: now the gap can be judged
"84.2 (best of 5)"                  the maximum of 5 draws, which is biased upward
"84.2" in bold, competitor "84.0"   bolding a difference of 0.2 is a claim, not a fact

Benchmark choice is a claim#

Which benchmarks appear is as informative as the numbers on them. A method evaluated on three datasets when the field's standard set has eight was probably evaluated on all eight. A new benchmark introduced in the same paper that proposes the method deserves particular care, because the method and the measure were designed together. None of this is misconduct — reporting your best result is human — but it changes what the table supports.

• Are the standard benchmarks for this problem all present, or a subset?
• Is the comparison against the strongest published baseline, or a convenient one?
• Are the baseline numbers copied from other papers, which may use different preprocessing, or rerun here?
• Does the improvement hold across every dataset, or come from one where the gain is large?
• Is the test set one the method's training data could plausibly have seen?

That last one has become the decisive question for anything involving a pretrained model. If a benchmark was published before the training data was collected, the questions and often the answers may simply be in the training set, and the score then measures memorisation. It is the first thing to check on a suspiciously strong language-model result, and the papers that have checked usually say so explicitly.

Results that will not replicate#

After a while these become recognisable on sight. The signals are consistent, and each has an innocent explanation that is sometimes even true.

signal                                  what it often means
a large gain on one dataset, small       the gain is that dataset, not the method
  or negative elsewhere
improvement of the same size as the      it has not been measured yet
  seed-to-seed spread
a method with many components and        the components are carrying nothing
  no ablation
hyperparameters tuned for the method     you are reading a tuning result
  but stated as defaults for baselines
the gain shrinks as the baseline gets    it was a baseline gap, not a method gain
  stronger across the table
no code, and a detail-light method       reproduction will find the missing details
  section

None of this means distrusting papers. It means reading the results section as evidence with a known error bar rather than as a verdict, which is exactly what its authors would want from a careful reader — and it is what an interviewer is testing when they hand you a paper and ask what you think of it.

The equations in a machine learning paper are usually a compressed description of about ten lines of code, and the notation is a small fixed vocabulary that recurs almost everywhere. This section gives you that vocabulary, then a method that works on any equation you meet: check the shape of everything in it, substitute small numbers and compute by hand, then write the code. The rest of the section does exactly that to the equation you will meet most often, at the pace you should do it yourself.

A small dictionary#

E_{x ~ p}[f(x)]      average of f(x) over x drawn from p     -> a mean over samples
argmax_x f(x)        the x that makes f largest              -> the best choice, not the value
nabla_theta L        gradient of L w.r.t. parameters         -> what loss.backward() computes
KL(p || q)           how different q is from p               -> not symmetric
sum_i / prod_i       add up / multiply together over i       -> a loop, or an axis argument
x ~ p                x is drawn from the distribution p      -> a sample
|| x ||              length of the vector x                  -> np.linalg.norm
x . y  or  x^T y     dot product                             -> (x * y).sum()
1[condition]         1 if the condition holds, else 0        -> a boolean used as a number
theta / phi          parameters being learned                -> the weights
hat{y}               a predicted value, not the true one     -> model output
log p(x)             log probability                         -> always logs, to avoid underflow

Shapes before meaning#

For every symbol, write down its shape: scalar, vector of length d, matrix n by d. Do this before trying to understand what the equation means, because most equations become obvious once the shapes are known, and a shape that does not line up is proof you have misread something rather than proof the maths is hard. Take scaled dot-product attention, written in every transformer paper as softmax of Q K-transpose over the square root of d-k, times V.

Q    [n_q, d]      one row per query
K    [n_k, d]      one row per key
V    [n_k, d_v]    one row per value, and there are as many values as keys

Q K^T              [n_q, d] @ [d, n_k]  ->  [n_q, n_k]   every query against every key
/ sqrt(d)          shape unchanged                       a scalar divide
softmax(...)       [n_q, n_k], each row summing to 1     the rows are the weights
... @ V            [n_q, n_k] @ [n_k, d_v] -> [n_q, d_v] one output row per query

Plug in numbers#

Now make it concrete with the smallest example that still has structure: one query, three keys, two dimensions. Choose values you can compute in your head — a query that points along the first axis, and keys that point along the first, the second, and diagonally between them.

Q = [[1, 0]]                 one query, pointing along the first axis
K = [[1, 0], [0, 1], [1, 1]] three keys: same direction, perpendicular, between
V = [[10, 0], [0, 10], [5, 5]]

Q K^T   = [[1, 0, 1]]        query matches key 1 and key 3, not key 2
/ sqrt(2) = [[0.707, 0, 0.707]]
softmax = [[0.401, 0.198, 0.401]]   the two matching keys share most of the weight
@ V     = [[6.017, 3.983]]          mostly value 1 and value 3, a little of value 2

Then push it to the extremes, which is where the understanding actually arrives. Multiply Q by ten: the scores become 10, 0, 10, the softmax becomes 0.4998, 0.0004, 0.4998, and the output is a hard selection rather than a blend — which is why the scale of the scores matters and why the division by the square root of d is in the equation at all. Without it, larger d makes the dot products larger, the softmax sharper, and the gradients smaller.

Code it#

The last step is to write the ten lines and check them against the numbers you computed by hand. If they agree, you have read the equation correctly; if they do not, one of the two is wrong and finding out which is the fastest learning available.

import numpy as np

def attention(Q, K, V):
    d = Q.shape[-1]
    scores = Q @ K.T / np.sqrt(d)                  # [n_q, n_k]
    scores = scores - scores.max(-1, keepdims=True)  # subtract max: no overflow
    w = np.exp(scores)
    w = w / w.sum(-1, keepdims=True)               # rows sum to 1
    return w @ V                                   # [n_q, d_v]

Q = np.array([[1.0, 0.0]])
K = np.array([[1.0, 0.0], [0.0, 1.0], [1.0, 1.0]])
V = np.array([[10.0, 0.0], [0.0, 10.0], [5.0, 5.0]])
print(np.round(attention(Q, K, V), 3))
# [[6.017 3.983]]

The same four steps handle equations that look far worse. The DPO objective below is a page of derivation in its paper and four lines here, and the notation is all in the dictionary above: an expectation is a mean, pi and ref are two models' log probabilities of the same text, and the subscripts w and l are the preferred and rejected responses.

# L = -E[ log sigma( beta * ((log pi(y_w|x) - log ref(y_w|x))
#                            - (log pi(y_l|x) - log ref(y_l|x))) ) ]
import torch.nn.functional as F

def dpo_loss(pi_w, pi_l, ref_w, ref_l, beta=0.1):   # all log probs, shape [batch]
    margin = beta * ((pi_w - ref_w) - (pi_l - ref_l))
    return -F.logsigmoid(margin).mean()

Reproducing a result teaches more per hour than reading does, because it forces every detail the paper left implicit out into the open. This section covers choosing a paper you can afford to reproduce, working from the paper before the code, starting small enough that the first run finishes, diagnosing a mismatch in the order that finds it fastest, and writing up what you found. It starts with a reproduction you can run in the next two minutes.

One you can run right now#

Double descent is a well-known result: as a model grows past the point where it can fit the training data exactly, test error rises to a peak and then falls again, ending up better than any of the smaller models. It contradicts the bias-variance picture most courses teach, it was the subject of a widely cited paper, and it reproduces on a laptop in about fifteen lines. Forty training examples, and a random-feature model whose width is swept from far below that to ten times it.

import numpy as np
rng = np.random.default_rng(0)

n_train, n_test, d = 40, 500, 20
w = rng.normal(size=d)

def make(n):
    X = rng.normal(size=(n, d))
    return X, X @ w + rng.normal(0, 0.5, n)

Xtr, ytr = make(n_train)
Xte, yte = make(n_test)

P = rng.normal(size=(d, 400))            # a pool of random projections
for p in (5, 20, 38, 40, 42, 50, 80, 200, 400):
    Ftr = np.tanh(Xtr @ P[:, :p])        # p random features
    Fte = np.tanh(Xte @ P[:, :p])
    beta, *_ = np.linalg.lstsq(Ftr, ytr, rcond=None)   # minimum-norm fit
    print(f"p={p:4d}  test MSE {np.mean((Fte @ beta - yte) ** 2):10.3f}")

# p=   5  test MSE     12.834
# p=  20  test MSE     13.360
# p=  38  test MSE    228.365
# p=  40  test MSE    248.771      <- p = n, the interpolation threshold
# p=  42  test MSE    183.613
# p=  50  test MSE     36.164
# p=  80  test MSE      5.108
# p= 200  test MSE      3.693
# p= 400  test MSE      3.106      <- ten times as many parameters as data

That is what a reproduction feels like when it works, and it is why the exercise is worth the hours. You now know something is true rather than having read that it is, you have a knob you can turn, and the next questions arrive on their own — why does the peak sit there, what happens with regularisation added, what happens with more training data. Each is a short edit away.

Choose well#

Most reproductions fail at the choosing step, because the paper needed a cluster and a month. Pick for feasibility first and interest second, since an interesting paper you cannot finish teaches nothing.

• The compute fits what you have, or the result has a small-scale version that keeps the phenomenon.
• The data is public and downloadable today, not on request.
• The claim is specific enough to be checked — a number in a table, not a general improvement.
• There is official code, ideally one you deliberately do not read until your version runs.
• The result is surprising to you. Reproducing something you already believe teaches less.

Implement from the paper, then compare#

Write your version from the paper first. Only then read the official code, and list every difference. Official code routinely contains details the paper omits — a learning rate warmup, a normalisation, a data filter, a gradient clip, an evaluation that drops the last incomplete batch. That list of differences is the most valuable artefact the exercise produces, and it is the thing you can only get by implementing first. Read the code first and you will simply absorb the details without ever noticing they were missing.

Start small#

Get the method working on a tiny version of the problem first: fewer layers, less data, shorter training. Confirm your baseline matches the paper's baseline at that scale before you test the method at all. If the baseline is off, the method comparison is meaningless and every hour spent on it is wasted. A run you can complete in two minutes is worth more than a faithful one you can run twice.

When numbers do not match#

They usually will not, and the causes have a reliable order. Work down this list rather than rereading the method, because the method is rarely the problem.

check first, it is usually here
  evaluation mismatch   different split, different metric, different averaging
  preprocessing         tokenizer, normalisation, resizing, deduplication
  seed variance         is your gap smaller than the run-to-run spread?
  training budget       steps, epochs, batch size, effective batch after accumulation
  schedule details      warmup, decay shape, gradient clipping
  numerical precision   fp16 vs bf16 vs fp32, and where the loss is accumulated

check last, it is rarely here
  the method itself     the equation you implemented from the paper

Write it up#

A short report saying what you reproduced, what differed, which undocumented details you found, and a link to your code is a genuinely useful public artefact — and for research roles it is some of the most persuasive evidence you can offer, because it is the only kind that shows what you do when a number does not come out right. Keep it to a page: the claim, your setup, a table of your numbers against the paper's, the differences you found, and what you would check next.