Perplexity Decider

Lansăm Decider v1.3 și Decider Flash v1.3, succesorii modelelor noastre de decizie anterioare: v1, v1.1, v1.2 și Flash v1.2.

Decider Flash v1.3 este un model mai mic, distilat din Decider v1.3. Ambele modele sunt disponibile pe Hugging Face, sub licență Apache, prin OpenRouter și prin Perplexity Decisions API.

Perplexity Decider este inspirat de Jev, System One Model de la TypeSafe AI. Acceptă clasificare binară și multiclasă, cu etichete ordonate sau neordonate, returnând probabilități pe care aplicațiile le pot folosi pentru a clasifica, ruta, ordona și evalua intrările.

Ambele modele v1.3 îmbunătățesc performanța și robustețea într-o gamă largă de sarcini de text și vizuale, datorită atenției bidirecționale, datelor de antrenare mai bine selectate și unei rețete de antrenare rafinate. Introducem și locate, o funcție nouă care evidențiază conținutul selectat pentru sarcini de recunoaștere a entităților denumite, identificare a informațiilor personale și răspuns extractiv la întrebări.

În această postare explicăm cum antrenăm și evaluăm Decider și arătăm cum îl folosim intern la Perplexity.

Ce este un model de decizie?

Un model de decizie este un clasificator de uz general. Îi oferiți o intrare și un set de întrebări, fiecare cu răspunsurile posibile. Pentru fiecare întrebare, returnează o distribuție de probabilitate peste răspunsuri. Acceptă 3 tipuri de întrebări:

• Da / Nu: decizii binare.
• Variante multiple: etichete personalizate cu mai multe clase.
• Scor: niveluri ordonate.

Modelele de decizie acceptă o gamă largă de sarcini de clasificare și scorare:

• Evaluarea rezultatelor: aprecierea fidelității, calității și siguranței.
• Rutare: direcționarea solicitărilor către modele mai mici sau mai mari în funcție de dificultate.
• Moderare și securitate: detectarea conținutului dăunător, a phishingului și a injecțiilor de prompturi în rezultatele instrumentelor.
• Filtrare și etichetare: organizarea unor colecții mari de conținut.
• Regăsire și reordonare: scorarea rezultatelor căutării după relevanță.

Multe dintre aceste sarcini erau gestionate anterior de modele generative precum LLM-urile, chiar dacă nu necesită generare de text liber. Modelele de decizie se situează între LLM-uri și clasificatoarele specifice sarcinilor. Ele returnează probabilități pentru mai multe întrebări despre aceeași intrare într-o singură trecere directă, evitând generarea răspunsurilor token cu token și partajând calculul între întrebări. Spre deosebire de clasificatoarele specifice sarcinilor, ele pot gestiona sarcini noi prin prompturi în limbaj natural, o flexibilitate învățată din antrenarea pe sarcini diverse într-un format comun de întrebare-răspuns.

Antrenare

Transformarea unui LLM generativ într-un model de decizie

Construim Decider adaptând backbone-uri LLM generative puternice. Pentru a explica adaptarea, descriem mai întâi cum este reprezentată o cerere. După cum este ilustrat mai jos, o cerere constă dintr-un context comun (starea) și un număr de întrebări. Starea va fi reutilizată de toate întrebările.

De exemplu, pentru un document și rezumatul său, o singură solicitare poate întreba dacă rezumatul reprezintă fidel documentul și dacă este destinat unui expert sau publicului larg. După stare, fiecare bloc de întrebare conține o întrebare și răspunsurile posibile, fiecăruia fiindu-i atribuit un token de etichetă predefinit, precum A, B sau C. Un token special <|marker|> indică locul de unde se citește predicția modelului. În această poziție, un strat de ieșire liniar învățat (un cap de decizie) mapează starea ascunsă la scoruri pentru opțiunile de răspuns ale întrebării, care sunt apoi convertite în probabilități.

