Perplexity Decider

Vydáváme Decider v1.3 a Decider Flash v1.3, nástupce našich dřívějších rozhodovacích modelů: v1, v1.1, v1.2 a Flash v1.2.

Decider Flash v1.3 je menší model destilovaný z modelu Decider v1.3. Oba modely jsou k dispozici na Hugging Face pod licencí Apache, prostřednictvím OpenRouter a přes Perplexity Decisions API.

Perplexity Decider je inspirován modelem Jev, System One Model společnosti TypeSafe AI. Podporuje binární i vícetřídní klasifikaci s uspořádanými nebo neuspořádanými štítky a vrací pravděpodobnosti, které mohou aplikace využít ke klasifikaci, směrování, řazení a hodnocení vstupů.

Oba modely v1.3 zlepšují výkon a robustnost v široké škále textových i vizuálních úloh díky obousměrné pozornosti, lépe vybraným trénovacím datům a vylepšenému tréninkovému postupu. Představujeme také locate, novou funkci, která zvýrazňuje vybraný obsah v úlohách rozpoznávání pojmenovaných entit, identifikace osobních údajů a extraktivního zodpovídání otázek.

V tomto článku vysvětlujeme, jak Decider trénujeme a hodnotíme, a ukazujeme, jak ho interně využíváme v Perplexity.

Co je rozhodovací model?

Rozhodovací model je univerzální klasifikátor. Zadáte mu vstup a sadu otázek, z nichž každá má své možné odpovědi. Pro každou otázku vrátí rozdělení pravděpodobnosti přes odpovědi. Podporuje 3 typy otázek:

• Ano / Ne: binární rozhodnutí.
• Výběr z možností: vlastní štítky pro více tříd.
• Skóre: seřazené úrovně.

Rozhodovací modely podporují širokou škálu klasifikačních a hodnoticích úloh:

• Hodnocení výstupů: posuzování věrnosti, kvality a bezpečnosti.
• Směrování: nasměrování požadavků na menší nebo větší modely podle obtížnosti.
• Moderování a bezpečnost: detekce škodlivého obsahu, phishingu a prompt injection ve výstupech nástrojů.
• Filtrování a označování: uspořádání rozsáhlých sbírek obsahu.
• Vyhledávání a reranking: hodnocení výsledků vyhledávání podle relevance.

Mnoho z těchto úloh dříve zpracovávaly generativní modely, jako jsou LLM, přestože nevyžadují generování volného textu. Rozhodovací modely stojí mezi LLM a klasifikátory pro konkrétní úlohy. Vracejí pravděpodobnosti pro více otázek týkajících se téhož vstupu v jediném dopředném průchodu, čímž se vyhýbají generování odpovědí token po tokenu a sdílejí výpočty napříč otázkami. Na rozdíl od klasifikátorů pro konkrétní úlohy zvládnou nové úlohy prostřednictvím promptů v přirozeném jazyce – tuto flexibilitu získávají trénováním na rozmanitých úlohách ve sdíleném formátu otázek a odpovědí.

Trénink

Jak z generativního LLM udělat rozhodovací model

Decider vytváříme adaptací silných generativních LLM jako páteřních modelů. Abychom tuto adaptaci vysvětlili, nejprve popíšeme, jak je reprezentován požadavek. Jak je znázorněno níže, požadavek se skládá ze sdíleného kontextu (stavu) a určitého počtu otázek. Stav budou opakovaně využívat všechny otázky.

Například pro dokument a jeho shrnutí se jediný požadavek může zeptat, zda shrnutí věrně odpovídá dokumentu a zda je určeno odborníkům, nebo široké veřejnosti. Za stavem následují bloky otázek, z nichž každý obsahuje otázku a její možné odpovědi, přičemž každé odpovědi je přiřazen předdefinovaný token štítku, například A, B nebo C. Speciální token <|marker|> označuje místo, odkud se čte predikce modelu. Na této pozici naučená lineární výstupní vrstva (rozhodovací hlava) mapuje skrytý stav na skóre možností odpovědi dané otázky, která se poté převedou na pravděpodobnosti.

