Perplexity Decider

Vi lanserer Decider v1.3 og Decider Flash v1.3, etterfølgerne til våre tidligere beslutningsmodeller: v1, v1.1, v1.2 og Flash v1.2.

Decider Flash v1.3 er en mindre modell destillert fra Decider v1.3. Begge modellene er tilgjengelige på Hugging Face under Apache-lisens, via OpenRouter og gjennom Perplexity Decisions API.

Perplexity Decider er inspirert av Jev, TypeSafe AIs System One Model. Den støtter binær klassifisering og flerklasseklassifisering med ordnede eller uordnede etiketter, og returnerer sannsynligheter som applikasjoner kan bruke til å klassifisere, rute, rangere og evaluere inndata.

Begge v1.3-modellene forbedrer ytelse og robusthet på tvers av et bredt spekter av tekst- og bildeoppgaver gjennom toveis oppmerksomhet, bedre kuraterte treningsdata og en forbedret treningsoppskrift. Vi introduserer også locate, en ny funksjon som fremhever det valgte innholdet for navngitt entitetsgjenkjenning, identifisering av personopplysninger og ekstraktive spørsmål-svar-oppgaver.

I dette innlegget forklarer vi hvordan vi trener og evaluerer Decider, og deler hvordan vi bruker den internt hos Perplexity.

Hva er en beslutningsmodell?

En beslutningsmodell er en generell klassifikator. Du gir den inndata og et sett med spørsmål, hvert med sine mulige svar. For hvert spørsmål returnerer den en sannsynlighetsfordeling over svarene. Den støtter 3 spørsmålstyper:

• Ja / Nei: binære beslutninger.
• Flervalg: egendefinerte etiketter med flere klasser.
• Poengsum: ordnede nivåer.

Beslutningsmodeller støtter et bredt spekter av klassifiserings- og poengsettingsoppgaver:

• Vurdering av utdata: evaluering av kildetroskap, kvalitet og sikkerhet.
• Ruting: dirigering av forespørsler til mindre eller større modeller basert på vanskelighetsgrad.
• Moderering og sikkerhet: oppdagelse av skadelig innhold, phishing og prompt injection i verktøyutdata.
• Filtrering og tagging: organisering av store innholdssamlinger.
• Gjenfinning og omrangering: poengsetting av søkeresultater etter relevans.

Mange av disse oppgavene ble tidligere håndtert av generative modeller som LLM-er, selv om de ikke krever fri tekstgenerering. Beslutningsmodeller plasserer seg mellom LLM-er og oppgavespesifikke klassifikatorer. De returnerer sannsynligheter for flere spørsmål om de samme inndataene i én enkelt foroverpassering, slik at de unngår å generere svar token for token og deler beregninger på tvers av spørsmålene. I motsetning til oppgavespesifikke klassifikatorer kan de håndtere nye oppgaver via prompter i naturlig språk, en fleksibilitet de har lært gjennom trening på varierte oppgaver i et felles spørsmål-svar-format.

Trening

Slik gjør vi en generativ LLM om til en beslutningsmodell

Vi bygger Decider ved å tilpasse sterke generative LLM-ryggrader. For å forklare tilpasningen beskriver vi først hvordan en forespørsel representeres. Som vist nedenfor består en forespørsel av en delt kontekst (tilstanden) og et antall spørsmål. Tilstanden gjenbrukes av alle spørsmålene.

Gitt for eksempel et dokument og sammendraget av det, kan én enkelt forespørsel spørre om sammendraget gjengir dokumentet korrekt, og om det er ment for en ekspert eller et allment publikum. Etter tilstanden inneholder hver spørsmålsblokk et spørsmål og de mulige svarene, som hvert er tildelt et forhåndsdefinert etikett-token som A, B eller C. Et spesielt <|marker|>-token angir hvor modellens prediksjon skal leses ut. I denne posisjonen tilordner et lært lineært utdatalag (et beslutningshode) den skjulte tilstanden til poengsummer for spørsmålets svaralternativer, som deretter konverteres til sannsynligheter.

Forstørr

Vi initialiserer utdatalaget fra basismodellen, som vanligvis gir poengsum til neste token fra hele vokabularet, og beholder bare radene som tilsvarer de forhåndsdefinerte alternativ-tokenene som A, B eller C. Dette beskårne laget trenes deretter til å gjøre den skjulte tilstanden til <|marker|> om til svarpoeng. Denne tilnærmingen dekker alle klassifiseringsspørsmål, fordi de alle kan formuleres som flervalg.

