Reading Papers

Papers are how the field communicates ideas to itself before those ideas become curriculum. Reading papers is the only way to be current in 2026; the textbook version of any 2024 result will not exist until 2027 at earliest, and the post-by-influencer version is filtered through someone else's reading.

The honest counterweight: most papers are not worth your time. The bar to publish is low, the rate of replication is unevenly enforced, and the asymmetric incentives of publish-or-perish produce a long tail of work whose claims do not survive a careful reading. Reading a bad paper carefully is worse than not reading it, because you spend the time and you may form a wrong belief that costs you later.

The decision rule that converges on useful: read papers only against a question you have. "What is the best way to evaluate prompt-injection robustness?" is a question. "What is hot on Twitter today?" is not. The question gives you the depth budget and the stop criterion. Without a question, you read until you get tired, learn nothing durable, and convince yourself you have been productive.

When not to read a paper:

• You are trying to build something and the paper does not change the build. Read the README instead.
• The paper claims a small effect size on a benchmark you do not deploy against.
• The first sentence of the abstract is "We propose a novel framework..." and the abstract does not say what the novelty is. (Hard heuristic, but high precision in 2026.)
• You have already read three papers this week and you have not finished implementing the last one.

In 2026 the arXiv cs.LG / cs.CL / cs.AI streams together emit somewhere around 300 papers per day. The community filters at roughly four levels:

1. arXiv-sanity-style aggregators (the modern equivalent of Karpathy's original arxiv-sanity, a tool that "tames the overwhelming flood of papers on Arxiv" by letting you search, sort by similarity, and get recommendations). Sorted by recency, sometimes by topic embedding similarity to papers you have starred.
2. Curated feeds, i.e. researcher-run newsletters and blogs each summarizing a hand-picked slice of the week. Sebastian Raschka's substack, Eugene Yan's reading list, Lilian Weng's blog, Jack Clark's "Import AI", the AlphaSignal newsletter, Hugging Face daily papers. Each is one researcher's high-precision filter; subscribe before you can name the difference between them, and drop the ones that waste your week.
3. Conference acceptances. ICLR, NeurIPS, ICML, ACL. The set of accepted papers is a reasonable proxy for "the community thinks these matter", with the caveat that acceptance rates are around 25% and the rejected papers include both noise and rejected-because-controversial work.
4. Citation graphs and replications. A paper that has been cited 200 times in 18 months has passed the smell test of enough strangers to be worth your attention. A paper that has been actively replicated is in a smaller, much more useful subset.

The right filtering posture for you depends on how much of your job is "be near the frontier" vs "ship something useful with what is already known". For most ML practitioners, filter level (2) is the right load. Subscribe to two curated feeds. Read their summaries. Click through to the paper only when the summary makes you curious.

If you find yourself reading the arXiv listing directly, you have either become a full-time researcher (legitimate) or you are mistaking activity for productivity (much more common). Be honest about which.

Srinivasan Keshav's "How to read a paper" remains the cleanest reading protocol after twenty years. The version I use, adapted to ML:

Pass 1 — five to ten minutes. Title, abstract, introduction. Section and sub-section headings. Conclusions. Glance at references. Decide: do I read this further? Output: a one-paragraph note that says what the paper claims, what evidence it offers, and whether it is worth a deeper read.

The questions to answer after Pass 1:

• Category. Method paper, empirical study, theory, position, survey, benchmark.
• Context. What problem and what prior work.
• Correctness. Do the claims seem reasonable on their face.
• Contributions. What is allegedly new.
• Clarity. Is the paper well-written.

If two of those five are no, stop.

Pass 2 — about an hour. Read the paper carefully, but ignore proofs and ignore details you cannot follow. Look at figures, tables, plots. Mark the references you should look up. Output: a one-page summary that captures the paper's main idea and supporting evidence, in your own words.

By the end of Pass 2 you should be able to explain the paper to someone in your field in five minutes without looking at it. If you cannot, you have not done Pass 2; you have done two iterations of Pass 1.

Pass 3 — four to six hours, sometimes much more. Virtually re-execute the paper. For an ML paper, this means: try to figure out, in your own head, what experiments you would have run to make the same claim. Compare. Where they differ from your imagined version, ask why. Where they did the right thing, ask how they knew. The goal is to identify the paper's hidden assumptions and the alternative paths not taken. Output: a critique, with notes on what would convince you the claim is wrong, and a list of follow-up work the paper makes obvious.

Pass 3 is also where you decide: am I re-implementing this. Sometimes yes. (See section 9.)

Most papers can be triaged in five minutes if you know what to look at. The sequence:

1. Title. Strong signal of category. "Attention Is All You Need" is a method paper claim. "On the Effectiveness of X" is an empirical study. "Towards Y" is often a position paper.
2. Abstract. Read it twice. The first read gets you the claim; the second read gets you the qualifiers. The qualifiers are where the work lives. "Improves performance on Z" — by how much, on which evaluation, with what compute, vs which baselines.
3. Figure 1. ML papers in 2026 reliably put their headline result in Figure 1. If Figure 1 is a confusing block diagram of the proposed method but no result, the authors are not confident.
4. Conclusions. Usually a softened repeat of the abstract, with one or two genuine caveats you would not have seen otherwise.
5. The first paragraph of related work. This tells you what the authors think the relevant prior art is, which is often more revealing than their own contributions.

The trick is to not read the introduction in Pass 1. The introduction is the author's marketing pitch; it is written to convince you to keep reading. Reading it carefully in Pass 1 anchors you to the author's framing before you have decided whether their framing is the right one.

Library path (a personal arXiv triage script). It leans on the arxiv package (pip install arxiv, a thin Python client over the public arXiv API — the same trick Chip Huyen's sotawhat used to query arXiv for abstracts from a script); the notebook stubs the call so you are never blocked offline:

# triage.py — given an arXiv ID, dump abstract + figure 1 caption + conclusion
import arxiv, requests
from pathlib import Path

def triage(arxiv_id: str, out: Path):
    s = arxiv.Search(id_list=[arxiv_id])
    paper = next(arxiv.Client().results(s))
    out.write_text(f"# {paper.title}\n\n"
                   f"**Authors:** {', '.join(a.name for a in paper.authors)}\n"
                   f"**Categories:** {', '.join(paper.categories)}\n"
                   f"**Published:** {paper.published.date()}\n\n"
                   f"## Abstract\n\n{paper.summary}\n\n"
                   f"## Triage notes\n\n- Category (method/empirical/theory/position): \n"
                   f"- Two-sentence claim: \n"
                   f"- Single piece of supporting evidence: \n"
                   f"- Strongest objection: \n"
                   f"- Decision (deeper read / skip): \n")

Open it in your editor of choice; fill in the four lines; save. Now you have a one-paragraph note for every paper you triaged. After a month, this archive is more useful than any external newsletter you could subscribe to, because it is keyed to your questions.

The hour-long careful pass. Read every section in order; skip equations whose meaning you cannot reconstruct after one read. Take notes as you go, in your own words.

The note-taking format that works for me — adapted from Cornell method, biased toward ML:

+--------------------------+--------------------------------------------------+
| TITLE: <paper title>     | CLAIM (in your words):                           |
| AUTHORS: <authors>       | The paper claims that ...                        |
| YEAR: <year>             |                                                  |
| LINK: <arxiv id>         | METHOD:                                          |
|                          | 1. ...                                           |
| KEYWORDS:                | 2. ...                                           |
| - <topic 1>              |                                                  |
| - <topic 2>              | EVIDENCE:                                        |
|                          | - Table 2 shows ... (notice that the baseline    |
| READ ON:                 |   numbers come from a different setup)           |
| <date>                   | - Figure 4: the curve is monotonic in <param>    |
|                          |                                                  |
| RELATED WORK YOU SHOULD  | LIMITATIONS (authors named, plus your own):      |
| READ:                    | - eval is on <narrow domain>; not clear it       |
| - <citation>             |   generalizes                                    |
| - <citation>             | - no ablation of <component>                     |
|                          |                                                  |
+--------------------------+--------------------------------------------------+
|                                                                             |
| ONE-PARAGRAPH SUMMARY (in your own words, no jargon you would not use):     |
|                                                                             |
| [Write this last. It is the artifact you will reread in two years.]         |
|                                                                             |
+-----------------------------------------------------------------------------+

The summary at the bottom is the single most important box. Force yourself to write it without looking at the paper. If you cannot, you have not done Pass 2.

Library path (a paper-card template as a markdown file your knowledge base reads):

title: "Refusal in LLMs is Mediated by a Single Direction"
authors: ["Arditi", "Obeso", "Syed", "Paleka", "Rimsky", "Gurnee", "Nanda"]
year: 2024
arxiv: 2406.11717
keywords: [interp, refusal, steering, safety]
read_on: 2026-05-12

## Claim
Refusal behavior in chat-fine-tuned LLMs is encoded in a single direction in the
residual stream. Ablating that direction at every layer (in inference) removes
refusal without otherwise meaningfully degrading the model.

## Method
1. Pair (harmful, harmless) prompts.
2. Compute mean residual-stream activations at each layer for each set.
3. Refusal direction = mean(harmful) - mean(harmless), normalized.
4. Ablate: project residual stream onto the orthogonal complement at every layer
   for every forward pass.

## Evidence
- Works on Llama-2, Llama-3, Qwen, Mistral families.
- Quantitative: substring-based refusal classifier shows refusal rate drops from
  ~95% to ~5% on harmful prompts.
- Standard benchmarks (MMLU, ARC) ~unchanged.

## Limitations
- Single direction per *family*; differs across families.
- Ablation strength affects helpfulness on edge cases.
- Tested mostly on open-weight chat models; closed models presumably similar but
  not tested.

## What this changes for me
- The Ch 24 refusal-direction lab uses this construction directly.
- Implies that open-weight refusal training is fundamentally undermineable by
  anyone with the weights.

## Related (read next)
- Persona Vectors (Chen et al. 2025)
- The Assistant Axis (Lu et al. 2026)

## Five-minute summary (your own words, no looking)
[...]

The deepest non-implementation pass. The protocol:

For each major claim, write down what experiment would convince you that the claim is wrong. Then check whether that experiment exists in the paper. Some examples:

• Paper claims: "Method X improves accuracy by 3 points on benchmark Y."
  • Falsifier you would run: report on a different benchmark Y' that the method authors did not pick.
  • In the paper? Sometimes. Often only if a reviewer pushed back.
• Paper claims: "The improvement is robust to hyperparameter Z."
  • Falsifier: ablation table over Z.
  • In the paper? Often yes, but check the range of Z.
• Paper claims: "We achieve SOTA on benchmark B."
  • Falsifier: are the baselines well-tuned? Did the authors compare to a 2026 baseline or a 2023 baseline labeled as the SOTA in the original paper?
  • In the paper? Sometimes the comparison is to old numbers; this is the most common fair-comparison failure.

The intent is not to discredit; it is to calibrate your belief in the paper's claims. After Pass 3 you should be able to write a one-paragraph evaluation that names the strongest evidence in favor and the strongest evidence against the central claim.

The output: an internal critique. If the paper survives, it joins the small set of papers you have internally validated. That set is much smaller than the set you have read. The small set is what you build on.

The knowledge base is the artifact that makes reading durable. Without it, you read a paper, you forget the details in three weeks, you re-read it next time you need it. With it, you have a one-page note that primes you in two minutes.

The three systems I have seen work for ML researchers (each is a separate note-taking app you install and learn on its own; none ships with the course, so treat the names below as starting points to go try):

Zettelkasten in Obsidian or Logseq. A Zettelkasten ("slip-box") is a note system that emphasizes links between notes over the notes themselves — Eugene Yan runs his in Roam; Obsidian and Logseq are the popular markdown-file equivalents. One markdown file per paper, dense link graph, daily notes that link to papers as you reference them. Eugene Yan's writeup (24-founder-blogs/eugeneyan-eugeneyan-com-writing-note-taking-zettelkasten) is the canonical entry point. Strength: the link graph reveals adjacency you would not have noticed. Weakness: maintenance discipline required; many people abandon.

Notion / Airtable database. Each paper is a row with columns for keywords, status, summary, "what this changes for me". Queryable by tag. Strength: easy to share with a team. Weakness: doesn't capture link structure.

Org-roam (for the Emacs-curious). Same as Zettelkasten but inside Emacs. The killer feature is org-roam-bibtex: paste an arXiv ID, get a file pre-populated with bibliographic data and a template. Strength: text-based, lasts forever. Weakness: Emacs.

Whatever you pick, three habits make it work:

1. Write the summary in your own words. Copy-paste from the abstract is worthless.
2. Link aggressively. Every paper should link to the related work that produced it and the work it has influenced. The links are the graph; the graph is what makes the base searchable.
3. Add one paragraph of "what this changes for me". If a paper does not change anything for you, it probably should not be in the base. Note the gap; reconsider next time.

Library path (a simple Obsidian-friendly script that turns an arXiv ID into a starter note):

import arxiv, re, sys
from pathlib import Path

def to_note(arxiv_id: str, vault: Path) -> Path:
    paper = next(arxiv.Client().results(arxiv.Search(id_list=[arxiv_id])))
    safe_title = re.sub(r"[^\w\- ]", "", paper.title)[:80]
    fname = vault / f"{paper.published.year}-{arxiv_id}-{safe_title}.md"
    fname.write_text(
        f"---\n"
        f"title: \"{paper.title}\"\n"
        f"authors: {[a.name for a in paper.authors]}\n"
        f"year: {paper.published.year}\n"
        f"arxiv: {arxiv_id}\n"
        f"keywords: []\n"
        f"read_on: \n"
        f"---\n\n"
        f"## Claim\n\n## Method\n\n## Evidence\n\n## Limitations\n\n"
        f"## What this changes for me\n\n## Related (read next)\n\n"
        f"## Five-minute summary (your own words, no looking)\n\n"
    )
    return fname

if __name__ == "__main__":
    print(to_note(sys.argv[1], Path(sys.argv[2])))

When a paper says "as shown in [X]", you have two choices: trust the claim, or follow the citation. Most people trust, by default. The result is a research culture where the loudest secondary sources crowd out the canonical primaries.

Practical citation-graph navigation:

Backward search: from the paper you are reading, follow citations backward to find the foundational works. Usually you can stop after two hops. The paper of interest cites a method paper which cites the seminal paper. Three deep is the right depth budget for most contexts.

Forward search: from a paper you know is canonical, find papers that cite it. Use a free citation-index tool — Semantic Scholar (semanticscholar.org, which also exposes a public API you can script against, as the §8 snippet does), Google Scholar, or Connected Papers. Sort by citation count or by date. The most-cited recent forward citations are usually surveys or follow-up methods.

Connected Papers (connectedpapers.com) is the single most useful citation-graph tool in 2026. Paste an arXiv ID. The tool builds a graph of the most related work by citation-similarity. You see clusters: the prior work, the parallel work, the follow-up work. This is the right way to land on the actual canonical references.

Caveat: citation count is a lagging indicator. A 2026 paper that has been cited 5 times might be more important than a 2022 paper cited 500 times. Also: self-citations, citation rings, and "we cite [bad paper] because it is well-known not because it is correct" are real. Read the cited paper before you cite it yourself.

Library path (the free Semantic Scholar API for forward and backward search; the notebook ships a canned citation graph so this runs with no network):

import requests

def citations(arxiv_id: str, direction: str = "outgoing") -> list[dict]:
    """direction: 'outgoing' = papers this one cites; 'incoming' = papers citing this one"""
    endpoint = "references" if direction == "outgoing" else "citations"
    r = requests.get(
        f"https://api.semanticscholar.org/graph/v1/paper/arXiv:{arxiv_id}/{endpoint}",
        params={"fields": "title,year,authors,citationCount", "limit": 50},
    )
    return r.json()["data"]

# Sort by citation count to find the canonical backward citations
ref_data = citations("2406.11717", "outgoing")
ref_data.sort(key=lambda r: -(r["citedPaper"].get("citationCount") or 0))
for r in ref_data[:10]:
    p = r["citedPaper"]
    print(f"{p.get('citationCount', 0):5d} {p.get('year', '???'):4} {p.get('title')}")

A paper you re-implement is a paper you understand. A paper you have only read is a paper you have opinions about. The two are not the same.

The Harvard NLP "Annotated Transformer" (01-explorables/annotated-transformer) is the prototype: take a canonical paper (Vaswani et al. 2017), reproduce the equations in code interleaved with prose, until the line between paper and implementation disappears. That artifact is the reason a generation of researchers know transformers in their bones. Andrej Karpathy's nanoGPT is the same move applied to GPT-2: read, re-implement, ship the re-implementation as the explanation.

The discipline:

1. Pick a paper with a small core method. A 200-LoC re-implementation is achievable. A 20,000-LoC system is a project, not a re-read. Method papers are good targets; system papers are usually not.
2. Implement the method in isolation. Forget the benchmarks; reproduce one small result that the method enables. If the paper proposes a new attention mechanism, implement it and compare it to standard attention on a toy task. You do not need to reproduce the headline benchmark to verify you understand the method.
3. Match a number. Pick one number from the paper. Reproduce it. The mismatch is the part you do not understand. Hunt it.
4. Write the post-mortem. What did the paper not say that you had to figure out? That delta is the actual content of the paper.

This is the work that turns "I have read about RLHF" into "I have written PPO from scratch and watched the KL term blow up at low warmup and learned to fix it". The latter is durable.

Library path (set up a paper-replication scaffold):

# Standard layout I use for any paper replication
mkdir -p replications/2406.11717-refusal-direction/
cd replications/2406.11717-refusal-direction/
mkdir -p src/ tests/ data/ notebooks/
touch README.md src/method.py src/evaluate.py tests/test_method.py
# README.md captures the target number you are reproducing.
# src/method.py implements the proposed method.
# src/evaluate.py runs the comparison.
# tests/test_method.py asserts the target number is reached (or names the gap).

Most papers do not matter. Some are obviously important on publication day (Vaswani 2017, AlphaGo 2016, GPT-3 2020). Most of the ones that turn out to matter are not obvious in the first 90 days. Some heuristics that beat random:

• The authors have a track record. A new paper from an author whose previous papers held up is more likely to hold up. Track this manually.
• The result is mechanistic, not benchmark-driven. A paper that explains why a thing works tends to outlast a paper that shows the thing works on benchmark B. Benchmarks rotate; mechanisms compose.
• The paper is simple. "We changed one thing and now training works at scale" is the shape of a high-impact paper. "We propose a 9-component framework with 12 hyperparameters" is the shape of a paper nobody reproduces.
• The paper has working open-source code. Especially clean code from the authors, not a reproduction. Code that runs reduces the time-to-replicate, which is correlated with eventual impact.
• Three different people you trust mention it independently within a month. This is not a technical signal; it is a social signal, but it is high-precision.

The anti-signals:

• The first sentence is "Inspired by recent advances in [hot topic]..."
• The benchmark is one the authors created.
• The improvement is monotonic in compute and disappears at small scale.
• The authors will not release code.

The skills compound. You learn to read papers, which makes you a better writer; you learn to write papers, which makes you a better reader. A short discipline for writing your own writeup, internal memo or arXiv:

The TL;DR up top. Three sentences. What you did, what you found, what changes as a result.

The figure-one principle. If your reader sees only one figure, what should it be. Build that figure. Put it on page one. Reference it throughout.

Methods that someone could implement. Not "we used standard transformer". State your config. State the seed. State the eval. State the hyperparameter ranges you searched.

Negative results. What did not work, with the failure mode named. Negative results from credible authors are read more carefully than positive results because nobody has to write them; they are written when the author is being honest.

Limitations as a real section. Not a single defensive paragraph. A list, with the worst limitation first.

Andrej Karpathy's "Recipe for training neural networks" (24-founder-blogs/karpathy-recipe) is a writeup that taught a generation. It is not a paper. It is the right shape of a writeup: opinionated, specific, full of "I learned this the hard way" disclosures. Aim for that.