Perplexity Decider

Så tränar, utvärderar och använder vi den.

FörfattarePerplexity Research

Vi lanserar Decider v1.3 och Decider Flash v1.3, efterföljarna till våra tidigare beslutsmodeller: v1, v1.1, v1.2 och Flash v1.2.

Decider Flash v1.3 är en mindre modell som destillerats från Decider v1.3. Båda modellerna finns tillgängliga på Hugging Face under Apache-licens, via OpenRouter och via Perplexity Decisions API.

Perplexity Decider är inspirerad av Jev, TypeSafe AI:s System One Model. Den stöder binär klassificering och klassificering med flera klasser, med ordnade eller oordnade etiketter, och returnerar sannolikheter som tillämpningar kan använda för att klassificera, dirigera, ranka och utvärdera indata.

Båda v1.3-modellerna förbättrar prestanda och robusthet i ett brett spektrum av text- och bilduppgifter tack vare dubbelriktad uppmärksamhet, bättre kurerad träningsdata och ett förfinat träningsrecept. Vi introducerar också locate, en ny funktion som markerar det valda innehållet för uppgifter som namngiven entitetsigenkänning, identifiering av personuppgifter och extraktiv frågebesvaring.

I det här inlägget förklarar vi hur vi tränar och utvärderar Decider och berättar hur vi använder den internt på Perplexity.

Vad är en beslutsmodell?

En beslutsmodell är en klassificerare för allmänna ändamål. Du ger den indata och en uppsättning frågor, var och en med sina möjliga svar. För varje fråga returnerar den en sannolikhetsfördelning över svaren. Den stöder 3 frågetyper:

  • Ja/nej: binära beslut.
  • Flerval: anpassade etiketter för flera klasser.
  • Poäng: ordnade nivåer.

Beslutsmodeller stöder ett brett spektrum av klassificerings- och poängsättningsuppgifter:

  • Bedömning av utdata: utvärdering av trohet, kvalitet och säkerhet.
  • Routning: styrning av förfrågningar till mindre eller större modeller utifrån svårighetsgrad.
  • Moderering och säkerhet: upptäckt av skadligt innehåll, nätfiske och promptinjektion i verktygsutdata.
  • Filtrering och taggning: organisering av stora innehållssamlingar.
  • Hämtning och omrankning: poängsättning av sökresultat efter relevans.

Många av dessa uppgifter hanterades tidigare av generativa modeller som LLM:er, trots att de inte kräver fri textgenerering. Beslutsmodeller placerar sig mellan LLM:er och uppgiftsspecifika klassificerare. De returnerar sannolikheter för flera frågor om samma indata i ett enda framåtpass, vilket gör att de slipper generera svar token för token och kan dela beräkningar mellan frågorna. Till skillnad från uppgiftsspecifika klassificerare kan de hantera nya uppgifter via promptar på naturligt språk, en flexibilitet som de har lärt sig genom träning på varierade uppgifter i ett gemensamt fråga-svar-format.

Träning

Att göra en generativ LLM till en beslutsmodell

Vi bygger Decider genom att anpassa kraftfulla generativa LLM-stommodeller. För att förklara anpassningen beskriver vi först hur en förfrågan representeras. Som visas nedan består en förfrågan av en delad kontext (tillståndet) och ett antal frågor. Tillståndet återanvänds av alla frågor.

Givet till exempel ett dokument och dess sammanfattning kan en enda förfrågan fråga om sammanfattningen troget återger dokumentet och om den riktar sig till en expert eller en bred publik. Efter tillståndet innehåller varje frågeblock en fråga och dess möjliga svar, där varje svar tilldelas en fördefinierad etikett-token som A, B eller C. En särskild <|marker|>-token anger var modellens förutsägelse ska läsas av. På den positionen mappar ett inlärt linjärt utdatalager (ett beslutshuvud) det dolda tillståndet till poäng för frågans svarsalternativ, som sedan omvandlas till sannolikheter.

Vi initierar utdatalagret från basmodellen, som normalt poängsätter nästa token utifrån hela vokabulären, och behåller bara de rader som motsvarar de fördefinierade alternativtokens som A, B eller C. Detta beskurna lager tränas sedan att omvandla det dolda tillståndet för <|marker|> till svarspoäng. Detta tillvägagångssätt täcker alla klassificeringsfrågor eftersom de alla kan formuleras som flervalsfrågor.

