Perplexity Decider

Presentem Decider v1.3 i Decider Flash v1.3, els successors dels nostres models de decisió anteriors: v1, v1.1, v1.2 i Flash v1.2.

Decider Flash v1.3 és un model més petit destil·lat a partir de Decider v1.3. Tots dos models estan disponibles a Hugging Face amb llicència Apache, a través d’OpenRouter i a la Perplexity Decisions API.

Perplexity Decider s’inspira en Jev, el System One Model de TypeSafe AI. Admet classificació binària i multiclasse amb etiquetes ordenades o no ordenades, i retorna probabilitats que les aplicacions poden fer servir per classificar, encaminar, ordenar i avaluar entrades.

Tots dos models v1.3 milloren el rendiment i la robustesa en una àmplia gamma de tasques de text i de visió gràcies a l’atenció bidireccional, unes dades d’entrenament més ben seleccionades i una recepta d’entrenament refinada. També presentem locate, una funció nova per destacar el contingut seleccionat en tasques de reconeixement d’entitats amb nom, identificació d’informació personal i resposta extractiva a preguntes.

En aquesta publicació expliquem com entrenem i avaluem Decider i compartim com el fem servir internament a Perplexity.

Què és un model de decisió?

Un model de decisió és un classificador d’ús general. Li proporciones una entrada i un conjunt de preguntes, cadascuna amb les seves respostes possibles. Per a cada pregunta, retorna una distribució de probabilitat sobre les respostes. Admet 3 tipus de preguntes:

• Sí / No: decisions binàries.
• Opció múltiple: etiquetes multiclasse personalitzades.
• Puntuació: nivells ordenats.

Els models de decisió admeten una àmplia varietat de tasques de classificació i puntuació:

• Avaluació de sortides: valoració de la fidelitat, la qualitat i la seguretat.
• Encaminament: dirigir les sol·licituds a models més petits o més grans segons la dificultat.
• Moderació i seguretat: detecció de contingut nociu, phishing i injecció de prompts en les sortides d’eines.
• Filtratge i etiquetatge: organització de grans col·leccions de contingut.
• Recuperació i reordenació: puntuació dels resultats de cerca segons la rellevància.

Moltes d'aquestes tasques les gestionaven abans models generatius com els LLM, tot i que no requereixen generació de text lliure. Els models de decisió se situen entre els LLM i els classificadors específics de tasques. Retornen probabilitats per a diverses preguntes sobre la mateixa entrada en una sola passada endavant, cosa que evita generar respostes token a token i permet compartir el càlcul entre preguntes. A diferència dels classificadors específics de tasques, poden gestionar tasques noves mitjançant prompts en llenguatge natural, una flexibilitat apresa en entrenar-se amb tasques diverses en un format compartit de preguntes i respostes.

Entrenament

Convertir un LLM generatiu en un model de decisió

