Perplexity Decider

Vi frigiver Decider v1.3 og Decider Flash v1.3, efterfølgerne til vores tidligere beslutningsmodeller: v1, v1.1, v1.2 og Flash v1.2.

Decider Flash v1.3 er en mindre model destilleret fra Decider v1.3. Begge modeller er tilgængelige på Hugging Face under Apache-licens, via OpenRouter og via Perplexity Decisions API.

Perplexity Decider er inspireret af Jev, TypeSafe AI’s System One Model. Den understøtter binær klassificering og klassificering med flere klasser med ordnede eller uordnede etiketter og returnerer sandsynligheder, som applikationer kan bruge til at klassificere, route, rangere og evaluere input.

Begge v1.3-modeller forbedrer ydeevne og robusthed på tværs af en bred vifte af tekst- og billedopgaver takket være bidirektionel attention, bedre kurateret træningsdata og en forfinet træningsopskrift. Vi introducerer også locate, en ny funktion, der fremhæver det udvalgte indhold til genkendelse af navngivne entiteter, identifikation af personoplysninger og ekstraktive spørgsmål-svar-opgaver.

I dette indlæg forklarer vi, hvordan vi træner og evaluerer Decider, og fortæller, hvordan vi bruger den internt hos Perplexity.

Hvad er en beslutningsmodel?

En beslutningsmodel er en generel klassifikator. Du giver den et input og et sæt spørgsmål, hver med sine mulige svar. For hvert spørgsmål returnerer den en sandsynlighedsfordeling over svarene. Den understøtter 3 spørgsmålstyper:

• Ja/nej: binære beslutninger.
• Multiple choice: brugerdefinerede etiketter med flere klasser.
• Score: ordnede niveauer.

Beslutningsmodeller understøtter en bred vifte af klassificerings- og scoringsopgaver:

• Bedømmelse af output: vurdering af kildetroskab, kvalitet og sikkerhed.
• Routing: videresendelse af forespørgsler til mindre eller større modeller baseret på sværhedsgrad.
• Moderering og sikkerhed: registrering af skadeligt indhold, phishing og prompt injection i værktøjsoutput.
• Filtrering og tagging: organisering af store indholdssamlinger.
• Hentning og genrangering: scoring af søgeresultater efter relevans.

Mange af disse opgaver blev tidligere håndteret af generative modeller som LLM’er, selvom de ikke kræver fri tekstgenerering. Beslutningsmodeller ligger mellem LLM’er og opgavespecifikke klassifikatorer. De returnerer sandsynligheder for flere spørgsmål om det samme input i ét enkelt forward pass, så de undgår at generere svar token for token og deler beregningerne på tværs af spørgsmål. I modsætning til opgavespecifikke klassifikatorer kan de håndtere nye opgaver via prompts i naturligt sprog – en fleksibilitet, de har lært ved at blive trænet på mange forskellige opgaver i et fælles spørgsmål-svar-format.

Træning

Sådan gør man en generativ LLM til en beslutningsmodel

Vi bygger Decider ved at tilpasse stærke generative LLM-backbones. For at forklare tilpasningen beskriver vi først, hvordan en forespørgsel repræsenteres. Som vist nedenfor består en forespørgsel af en fælles kontekst (tilstanden) og et antal spørgsmål. Tilstanden genbruges af alle spørgsmål.

Givet et dokument og dets resumé kan en enkelt forespørgsel for eksempel spørge, om resuméet gengiver dokumentet tro, og om det er rettet mod en ekspert eller et bredt publikum. Efter tilstanden indeholder hver spørgsmålsblok et spørgsmål og dets mulige svar, som hver tildeles et foruddefineret etikettoken såsom A, B eller C. Et særligt <|marker|>-token angiver, hvor modellens forudsigelse skal aflæses. På denne position mapper et lært lineært outputlag (et beslutningshoved) den skjulte tilstand til scores for spørgsmålets svarmuligheder, som derefter konverteres til sandsynligheder.

Udvid

Vi initialiserer outputlaget fra basismodellen, som normalt scorer det næste token ud fra hele ordforrådet, og beholder kun de rækker, der svarer til de foruddefinerede svartokens såsom A, B eller C. Dette beskårne lag trænes derefter til at omsætte den skjulte tilstand for <|marker|> til svarscores. Denne tilgang dækker alle klassificeringsspørgsmål, fordi de alle kan formuleres som multiple choice.