Extinde

Inițializăm stratul de ieșire din modelul de bază, care în mod normal scorează următorul token din întregul vocabular, și păstrăm doar rândurile corespunzătoare tokenurilor de opțiune predefinite, precum A, B sau C. Acest strat redus este apoi antrenat să transforme starea ascunsă a lui <|marker|> în scoruri de răspuns. Această abordare acoperă toate întrebările de clasificare, deoarece toate pot fi formulate ca întrebări cu variante multiple de răspuns.

Pentru antrenare, luăm sute de seturi de date publice care acoperă sarcini diverse (sentiment, inferență în limbaj natural, detectarea intenției, potrivirea entităților, moderare, verificarea faptelor, evaluări etc.) și convertim fiecare exemplu în formatul unificat descris mai sus: o stare, una sau mai multe întrebări, opțiunile acestora și o țintă. Ținta poate fi singura opțiune corectă, dacă avem etichete de referință, sau o distribuție de probabilitate peste opțiuni.

În v1.3 introducem locate, care extrage text din stare în loc să aleagă dintre opțiuni predefinite. O întrebare locate descrie ce trebuie găsit, folosind fie o etichetă scurtă, precum „locație”, fie o instrucțiune, precum „Extrage numele orașului în care se află postul.” Modelul returnează textul exact corespunzător din stare, împreună cu pozițiile caracterelor de început și de sfârșit. Dacă nu identifică nicio potrivire, returnează o listă goală.

Extinde

Datorită stării partajate, o singură solicitare poate combina întrebări de tip locate, de clasificare și de scorare despre aceeași intrare. De exemplu, poate întreba dacă un post necesită experiență la nivel senior și poate extrage competențele cerute.

Atenție bidirecțională: modelul citește în ambele direcții

Modelele noastre pornesc de la arhitecturi de bază generative puternice, preantrenate, a căror atenție cauzală permite fiecărui token să acorde atenție doar lui însuși și tokenurilor precedente. Studiile noastre de ablație au arătat că transformarea straturilor de atenție completă ale arhitecturii de bază în straturi bidirecționale îmbunătățește performanța, așa că adoptăm acest design pentru a permite fiecărui token să încorporeze context din întreaga intrare.

Atenția bidirecțională introduce o altă alegere de design: cum ar trebui să interacționeze starea și întrebările? Am luat în considerare trei tipare de atenție, cu implicații diferite pentru performanță, stabilitatea răspunsurilor și reutilizarea cache-ului:

• Totul vede totul (v1.2): Starea și toate întrebările sunt procesate împreună, cu atenție bidirecțională completă. Calculul asupra stării este partajat, dar răspunsul la o întrebare se poate schimba în funcție de celelalte întrebări puse.
• Întrebări izolate (v1.3): Starea acordă atenție tuturor întrebărilor, în timp ce fiecare întrebare acordă atenție doar stării și propriilor tokenuri. Întrebările se pot influența în continuare indirect prin starea partajată, dar rezultatele sunt mai stabile.
• Complet stocabil în cache: Starea acordă atenție doar sieși, în timp ce fiecare întrebare acordă atenție stării și propriilor tokenuri. Starea este independentă de întrebări și reutilizabilă între cereri, pentru a profita de stocarea în cache a prompturilor. Nu o folosim în mod implicit, deoarece faptul că starea poate vedea întrebările contează foarte mult pentru mai multe sarcini, dar o mică ajustare fină poate comuta un model la această variantă.

În cele din urmă, am ales întrebările izolate pentru performanța și stabilitatea lor ridicate.

Extinde

Rețeta de antrenare

Antrenarea se desfășoară în trei etape pentru ambele dimensiuni de model. Mai întâi antrenăm modelul mai mare, bazat pe Qwen3.8-27B, folosind entropia încrucișată pe seturi mari de date, apoi îl distilăm în modelul mai mic Qwen3.5-4B.