För träningen tar vi hundratals offentliga datamängder som spänner över olika uppgifter (sentiment, naturlig språkinferens, avsiktsigenkänning, entitetsmatchning, moderering, faktagranskning, betyg m.m.) och konverterar varje exempel till det enhetliga format som beskrivs ovan: ett tillstånd, en eller flera frågor, deras alternativ och ett mål. Målet kan vara det enda korrekta alternativet om vi har facitetiketter, eller en sannolikhetsfördelning över alternativen.

I v1.3 introducerar vi locate, som extraherar text från tillståndet i stället för att välja bland fördefinierade alternativ. En locate-fråga beskriver vad som ska hittas, antingen med en kort etikett som ”plats” eller med en instruktion som ”Extrahera namnet på staden där jobbet finns.” Modellen returnerar den exakt matchande texten från tillståndet, tillsammans med dess start- och slutposition räknat i tecken. Om den inte hittar några matchningar returnerar den en tom lista.

Tack vare det delade tillståndet kan en enda förfrågan kombinera locate-, klassificerings- och poängsättningsfrågor om samma indata. Den kan till exempel fråga om ett jobb kräver erfarenhet på seniornivå och samtidigt extrahera de kompetenser som krävs.

Dubbelriktad uppmärksamhet: låt modellen läsa åt båda hållen

Våra modeller utgår från starka förtränade generativa grundmodeller, vars kausala uppmärksamhet låter varje token ta hänsyn enbart till sig själv och föregående tokens. Våra ablationsstudier visade att prestandan förbättras om grundmodellens lager med full uppmärksamhet görs dubbelriktade, så vi använder den designen för att låta varje token ta in kontext från hela indatat.

Dubbelriktad uppmärksamhet medför ytterligare ett designval: hur ska tillståndet och frågorna interagera? Vi övervägde tre uppmärksamhetsmönster, med olika konsekvenser för prestanda, svarsstabilitet och återanvändning av cache:

  • Allt ser allt (v1.2): Tillståndet och alla frågor bearbetas tillsammans med full dubbelriktad uppmärksamhet. Beräkningen över tillståndet delas, men svaret på en fråga kan ändras beroende på vad mer som frågas.
  • Isolerade frågor (v1.3): Tillståndet tar hänsyn till alla frågor, medan varje fråga bara tar hänsyn till tillståndet och sina egna tokens. Frågorna kan fortfarande påverka varandra indirekt via det delade tillståndet, men resultaten blir stabilare.
  • Helt cachebart: Tillståndet riktar endast attention mot sig självt, medan varje fråga riktar attention mot tillståndet och sina egna tokens. Tillståndet är oberoende av frågorna och kan återanvändas mellan förfrågningar för att dra nytta av promptcachning. Vi använder det inte som standard, eftersom det är mycket viktigt för flera uppgifter att tillståndet kan se frågorna, men en liten finjustering räcker för att ställa om en modell till det.

Till slut valde vi isolerade frågor för deras goda prestanda och stabilitet.

Träningsrecept

Träningen sker i tre steg för båda modellstorlekarna. Vi tränar först den större modellen, baserad på Qwen3.8-27B, med korsentropi på stora datamängder, och destillerar den sedan till den mindre modellen Qwen3.5-4B.

Det första steget är generalistträning, där vi finjusterar hela modellen på storskaliga korpusar. I det här steget accepterar vi bara data som hjälper modellen överlag och inte är specifik för något benchmark; därför utesluter vi alla träningsdelar av benchmarks.

När den här generalistmodellen har tränats kör vi ett andra, mer finkornigt steg med LoRA. Datan i det här steget är inriktad på specifika domäner och uppgifter. Vi lägger till data i det andra steget i stället för det första om vi ser begränsade förbättringar eller om vi ser vissa försämringar på andra uppgifter. Vi använder LoRA för att undvika att avvika för mycket från generalistmodellen och riskera att förlora prestanda för att anpassa den till de specifika domänerna. Målet är att förbättra prestandan samtidigt som stommodellens allmänna kunskap behålls. Vi använder också en vikt när vi slår ihop LoRA med basmodellen igen, för att styra avvikelsen mer exakt och prioritera mätvärden på undanhållna data framför eventuella förbättringar inom domänen.