Til træning tager vi hundredvis af offentlige datasæt, der spænder over forskellige opgaver (sentiment, naturlig sproginferens, intentionsgenkendelse, entitetsmatching, moderering, faktatjek, bedømmelser osv.), og konverterer hvert eksempel til det samlede format, der er beskrevet ovenfor: en tilstand, et eller flere spørgsmål, deres svarmuligheder og et mål. Målet kan være den ene korrekte svarmulighed, hvis vi har guldstandard-etiketter, eller en sandsynlighedsfordeling over svarmulighederne.

I v1.3 introducerer vi locate, som udtrækker tekst fra tilstanden i stedet for at vælge blandt foruddefinerede muligheder. Et locate-spørgsmål beskriver, hvad der skal findes, enten med en kort etiket som „placering“ eller en instruktion som „Udtræk navnet på den by, hvor jobbet er placeret.“ Modellen returnerer den nøjagtigt matchende tekst fra tilstanden sammen med dens start- og slutposition målt i tegn. Hvis den ikke finder nogen match, returnerer den en tom liste.

Udvid

Fordi tilstanden er delt, kan en enkelt forespørgsel kombinere locate-, klassificerings- og scoringsspørgsmål om det samme input. Den kan for eksempel spørge, om et job kræver erfaring på seniorniveau, og udtrække de påkrævede kompetencer.

Bidirektionel attention: Modellen læser i begge retninger

Vores modeller tager udgangspunkt i stærke prætrænede generative backbones, hvis kausale attention kun lader hvert token være opmærksomt på sig selv og foregående tokens. Vores ablationsstudier viste, at det forbedrer ydeevnen at gøre backbonens fuld-attention-lag bidirektionelle, så vi anvender dette design for at lade hvert token inddrage kontekst fra hele inputtet.

Bidirektionel attention medfører endnu et designvalg: Hvordan skal tilstanden og spørgsmålene interagere? Vi overvejede tre attention-mønstre med forskellige konsekvenser for ydeevne, svarstabilitet og genbrug af cache:

• Alt ser alt (v1.2): Tilstanden og alle spørgsmål behandles samlet med fuld bidirektionel attention. Beregningen over tilstanden deles, men svaret på ét spørgsmål kan ændre sig afhængigt af, hvad der ellers bliver spurgt om.
• Isolerede spørgsmål (v1.3): Tilstanden har attention på alle spørgsmålene, mens hvert spørgsmål kun har attention på tilstanden og sine egne tokens. Spørgsmål kan stadig påvirke hinanden indirekte gennem den delte tilstand, men resultaterne er mere stabile.
• Fuldt cachebar: Tilstanden retter kun opmærksomheden mod sig selv, mens hvert spørgsmål retter opmærksomheden mod tilstanden og sine egne tokens. Tilstanden er uafhængig af spørgsmålene og kan genbruges på tværs af forespørgsler, så man kan drage fordel af prompt-caching. Vi bruger den ikke som standard, fordi det betyder meget for flere opgaver, at tilstanden kan se spørgsmålene, men en lille finjustering kan skifte en model over til den.

Vi valgte i sidste ende isolerede spørgsmål på grund af deres stærke ydeevne og stabilitet.

Udvid

Træningsopskrift

Træningen foregår i tre faser for begge modelstørrelser. Vi træner først den største model, baseret på Qwen3.8-27B, med krydsentropi på store datasæt og destillerer den derefter ind i den mindre Qwen3.5-4B-model.

Det første trin er generalisttræning, hvor vi finjusterer hele modellen på store korpusser. I dette trin accepterer vi kun data, der hjælper modellen generelt og ikke er specifikke for et bestemt benchmark; vi udelukker derfor alle træningssplits fra benchmarks.

Når denne generalistmodel er trænet, kører vi en anden, mere finkornet fase med LoRA. Dataene i denne fase er målrettet specifikke domæner og opgaver. Vi tilføjer data i den anden fase frem for den første, hvis vi ser snævre forbedringer, eller hvis vi ser regressioner på andre opgaver. Vi bruger LoRA for at undgå at bevæge os for langt væk fra generalistmodellen og risikere at miste ydeevne for at tilpasse modellen til de specifikke domæner. Målet er at forbedre ydeevnen og samtidig bevare backbonens generelle viden. Vi bruger også en vægt, når vi fletter LoRA’en tilbage i basismodellen, så vi kan styre afvigelsen mere præcist og prioritere metrikker på tilbageholdte data over gevinster inden for domænet.