Zvětšit

Výstupní vrstvu inicializujeme ze základního modelu, který běžně hodnotí další token z celého slovníku, a ponecháme pouze řádky odpovídající předdefinovaným tokenům možností, například A, B nebo C. Tato prořezaná vrstva se pak trénuje tak, aby převáděla skrytý stav tokenu <|marker|> na skóre odpovědí. Tento přístup pokrývá všechny klasifikační otázky, protože všechny je lze formulovat jako výběr z možností.

Pro trénink bereme stovky veřejných datových sad pokrývajících různorodé úlohy (sentiment, odvozování v přirozeném jazyce, detekce záměru, párování entit, moderování, ověřování faktů, hodnocení atd.) a každý příklad převádíme do výše popsaného jednotného formátu: stav, jedna nebo více otázek, jejich možnosti a cíl. Cílem může být jediná správná možnost, pokud máme zlaté štítky (gold labels), nebo rozdělení pravděpodobnosti přes možnosti.

Ve verzi v1.3 představujeme locate, funkci, která místo výběru z předdefinovaných možností extrahuje text ze stavu. Otázka typu locate popisuje, co se má najít, a to buď krátkým štítkem, například „místo“, nebo instrukcí, například „Extrahuj název města, kde se pracovní místo nachází.“ Model vrátí přesně odpovídající text ze stavu spolu s jeho počáteční a koncovou pozicí ve znacích. Pokud nenajde žádnou shodu, vrátí prázdný seznam.

Zvětšit

Díky sdílenému stavu může jediný požadavek kombinovat otázky typu locate s klasifikačními a hodnoticími otázkami ke stejnému vstupu. Může se například zeptat, zda pracovní pozice vyžaduje zkušenosti na seniorní úrovni, a zároveň extrahovat požadované dovednosti.

Obousměrná pozornost: umožňuje modelu číst oběma směry

Naše modely vycházejí ze silných předtrénovaných generativních základních modelů (backbone), jejichž kauzální pozornost umožňuje každému tokenu věnovat pozornost pouze sobě a předchozím tokenům. Naše ablační studie ukázaly, že převedení vrstev plné pozornosti základního modelu na obousměrné zlepšuje výkon. Tento návrh jsme proto přijali, aby každý token mohl zahrnout kontext z celého vstupu.

Obousměrná pozornost přináší další návrhové rozhodnutí: jak by měly stav a otázky vzájemně interagovat? Zvažovali jsme tři vzory pozornosti s různými dopady na výkon, stabilitu odpovědí a opakované využití cache:

• Všechno vidí všechno (v1.2): Stav i všechny otázky se zpracovávají společně s plnou obousměrnou pozorností. Výpočet nad stavem je sdílený, ale odpověď na jednu otázku se může měnit podle toho, na co dalšího se požadavek ptá.
• Izolované otázky (v1.3): Stav věnuje pozornost všem otázkám, zatímco každá otázka věnuje pozornost pouze stavu a svým vlastním tokenům. Otázky se stále mohou navzájem nepřímo ovlivňovat prostřednictvím sdíleného stavu, ale výsledky jsou stabilnější.
• Plně cachovatelná varianta: Stav věnuje pozornost pouze sám sobě, zatímco každá otázka věnuje pozornost stavu a svým vlastním tokenům. Stav je nezávislý na otázkách a lze jej opakovaně používat napříč požadavky, a využít tak ukládání promptů do mezipaměti. Ve výchozím nastavení tuto variantu nepoužíváme, protože u řady úloh velmi záleží na tom, aby stav viděl otázky, ale model na ni lze přepnout malým doladěním.

Nakonec jsme zvolili izolované otázky kvůli jejich vysokému výkonu a stabilitě.

