annotated_research_papers: A PDF Collection of Hand-Annotated Machine Learning Papers

What annotated_research_papers actually is, and who it is for

This repository is a collection of PDFs with annotations already drawn on them. The README frames the motivation plainly: the author reads papers as part of machine learning work and describes himself as "a pen-paper guy", so the annotations reproduce the margin notes he would otherwise write on a printed copy. The stated audience is anyone who finds research papers intimidating, or who wants to read more of them and wants a worked example of how one reader moves through a paper.

That framing matters, because the name invites a wrong expectation. This is not a tool, not a library, and not an annotation format. There is no schema, no viewer, and no pipeline that ingests a paper and marks it up. What you get is a set of files. The author also sets a scope limit in the README: "I cannot annotate all the papers I read, but you can expect all the interesting papers to be uploaded here." The ordering is not strictly chronological either, since papers are sometimes put on hold and read later.

The practical audience is narrow and specific. It suits a student or engineer who is working through a canonical paper, such as Vision Transformer or Masked Autoencoders, and wants to see where another reader paused. It does not suit anyone who needs a citation manager, a reading queue, or an automated summary.

How the papers are organised by field

The repository is a directory tree, and the top level names the fields: MLLMs, NLP, diffusion_models, gans, interpretability_and_explainability, meta-learning, multi-task-learning, segmentation, self-supervised-learning, semi-supervised-learning, speech, and supervised. A static directory holds the image used in the README, and the licence sits alongside the README at the root.

The README carries a table with three useful columns: the annotated paper, a link to code where one exists, and a link to the abstract. The paper links are relative paths into the tree, so a row for ConvNext points at ./supervised/convnexts.pdf, while its code link goes to the ConvNeXt repository from Facebook Research and its abstract link goes to arXiv. Not every row has a code link. Segment Anything, for example, has an abstract link but no code link in the table.

Two things are worth flagging. First, the table is incomplete. It contains rows with empty cells, and it is truncated in the README as given, so the table is not a reliable index of everything in the tree. Second, the annotations live inside the PDF, not in a sidecar file. There is no separate annotation layer to parse, which means the only way to read them is to open the PDF.

Getting the PDFs and reading one

The README does not document an installation step, because there is nothing to install. The project says to get it by cloning the repository. The command below clones the default branch, master, into a local directory.

git clone https://github.com/AakashKumarNain/annotated_research_papers.git
cd annotated_research_papers

After that you have the tree on disk. To confirm the layout matches the README, list the top level. You should see the field directories named in the README, such as supervised and self-supervised-learning, plus README.md, LICENSE, and static.

ls

To open a specific annotated paper, use the relative path from the README table. The example below opens the Vision Transformer annotation, which the README links as ./supervised/an_image_is_worth_16x16_words_transformers_for_image_recognition_at_scale.pdf. Any PDF viewer works, and the annotations are visible in the page margins.

open supervised/an_image_is_worth_16x16_words_transformers_for_image_recognition_at_scale.pdf

That is the whole first use. There is no build, no server, and no configuration file.

What the annotations cannot do, and where the repository is thin

The central limitation is coverage. The README states that not every paper the author reads gets annotated, and that only the interesting ones are expected to be uploaded. The table shows the consequence: there are blank rows, and some rows are missing code links. A reader who arrives looking for a specific paper in a specific subfield may find nothing.

The second limitation is that annotations are personal notes, not a tutorial. The README describes sharing "my thought process", which is a different product from a structured explanation of the paper. Nothing in the repository states a convention for what the marks mean, so there is no legend to consult. If you want to know why a passage was underlined, the answer is in the author's head, not in the repository.

The third is discoverability. Because the table is incomplete and the README is the only index, browsing means listing directories yourself. There is also no release and no versioned snapshot, so the state of the collection is whatever master holds at the moment you clone. And if what you actually need is a formatted annotated bibliography with citations, this repository is the wrong tool entirely: it produces no citation text and follows no style guide.

Alternatives: a curated PDF set versus a generated bibliography

The closest alternative in practice is not another repository of the same kind. It is an annotated bibliography workflow, where you write the entry yourself or generate it. The difference in approach is fundamental. Here, the artefact is a marked-up PDF and the value is in the human reading trace. In a bibliography workflow, the artefact is text: a citation followed by a summary and an evaluation, formatted to a style such as APA.

That distinction decides the choice. If your goal is to understand a paper, the PDF annotations give you something a generated entry cannot, because they show where a reader stopped and what they noticed. If your goal is to submit a literature review with a reference list, the PDFs are useless to you, and a generator or a reference manager is the right category of tool.

A second alternative is simply reading the paper alongside its official code repository. Several rows in the table link to the authors' code, so you can pair the annotated PDF with a working implementation. That route gives you executable detail, but it gives you no reading trace, which is exactly what this repository supplies.

Maintenance, licence, and the cost of following along

The repository is not archived, and the last push was on 2026-08-29. That is recent enough that the collection is still being extended, though no release has been published, so there is no version to pin and no changelog to read. Upgrading is therefore a plain git pull, and the cost of staying current is the cost of re-cloning or pulling, plus whatever it takes to re-read a PDF you had already opened.

The licence is MIT, declared at the root of the repository. That covers the repository's own contents. It does not change the status of the papers themselves. Each PDF is a copy of a paper whose rights sit with its authors or publisher, and the README links to the original abstract on arXiv or OpenReview for each entry. If you intend to redistribute the PDFs rather than read them locally, check the terms attached to each paper; the MIT licence on this repository is not a statement about them. Nothing here is legal advice.

The ongoing cost is editorial rather than technical. Because annotations are hand-drawn and the author annotates selectively, the collection grows at the pace of one person's reading, and the README makes no commitment about what will be added next.

Editorial conclusion

Adopt it if you learn better from a worked example than from an abstract, and if the papers already listed match what you are reading. Do not adopt it as a bibliography workflow: it produces no citations and no formatting. Before relying on it, check the directory for the field you care about and open the PDF, because the README table is incomplete and the repository holds no releases to pin.

Frequently asked questions

Official sources

1. AakashKumarNain/annotated_research_papers on GitHub
2. Issues
3. License: MIT
4. README