Perplexity Decider

We brengen Decider v1.3 en Decider Flash v1.3 uit, de opvolgers van onze eerdere beslissingsmodellen: v1, v1.1, v1.2 en Flash v1.2.

Decider Flash v1.3 is een kleiner model dat is gedistilleerd uit Decider v1.3. Beide modellen zijn beschikbaar op Hugging Face onder de Apache-licentie, via OpenRouter en via de Perplexity Decisions API.

Perplexity Decider is geïnspireerd op Jev, het System One Model van TypeSafe AI. Het ondersteunt binaire en multiclass-classificatie met geordende of ongeordende labels en retourneert kansen die toepassingen kunnen gebruiken om invoer te classificeren, routeren, rangschikken en evalueren.

Beide v1.3-modellen verbeteren de prestaties en robuustheid bij een breed scala aan tekst- en visietaken dankzij bidirectionele attention, beter samengestelde trainingsdata en een verfijnd trainingsrecept. We introduceren ook locate, een nieuwe functie die de geselecteerde content markeert voor taken als named entity recognition, identificatie van persoonsgegevens en extractieve vraagbeantwoording.

In dit bericht leggen we uit hoe we Decider trainen en evalueren, en delen we hoe we het intern bij Perplexity gebruiken.

Wat is een beslissingsmodel?

Een beslissingsmodel is een classificator voor algemeen gebruik. Je geeft het een invoer en een reeks vragen, elk met de mogelijke antwoorden. Voor elke vraag retourneert het een kansverdeling over de antwoorden. Het ondersteunt 3 vraagtypen:

• Ja / Nee: binaire beslissingen.
• Meerkeuze: aangepaste labels voor meerdere klassen.
• Score: geordende niveaus.

Beslissingsmodellen ondersteunen een breed scala aan classificatie- en scoretaken:

• Outputs beoordelen: getrouwheid, kwaliteit en veiligheid evalueren.
• Routering: verzoeken op basis van moeilijkheid naar kleinere of grotere modellen sturen.
• Moderatie en beveiliging: schadelijke content, phishing en promptinjectie in tooluitvoer detecteren.
• Filteren en taggen: grote verzamelingen content organiseren.
• Retrieval en reranking: zoekresultaten scoren op relevantie.

Veel van deze taken werden voorheen uitgevoerd door generatieve modellen zoals LLM's, hoewel ze geen vrije tekstgeneratie vereisen. Beslissingsmodellen zitten tussen LLM's en taakspecifieke classifiers in. Ze geven in één forward pass kansen terug voor meerdere vragen over dezelfde input, waardoor antwoorden niet token voor token gegenereerd hoeven te worden en rekenwerk over vragen heen wordt gedeeld. In tegenstelling tot taakspecifieke classifiers kunnen ze nieuwe taken aan via prompts in natuurlijke taal, een flexibiliteit die ze hebben geleerd door training op uiteenlopende taken in een gedeeld vraag-antwoordformaat.

Training

Van generatieve LLM naar beslissingsmodel

We bouwen Decider door sterke generatieve LLM-backbones aan te passen. Om die aanpassing uit te leggen, beschrijven we eerst hoe een verzoek wordt gerepresenteerd. Zoals hieronder geïllustreerd, bestaat een verzoek uit een gedeelde context (de state) en een aantal vragen. De state wordt door alle vragen hergebruikt.

Bij een document en de samenvatting ervan kan één verzoek bijvoorbeeld vragen of de samenvatting het document getrouw weergeeft en of die bedoeld is voor een expert of voor een algemeen publiek. Na de state bevat elk vraagblok een vraag en de mogelijke antwoorden, die elk een vooraf gedefinieerd labeltoken krijgen, zoals A, B of C. Een speciaal <|marker|>-token geeft aan waar de voorspelling van het model wordt uitgelezen. Op deze positie zet een geleerde lineaire outputlaag (een decision head) de hidden state om in scores voor de antwoordopties van de vraag, die vervolgens worden omgezet in kansen.

Vergroten

We initialiseren de outputlaag vanuit het basismodel, dat normaal gesproken het volgende token scoort over de hele vocabulaire, en behouden alleen de rijen die overeenkomen met de vooraf gedefinieerde optietokens, zoals A, B of C. Deze gesnoeide laag wordt vervolgens getraind om de hidden state van <|marker|> om te zetten in antwoordscores. Deze aanpak dekt alle classificatievragen, omdat ze allemaal als meerkeuzevraag kunnen worden geformuleerd.

