Perplexity Decider

Rilasciamo Decider v1.3 e Decider Flash v1.3, i successori dei nostri precedenti modelli decisionali: v1, v1.1, v1.2 e Flash v1.2.

Decider Flash v1.3 è un modello più piccolo distillato da Decider v1.3. Entrambi i modelli sono disponibili su Hugging Face con licenza Apache, tramite OpenRouter e tramite la Perplexity Decisions API.

Perplexity Decider si ispira a Jev, il System One Model di TypeSafe AI. Supporta la classificazione binaria e multiclasse con etichette ordinate o non ordinate, restituendo probabilità che le applicazioni possono usare per classificare, instradare, ordinare e valutare gli input.

Entrambi i modelli v1.3 migliorano prestazioni e robustezza su un'ampia gamma di attività testuali e visive grazie all'attenzione bidirezionale, a dati di addestramento più curati e a una ricetta di addestramento perfezionata. Introduciamo inoltre locate, una nuova funzionalità che evidenzia il contenuto selezionato nelle attività di riconoscimento delle entità nominate, identificazione delle informazioni personali e question answering estrattivo.

In questo articolo spieghiamo come addestriamo e valutiamo Decider e raccontiamo come lo usiamo internamente in Perplexity.

Che cos'è un modello decisionale?

Un modello decisionale è un classificatore generico. Gli fornisci un input e un insieme di domande, ciascuna con le sue possibili risposte. Per ogni domanda, restituisce una distribuzione di probabilità sulle risposte. Supporta 3 tipi di domande:

• Sì / No: decisioni binarie.
• Scelta multipla: etichette multiclasse personalizzate.
• Punteggio: livelli ordinati.

I modelli decisionali supportano un'ampia gamma di attività di classificazione e assegnazione di punteggi:

• Valutazione degli output: verifica di fedeltà, qualità e sicurezza.
• Instradamento: indirizzamento delle richieste verso modelli più piccoli o più grandi in base alla difficoltà.
• Moderazione e sicurezza: rilevamento di contenuti dannosi, phishing e prompt injection negli output degli strumenti.
• Filtraggio e tagging: organizzazione di grandi raccolte di contenuti.
• Recupero e reranking: assegnazione di punteggi ai risultati di ricerca in base alla pertinenza.

Molte di queste attività erano in precedenza gestite da modelli generativi come gli LLM, anche se non richiedono la generazione di testo libero. I modelli decisionali si collocano tra gli LLM e i classificatori specifici per attività. Restituiscono probabilità per più domande sullo stesso input in un unico forward pass, evitando la generazione della risposta token per token e condividendo il calcolo tra le domande. A differenza dei classificatori specifici per attività, possono gestire nuove attività tramite prompt in linguaggio naturale, una flessibilità appresa grazie all'addestramento su attività diverse in un formato condiviso di domanda e risposta.

Addestramento

Trasformare un LLM generativo in un modello decisionale

Costruiamo Decider adattando solidi backbone LLM generativi. Per spiegare l'adattamento, descriviamo innanzitutto come viene rappresentata una richiesta. Come illustrato di seguito, una richiesta è composta da un contesto condiviso (lo stato) e da un certo numero di domande. Lo stato verrà riutilizzato da tutte le domande.

Ad esempio, dati un documento e il suo riassunto, una singola richiesta può chiedere se il riassunto rappresenta fedelmente il documento e se è destinato a un pubblico esperto o generico. Dopo lo stato, ogni blocco di domanda contiene una domanda e le sue possibili risposte, a ciascuna delle quali è assegnato un token di etichetta predefinito come A, B o C. Un token speciale <|marker|> indica dove leggere la previsione del modello. In questa posizione, un livello di output lineare appreso (una decision head) mappa lo stato nascosto in punteggi per le opzioni di risposta della domanda, che vengono poi convertiti in probabilità.

Espandi

Inizializziamo il livello di output a partire dal modello base, che normalmente assegna un punteggio al token successivo sull'intero vocabolario, e manteniamo solo le righe corrispondenti ai token di opzione predefiniti come A, B o C. Questo livello ridotto viene poi addestrato per trasformare lo stato nascosto di <|marker|> in punteggi di risposta. Questo approccio copre tutte le domande di classificazione, perché possono essere tutte formulate come domande a scelta multipla.

