Decisions API di Perplexity: l’AI che risponde con probabilità, non con testo

Per anni abbiamo chiesto ai modelli linguistici di rispondere in prosa e poi abbiamo scritto codice per interpretare quella prosa. Perplexity ha deciso di eliminare questo passaggio: il 2 ottobre 2026 ha presentato la Decisions API, un servizio che non genera testo ma restituisce probabilità. Se devi capire se un messaggio è urgente, a quale categoria appartiene o che voto merita un testo, ottieni direttamente numeri su cui puoi ragionare con una semplice soglia.

La novità è meno appariscente di un nuovo chatbot, ma per chi costruisce prodotti con l’AI può contare più di tante demo spettacolari.

Che cos’è la Decisions API di Perplexity

Secondo la documentazione ufficiale di Perplexity, la Decisions API risponde a domande su un contenuto con distribuzioni di probabilità invece che con testo. Le dai uno “stato”, cioè il materiale da valutare, e una serie di domande tipizzate. Il servizio ti restituisce risposte strutturate, già pronte per essere usate dal tuo software, senza bisogno di estrarre un’etichetta da un paragrafo scritto in linguaggio naturale.

L’endpoint è una chiamata POST a api.perplexity.ai/v1/decisions, con autenticazione tramite chiave API. L’unico modello disponibile al momento è pplx-decider-v1-27b, un modello specializzato da 27 miliardi di parametri, multimodale, pensato per dare risposte tipizzate e non per conversare.

Cosa puoi dare in input

Lo stato può essere una stringa di testo, un oggetto JSON, un array oppure un’immagine in formato PNG, JPEG o WebP codificata come data URL in base64. Per le immagini c’è un limite di 2.048 tile da 32 per 32 pixel, che corrisponde a circa 1440 per 1440 pixel oppure 2048 per 1024. Ogni richiesta deve restare sotto i 262.144 token di input.

Un dettaglio utile: nella stessa chiamata puoi porre più domande sullo stesso contenuto, quindi un ticket di assistenza o un documento viene letto una volta sola e valutato su più dimensioni.

I tre tipi di domanda

La prima è la domanda sì o no, indicata nella documentazione con il tipo noul, che restituisce un’unica probabilità compresa tra 0 e 1. La seconda è la scelta multipla, il tipo choice, che ti dà l’opzione più probabile, le probabilità di tutte le alternative e un indice di confidenza. La terza è il punteggio, il tipo score, che applica una scala ordinata da 0 a 10 e restituisce la media pesata dalle probabilità di ciascun livello, oltre alle probabilità dei singoli livelli e alla confidenza.

In pratica, al posto di “mi sembra abbastanza urgente” ottieni “0,42 di probabilità che sia critico”. Ed è un’informazione con cui si può lavorare davvero.

Perché le probabilità cambiano il modo di costruire un flusso AI

Chi ha integrato un modello generativo in un processo aziendale conosce il problema. Chiedi di classificare un messaggio, il modello risponde con una frase gentile, a volte con un’etichetta leggermente diversa da quelle previste, a volte con una spiegazione che nessuno ha chiesto. Servono prompt rigidi, parser fragili e controlli per i casi anomali. E anche quando tutto funziona, non sai quanto il modello fosse sicuro della scelta.

Con una distribuzione di probabilità il ragionamento si sposta altrove. Non devi più convincere il modello a rispettare un formato, perché il formato è garantito dall’API. Devi solo decidere dove mettere le soglie.

L’esempio dello smistamento dei ticket

Perplexity mostra il concetto con un esempio di smistamento dei ticket di assistenza. Ogni richiesta viene inviata con il suo piano, l’oggetto e il testo, insieme a domande di tre tipi: una sì o no, una a scelta multipla sull’intento e una a punteggio sulla gravità. Le probabilità vengono poi trasformate in percorsi tramite regole elementari.

Il ticket viene escalato se la probabilità di criticità raggiunge almeno 0,35 oppure se la gravità attesa arriva a 2,5. Finisce in revisione umana quando la confidenza sull’intento scende sotto 0,60, perché l’incertezza richiede un giudizio delle persone. Viene chiuso se è spam con gravità sotto 0,5, ottiene una risposta automatica se il bisogno umano e la gravità sono bassi e l’intento è di self service, altrimenti va in coda come di consueto.

Nella documentazione si legge che le soglie diventano confronti di una riga e che regolarle significa cambiare una costante, non riscrivere un prompt.

Il vantaggio economico è altrettanto chiaro. Nell’esempio solo i ticket escalati passano alla fase di indagine con un modello di frontiera, e le chiamate costose scendono da 12 ticket a 3. È il principio di molte architetture mature: un modello piccolo e veloce filtra, il modello grande interviene solo quando serve.