Voor de training nemen we honderden openbare datasets met uiteenlopende taken (sentiment, natural language inference, intentiedetectie, entiteitsmatching, moderatie, factchecking, beoordelingen enz.) en zetten we elk voorbeeld om naar het hierboven beschreven uniforme formaat: een state, een of meer vragen, de bijbehorende opties en een target. Het target kan de enige juiste optie zijn als we gold labels hebben, of een kansverdeling over de opties.

In v1.3 introduceren we locate, dat tekst uit de state extraheert in plaats van te kiezen uit vooraf gedefinieerde opties. Een locate-vraag beschrijft wat er gevonden moet worden, met een kort label zoals “locatie” of een instructie zoals “Extraheer de naam van de stad waar de vacature zich bevindt.” Het model retourneert de exact overeenkomende tekst uit de state, samen met de begin- en eindpositie in tekens. Als het geen overeenkomsten vindt, retourneert het een lege lijst.

Vergroten

Dankzij de gedeelde state kan één verzoek locate-, classificatie- en scorevragen over dezelfde invoer combineren. Zo kan het bijvoorbeeld vragen of een vacature ervaring op seniorniveau vereist en de vereiste vaardigheden extraheren.

Bidirectionele attention: het model in beide richtingen laten lezen

Onze modellen starten vanuit sterke voorgetrainde generatieve backbones, waarvan de causale attention elk token alleen laat letten op zichzelf en voorgaande tokens. Uit onze ablatiestudies bleek dat het bidirectioneel maken van de full-attention-lagen van de backbone de prestaties verbetert. Daarom passen we dit ontwerp toe, zodat elk token context uit de volledige invoer kan meenemen.

Bidirectionele attention brengt nog een ontwerpkeuze met zich mee: hoe moeten de state en de vragen met elkaar interageren? We hebben drie attentionpatronen overwogen, met verschillende gevolgen voor prestaties, antwoordstabiliteit en hergebruik van de cache:

• Alles ziet alles (v1.2): De state en alle vragen worden samen verwerkt met volledige bidirectionele attention. De berekening over de state wordt gedeeld, maar het antwoord op een vraag kan veranderen afhankelijk van wat er verder wordt gevraagd.
• Geïsoleerde vragen (v1.3): De state let op alle vragen, terwijl elke vraag alleen op de state en haar eigen tokens let. Vragen kunnen elkaar nog steeds indirect beïnvloeden via de gedeelde state, maar de resultaten zijn stabieler.
• Volledig cachebaar: De state attendeert alleen op zichzelf, terwijl elke vraag attendeert op de state en haar eigen tokens. De state is onafhankelijk van de vragen en herbruikbaar over verzoeken heen, zodat prompt caching kan worden benut. We gebruiken dit niet standaard, omdat het voor verschillende taken veel uitmaakt dat de state de vragen kan zien, maar met een kleine fine-tuning kan een model hierop worden overgeschakeld.

Uiteindelijk kozen we voor geïsoleerde vragen vanwege de sterke prestaties en stabiliteit.

Vergroten

Trainingsrecept

De training verloopt voor beide modelgroottes in drie fasen. We trainen eerst het grotere model, gebaseerd op Qwen3.8-27B, met cross-entropy op grote datasets en distilleren het vervolgens naar het kleinere Qwen3.5-4B-model.

De eerste fase is generalistische training, waarbij we het model volledig fine-tunen op grootschalige corpora. In deze fase accepteren we alleen data die het model over de hele linie helpt en niet specifiek is voor een benchmark; daarom sluiten we alle trainingssplits van benchmarks uit.

Nadat dit generalistische model is getraind, voeren we een tweede, fijnmaziger fase uit met LoRA. De data in deze fase is gericht op specifieke domeinen en taken. We voegen data toe in de tweede fase in plaats van in de eerste als we slechts beperkte winst zien of als we regressies op andere taken waarnemen. We gebruiken LoRA om niet te ver af te drijven van het generalistische model en te voorkomen dat we prestaties inleveren om die specifieke domeinen te bedienen. Het doel is de prestaties te verbeteren en tegelijk de algemene kennis van de backbone te behouden. We gebruiken ook een gewicht bij het terugmergen van de LoRA in het basismodel, om de drift preciezer te sturen en held-out-metrics voorrang te geven boven winst binnen het domein.

