Perplexity Open-Sources Decider v1.3 for Classification, Reranking, and Span Extraction

Summary:Perplexity has released two Apache 2.0 open-weight models for structured decision-making: Decider v1.3, built on a roughly 26B-parameter backbone, and Decider Flash v1.3, distilled from the larger model into a 4B backbone. Rather than generating text token by token, the models score answer options against an input state and natural-language questions. Supported tasks include binary decisions, multiple-choice questions with up to 255 options, ordinal scoring, and reranking. Version 1.3 also intr

---

Core release: turning a generative backbone into a probabilistic decision model

Perplexity released pplx-decider-v1.3 and pplx-decider-flash-v1.3 under the Apache 2.0 license. Instead of producing free-form text token by token, these models read an input state and one or more natural-language questions, then return probability distributions over candidate answers.

That interface makes the models useful as composable decision components for classification, moderation, reranking, routing, and extraction. The key operational benefit is not a new decoding strategy, but the ability to inspect confidence, apply thresholds, and route uncertain cases to manual review.

Model configurations and deployment footprint

pplx-decider-v1.3 has approximately 26B parameters and requires about 49 GiB for its BF16 weights. Flash uses a roughly 4B backbone and requires about 8.5 GiB in BF16. The smaller model was distilled from the larger teacher with a KL objective over output distributions rather than hard labels alone.

The resulting deployment split is straightforward:

• Decider v1.3 targets the highest classification and extraction quality, local data control, and multi-GPU environments.
• Decider Flash v1.3 targets high-throughput or cost-sensitive workloads with a much smaller memory footprint.
• Hosted access through the Perplexity API and OpenRouter avoids operating a nonstandard inference stack.

Parameter count alone does not determine serving cost, however. Bidirectional attention, 30K-token contexts, image processing, and the extra locate path can materially change latency and memory use.

Decision interfaces

The models support four principal question types:

1. Yes/No for binary decisions such as moderation, intent detection, and policy routing.
2. Multiple Choice with up to 255 options per request.
3. Ordered Scores for scoring or reranking candidates.
4. Locate for returning verbatim spans and character offsets.

Several questions can share one state. By default, each question runs in its own sequence, providing stronger isolation. An isolated mode reads the state only once and reduces compute for multi-question requests, but answers can shift slightly because the question set and attention distribution change. Default isolation is preferable for audit-sensitive workloads; the cheaper mode is more suitable for cost-sensitive pipelines.

Perplexity reports 83.99 nDCG@10 across 72 retrieval tasks for Decider v1.3, 1.81 points above Qwen3-Reranker-8B. The exact dataset splits, prompt templates, concurrency settings, and confidence intervals were not fully disclosed in the supplied material, so teams should reproduce the comparison on their own retrieval workloads.

Architecture: bidirectional attention changes the inference contract

Decider converts the backbone's full-attention layers to bidirectional attention. Each question can then observe the complete state and all question tokens without a causal mask. This is useful for jointly modeling several related decisions.

The engineering consequence is important: a conventional causal inference path does not reproduce the official outputs, and the Perplexity pplx_decider package is required. The serving profile also differs from that of a standard autoregressive model, making parameter count an unreliable proxy for throughput. Training sequences reached approximately 30K tokens, so long-document deployments still need to account for prefill time, KV-cache memory, and batching behavior.

Locate v1.3: extraction and classification on one backbone

locate is the main addition in v1.3. A caller can provide a field label such as “person” or “email address,” or a natural-language instruction such as “the person who signed the contract.” The model returns verbatim spans, character start and end offsets, and confidence scores, or an empty list when nothing matches.

The mode targets named-entity recognition, PII detection, extractive QA, and structured field extraction. A request can contain up to 128 locate questions. Compared with generative extraction, offsets and exact source spans provide better auditability and can directly support highlighting, masking, and field linking.

Locate currently supports text but not images. It is implemented through a separate LoRA adapter and span head. Perplexity left them unmerged because merging regressed classification performance. Consequently, mixed classify-and-locate requests require extra forward passes and should not inherit the latency profile of classification-only traffic.

Reported performance and its limits

Perplexity reports:

• Multilingual classification accuracy across eight languages: 88.16% for Decider v1.3 and 86.50% for Flash, versus 85.41% for TypeSafe Jev 1.14.
• 83.99 nDCG@10 across 72 retrieval tasks for the larger model.
• Average performance across 17 out-of-domain NER, PII, extractive-QA, and structured-extraction tasks: 69.0 for Decider v1.3 and 63.6 for Flash. Liquid d1, Cloudflare Clairic, and GLiNER large v2.5 are listed at 43.3, 41.5, and 33.6.
• Artificial Analysis Decision Index scores of approximately 70 and 64, with listed costs near $68 and $34 per million tasks.

These figures support a claim of competitive performance on the evaluated tasks, but they do not amount to independent validation. The supplied information states that most evaluations were performed by Perplexity. Task selection, prompt design, metric aggregation, preprocessing, and failure-handling policies could materially affect the comparisons.

Calibration and deployment guidance

The developers explicitly advise calibrating the returned probabilities on the user's own data before setting operational thresholds. A raw score is not automatically the probability that the answer is correct; distribution shift, question wording, candidate construction, and calibration method all matter.

A production pipeline should:

1. Separate calibration data from an untouched test set. Do not fit thresholds and report accuracy on the same examples.
2. Compare default isolated execution with isolated mode, measuring answer stability, latency, and cost rather than assuming the cheaper mode is equivalent.
3. Validate locate outputs for legal character offsets, exact source consistency, duplicate spans, and overlaps.
4. Benchmark classification and extraction separately, accounting for the additional adapter and span-head computation in mixed requests.
5. Evaluate extraction with exact match, span F1, and character-offset error instead of relying on one aggregate score.
6. Use conservative thresholds and human review for high-impact decisions, while monitoring drift, abstention rates, and calibration across languages and domains.

Practical scope

Decider v1.3's main contribution is an open-weight, probability-oriented interface that combines multiple decision tasks and can run locally. It does not eliminate core model-engineering constraints: long contexts raise resource requirements, bidirectional attention requires a dedicated inference package, locate and classification cannot yet be fully merged, and probabilities still require domain calibration. For simple binary classification, a smaller model may be sufficient; for cross-document reasoning, complex reranking, or multimodal decisions, teams should measure the incremental benefit against specialized systems before adopting Decider as a default.

---

Source: Reddit r/LocalLLaMA (2026-11-13)

— END —

Tags: #Perplexity Follow #Decider v1.3 Follow #Open Weights Follow #Probabilistic Classification Follow #Span Extraction Follow