Zvětšit

Tréninkový postup

Trénování u obou velikostí modelu probíhá ve třech fázích. Nejprve trénujeme větší model založený na Qwen3.8-27B pomocí křížové entropie na rozsáhlých datových sadách a poté jej destilujeme do menšího modelu Qwen3.5-4B.

První fází je obecný trénink, při kterém model plně dolaďujeme na rozsáhlých korpusech. V této fázi přijímáme pouze data, která modelu pomáhají plošně a nejsou specifická pro žádný benchmark; proto vylučujeme veškeré trénovací části benchmarků.

Po natrénování tohoto univerzálního modelu provádíme druhou, jemnější fázi pomocí LoRA. Data použitá v této fázi jsou zaměřena na konkrétní domény a úlohy. Data přidáváme až ve druhé fázi, nikoli v první, pokud pozorujeme jen úzce zaměřená zlepšení nebo určité regrese u jiných úloh. LoRA používáme, abychom se od univerzálního modelu příliš nevzdálili a neriskovali ztrátu výkonu kvůli přizpůsobení těmto konkrétním doménám. Cílem je zlepšit výkon a zároveň zachovat obecné znalosti páteřního modelu. Při slučování LoRA zpět do základního modelu také používáme váhu, abychom odchylku řídili přesněji a upřednostnili metriky na odložených datech před jakýmikoli zlepšeními v rámci domény.

Nakonec přidáváme krok zaměřený na vizuální úlohy. Podobně jako druhá fáze je i tento krok pojat jako další jemná specializace s využitím adaptéru LoRA, který se s určitou váhou začlení zpět do základního modelu. Některé vizuální schopnosti mohou být vykoupeny nižším výkonem v textu. Protože pozorujeme výrazně vyšší využití modelů na text, upřednostňujeme textové metriky před vizuálními.

V obou textových fázích používáme průměrné váhy ze tří běhů, z nichž každý používá jiný náhodný seed. Zjistili jsme, že to zlepšuje výkon a robustnost výsledného agregovaného modelu.

Jakmile získáme finální velký model, aplikujeme stejný třífázový trénovací postup na menší model. Velký model zde slouží jako učitel: jeho predikované výstupní rozdělení nahrazuje zlaté štítky a menší model se trénuje tak, aby minimalizoval KL divergenci mezi svými predikcemi a predikcemi učitele. Tato destilační cílová funkce překonává křížovou entropii na stejných trénovacích datech. Zatímco křížová entropie dosahuje lepších výsledků na benchmarcích s vyhrazenými trénovacími daty, hůře generalizuje na odložená data. Předpokládáme, že destilace lépe přenáší výstupní rozdělení učitele, včetně jeho jistoty ohledně alternativ mimo zlaté štítky, zatímco křížová entropie podporuje přeučení na trénovací rozdělení specifické pro daný benchmark. Proto používáme destilační cílovou funkci založenou na KL divergenci.

Abychom omezili kontaminaci mezi trénovacími a testovacími daty, odstraňujeme všechny trénovací vzorky, které by se mohly překrývat s kteroukoli evaluací, kterou používáme. To je důležité, protože některé veřejné trénovací datové sady obsahují velké části některých evaluačních datových sad. Provádíme také rozsáhlé audity zkreslení a jejich odstraňování, abychom zajistili, že naše zlepšení jsou spolehlivá a nejsou pouze důsledkem naučených zkreslení.

Přidání schopnosti extrahovat informace

Funkce locate extrahuje z textu informace, například pojmenované entity, aniž by měnila způsob, jakým model odpovídá na běžné požadavky. Za tímto účelem zavádíme další fázi tréninku: do modelu Decider přidáváme nový speciální token <|locate|>, hlavu pro rozsahy (span head) a adaptér LoRA.