Til treningen tar vi hundrevis av offentlige datasett som spenner over ulike oppgaver (sentiment, naturlig språkinferens, intensjonsgjenkjenning, entitetsmatching, moderering, faktasjekk, vurderinger osv.) og konverterer hvert eksempel til det enhetlige formatet beskrevet ovenfor: en tilstand, ett eller flere spørsmål, svaralternativene deres og et mål. Målet kan være det ene riktige alternativet hvis vi har gullstandardetiketter, eller en sannsynlighetsfordeling over alternativene.

I v1.3 introduserer vi locate, som trekker ut tekst fra tilstanden i stedet for å velge blant forhåndsdefinerte alternativer. Et locate-spørsmål beskriver hva som skal finnes, enten med en kort etikett som «sted» eller en instruksjon som «Trekk ut navnet på byen der jobben ligger.» Modellen returnerer den nøyaktig samsvarende teksten fra tilstanden, sammen med start- og sluttposisjonen for tegnene. Hvis den ikke finner noen treff, returnerer den en tom liste.

Forstørr

Takket være delt tilstand kan én enkelt forespørsel kombinere locate-, klassifiserings- og poengsettingsspørsmål om de samme inndataene. Den kan for eksempel spørre om en jobb krever erfaring på seniornivå, og trekke ut de nødvendige ferdighetene.

Toveis oppmerksomhet: modellen leser i begge retninger

Modellene våre tar utgangspunkt i sterke forhåndstrente generative ryggrader, der kausal oppmerksomhet lar hvert token rette oppmerksomheten bare mot seg selv og foregående tokens. Ablasjonsstudiene våre viste at det å gjøre ryggradens lag med full oppmerksomhet toveis forbedrer ytelsen, så vi tar i bruk denne utformingen slik at hvert token kan inkorporere kontekst fra hele inndataen.

Toveis oppmerksomhet medfører et annet designvalg: Hvordan skal tilstanden og spørsmålene samhandle? Vi vurderte tre oppmerksomhetsmønstre med ulike konsekvenser for ytelse, svarstabilitet og gjenbruk av hurtigbuffer:

• Alt ser alt (v1.2): Tilstanden og alle spørsmålene behandles sammen med full toveis oppmerksomhet. Beregningen over tilstanden deles, men svaret på ett spørsmål kan endre seg avhengig av hva annet som spørres om.
• Isolerte spørsmål (v1.3): Tilstanden retter oppmerksomheten mot alle spørsmålene, mens hvert spørsmål bare retter oppmerksomheten mot tilstanden og sine egne tokens. Spørsmål kan fortsatt påvirke hverandre indirekte gjennom den delte tilstanden, men resultatene er mer stabile.
• Fullt hurtigbufferbar: Tilstanden har bare oppmerksomhet mot seg selv, mens hvert spørsmål har oppmerksomhet mot tilstanden og sine egne tokener. Tilstanden er uavhengig av spørsmålene og kan gjenbrukes på tvers av forespørsler for å dra nytte av prompt-hurtigbufring. Vi bruker ikke dette som standard, fordi det betyr mye for flere oppgaver at tilstanden kan se spørsmålene, men en liten finjustering kan få en modell over på denne varianten.

Til slutt valgte vi isolerte spørsmål på grunn av den sterke ytelsen og stabiliteten.

Forstørr

Treningsoppskrift

Treningen foregår i tre trinn for begge modellstørrelsene. Vi trener først den større modellen, basert på Qwen3.8-27B, med kryssentropi på store datasett, og destillerer den deretter inn i den mindre Qwen3.5-4B-modellen.

Det første trinnet er generalisttrening, der vi finjusterer hele modellen på store korpus. I dette trinnet godtar vi bare data som hjelper modellen over hele linjen og ikke er spesifikke for noen referansetest; vi utelater derfor alle treningsdelinger fra referansetester.

Etter at denne generalistmodellen er trent, kjører vi et andre, mer finkornet trinn med LoRA. Dataene som brukes i dette trinnet, er rettet mot spesifikke domener og oppgaver. Vi legger til data i andre trinn i stedet for det første hvis vi ser smale forbedringer, eller hvis vi ser regresjoner på andre oppgaver. Vi bruker LoRA for å unngå å drive for langt bort fra generalistmodellen og risikere å miste ytelse for å tilpasse oss disse spesifikke domenene. Målet er å forbedre ytelsen samtidig som ryggradens generelle kunnskap bevares. Vi bruker også en vekt når vi fletter LoRA-en tilbake inn i grunnmodellen, for å styre avdriften mer presist og prioritere metrikker på tilbakeholdte data fremfor eventuelle forbedringer innenfor domenet.