Ten slotte voegen we een visiespecifieke stap toe. Net als de tweede fase wordt de visiestap behandeld als een extra fijnmazige specialisatiestap, met een LoRA-adapter die met een gewicht weer in het basismodel wordt samengevoegd. Sommige visiemogelijkheden kunnen ten koste gaan van de tekstprestaties. Omdat we veel meer gebruik van de modellen op tekst zien, geven we voorrang aan tekstmetrics boven visiemetrics.

Voor beide tekstfasen gebruiken we de gemiddelde gewichten van drie runs, elk met een andere willekeurige seed. We merkten dat dit de prestaties en robuustheid van het samengevoegde model verbetert.

Zodra het uiteindelijke grote model gereed is, passen we dezelfde training in drie fasen toe op het kleinere model. Hier fungeert het grote model als teacher: de voorspelde outputdistributie ervan vervangt de gold labels, en het kleinere model wordt getraind om de KL-divergentie tussen zijn eigen voorspellingen en die van de teacher te minimaliseren. Dit distillatiedoel presteert beter dan cross-entropy op dezelfde trainingsdata. Hoewel cross-entropy beter presteert op benchmarks met specifieke trainingsdata, generaliseert het minder goed naar held-out data. Onze hypothese is dat distillatie de outputdistributie van de teacher beter overdraagt, inclusief de zekerheid over niet-gold alternatieven, terwijl cross-entropy overfitting op de benchmarkspecifieke trainingsdistributie in de hand werkt. Daarom kiezen we voor het op KL gebaseerde distillatiedoel.

Om besmetting tussen trainings- en testdata te beperken, verwijderen we alle trainingsvoorbeelden die zouden kunnen overlappen met een van de evaluaties die we gebruiken. Dit is belangrijk omdat sommige openbare trainingsdatasets grote delen van bepaalde evaluatiedatasets bevatten. We voeren ook uitgebreide bias-audits uit en verwijderen bias, zodat onze winst betrouwbaar is en niet alleen voortkomt uit aangeleerde bias.

De mogelijkheid toevoegen om informatie te extraheren

De locate functie extraheert informatie zoals named entities uit tekst, zonder te veranderen hoe het model gewone verzoeken beantwoordt. Daarvoor introduceren we een extra trainingsfase: we voegen een nieuw speciaal token, <|locate|>, een span head en een LoRA-adapter toe aan Decider.

We initialiseren de embedding van <|locate|> vanuit <|marker|>, zoals geleerd in de vorige trainingsfasen. We trainen alleen deze nieuwe embedding, de span head en de LoRA-adapters, terwijl de oorspronkelijke backbonegewichten en de decision head bevroren blijven. Elk gevraagd veld krijgt een eigen <|locate|>-token.

De span-head gebruikt de representatie van <|locate|> samen met de representaties van de state-tokens om te scoren waar overeenkomende spans beginnen en eindigen, en welke begin-eindparen bij elkaar horen. Daarnaast gebruikt hij de representatie van het <|locate|>-token om veldspecifieke drempelwaarden voor deze scores te voorspellen. Geselecteerde spans worden teruggegeven als tekenposities in de oorspronkelijke tekst.

We trainen de span-head met een aangepaste InfoNCE-loss die elke gold span boven de drempelwaarde duwt, en de drempelwaarde boven elke andere span. De loss bestaat uit twee termen: de eerste duwt de scores van correcte spans boven de drempelwaarde en de foute spans. De tweede term duwt de drempelwaarde boven de scores van foute spans. Velden zonder antwoord krijgen alleen de tweede term, waardoor het model leert een lege lijst terug te geven.

We trainen op een mix van span-extractietaken, waaronder named entity recognition, PII-detectie en extractieve vraagbeantwoording. We variëren de veldbeschrijvingen van korte labels tot gedetailleerde instructies, zodat het model leert het verzoek te volgen in plaats van een vaste set labels uit het hoofd te leren.

Locate leert het model een structureel andere taak, en die willen we toevoegen zonder te verliezen waar het model al goed in is. Het mergen van de locate-adapters in de backbone veroorzaakt enige regressie bij beslissingsverzoeken. Om dit te beperken, doen we onderzoek naar onder meer extra replay-data uit eerdere fasen en hulpdoelen die de outputs van het model bij beslissingsverzoeken dicht bij die van het oorspronkelijke model houden. We merken echter dat mergen momenteel nog niet verliesvrij is, dus houden we de adapters gescheiden van de backbone en activeren we ze alleen voor locate-verzoeken.