Embedding tokenu <|locate|> inicializujeme z tokenu <|marker|> naučeného v předchozích fázích tréninku. Trénujeme pouze tento nový embedding, hlavu pro rozsahy a adaptéry LoRA, zatímco původní váhy základního modelu i rozhodovací hlava zůstávají zmrazené. Každé požadované pole dostane vlastní token <|locate|>.

Hlava pro úseky (span head) používá reprezentaci tokenu <|locate|> spolu s reprezentacemi stavových tokenů k ohodnocení toho, kde odpovídající úseky začínají a končí a které dvojice začátku a konce k sobě patří. Reprezentaci tokenu <|locate|> využívá také k predikci prahových hodnot pro tato skóre, specifických pro jednotlivá pole. Vybrané úseky se vracejí jako pozice znaků v původním textu.

Hlavu pro úseky trénujeme pomocí upravené ztrátové funkce InfoNCE, která posouvá každý zlatý úsek nad práh a práh nad každý jiný úsek. Ztráta má dva členy: První posouvá skóre správných úseků nad práh a nad chybné úseky. Druhý člen posouvá práh nad skóre chybných úseků. Pole bez odpovědi dostávají pouze druhý člen, což model učí vracet prázdný seznam.

Trénujeme na kombinaci úloh extrakce úseků textu, včetně rozpoznávání pojmenovaných entit, detekce PII a extraktivního zodpovídání otázek. Popisy polí obměňujeme od krátkých štítků po podrobné instrukce, aby se model naučil řídit požadavkem, a ne si zapamatovat pevnou sadu štítků.

Locate učí model strukturálně odlišnou úlohu a my ji chceme přidat, aniž bychom ztratili to, v čem model již vyniká. Sloučení adaptérů Locate do páteřního modelu způsobuje určitou regresi u rozhodovacích požadavků. Abychom to omezili, zkoumáme možnosti, jako je více dat pro opakované přehrávání (replay) z dřívějších fází a pomocné cílové funkce, které udržují výstupy modelu u rozhodovacích požadavků blízko výstupům původního modelu. Zjišťujeme však, že sloučení zatím stále není bezztrátové, proto adaptéry ponecháváme nesloučené a aktivujeme je pouze pro požadavky typu Locate.

Hodnocení

Decider v1.3 a Decider Flash v1.3 vyhodnocujeme na externích benchmarcích z Hugging Face Decision Index, ClaimBench od Vals AI a Artificial Analysis Decision Index.

V rámci těchto evaluací vykazují naše modely vysoký výkon. Přestože tyto žebříčky zahrnují soukromě držené úlohy, lze s nimi stále manipulovat opakovaným odesíláním a iterativním laděním na základě zpětné vazby ze žebříčku. Jako doplněk k těmto žebříčkům vyhodnocujeme modely na interní sadě, která kombinuje soukromé produkční úlohy s evaluacemi na odložených datech z veřejných datových sad, jež nejsou benchmarky. Tyto evaluace poskytují dodatečnou kontrolu generalizace nad rámec veřejných benchmarků a pomáhají nám odlišit širší zlepšení od zisků specifických pro známé evaluační sady.

Interně jsme vytvořili sadu více než 200 úloh z různých oblastí, zahrnujících například klasifikaci, hodnocení, reranking a extrakci entit. Abychom poctivě posoudili výkon modelu Decider v reálném provozu, provádíme všechna hodnocení v režimu zero-shot, bez dolaďování na konkrétní úlohy. To nám dává jasný signál, kde model zlepšit.

Klasifikace dotazů

V Perplexity zpracováváme každý uživatelský dotaz pomocí klasifikačního systému s více hlavami. Každý dotaz nejprve projde embeddingovým modelem, který slouží jako extraktor příznaků. Výsledný embedding se poté předá do několika samostatných klasifikačních hlav, včetně binárních klasifikátorů i klasifikátorů s více štítky. Například jedna hlava určuje, zda má uživatelský dotaz spustit vyhledávání na webu.