Prima etapă este antrenarea generalistă, în care ajustăm complet modelul pe corpusuri la scară largă. În această etapă acceptăm doar date care ajută modelul în general și care nu sunt specifice niciunui benchmark; prin urmare, excludem orice partiții de antrenare ale benchmarkurilor.

După ce acest model generalist este antrenat, rulăm o a doua etapă, mai granulară, folosind LoRA. Datele folosite în această etapă vizează domenii și sarcini specifice. Adăugăm date în a doua etapă, nu în prima, dacă observăm câștiguri restrânse sau unele regresii pe alte sarcini. Folosim LoRA pentru a evita să ne îndepărtăm prea mult de modelul generalist și să riscăm pierderea de performanță pentru a ne adapta acelor domenii specifice. Scopul este îmbunătățirea performanței, păstrând în același timp cunoștințele generale ale backbone-ului. De asemenea, folosim o pondere atunci când integrăm LoRA înapoi în modelul de bază, pentru a controla mai precis deriva și a favoriza metricile pe datele rezervate în detrimentul oricăror câștiguri în domeniu.

În final, adăugăm un pas specific pentru viziune. Similar celei de-a doua etape, pasul de viziune este tratat ca un alt pas de specializare fină, folosind un adaptor LoRA care este îmbinat înapoi în modelul de bază cu o anumită pondere. Unele capacități vizuale pot fi obținute în detrimentul performanței pe text. Deoarece observăm o utilizare mult mai mare a modelelor pe text, prioritizăm metricile pentru text în fața celor pentru viziune.

Pentru ambele etape de text, folosim media ponderilor din trei rulări, fiecare cu un seed aleatoriu diferit. Am constatat că acest lucru îmbunătățește performanța și robustețea modelului agregat.

După obținerea modelului mare final, aplicăm aceeași procedură de antrenare în trei etape modelului mai mic. Aici, modelul mare acționează ca profesor: distribuția de ieșire prezisă de acesta înlocuiește etichetele de referință, iar modelul mai mic este antrenat să minimizeze divergența KL dintre predicțiile sale și cele ale profesorului. Acest obiectiv de distilare depășește entropia încrucișată pe aceleași date de antrenare. Deși entropia încrucișată are performanțe mai bune pe benchmarkurile cu date de antrenare dedicate, aceasta generalizează mai slab pe datele rezervate. Ipoteza noastră este că distilarea transferă mai bine distribuția de ieșire a profesorului, inclusiv încrederea acestuia în alternativele care nu sunt de referință, în timp ce entropia încrucișată încurajează supraadaptarea la distribuția de antrenare specifică benchmarkului. Prin urmare, adoptăm obiectivul de distilare bazat pe KL.

Pentru a atenua contaminarea dintre datele de antrenare și cele de testare, eliminăm orice eșantioane de antrenare care s-ar putea suprapune cu oricare dintre evaluările pe care le folosim. Acest lucru este important deoarece unele seturi de date publice de antrenare conțin părți mari din unele seturi de date de evaluare. De asemenea, efectuăm audituri ample ale biasurilor și le eliminăm, pentru a ne asigura că îmbunătățirile noastre sunt fiabile și nu sunt determinate doar de biasuri învățate.

Adăugarea capacității de a extrage informații

Funcția locate extrage informații, precum entitățile denumite, din text, fără a schimba modul în care răspunde la solicitările obișnuite. Pentru aceasta, introducem o etapă suplimentară de antrenare: adăugăm la Decider un nou token special, <|locate|>, un cap de span și un adaptor LoRA.

Inițializăm embedding-ul lui <|locate|> pornind de la <|marker|>, învățat în etapele anterioare de antrenare. Antrenăm doar acest nou embedding, capul de span și adaptoarele LoRA, păstrând înghețate ponderile originale ale arhitecturii de bază și capul de decizie. Fiecare câmp solicitat primește propriul token <|locate|>.

