Common Mistakes When Citing AI and Machine Learning Papers

A citation to an AI or machine learning paper often looks solid on the surface: an author list, a year, a title, maybe an arXiv identifier. But look closer at how these citations get used in blog posts, technical documentation, and even academic drafts, and a pattern emerges. The paper referenced isn't quite the paper being discussed. The numbers cited don't match what the current version reports. The model name means something different than it did when the citation was written. These aren't rare slip-ups; they're structural problems that come from how fast this field moves and how casually most people cite it.

Traditional academic citation norms assume a paper is a fixed object: published once, indexed once, cited forever with the same meaning. AI and ML research doesn't work that way. Papers get revised on arXiv multiple times before or instead of formal publication. Model names get reused for substantially different systems. Benchmark numbers get updated as authors fix bugs or add baselines. Citing this literature correctly requires a different set of habits than citing a chemistry paper from 1998. Here are the mistakes that come up most often, along with what to do instead.

Citing the arXiv Preprint Without Checking for a Published Version

arXiv is where most ML research first appears, and for many practitioners it's also where the citation trail ends. The problem is that a large share of papers posted to arXiv are later accepted at a conference or journal, and the peer-reviewed version frequently differs from the original preprint. Reviewers ask for additional baselines. Authors catch errors in their own benchmark numbers. Sometimes a method gets renamed between v1 and the camera-ready version because a name collision was pointed out during review.

If you cite an early arXiv version and the paper was later revised, your citation may point to conclusions the authors no longer stand behind. This is easy to miss because the title and author list usually stay the same, so nothing about the citation looks wrong at a glance.

A simple pre-citation check

• Search the paper title in a general search engine or academic search tool to see if it has a conference or journal listing.
• Check whether the paper has a DOI, which usually indicates a formal publication rather than just a preprint.
• If a published version exists, cite that one and treat the arXiv link as a secondary, open-access pointer.
• If you must cite a specific arXiv version because you're referencing preliminary results, name the version number explicitly (for example, "v1") so readers know exactly what you're pointing to.

Citation managers that auto-fetch metadata are not reliable for this. They often index whichever entry appeared first, which is usually the preprint, and they rarely reconcile it with a later published record automatically. A manual check takes a minute and prevents citing a version the authors themselves have superseded.

Treating Model Names as Static When They Refer to a Moving Target

Model names in AI research are frequently reused, extended, or applied to systems that changed significantly over time. A name that referred to a specific architecture and training setup at launch may later refer to a different checkpoint, a fine-tuned variant, or an entirely retrained version with the same public-facing label. When someone cites "the model described in Paper X" without specifying a version or checkpoint, readers have no way to know which iteration is meant.

This becomes a real problem when the citation is used to justify a claim. If a paper reports a capability or limitation for one version of a model, and a later version addresses that limitation, citing the paper without a date or version marker can misrepresent the current state of the system entirely.

What a precise citation looks like

Adding a date or version qualifier costs a few words and removes ambiguity about whether the finding still applies.

Copying Benchmark Numbers Without Noting the Evaluation Setup

Benchmark tables in ML papers are frequently cited as if the numbers are context-free facts, when in reality they depend heavily on the evaluation setup: which dataset split was used, whether few-shot or zero-shot prompting was applied, what hardware and hyperparameters were involved, and sometimes which version of an evaluation script was run. Two papers can report different numbers for the same model on the same benchmark simply because they measured it differently.

When someone lifts a number from a table and cites it as a general fact about a model's performance, they strip away all of that context. This is how misleading comparisons spread: a number gets cited, then re-cited from the citation rather than the source, and by the third or fourth hop, nobody remembers what conditions produced it.

A better citation habit

• State the benchmark name and setting alongside the number, not just the number itself.
• Note whether the result comes from the paper's own reported table or from an independent reproduction, since these can diverge.
• Avoid citing a number as representative of "the model's performance" in general when it reflects one specific evaluation condition.

This extra context is often just one clause, but it's the difference between a citation that can be checked and one that can't.

Citing a Survey or Blog Summary Instead of the Original Paper

Secondary sources, survey papers, technical blog posts, and social media threads summarizing new research, are a normal part of how people first encounter ML papers. The mistake is citing the summary as if it were the primary source, especially when the summary has simplified, reordered, or slightly misstated a claim from the original work.

This is especially common with widely shared technical explainer posts. A well-written summary can make a paper's finding sound more sweeping or more certain than the authors' own hedged language in the paper. If a citation traces back only to that summary, any distortion introduced there gets passed along as though it were the original claim.

The fix is straightforward: read the section of the primary paper being referenced before citing it, even if a summary is what led you there. If the primary paper is genuinely inaccessible or highly technical and you're citing a secondary explanation on purpose, say so explicitly rather than presenting it as a direct citation of the research itself.

Ignoring Retractions, Errata, and Author-Issued Corrections

Retractions and corrections are less common in ML than in some other fields, but they do happen, particularly around bugs discovered in evaluation code, data contamination between training and test sets, or errors in reported statistics. When a correction is issued, it's usually posted as an update to the arXiv listing, a note in a follow-up paper, or a comment thread on the venue where the paper was published. It almost never automatically propagates to everyone who already cited the original claim.

A citation written before a correction was published isn't wrong at the time it was made, but if it's left unchanged in a document that continues to circulate, it becomes a stale claim being presented as current. This matters most in reference material meant to stay accurate over time, such as documentation or long-lived blog content, rather than in a dated conference paper that reflects its moment of publication.

A periodic maintenance habit

• For any citation load-bearing enough to support a specific claim, revisit it periodically to check for updates, corrections, or retractions.
• When citing a paper with known data contamination concerns or a disputed result, note that context rather than presenting the number as settled.
• Prefer linking directly to the paper's official listing page over a cached PDF, since the listing page is more likely to reflect corrections.

None of these fixes require special tools or extensive extra research time. They mostly require treating an AI or ML citation the way it actually behaves: as a reference to something that can change, rather than a fixed fact frozen at the moment it was first written down.