Til sidst tilføjer vi et visionsspecifikt trin. Ligesom andet trin behandles visionstrinnet som endnu et finkornet specialiseringstrin med en LoRA-adapter, der flettes tilbage i basismodellen med en vægt. Nogle visionsfunktioner kan gå ud over tekstydeevnen. Da vi ser langt mere brug af modellerne på tekst, prioriterer vi tekstmålinger over visionsmålinger.

For begge teksttrin bruger vi gennemsnittet af vægtene fra tre kørsler, der hver bruger et forskelligt tilfældigt seed. Vi har fundet ud af, at det forbedrer den samlede models ydeevne og robusthed.

Når den endelige store model er klar, anvender vi den samme tretrins træningsprocedure på den mindre model. Her fungerer den store model som lærer: Dens forudsagte outputfordeling erstatter guldetiketterne, og den mindre model trænes til at minimere KL-divergensen mellem sine forudsigelser og lærerens. Dette destillationsmål klarer sig bedre end krydsentropi på de samme træningsdata. Krydsentropi klarer sig bedre på benchmarks med dedikerede træningsdata, men generaliserer dårligere til tilbageholdte data. Vores hypotese er, at destillation bedre overfører lærerens outputfordeling, herunder dens konfidens for alternativer uden for guldetiketterne, mens krydsentropi fremmer overfitting til den benchmarkspecifikke træningsfordeling. Vi anvender derfor det KL-baserede destillationsmål.

For at begrænse kontaminering mellem trænings- og testdata fjerner vi alle træningseksempler, der kan overlappe med de evalueringer, vi bruger. Det er vigtigt, fordi nogle offentlige træningsdatasæt indeholder store dele af visse evalueringsdatasæt. Vi gennemfører også omfattende bias-audits og fjerner bias for at sikre, at vores forbedringer er pålidelige og ikke blot drevet af tillærte bias.

Tilføjelse af evnen til at udtrække information

Funktionen locate udtrækker information såsom navngivne entiteter fra tekst uden at ændre, hvordan den besvarer almindelige forespørgsler. For at opnå dette introducerer vi et ekstra træningstrin: Vi tilføjer et nyt specialtoken, <|locate|>, et span-hoved og en LoRA-adapter til Decider.

Vi initialiserer embeddingen for <|locate|> ud fra <|marker|>, der er lært i de foregående træningstrin. Vi træner kun denne nye embedding, span-hovedet og LoRA-adapterne, mens de oprindelige backbonevægte og beslutningshovedet holdes frosne. Hvert ønsket felt får sit eget <|locate|>-token.

Span-hovedet bruger repræsentationen af <|locate|> sammen med repræsentationerne af tilstandstokens til at score, hvor matchende spans starter og slutter, og hvilke start-slut-par der hører sammen. Det bruger også repræsentationen af <|locate|>-tokenet til at forudsige feltspecifikke tærskler for disse scorer. De valgte spans returneres som tegnpositioner i den oprindelige tekst.

Vi træner span-hovedet med et tilpasset InfoNCE-tab, der skubber hvert guld-span over tærsklen og tærsklen over alle andre spans. Tabet har to led: Det første skubber scorerne for korrekte spans over tærsklen og de forkerte spans. Det andet led skubber tærsklen over scorerne for forkerte spans. Felter uden svar får kun det andet led, hvilket lærer modellen at returnere en tom liste.

Vi træner på en blanding af span-udtrækningsopgaver, herunder genkendelse af navngivne entiteter, registrering af PII og ekstraktiv besvarelse af spørgsmål. Vi varierer feltbeskrivelserne fra korte etiketter til detaljerede instruktioner, så modellen lærer at følge forespørgslen i stedet for at huske et fast sæt etiketter udenad.