Napříč 63 klasifikačními úlohami s referencemi nezávisle přeoznačenými špičkovým LLM dosahuje Decider v1.3 průměrné přesnosti 91,6 % a překonává naše produkční klasifikátory o 6,54 procentního bodu. Decider Flash v1.3 také překonává produkční základ, zatímco Decider v1.3 překonává Jev 1.14.

Zvětšit

Oborově specifická klasifikace

Z veřejných datových sad jsme sestavili oborově specifickou hodnoticí sadu, abychom posoudili klasifikační výkon rozhodovacích modelů v sedmi oborech: ověřování tvrzení (6 úloh), zdravotnictví (7), kybernetická bezpečnost (8), programování (16), státní správa (7), právo (9) a finance (9).

Například „posuď časovou složitost programu napsaného v jazyce Python“ nebo „na základě výroční finanční zprávy urči, zda volné peněžní prostředky společnosti pokrývají jistinu dluhu splatnou během následujících dvanácti měsíců“. Decider v1.3 vede ve všech sedmi oborech a překonává Jev 1.14 až o 12,9 procentního bodu ve financích a o 9,3 bodu v právu. Decider Flash v1.3 zaostává za Jev 1.14 ve financích, programování a právu a v ostatních oborech dosahuje podobných výsledků.

Zvětšit

Vyhledávání a reranking

Vyhledávání je jádrem Perplexity. Udržujeme rozsáhlou sadu úloh vyhledávání, na kterých hodnotíme rerankingový výkon našich modelů. Pro každou úlohu nejprve pomocí skupiny embeddingových modelů získáme z každého korpusu 50 nejlepších kandidátních dokumentů. Tyto kandidáty pak přeřadíme pomocí modelu Decider a jeho výkon porovnáme se silným referenčním rerankerem Qwen3-Reranker-8B.

Decider hodnotíme v nastavení zero-shot po jednotlivých položkách (pointwise): model přímo a nezávisle ohodnotí každou dvojici dotaz–dokument a dokumenty seřadíme podle relevance. Napříč 72 úlohami vyhledávání dosahuje Decider v1.3 průměrného nDCG@10 ve výši 83,99, čímž překonává Qwen3-Reranker-8B o 1,81 bodu a Jev 1.14 o 2,24 bodu.

V benchmarku BEIR oba modely překonávají Qwen3-Reranker-8B o 8,78, resp. 7,05 bodu nDCG@10. Oproti Jev 1.14 dosahuje Decider v1.3 o 1,33 bodu více, zatímco verze Flash o 0,4 bodu méně.

Zvětšit

Vícejazyčná klasifikace

Abychom rozhodovací modely hodnotili i mimo angličtinu, sestavili jsme vícejazyčný klasifikační benchmark složený z 19 jazykově specifických úloh z 8 veřejných datových sad se 46 484 příklady v osmi jazycích: němčině, španělštině, francouzštině, italštině, ruštině, japonštině, korejštině a čínštině. Benchmark zahrnuje detekci záměru, klasifikaci témat, analýzu sentimentu, odvozování v přirozeném jazyce, detekci parafrází, detekci urážlivého jazyka a gramatickou přijatelnost.

Uvádíme průměrnou přesnost napříč úlohami v každém jazyce, přičemž každá úloha má stejnou váhu. Decider v1.3 překonává Jev 1.14 ve všech osmi jazycích a Decider Flash v1.3 v šesti z nich, s průměrnou přesností úloh 88,16 % u modelu Decider v1.3 a 86,50 % u modelu Decider Flash v1.3 oproti 85,41 % u modelu Jev 1.14.

Zvětšit

NER, PII a extraktivní QA