Til slutt legger vi til et bildespesifikt trinn. I likhet med det andre trinnet behandles bildetrinnet som enda et finkornet spesialiseringstrinn, med en LoRA-adapter som slås sammen med basismodellen igjen med en vekt. Enkelte bildeegenskaper kan gå på bekostning av tekstytelsen. Siden vi ser mye mer bruk av modellene på tekst, prioriterer vi tekstmålinger fremfor bildemålinger.

For begge teksttrinnene bruker vi gjennomsnittsvektene fra tre kjøringer, hver med et ulikt tilfeldig frø. Vi fant at dette forbedrer ytelsen og robustheten til den aggregerte modellen.

Når den endelige store modellen er klar, bruker vi den samme tretrinns treningsprosedyren på den mindre modellen. Her fungerer den store modellen som lærer: Den predikerte utdatafordelingen dens erstatter fasitetikettene, og den mindre modellen trenes til å minimere KL-divergensen mellom sine egne prediksjoner og lærerens. Dette destillasjonsmålet gir bedre resultater enn kryssentropi på de samme treningsdataene. Selv om kryssentropi gir bedre resultater på referansetester med egne treningsdata, generaliserer den dårligere til tilbakeholdte data. Vi antar at destillasjon bedre overfører lærerens utdatafordeling, inkludert konfidensen for alternativer utenom fasiten, mens kryssentropi fremmer overtilpasning til den referansetestspesifikke treningsfordelingen. Vi tar derfor i bruk det KL-baserte destillasjonsmålet.

For å redusere kontaminering mellom trening og test fjerner vi alle treningseksempler som kan overlappe med noen av evalueringene vi bruker. Dette er viktig fordi enkelte offentlige treningsdatasett inneholder store deler av enkelte evalueringsdatasett. Vi gjennomfører også omfattende revisjoner og fjerning av skjevheter for å sikre at forbedringene våre er pålitelige og ikke bare drevet av innlærte skjevheter.

Legge til evnen til å trekke ut informasjon

Funksjonen locate trekker ut informasjon, for eksempel navngitte entiteter, fra tekst uten å endre hvordan den svarer på vanlige forespørsler. For å få til dette introduserer vi et ekstra treningstrinn: Vi legger til et nytt spesialtoken, <|locate|>, et span-hode og en LoRA-adapter i Decider.

Vi initialiserer embeddingen til <|locate|> fra <|marker|>, som ble lært i de foregående treningstrinnene. Vi trener bare denne nye embeddingen, span-hodet og LoRA-adapterne, mens de opprinnelige vektene i ryggraden og beslutningshodet holdes frosne. Hvert forespurt felt får sitt eget <|locate|>-token.

Span-hodet bruker representasjonen til <|locate|> sammen med representasjonene av tilstandstokenene for å gi poengsummer for hvor samsvarende spenn starter og slutter, og hvilke start–slutt-par som hører sammen. Det bruker også representasjonen til <|locate|>-tokenet til å forutsi feltspesifikke terskler for disse poengsummene. Valgte spenn returneres som tegnposisjoner i originalteksten.

Vi trener span-hodet med et tilpasset InfoNCE-tap som skyver hvert fasitspenn over terskelen, og terskelen over alle andre spenn. Tapet har to ledd: Det første skyver poengsummene for riktige spenn over terskelen og de gale spennene. Det andre leddet skyver terskelen over poengsummene for gale spenn. Felt uten svar får bare det andre leddet, noe som lærer modellen å returnere en tom liste.

Vi trener på en blanding av oppgaver for uttrekk av tekstsegmenter, inkludert navngitt entitetsgjenkjenning, PII-gjenkjenning og ekstraktiv spørsmålsbesvarelse. Vi varierer feltbeskrivelsene fra korte etiketter til detaljerte instruksjoner, slik at modellen lærer å følge forespørselen i stedet for å memorere et fast sett med etiketter.