Capul de segmente folosește reprezentarea lui <|locate|> împreună cu reprezentările tokenurilor de stare pentru a evalua unde încep și unde se termină segmentele potrivite și ce perechi început-sfârșit corespund între ele. De asemenea, folosește reprezentarea tokenului <|locate|> pentru a prezice praguri specifice fiecărui câmp pentru aceste scoruri. Segmentele selectate sunt returnate ca poziții de caractere în textul original.

Antrenăm capul de segmente cu o funcție de pierdere InfoNCE adaptată, care împinge fiecare segment de referință peste prag, iar pragul peste orice alt segment. Funcția de pierdere are doi termeni: primul împinge scorurile segmentelor corecte peste prag și peste segmentele greșite. Al doilea termen împinge pragul peste scorurile segmentelor greșite. Câmpurile fără răspuns primesc doar al doilea termen, care învață modelul să returneze o listă goală.

Antrenăm pe o combinație de sarcini de extragere a secvențelor de text (span extraction), inclusiv recunoașterea entităților denumite, detectarea PII și răspunsul extractiv la întrebări. Variem descrierile câmpurilor de la etichete scurte la instrucțiuni detaliate, astfel încât modelul să învețe să urmeze cererea, nu să memoreze un set fix de etichete.

Locate învață modelul o sarcină diferită din punct de vedere structural și dorim să o adăugăm fără a pierde ceea ce modelul face deja bine. Integrarea adaptoarelor locate în backbone cauzează o anumită regresie pe cererile de decizie. Pentru a limita acest efect, desfășurăm investigații, cum ar fi mai multe date de reluare din etapele anterioare și obiective auxiliare care mențin ieșirile modelului pe cererile de decizie apropiate de cele ale modelului original. Totuși, constatăm că, în prezent, integrarea nu este încă lipsită de pierderi, așa că păstrăm adaptoarele neintegrate și le activăm doar pentru cererile locate.

Evaluare

Evaluăm Decider v1.3 și Decider Flash v1.3 pe benchmarkuri externe din Hugging Face Decision Index, ClaimBench de la Vals AI și Artificial Analysis Decision Index.

În cadrul acestor evaluări, modelele noastre demonstrează performanțe solide. Chiar dacă aceste clasamente includ sarcini private, ele pot fi totuși manipulate prin trimiteri repetate și ajustări iterative bazate pe feedbackul din clasament. Pentru a completa aceste clasamente, evaluăm modelele pe o suită internă care combină sarcini private de producție cu evaluări pe date rezervate, extrase din seturi de date publice care nu sunt benchmarkuri. Aceste evaluări oferă o verificare suplimentară a generalizării dincolo de benchmarkurile publice, ajutându-ne să distingem îmbunătățirile mai ample de câștigurile specifice suitelor de evaluare familiare.

Intern, am construit o suită de peste 200 de sarcini care acoperă diverse domenii și tipuri de sarcini, precum clasificarea, scorarea, reordonarea și extragerea entităților. Pentru a evalua onest performanța reală a lui Decider, toate evaluările se fac zero-shot, fără ajustare fină specifică sarcinii, ceea ce ne oferă un semnal clar despre aspectele în care trebuie să îmbunătățim modelul.

Clasificarea interogărilor

La Perplexity folosim un sistem de clasificare cu mai multe capete pentru a procesa fiecare interogare a utilizatorilor. Fiecare interogare trece mai întâi printr-un model de embedding care acționează ca extractor de trăsături. Embedding-ul rezultat este apoi transmis mai multor capete de clasificare separate, inclusiv clasificatori binari și multi-etichetă. De exemplu, un cap determină dacă o interogare a utilizatorului ar trebui să declanșeze o căutare pe web.