Per l'addestramento prendiamo centinaia di dataset pubblici che coprono attività diverse (sentiment, inferenza in linguaggio naturale, rilevamento dell'intento, corrispondenza di entità, moderazione, fact checking, valutazioni, ecc.) e convertiamo ogni esempio nel formato unificato descritto sopra: uno stato, una o più domande, le relative opzioni e un target. Il target può essere la singola opzione corretta, se disponiamo di etichette gold, oppure una distribuzione di probabilità sulle opzioni.

Nella v1.3 introduciamo locate, che estrae testo dallo stato invece di selezionare tra opzioni predefinite. Una domanda locate descrive cosa trovare, usando un'etichetta breve come “posizione” oppure un'istruzione come “Estrai il nome della città in cui si trova il lavoro.” Il modello restituisce il testo esatto corrispondente presente nello stato, insieme alle posizioni dei caratteri di inizio e di fine. Se non individua corrispondenze, restituisce un elenco vuoto.

Espandi

Grazie allo stato condiviso, una singola richiesta può combinare domande di locate, classificazione e assegnazione di punteggi sullo stesso input. Ad esempio, può chiedere se un'offerta di lavoro richiede un'esperienza di livello senior ed estrarre le competenze richieste.

Attenzione bidirezionale: consentire al modello di leggere in entrambe le direzioni

I nostri modelli partono da solidi backbone generativi preaddestrati, la cui attenzione causale consente a ogni token di prestare attenzione solo a se stesso e ai token precedenti. I nostri studi di ablazione hanno mostrato che rendere bidirezionali i livelli a piena attenzione del backbone migliora le prestazioni, quindi adottiamo questo design per consentire a ogni token di incorporare il contesto dell'intero input.

L'attenzione bidirezionale introduce un'altra scelta progettuale: come dovrebbero interagire lo stato e le domande? Abbiamo considerato tre schemi di attenzione, con implicazioni diverse per prestazioni, stabilità delle risposte e riutilizzo della cache:

• Tutto vede tutto (v1.2): lo stato e tutte le domande vengono elaborati insieme con piena attenzione bidirezionale. Il calcolo sullo stato è condiviso, ma la risposta a una domanda può cambiare a seconda di cos'altro viene chiesto.
• Domande isolate (v1.3): lo stato presta attenzione a tutte le domande, mentre ogni domanda presta attenzione solo allo stato e ai propri token. Le domande possono comunque influenzarsi indirettamente tramite lo stato condiviso, ma i risultati sono più stabili.
• Completamente memorizzabile nella cache: lo stato presta attenzione solo a se stesso, mentre ogni domanda presta attenzione allo stato e ai propri token. Lo stato è indipendente dalle domande e riutilizzabile tra le richieste per sfruttare il prompt caching. Non lo usiamo per impostazione predefinita, perché permettere allo stato di vedere le domande è molto importante per diverse attività, ma un piccolo fine-tuning può far passare un modello a questa modalità.

Alla fine abbiamo scelto le domande isolate per le loro ottime prestazioni e la loro stabilità.

Espandi

Ricetta di addestramento

L'addestramento procede in tre fasi per entrambe le dimensioni del modello. Prima addestriamo il modello più grande, basato su Qwen3.8-27B, utilizzando la cross-entropy su grandi set di dati, poi lo distilliamo nel modello più piccolo Qwen3.5-4B.

La prima fase è l'addestramento generalista, in cui eseguiamo il fine-tuning completo del modello su corpora su larga scala. In questa fase accettiamo solo dati che aiutano il modello in modo trasversale e che non sono specifici di alcun benchmark; escludiamo quindi qualsiasi split di addestramento dei benchmark.

Dopo aver addestrato questo modello generalista, eseguiamo una seconda fase, più granulare, utilizzando LoRA. I dati usati in questa fase sono mirati a domini e attività specifici. Aggiungiamo dati nella seconda fase anziché nella prima se osserviamo guadagni limitati o alcune regressioni su altre attività. Usiamo LoRA per evitare di allontanarci troppo dal modello generalista e di rischiare di perdere prestazioni per adattarci a quei domini specifici. L'obiettivo è migliorare le prestazioni mantenendo la conoscenza generale del backbone. Usiamo inoltre un peso quando fondiamo il LoRA nel modello base, per controllare la deriva in modo più preciso e privilegiare le metriche sui dati esclusi dall'addestramento rispetto a qualsiasi guadagno nel dominio.