Locate lærer modellen en strukturelt annerledes oppgave, og vi vil legge den til uten å miste det modellen allerede gjør godt. Når locate-adapterne flettes inn i ryggraden, gir det en viss regresjon på beslutningsforespørsler. For å begrense dette undersøker vi blant annet mer replay-data fra tidligere trinn og hjelpemål som holder modellens utdata for beslutningsforespørsler nær den opprinnelige modellens. Vi ser imidlertid at fletting foreløpig ikke er tapsfri, så vi fletter ikke inn adapterne, men aktiverer dem bare for locate-forespørsler.

Evaluering

Vi evaluerer Decider v1.3 og Decider Flash v1.3 på eksterne referansetester fra Hugging Face Decision Index, ClaimBench fra Vals AI og Artificial Analysis Decision Index.

På tvers av disse evalueringene viser modellene våre sterk ytelse. Selv om disse rangeringslistene inkluderer ikke-offentlige oppgaver, kan de fortsatt manipuleres gjennom gjentatte innsendinger og iterativ justering basert på tilbakemeldinger fra rangeringslisten. Som et supplement til disse rangeringslistene evaluerer vi modellene på en intern pakke som kombinerer private produksjonsoppgaver med tilbakeholdte evalueringer hentet fra offentlige datasett som ikke er referansetester. Disse evalueringene gir en ekstra kontroll av generalisering utover offentlige referansetester, og hjelper oss med å skille bredere forbedringer fra gevinster som er spesifikke for kjente evalueringspakker.

Internt har vi bygget en samling på mer enn 200 oppgaver som spenner over ulike domener og oppgavetyper, som klassifisering, poengsetting, omrangering og entitetsuttrekk. For å gi en ærlig vurdering av Deciders ytelse i praksis utføres alle evalueringer zero-shot, uten oppgavespesifikk finjustering, noe som gir oss et tydelig signal om hvor modellen bør forbedres.

Klassifisering av spørringer

Hos Perplexity bruker vi et klassifiseringssystem med flere hoder til å behandle hver brukerspørring. Hver spørring sendes først gjennom en embeddingmodell som fungerer som egenskapsuttrekker. Den resulterende embeddingen mates deretter inn i flere separate klassifiseringshoder, inkludert både binære klassifikatorer og fleretikettklassifikatorer. For eksempel avgjør ett hode om en brukerspørring skal utløse et nettsøk.

På tvers av 63 klassifiseringsoppgaver med referanser som er uavhengig ometikettert av en ledende LLM, oppnår Decider v1.3 en gjennomsnittlig nøyaktighet på 91,6 % og overgår produksjonsklassifikatorene våre med 6,54 prosentpoeng. Decider Flash v1.3 overgår også produksjonsreferansen, mens Decider v1.3 overgår Jev 1.14.

Forstørr

Domenespesifikk klassifisering

Vi satte sammen en domenespesifikk evalueringssamling fra offentlige datasett for å vurdere beslutningsmodellers klassifiseringsytelse på tvers av sju domener: påstandsverifisering (6 oppgaver), helse (7), cybersikkerhet (8), programmering (16), offentlig forvaltning (7), juss (9) og finans (9).

For eksempel «vurder tidskompleksiteten til et Python-program» eller «bruk en årsrapport til å avgjøre om et selskaps frie kontanter dekker gjeldsavdrag som forfaller i løpet av de neste tolv månedene». Decider v1.3 leder i alle sju domener og overgår Jev 1.14 med opptil 12,9 prosentpoeng innen finans og 9,3 poeng innen juss. Decider Flash v1.3 ligger bak Jev 1.14 innen finans, programmering og juss, og presterer omtrent likt i de andre domenene.

Forstørr

Gjenfinning og omrangering

Søk er kjernen i Perplexity. Vi har en omfattende samling gjenfinningsoppgaver for å evaluere modellenes omrangeringsytelse. For hver oppgave bruker vi først en gruppe embeddingmodeller til å hente de 50 beste kandidatdokumentene fra hvert korpus. Deretter omrangerer vi disse kandidatene med Decider og sammenligner ytelsen med en sterk referansemodell for omrangering, Qwen3-Reranker-8B.

Vi evaluerer Decider i et zero-shot-oppsett med punktvis vurdering, der modellen gir hvert spørring–dokument-par en poengsum direkte og uavhengig og rangerer dokumentene etter relevans. På tvers av 72 gjenfinningsoppgaver oppnår Decider v1.3 en gjennomsnittlig nDCG@10 på 83,99 og overgår Qwen3-Reranker-8B med 1,81 poeng og Jev 1.14 med 2,24 poeng.

