🔍 Beginner ~10 min Slow · 60d

Search With AI Without Getting Fabricated Citations

Perplexity's own docs warn that model-generated URLs can be hallucinated. A three-check routine for catching a fake citation before you cite it.

The AI Dude · Published July 31, 2026 · Verified July 31, 2026

Assumes you've done: Frame a Question a Machine Can Help With. Advisory, not a gate — this page stands on its own.

The clearest warning about fabricated citations is published by a company that sells cited answers. From Perplexity's own developer documentation:

"Never ask the model to generate source URLs. Always use the search_results output from the API response. Model-generated URLs can be hallucinated."

That sentence contains the entire problem. A language model can produce a citation-shaped string at any time, from anywhere, and a real citation and an invented one are visually identical. Detection is a process, not a glance.

A citation number is a pointer, and pointers can dangle

Understanding how a grounded answer is assembled tells you where it can break. In Perplexity's API, the sources arrive separately from the prose. Search results come through response.reasoning.search_results, each carrying an id, title, url, snippet and date. The answer text then contains markers, described in the docs as "numbered markers like [1], [2], mapping to the search result id field."

So a citation in a system like this is a number that indexes a list. The docs flag the obvious consequence in a second warning, and this one is about your own code rather than the model:

"Always collect the results from every event or item. If you keep only the first batch, most [N] references in the text won't resolve and citations will look hallucinated."

Read that phrasing carefully. Citations "will look hallucinated." There is a class of broken citation that is not a model fabrication at all, just an incomplete list on the receiving end. Which means the surface symptom, a reference that does not resolve, has at least two causes and tells you nothing about which one you hit.

The practical rule for anyone reading output rather than writing code: a bracketed number is a claim about a list you cannot see. Treat it as unverified until you have clicked it.

Grounded describes the plumbing, not the paper

NotebookLM takes the strictest possible position on this, and Google's help pages state it flatly: "Chat responses in Gemini Notebook only use data from your sources," and the tool "answers questions based on the information provided in your uploaded sources. If the answer isn't in the source material, it won't provide a response."

The citation mechanism matches. It "uses direct quotes, text, and images straight from your sources as citations," you "can hover over any citation to get the full quoted text right away," and selecting one navigates to the quote's location in context. That is a genuinely good verification affordance, better than a footnote list, because checking costs one hover.

Now the exception, which is documented in the same help centre and easy to skim past: "If your source content is too short, Gemini Notebook references the entire document without a cited individual text from your source."

That is a citation with no quote behind it. It points at a document rather than a sentence, and it is the one kind of reference in this system you cannot spot-check by hovering. Short sources, a pasted note, a one-paragraph abstract, an email, produce exactly this. If a claim matters and its citation opens a whole document instead of a highlighted line, that claim has not been checked.

The larger caveat applies to every grounded system. Constraining an answer to your sources guarantees provenance, not correctness. Fifty documents that are all wrong produce a perfectly cited wrong answer.

Elicit's limitations page says more than its reliability page

Academic tools shift the failure mode rather than removing it. Elicit has two help articles on this, and they read very differently.

The reliability article is reassuring and lists real engineering: the information is "extracted directly from papers or generated based on research papers," the source is highlighted "within the relevant papers," and the mitigation stack includes "process supervision, prompt engineering, ensembling multiple models, double-checking our results with custom models and internal evaluations." What that page does not do is publish a hallucination rate, and it does not claim the problem is solved.

The limitations article is the one to plan around. Four lines from it:

  • "the models aren't explicitly trained to be faithful to a body of text by default"
  • "in some cases Elicit can miss the nuance of a paper or misunderstand what a number refers to"
  • "Elicit does not yet know how to evaluate whether one paper is more trustworthy than another"
  • "Elicit is only as good as the papers underlying it"

Put those two pages next to each other and the honest reading is that faithfulness is engineered on top of models that are not faithful by default. That is not a criticism of Elicit, which is more forthcoming here than most vendors. It is a description of how every one of these tools works.

It also tells you which error to hunt for. With a corpus-grounded tool, an invented paper is unlikely. The likely error is a real paper cited for a claim it does not support, or a number pulled from the wrong column. Those pass every quick check. The link opens, the title matches, the authors exist.

The identifier you would verify with is sometimes a paid field

Consensus searches "over 200 million peer-reviewed academic research papers," and its integration docs list exactly what comes back per result: "title, authors, abstract, journal, year, citation_count, and url." Then the tier note: "Pro plans and above add study_type and takeaway for each paper. Enterprise includes doi."

The DOI, the identifier designed for exactly this job, sits behind the top tier on that surface. Below it you verify by URL and title, which works but adds a lookup step and fails silently on retitled preprints and duplicate records. Worth knowing before you build a workflow that assumes a DOI will be there.

Three checks, and only the third one is expensive

Crossref's REST API needs no key and turns citation checking into one request. The base is https://api.crossref.org/ and the single-record endpoint is /works/{doi}.

curl "https://api.crossref.org/works/10.1128/mbio.01735-25?mailto=you@example.org"

If a citation arrives without a DOI, search the metadata instead. The /works endpoint accepts query.bibliographic for a full reference string and query.author for an author name:

curl "https://api.crossref.org/works?query.bibliographic=Attention+is+all+you+need&rows=3&mailto=you@example.org"

Crossref asks you to include a contact address to reach its polite pool, documented as appending ?rows=0&mailto=yourmail@company.org to requests. Add it. It costs nothing and keeps you out of the anonymous queue.

Run three checks in order, and stop early only if one fails:

  1. Does the identifier resolve? A DOI that returns nothing from Crossref is either fabricated or mistyped. Seconds.
  2. Does the returned metadata match the citation as written? Title, first author, year, journal. A real DOI attached to the wrong title is the signature of a model stitching two records together. Seconds.
  3. Does the source actually say the thing? Open it and find the sentence, table or figure the claim came from. Minutes.

Checks one and two are cheap and catch the crude failures. Check three is the only one that catches a real paper attached to a claim it does not make, which is the error that survives every automated defence and the one most likely to end up in something you publish. Budget for it on the claims that carry weight, and skip it on background.

Instructions that force a model to show its misses

If you are prompting a search-enabled model yourself, Perplexity's prompt guide publishes instruction text that makes bad citations easier to see. Three lines are worth copying:

"Your response must include at least 1 citation. Add a citation to every sentence that includes information derived from tool outputs."

"Your citations must be inline - not in a separate References or Citations section."

"If searches do not return relevant results after trying alternative phrasings, say so explicitly rather than providing speculative information."

The per-sentence rule is the important one, and the reason is diagnostic rather than stylistic. A paragraph followed by five real references looks well sourced even when one sentence in the middle came from the model's own memory. Force a citation onto every sourced sentence and the unsourced one stands out because nothing is attached to it. The guide also specifies the format, brackets like [type:index] with each source in its own pair, as in [web:1][web:2][web:3].

One closing note on how much any vendor knows about its own failure modes. Elicit ends its limitations page with a line most companies would delete: "This section is really way too short...this is not a comprehensive list of possible limitations." Take that at face value, and assume the same of every tool here that has not written it down.

hallucinated citationsPerplexityElicitCrossrefsource verification
Changelog (1)
  • July 31, 2026 — First published.