Locate lærer modellen en strukturelt anderledes opgave, og vi vil tilføje den uden at miste det, modellen allerede gør godt. Når locate-adapterne flettes ind i backbonen, giver det en vis regression på beslutningsforespørgsler. For at begrænse dette undersøger vi bl.a. mere replay-data fra tidligere faser og hjælpemål, der holder modellens output på beslutningsforespørgsler tæt på den oprindelige models. Vi ser dog, at fletningen stadig ikke er tabsfri, så vi fletter ikke adapterne ind, men aktiverer dem kun for locate-forespørgsler.

Evaluering

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

På tværs af disse evalueringer viser vores modeller stærk ydeevne. Selvom disse leaderboards omfatter private opgaver, kan de stadig manipuleres gennem gentagne indsendelser og iterativ tuning baseret på feedback fra leaderboardet. Som supplement til disse leaderboards evaluerer vi modellerne på en intern samling, der kombinerer private produktionsopgaver med tilbageholdte evalueringer hentet fra offentlige datasæt, der ikke er benchmarks. Disse evalueringer giver et ekstra tjek af generaliseringen ud over offentlige benchmarks og hjælper os med at skelne bredere forbedringer fra gevinster, der er specifikke for velkendte evalueringssæt.

Internt har vi bygget en suite af mere end 200 opgaver på tværs af forskellige domæner og opgavetyper som klassificering, scoring, genrangering og udtrækning af entiteter. For at give en ærlig vurdering af Deciders ydeevne i praksis udføres alle evalueringer zero-shot, uden opgavespecifik finjustering, hvilket giver os et klart signal om, hvor modellen kan forbedres.

Klassificering af forespørgsler

Hos Perplexity bruger vi et klassificeringssystem med flere hoveder til at behandle hver brugerforespørgsel. Hver forespørgsel sendes først gennem en embeddingmodel, der fungerer som egenskabsudtrækker. Den resulterende embedding føres derefter ind i flere separate klassificeringshoveder, herunder både binære klassifikatorer og multi-label-klassifikatorer. Et af hovederne afgør for eksempel, om en brugerforespørgsel skal udløse en websøgning.

På tværs af 63 klassificeringsopgaver med referencer, der er uafhængigt genannoteret af en frontier-LLM, opnår Decider v1.3 en gennemsnitlig nøjagtighed på 91,6 % og overgår vores produktionsklassifikatorer med 6,54 procentpoint. Decider Flash v1.3 overgår også produktionsbaselinen, mens Decider v1.3 overgår Jev 1.14.

Udvid

Domænespecifik klassificering

Vi har sammensat en domænespecifik evalueringssuite ud fra offentlige datasæt for at vurdere beslutningsmodellers klassificeringsevne på tværs af syv domæner: verificering af påstande (6 opgaver), sundhed (7), cybersikkerhed (8), programmering (16), offentlig forvaltning (7), jura (9) og finans (9).

For eksempel „bedøm tidskompleksiteten af et Python-program“ eller „brug en årsrapport til at afgøre, om en virksomheds frie likvider dækker gældsafdrag, der forfalder inden for de næste tolv måneder“. Decider v1.3 fører på tværs af alle syv domæner og overgår Jev 1.14 med op til 12,9 procentpoint inden for finans og 9,3 point inden for jura. Decider Flash v1.3 ligger efter Jev 1.14 inden for finans, programmering og jura og præsterer på samme niveau i de øvrige domæner.

Udvid

Hentning og genrangering

Søgning er kernen i Perplexity. Vi vedligeholder en bred suite af hentningsopgaver for at evaluere vores modellers genrangeringsevne. For hver opgave bruger vi først en pulje af embeddingmodeller til at hente de 50 bedste kandidatdokumenter fra hvert korpus. Derefter genrangerer vi disse kandidater med Decider og sammenligner ydeevnen med en stærk baseline for genrangering, Qwen3-Reranker-8B.

Vi evaluerer Decider i en zero-shot, punktvis opsætning, hvor modellen direkte scorer hvert forespørgsel–dokument-par uafhængigt og rangerer dokumenterne efter relevans. På tværs af 72 hentningsopgaver opnår Decider v1.3 en gennemsnitlig nDCG@10 på 83,99 og overgår Qwen3-Reranker-8B med 1,81 point og Jev 1.14 med 2,24 point.

