Inspiration

Scientific progress is achieved by building on the discoveries and work of those scientists that precede us. Citations are an important part of how research papers build on the past knowledge and create new knowledge from it. Yet most people don't take the time to actually check whether the citations support the claims being made or if it is misinformation. This is likely because readers blindly trust the paper and/or find it tedious work.

Checking a citation involves looking up the cited paper, reading it and locating the relevant passages and judging the claim against the evidence. This is okay for a few citations, but requires a lot of time and effort for typical papers that have fifty to a hundred citations.

We built this tool to automate the process, presenting the information in an easy-to-read report, making it easy to assess the validity of each citation.

What it does

  • The app ingests a paper (either by providing an arXiv id/link or uploading a PDF) and parses the paper for each of its citing sentences and the bibliography.
  • Each referred paper in the bibliography is found by searching arXiv, OpenAlex, Crossref and Europe PMC.
  • The claims made in the ingested paper are extracted.
  • The evidence (relevant passages) from the referred papers is retrieved. -The claims are judged against the evidence and a verdict (supported, overstated, contradicted, not found, or could not be verified) is given.
  • A neat report is generated, making it easy to navigate through the checked paper and look at the verdicts given to the citations and also why a verdict was made. If the verdict of a citation is overstated, contradicted or not found, it is marked 'Needs human check'.

Along with a verdict, in some cases, there are failure-mode tags that explain the type of problem (namely number_drift, scope_inflation, hypothesis_as_finding, secondary_citation, retracted_source, off_topic_citation, correlation_as_causation, significance_inflation and corrected_source).

The user can choose between a quick check and a full check (where the former only checks the first 20 citing sentences).

There is a demo paper (Chain-of-Thought Prompting) where errors were planted that opens without taking time to load and shows how many of those planted errors were caught, giving the user an idea of how well the app performs.

How we built it

We use Python and FastAPI for the backend, while we built the UI with HTML, CSS and JavaScript.

  • When the input paper is from arXiv, we use the LaTeX source since the citation commands and compiled bibliography precisely match each citation to its reference.
  • For PDFs as the input, a layout parser, built on PyMuPDF, finds headings, paragraphs, page breaks, drops tables, sidebars and footnotes, and reads seven bibliography styles.
  • To find the cited papers from the bibliography, the app looks through arXiv, OpenAlex, CrossRef and Europe PMC.
  • The next parts of the pipeline use models from Token Factory, all sitting behind one OpenAI-compatible endpoint, each assigned to a specific task
    • Each citing sentence, along with neighbouring sentences and the citing paper's title, goes to the extraction model (Nemotron 3 Nano), which writes what the sentence attributes to the cited work. It works with one call per citing sentence and reasoning off.
    • To retrieve evidence, each cited paper is split into chunks (around 400 tokens with 80 tokens overlapping). Each chunk is embedded, as is the corresponding claim from the citing paper, and the 5 chunks closest to the claim (in terms of cosine similarity) form a (claim, reference) pair, all with the help of the Qwen3-Embedding model.
    • Each (claim, reference) pair is fed into a judging model (Nemotron 3 Super) which returns a verdict label (supported, overstated, not_found, contradicted or unverifiable), a confidence score, an explanation for the verdict and a failure-mode tag. The model works with one call per pair and reasoning on.
    • If a verdict has a low confidence score, is an accusation or if no quote can be verified, Nemotron 3 Ultra is brought in for a second opinion. It uses the whole cited paper to make its judgment. It works with reasoning on.

How well it works