Pe 63 de sarcini de clasificare cu referințe reetichetate independent de un LLM de frontieră, Decider v1.3 obține o acuratețe medie de 91,6%, depășind clasificatorii noștri din producție cu 6,54 puncte procentuale. Și Decider Flash v1.3 depășește modelul de referință din producție, iar Decider v1.3 depășește Jev 1.14.

Extinde

Clasificare specifică domeniilor

Am alcătuit, din seturi de date publice, o suită de evaluare specifică domeniilor pentru a evalua performanța de clasificare a modelelor de decizie în șapte domenii: verificarea afirmațiilor (6 sarcini), sănătate (7), securitate cibernetică (8), programare (16), administrație publică (7), drept (9) și finanțe (9).

De exemplu, „evaluează complexitatea temporală a unui program Python” sau „folosește un raport financiar anual pentru a determina dacă numerarul nerestricționat al unei companii acoperă principalul datoriei scadent în următoarele douăsprezece luni”. Decider v1.3 conduce în toate cele șapte domenii, depășind Jev 1.14 cu până la 12,9 puncte procentuale în finanțe și cu 9,3 puncte în drept. Decider Flash v1.3 rămâne în urma lui Jev 1.14 în finanțe, programare și drept și are performanțe similare în celelalte domenii.

Extinde

Regăsire și reordonare

Căutarea este în centrul Perplexity. Menținem o suită amplă de sarcini de regăsire pentru a evalua performanța de reordonare a modelelor noastre. Pentru fiecare sarcină, folosim mai întâi un set de modele de embedding pentru a regăsi primele 50 de documente candidate din fiecare corpus. Apoi reordonăm acești candidați folosind Decider și îi comparăm performanța cu un reranker de referință puternic, Qwen3-Reranker-8B.

Evaluăm Decider într-un cadru zero-shot, punctual (pointwise), folosind modelul pentru a scora direct și independent fiecare pereche interogare–document și a ordona documentele după relevanță. Pe 72 de sarcini de regăsire, Decider v1.3 obține un nDCG@10 mediu de 83,99, depășind Qwen3-Reranker-8B cu 1,81 puncte și Jev 1.14 cu 2,24 puncte.

Pe benchmarkul BEIR, ambele modele depășesc Qwen3-Reranker-8B cu 8,78, respectiv 7,05 puncte nDCG@10. Față de Jev 1.14, Decider v1.3 obține cu 1,33 puncte mai mult, în timp ce versiunea Flash obține cu 0,4 puncte mai puțin.

Extinde

Clasificare multilingvă

Pentru a evalua modelele de decizie dincolo de limba engleză, am alcătuit un benchmark de clasificare multilingvă cu 19 sarcini specifice limbilor, din 8 seturi de date publice, cu 46.484 de exemple în opt limbi: germană, spaniolă, franceză, italiană, rusă, japoneză, coreeană și chineză. Benchmarkul acoperă detectarea intenției, clasificarea pe subiecte, analiza sentimentelor, inferența în limbaj natural, detectarea parafrazelor, detectarea limbajului ofensator și acceptabilitatea gramaticală.

Raportăm acuratețea medie pe sarcini pentru fiecare limbă, ponderând fiecare sarcină în mod egal. Decider v1.3 depășește Jev 1.14 în toate cele opt limbi, iar Decider Flash v1.3 în șase, cu acuratețe medii pe sarcini de 88,16% pentru Decider v1.3 și 86,50% pentru Decider Flash v1.3, față de 85,41% pentru Jev 1.14.

Extinde

NER, PII și QA extractiv

Evaluăm funcția locate pe 17 sarcini din afara domeniului de antrenare, care îi testează capacitatea de extragere în diverse domenii, formate de intrare (text, tabele, documente structurate) și instrucțiuni (etichete scurte, întrebări și descrieri detaliate). Domeniile variază de la Wikipedia la lucrări științifice, rapoarte despre amenințări cibernetice, asistență tehnică, politici de confidențialitate, CV-uri și contracte juridice. Solicitările variază de la nume scurte de etichete, precum „persoană” sau „adresă de e-mail”, la întrebări despre un tabel sau un tichet de asistență, până la descrieri detaliate ale câmpurilor pentru extragerea structurată, precum părțile unui NDA sau totalul de pe o factură.