På BEIR-benchmarket overgår begge modeller Qwen3-Reranker-8B med henholdsvis 8,78 og 7,05 nDCG@10. Sammenlignet med Jev 1.14 ligger Decider v1.3 1,33 point højere, mens Flash-versionen scorer 0,4 lavere.

Udvid

Flersproget klassificering

For at evaluere beslutningsmodeller ud over engelsk har vi sammensat et flersproget klassificeringsbenchmark bestående af 19 sprogspecifikke opgaver fra 8 offentlige datasæt med 46.484 eksempler på otte sprog: tysk, spansk, fransk, italiensk, russisk, japansk, koreansk og kinesisk. Benchmarket dækker intentionsgenkendelse, emneklassificering, sentimentanalyse, naturlig sproginferens, genkendelse af parafraser, genkendelse af stødende sprog og grammatisk acceptabilitet.

Vi rapporterer den gennemsnitlige nøjagtighed på tværs af opgaver inden for hvert sprog, hvor hver opgave vægtes ligeligt. Decider v1.3 overgår Jev 1.14 på alle otte sprog, og Decider Flash v1.3 gør det på seks, med gennemsnitlige opgavenøjagtigheder på 88,16 % for Decider v1.3 og 86,50 % for Decider Flash v1.3, sammenlignet med 85,41 % for Jev 1.14.

Udvid

NER, PII og ekstraktiv QA

Vi evaluerer locate-funktionen på 17 opgaver uden for domænet, der tester dens udtrækning på tværs af forskellige domæner, inputformater (tekst, tabeller, strukturerede dokumenter) og instruktioner (korte etiketter, spørgsmål og detaljerede beskrivelser). Domænerne spænder fra Wikipedia til videnskabelige artikler, rapporter om cybertrusler, teknisk support, privatlivspolitikker, CV'er og juridiske kontrakter. Forespørgslerne spænder fra korte etiketnavne som „person“ eller „e-mailadresse“ over spørgsmål om en tabel eller en supportsag til detaljerede feltbeskrivelser til struktureret udtrækning, såsom parterne i en NDA eller totalbeløbet på en faktura.

Vi evaluerer NER og PII med exact-span F1, som kræver, at forudsagte spans matcher referencegrænserne nøjagtigt. Ekstraktiv QA bruger F1 på tegnniveau, som giver delvis point for overlappende svartekst, mens struktureret udtrækning bruger feltnøjagtighed, dvs. andelen af felter, der udtrækkes korrekt. Til CV-parsing tager vi gennemsnittet af exact-span F1-scorerne for NER og PII.

Vi sammenligner vores modeller med generelle udtrækningsmodeller af forskellig størrelse: GLiNER large v2.5 (0,5B), Liquid d1 (2B) og Cloudflares Clairic (ikke oplyst). Decider v1.3 når en gennemsnitlig score på 69,0 (baseret på hver opgaves primære metrik), og Decider Flash v1.3 når 63,6, sammenlignet med 43,3 for Liquid d1, 41,5 for Clairic og 33,6 for GLiNER large v2.5. Begge Decider-modeller fører i alle kategorier.

Udvid

Billedklassificering

Decider har understøttet billedopgaver indbygget siden v1. For at evaluere ydeevnen ud over tekst har vi sammensat en benchmarksuite med fem opgaver med særligt fokus på dokumentklassificering, herunder fakturaer, breve og CV'er. Suiten dækker også klassificering af satellitbilleder, klassificering af teksturer, klassificering af kæledyrsracer og optælling af dyr.

Decider v1.3 opnår en gennemsnitlig nøjagtighed på 76,99 % på tværs af de fem visuelle opgaver og overgår Jev 1.14 med 1,47 procentpoint. Decider Flash v1.3 opnår 72,77 %, hvilket demonstrerer visuelle klassificeringsevner i en mindre model.

Udvid

Beslutningsforespørgsler fra den virkelige verden

Vi udtog en stikprøve på en million deduplikerede, PII-maskerede forespørgsler, der blev indsendt til Perplexity Decision API i løbet af de første 18 dage, den var tilgængelig. Da hver forespørgsel kan indeholde flere spørgsmål om den samme tilstand, omfatter stikprøven 2.318.887 individuelle spørgsmål. Alle forespørgsler blev medtaget med udtrykkelig tilladelse fra brugerne til forskningsformål.