Slutligen lägger vi till ett bildspecifikt steg. Liksom det andra steget behandlas bildsteget som ytterligare ett finkornigt specialiseringssteg, med en LoRA-adapter som slås samman med basmodellen igen med en viss vikt. Vissa bildförmågor kan gå ut över textprestandan. Eftersom modellerna används betydligt mer för text prioriterar vi textmått framför bildmått.

För båda textstegen använder vi medelvärdet av vikterna från tre körningar, var och en med ett eget slumpmässigt frö. Vi fann att detta förbättrar den sammanslagna modellens prestanda och robusthet.

När den slutliga stora modellen är klar tillämpar vi samma träningsprocedur i tre steg på den mindre modellen. Här fungerar den stora modellen som lärare: dess förutsagda utdatafördelning ersätter guldetiketterna, och den mindre modellen tränas för att minimera KL-divergensen mellan sina förutsägelser och lärarens. Detta destillationsmål presterar bättre än korsentropi på samma träningsdata. Korsentropi presterar visserligen bättre på benchmarks med dedikerad träningsdata, men generaliserar sämre till undanhållna data. Vår hypotes är att destillation bättre överför lärarens utdatafördelning, inklusive dess konfidens för alternativ som inte är guldetiketter, medan korsentropi uppmuntrar överanpassning till den benchmarkspecifika träningsfördelningen. Vi använder därför det KL-baserade destillationsmålet.

För att motverka kontaminering mellan tränings- och testdata tar vi bort alla träningsexempel som kan överlappa med någon av de utvärderingar vi använder. Detta är viktigt eftersom vissa offentliga träningsdatamängder innehåller stora delar av vissa utvärderingsdatamängder. Vi genomför också omfattande granskningar och borttagning av bias för att säkerställa att våra förbättringar är tillförlitliga och inte bara drivs av inlärda bias.

Lägga till förmågan att extrahera information

Funktionen locate extraherar information, till exempel namngivna entiteter, ur text utan att ändra hur den besvarar vanliga förfrågningar. För att åstadkomma detta inför vi ytterligare ett träningssteg: vi lägger till en ny specialtoken, <|locate|>, ett span-huvud och en LoRA-adapter i Decider.

Vi initierar inbäddningen för <|locate|> från inbäddningen för <|marker|> som lärts in i de tidigare träningsstegen. Vi tränar bara denna nya inbäddning, span-huvudet och LoRA-adaptrarna, medan grundmodellens ursprungliga vikter och beslutshuvudet hålls frysta. Varje efterfrågat fält får en egen <|locate|>-token.

Span-huvudet använder representationen av <|locate|> tillsammans med representationerna av tillståndstokens för att poängsätta var matchande spann börjar och slutar, och vilka start–slut-par som hör ihop. Det använder också representationen av token <|locate|> för att förutsäga fältspecifika tröskelvärden för dessa poäng. Valda spann returneras som teckenpositioner i originaltexten.

Vi tränar span-huvudet med en anpassad InfoNCE-förlust som trycker upp varje guldspann över tröskelvärdet, och tröskelvärdet över alla andra spann. Förlusten har två termer: Den första trycker upp poängen för korrekta spann över tröskelvärdet och de felaktiga spannen. Den andra termen trycker upp tröskelvärdet över poängen för felaktiga spann. Fält utan svar får bara den andra termen, vilket lär modellen att returnera en tom lista.

Vi tränar på en blandning av uppgifter för extraktion av textavsnitt, däribland namngiven entitetsigenkänning, PII-detektering och extraktiv frågebesvaring. Vi varierar fältbeskrivningarna från korta etiketter till detaljerade instruktioner, så att modellen lär sig att följa förfrågan i stället för att memorera en fast uppsättning etiketter.

Locate lär modellen en strukturellt annorlunda uppgift, och vi vill lägga till den utan att förlora det som modellen redan gör bra. Att slå ihop locate-adaptrarna med stommodellen leder till vissa försämringar på beslutsförfrågningar. För att begränsa detta undersöker vi bland annat mer replay-data från tidigare steg och hjälpmål som håller modellens utdata för beslutsförfrågningar nära den ursprungliga modellens. Vi ser dock att sammanslagningen för närvarande fortfarande inte är förlustfri, så vi håller adaptrarna separata och aktiverar dem endast för locate-förfrågningar.

