Perplexity Photon Speeds Retrieval but Does Not Explain Citations

Perplexity has replaced its retrieval and ranking engine with a system called Photon. The September 24 engineering account reports a much faster internal search stage and a new fast preset for the Search API. For publishers, the useful distinction is where this system sits: it selects candidate pages before an answer is written. A faster selector does not, by itself, tell us which publisher will be cited.

That boundary is easy to miss when a search product reports latency, answer quality and citations in the same announcement. Perplexity’s technical account of Photon describes the retrieval and ranking machinery; it does not publish a before-and-after distribution of cited publisher domains, referral clicks or inclusion rates.

The step Photon actually changes

Imagine a question that could be answered by a product page, an independent review and a technical document. An index has to find plausible pages, rank a smaller set, and pass information about them to the answer system. That system may read more content, compose a response and decide which links to display. Photon is in the candidate selection and ranking stage. It is not a public rulebook for the later citation decision.

Perplexity says its previous adapted engine struggled as the index and per-document information grew. Data outside available RAM caused slow disk reads, and index merging could worsen the slowest requests. Photon uses compact posting lists for candidate retrieval and separate per-document records for ranking details. It checks a batch of needed records in cache, then overlaps disk reads for misses. Index construction happens on different nodes from live query serving, with a new serving group warmed before it receives traffic.

That design matters because a search service has a limited time budget to consider documents. It may have to choose a bounded candidate set rather than exhaustively inspect every plausible page. The architecture makes the selection stage more efficient in Perplexity’s system. It does not establish that the service now indexes more sites, favors longer pages, prefers a particular schema field, or cites more sources per answer.

Three performance numbers, three different claims

Perplexity reports that the p99 latency of its internal retrieval-and-ranking stage fell from about 800 milliseconds to 65 milliseconds after migration. The company also says its new Search API fast preset returned a single search call in 160 milliseconds at the median and 230 milliseconds at the 95th percentile. Those are not the same timer: one measures an internal stage, the other an API call. Neither measures how long a reader waits for a complete answer with citations.

The company evaluated the fast preset on six agent benchmarks spanning 3,554 selected tasks. Its task-weighted aggregate score was 64.3% at an estimated $59.73 in total model-plus-search cost, compared with 64.0% at $187.60 for the default Perplexity preset. The roughly 68% cost reduction is a vendor-run result for that task set and cost model, not a published independent quality audit. Perplexity also cautions that provider-reported search-call latency charts do not share a controlled measurement setup.

The strongest conclusion is therefore operational: Perplexity says it can serve this search stage with much lower tail latency while retaining comparable aggregate benchmark performance under its chosen evaluation. The result does not justify a publisher claim such as “Photon increased our chance of citation by 68%.” Cost per task, retrieval latency and publisher citation share have different numerators and denominators.

What a publisher can test without guessing a ranking factor

Keep an existing panel of exact questions and record the Perplexity surface, account state, locale, date, full answer, visible cited URLs and resolved destinations. Repeat each question. Compare the same panel before and after a documented change, and label any gap in the capture history. If only a post-launch sample exists, call it a baseline, not a Photon effect.

For a cited page, inspect whether the link supports the claim beside it and whether a measurable visit followed. For an uncited page, do not assume Photon rejected it. The page might not have been crawled, might have lost candidate selection, might have been read but not used, or might have informed an answer without a displayed link. Our citation-failure map separates those possibilities. Perplexity’s Q2D-Web retrieval benchmark addresses an earlier candidate-search question, not this release’s publisher traffic outcome.

A useful change log would keep four columns: source eligibility, candidate or answer evidence when observable, displayed citation, and referral. Most publishers cannot see Perplexity’s internal candidate list. Mark that field unknown rather than inferring it from the final answer. If citation mix changes, investigate alongside crawl access, question wording, model or interface changes and normal answer variation before assigning a cause.

The publisher implication is a boundary, not a tactic

Photon is evidence that Perplexity treats retrieval infrastructure as a core part of AI search. It is not evidence of a new public optimization requirement. A publisher’s durable work remains making important pages accessible, precise, current and independently useful, then measuring whether they are discovered, cited and visited as separate outcomes. The next meaningful test is a repeated citation-and-referral panel, not a sitewide rewrite to match an undocumented ranking system.

Fast Search: current price and client-library limits

Perplexity’s Fast Search documentation, checked October 10, lists search_type: "fast" at $1 per 1,000 successful Search API POST /search requests, versus $5 for default web. This corrects the $2.50 comparison previously in this article. Standalone Search API billing has no additional token charge; model costs elsewhere in an agent workflow remain separate.

Fast Search accepts one to twenty results and uses the standard response shape. Perplexity recommends standard web search for rare, difficult or ambiguous questions. The search type is not the Agent API’s similarly named fast preset.

The docs flag Python library versions 0.43.4 and 0.43.5: pass extra_body={"search_type": "fast"}, because the direct argument fails validation. The TypeScript 0.38.5 example temporarily casts the value because its types do not include fast. These are documented version-specific workarounds, not client tests performed here; recheck them when upgrading.

A cost comparison with a fallback lane

At 100,000 successful requests, the listed standalone retrieval charges would be $100 for fast and $500 for standard, an illustrative $400 difference before other workflow costs. A mixed workload with 80,000 fast requests and 20,000 standard requests would cost $80 + $100 = $180. Neither calculation proves equal answer quality or a particular latency improvement.

Evaluate routine and ambiguous queries separately rather than averaging them into one win. Keep a fallback for missing, stale or unsupported results, and measure the fraction needing another search. A cheap first request loses value when repeated retrieval and reviewer work erase the difference. The benchmark completeness explainer clarifies what a quality score actually counts. For model charges alongside retrieval, see the Haiku batching example.