Evaluăm NER și PII folosind F1 pe segmente exacte, care necesită ca segmentele prezise să corespundă exact limitelor de referință. QA extractiv folosește F1 la nivel de caracter, acordând credit parțial pentru textul de răspuns care se suprapune, în timp ce extracția structurată folosește acuratețea câmpurilor, adică proporția de câmpuri extrase corect. Pentru analiza CV-urilor, facem media scorurilor F1 pe segmente exacte pentru NER și PII.

Comparăm modelele noastre cu modele de extragere de uz general de dimensiuni diferite: GLiNER large v2.5 (0,5B), Liquid d1 (2B) și Clairic de la Cloudflare (dimensiune nedezvăluită). Decider v1.3 atinge un scor mediu de 69,0 (folosind metrica principală a fiecărei sarcini), iar Decider Flash v1.3 atinge 63,6, față de 43,3 pentru Liquid d1, 41,5 pentru Clairic și 33,6 pentru GLiNER large v2.5. Ambele modele Decider conduc în fiecare categorie.

Extinde

Clasificarea imaginilor

Decider acceptă nativ sarcini vizuale încă de la v1. Pentru a-i evalua performanța dincolo de text, am alcătuit o suită de benchmarkuri cu cinci sarcini, cu accent deosebit pe clasificarea documentelor, inclusiv facturi, scrisori și CV-uri. Suita acoperă și clasificarea imaginilor din satelit, clasificarea texturilor, clasificarea raselor de animale de companie și numărarea animalelor.

Decider v1.3 obține o acuratețe medie de 76,99% pe cele cinci sarcini vizuale, depășind Jev 1.14 cu 1,47 puncte procentuale. Decider Flash v1.3 obține 72,77%, demonstrând capacități de clasificare vizuală într-un model mai mic.

Extinde

Solicitări de decizie din lumea reală

Am eșantionat un milion de solicitări deduplicate, cu PII mascate, trimise către Perplexity Decision API în primele 18 zile de disponibilitate. Deoarece fiecare solicitare poate conține mai multe întrebări despre aceeași stare, eșantionul cuprinde 2.318.887 de întrebări individuale. Toate solicitările au fost incluse cu permisiunea explicită a utilizatorilor pentru cercetare.

Solicitările din producție nu vin cu etichete de referință (ground truth), așa că folosim LLM-uri de frontieră ca evaluatori pentru a genera răspunsuri de referință și măsurăm gradul de concordanță al fiecărui model cu acestea. De asemenea, grupăm solicitările în 10 categorii de sarcini, inclusiv extragerea de informații, clasificarea pe domenii, analiza sentimentelor, intenție și rutare, ordonarea după relevanță, moderarea conținutului, verificarea calității și a conformității, potrivirea entităților, analiza de business și o categorie „Altele”. Această defalcare arată cum variază performanța în diferite cazuri de utilizare reale.

Combinația de sarcini este inegală: extragerea de informații reprezintă 425.402 întrebări, clasificarea pe domenii 409.564, iar analiza sentimentelor 344.158. Împreună, aceste trei categorii reprezintă 50,8% din întrebările eșantionate.

Decider v1.3 obține cea mai mare concordanță cu evaluatorii, de 93,98%, față de 93,68% pentru Decider v1.2 și 93,35% pentru Jev 1.14. Decider v1.3 și Jev 1.14 sunt foarte apropiate la clasificarea pe domenii și analiza sentimentelor, cu diferențe de 0,34, respectiv 0,07 puncte procentuale. Jev conduce cu 0,69 puncte la ordonarea după relevanță, în timp ce Decider v1.3 conduce cu 0,93 puncte la extragerea de informații (cea mai frecventă sarcină din eșantion) și cu 1,21 puncte la intenție și rutare.