På BEIR-benchmarken overgår begge modellene Qwen3-Reranker-8B med henholdsvis 8,78 og 7,05 nDCG@10. Sammenlignet med Jev 1.14 ligger Decider v1.3 1,33 poeng høyere, mens Flash-versjonen får 0,4 poeng lavere.

Forstørr

Flerspråklig klassifisering

For å evaluere beslutningsmodeller utover engelsk satte vi sammen en flerspråklig referansetest for klassifisering bestående av 19 språkspesifikke oppgaver fra 8 offentlige datasett, med 46 484 eksempler på tvers av åtte språk: tysk, spansk, fransk, italiensk, russisk, japansk, koreansk og kinesisk. Referansetesten dekker intensjonsgjenkjenning, emneklassifisering, sentimentanalyse, naturlig språkinferens, parafrasegjenkjenning, gjenkjenning av støtende språk og grammatisk akseptabilitet.

Vi rapporterer gjennomsnittlig nøyaktighet på tvers av oppgavene innenfor hvert språk, med lik vekting av hver oppgave. Decider v1.3 overgår Jev 1.14 på alle åtte språk, og Decider Flash v1.3 gjør det på seks, med gjennomsnittlig oppgavenøyaktighet på 88,16 % for Decider v1.3 og 86,50 % for Decider Flash v1.3, sammenlignet med 85,41 % for Jev 1.14.

Forstørr

NER, PII og ekstraktiv QA

Vi evaluerer locate-funksjonen på 17 oppgaver utenfor treningsdomenet som tester uttrekket på tvers av ulike domener, inndataformater (tekst, tabeller, strukturerte dokumenter) og instruksjoner (korte etiketter, spørsmål og detaljerte beskrivelser). Domenene spenner fra Wikipedia til vitenskapelige artikler, rapporter om cybertrusler, teknisk støtte, personvernerklæringer, CV-er og juridiske kontrakter. Forespørslene spenner fra korte etikettnavn som «person» eller «e-postadresse», via spørsmål om en tabell eller en supportsak, til detaljerte feltbeskrivelser for strukturert uttrekk, for eksempel partene i en taushetserklæring (NDA) eller totalbeløpet på en faktura.

Vi evaluerer NER og PII med F1 for eksakte spenn, som krever at predikerte spenn samsvarer nøyaktig med referansegrensene. Ekstraktiv QA bruker F1 på tegnnivå, som gir delvis uttelling for overlappende svartekst, mens strukturert uttrekking bruker feltnøyaktighet, det vil si andelen felt som trekkes ut riktig. For CV-parsing tar vi gjennomsnittet av F1-poengsummene for eksakte spenn for NER og PII.

Vi sammenligner modellene våre med generelle uttrekksmodeller i ulike størrelser: GLiNER large v2.5 (0,5B), Liquid d1 (2B) og Cloudflares Clairic (ikke oppgitt). Decider v1.3 oppnår en gjennomsnittlig poengsum på 69,0 (med hver oppgaves primære måleparameter), og Decider Flash v1.3 oppnår 63,6, sammenlignet med 43,3 for Liquid d1, 41,5 for Clairic og 33,6 for GLiNER large v2.5. Begge Decider-modellene leder i alle kategorier.

Forstørr

Bildeklassifisering

Decider har hatt innebygd støtte for bildeoppgaver siden v1. For å evaluere ytelsen utover tekst satte vi sammen en referansetestsamling med fem oppgaver og særlig vekt på dokumentklassifisering, inkludert fakturaer, brev og CV-er. Samlingen dekker også klassifisering av satellittbilder, teksturklassifisering, klassifisering av kjæledyrraser og telling av dyr.

Decider v1.3 oppnår en gjennomsnittlig nøyaktighet på 76,99 % på tvers av de fem visuelle oppgavene og overgår Jev 1.14 med 1,47 prosentpoeng. Decider Flash v1.3 oppnår 72,77 %, noe som viser visuelle klassifiseringsevner i en mindre modell.

Forstørr

Reelle beslutningsforespørsler

Vi tok et utvalg av én million deduplierte, PII-maskerte forespørsler som ble sendt til Perplexity Decision API i løpet av de første 18 dagene den var tilgjengelig. Fordi hver forespørsel kan inneholde flere spørsmål om samme tilstand, omfatter utvalget 2 318 887 enkeltspørsmål. Alle forespørslene ble inkludert med uttrykkelig tillatelse fra brukerne til forskning.