Evaluatie

We evalueren Decider v1.3 en Decider Flash v1.3 op externe benchmarks uit de Hugging Face Decision Index, ClaimBench van Vals AI en de Artificial Analysis Decision Index.

In al deze evaluaties laten onze modellen sterke prestaties zien. Hoewel deze leaderboards ook niet-openbare taken bevatten, kunnen ze nog steeds worden gemanipuleerd door herhaaldelijk in te dienen en iteratief bij te stellen op basis van feedback van het leaderboard. Als aanvulling op deze leaderboards evalueren we de modellen op een interne suite die niet-openbare productietaken combineert met held-out-evaluaties op basis van openbare datasets die geen benchmark zijn. Deze evaluaties bieden een extra controle op generalisatie buiten openbare benchmarks, zodat we bredere verbeteringen kunnen onderscheiden van winst die specifiek is voor bekende evaluatiesuites.

Intern hebben we een suite van meer dan 200 taken gebouwd die verschillende domeinen en taken omvatten, zoals classificatie, scoring, reranking en entiteitsextractie. Om de prestaties van Decider in de praktijk eerlijk te beoordelen, worden alle evaluaties zero-shot uitgevoerd, zonder taakspecifieke fine-tuning. Zo krijgen we een duidelijk signaal over waar het model beter kan.

Queryclassificatie

Bij Perplexity gebruiken we een classificatiesysteem met meerdere heads om elke gebruikersquery te verwerken. Elke query gaat eerst door een embeddingmodel dat als feature-extractor fungeert. De resulterende embedding wordt vervolgens ingevoerd in meerdere afzonderlijke classificatieheads, waaronder zowel binaire als multilabelclassificatoren. Eén head bepaalt bijvoorbeeld of een gebruikersquery een zoekopdracht op het web moet activeren.

Over 63 classificatietaken met referenties die onafhankelijk opnieuw zijn gelabeld door een frontier-LLM behaalt Decider v1.3 een gemiddelde nauwkeurigheid van 91,6% en presteert daarmee 6,54 procentpunten beter dan onze productieclassificatoren. Ook Decider Flash v1.3 presteert beter dan de productiebaseline, terwijl Decider v1.3 beter presteert dan Jev 1.14.

Vergroten

Domeinspecifieke classificatie

We hebben op basis van openbare datasets een domeinspecifieke evaluatiesuite samengesteld om de classificatieprestaties van beslissingsmodellen in zeven domeinen te beoordelen: claimverificatie (6 taken), gezondheidszorg (7), cybersecurity (8), programmeren (16), overheid (7), recht (9) en financiën (9).

Bijvoorbeeld “beoordeel de tijdcomplexiteit van een Python-programma” of “gebruik een jaarverslag om te bepalen of de vrij beschikbare liquide middelen van een bedrijf de aflossing van schulden dekken die binnen de komende twaalf maanden vervalt”. Decider v1.3 scoort het best in alle zeven domeinen en presteert tot 12,9 procentpunten beter dan Jev 1.14 in financiën en 9,3 punten beter in recht. Decider Flash v1.3 blijft achter bij Jev 1.14 in financiën, programmeren en recht, en presteert vergelijkbaar in de andere domeinen.

Vergroten

Retrieval en reranking

Zoeken vormt de kern van Perplexity. We onderhouden een brede suite van retrievaltaken om de rerankingprestaties van onze modellen te evalueren. Voor elke taak gebruiken we eerst een pool van embeddingmodellen om de top 50 kandidaatdocumenten uit elk corpus op te halen. Vervolgens herrangschikken we deze kandidaten met Decider en vergelijken we de prestaties met een sterke reranker-baseline, Qwen3-Reranker-8B.

We evalueren Decider in een zero-shot, pointwise setting, waarbij het model elk query-documentpaar direct en onafhankelijk scoort en documenten op relevantie rangschikt. Over 72 retrievaltaken behaalt Decider v1.3 een gemiddelde nDCG@10 van 83,99 en presteert daarmee 1,81 punten beter dan Qwen3-Reranker-8B en 2,24 punten beter dan Jev 1.14.