Extinde

Graficul de mai jos compară costul raportat al rulării acelorași un milion de solicitări din producție. Fiecare solicitare poate conține mai multe întrebări, așa că unitatea de măsură aici este solicitarea, nu întrebarea individuală.

Extinde

Robustețe

Am evaluat sensibilitatea la etichete pe 372 de întrebări cu variante multiple de răspuns, trimițând 4.788 de solicitări per model. Am reordonat opțiunile, am reatribuit etichetele textelor de răspuns și am redenumit etichetele, păstrând sensul fiecărei întrebări, apoi am verificat dacă răspunsul semantic al modelului s-a schimbat. Ratele mai mici de schimbare a răspunsului indică o stabilitate mai mare.

Decider v1.3 și-a schimbat răspunsul la doar 0,27% dintre întrebări la fiecare transformare, față de 2,69–4,84% pentru Jev 1.14. Am repetat și intrări identice pentru a măsura variabilitatea la servire: Decider v1.3 nu a prezentat nicio modificare, în timp ce Jev 1.14 și-a schimbat răspunsul la 1,88% dintre întrebări.

Extinde

Cum folosim Decider

Decider este creat pentru fluxuri de lucru care au nevoie de decizii rapide și structurate. În această secțiune explorăm cum îl putem folosi pentru a avea un impact semnificativ asupra modului în care lucrăm. Iată câteva exemple care s-au remarcat.

Reguli de securitate care se îmbunătățesc singure

Intern, folosim deja Decider pentru a ne îmbunătăți politicile de securitate.

Activitatea agenților noștri este înregistrată și se efectuează o serie de verificări bazate pe reguli pentru a identifica orice comportament problematic. O abordare bazată pe reguli ne permite să monitorizăm agenții în timp real, cu o latență suplimentară neglijabilă. Offline, folosim Decider pentru a analiza eșantioane din aceste jurnale înregistrate ale agenților. Dacă nu a fost semnalat niciun comportament problematic, Decider verifică dacă există ceva ce setul nostru de reguli a omis; iar dacă s-a declanșat o alarmă, Decider verifică dacă a fost o alarmă falsă. Orice înregistrare pentru care setul de reguli eșuează în oricare dintre cazuri este trimisă unui agent pentru triere, iar acesta propune o corecție a regulilor, care trebuie aprobată de un membru al echipei noastre de securitate.

Într-o singură zi, Decider a citit 1 miliard de tokenuri din 7.000 de sesiuni ale agenților și a identificat deficiențe care au dus la 14 corecții ale regulilor, dintre care 6 au fost aprobate și implementate în două zile. Rulate din nou pe jurnalele unei săptămâni, corecțiile au redus cu 52% volumul celei mai active reguli, iar regulile extinse au detectat cu aproximativ 40% mai multe acțiuni legitime de investigat.

Extinde

Monitorizarea rollout-urilor RL

Când post-antrenăm modele cu învățare prin întărire, metricile agregate, precum recompensa finală, nu explică de ce un rollout (o încercare individuală de a rezolva o sarcină) a reușit sau a eșuat. Acesta poate pierde recompensa pe nedrept, pentru că un serviciu de instrumente sau mediul sandbox a eșuat, ori poate primi o recompensă nemeritată dacă evaluatorul trece cu vederea o afirmație nesusținută, cum ar fi o valoare inventată pe care niciun instrument nu a returnat-o.

