Perplexity: Decider V1.1 27B

Decider V1.1 27B is het bijgewerkte beslissingscheckpoint van Perplexity. Het evalueert aangeleverde inhoud aan de hand van een gedefinieerde vraag en produceert kansen over de geldige antwoorden. Het native artefact heeft een beslissingsreadout in plaats van een taalgeneratiekop voor de volledige woordenschat. Het bruikbare resultaat is een afgebakende beslissingsverdeling met het geïnterpreteerde antwoord, geen open uitleg en geen algemeen chatantwoord.

Wat er verandert in de editie V1.1

Perplexity omschrijft dit model als een update van Decider V1 27B die dezelfde backbone behoudt, met wijzigingen in de attention-opzet en meer trainingsdata. De backbone is Qwen3.8-27B. De editie V1.1 behoudt haar eigen naam en configuratie en wordt niet beschreven als een uitwisselbare kopie van het eerdere checkpoint.

Toestand, vraag en geldige antwoorden

Het gepubliceerde voorbeeld levert een rij met een toestand en een getypeerde keuzevraag. De vraag bevat instructies en criteria waarvan de sleutels de semantische antwoorden zijn en waarvan de beschrijvingen bepalen wanneer elk antwoord van toepassing is. Het model voorspelt kansen, waarna de antwoordhelper van de producent die kansen voor de vraag interpreteert. Het inferentievoorbeeld kan een lijst met rijen verwerken, met één beslissing per rij, gekoppeld aan het bewijsmateriaal en de vraag van die rij.

Lever voor het routeren van verzoeken het werkelijke bericht en de relevante context aan, en definieer vervolgens de beschikbare afdelingen of categorieën. Een illustratieve taak kan onderscheid maken tussen een integratiestoring, een toegangsprobleem en een verzoek om productinformatie. Maak elke beschrijving precies genoeg om een grensgeval te beslechten, en bewaar de optiedefinities bij het resultaat. Een categorieverdeling kan dan een routeringsbeslissing ondersteunen, of een reviewstap wanneer alternatieven dicht bij elkaar blijven liggen. Het gekozen resultaat van het model voert de workflowactie zelf niet uit.

Bewijs in tekst en afbeeldingen

De native implementatie accepteert afbeeldingen naast de toestand en de vraag, via afbeeldingsbestanden, afbeeldingen in het geheugen of gecodeerde afbeeldingsdata. Lever bij een documentafbeelding of screenshot het visuele bewijs aan en stel een gesloten vraag waarvan de opties de relevante uitkomsten beschrijven. Benoem het zichtbare kenmerk dat ertoe doet en geef de tekstcontext die nodig is om het te interpreteren. Classificeer bijvoorbeeld of een afgebeeld artikel tot een van de aangeleverde productcategorieën behoort, in plaats van het beslissingsmodel te vragen een volledige productbeschrijving te schrijven.

De processor behoudt de beeldverhouding bij het schalen en rondt de zijden van een afbeelding af op veelvouden van 32 pixels. Het gedocumenteerde verwerkte oppervlak begint bij 65.536 pixels en wordt begrensd door een configureerbaar maximum; de standaardwaarde is 4.194.304 pixels, oftewel 2048 bij 2048. Elke patch van 32 bij 32 levert één visueel token op, zodat die standaardwaarde tot 4.096 visuele tokens per afbeelding toelaat. Deze cijfers beschrijven de native afbeeldingsvoorbereiding van de producent, geen algemeen uploadcontract voor applicaties.

Gecombineerde invoerlimieten en reikwijdte van de resolutie

De gedocumenteerde voorbereidingsstap vereist dat de tekst en alle afbeeldingen van één beslissing binnen 8.192 tokens passen. Te grote invoer wordt geweigerd en niet stilzwijgend afgekapt. Meerdere afbeeldingen delen dat budget met de geschreven toestand en vraag. Verminder irrelevante brontekst of verlaag de limiet voor de afbeeldingsgrootte bij het voorbereiden van een gecombineerde beslissing, en behoud het detail dat het antwoord bepaalt.

De training en de gerapporteerde evaluatieopzet begrensden afbeeldingen op 512 bij 512, wat overeenkomt met 262.144 pixels en tot 256 visuele tokens. De configureerbare limiet bij inferentie kan meer detail behouden, maar de modelkaart waarschuwt dat een hogere resolutie buiten die trainingsverdeling valt en meer geheugen en verwerkingstijd kost. Een grotere afbeeldingsinstelling is dus geen garantie voor een betere beslissing. Houd de invoervoorbereiding consistent met de vraag en controleer of het benodigde visuele kenmerk duidelijk wordt weergegeven.

Attention, readout en kalibratie van kansen

De full-attention-lagen van het native checkpoint gebruiken een opgeslagen niet-causale attention-modus, terwijl de linear-attention-lagen hun eigen gedrag behouden. De maker stelt dat standaard causale inferentie de geëvalueerde opzet niet reproduceert. De voorspellingsimplementatie past de opgeslagen kalibratietemperatuur toe; als logits direct worden gebruikt, wordt die temperatuur één keer toegepast en worden de kansen genormaliseerd over de huidige geldige kandidaten. Deze details horen bij het exacte beslissingsprofiel en blijven behouden bij het interpreteren van de numerieke uitvoer.

De afzonderlijke beslissingsreadout onderscheidt dit artefact ook van een generatieve export. Een conversie naar een op woordenschat gebaseerde generatie-interface vereist een expliciete mapping en moet het attention-gedrag behouden. Bereid gesloten vragen voor voor het native beslissingsprofiel; gebruik een geschikt generatiemodel wanneer de taak chat, code, uitleg of toolverzoeken nodig heeft.

Een bruikbaar eindartefact houdt de toestand, de vraag, de toegestane antwoorden en de resulterende verdeling met elkaar verbonden. Definieer de vraag rond bewijs dat werkelijk aanwezig is, beoordeel dubbelzinnige gevallen aan de hand van dat bewijs en gebruik gelabelde voorbeelden uit de beoogde taak om te bepalen hoe numerieke uitvoer de routering of classificatie beïnvloedt. Het model levert beslissingskansen; de criteria en de omringende applicatie bepalen hoe die kansen een bruikbare actie of een vastgelegd label worden.