Infine, aggiungiamo un passaggio specifico per la visione. Analogamente alla seconda fase, il passaggio di visione è trattato come un ulteriore passaggio di specializzazione mirata, che usa un adapter LoRA reintegrato nel modello base con un peso. Alcune capacità visive possono andare a scapito delle prestazioni sul testo. Poiché osserviamo un utilizzo dei modelli molto maggiore sul testo, diamo priorità alle metriche testuali rispetto a quelle visive.

Per entrambe le fasi testuali utilizziamo la media dei pesi di tre esecuzioni, ciascuna con un diverso seed casuale. Abbiamo riscontrato che questo migliora le prestazioni e la robustezza del modello aggregato.

Una volta ottenuto il modello grande finale, applichiamo la stessa procedura di addestramento in tre fasi al modello più piccolo. In questo caso il modello grande funge da insegnante: la sua distribuzione di output prevista sostituisce le etichette gold e il modello più piccolo viene addestrato a minimizzare la divergenza KL tra le proprie previsioni e quelle dell'insegnante. Questo obiettivo di distillazione supera la cross-entropy sugli stessi dati di addestramento. Sebbene la cross-entropy ottenga risultati migliori sui benchmark con dati di addestramento dedicati, generalizza meno bene ai dati esclusi dall'addestramento. Ipotizziamo che la distillazione trasferisca meglio la distribuzione di output dell'insegnante, inclusa la sua confidenza sulle alternative non gold, mentre la cross-entropy favorisce l'overfitting sulla distribuzione di addestramento specifica del benchmark. Adottiamo quindi l'obiettivo di distillazione basato sulla KL.

Per mitigare la contaminazione tra addestramento e test, rimuoviamo tutti i campioni di addestramento che potrebbero sovrapporsi a una qualsiasi delle valutazioni che utilizziamo. Questo è importante perché alcuni set di dati di addestramento pubblici contengono ampie porzioni di alcuni set di dati di valutazione. Conduciamo inoltre ampi audit e rimozioni dei bias per assicurarci che i nostri miglioramenti siano affidabili e non dovuti semplicemente a bias appresi.

Aggiunta della capacità di estrarre informazioni

La funzionalità locate estrae dal testo informazioni come le entità nominate, senza modificare il modo in cui il modello risponde alle richieste ordinarie. A tal fine introduciamo una fase di addestramento aggiuntiva: aggiungiamo a Decider un nuovo token speciale, <|locate|>, una span head e un adapter LoRA.

Inizializziamo l'embedding di <|locate|> a partire da <|marker|>, appreso nelle fasi di addestramento precedenti. Addestriamo solo questo nuovo embedding, la span head e gli adapter LoRA, mantenendo congelati i pesi originali del backbone e la decision head. Ogni campo richiesto ottiene il proprio token <|locate|>.

La testa di span usa la rappresentazione di <|locate|> insieme alle rappresentazioni dei token di stato per assegnare un punteggio ai punti in cui iniziano e finiscono gli span corrispondenti e alle coppie inizio-fine che vanno insieme. Usa inoltre la rappresentazione del token <|locate|> per prevedere soglie specifiche per campo per questi punteggi. Gli span selezionati vengono restituiti come posizioni dei caratteri nel testo originale.

Addestriamo la testa di span con una loss InfoNCE adattata che spinge ogni span gold al di sopra della soglia e la soglia al di sopra di ogni altro span. La loss ha due termini: il primo spinge i punteggi degli span corretti al di sopra della soglia e degli span errati. Il secondo termine spinge la soglia al di sopra dei punteggi degli span errati. I campi senza risposta ricevono solo il secondo termine, che insegna al modello a restituire un elenco vuoto.

Addestriamo il modello su un mix di attività di estrazione di span, tra cui riconoscimento delle entità nominate, rilevamento di PII e question answering estrattivo. Variamo le descrizioni dei campi da etichette brevi a istruzioni dettagliate, in modo che il modello impari a seguire la richiesta anziché memorizzare un insieme fisso di etichette.