Funkci locate hodnotíme na 17 úlohách mimo trénovací doménu, které testují extrakci napříč různými obory, vstupními formáty (text, tabulky, strukturované dokumenty) a instrukcemi (krátké štítky, otázky a podrobné popisy). Obory sahají od Wikipedie po vědecké články, zprávy o kybernetických hrozbách, technickou podporu, zásady ochrany osobních údajů, životopisy a právní smlouvy. Požadavky sahají od krátkých názvů štítků, jako je „osoba“ nebo „e-mailová adresa“, přes otázky k tabulce nebo tiketu podpory až po podrobné popisy polí pro strukturovanou extrakci, například smluvních stran NDA nebo celkové částky na faktuře.

NER a PII vyhodnocujeme pomocí metriky exact-span F1, která vyžaduje, aby se predikované úseky přesně shodovaly s referenčními hranicemi. Extraktivní QA používá metriku F1 na úrovni znaků, která uděluje částečné body za překrývající se text odpovědi, zatímco strukturovaná extrakce používá přesnost polí, tedy podíl správně extrahovaných polí. U parsování CV průměrujeme skóre exact-span F1 pro NER a PII.

Naše modely porovnáváme s univerzálními extrakčními modely různých velikostí: GLiNER large v2.5 (0,5B), Liquid d1 (2B) a Clairic společnosti Cloudflare (velikost nezveřejněna). Decider v1.3 dosahuje průměrného skóre 69,0 (podle primární metriky každé úlohy) a Decider Flash v1.3 skóre 63,6, oproti 43,3 u modelu Liquid d1, 41,5 u modelu Clairic a 33,6 u modelu GLiNER large v2.5. Oba modely Decider vedou ve všech kategoriích.

Zvětšit

Klasifikace obrázků

Decider nativně podporuje vizuální úlohy už od verze v1. Abychom hodnotili jeho výkon i mimo text, sestavili jsme sadu benchmarků s pěti úlohami se zvláštním důrazem na klasifikaci dokumentů, včetně faktur, dopisů a životopisů. Sada zahrnuje také klasifikaci satelitních snímků, klasifikaci textur, klasifikaci plemen domácích zvířat a počítání zvířat.

Decider v1.3 dosahuje v pěti vizuálních úlohách průměrné přesnosti 76,99 % a překonává Jev 1.14 o 1,47 procentního bodu. Decider Flash v1.3 dosahuje 72,77 %, čímž prokazuje schopnosti vizuální klasifikace i v menším modelu.

Zvětšit

Rozhodovací požadavky z reálného provozu

Vybrali jsme vzorek jednoho milionu deduplikovaných požadavků s maskovanými PII, které byly odeslány do Perplexity Decision API během prvních 18 dnů jeho dostupnosti. Protože každý požadavek může obsahovat více otázek ke stejnému stavu, zahrnuje vzorek 2 318 887 jednotlivých otázek. Všechny požadavky byly zahrnuty s výslovným svolením uživatelů k výzkumu.

Produkční požadavky nemají referenční (ground-truth) štítky, proto k vytvoření referenčních odpovědí používáme jako hodnotitele špičkové LLM a měříme, nakolik se s nimi jednotlivé modely shodují. Požadavky také seskupujeme do 10 kategorií úloh: extrakce informací, klasifikace domén, analýza sentimentu, záměr a směrování, řazení podle relevance, moderování obsahu, kontrola kvality a souladu, párování entit, obchodní analýza a kategorie „Ostatní“. Toto rozdělení ukazuje, jak se výkon liší napříč reálnými případy použití.

Skladba úloh je nerovnoměrná: na extrakci informací připadá 425 402 otázek, na klasifikaci domén 409 564 a na analýzu sentimentu 344 158. Tyto tři kategorie dohromady tvoří 50,8 % otázek ve vzorku.