We also set up a procedure for evaluating the app.

  • We planted errors (of four kinds: changed numbers, inflated scope, removed hedges and swapped citations) into real papers, and then documented how many of the errors were picked up by the tool. This was how we measured recall.
  • Flags on the unaltered citations were checked by hand against the cited text to see if they were genuine or false alarms. This was how we measured precision.
  • We checked the demo paper(Chain-of-Thought Prompting) once before calibrating the pipeline and checked this paper again. Recall rose from 7/10 to 9/10 errors caught and precision rose from 32% to 63%.
  • Round 1. Following that, to attain an honest evaluation, we tested the pipeline on 6 held-out papers (those that the checker had not seen before), drawn randomly from OpenAlex, with 44 planted errors in total. Recall was 80% and precision was 54%.
  • Round 2. After making some changes, we tested it on 12 new papers, with 103 planted errors. Compared with the old version, the recall shifted from 84% to 86% and precision from 61% to 60%.
  • Four detector rules were added, which, on the previously tested papers, improved recall to 93% and precision to 63%. A round 3, i.e., more held-out papers, is necessary to get an honest evaluation of the new version of the pipeline. Unfortunately, carrying out those tests is very expensive.

Challenges we ran into

  • Parsing clean text out of the papers was one of the first problems. PDFs, like a PLOS ONE paper for example, would come out jumbled: references were mistaken for body text, sidebars and table cells passed as paragraphs, and words were broken at line ends. Exponents would also lose their superscripts (10^-7 would be 10-7) and ranges (1800-2000K) would be counted as two numbers (causing false number-drift flags). In LaTeX papers, anything that wasn't recognized was just dropped. The parser had to be rebuilt around these cases.
  • At times, the wrong cited paper would be looked up. Generic titles would match the wrong paper, DOIs (Digital Object Identifier) split across two lines would resolve to the wrong paper, database records would link the wrong paper, preprints would have different numbers from the journal version cited by the authors. Adding consistency checks helped deal with these problems.
  • Many of the referenced papers are locked behind paywalls or block automated downloads, more for some fields than others. Adding Europe PMC as one of the sources for our references doubled our access to biomedical papers.
  • Search APIs (on their free versions) like OpenAlex, Crossref and arXiv either throttled or refused downloads for papers.
  • Evident in our evaluation, false alarms were a big problem, more so than missing errors. The problem was that the judge read citations too literally. We thought a leniency rule would help, but the tricky part with that was that there was a trade-off between recall and precision. Some of the planned changes we have for the next version of the pipeline hopefully improve both metrics.

Accomplishments that we're proud of

  • In round 2 of our held-out evaluation (12 papers), the checker found 17 genuine citation issues in the original unedited texts. Its ability to find problems nobody planted proves that it can actually be a useful tool.
  • In the same 12 papers, with a total of 103 planted errors, the checker caught 93% of them, with 91% of them the right label. And precision after human review was 63%.
  • Each verdict shows the evidence that backs it and cannot invent support. If a verdict is 'overstated', 'contradicted' or 'not found', it needs a word-for-word quote from the cited papers and checked by code. Verdicts whose quotes can't be found have their confidence halved and sent to Ultra for a second opinion.
  • Our own PDF parser, which we built with PyMuPDF, processes citations from a PDF just as accurately as LaTeX sources on the papers we compared. It works for papers across fields and formats: machine learning, computer vision, quantum computing, astrophysics, medicine, biology and psychology. It can also handle seven bibliography styles and citations in the form of numbers, ranges, superscripts or author-years.
  • When an issue is found, the verdict isn't just 'not supported' alone; it explains what kind of problem it is by adding failure-mode tags. Each tag requires rule-based evidence that is checked by code, not a call to a model.
  • The performance of the checker was measured honestly. We planted (four kinds of) errors into real papers only for citations that were already marked supported, so every catch was a real catch. The test papers were selected blindly (with rules for eligibility) from a seeded random sample. No tuning of the pipeline was done between planting and scoring and every flag was reviewed by hand, ensuring a true assessment. All of the above make our evaluation reproducible.