Utvärdering

Vi utvärderar Decider v1.3 och Decider Flash v1.3 på externa benchmarks från Hugging Face Decision Index, Vals AI:s ClaimBench och Artificial Analysis Decision Index.

I dessa utvärderingar visar våra modeller stark prestanda. Även om topplistorna innehåller privata uppgifter kan de fortfarande manipuleras genom upprepade inlämningar och iterativ finjustering utifrån återkoppling från topplistan. Som komplement till topplistorna utvärderar vi modellerna på en intern svit som kombinerar privata produktionsuppgifter med undanhållna utvärderingar hämtade från offentliga datamängder som inte är benchmarks. Dessa utvärderingar ger en extra kontroll av generaliseringen bortom offentliga benchmarks och hjälper oss att skilja bredare förbättringar från förbättringar som är specifika för välbekanta utvärderingssviter.

Internt har vi byggt en svit med fler än 200 uppgifter inom olika domäner och uppgiftstyper, som klassificering, poängsättning, omrankning och entitetsextraktion. För att ärligt bedöma Deciders prestanda i verkligheten utförs alla utvärderingar zero-shot, utan uppgiftsspecifik finjustering, vilket ger oss en tydlig signal om var modellen behöver förbättras.

Klassificering av sökfrågor

På Perplexity använder vi ett klassificeringssystem med flera huvuden för att bearbeta varje användarfråga. Varje fråga skickas först genom en inbäddningsmodell som fungerar som särdragsextraktor. Den resulterande inbäddningen matas sedan in i flera separata klassificeringshuvuden, däribland både binära klassificerare och klassificerare med flera etiketter. Ett huvud avgör till exempel om en användarfråga ska utlösa en webbsökning.

Över 63 klassificeringsuppgifter med referenser som oberoende märkts om av en frontier-LLM uppnår Decider v1.3 en genomsnittlig noggrannhet på 91,6 %, vilket överträffar våra produktionsklassificerare med 6,54 procentenheter. Decider Flash v1.3 överträffar också produktionsbaslinjen, medan Decider v1.3 överträffar Jev 1.14.

Domänspecifik klassificering

Vi har sammanställt en domänspecifik utvärderingssvit från offentliga datamängder för att bedöma beslutsmodellers klassificeringsprestanda inom sju domäner: verifiering av påståenden (6 uppgifter), hälso- och sjukvård (7), cybersäkerhet (8), programmering (16), offentlig förvaltning (7), juridik (9) och finans (9).

Till exempel ”bedöm tidskomplexiteten hos ett Python-program” eller ”använd en årsredovisning för att avgöra om ett företags fritt disponibla likvida medel täcker de skuldbelopp som förfaller inom de kommande tolv månaderna”. Decider v1.3 leder inom alla sju domäner och överträffar Jev 1.14 med upp till 12,9 procentenheter inom finans och 9,3 procentenheter inom juridik. Decider Flash v1.3 ligger efter Jev 1.14 inom finans, programmering och juridik och presterar likvärdigt inom övriga domäner.

Hämtning och omrankning

Sökning är kärnan i Perplexity. Vi har en bred svit med hämtningsuppgifter för att utvärdera våra modellers omrankningsprestanda. För varje uppgift använder vi först en pool av inbäddningsmodeller för att hämta de 50 bästa kandidatdokumenten från varje korpus. Sedan omrankar vi dessa kandidater med Decider och jämför dess prestanda med en stark baslinje för omrankning, Qwen3-Reranker-8B.

Vi utvärderar Decider zero-shot och punktvis, där modellen direkt poängsätter varje par av sökfråga och dokument oberoende av varandra och rankar dokumenten efter relevans. Över 72 hämtningsuppgifter uppnår Decider v1.3 ett genomsnittligt nDCG@10 på 83,99 och överträffar Qwen3-Reranker-8B med 1,81 poäng och Jev 1.14 med 2,24 poäng.

