When you ask an AI assistant to pull a figure from a dense PDF, getting the right number is only half the job. The tool also has to show its work—pointing you to the exact entity, reporting period, and unit that back up the claim.
A document assistant may return an accurate figure alongside a reassuring page citation. But what happens when you actually open that page? Does the highlighted table cell genuinely prove the answer, or is it just pointing somewhere roughly in the neighborhood?
Evaluating the citation is a completely separate test from evaluating the answer itself. That distinction matters whenever a team relies on AI to draft comparisons, back up sales claims, or prepare financial analysis that a second person has to sign off on. A colleague should be able to click a citation and verify the claim immediately, without having to re-read the entire document from scratch.
Look at where the citation fails, not just how neat the box is
The CiteVQA benchmark tests this exact problem by grading models on both their answers and their ability to draw bounding boxes around the supporting evidence inside supplied PDFs. The dataset spans 1,897 questions across 711 English and Chinese documents, pulling from text, tables, images, and equations.
The standout takeaway isn't the overall leaderboard score, but how the models fail. When looking specifically at the pool of answers that failed the benchmark's combined answer-and-evidence check, pointing to the wrong page or the wrong document element entirely accounted for 34.8% to 51.7% of those failures across different models. By contrast, messy bounding boxes—where the model found the right spot but drew the box slightly too large or off-center—accounted for just 1% to 5% of the failed cases. (Keep in mind that these percentages are shares of the failed samples, not shares of all questions asked.)
That breakdown should change how you watch a vendor demo. A bounding box that is a little sloppy around the edges may still let a human reviewer verify the fact. A crisp, tightly drawn box around the wrong table cell is useless. The researchers break down these specific error rates in Section 5.1 of the paper.
Identical numbers aren't interchangeable evidence
Imagine a financial table where a company happens to report the exact same figure in two different years. If you ask for this year's number, an AI might give you the right value while highlighting last year's cell. Any automated check that merely looks for a matching string of digits will give that citation a passing grade, even though the time period is completely wrong.
A separate study on financial evidence verification probed this blind spot by deliberately swapping citations between table cells that held identical numbers while keeping the underlying math intact. Their verification system accepted some citations pointing to the wrong conceptual role and rejected some valid, equivalent alternatives. Because the researchers hand-picked and constructed these test cases, the study illustrates a specific vulnerability rather than how often it happens in the wild.
Still, the takeaway for anyone testing document tools is straightforward: a number stripped of its labels isn't evidence. To verify a table cell, you need its row header, column header, unit of measurement, reporting period, and any attached footnotes. A percentage separated from its denominator is just as dangerous as a revenue figure pulled from the wrong column.
Build a practical test suite from your own files
If you are evaluating a document assistant for your team, skip the generic benchmarks and build a small acceptance test using the actual files you work with every day. Write down the exact answers and the specific page regions you expect the tool to cite before you run a single prompt. Make sure to mix routine lookups with trickier edge cases—if your test is nothing but adversarial traps, you won't learn much about how the tool handles Tuesday morning busywork.
A solid starter kit only needs five types of prompts:
- A straightforward fact stated plainly in a single paragraph.
- A table lookup that only makes sense when combining a specific row label and column header.
- A comparison that forces the tool to pull figures across two different time periods or separate files.
- A claim that looks simple on the surface, but is heavily qualified by a footnote or exception.
- A question that the uploaded documents simply do not answer.
Grade every response on two separate tracks: did it get the answer right, and did the citation actually prove it? Check whether the link opens the right document version and page, highlights the right element, and keeps the surrounding context intact.
Pay close attention to that fifth prompt where the evidence is missing. A tool that plainly states it cannot find the answer in the provided text is doing its job. A tool that guesses a plausible answer and pins it to a vaguely related paragraph is just creating extra cleanup work for your reviewers.
This five-part check is just a practical buyer's exercise, not a formal scoring methodology from either paper. Its real value is giving you concrete, reproducible failure examples to bring back to the vendor.
Make sure you are testing the model, not the file parser
What you upload to an AI tool isn't necessarily what the underlying model actually sees. Under the hood, one pipeline might feed the model high-resolution page images, another might strip out raw text, and a third might use a hybrid parser. Fine print and complex table grids can easily survive one ingestion method and get mangled by another.
The authors of CiteVQA explicitly warn that their own model comparisons didn't use uniform visual input quality across every system—meaning you shouldn't treat their leaderboard as a definitive buyer's guide. When you run your own bake-off, log the exact source files you use alongside any resolution or parsing settings you can control. Otherwise, it is very easy to blame the language model for what is actually a document ingestion failure.
Finally, hand the tool's output to a colleague and ask them to verify the claims using nothing but the provided citations. If they still have to Ctrl+F their way through the PDF to be sure the answer is right, the tool hasn't actually delivered on the promise of traceability.
That leaves you with a simple purchasing criterion: does this software genuinely cut down the time it takes our team to get a verified answer from our own documents? If you track citation failures separately from answer accuracy, a lucky guess backed by the wrong table cell won't be able to hide inside a respectable average score.