Op de BEIR-benchmark presteren beide modellen respectievelijk 8,78 en 7,05 nDCG@10 beter dan Qwen3-Reranker-8B. Ten opzichte van Jev 1.14 scoort Decider v1.3 1,33 punten hoger, terwijl de Flash-versie 0,4 lager scoort.

Vergroten

Meertalige classificatie

Om beslissingsmodellen ook buiten het Engels te evalueren, hebben we een meertalige classificatiebenchmark samengesteld met 19 taalspecifieke taken uit 8 openbare datasets, met 46.484 voorbeelden in acht talen: Duits, Spaans, Frans, Italiaans, Russisch, Japans, Koreaans en Chinees. De benchmark omvat intentiedetectie, onderwerpclassificatie, sentimentanalyse, natural language inference, parafrasedetectie, detectie van beledigend taalgebruik en grammaticale aanvaardbaarheid.

We rapporteren de gemiddelde nauwkeurigheid over de taken binnen elke taal, waarbij elke taak even zwaar weegt. Decider v1.3 presteert in alle acht talen beter dan Jev 1.14 en Decider Flash v1.3 in zes talen, met een gemiddelde taaknauwkeurigheid van 88,16% voor Decider v1.3 en 86,50% voor Decider Flash v1.3, tegenover 85,41% voor Jev 1.14.

Vergroten

NER, PII en extractieve QA

We evalueren de locate-functie op 17 out-of-domain-taken die de extractie testen over verschillende domeinen, invoerformaten (tekst, tabellen, gestructureerde documenten) en instructies (korte labels, vragen en gedetailleerde beschrijvingen). De domeinen variëren van Wikipedia tot wetenschappelijke artikelen, rapporten over cyberdreigingen, technische ondersteuning, privacybeleid, cv's en juridische contracten. De verzoeken variëren van korte labelnamen zoals “persoon” of “e-mailadres”, via vragen over een tabel of een supportticket, tot gedetailleerde veldbeschrijvingen voor gestructureerde extractie, zoals de partijen bij een NDA of het totaalbedrag op een factuur.

We evalueren NER en PII met exact-span-F1, waarbij voorspelde spans exact moeten overeenkomen met de referentiegrenzen. Extractieve QA gebruikt F1 op tekenniveau, die gedeeltelijk punten toekent voor overlappende antwoordtekst, terwijl gestructureerde extractie veldnauwkeurigheid gebruikt: het aandeel velden dat correct is geëxtraheerd. Voor het parsen van cv's nemen we het gemiddelde van de exact-span-F1-scores voor NER en PII.

We vergelijken onze modellen met extractiemodellen voor algemeen gebruik van verschillende groottes: GLiNER large v2.5 (0,5B), Liquid d1 (2B) en Clairic van Cloudflare (niet bekendgemaakt). Decider v1.3 behaalt een gemiddelde score van 69,0 (op basis van de primaire metric van elke taak) en Decider Flash v1.3 haalt 63,6, tegenover 43,3 voor Liquid d1, 41,5 voor Clairic en 33,6 voor GLiNER large v2.5. Beide Decider-modellen scoren het best in elke categorie.

Vergroten

Beeldclassificatie

Decider ondersteunt sinds v1 native visietaken. Om de prestaties buiten tekst te evalueren, hebben we een benchmarksuite van vijf taken samengesteld met bijzondere aandacht voor documentclassificatie, waaronder facturen, brieven en cv's. De suite omvat ook classificatie van satellietbeelden, textuurclassificatie, classificatie van huisdierrassen en het tellen van dieren.

Decider v1.3 behaalt een gemiddelde nauwkeurigheid van 76,99% over de vijf visuele taken en presteert daarmee 1,47 procentpunten beter dan Jev 1.14. Decider Flash v1.3 behaalt 72,77%, wat laat zien dat ook een kleiner model visuele classificatie beheerst.

Vergroten

Beslissingsverzoeken uit de praktijk

We namen een steekproef van een miljoen gededupliceerde verzoeken met gemaskeerde PII die in de eerste 18 dagen van beschikbaarheid bij de Perplexity Decision API zijn ingediend. Omdat elk verzoek meerdere vragen over dezelfde state kan bevatten, omvat de steekproef 2.318.887 afzonderlijke vragen. Alle verzoeken zijn met uitdrukkelijke toestemming van de gebruiker voor onderzoek opgenomen.

