PARAS MADAN
All writing

Latest in AI

Perplexity Decider 1.3 Locate: Extract Text Spans Without Breaking Offsets

The new extraction mode returns source spans rather than generated answers, but your application still has to preserve and validate the text.

Perplexity's Decider 1.3 adds locate, a question type for extracting matching text spans. It gives developers a way to highlight evidence inside an input rather than asking a chat model to reproduce it. The useful integration detail is where those spans point, especially when the text contains emoji.

The November 12 release positions locate for entity recognition, personal-information identification and extractive question answering. That makes it relevant to review interfaces: identify the delivery city in a support ticket, then show the operator exactly which words supplied that answer.

Start with one extraction question

The Decisions API documentation specifies type and instructions for locate; criteria is ignored. Send this illustrative JSON body to POST https://api.perplexity.ai/v1/decisions using your normal API authentication:

{
  "model": "pplx-decider-v1.3",
  "state": "๐Ÿšš Delivery to Pune is delayed.",
  "questions": {
    "destination": {
      "type": "locate",
      "instructions": "Find the delivery destination city."
    }
  }
}

This request has not been sent to the live API. It is a worked integration example, not evidence that the model finds the right city every time.

Locate requires string state and either pplx-decider-v1.3 or pplx-decider-flash-v1.3. Objects, arrays and images are unsupported. Requests containing locate allow at most 128 questions and cannot use web grounding. These incompatible combinations return HTTP 400.

Validate offsets against the exact submitted string

Each returned span contains text, start, end and score. Offsets count Unicode characters, with an exclusive end; higher scores indicate greater certainty. No match produces an empty span list.

For the example above, the intended substring Pune occupies positions 14 through 17, so its exclusive end is 18. This is a locally checked string calculation, not an invented model response. The following Python check verifies those boundaries:

state = "๐Ÿšš Delivery to Pune is delayed."
start, end = 14, 18  # Illustrative boundaries, not an API result
assert state[start:end] == "Pune"

The opening emoji makes this a useful regression case. The substring starts after 14 Unicode code points but after 15 UTF-16 code units. Passing the same numbers directly to JavaScript's ordinary string slicing therefore selects the wrong characters. For this example, slicing an array of code points preserves the intended result:

const state = "๐Ÿšš Delivery to Pune is delayed.";
const extracted = Array.from(state).slice(14, 18).join("");
console.assert(extracted === "Pune");

Keep the exact submitted text beside the result. If you trim whitespace, normalize Unicode or replace line endings before rendering, old offsets may point somewhere else. A document identifier alone is insufficient when the document can change between extraction and display.

A correct substring can still be the wrong answer

A boundary check establishes that the text exists where the response says it does. It does not establish that the text answers your question. A ticket could mention the customer's city, a warehouse and the delivery destination in one paragraph.

Build a small labeled evaluation set containing that ambiguity, multiple matching cities and no destination at all. Check both whether the expected span was found and whether extra spans were returned. Keep low-confidence or ambiguous cases available for review rather than silently turning a highlight into a database update.

The documentation reports locate training inputs up to 8K tokens and evaluation up to 32K. Longer inputs are accepted without measured span quality. For longer documents, evaluate representative sections before relying on extraction across the whole file.

Extraction is not redaction. Even if every returned span is valid, an omitted span could leave sensitive text behind. A highlighting assistant and an automatic privacy filter need different acceptance criteria. Start with the former unless you have evidence that the latter meets your requirements.

The practical advantage of locate is a link back to the source. Preserve that link through storage, validation and display, rather than discarding it after converting the answer into a label.

Iโ€™m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn API capabilities and implementation trade-offs into clear examples developers can use.

Book a 30-minute call