Folosim Decider pentru a monitoriza rollout-urile în aceste cazuri. Mai întâi, codul identifică părțile unui rollout care merită o inspecție mai atentă: un apel de instrument eșuat și raționamentul din jurul lui, codul care a rulat fără erori sau răspunsul final. Apoi, Decider răspunde la întrebări cu variante multiple despre fiecare parte, de exemplu ce a eșuat într-un pas (un serviciu de instrumente, un site extern, mediul sandbox, infrastructura harness sau propriul cod al agentului) și dacă agentul a interpretat corect rezultatul. Grupăm toate întrebările despre o anumită parte într-o singură solicitare și stocăm probabilitățile în locul unui verdict, astfel încât să putem ajusta pragurile ulterior fără a interoga din nou Decider. Monitorul doar observă și diagnostichează: nu modifică niciodată o recompensă și nu oprește nicio rulare.

Extinde

Filtrarea paginilor după calitate

Când parcurgem pagini web prin crawling pentru a le indexa și a le servi utilizatorilor, multe pagini au o calitate prea slabă pentru a fi utile. Aici intră zidurile anti-bot, CAPTCHA-urile și paginile de eroare, dar și pagini web încărcate corect care pur și simplu nu conțin informații utile, precum spamul, conținutul de umplutură pentru SEO sau paginile doar de navigare. Aceste pagini de calitate slabă trebuie identificate și eliminate din indexul nostru.

Folosind Decider, putem evalua calitatea paginilor pe măsură ce le accesăm prin crawling. În aceeași trecere directă, efectuăm o serie de alte sarcini de clasificare, cum ar fi identificarea domeniului și a publicului țintă al conținutului și dacă acesta conține informații dăunătoare, ilegale sau de identificare personală. Comparativ cu utilizarea unui LLM ca evaluator, Decider este considerabil mai rapid și mai ieftin.

Extinde

Pe lângă aceste utilizări interne, Decider se potrivește și pentru fluxuri de lucru precum următoarele.

QA vizual

Deoarece Decider citește imagini, funcționează și ca verificator vizual, analizând modificările de stil ale paginilor web sau ale aplicațiilor și identificând defectele. Poate examina capturi de ecran ale paginilor pentru a depista text trunchiat, elemente suprapuse sau machete defecte înainte de lansarea unei modificări ori poate semnala graficele al căror design ar putea induce în eroare cititorul sau ar putea încălca un ghid de brand.

Extinde

Navigarea în browser

Agenții pot folosi Decider pentru deciziile mici din cadrul unor sarcini mai ample. Un agent de browser poate trimite o captură de ecran la fiecare pas și poate primi informații detaliate despre starea paginii și rezultatul așteptat al fiecărei acțiuni posibile.

Extinde

Planificarea sarcinilor de cercetare

Întrebările utilizatorilor pot varia foarte mult în complexitate, la fel ca profunzimea căutării necesare pentru a găsi un răspuns. Decider poate estima acest lucru înainte de începerea căutării, permițând alocarea a mai puține resurse întrebărilor simple.

Extinde

Primii pași

Decider returnează probabilități. Pragul de decizie potrivit depinde de aplicație. Frecvențele etichetelor și costurile relative ale rezultatelor fals pozitive și fals negative variază de la un caz de utilizare la altul. Prin urmare, încurajăm utilizatorii să ajusteze pragurile pe un set de dezvoltare mic, reprezentativ și etichetat, în loc să presupună că un prag fix va funcționa la fel de bine pentru toate sarcinile.

Vă recomandăm să folosiți Decider v1.3 pentru judecăți nuanțate, criterii de evaluare detaliate și fluxuri de lucru în care erorile sunt costisitoare. Alegeți Decider Flash v1.3 pentru rutare, etichetare și filtrare la volum mare, unde latența și costul sunt principalele constrângeri. Evaluați ambele modele pe exemple reprezentative din volumul dvs. de lucru, apoi alegeți modelul care corespunde cerințelor dvs. de calitate, latență și buget.

Ambele modele sunt disponibile ca ponderi descărcabile pe Hugging Face, sub licență Apache, prin OpenRouter și prin Perplexity Decisions API.

Citare

@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}
}