What we learned

  • Regarding the judge's prompt, we expected simple instructions (like "always quote the cited text" and "don't accuse background citations") to be followed, and they were in most cases. But with hundreds of verdicts per paper, there were a significant number of lapses where those instructions weren't followed. What fixed this was having important instructions or rules enforced through code instead of the prompt alone. We learned that while LLMs are good at reading and judging, it is necessary to place deterministic code in some places to guarantee accuracy, making the whole system more trustworthy.
  • We thought the models misjudging would be the cause of most mistakes, when in fact the worst verdicts were due to bad parsing of the text fed to the models. Adding checks (e.g., making sure years in a preprint and published version are consistent, rejoining broken DOIs and ensuring relevant LaTeX symbols aren't dropped) improved the pipeline's performance. We realised that we should be looking at all steps in the pipeline, instead of just the judging stage.
  • Regarding the evaluation, in the beginning, we saw that fixing the issues found in the previous round and then testing on new papers yielded better numbers (recall from 80% to 86% and precision from 54% to 60%), indicating that the fixes worked. But that comparison was between the old pipeline on old papers and the new pipeline on new papers. When we tested the old pipeline on the new papers, we saw that it scored the same (84% recall and 61% precision). The apparent improvement was because the new papers were easier. This taught us the importance of testing on a held-out set, and that comparing versions on the same papers shows us the real effects of the fixes made.

What's next for Citation-Checker

  • The next big fix is lowering false alarms. Round 2 showed us where most false alarms came from. So far, we've identified three types of issues and their fixes:
    • Some papers take a dataset from a cited paper and compute something new from it, like an average, for example. So when our judge searches the cited paper for the average and doesn't find it, it flags the citation. Fixing this involves recognising derived values and checking the cited paper for the underlying data, not the final figure.
    • The next issue shows up when the author makes a comparison to something in the cited paper. For example, “Our method is faster than [12]”. This statement depends on the citing paper's experiments. Paper [12] has to describe the method being compared against, not the comparison itself, which is what the judge sometimes expects. So the fix is for the claim extraction stage to separate the two parts.
    • Joint citations raise another issue. For example, "Earlier work found X and Y [4, 7]” could be split between works, such that [4] supports X and [7] supports Y. At the moment, each work is judged against the whole sentence, so it looks like each work supports half the claim. Judging the works together or giving each work the part it was cited for would fix this.
  • Round 3 is necessary because the changes made after round 2 need to be tested on a held-out set. This includes the detector rules and the false-alarm fixes (from above). Without this new round, we can't honestly report how good the latest version of this pipeline is. This round involves fresh papers for testing and differently worded planted errors. The old versions of the pipeline will also be tested on this set, so we can examine the improvement. The reason we haven't done this round of evaluation is that testing all these papers uses a lot of tokens, making it very expensive.
  • At the moment, as far as we know, Token Factory doesn't offer fine-tuning for Nemotron models. When it does, the checker could use it well. At the moment, Ultra produces reliable verdicts, and each evaluation round adds human labels. With 50-100 labelled papers (which amounts to around 3000-8000 claim-reference pairs), a Nano model could be trained to match those verdicts. If the distilled judge works well enough to make Super and Ultra redundant, the full check would cost less than the current $1.16.
  • Furthermore, the checker could learn from reviewers. A user could mark each flag as genuine or a false alarm as they go through the report. This labelled data can be used to train the distilled judge further and be used in an evaluation round.
  • The current checker leaves out a lot of information in a paper.
    • Scanned PDFs are refused as there's no text layer to extract. Nemotron Nano Omni could be used to read such pages.
    • Figures and tables in the ingested paper aren't parsed, so citations in captions or table notes aren't checked.
    • Figures in cited papers aren't read, so information in a plot cannot be used as evidence, making this another source of false alarms.
  • So far, each paper evaluated was in English. The Nemotron models and Qwen3-Embedding are multilingual, so we could extend the checker to other languages.
  • At the moment, the checker has no access to papers behind a paywall. Many users would have institutional access to those papers. So after one run of the checker, the report can include a list of inaccessible papers. The user can then upload PDFs of whichever of those papers they can get, and then rerun the pipeline with increased coverage.

Built With

Share this project:

Updates

Submission history