På BEIR-benchmarket överträffar båda modellerna Qwen3-Reranker-8B med 8,78 respektive 7,05 nDCG@10. Jämfört med Jev 1.14 ligger Decider v1.3 1,33 poäng högre, medan Flash-versionen ligger 0,4 poäng lägre.

Flerspråkig klassificering

För att utvärdera beslutsmodeller bortom engelska har vi sammanställt ett flerspråkigt klassificeringsbenchmark med 19 språkspecifika uppgifter från 8 offentliga datamängder, med 46 484 exempel på åtta språk: tyska, spanska, franska, italienska, ryska, japanska, koreanska och kinesiska. Benchmarket omfattar avsiktsigenkänning, ämnesklassificering, sentimentanalys, naturlig språkinferens, parafrasdetektering, detektering av stötande språk och grammatisk acceptabilitet.

Vi rapporterar genomsnittlig noggrannhet över uppgifterna inom varje språk, där varje uppgift viktas lika. Decider v1.3 överträffar Jev 1.14 på alla åtta språk och Decider Flash v1.3 gör det på sex, med en genomsnittlig uppgiftsnoggrannhet på 88,16 % för Decider v1.3 och 86,50 % för Decider Flash v1.3, jämfört med 85,41 % för Jev 1.14.

NER, PII och extraktiv QA

Vi utvärderar locate-funktionen på 17 uppgifter utanför träningsdomänen som testar dess extraktion inom olika domäner, indataformat (text, tabeller, strukturerade dokument) och instruktioner (korta etiketter, frågor och detaljerade beskrivningar). Domänerna sträcker sig från Wikipedia till vetenskapliga artiklar, rapporter om cyberhot, teknisk support, integritetspolicyer, CV:n och juridiska avtal. Förfrågningarna sträcker sig från korta etikettnamn som ”person” eller ”e-postadress”, via frågor om en tabell eller ett supportärende, till detaljerade fältbeskrivningar för strukturerad extraktion, till exempel parterna i ett sekretessavtal (NDA) eller totalbeloppet på en faktura.

Vi utvärderar NER och PII med F1 för exakta spann, vilket kräver att förutsagda spann matchar referensgränserna exakt. Extraktiv QA använder F1 på teckennivå, vilket ger delpoäng för överlappande svarstext, medan strukturerad extraktion använder fältnoggrannhet, det vill säga andelen fält som extraheras korrekt. För CV-tolkning beräknar vi medelvärdet av F1-poängen för exakta spann för NER och PII.

Vi jämför våra modeller med extraktionsmodeller för allmänna ändamål av olika storlekar: GLiNER large v2.5 (0,5B), Liquid d1 (2B) och Cloudflares Clairic (ej offentliggjord storlek). Decider v1.3 når ett genomsnittligt resultat på 69,0 (med varje uppgifts primära mått) och Decider Flash v1.3 når 63,6, jämfört med 43,3 för Liquid d1, 41,5 för Clairic och 33,6 för GLiNER large v2.5. Båda Decider-modellerna leder i alla kategorier.

Bildklassificering

Decider har haft inbyggt stöd för bilduppgifter sedan v1. För att utvärdera dess prestanda bortom text har vi sammanställt en benchmarksvit med fem uppgifter och särskilt fokus på dokumentklassificering, däribland fakturor, brev och CV:n. Sviten omfattar även klassificering av satellitbilder, texturklassificering, klassificering av husdjursraser och räkning av djur.

Decider v1.3 uppnår en genomsnittlig noggrannhet på 76,99 % över de fem visuella uppgifterna och överträffar Jev 1.14 med 1,47 procentenheter. Decider Flash v1.3 uppnår 72,77 %, vilket visar på visuell klassificeringsförmåga i en mindre modell.

Beslutsförfrågningar från verkligheten

Vi tog ett urval på en miljon deduplicerade, PII-maskerade förfrågningar som skickades till Perplexity Decision API under dess första 18 dagar av tillgänglighet. Eftersom varje förfrågan kan innehålla flera frågor om samma tillstånd omfattar urvalet 2 318 887 enskilda frågor. Alla förfrågningar inkluderades med uttryckligt tillstånd från användarna för forskningsändamål.