Locate insegna al modello un'attività strutturalmente diversa e vogliamo aggiungerla senza perdere ciò che il modello sa già fare bene. Fondere gli adapter locate nel backbone causa alcune regressioni sulle richieste di decisione. Per limitare questo effetto, stiamo conducendo indagini come l'uso di più dati di replay dalle fasi precedenti e di obiettivi ausiliari che mantengano gli output del modello sulle richieste di decisione vicini a quelli del modello originale. Tuttavia, riscontriamo che la fusione non è ancora priva di perdite, quindi manteniamo gli adapter separati e li attiviamo solo per le richieste locate.

Valutazione

Valutiamo Decider v1.3 e Decider Flash v1.3 su benchmark esterni tratti dall'Hugging Face Decision Index, dal ClaimBench di Vals AI e dall'Artificial Analysis Decision Index.

In queste valutazioni, i nostri modelli dimostrano ottime prestazioni. Anche se queste classifiche includono attività private, possono comunque essere manipolate tramite invii ripetuti e ottimizzazioni iterative basate sul feedback della classifica. Per integrare queste classifiche, valutiamo i modelli su una suite interna che combina attività di produzione private con valutazioni su dati esclusi dall'addestramento, tratti da set di dati pubblici non di benchmark. Queste valutazioni offrono un'ulteriore verifica della generalizzazione oltre i benchmark pubblici, aiutandoci a distinguere i miglioramenti più ampi dai guadagni specifici di suite di valutazione già note.

Internamente abbiamo creato una suite di oltre 200 attività che abbracciano vari domini e compiti come classificazione, assegnazione di punteggi, reranking ed estrazione di entità. Per valutare onestamente le prestazioni di Decider nel mondo reale, tutte le valutazioni vengono eseguite in modalità zero-shot, senza fine-tuning specifico per attività, così da ottenere un segnale chiaro su dove migliorare il modello.

Classificazione delle query

In Perplexity usiamo un sistema di classificazione multi-head per elaborare ogni query degli utenti. Ogni query passa prima attraverso un modello di embedding che funge da estrattore di feature. L'embedding risultante viene poi fornito a più head di classificazione separate, che includono classificatori sia binari sia multi-etichetta. Ad esempio, una head determina se la query di un utente debba attivare la ricerca web.

Su 63 attività di classificazione con riferimenti rietichettati in modo indipendente da un LLM di frontiera, Decider v1.3 raggiunge un'accuratezza media del 91,6%, superando i nostri classificatori di produzione di 6,54 punti percentuali. Anche Decider Flash v1.3 supera la baseline di produzione, mentre Decider v1.3 supera Jev 1.14.

Espandi

Classificazione specifica per dominio

Abbiamo assemblato una suite di valutazione specifica per dominio a partire da dataset pubblici per valutare le prestazioni di classificazione dei modelli decisionali in sette domini: verifica delle affermazioni (6 attività), sanità (7), sicurezza informatica (8), programmazione (16), pubblica amministrazione (7), diritto (9) e finanza (9).

Ad esempio, “valutare la complessità temporale di un programma Python” oppure “usare una relazione finanziaria annuale per stabilire se la liquidità non vincolata di un'azienda copre il capitale del debito in scadenza nei prossimi dodici mesi”. Decider v1.3 è in testa in tutti e sette i domini, superando Jev 1.14 fino a 12,9 punti percentuali nella finanza e di 9,3 punti nel diritto. Decider Flash v1.3 è dietro a Jev 1.14 in finanza, programmazione e diritto, e ottiene risultati simili negli altri domini.

Espandi

Recupero e reranking

La ricerca è al centro di Perplexity. Manteniamo un'ampia suite di attività di recupero per valutare le prestazioni di reranking dei nostri modelli. Per ogni attività, usiamo prima un pool di modelli di embedding per recuperare i primi 50 documenti candidati da ciascun corpus. Poi effettuiamo il reranking di questi candidati con Decider e ne confrontiamo le prestazioni con una solida baseline di reranking, Qwen3-Reranker-8B.

Valutiamo Decider in un'impostazione zero-shot e pointwise, usando il modello per assegnare direttamente e in modo indipendente un punteggio a ciascuna coppia query–documento e ordinare i documenti per pertinenza. Su 72 attività di recupero, Decider v1.3 raggiunge un nDCG@10 medio di 83,99, superando Qwen3-Reranker-8B di 1,81 punti e Jev 1.14 di 2,24 punti.