Productieverzoeken hebben geen ground-truth-labels, dus gebruiken we frontier-LLM's als beoordelaars om referentieantwoorden te genereren en meten we in hoeverre elk model daarmee overeenstemt. We delen de verzoeken ook in 10 taakcategorieën in, waaronder informatie-extractie, domeinclassificatie, sentimentanalyse, intentie en routering, relevantierangschikking, contentmoderatie, kwaliteits- en compliancecontrole, entiteitsmatching, bedrijfsanalyse en een categorie “Overig”. Deze uitsplitsing laat zien hoe de prestaties variëren tussen praktijkgevallen.

De takenmix is ongelijk verdeeld: informatie-extractie is goed voor 425.402 vragen, domeinclassificatie voor 409.564 en sentimentanalyse voor 344.158. Samen vormen deze drie categorieën 50,8% van de vragen in de steekproef.

Decider v1.3 stemt met 93,98% het meest overeen met de beoordelaars, tegenover 93,68% voor Decider v1.2 en 93,35% voor Jev 1.14. Decider v1.3 en Jev 1.14 liggen dicht bij elkaar bij domeinclassificatie en sentimentanalyse, met verschillen van respectievelijk 0,34 en 0,07 procentpunten. Jev loopt 0,69 punten voor bij relevantierangschikking, terwijl Decider v1.3 0,93 punten voorloopt bij informatie-extractie (de meest voorkomende taak in de steekproef) en 1,21 punten bij intentie en routering.

Vergroten

De onderstaande grafiek vergelijkt de gerapporteerde kosten voor het uitvoeren van dezelfde set van een miljoen productieverzoeken. Elk verzoek kan meerdere vragen bevatten, dus de eenheid is hier verzoeken, niet afzonderlijke vragen.

Vergroten

Robuustheid

We evalueerden de labelgevoeligheid op 372 meerkeuzevragen, met 4.788 verzoeken per model. We wijzigden de volgorde van de opties, wezen labels opnieuw toe aan antwoordteksten en hernoemden labels met behoud van de betekenis van elke vraag, en controleerden daarna of het semantische antwoord van het model veranderde. Een lager percentage omgeslagen antwoorden wijst op meer stabiliteit.

Decider v1.3 veranderde bij elke transformatie zijn antwoord op slechts 0,27% van de vragen, tegenover 2,69–4,84% bij Jev 1.14. We herhaalden ook identieke invoer om de variabiliteit bij serving te meten: Decider v1.3 vertoonde geen veranderingen, terwijl Jev 1.14 bij 1,88% van de vragen veranderde.

Vergroten

Hoe we Decider gebruiken

Decider is gebouwd voor workflows die snelle en gestructureerde beslissingen vereisen. In dit gedeelte bekijken we hoe we die kunnen inzetten om onze manier van werken merkbaar te verbeteren. Hier zijn enkele toepassingen die eruit sprongen.

Zelfverbeterende beveiligingsregels

Intern gebruiken we Decider al om ons beveiligingsbeleid te verbeteren.

De activiteit van onze agents wordt vastgelegd en er wordt een reeks regelgebaseerde controles uitgevoerd om problematisch gedrag op te sporen. Dankzij een regelgebaseerde aanpak kunnen we onze agents in realtime monitoren met verwaarloosbare extra latentie. Offline gebruiken we Decider om steekproeven uit deze vastgelegde agentlogs te bekijken. Als er geen problematisch gedrag is gemarkeerd, controleert Decider of onze regels iets hebben gemist; en als er wel een alarm is afgegaan, controleert Decider of het om een vals alarm ging. Alle records waarbij onze regelset in een van beide gevallen faalt, worden voor triage naar een agent gestuurd die een aanpassing van de regels voorstelt, die vervolgens moet worden goedgekeurd door een lid van ons securityteam.

In één dag las Decider 1 miljard tokens in 7.000 agentsessies en spoorde het gebreken op die leidden tot 14 regelaanpassingen, waarvan er 6 binnen twee dagen werden goedgekeurd en uitgerold. Toen we een week aan logs opnieuw afspeelden, verminderden de aanpassingen het volume van onze drukste regel met 52%, en vingen de verruimde regels ongeveer 40% meer legitieme acties om te onderzoeken.

Vergroten

RL-rollouts monitoren

