Reading AI papers

Three famous models

Now try it on real papers. The code below has two helpers. attention(d, kv) counts one attention part, where d is the width. mlp(d, hidden, gated) counts one MLP, where hidden is the MLP size.

Two details from the papers matter:

• The original Transformer (2017) has an encoder and a decoder. Each decoder block has two attention parts. One is the usual self-attention. The other, cross-attention, reads the encoder's output.
• GPT-3 uses the same embedding table for input and output, so it's counted once. This is called tied embeddings. Llama 2 keeps two separate tables, so it's counted twice.

def attention(d, kv=None):
    kv = kv or d
    return 2 * d * d + 2 * d * kv              # queries and output: d x d; keys and values: d x kv

def mlp(d, hidden, gated):
    return (3 if gated else 2) * d * hidden     # gated (SwiGLU) MLPs have three matrices

# "Attention Is All You Need" (2017), base model: 6 encoder + 6 decoder layers, width 512,
# MLP 2048, a shared 37,000-token vocabulary. Reported: 65 million parameters.
d, hidden = 512, 2048
encoder = 6 * (attention(d) + mlp(d, hidden, False))
decoder = 6 * (2 * attention(d) + mlp(d, hidden, False))       # self-attention plus cross-attention
print(f"Transformer base: {(encoder + decoder + 37000 * d) / 1e6:.0f}M (reported 65M)")

# GPT-3 (2020): 96 layers, width 12,288, MLP 4x width, 50,257-token vocabulary shared with the output.
print(f"GPT-3: {(96 * (attention(12288) + mlp(12288, 4 * 12288, False)) + 50257 * 12288) / 1e9:.1f}B (reported 175B)")

# Llama 2 7B (2023): 32 layers, width 4,096, gated MLP of 11,008, 32,000 tokens, separate input/output embeddings.
print(f"Llama 2 7B: {(32 * (attention(4096) + mlp(4096, 11008, True)) + 2 * 32000 * 4096) / 1e9:.2f}B (reported 6.7B)")

The estimates are 63M against a reported 65M, 174.6B against 175B, and 6.74B against 6.7B. All three land within a few percent. Part of the gap is rounding in the reported figures (the Llama 2 estimate is even a little above its rounded 6.7B). The rest is the biases, layer norms and position embeddings the count skips.

When your estimate is far off, one of two things happened. You misread the configuration, or the paper leaves something out. The second case is worth asking about.

The same habit works for training compute. Compute is counted in FLOPs: one FLOP is one multiply or one add on decimal numbers. The pretraining lesson gave the rule: compute is about 6 × parameters × tokens.

In plain words: training costs about 6 FLOPs for every parameter, for every token it reads.

Take a model with 1,000 parameters trained on 50 tokens. That's 6 × 1,000 × 50 = 300,000 FLOPs. In Python, 6 * 1_000 * 50 gives the same 300000. To check a paper's compute claim, plug in its own parameter and token counts. Cost claims yield to the same kind of arithmetic.

layers, width, mlp_size = 10, 100, 400
print(layers * (4 * width * width + 2 * width * mlp_size))

Is the gain real?

Most results tables compare a new method with a baseline. A baseline is an existing method used as the yardstick. A bigger number in the new method's column looks like a win. But test scores wobble with luck, as you saw in the benchmarks lesson.

Picture a taste test between two bakeries. Say 6 of 10 tasters prefer bakery A. That could easily be luck. Now say 600 of 1,000 tasters prefer A. That almost certainly isn't luck. The share is the same, but the evidence is very different. What matters is the size of the gap compared with the size of the wobble.

The standard error is the typical size of that wobble. You met it in the benchmarks lesson. Divide the gap by the standard error of the gap, and you get the z-score:

z = gap ÷ standard error of the gap

In plain words: z says how many "typical wobbles" the gap is. Suppose the two methods were really equally good. Then a z further from zero than 1.96 would turn up by luck less than 5% of the time. So above 1.96 (about 2), call the gain real. Below it, the gain is within the noise.

import math

new, base, n = 0.60, 0.50, 400
se = math.sqrt(new * (1 - new) / n + base * (1 - base) / n)   # standard error of the gap
z = (new - base) / se
print(round(se, 3), round(z, 2))

A table that fools people

Here's a made-up results table. It's the kind behind many abstracts that say "our method improves accuracy on all three benchmarks". Each row has the benchmark, its number of test items, and the two accuracies.

import math

rows = [  # benchmark, number of test items, new method, baseline
    ("Benchmark A", 500, 0.712, 0.704),
    ("Benchmark B", 10_000, 0.655, 0.641),
    ("Benchmark C", 150, 0.820, 0.787),
]
for name, n, new, base in rows:
    se = math.sqrt(new * (1 - new) / n + base * (1 - base) / n)      # standard error of the difference
    z = (new - base) / se
    verdict = "real (|z| > 1.96)" if abs(z) > 1.96 else "within the noise"
    print(f"{name}: +{(new - base) * 100:.1f} points on {n:,} items, z = {z:.2f}  -> {verdict}")

Read the output row by row.

• Benchmark A: +0.8 points on 500 items gives z = 0.28. That's within the noise.
• Benchmark B: +1.4 points on 10,000 items gives z = 2.07. That's real.
• Benchmark C: +3.3 points on 150 items gives z = 0.72. That's within the noise.

The biggest gain, +3.3 points on Benchmark C, is one of the least convincing. Its test set is tiny. The modest +1.4 points on Benchmark B is the only clear win. "Improves on all three" is true, but only one of the three gains shows more than luck.

What to look for

Your second pass is where you test the evidence. Here's a checklist.

• Baselines. Are they strong and recent? Were they run with the same care as the new method: the same prompts, tuning and compute? Beating a weak or poorly tuned baseline proves little.
• Ablations. Picture a cake recipe with three changes: more butter, a hotter oven and a new flour. The cake is better, but which change did it? You only know if you bake it again, leaving out one change at a time. In a paper, that's an ablation. Without ablations, you can't tell which part of a method did the work.
• Selection. Are the reported numbers the best of many runs, seeds or prompts? Are the examples in the figures typical, or cherry-picked: chosen because they look good?
• Evaluation details. How big is the test set? Did the authors check for contamination, test questions leaking into training data? How many runs were there? How were outputs scored: exact match, an LLM judge, or people? Did the rival models get the same treatment?
• Compute and cost. A small gain bought with ten times the compute may not be worth it.
• Scope of the claim. Results on one model family, one language or toy tasks don't automatically carry over to others. Read the limitations section. Good papers write a real one.
• Who and how. Lab papers often describe systems you can't reproduce. Preprints haven't been peer reviewed. Even peer review rarely re-runs the experiments.

Reading with an LLM

Language models make good reading assistants. You can ask for a summary in plain language. You can ask what an unfamiliar term or equation means. You can ask, "What are the weakest parts of this paper's evidence?"

Give the model the real text. Paste it in, or use a model that can read the PDF. A summary from the model's memory can be wrong or out of date. Then check the key numbers and claims against the paper yourself. A summary is a map, not the territory.

For marketers: a vendor might say, "a study shows our AI improves conversion by 30%". Apply the same checks. What was compared? On how many cases? Chosen how, and measured how?