Decider v1.3 dosahuje nejvyšší shody s hodnotiteli, a to 93,98 %, oproti 93,68 % u modelu Decider v1.2 a 93,35 % u modelu Jev 1.14. Decider v1.3 a Jev 1.14 jsou si velmi blízko v klasifikaci domén a analýze sentimentu s rozdíly 0,34, resp. 0,07 procentního bodu. Jev vede o 0,69 bodu v řazení podle relevance, zatímco Decider v1.3 vede o 0,93 bodu v extrakci informací (nejčastější úloze ve vzorku) a o 1,21 bodu v kategorii záměr a směrování.

Zvětšit

Graf níže porovnává vykázané náklady na zpracování stejného jednoho milionu produkčních požadavků. Každý požadavek může obsahovat více otázek, proto jsou jednotkou požadavky, nikoli jednotlivé otázky.

Zvětšit

Robustnost

Citlivost na štítky jsme hodnotili na 372 otázkách s výběrem z možností, přičemž jsme na každý model odeslali 4 788 požadavků. Měnili jsme pořadí možností, přiřazovali štítky k jiným textům odpovědí a přejmenovávali štítky při zachování významu každé otázky. Poté jsme kontrolovali, zda se změnila sémantická odpověď modelu. Nižší míra změn odpovědí znamená vyšší stabilitu.

Decider v1.3 změnil svou odpověď u každé transformace jen u 0,27 % otázek, oproti 2,69–4,84 % u modelu Jev 1.14. Opakovali jsme také identické vstupy, abychom změřili variabilitu při inferenci: Decider v1.3 nevykázal žádné změny, zatímco Jev 1.14 změnil odpověď u 1,88 % otázek.

Zvětšit

Jak Decider používáme

Decider je navržen pro pracovní postupy, které vyžadují rychlá a strukturovaná rozhodnutí. V této části se podíváme, jak ho využít, aby měl skutečný dopad na způsob naší práce. Zde je několik příkladů, které nás zaujaly.

Samozdokonalující se bezpečnostní pravidla

Interně již Decider používáme ke zlepšování našich bezpečnostních zásad.

Činnost našich agentů se zaznamenává a provádí se řada kontrol založených na pravidlech, které mají odhalit jakékoli problematické chování. Přístup založený na pravidlech nám umožňuje monitorovat agenty v reálném čase se zanedbatelnou přidanou latencí. Offline pak pomocí modelu Decider procházíme vzorky z těchto zaznamenaných logů agentů. Pokud nebylo označeno žádné problematické chování, Decider kontroluje, zda naše sada pravidel něco nepřehlédla; a pokud byl vyvolán poplach, Decider ověřuje, zda nešlo o planý poplach. Všechny záznamy, u kterých naše sada pravidel v kterémkoli z těchto případů selže, se odešlou agentovi k posouzení, který navrhne úpravu pravidel. Tu pak musí schválit člen našeho bezpečnostního týmu.

Během jednoho dne Decider přečetl 1 miliardu tokenů v 7 000 relacích agentů a odhalil nedostatky, které vedly ke 14 opravám pravidel, z nichž 6 bylo schváleno a nasazeno do dvou dnů. Při zpětném přehrání na logech za jeden týden snížily opravy objem našeho nejvytíženějšího pravidla o 52 % a rozšířená pravidla zachytila zhruba o 40 % více legitimních akcí k prošetření.

Zvětšit

Monitorování rolloutů RL

Když modely v rámci post-tréninku trénujeme posilovaným učením, agregované metriky, jako je koncová odměna, nevysvětlují, proč rollout (jednotlivý pokus o splnění úlohy) uspěl, nebo selhal. Rollout může nespravedlivě přijít o odměnu, protože selhala služba nástroje nebo sandbox, nebo získat nezaslouženou odměnu, pokud hodnotitel přehlédne nepodložené tvrzení, například vymyšlenou hodnotu, kterou žádný nástroj nevrátil.