Prezzi, prestazioni e cosa sappiamo del modello

Sul fronte dei costi la documentazione è netta: la Decisions API costa 0,04 dollari per milione di token in input, mentre i token in output sono gratuiti. Trattandosi di risposte numeriche e brevi, la cifra è bassa rispetto ai modelli generativi di fascia alta, e questo rende realistico applicarla a volumi elevati di contenuti, come code di assistenza, moderazione o controllo di qualità.

Alcuni media di settore riportano inoltre che Perplexity ha reso disponibile il modello pplx-decider-v1-27b come modello aperto. Questo punto compare nelle cronache sul lancio, ma la pagina della documentazione che abbiamo consultato non ne parla: prima di basare un progetto sulla disponibilità dei pesi ti conviene verificare licenza e condizioni direttamente dalle fonti ufficiali.

I benchmark vanno letti con cautela

Sempre secondo le cronache sul lancio, il modello avrebbe ottenuto un’accuratezza composita dell’85,71% su 11 compiti di valutazione e 7.210 campioni, tra cui test come FinancialPhraseBank, RAGTruth, TabFact e Circa. Il concorrente citato, Jev, si fermerebbe all’84,51%. Il margine è sottile e c’è una precisazione importante: Jev avrebbe ottenuto un punteggio migliore in 6 test su 11.

Si tratta inoltre di risultati ottenuti con test interni di Perplexity, non di una valutazione indipendente. Vanno quindi considerati un’indicazione, non una garanzia: prima di mettere il modello in produzione, provalo sui tuoi dati reali.

Il contesto: i modelli di decisione entrano in scena

La Decisions API si inserisce in una tendenza più ampia. Dopo anni di corsa verso modelli sempre più grandi e loquaci, cresce l’interesse per modelli piccoli e specializzati, che svolgono un solo compito e lo fanno in modo prevedibile. Un modello da 27 miliardi di parametri non è minuscolo, ma è lontanissimo dai sistemi di frontiera come Gemini 4 Argon di Google, pensato per lavori complessi e di lunga durata.

La divisione dei ruoli è sensata: il modello di frontiera ragiona, pianifica e scrive, il modello di decisione smista e valuta. Anche il rapporto con i costi cambia, e chi segue i piani a pagamento dei grandi servizi, come il nuovo piano ChatGPT Pro da 500 dollari, sa quanto conti usare il modello giusto per ogni passaggio.

Una questione di controllo e di affidabilità

C’è poi un tema di trasparenza. Un modello generativo può sembrare convincente anche quando sbaglia, mentre una probabilità esplicita rende visibile l’incertezza. Resta da ricordare che una probabilità non è una verità: se il modello è mal calibrato, un 0,90 può essere comunque sbagliato. Per questo servono test di calibrazione sui tuoi dati, esattamente come quando regoli parametri di campionamento come descritto nella nostra guida a temperatura, top-p e top-k.

Come puoi usarla nel tuo lavoro

Se sei uno sviluppatore, il caso d’uso più immediato è il filtro a monte di un flusso con agenti: classificare le richieste in ingresso, stabilire quali richiedono un modello costoso e quali una risposta standard. Se lavori nel marketing o nei contenuti, puoi immaginare una valutazione a punteggio di bozze, descrizioni di prodotto o commenti degli utenti secondo una griglia che definisci tu.

Chi si occupa di SEO può pensare a controlli ripetitivi su grandi quantità di pagine, per esempio per segnalare testi di bassa qualità o per assegnare una categoria di intento di ricerca, riservando la revisione umana ai casi dubbi. Nulla di tutto questo è magico: serve definire criteri chiari, soglie sensate e un campione di verifica.

Alcune buone pratiche valgono comunque sempre. Parti da un campione etichettato a mano e confronta le risposte del modello. Scegli le soglie in base al costo degli errori, perché perdere un ticket critico pesa più di rivedere un ticket banale. Tieni sempre un percorso di revisione umana per i casi in cui la confidenza è bassa.

Conclusioni

La Decisions API di Perplexity non è l’ennesimo assistente conversazionale, ed è proprio questo il suo punto di forza: risponde con numeri, costa pochissimo per milione di token in input e si inserisce bene in flussi automatici dove la prevedibilità conta più della creatività. I dati sulle prestazioni arrivano da test interni e vanno verificati, ma l’idea di sostituire la prosa con probabilità è concreta e utile.

Se hai un processo in cui oggi un modello generativo etichetta, smista o valuta contenuti, prova a rifarlo in piccolo con la documentazione ufficiale e confronta costi e precisione sui tuoi casi reali. Poi raccontaci come è andata: siamo curiosi di sapere dove le soglie hanno funzionato meglio.