Förfrågningar i produktion levereras inte med facitetiketter, så vi använder frontier-LLM:er som bedömare för att generera referenssvar och mäter hur väl varje modell överensstämmer med dem. Vi grupperar också förfrågningarna i 10 uppgiftskategorier, däribland informationsextraktion, domänklassificering, sentimentanalys, avsikt och routning, relevansrankning, innehållsmoderering, kvalitets- och efterlevnadsgranskning, entitetsmatchning, affärsanalys samt kategorin ”Övrigt”. Denna uppdelning visar hur prestandan varierar mellan verkliga användningsfall.

Uppgiftsfördelningen är ojämn: informationsextraktion står för 425 402 frågor, domänklassificering för 409 564 och sentimentanalys för 344 158. Tillsammans utgör dessa tre kategorier 50,8 % av frågorna i urvalet.

Decider v1.3 uppnår högst överensstämmelse med bedömarna, 93,98 %, jämfört med 93,68 % för Decider v1.2 och 93,35 % för Jev 1.14. Decider v1.3 och Jev 1.14 ligger jämnt på domänklassificering och sentimentanalys, med skillnader på 0,34 respektive 0,07 procentenheter. Jev leder med 0,69 procentenheter på relevansrankning, medan Decider v1.3 leder med 0,93 procentenheter på informationsextraktion (den vanligaste uppgiften i urvalet) och med 1,21 procentenheter på avsikt och routning.

Diagrammet nedan jämför den rapporterade kostnaden för att köra samma uppsättning om en miljon produktionsförfrågningar. Varje förfrågan kan innehålla flera frågor, så enheten här är förfrågningar, inte enskilda frågor.

Decider kördes lokalt, GLM och DeepSeek använde llm-api och Jev använde OpenRouter. De rapporterade kostnaderna är specifika för arbetsbelastningen, med ospecificerad redovisning av lokala hårdvarukostnader och utan jämförelse vid matchad latens.

Robusthet

Vi utvärderade etikettkänslighet på 372 flervalsfrågor och skickade 4 788 förfrågningar per modell. Vi ändrade ordningen på alternativen, kopplade etiketterna till andra svarstexter och döpte om etiketter samtidigt som varje frågas betydelse bevarades, och kontrollerade sedan om modellens semantiska svar ändrades. En lägre andel ändrade svar innebär större stabilitet.

Decider v1.3 ändrade sitt svar på bara 0,27 % av frågorna under varje transformation, jämfört med 2,69–4,84 % för Jev 1.14. Vi upprepade också identiska indata för att mäta variationen vid servering: Decider v1.3 uppvisade inga förändringar, medan Jev 1.14 ändrade sitt svar på 1,88 % av frågorna.

Hur vi använder Decider

Decider är byggd för arbetsflöden som kräver snabba och strukturerade beslut. I det här avsnittet utforskar vi hur de kan användas för att göra verklig skillnad i hur vi arbetar. Här är några som stack ut.

Självförbättrande säkerhetsregler

Internt använder vi redan Decider för att förbättra våra säkerhetspolicyer.

Våra agenters aktivitet loggas och en serie regelbaserade kontroller utförs för att identifiera eventuellt problematiskt beteende. Ett regelbaserat tillvägagångssätt innebär att vi kan övervaka våra agenter i realtid med försumbar extra latens. Offline använder vi Decider för att granska stickprov ur dessa loggar över agenternas aktivitet. Om inget problematiskt beteende flaggades kontrollerar Decider om det finns något som våra regler missade, och om ett larm utlöstes kontrollerar Decider om det var ett falsklarm. Alla poster där vår regeluppsättning brister i något av fallen skickas till en agent för triagering, och en korrigering av reglerna föreslås, som sedan ska godkännas av en medlem i vårt säkerhetsteam.

På en dag läste Decider 1 miljard tokens fördelat på 7 000 agentsessioner och identifierade brister som ledde till 14 regelkorrigeringar, varav 6 godkändes och driftsattes inom två dagar. När korrigeringarna kördes om på en veckas loggar minskade volymen för vår mest belastade regel med 52 %, och de utvidgade reglerna fångade omkring 40 % fler legitima åtgärder att undersöka.

Övervakning av RL-rollouts