Produksjonsforespørsler kommer ikke med fasitetiketter, så vi bruker ledende LLM-er som dommere til å generere referansesvar og måler hver modells samsvar med dem. Vi grupperer også forespørslene i 10 oppgavekategorier, blant annet informasjonsuttrekk, domeneklassifisering, sentimentanalyse, intensjon og ruting, relevansrangering, innholdsmoderering, kvalitets- og samsvarsgjennomgang, entitetsmatching, forretningsanalyse og en «Annet»-kategori. Denne inndelingen viser hvordan ytelsen varierer på tvers av reelle brukstilfeller.

Oppgavefordelingen er ujevn: Informasjonsuttrekk står for 425 402 spørsmål, domeneklassifisering for 409 564 og sentimentanalyse for 344 158. Til sammen utgjør disse tre kategoriene 50,8 % av spørsmålene i utvalget.

Decider v1.3 oppnår det høyeste samsvaret med dommerne, 93,98 %, sammenlignet med 93,68 % for Decider v1.2 og 93,35 % for Jev 1.14. Decider v1.3 og Jev 1.14 er jevnbyrdige på domeneklassifisering og sentimentanalyse, med forskjeller på henholdsvis 0,34 og 0,07 prosentpoeng. Jev leder med 0,69 poeng på relevansrangering, mens Decider v1.3 leder med 0,93 poeng på informasjonsuttrekk (den vanligste oppgaven i utvalget) og med 1,21 poeng på intensjon og ruting.

Forstørr

Diagrammet nedenfor sammenligner de rapporterte kostnadene ved å kjøre de samme én million produksjonsforespørslene. Hver forespørsel kan inneholde flere spørsmål, så enheten her er forespørsler, ikke enkeltspørsmål.

Forstørr

Robusthet

Vi evaluerte etikettsensitivitet på 372 flervalgsspørsmål med 4 788 forespørsler per modell. Vi endret rekkefølgen på alternativene, tilordnet etikettene til andre svartekster og ga etikettene nye navn, samtidig som vi bevarte betydningen av hvert spørsmål, og sjekket deretter om modellens semantiske svar endret seg. Lavere endringsrater tyder på større stabilitet.

Decider v1.3 endret svaret sitt på bare 0,27 % av spørsmålene under hver transformasjon, sammenlignet med 2,69–4,84 % for Jev 1.14. Vi gjentok også identiske inndata for å måle variasjon i tjenesteleveransen: Decider v1.3 viste ingen endringer, mens Jev 1.14 endret seg på 1,88 % av spørsmålene.

Forstørr

Slik bruker vi Decider

Decider er bygget for arbeidsflyter som krever raske og strukturerte beslutninger. I denne delen ser vi på hvordan vi kan utnytte dem til å påvirke måten vi jobber på, på en meningsfull måte. Her er noen som skilte seg ut.

Selvforbedrende sikkerhetsregler

Internt bruker vi allerede Decider til å forbedre sikkerhetsreglene våre.

Aktiviteten til agentene våre registreres, og en rekke regelbaserte kontroller utføres for å identifisere problematisk atferd. En regelbasert tilnærming betyr at vi kan overvåke agentene våre i sanntid med ubetydelig ekstra forsinkelse. Offline bruker vi Decider til å se på utvalg fra disse registrerte agentloggene. Hvis ingen problematisk atferd ble flagget, sjekker Decider om det er noe regelsettet vårt har oversett, og hvis en alarm ble utløst, sjekker Decider om det var en falsk alarm. Alle oppføringer der regelsettet vårt svikter i begge tilfeller, sendes til en agent for triagering, og det foreslås en rettelse av reglene som må godkjennes av et medlem av sikkerhetsteamet vårt.

På én dag leste Decider 1 milliard tokens fordelt på 7 000 agentøkter og identifiserte svakheter som førte til 14 regelrettelser, hvorav 6 ble godkjent og tatt i bruk innen to dager. Da rettelsene ble kjørt på nytt mot en ukes logger, reduserte de volumet for den mest aktive regelen vår med 52 %, og de utvidede reglene fanget opp om lag 40 % flere legitime handlinger å undersøke.

Forstørr

Overvåking av RL-rollouts