Produktionsforespørgsler leveres ikke med ground truth-etiketter, så vi bruger frontier-LLM'er som dommere til at generere referencesvar og måler hver models overensstemmelse med dem. Vi grupperer også forespørgslerne i 10 opgavekategorier, herunder informationsudtrækning, domæneklassificering, sentimentanalyse, intention og routing, relevansrangering, indholdsmoderering, kvalitets- og compliancegennemgang, entitetsmatching, forretningsanalyse og en kategori kaldet „Andet“. Denne opdeling viser, hvordan ydeevnen varierer på tværs af anvendelsestilfælde i den virkelige verden.

Opgavefordelingen er ujævn: Informationsudtrækning står for 425.402 spørgsmål, domæneklassificering for 409.564 og sentimentanalyse for 344.158. Tilsammen udgør disse tre kategorier 50,8 % af de udvalgte spørgsmål.

Decider v1.3 opnår den højeste overensstemmelse med dommerne med 93,98 %, sammenlignet med 93,68 % for Decider v1.2 og 93,35 % for Jev 1.14. Decider v1.3 og Jev 1.14 ligger tæt på hinanden inden for domæneklassificering og sentimentanalyse med forskelle på henholdsvis 0,34 og 0,07 procentpoint. Jev fører med 0,69 point inden for relevansrangering, mens Decider v1.3 fører med 0,93 point inden for informationsudtrækning (den mest almindelige opgave i stikprøven) og med 1,21 point inden for intention og routing.

Udvid

Diagrammet nedenfor sammenligner de rapporterede omkostninger ved at køre de samme en million produktionsforespørgsler. Hver forespørgsel kan indeholde flere spørgsmål, så enheden her er forespørgsler, ikke individuelle spørgsmål.

Udvid

Robusthed

Vi evaluerede etiketfølsomhed på 372 multiple choice-spørgsmål med 4.788 forespørgsler pr. model. Vi ændrede rækkefølgen af svarmulighederne, tildelte etiketterne til andre svartekster og omdøbte etiketter, mens hvert spørgsmåls betydning blev bevaret, og kontrollerede derefter, om modellens semantiske svar ændrede sig. Lavere skifterater indikerer større stabilitet.

Decider v1.3 ændrede sit svar på blot 0,27 % af spørgsmålene under hver transformation, sammenlignet med 2,69–4,84 % for Jev 1.14. Vi gentog også identiske input for at måle variationen i modelafviklingen: Decider v1.3 viste ingen ændringer, mens Jev 1.14 ændrede svar på 1,88 % af spørgsmålene.

Udvid

Sådan bruger vi Decider

Decider er bygget til arbejdsprocesser, der kræver hurtige og strukturerede beslutninger. I dette afsnit ser vi på, hvordan de kan udnyttes til at gøre en mærkbar forskel for den måde, vi arbejder på. Her er nogle, der skilte sig ud.

Selvforbedrende sikkerhedsregler

Internt bruger vi allerede Decider til at forbedre vores sikkerhedspolitikker.

Vores agenters aktivitet registreres, og en række regelbaserede kontroller udføres for at identificere problematisk adfærd. En regelbaseret tilgang betyder, at vi kan overvåge vores agenter i realtid med ubetydelig ekstra latenstid. Offline bruger vi Decider til at gennemgå stikprøver fra disse registrerede agentlogs. Hvis der ikke blev markeret nogen problematisk adfærd, tjekker Decider, om der er noget, vores regelsæt har overset; og hvis der blev slået alarm, tjekker Decider, om det var falsk alarm. Alle registreringer, hvor vores regelsæt fejler i et af tilfældene, sendes til en agent til triage, og der foreslås en rettelse af reglerne, som skal godkendes af et medlem af vores sikkerhedsteam.

På én dag læste Decider 1 milliard tokens på tværs af 7.000 agentsessioner og identificerede fejl, der førte til 14 regelrettelser, hvoraf 6 blev godkendt og udrullet inden for to dage. Afspillet på en uges logs reducerede rettelserne volumenet for vores travleste regel med 52 %, og de udvidede regler fangede omkring 40 % flere legitime handlinger til undersøgelse.

Udvid

Overvågning af RL-rollouts