När vi efterträner modeller med förstärkningsinlärning förklarar aggregerade mått, som en slutlig belöning, inte varför en rollout (ett enskilt försök att lösa en uppgift) lyckades eller misslyckades. Den kan orättvist gå miste om belöning för att en verktygstjänst eller sandlådan slutade fungera, eller få en oförtjänt belöning om utvärderaren förbiser ett ostött påstående, till exempel ett påhittat värde som inget verktyg returnerade.

Vi använder Decider för att övervaka rollouts med avseende på dessa fall. Först identifierar kod de delar av en rollout som motiverar en närmare granskning: ett misslyckat verktygsanrop och det omgivande resonemanget, kod som kördes utan fel eller det slutliga svaret. Decider besvarar sedan flervalsfrågor om varje del, till exempel vad som gick fel i ett steg (en verktygstjänst, en extern webbplats, sandlådan, harness eller agentens egen kod) och om agenten tolkade resultatet korrekt. Vi samlar alla frågor om en viss del i en enda förfrågan och lagrar sannolikheterna i stället för ett utlåtande, så att vi kan justera tröskelvärdena senare utan att fråga Decider igen. Övervakningen observerar och diagnostiserar enbart: den ändrar aldrig en belöning och stoppar aldrig en körning.

Kvalitetsfiltrering av sidor

När vi crawlar webbsidor för att indexera dem och visa dem för användare håller många sidor för låg kvalitet för att vara till någon nytta. Det gäller antibot-spärrar, CAPTCHA:er och felsidor, men också korrekt inlästa webbsidor som helt enkelt inte innehåller någon användbar information, till exempel spam, SEO-utfyllnad eller sidor med enbart navigering. Dessa lågkvalitativa sidor måste identifieras och filtreras bort från vårt index.

Med Decider kan vi bedöma sidornas kvalitet medan vi crawlar dem. I samma framåtpass utför vi en rad andra klassificeringsuppgifter, till exempel att identifiera innehållets domän och avsedda målgrupp och om det innehåller skadlig, olaglig eller personligt identifierbar information. Jämfört med att använda en LLM som bedömare är Decider betydligt snabbare och billigare.

Illustrativ förfrågan om sidkvalitet: användbar information, avsedd målgrupp, skadligt eller olagligt innehåll och personligt identifierbar information bedöms utifrån samma sida.

Utöver dessa interna användningsområden passar Decider även för arbetsflöden som följande.

Visuell QA

Eftersom Decider kan läsa bilder fungerar den också som visuell granskare som går igenom stiländringar på webbsidor eller i appar och identifierar fel. Den kan granska skärmbilder av sidor efter avklippt text, överlappande element och trasiga layouter innan en ändring släpps, eller flagga diagram vars utformning kan vilseleda en läsare eller bryta mot en varumärkesmanual.

Webbläsarnavigering

Agenter kan använda Decider för de små besluten inom större uppgifter. En webbläsaragent kan skicka en skärmbild vid varje steg och få detaljerad information om sidans tillstånd och det förväntade utfallet av varje möjlig åtgärd.

Planering av forskningsuppgifter

Användarnas frågor kan variera mycket i komplexitet, liksom hur djup sökning som krävs för att hitta ett svar. Decider kan uppskatta detta innan sökningen börjar, så att mindre resurser läggs på enkla frågor.

Kom igång

Decider returnerar sannolikheter. Vilket beslutströskelvärde som är lämpligt beror på tillämpningen. Etikettfrekvenser och de relativa kostnaderna för falska positiva och falska negativa varierar mellan användningsfall. Vi uppmuntrar därför användare att justera tröskelvärdena på en liten, representativ märkt utvecklingsmängd i stället för att anta att en fast gräns fungerar lika bra för alla uppgifter.

Vi rekommenderar Decider v1.3 för nyanserade bedömningar, detaljerade bedömningsmallar och arbetsflöden där fel är kostsamma. Välj Decider Flash v1.3 för routning, märkning och filtrering i stora volymer där latens och kostnad är de främsta begränsningarna. Utvärdera båda modellerna på representativa exempel från din arbetsbelastning och välj sedan den modell som uppfyller dina krav på kvalitet, latens och budget.

Båda modellerna finns tillgängliga som nedladdningsbara vikter på Hugging Face under Apache-licens, via OpenRouter och via Perplexity Decisions API.

Citering

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