Sul benchmark BEIR, entrambi i modelli superano Qwen3-Reranker-8B rispettivamente di 8,78 e 7,05 punti di nDCG@10. Rispetto a Jev 1.14, Decider v1.3 ottiene 1,33 punti in più, mentre la versione Flash ottiene 0,4 punti in meno.

Espandi

Classificazione multilingue

Per valutare i modelli decisionali oltre l'inglese, abbiamo assemblato un benchmark di classificazione multilingue composto da 19 attività specifiche per lingua tratte da 8 dataset pubblici, con 46.484 esempi in otto lingue: tedesco, spagnolo, francese, italiano, russo, giapponese, coreano e cinese. Il benchmark copre rilevamento dell'intento, classificazione per argomento, analisi del sentiment, inferenza in linguaggio naturale, rilevamento di parafrasi, rilevamento di linguaggio offensivo e accettabilità grammaticale.

Riportiamo l'accuratezza media sulle attività di ciascuna lingua, ponderando ogni attività allo stesso modo. Decider v1.3 supera Jev 1.14 in tutte e otto le lingue e Decider Flash v1.3 in sei, con accuratezze medie per attività dell'88,16% per Decider v1.3 e dell'86,50% per Decider Flash v1.3, rispetto all'85,41% di Jev 1.14.

Espandi

NER, PII e QA estrattivo

Valutiamo la funzionalità locate su 17 attività fuori dominio che ne mettono alla prova la capacità di estrazione in vari domini, formati di input (testo, tabelle, documenti strutturati) e istruzioni (etichette brevi, domande e descrizioni dettagliate). I domini spaziano da Wikipedia agli articoli scientifici, dai report sulle minacce informatiche al supporto tecnico, dalle informative sulla privacy ai curriculum e ai contratti legali. Le richieste vanno da nomi di etichette brevi come “persona” o “indirizzo email”, passando per domande su una tabella o un ticket di supporto, fino a descrizioni dettagliate dei campi per l'estrazione strutturata, come le parti di un NDA o il totale di una fattura.

Valutiamo NER e PII utilizzando l'F1 a span esatto, che richiede che gli span previsti corrispondano esattamente ai confini di riferimento. Il QA estrattivo usa l'F1 a livello di carattere, assegnando un credito parziale per il testo della risposta sovrapposto, mentre l'estrazione strutturata usa l'accuratezza per campo, ovvero la proporzione di campi estratti correttamente. Per l'analisi dei CV, calcoliamo la media dei punteggi F1 a span esatto di NER e PII.

Confrontiamo i nostri modelli con modelli di estrazione generici di diverse dimensioni: GLiNER large v2.5 (0,5B), Liquid d1 (2B) e Clairic di Cloudflare (dimensione non divulgata). Decider v1.3 raggiunge un punteggio medio di 69,0 (usando la metrica principale di ciascuna attività) e Decider Flash v1.3 raggiunge 63,6, rispetto a 43,3 per Liquid d1, 41,5 per Clairic e 33,6 per GLiNER large v2.5. Entrambi i modelli Decider sono in testa in ogni categoria.

Espandi

Classificazione delle immagini

Decider supporta nativamente le attività visive fin dalla v1. Per valutarne le prestazioni oltre il testo, abbiamo assemblato una suite di benchmark di cinque attività con particolare attenzione alla classificazione di documenti, tra cui fatture, lettere e curriculum. La suite copre anche la classificazione di immagini satellitari, la classificazione di texture, la classificazione delle razze di animali domestici e il conteggio di animali.

Decider v1.3 raggiunge un'accuratezza media del 76,99% sulle cinque attività visive, superando Jev 1.14 di 1,47 punti percentuali. Decider Flash v1.3 raggiunge il 72,77%, dimostrando capacità di classificazione visiva in un modello più piccolo.

Espandi

Richieste decisionali reali

Abbiamo campionato un milione di richieste deduplicate e con PII mascherate, inviate alla Perplexity Decision API durante i suoi primi 18 giorni di disponibilità. Poiché ogni richiesta può contenere più domande sullo stesso stato, il campione comprende 2.318.887 domande individuali. Tutte le richieste sono state incluse con l'autorizzazione esplicita degli utenti a fini di ricerca.