Når vi etter-trener modeller med forsterkende læring, forklarer ikke aggregerte målinger som en sluttbelønning hvorfor en rollout (et enkelt forsøk på en oppgave) lyktes eller mislyktes. Den kan miste belønning urettferdig fordi en verktøytjeneste eller sandbox-miljøet feilet, eller få ufortjent belønning hvis evaluatoren overser en udokumentert påstand, for eksempel en oppdiktet verdi som ingen verktøy returnerte.

Vi bruker Decider til å overvåke rollouts for slike tilfeller. Først identifiserer kode de delene av en rollout som krever nærmere inspeksjon: et mislykket verktøykall og resonnementet rundt det, kode som kjørte uten feil, eller det endelige svaret. Deretter svarer Decider på flervalgsspørsmål om hver del, for eksempel hva som feilet i et trinn (en verktøytjeneste, et eksternt nettsted, sandbox-miljøet, harness-oppsettet eller agentens egen kode) og om agenten tolket resultatet riktig. Vi samler alle spørsmål om en gitt del i én forespørsel og lagrer sannsynlighetene i stedet for en konklusjon, slik at vi kan justere tersklene senere uten å spørre Decider på nytt. Monitoren bare observerer og diagnostiserer: Den endrer aldri en belønning og stopper aldri en kjøring.

Forstørr

Filtrering av sidekvalitet

Når vi gjennomsøker nettsider for å indeksere dem og vise dem til brukere, har mange sider for lav kvalitet til å være til nytte. Dette omfatter antibot-vegger, CAPTCHA-er og feilsider, i tillegg til korrekt innlastede nettsider som rett og slett ikke inneholder nyttig informasjon, for eksempel spam, SEO-fyll eller sider med bare navigasjon. Disse lavkvalitetssidene må identifiseres og filtreres ut av indeksen vår.

Med Decider kan vi vurdere kvaliteten på sider mens vi gjennomsøker dem. I samme foroverpassering utfører vi en rekke andre klassifiseringsoppgaver, for eksempel å identifisere innholdets domene og tiltenkte målgruppe, og om det inneholder skadelig, ulovlig eller personidentifiserbar informasjon. Sammenlignet med å bruke en LLM-dommer er Decider betydelig raskere og billigere.

Forstørr

Utover disse interne bruksområdene passer Decider også til arbeidsflyter som disse.

Visuell QA

Fordi Decider leser bilder, fungerer den også som visuell kontrollør som gjennomgår stilendringer på nettsider eller i apper og identifiserer feil. Den kan gjennomgå skjermbilder av sider for avkuttet tekst, overlappende elementer og ødelagte oppsett før en endring lanseres, eller flagge diagrammer med en utforming som kan villede leseren eller bryte med en merkevareprofil.

Forstørr

Nettlesernavigasjon

Agenter kan bruke Decider til de små beslutningene i større oppgaver. En nettleseragent kan sende et skjermbilde for hvert trinn og motta detaljert informasjon om sidens tilstand og det forventede utfallet av hver mulig handling.

Forstørr

Planlegging av forskningsoppgaver

Brukernes spørsmål kan variere mye i kompleksitet, og det samme gjelder hvor dypt søket må gå for å finne et svar. Decider kan anslå dette før søket starter, slik at mindre ressurser brukes på enkle spørsmål.

Forstørr

Kom i gang

Decider returnerer sannsynligheter. Hvilken beslutningsterskel som er passende, avhenger av bruksområdet. Etikettfrekvenser og de relative kostnadene ved falske positiver og falske negativer varierer mellom brukstilfeller. Vi oppfordrer derfor brukere til å justere tersklene på et lite, representativt merket utviklingssett i stedet for å anta at en fast grenseverdi vil fungere like godt på tvers av oppgaver.

Vi anbefaler Decider v1.3 for nyanserte vurderinger, detaljerte vurderingskriterier og arbeidsflyter der feil er kostbare. Velg Decider Flash v1.3 for ruting, merking og filtrering i store volumer der forsinkelse og kostnad er de viktigste begrensningene. Evaluer begge modellene på representative eksempler fra arbeidsmengden din, og velg deretter modellen som oppfyller kravene dine til kvalitet, forsinkelse og budsjett.

Begge modellene er tilgjengelige som nedlastbare vekter på Hugging Face under Apache-lisens, via OpenRouter og gjennom Perplexity Decisions API.

Sitering

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