Wanneer we modellen post-trainen met reinforcement learning, verklaren geaggregeerde metrics zoals een eindbeloning niet waarom een rollout (een individuele poging om een taak uit te voeren) is geslaagd of mislukt. Een rollout kan onterecht beloning mislopen doordat een tooldienst of de sandbox faalde, of onverdiend beloning krijgen als de beoordelaar een ononderbouwde bewering over het hoofd ziet, zoals een verzonnen waarde die door geen enkele tool is geretourneerd.

We gebruiken Decider om rollouts op deze gevallen te monitoren. Eerst identificeert code de delen van een rollout die nader onderzoek verdienen: een mislukte toolaanroep en de redenering eromheen, code die zonder fouten is uitgevoerd, of het uiteindelijke antwoord. Vervolgens beantwoordt Decider meerkeuzevragen over elk deel, zoals wat er in een stap misging (een tooldienst, een externe site, de sandbox, de harness of de eigen code van de agent) en of de agent het resultaat correct heeft geïnterpreteerd. We bundelen alle vragen over een bepaald deel in één verzoek en slaan de kansen op in plaats van een oordeel, zodat we drempelwaarden later kunnen aanpassen zonder Decider opnieuw te bevragen. De monitor observeert en diagnosticeert alleen: hij wijzigt nooit een beloning en stopt nooit een run.

Vergroten

Filteren op paginakwaliteit

Bij het crawlen van webpagina's om ze te indexeren en aan gebruikers te tonen, blijken veel pagina's van te lage kwaliteit om nuttig te zijn. Het gaat om anti-botmuren, CAPTCHA's en foutpagina's, maar ook om correct geladen webpagina's die simpelweg geen nuttige informatie bevatten, zoals spam, SEO-opvulling of pagina's met alleen navigatie. Deze pagina's van lage kwaliteit moeten worden herkend en uit onze index worden gefilterd.

Met Decider kunnen we de kwaliteit van pagina's beoordelen terwijl we ze crawlen. In dezelfde forward pass voeren we een reeks andere classificatietaken uit, zoals het bepalen van het domein en de beoogde doelgroep van de content en of deze schadelijke, illegale of persoonlijk identificeerbare informatie bevat. Vergeleken met een LLM als beoordelaar is Decider aanzienlijk sneller en goedkoper.

Vergroten

Naast deze interne toepassingen past Decider ook bij workflows zoals de volgende.

Visuele QA

Omdat Decider afbeeldingen kan lezen, werkt het ook als visuele controleur: het beoordeelt stijlwijzigingen in webpagina's of apps en spoort fouten op. Het kan screenshots van pagina's controleren op afgekapte tekst, overlappende elementen en kapotte lay-outs voordat een wijziging live gaat, of grafieken markeren waarvan het ontwerp een lezer kan misleiden of een huisstijlgids kan schenden.

Vergroten

Browsernavigatie

Agents kunnen Decider gebruiken voor de kleine beslissingen binnen grotere taken. Een browseragent kan bij elke stap een screenshot sturen en gedetailleerde informatie ontvangen over de staat van de pagina en de verwachte uitkomst van elke mogelijke actie.

Vergroten

Onderzoekstaken plannen

De vragen van gebruikers kunnen sterk verschillen in complexiteit, net als de zoekdiepte die nodig is om een antwoord te vinden. Decider kan dit inschatten voordat het zoeken begint, zodat er minder resources aan eenvoudige vragen worden besteed.

Vergroten

Aan de slag

Decider retourneert kansen. De geschikte beslissingsdrempel hangt af van de toepassing. Labelfrequenties en de relatieve kosten van fout-positieven en fout-negatieven verschillen per use case. We raden gebruikers daarom aan drempelwaarden af te stemmen op een kleine, representatieve gelabelde ontwikkelset, in plaats van aan te nemen dat een vaste grenswaarde voor alle taken even goed werkt.

We raden aan Decider v1.3 te gebruiken voor genuanceerde oordelen, gedetailleerde beoordelingscriteria en workflows waarin fouten kostbaar zijn. Kies Decider Flash v1.3 voor routing, labeling en filtering op grote schaal, waarbij latentie en kosten de belangrijkste beperkingen zijn. Evalueer beide modellen op representatieve voorbeelden uit je eigen workload en kies vervolgens het model dat voldoet aan je eisen voor kwaliteit, latentie en budget.

Beide modellen zijn beschikbaar als downloadbare gewichten op Hugging Face onder de Apache-licentie, via OpenRouter en via de Perplexity Decisions API.

Citatie

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