Le richieste di produzione non sono accompagnate da etichette di ground truth, quindi usiamo LLM di frontiera come giudici per generare risposte di riferimento e misurare il grado di accordo di ciascun modello con esse. Raggruppiamo inoltre le richieste in 10 categorie di attività, tra cui estrazione di informazioni, classificazione per dominio, analisi del sentiment, intento e instradamento, ranking per pertinenza, moderazione dei contenuti, revisione di qualità e conformità, corrispondenza di entità, analisi aziendale e una categoria “Altro”. Questa suddivisione mostra come variano le prestazioni nei diversi casi d'uso reali.

La distribuzione delle attività è disomogenea: l'estrazione di informazioni rappresenta 425.402 domande, la classificazione per dominio 409.564 e l'analisi del sentiment 344.158. Insieme, queste tre categorie costituiscono il 50,8% delle domande campionate.

Decider v1.3 ottiene il massimo accordo con i giudici, pari al 93,98%, rispetto al 93,68% di Decider v1.2 e al 93,35% di Jev 1.14. Decider v1.3 e Jev 1.14 sono molto vicini nella classificazione per dominio e nell'analisi del sentiment, con scarti rispettivamente di 0,34 e 0,07 punti percentuali. Jev è in vantaggio di 0,69 punti nel ranking per pertinenza, mentre Decider v1.3 è in vantaggio di 0,93 punti nell'estrazione di informazioni (l'attività più comune nel campione) e di 1,21 punti in intento e instradamento.

Espandi

Il grafico seguente confronta il costo riportato per l'esecuzione dello stesso milione di richieste di produzione. Ogni richiesta può contenere più domande, quindi l'unità di misura qui è la richiesta, non la singola domanda.

Espandi

Robustezza

Abbiamo valutato la sensibilità alle etichette su 372 domande a scelta multipla, effettuando 4.788 richieste per modello. Abbiamo riordinato le opzioni, riassegnato le etichette ai testi delle risposte e rinominato le etichette preservando il significato di ogni domanda, quindi abbiamo verificato se la risposta semantica del modello cambiava. Tassi di inversione più bassi indicano una maggiore stabilità.

Decider v1.3 ha cambiato risposta solo sullo 0,27% delle domande per ciascuna trasformazione, rispetto al 2,69–4,84% di Jev 1.14. Abbiamo inoltre ripetuto input identici per misurare la variabilità in fase di serving: Decider v1.3 non ha mostrato alcuna variazione, mentre Jev 1.14 ha cambiato risposta sull'1,88% delle domande.

Espandi

Come usiamo Decider

Decider è pensato per flussi di lavoro che richiedono decisioni rapide e strutturate. In questa sezione esploriamo come sfruttare questi modelli per produrre un impatto significativo sul nostro modo di lavorare. Ecco alcuni dei casi più significativi.

Regole di sicurezza che migliorano da sole

Internamente utilizziamo già Decider per migliorare le nostre politiche di sicurezza.

L'attività dei nostri agenti viene registrata e viene eseguita una serie di controlli basati su regole per identificare eventuali comportamenti problematici. Un approccio basato su regole ci consente di monitorare i nostri agenti in tempo reale aggiungendo una latenza trascurabile. Offline, usiamo Decider per esaminare campioni di questi log registrati degli agenti. Se non è stato segnalato alcun comportamento problematico, Decider verifica se c'è qualcosa che il nostro insieme di regole ha trascurato; se invece è scattato un allarme, Decider verifica se si trattava di un falso allarme. Tutti i record in cui il nostro insieme di regole fallisce, in entrambi i casi, vengono inviati a un agente per il triage e viene proposta una correzione alle regole, che deve essere approvata da un membro del nostro team di sicurezza.

In un giorno, Decider ha letto 1 miliardo di token in 7.000 sessioni di agenti e ha individuato difetti che hanno portato a 14 correzioni delle regole, 6 delle quali sono state approvate e rilasciate entro due giorni. Riapplicate a una settimana di log, le correzioni hanno ridotto del 52% il volume della nostra regola più attiva e le regole ampliate hanno intercettato circa il 40% in più di azioni legittime da analizzare.

Espandi

Monitoraggio dei rollout di RL

Quando eseguiamo il post-training dei modelli con l'apprendimento per rinforzo, metriche aggregate come una ricompensa terminale non spiegano perché un rollout (un singolo tentativo di svolgere un'attività) sia riuscito o fallito. Un rollout può perdere ricompensa ingiustamente perché un servizio di strumenti o la sandbox ha avuto un errore, oppure ricevere una ricompensa immeritata se il valutatore trascura un'affermazione non supportata, come un valore inventato che nessuno strumento ha restituito.