V těchto případech používáme Decider k monitorování rolloutů. Kód nejprve identifikuje části rolloutu, které si zaslouží bližší kontrolu: neúspěšné volání nástroje a okolní uvažování, kód, který proběhl bez chyb, nebo konečnou odpověď. Decider pak ke každé části odpovídá na otázky s výběrem z možností, například co v daném kroku selhalo (služba nástroje, externí web, sandbox, harness, nebo vlastní kód agenta) a zda agent výsledek správně interpretoval. Všechny otázky k dané části sdružujeme do jediného požadavku a místo verdiktu ukládáme pravděpodobnosti, takže můžeme prahové hodnoty později upravit, aniž bychom museli model Decider znovu dotazovat. Monitor pouze pozoruje a diagnostikuje: nikdy nemění odměnu ani nezastavuje běh.

Zvětšit

Filtrování stránek podle kvality

Při procházení webových stránek, které indexujeme a poskytujeme uživatelům, má mnoho stránek příliš nízkou kvalitu na to, aby byly k něčemu užitečné. Patří sem stěny proti botům, CAPTCHA a chybové stránky, ale i správně načtené webové stránky, které prostě neobsahují žádné užitečné informace, například spam, SEO výplň nebo čistě navigační stránky. Tyto nekvalitní stránky je třeba identifikovat a odfiltrovat z našeho indexu.

Pomocí modelu Decider můžeme posuzovat kvalitu stránek už při jejich procházení. V rámci téhož dopředného průchodu provádíme řadu dalších klasifikačních úloh, například určení domény a cílového publika obsahu a toho, zda obsahuje škodlivé, nelegální nebo osobně identifikovatelné informace. Ve srovnání s použitím LLM jako hodnotitele je Decider výrazně rychlejší a levnější.

Zvětšit

Kromě těchto interních využití se Decider hodí také pro pracovní postupy, jako jsou následující.

Vizuální QA

Protože Decider umí číst obrázky, funguje také jako vizuální kontrolor: kontroluje změny stylů webových stránek nebo aplikací a identifikuje chyby. Ještě před nasazením změny dokáže na snímcích obrazovky stránek odhalit oříznutý text, překrývající se prvky či rozbité rozvržení, nebo označit grafy, jejichž design by mohl čtenáře zavádět či porušovat zásady značky.

Zvětšit

Navigace v prohlížeči

Agenti mohou Decider využívat pro drobná rozhodnutí v rámci větších úloh. Agent v prohlížeči může v každém kroku odeslat snímek obrazovky a získat podrobné informace o stavu stránky a očekávaném výsledku každé možné akce.

Zvětšit

Plánování výzkumných úloh

Otázky uživatelů se mohou výrazně lišit svou složitostí, stejně jako hloubka vyhledávání potřebného k nalezení odpovědi. Decider to dokáže odhadnout ještě před zahájením vyhledávání, takže na jednoduché otázky lze vynaložit méně prostředků.

Zvětšit

Začínáme

Decider vrací pravděpodobnosti. Vhodný rozhodovací práh závisí na aplikaci. Četnosti štítků i relativní náklady falešně pozitivních a falešně negativních výsledků se v jednotlivých případech použití liší. Proto uživatelům doporučujeme ladit prahové hodnoty na malé, reprezentativní označené vývojové sadě, místo aby předpokládali, že pevně stanovená hranice bude fungovat stejně dobře napříč úlohami.

Decider v1.3 doporučujeme pro jemně odstíněné úsudky, podrobné hodnoticí rubriky a pracovní postupy, v nichž jsou chyby nákladné. Decider Flash v1.3 zvolte pro velkoobjemové směrování, označování a filtrování, kde jsou hlavními omezeními latence a náklady. Oba modely vyhodnoťte na reprezentativních příkladech ze své pracovní zátěže a poté zvolte model, který splňuje vaše požadavky na kvalitu, latenci a rozpočet.

Oba modely jsou k dispozici jako stažitelné váhy na Hugging Face pod licencí Apache, prostřednictvím OpenRouter a přes Perplexity Decisions API.

Citace

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