Construïm Decider adaptant models troncals sòlids d'LLM generatius. Per explicar l'adaptació, primer descrivim com es representa una sol·licitud. Com es mostra a continuació, una sol·licitud consisteix en un context compartit (l'estat) i un nombre determinat de preguntes. Totes les preguntes reutilitzaran l'estat.

Per exemple, donat un document i el seu resum, una sola sol·licitud pot preguntar si el resum representa fidelment el document i si va adreçat a un públic expert o general. Després de l’estat, cada bloc de pregunta conté una pregunta i les seves respostes possibles, cadascuna amb un token d’etiqueta predefinit assignat, com ara A, B o C. Un token especial <|marker|> indica on s’ha de llegir la predicció del model. En aquesta posició, una capa de sortida lineal apresa (un capçal de decisió) converteix l’estat ocult en puntuacions per a les opcions de resposta de la pregunta, que després es transformen en probabilitats.

Amplia

Inicialitzem la capa de sortida a partir del model base, que normalment puntua el token següent sobre tot el vocabulari, i només conservem les files corresponents als tokens d’opció predefinits, com ara A, B o C. Aquesta capa podada s’entrena després per convertir l’estat ocult de <|marker|> en puntuacions de resposta. Aquest enfocament cobreix totes les preguntes de classificació, perquè totes es poden formular com a opció múltiple.

Per a l’entrenament, prenem centenars de conjunts de dades públics que abasten tasques diverses (sentiment, inferència en llenguatge natural, detecció d’intencions, coincidència d’entitats, moderació, verificació de fets, valoracions, etc.) i convertim cada exemple al format unificat descrit més amunt: un estat, una o més preguntes, les seves opcions i un objectiu. L’objectiu pot ser l’única opció correcta, si tenim etiquetes de referència, o una distribució de probabilitat sobre les opcions.

A la v1.3 presentem locate, que extreu text de l’estat en lloc de seleccionar entre opcions predefinides. Una pregunta de locate descriu què cal trobar, ja sigui amb una etiqueta breu com ara «ubicació» o amb una instrucció com ara «Extreu el nom de la ciutat on es troba la feina». El model retorna el text exacte coincident de l’estat, juntament amb les posicions dels caràcters inicial i final. Si no troba cap coincidència, retorna una llista buida.

Amplia

Com que l’estat és compartit, una sola sol·licitud pot combinar preguntes de locate, de classificació i de puntuació sobre la mateixa entrada. Per exemple, pot preguntar si una feina requereix experiència de nivell sènior i extreure’n les competències necessàries.

Atenció bidireccional: deixar que el model llegeixi en tots dos sentits

Els nostres models parteixen de backbones generatius preentrenats i sòlids, l’atenció causal dels quals permet que cada token atengui només a si mateix i als tokens anteriors. Els nostres estudis d’ablació van mostrar que fer bidireccionals les capes d’atenció completa del backbone millora el rendiment, de manera que adoptem aquest disseny perquè cada token incorpori context de tota l’entrada.

L’atenció bidireccional introdueix una altra decisió de disseny: com han d’interactuar l’estat i les preguntes? Vam considerar tres patrons d’atenció, amb implicacions diferents per al rendiment, l’estabilitat de les respostes i la reutilització de la memòria cau:

• Tot veu tot (v1.2): l’estat i totes les preguntes es processen conjuntament amb atenció bidireccional completa. El càlcul sobre l’estat es comparteix, però la resposta a una pregunta pot canviar segons què més es pregunti.
• Preguntes aïllades (v1.3): l’estat atén a totes les preguntes, mentre que cada pregunta atén només a l’estat i als seus propis tokens. Les preguntes encara es poden influir indirectament a través de l’estat compartit, però els resultats són més estables.
• Totalment emmagatzemable a la memòria cau: L'estat només presta atenció a si mateix, mentre que cada pregunta presta atenció a l'estat i als seus propis tokens. L'estat és independent de les preguntes i es pot reutilitzar entre sol·licituds per aprofitar la memòria cau de prompts. No l'utilitzem per defecte, perquè permetre que l'estat vegi les preguntes és molt important per a diverses tasques, però un petit ajust fi pot fer que un model passi a fer-lo servir.

Finalment, vam triar les preguntes aïllades pel seu bon rendiment i la seva estabilitat.

Amplia

Recepta d’entrenament

L'entrenament es fa en tres etapes per a totes dues mides de model. Primer entrenem el model més gran, basat en Qwen3.8-27B, amb entropia creuada sobre grans conjunts de dades, i després el destil·lem al model més petit, Qwen3.5-4B.

La primera etapa és l’entrenament generalista, en què fem un ajustament fi complet del model amb corpus a gran escala. En aquesta etapa, només acceptem dades que ajudin el model de manera general i que no siguin específiques de cap banc de proves; per tant, excloem qualsevol partició d’entrenament dels bancs de proves.

Un cop entrenat aquest model generalista, executem una segona etapa, més detallada, amb LoRA. Les dades que s'utilitzen en aquesta etapa estan orientades a dominis i tasques específics. Afegim dades a la segona etapa en lloc de la primera si observem millores limitades o si observem algunes regressions en altres tasques. Utilitzem LoRA per evitar allunyar-nos massa del model generalista i arriscar-nos a perdre rendiment per ajustar-nos a aquests dominis específics. L'objectiu és millorar el rendiment tot conservant el coneixement general del model troncal. També apliquem un pes en fusionar el LoRA de nou amb el model base, per controlar la deriva amb més precisió i prioritzar les mètriques sobre dades reservades per sobre de qualsevol millora dins del domini.

Finalment, afegim un pas específic per a la visió. De manera similar a la segona etapa, el pas de visió es tracta com un altre pas d’especialització detallada, amb un adaptador LoRA que es torna a fusionar amb el model base amb un pes. Algunes capacitats de visió poden tenir un cost en el rendiment amb text. Com que observem un ús dels models molt més gran en text, prioritzem les mètriques de text per sobre de les de visió.

En ambdues etapes de text, fem servir la mitjana dels pesos de tres execucions, cadascuna amb una llavor aleatòria diferent. Hem comprovat que això millora el rendiment i la robustesa del model agregat.

Un cop obtingut el model gran final, apliquem el mateix procediment d'entrenament en tres etapes al model més petit. Aquí, el model gran fa de professor: la distribució de sortida que prediu substitueix les etiquetes de referència, i el model més petit s'entrena per minimitzar la divergència KL entre les seves prediccions i les del professor. Aquest objectiu de destil·lació supera l'entropia creuada amb les mateixes dades d'entrenament. Tot i que l'entropia creuada té un millor rendiment en benchmarks amb dades d'entrenament dedicades, generalitza pitjor a dades reservades. La nostra hipòtesi és que la destil·lació transfereix millor la distribució de sortida del professor, inclosa la seva confiança en alternatives que no són de referència, mentre que l'entropia creuada afavoreix el sobreajustament a la distribució d'entrenament específica de cada benchmark. Per tant, adoptem l'objectiu de destil·lació basat en KL.

Per mitigar la contaminació entre entrenament i prova, eliminem qualsevol mostra d'entrenament que es pugui solapar amb qualsevol de les avaluacions que fem servir. Això és important perquè alguns conjunts de dades d'entrenament públics contenen grans parts d'alguns conjunts de dades d'avaluació. També fem auditories exhaustives de biaixos i n'eliminem per assegurar-nos que les nostres millores són fiables i no es deuen simplement a biaixos apresos.

Afegir la capacitat d'extreure informació

La funció locate extreu informació d’un text, com ara entitats amb nom, sense canviar la manera com respon a les sol·licituds habituals. Per fer-ho, introduïm una etapa d’entrenament addicional: afegim a Decider un token especial nou, <|locate|>, un capçal de fragments i un adaptador LoRA.

Inicialitzem l’embedding de <|locate|> a partir de <|marker|>, après en les etapes d’entrenament anteriors. Entrenem només aquest embedding nou, el capçal de fragments i els adaptadors LoRA, i mantenim congelats els pesos originals del backbone i el capçal de decisió. Cada camp sol·licitat té el seu propi token <|locate|>.

El capçal de segments utilitza la representació de <|locate|> juntament amb les representacions dels tokens d'estat per puntuar on comencen i acaben els segments coincidents, i quins parells d'inici i final van junts. També utilitza la representació del token <|locate|> per predir llindars específics de cada camp per a aquestes puntuacions. Els segments seleccionats es retornen com a posicions de caràcter en el text original.

Entrenem el capçal de segments amb una pèrdua InfoNCE adaptada que situa cada segment de referència per sobre del llindar, i el llindar per sobre de qualsevol altre segment. La pèrdua té dos termes: el primer situa les puntuacions dels segments correctes per sobre del llindar i dels segments incorrectes. El segon terme situa el llindar per sobre de les puntuacions dels segments incorrectes. Els camps sense resposta només reben el segon terme, cosa que ensenya al model a retornar una llista buida.

Entrenem amb una combinació de tasques d’extracció de fragments, com ara reconeixement d’entitats amb nom, detecció de PII i resposta extractiva a preguntes. Variem les descripcions dels camps, des d’etiquetes breus fins a instruccions detallades, perquè el model aprengui a seguir la sol·licitud en lloc de memoritzar un conjunt fix d’etiquetes.

Locate ensenya al model una tasca estructuralment diferent, i volem afegir-la sense perdre allò que el model ja fa bé. Fusionar els adaptadors de locate amb el model troncal provoca certa regressió en les sol·licituds de decisió. Per limitar-ho, estem investigant opcions com ara més dades de repetició d'etapes anteriors i objectius auxiliars que mantinguin les sortides del model en sol·licituds de decisió properes a les del model original. Tanmateix, constatem que, de moment, la fusió encara no és sense pèrdues, de manera que mantenim els adaptadors sense fusionar i només els activem per a les sol·licituds de locate.

Avaluació

Avaluem Decider v1.3 i Decider Flash v1.3 en benchmarks externs de l'Hugging Face Decision Index, el ClaimBench de Vals AI i l'Artificial Analysis Decision Index.

En aquestes avaluacions, els nostres models mostren un rendiment sòlid. Tot i que aquestes classificacions inclouen tasques privades, encara es poden manipular mitjançant enviaments repetits i ajustos iteratius basats en els resultats de la classificació. Per complementar aquestes classificacions, avaluem els models amb un conjunt intern que combina tasques de producció privades amb avaluacions reservades extretes de conjunts de dades públics que no són benchmarks. Aquestes avaluacions proporcionen una comprovació addicional de la generalització més enllà dels benchmarks públics i ens ajuden a distingir les millores més àmplies de les millores específiques de conjunts d'avaluació coneguts.

Internament, hem creat un conjunt de més de 200 tasques que abasten diversos dominis i tipus de tasca, com ara classificació, puntuació, reordenació i extracció d’entitats. Per avaluar amb honestedat el rendiment real de Decider, totes les avaluacions es fan en mode zero-shot, sense ajustament fi específic per a cada tasca, cosa que ens dona una indicació clara de què cal millorar del model.

Classificació de consultes

A Perplexity fem servir un sistema de classificació multicapçal per processar cada consulta dels usuaris. Primer, cada consulta passa per un model d’embeddings que actua com a extractor de característiques. A continuació, l’embedding resultant s’introdueix en diversos capçals de classificació independents, que inclouen tant classificadors binaris com multietiqueta. Per exemple, un capçal determina si una consulta de l’usuari ha d’activar una cerca web.

En 63 tasques de classificació amb referències reetiquetades de manera independent per un LLM de frontera, Decider v1.3 assoleix una exactitud mitjana del 91,6 % i supera els nostres classificadors de producció en 6,54 punts percentuals. Decider Flash v1.3 també supera la referència de producció, mentre que Decider v1.3 supera Jev 1.14.

Amplia

Classificació específica per dominis

Hem reunit un conjunt d’avaluació específic per dominis a partir de conjunts de dades públics per avaluar el rendiment de classificació dels models de decisió en set dominis: verificació d’afirmacions (6 tasques), salut (7), ciberseguretat (8), programació (16), administració pública (7), dret (9) i finances (9).

Per exemple, «jutja la complexitat temporal d’un programa en Python» o «fes servir un informe financer anual per determinar si l’efectiu no restringit d’una empresa cobreix el principal del deute que venç en els pròxims dotze mesos». Decider v1.3 lidera en els set dominis i supera Jev 1.14 en fins a 12,9 punts percentuals en finances i 9,3 punts en dret. Decider Flash v1.3 queda per darrere de Jev 1.14 en finances, programació i dret, i té un rendiment similar en els altres dominis.

Amplia

Recuperació i reordenació

La cerca és el nucli de Perplexity. Mantenim un ampli conjunt de tasques de recuperació per avaluar el rendiment de reordenació dels nostres models. Per a cada tasca, primer fem servir un conjunt de models d’embeddings per recuperar els 50 documents candidats principals de cada corpus. Després reordenem aquests candidats amb Decider i en comparem el rendiment amb un reordenador de referència potent, Qwen3-Reranker-8B.

Avaluem Decider en un entorn zero-shot i puntual (pointwise): fem servir el model per puntuar directament cada parell consulta–document de manera independent i ordenem els documents per rellevància. En 72 tasques de recuperació, Decider v1.3 assoleix un nDCG@10 mitjà de 83,99 i supera Qwen3-Reranker-8B en 1,81 punts i Jev 1.14 en 2,24 punts.

Al banc de proves BEIR, tots dos models superen Qwen3-Reranker-8B en 8,78 i 7,05 punts de nDCG@10, respectivament. Respecte a Jev 1.14, Decider v1.3 obté 1,33 punts més, mentre que la versió Flash puntua 0,4 punts menys.

Amplia

Classificació multilingüe

Per avaluar els models de decisió més enllà de l’anglès, hem reunit un banc de proves de classificació multilingüe format per 19 tasques específiques de cada llengua procedents de 8 conjunts de dades públics, amb 46.484 exemples en vuit llengües: alemany, espanyol, francès, italià, rus, japonès, coreà i xinès. El banc de proves cobreix detecció d’intencions, classificació temàtica, anàlisi de sentiment, inferència en llenguatge natural, detecció de paràfrasis, detecció de llenguatge ofensiu i acceptabilitat gramatical.

Informem de l’exactitud mitjana de les tasques de cada llengua, amb el mateix pes per a cada tasca. Decider v1.3 supera Jev 1.14 en les vuit llengües i Decider Flash v1.3 ho fa en sis, amb exactituds mitjanes per tasca del 88,16 % per a Decider v1.3 i del 86,50 % per a Decider Flash v1.3, en comparació amb el 85,41 % de Jev 1.14.

Amplia

NER, PII i QA extractiva

Avaluem la funció locate en 17 tasques fora de domini que posen a prova la capacitat d’extracció en diversos dominis, formats d’entrada (text, taules, documents estructurats) i instruccions (etiquetes breus, preguntes i descripcions detallades). Els dominis van des de Wikipedia fins a articles científics, informes de ciberamenaces, suport tècnic, polítiques de privadesa, currículums i contractes legals. Les sol·licituds van des de noms d’etiqueta breus com ara «persona» o «adreça electrònica», passant per preguntes sobre una taula o una incidència de suport, fins a descripcions detallades de camps per a l’extracció estructurada, com ara les parts d’un acord de confidencialitat (NDA) o l’import total d’una factura.

Avaluem el NER i la PII amb l'F1 de segment exacte, que requereix que els segments predits coincideixin exactament amb els límits de referència. La QA extractiva utilitza l'F1 a nivell de caràcter, que atorga crèdit parcial al text de resposta que se superposa, mentre que l'extracció estructurada utilitza la precisió per camp, és a dir, la proporció de camps extrets correctament. Per a l'anàlisi de CV, fem la mitjana de les puntuacions F1 de segment exacte de NER i PII.

Comparem els nostres models amb models d’extracció d’ús general de diverses mides: GLiNER large v2.5 (0,5B), Liquid d1 (2B) i Clairic de Cloudflare (mida no revelada). Decider v1.3 assoleix una puntuació mitjana de 69,0 (amb la mètrica principal de cada tasca) i Decider Flash v1.3 arriba a 63,6, en comparació amb 43,3 de Liquid d1, 41,5 de Clairic i 33,6 de GLiNER large v2.5. Tots dos models Decider lideren en totes les categories.

Amplia

Classificació d'imatges

Decider admet de manera nativa tasques de visió des de la v1. Per avaluar-ne el rendiment més enllà del text, hem reunit un conjunt de proves de cinc tasques amb un èmfasi especial en la classificació de documents, com ara factures, cartes i currículums. El conjunt també inclou classificació d’imatges de satèl·lit, classificació de textures, classificació de races de mascotes i recompte d’animals.

Decider v1.3 assoleix una exactitud mitjana del 76,99 % en les cinc tasques visuals i supera Jev 1.14 en 1,47 punts percentuals. Decider Flash v1.3 arriba al 72,77 %, cosa que demostra capacitats de classificació visual en un model més petit.

Amplia

Sol·licituds de decisió reals

Vam prendre una mostra d’un milió de sol·licituds deduplicades i amb la PII emmascarada enviades a la Perplexity Decision API durant els primers 18 dies de disponibilitat. Com que cada sol·licitud pot contenir diverses preguntes sobre el mateix estat, la mostra inclou 2.318.887 preguntes individuals. Totes les sol·licituds es van incloure amb el permís explícit dels usuaris per a finalitats d’investigació.

Les sol·licituds de producció no inclouen etiquetes de referència verificades, de manera que fem servir LLM de frontera com a jutges per generar respostes de referència i mesurem el grau d’acord de cada model amb aquestes respostes. També agrupem les sol·licituds en 10 categories de tasques: extracció d’informació, classificació per dominis, anàlisi de sentiment, intenció i encaminament, ordenació per rellevància, moderació de contingut, revisió de qualitat i compliment normatiu, coincidència d’entitats, anàlisi empresarial i una categoria «Altres». Aquest desglossament mostra com varia el rendiment segons els casos d’ús reals.

La combinació de tasques és desigual: l’extracció d’informació representa 425.402 preguntes; la classificació per dominis, 409.564; i l’anàlisi de sentiment, 344.158. En conjunt, aquestes tres categories constitueixen el 50,8 % de les preguntes de la mostra.

Decider v1.3 assoleix el grau d’acord més alt amb els jutges, amb un 93,98 %, en comparació amb el 93,68 % de Decider v1.2 i el 93,35 % de Jev 1.14. Decider v1.3 i Jev 1.14 estan molt igualats en classificació per dominis i anàlisi de sentiment, amb diferències de 0,34 i 0,07 punts percentuals, respectivament. Jev va al davant per 0,69 punts en ordenació per rellevància, mentre que Decider v1.3 va al davant per 0,93 punts en extracció d’informació (la tasca més habitual de la mostra) i per 1,21 punts en intenció i encaminament.

Amplia

El gràfic següent compara el cost declarat d’executar el mateix milió de sol·licituds de producció. Cada sol·licitud pot contenir diverses preguntes, de manera que aquí la unitat són les sol·licituds, no les preguntes individuals.

Amplia

Robustesa

Vam avaluar la sensibilitat a les etiquetes amb 372 preguntes d’opció múltiple, amb 4.788 sol·licituds per model. Vam reordenar les opcions, reassignar les etiquetes als textos de resposta i canviar el nom de les etiquetes tot preservant el significat de cada pregunta, i després vam comprovar si la resposta semàntica del model canviava. Unes taxes de canvi més baixes indiquen més estabilitat.

Decider v1.3 va canviar la resposta en només el 0,27 % de les preguntes amb cada transformació, en comparació amb un percentatge d’entre el 2,69 % i el 4,84 % de Jev 1.14. També vam repetir entrades idèntiques per mesurar la variabilitat del servei: Decider v1.3 no va mostrar cap canvi, mentre que Jev 1.14 va canviar en l’1,88 % de les preguntes.

Amplia

Com fem servir Decider

Decider està pensat per a fluxos de treball que necessiten decisions ràpides i estructurades. En aquesta secció explorem com aprofitar-lo per tenir un impacte significatiu en la nostra manera de treballar. Aquests són alguns dels usos que més destaquen.

Regles de seguretat que milloren per si soles

Internament, ja utilitzem Decider per millorar les nostres polítiques de seguretat.

L’activitat dels nostres agents queda registrada i s’hi apliquen un seguit de comprovacions basades en regles per identificar qualsevol comportament problemàtic. Un enfocament basat en regles ens permet supervisar els agents en temps real amb una latència addicional insignificant. Fora de línia, fem servir Decider per examinar mostres d’aquests registres d’agents. Si no s’ha detectat cap comportament problemàtic, Decider comprova si hi ha alguna cosa que el nostre conjunt de regles hagi passat per alt; i si s’ha disparat una alarma, Decider comprova si era una falsa alarma. Tots els registres en què el conjunt de regles falla en qualsevol dels dos casos s’envien a un agent perquè els classifiqui i proposi una correcció de les regles, que ha d’aprovar un membre del nostre equip de seguretat.

En un sol dia, Decider va llegir 1.000 milions de tokens en 7.000 sessions d’agent i va identificar defectes que van donar lloc a 14 correccions de regles, 6 de les quals es van aprovar i desplegar en dos dies. En reproduir-les sobre una setmana de registres, les correccions van reduir un 52 % el volum de la nostra regla més activa, i les regles ampliades van detectar aproximadament un 40 % més d’accions legítimes per investigar.

Amplia

Supervisió de rollouts d’RL

Quan fem el postentrenament de models amb aprenentatge per reforç, les mètriques agregades, com ara una recompensa final, no expliquen per què un rollout (un intent individual de dur a terme una tasca) ha tingut èxit o ha fallat. Pot perdre recompensa injustament perquè ha fallat un servei d’eines o l’entorn de proves, o rebre una recompensa immerescuda si l’avaluador passa per alt una afirmació sense fonament, com ara un valor inventat que cap eina no ha retornat.

Fem servir Decider per supervisar els rollouts en aquests casos. Primer, el codi identifica les parts d’un rollout que mereixen una inspecció més detallada: una crida a una eina que ha fallat i el raonament que l’envolta, codi que s’ha executat sense errors o la resposta final. Després, Decider respon preguntes d’opció múltiple sobre cada part, com ara què ha fallat en un pas (un servei d’eines, un lloc extern, l’entorn de proves, el harness o el codi del mateix agent) i si l’agent ha interpretat correctament el resultat. Agrupem totes les preguntes sobre una part determinada en una sola sol·licitud i desem les probabilitats en lloc d’un veredicte, de manera que puguem ajustar els llindars més endavant sense tornar a consultar Decider. El monitor només observa i diagnostica: mai no canvia una recompensa ni atura una execució.

Amplia

Filtratge de pàgines per qualitat

Quan rastregem pàgines web per indexar-les i servir-les als usuaris, moltes tenen massa poca qualitat per ser útils. Això inclou murs antibots, CAPTCHA i pàgines d’error, així com pàgines web que es carreguen correctament però que no contenen cap informació útil, com ara contingut brossa, farciment per a SEO o pàgines que només serveixen per navegar. Cal identificar aquestes pàgines de baixa qualitat i filtrar-les del nostre índex.

Amb Decider, podem jutjar la qualitat de les pàgines a mesura que les rastregem. En la mateixa passada endavant, duem a terme un conjunt d'altres tasques de classificació, com ara identificar el domini i el públic objectiu del contingut i determinar si conté informació nociva, il·legal o d'identificació personal. En comparació amb l'ús d'un LLM com a jutge, Decider és considerablement més ràpid i econòmic.

Amplia

A més d’aquests usos interns, Decider també s’adapta a fluxos de treball com els següents.

Preguntes i respostes visuals

Com que Decider llegeix imatges, també funciona com a verificador visual: revisa canvis d’estil en pàgines web o aplicacions i n’identifica els errors. Pot revisar captures de pantalla de pàgines per detectar text retallat, elements superposats o dissenys trencats abans de publicar un canvi, o assenyalar gràfics el disseny dels quals podria induir a error el lector o incomplir una guia de marca.

Amplia

Navegació web

Els agents poden fer servir Decider per a les decisions petites dins de tasques més grans. Un agent de navegador pot enviar una captura de pantalla a cada pas i rebre informació detallada sobre l’estat de la pàgina i el resultat esperat de cada acció possible.

Amplia

Planificació de tasques d’investigació

La complexitat de les preguntes dels usuaris pot variar molt, igual que la profunditat de la cerca que cal fer per trobar-hi una resposta. Decider pot estimar-ho abans que comenci la cerca, cosa que permet dedicar menys recursos a les preguntes senzilles.

Amplia

Primers passos

Decider retorna probabilitats. El llindar de decisió adequat depèn de l’aplicació. Les freqüències de les etiquetes i els costos relatius dels falsos positius i els falsos negatius varien segons el cas d’ús. Per això, recomanem als usuaris que ajustin els llindars amb un conjunt de desenvolupament etiquetat petit i representatiu, en lloc de suposar que un punt de tall fix funcionarà igual de bé en totes les tasques.

Recomanem utilitzar Decider v1.3 per a judicis matisats, rúbriques detallades i fluxos de treball en què els errors són costosos. Trieu Decider Flash v1.3 per a l'encaminament, l'etiquetatge i el filtratge de gran volum, en què la latència i el cost són les principals limitacions. Avalueu tots dos models amb exemples representatius de la vostra càrrega de treball i, després, trieu el model que compleixi els vostres requisits de qualitat, latència i pressupost.

Tots dos models estan disponibles com a pesos descarregables a Hugging Face amb llicència Apache, a través d’OpenRouter i a la Perplexity Decisions API.

Citació

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