Usiamo Decider per monitorare i rollout in questi casi. Innanzitutto, il codice identifica le parti di un rollout che meritano un'ispezione più approfondita: una chiamata a uno strumento non riuscita e il ragionamento circostante, codice eseguito senza errori oppure la risposta finale. Decider risponde poi a domande a scelta multipla su ciascuna parte, ad esempio cosa non ha funzionato in un passaggio (un servizio di strumenti, un sito esterno, la sandbox, l'harness o il codice dell'agente stesso) e se l'agente ha interpretato correttamente il risultato. Raggruppiamo tutte le domande su una determinata parte in un'unica richiesta e memorizziamo le probabilità anziché un verdetto, così da poter regolare le soglie in seguito senza interrogare di nuovo Decider. Il monitor si limita a osservare e diagnosticare: non modifica mai una ricompensa né interrompe un'esecuzione.

Espandi

Filtraggio della qualità delle pagine

Durante la scansione delle pagine web da indicizzare e mostrare agli utenti, molte pagine risultano di qualità troppo bassa per essere utili. Tra queste rientrano muri anti-bot, CAPTCHA e pagine di errore, ma anche pagine web caricate correttamente che semplicemente non contengono informazioni utili, come spam, contenuti di riempimento SEO o pagine di sola navigazione. Queste pagine di bassa qualità devono essere identificate ed escluse dal nostro indice.

Con Decider possiamo giudicare la qualità delle pagine mentre le scansioniamo. Nello stesso forward pass eseguiamo una serie di altre attività di classificazione, come identificare il dominio e il pubblico di destinazione del contenuto e stabilire se contiene informazioni dannose, illegali o che consentono l'identificazione personale. Rispetto all'uso di un LLM come giudice, Decider è notevolmente più veloce ed economico.

Espandi

Oltre a questi usi interni, Decider si presta anche a flussi di lavoro come i seguenti.

QA visivo

Poiché Decider legge le immagini, funziona anche come verificatore visivo, esaminando le modifiche di stile a pagine web o app e individuando i difetti. Può esaminare gli screenshot delle pagine alla ricerca di testo tagliato, elementi sovrapposti e layout non funzionanti prima che una modifica venga rilasciata, oppure segnalare grafici il cui design potrebbe trarre in inganno chi legge o violare le linee guida del brand.

Espandi

Navigazione nel browser

Gli agenti possono usare Decider per le piccole decisioni all'interno di attività più ampie. Un agente browser può inviare uno screenshot a ogni passaggio e ricevere informazioni dettagliate sullo stato della pagina e sul risultato atteso di ogni possibile azione.

Espandi

Pianificazione delle attività di ricerca

Le domande degli utenti possono variare notevolmente in complessità, così come la profondità della ricerca necessaria per trovare una risposta. Decider può stimarla prima che inizi la ricerca, consentendo di dedicare meno risorse alle domande semplici.

Espandi

Per iniziare

Decider restituisce probabilità. La soglia decisionale appropriata dipende dall'applicazione. Le frequenze delle etichette e i costi relativi di falsi positivi e falsi negativi variano a seconda dei casi d'uso. Incoraggiamo quindi gli utenti a calibrare le soglie su un set di sviluppo etichettato piccolo e rappresentativo, anziché presumere che una soglia fissa funzioni ugualmente bene per tutte le attività.

Consigliamo di usare Decider v1.3 per giudizi sfumati, griglie di valutazione dettagliate e flussi di lavoro in cui gli errori sono costosi. Scegli Decider Flash v1.3 per routing, etichettatura e filtraggio ad alto volume, quando latenza e costi sono i vincoli principali. Valuta entrambi i modelli su esempi rappresentativi del tuo carico di lavoro, quindi scegli il modello che soddisfa i tuoi requisiti di qualità, latenza e budget.

Entrambi i modelli sono disponibili come pesi scaricabili su Hugging Face con licenza Apache, tramite OpenRouter e tramite la Perplexity Decisions API.

Citazione

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}