Når vi eftertræner modeller med reinforcement learning, forklarer aggregerede målinger som en endelig belønning ikke, hvorfor en rollout (et enkelt forsøg på en opgave) lykkedes eller mislykkedes. Den kan miste belønning uretfærdigt, fordi en værktøjstjeneste eller sandboxen fejlede, eller modtage ufortjent belønning, hvis evaluatoren overser en udokumenteret påstand, f.eks. en opdigtet værdi, som intet værktøj returnerede.

Vi bruger Decider til at overvåge rollouts i disse tilfælde. Kode identificerer først de dele af en rollout, der kræver nærmere inspektion: et mislykket værktøjskald og den omkringliggende ræsonnering, kode, der kørte uden fejl, eller det endelige svar. Decider besvarer derefter multiple choice-spørgsmål om hver del, f.eks. hvad der fejlede i et trin (en værktøjstjeneste, et eksternt website, sandboxen, harnessen eller agentens egen kode), og om agenten fortolkede resultatet korrekt. Vi samler alle spørgsmål om en given del i én forespørgsel og gemmer sandsynlighederne i stedet for en dom, så vi senere kan justere tærskler uden at forespørge Decider igen. Monitoren observerer og diagnosticerer kun: Den ændrer aldrig en belønning og stopper aldrig en kørsel.

Udvid

Filtrering af sidekvalitet

Når vi crawler websider for at indeksere dem og vise dem til brugerne, er mange sider af for lav kvalitet til at være til nogen nytte. Det omfatter anti-bot-mure, CAPTCHA'er og fejlsider samt korrekt indlæste websider, der blot ikke indeholder nogen nyttig information, såsom spam, SEO-fyld eller sider, der kun består af navigation. Disse sider af lav kvalitet skal identificeres og filtreres fra vores indeks.

Med Decider kan vi vurdere kvaliteten af sider, mens vi crawler dem. I samme forward pass udfører vi en række andre klassificeringsopgaver, f.eks. at identificere indholdets domæne og tiltænkte målgruppe, og om det indeholder skadelige, ulovlige eller personhenførbare oplysninger. Sammenlignet med at bruge en LLM-dommer er Decider betydeligt hurtigere og billigere.

Udvid

Ud over disse interne anvendelser passer Decider også til arbejdsprocesser som følgende.

Visuel QA

Fordi Decider kan læse billeder, fungerer den også som visuel kontrol, der gennemgår stilændringer på websider eller i apps og identificerer fejl. Den kan gennemgå skærmbilleder af sider for afskåret tekst, overlappende elementer og ødelagte layouts, før en ændring udrulles, eller markere diagrammer, hvis design kan vildlede en læser eller bryde med en brandguide.

Udvid

Browsernavigation

Agenter kan bruge Decider til de små beslutninger inden for større opgaver. En browseragent kan sende et skærmbillede ved hvert trin og modtage detaljeret information om sidens tilstand og det forventede resultat af hver mulig handling.

Udvid

Planlægning af researchopgaver

Brugernes spørgsmål kan variere meget i kompleksitet, og det samme gælder den søgedybde, der skal til for at finde et svar. Decider kan vurdere dette, før søgningen begynder, så der bruges færre ressourcer på enkle spørgsmål.

Udvid

Kom godt i gang

Decider returnerer sandsynligheder. Den passende beslutningstærskel afhænger af anvendelsen. Etiketfrekvenser og de relative omkostninger ved falske positiver og falske negativer varierer på tværs af anvendelsestilfælde. Vi opfordrer derfor brugerne til at justere tærskler på et lille, repræsentativt annoteret udviklingssæt i stedet for at antage, at en fast grænseværdi vil fungere lige godt på tværs af opgaver.

Vi anbefaler Decider v1.3 til nuancerede vurderinger, detaljerede bedømmelseskriterier og arbejdsgange, hvor fejl er dyre. Vælg Decider Flash v1.3 til routing, mærkning og filtrering i stor skala, hvor latens og omkostninger er de vigtigste begrænsninger. Evaluer begge modeller på repræsentative eksempler fra din arbejdsbelastning, og vælg derefter den model, der opfylder dine krav til kvalitet, latens og budget.

Begge modeller er tilgængelige som vægte, der kan downloades, på Hugging Face under Apache-licens, via OpenRouter og via Perplexity Decisions API.

Citering

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