Perplexity Decider

Vydávame Decider v1.3 a Decider Flash v1.3, nástupcov našich skorších rozhodovacích modelov: v1, v1.1, v1.2 a Flash v1.2.

Decider Flash v1.3 je menší model destilovaný z modelu Decider v1.3. Oba modely sú dostupné na Hugging Face pod licenciou Apache, prostredníctvom OpenRouter a cez Perplexity Decisions API.

Perplexity Decider je inšpirovaný modelom Jev (System One Model od spoločnosti TypeSafe AI). Podporuje binárnu aj viactriednu klasifikáciu s usporiadanými alebo neusporiadanými označeniami a vracia pravdepodobnosti, ktoré môžu aplikácie použiť na klasifikáciu, smerovanie, zoraďovanie a vyhodnocovanie vstupov.

Oba modely v1.3 zlepšujú výkon a robustnosť v širokom spektre textových a vizuálnych úloh vďaka obojsmernej pozornosti, lepšie kurátorovaným trénovacím dátam a vylepšenému postupu trénovania. Predstavujeme tiež locate, novú funkciu na zvýraznenie vybraného obsahu pri úlohách rozpoznávania pomenovaných entít, identifikácie osobných údajov a extraktívneho zodpovedania otázok.

V tomto článku vysvetľujeme, ako trénujeme a vyhodnocujeme Decider, a ukazujeme, ako ho interne používame v Perplexity.

Čo je rozhodovací model?

Rozhodovací model je univerzálny klasifikátor. Zadáte mu vstup a sadu otázok, z ktorých každá má svoje možné odpovede. Pre každú otázku vráti pravdepodobnostné rozdelenie nad odpoveďami. Podporuje 3 typy otázok:

• Áno / Nie: binárne rozhodnutia.
• Výber z možností: vlastné viactriedne označenia.
• Skóre: usporiadané úrovne.

Rozhodovacie modely podporujú široké spektrum úloh klasifikácie a hodnotenia:

• Hodnotenie výstupov: posudzovanie vernosti, kvality a bezpečnosti.
• Smerovanie: presmerovanie požiadaviek na menšie alebo väčšie modely podľa náročnosti.
• Moderovanie a bezpečnosť: odhaľovanie škodlivého obsahu, phishingu a prompt injection vo výstupoch nástrojov.
• Filtrovanie a označovanie: organizovanie veľkých kolekcií obsahu.
• Vyhľadávanie a opätovné zoraďovanie: hodnotenie výsledkov vyhľadávania podľa relevantnosti.

Mnohé z týchto úloh predtým riešili generatívne modely, ako sú LLM, hoci nevyžadujú generovanie voľného textu. Rozhodovacie modely stoja medzi LLM a klasifikátormi pre konkrétne úlohy. V jedinom doprednom prechode vracajú pravdepodobnosti pre viacero otázok o tom istom vstupe, čím sa vyhýbajú generovaniu odpovede token po tokene a zdieľajú výpočty naprieč otázkami. Na rozdiel od klasifikátorov pre konkrétne úlohy dokážu zvládať nové úlohy pomocou promptov v prirodzenom jazyku – túto flexibilitu získali tréningom na rozmanitých úlohách v zdieľanom formáte otázok a odpovedí.

Trénovanie

Ako z generatívneho LLM urobiť rozhodovací model

Decider vytvárame adaptáciou silných generatívnych LLM, ktoré slúžia ako základné modely. Aby sme adaptáciu vysvetlili, najprv opíšeme, ako je reprezentovaná požiadavka. Ako je znázornené nižšie, požiadavka pozostáva zo zdieľaného kontextu (stavu) a niekoľkých otázok. Stav budú opakovane využívať všetky otázky.

Napríklad pri dokumente a jeho zhrnutí sa jedna požiadavka môže opýtať, či zhrnutie verne vystihuje dokument a či je určené odborníkom alebo širokému publiku. Po stave obsahuje každý blok otázky samotnú otázku a jej možné odpovede, z ktorých má každá priradený preddefinovaný token označenia, napríklad A, B alebo C. Špeciálny token <|marker|> označuje, kde sa má odčítať predikcia modelu. Na tejto pozícii naučená lineárna výstupná vrstva (rozhodovacia hlava) mapuje skrytý stav na skóre pre možnosti odpovede na otázku, ktoré sa potom prevedú na pravdepodobnosti.

Zväčšiť

Výstupnú vrstvu, ktorá bežne hodnotí nasledujúci token z celého slovníka, inicializujeme zo základného modelu a ponecháme iba riadky zodpovedajúce preddefinovaným tokenom možností, napríklad A, B alebo C. Táto orezaná vrstva sa potom trénuje tak, aby prevádzala skrytý stav tokenu <|marker|> na skóre odpovedí. Tento prístup pokrýva všetky klasifikačné otázky, pretože všetky možno formulovať ako výber z možností.

Na trénovanie používame stovky verejných dátových súborov pokrývajúcich rôznorodé úlohy (sentiment, inferencia v prirodzenom jazyku, detekcia zámeru, párovanie entít, moderovanie, overovanie faktov, hodnotenia atď.) a každý príklad prevedieme do jednotného formátu opísaného vyššie: stav, jedna alebo viac otázok, ich možnosti a cieľ. Cieľom môže byť jediná správna možnosť, ak máme zlaté označenia (gold labels), alebo pravdepodobnostné rozdelenie nad možnosťami.

Vo v1.3 predstavujeme funkciu locate, ktorá extrahuje text zo stavu namiesto výberu z preddefinovaných možností. Otázka typu locate opisuje, čo treba nájsť, buď pomocou krátkeho označenia, napríklad „poloha“, alebo pokynu, napríklad „Extrahuj názov mesta, v ktorom sa pracovné miesto nachádza.“ Model vráti presne zodpovedajúci text zo stavu spolu s jeho počiatočnou a koncovou pozíciou znakov. Ak nenájde žiadnu zhodu, vráti prázdny zoznam.

Zväčšiť

Vďaka zdieľanému stavu môže jedna požiadavka kombinovať otázky typu locate, klasifikácie a hodnotenia o tom istom vstupe. Môže sa napríklad opýtať, či pracovná pozícia vyžaduje skúsenosti na seniornej úrovni, a zároveň extrahovať požadované zručnosti.

Obojsmerná pozornosť: model číta oboma smermi

Naše modely vychádzajú zo silných predtrénovaných generatívnych základných modelov (backbone), ktorých kauzálna pozornosť umožňuje každému tokenu venovať pozornosť len sebe a predchádzajúcim tokenom. Naše ablačné štúdie ukázali, že keď sú vrstvy plnej pozornosti základného modelu obojsmerné, výkon sa zlepší, preto sme tento návrh prijali, aby každý token mohol zahrnúť kontext z celého vstupu.

Obojsmerná pozornosť prináša ďalšiu otázku návrhu: ako by mali stav a otázky interagovať? Zvažovali sme tri vzory pozornosti s rôznymi dôsledkami pre výkon, stabilitu odpovedí a opätovné využitie cache:

• Všetko vidí všetko (v1.2): Stav a všetky otázky sa spracúvajú spoločne s plnou obojsmernou pozornosťou. Výpočet nad stavom je zdieľaný, no odpoveď na jednu otázku sa môže zmeniť v závislosti od toho, na čo sa ešte pýtame.
• Izolované otázky (v1.3): Stav venuje pozornosť všetkým otázkam, zatiaľ čo každá otázka venuje pozornosť len stavu a vlastným tokenom. Otázky sa stále môžu navzájom nepriamo ovplyvňovať prostredníctvom zdieľaného stavu, no výsledky sú stabilnejšie.
• Plná podpora vyrovnávacej pamäte: Stav uplatňuje pozornosť iba sám na seba, zatiaľ čo každá otázka uplatňuje pozornosť na stav a na svoje vlastné tokeny. Stav je nezávislý od otázok a dá sa opakovane použiť naprieč požiadavkami, takže možno využiť ukladanie promptov do vyrovnávacej pamäte. Predvolene tento režim nepoužívame, pretože pri viacerých úlohách je veľmi dôležité, aby stav videl otázky, no model naň možno prepnúť malým doladením.

Nakoniec sme zvolili izolované otázky pre ich vysoký výkon a stabilitu.

Zväčšiť

Postup trénovania

Tréning prebieha pri oboch veľkostiach modelu v troch fázach. Najprv trénujeme väčší model založený na Qwen3.8-27B pomocou krížovej entropie na veľkých dátových súboroch a potom ho destilujeme do menšieho modelu Qwen3.5-4B.

Prvou fázou je všeobecné trénovanie, pri ktorom model úplne dolaďujeme na rozsiahlych korpusoch. V tejto fáze prijímame iba dáta, ktoré modelu pomáhajú plošne a nie sú špecifické pre žiadny benchmark; preto vylučujeme všetky trénovacie časti benchmarkov.

Po natrénovaní tohto všeobecného modelu spúšťame druhú, jemnejšie zameranú fázu pomocou LoRA. Dáta použité v tejto fáze sú zamerané na konkrétne domény a úlohy. Dáta pridávame do druhej fázy namiesto prvej, ak pozorujeme iba úzko vymedzené zlepšenia alebo ak pozorujeme regresie v iných úlohách. LoRA používame, aby sme sa príliš neodchýlili od všeobecného modelu a neriskovali stratu výkonu pri prispôsobovaní sa týmto konkrétnym doménam. Cieľom je zlepšiť výkon a zároveň zachovať všeobecné znalosti základného modelu (backbone). Pri zlučovaní LoRA späť do základného modelu používame aj váhu, aby sme odchýlku kontrolovali presnejšie a uprednostnili metriky na odložených dátach pred akýmikoľvek zlepšeniami v rámci domény.

Nakoniec pridávame krok špecifický pre videnie. Podobne ako druhá fáza je aj krok pre videnie chápaný ako ďalší krok jemnej špecializácie s využitím adaptéra LoRA, ktorý sa s určitou váhou zlúči späť do základného modelu. Niektoré vizuálne schopnosti môžu byť vykúpené horším výkonom v texte. Keďže pozorujeme oveľa väčšie využitie modelov na text, uprednostňujeme textové metriky pred vizuálnymi.

Pre obe textové fázy používame priemerné váhy z troch behov, z ktorých každý používa iné náhodné semienko. Zistili sme, že to zlepšuje výkon a robustnosť agregovaného modelu.

Keď získame finálny veľký model, rovnaký trojfázový tréningový postup aplikujeme na menší model. Veľký model tu slúži ako učiteľ: jeho predpovedané výstupné rozdelenie nahrádza zlaté (referenčné) označenia a menší model sa trénuje tak, aby minimalizoval KL divergenciu medzi svojimi predpoveďami a predpoveďami učiteľa. Tento destilačný cieľ prekonáva krížovú entropiu na rovnakých tréningových dátach. Hoci krížová entropia dosahuje lepšie výsledky na benchmarkoch s vyhradenými tréningovými dátami, horšie zovšeobecňuje na odložené dáta. Predpokladáme, že destilácia lepšie prenáša výstupné rozdelenie učiteľa vrátane jeho istoty pri alternatívach mimo zlatých označení, zatiaľ čo krížová entropia podporuje preučenie na tréningové rozdelenie špecifické pre daný benchmark. Preto používame destilačný cieľ založený na KL divergencii.

Aby sme zmiernili kontamináciu medzi tréningovými a testovacími dátami, odstraňujeme všetky tréningové vzorky, ktoré by sa mohli prekrývať s akýmkoľvek hodnotením, ktoré používame. Je to dôležité, pretože niektoré verejné tréningové dátové súbory obsahujú veľké časti niektorých hodnotiacich dátových súborov. Vykonávame tiež rozsiahle audity skreslení a ich odstraňovanie, aby sme zabezpečili, že naše zlepšenia sú spoľahlivé a nie sú len dôsledkom naučených skreslení.

Pridanie schopnosti extrahovať informácie

Funkcia locate extrahuje z textu informácie, ako sú pomenované entity, bez toho, aby menila spôsob, akým odpovedá na bežné požiadavky. Na tento účel zavádzame ďalšiu fázu trénovania: do modelu Decider pridávame nový špeciálny token <|locate|>, hlavu pre rozsahy (span head) a adaptér LoRA.

Embedding tokenu <|locate|> inicializujeme z tokenu <|marker|> naučeného v predchádzajúcich fázach trénovania. Trénujeme iba tento nový embedding, hlavu pre rozsahy a adaptéry LoRA, pričom pôvodné váhy základného modelu a rozhodovacia hlava zostávajú zmrazené. Každé požadované pole dostane vlastný token <|locate|>.

Hlava pre úseky (span head) využíva reprezentáciu tokenu <|locate|> spolu s reprezentáciami tokenov stavu na ohodnotenie toho, kde zodpovedajúce úseky začínajú a končia a ktoré dvojice začiatku a konca k sebe patria. Reprezentáciu tokenu <|locate|> používa aj na predpovedanie prahových hodnôt pre tieto skóre, ktoré sú špecifické pre jednotlivé polia. Vybrané úseky sa vracajú ako pozície znakov v pôvodnom texte.

Hlavu pre úseky trénujeme pomocou upravenej straty InfoNCE, ktorá posúva každý zlatý úsek nad prah a prah nad každý iný úsek. Strata má dva členy: Prvý posúva skóre správnych úsekov nad prah a nad nesprávne úseky. Druhý člen posúva prah nad skóre nesprávnych úsekov. Polia bez odpovede dostávajú iba druhý člen, ktorý model učí vrátiť prázdny zoznam.

Trénujeme na kombinácii úloh extrakcie rozsahov vrátane rozpoznávania pomenovaných entít, detekcie PII a extraktívneho zodpovedania otázok. Opisy polí obmieňame od krátkych označení po podrobné pokyny, aby sa model naučil riadiť sa požiadavkou namiesto memorovania pevnej sady označení.

Locate učí model štrukturálne odlišnú úlohu a chceme ju pridať bez toho, aby model stratil to, v čom už vyniká. Zlúčenie adaptérov locate do základného modelu spôsobuje určitú regresiu pri rozhodovacích požiadavkách. Aby sme to obmedzili, skúmame prístupy, ako je viac dát na opätovné prehrávanie (replay) z predchádzajúcich fáz a pomocné ciele, ktoré udržiavajú výstupy modelu pri rozhodovacích požiadavkách blízko výstupom pôvodného modelu. Zistili sme však, že zlúčenie zatiaľ stále nie je bezstratové, preto adaptéry ponechávame nezlúčené a aktivujeme ich iba pri požiadavkách locate.

Vyhodnotenie

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

Vo všetkých týchto hodnoteniach naše modely preukazujú silný výkon. Hoci tieto rebríčky zahŕňajú neverejné úlohy, stále ich možno zmanipulovať opakovaným odosielaním a iteratívnym ladením na základe spätnej väzby z rebríčka. Ako doplnok k týmto rebríčkom vyhodnocujeme modely na internej sade, ktorá kombinuje neverejné produkčné úlohy s odloženými hodnoteniami z verejných dátových súborov, ktoré nie sú benchmarkmi. Tieto hodnotenia poskytujú dodatočnú kontrolu zovšeobecnenia nad rámec verejných benchmarkov a pomáhajú nám odlíšiť širšie zlepšenia od ziskov špecifických pre známe hodnotiace sady.

Interne sme vytvorili súbor viac ako 200 úloh z rôznych domén a typov úloh, ako je klasifikácia, hodnotenie, opätovné zoraďovanie (reranking) a extrakcia entít. Aby sme poctivo posúdili výkon modelu Decider v reálnom svete, všetky vyhodnotenia prebiehajú v režime zero-shot, bez dolaďovania pre konkrétne úlohy, čo nám dáva jasný signál, kde model zlepšiť.

Klasifikácia dopytov

V Perplexity používame na spracovanie každého používateľského dopytu klasifikačný systém s viacerými hlavami. Každý dopyt najprv prechádza embeddingovým modelom, ktorý slúži ako extraktor príznakov. Výsledný embedding sa potom posiela do viacerých samostatných klasifikačných hláv vrátane binárnych aj viacznačkových klasifikátorov. Napríklad jedna hlava určuje, či má používateľský dopyt spustiť vyhľadávanie na webe.

Naprieč 63 klasifikačnými úlohami s referenciami, ktoré nezávisle preoznačil špičkový LLM, dosahuje Decider v1.3 priemernú presnosť 91,6 % a prekonáva naše produkčné klasifikátory o 6,54 percentuálneho bodu. Decider Flash v1.3 tiež prekonáva produkčný referenčný model, zatiaľ čo Decider v1.3 prekonáva Jev 1.14.

Zväčšiť

Doménovo špecifická klasifikácia

Z verejných dátových súborov sme zostavili doménovo špecifickú sadu na vyhodnotenie klasifikačného výkonu rozhodovacích modelov v siedmich doménach: overovanie tvrdení (6 úloh), zdravotníctvo (7), kybernetická bezpečnosť (8), programovanie (16), verejná správa (7), právo (9) a financie (9).

Napríklad „posúď časovú zložitosť programu v jazyku Python“ alebo „na základe výročnej finančnej správy urči, či neviazaná hotovosť spoločnosti pokrýva istinu dlhu splatnú v nasledujúcich dvanástich mesiacoch“. Decider v1.3 vedie vo všetkých siedmich doménach a prekonáva Jev 1.14 až o 12,9 percentuálneho bodu vo financiách a o 9,3 bodu v práve. Decider Flash v1.3 zaostáva za Jev 1.14 vo financiách, programovaní a práve a v ostatných doménach dosahuje podobné výsledky.

Zväčšiť

Vyhľadávanie a opätovné zoraďovanie

Vyhľadávanie je jadrom Perplexity. Udržiavame širokú sadu úloh vyhľadávania na vyhodnotenie výkonu našich modelov pri opätovnom zoraďovaní. Pri každej úlohe najprv pomocou skupiny embeddingových modelov vyhľadáme z každého korpusu 50 najlepších kandidátskych dokumentov. Týchto kandidátov potom opätovne zoradíme pomocou modelu Decider a jeho výkon porovnáme so silným referenčným rerankerom Qwen3-Reranker-8B.

Decider vyhodnocujeme v nastavení zero-shot a pointwise, pričom model priamo a nezávisle hodnotí každú dvojicu dopyt – dokument a dokumenty zoraďuje podľa relevantnosti. Naprieč 72 úlohami vyhľadávania dosahuje Decider v1.3 priemerné nDCG@10 83,99 a prekonáva Qwen3-Reranker-8B o 1,81 bodu a Jev 1.14 o 2,24 bodu.

V benchmarku BEIR oba modely prekonávajú Qwen3-Reranker-8B o 8,78, resp. 7,05 bodu nDCG@10. V porovnaní s Jev 1.14 dosahuje Decider v1.3 o 1,33 bodu viac, zatiaľ čo verzia Flash o 0,4 bodu menej.

Zväčšiť

Viacjazyčná klasifikácia

Na vyhodnotenie rozhodovacích modelov aj mimo angličtiny sme zostavili viacjazyčný klasifikačný benchmark pozostávajúci z 19 jazykovo špecifických úloh z 8 verejných dátových súborov so 46 484 príkladmi v ôsmich jazykoch: nemčine, španielčine, francúzštine, taliančine, ruštine, japončine, kórejčine a čínštine. Benchmark zahŕňa detekciu zámeru, klasifikáciu tém, analýzu sentimentu, inferenciu v prirodzenom jazyku, detekciu parafráz, detekciu urážlivého jazyka a gramatickú prijateľnosť.

Uvádzame priemernú presnosť naprieč úlohami v rámci každého jazyka, pričom každá úloha má rovnakú váhu. Decider v1.3 prekonáva Jev 1.14 vo všetkých ôsmich jazykoch a Decider Flash v1.3 v šiestich, pričom priemerná presnosť úloh je 88,16 % pre Decider v1.3 a 86,50 % pre Decider Flash v1.3 v porovnaní s 85,41 % pre Jev 1.14.

Zväčšiť

NER, PII a extraktívne QA

Funkciu locate vyhodnocujeme na 17 úlohách mimo trénovacej domény, ktoré testujú jej schopnosť extrakcie v rôznych doménach, vstupných formátoch (text, tabuľky, štruktúrované dokumenty) a pokynoch (krátke označenia, otázky a podrobné opisy). Domény siahajú od Wikipédie cez vedecké články, správy o kybernetických hrozbách, technickú podporu, zásady ochrany osobných údajov a životopisy až po právne zmluvy. Požiadavky siahajú od krátkych názvov označení, ako „osoba“ alebo „e-mailová adresa“, cez otázky o tabuľke alebo tikete podpory až po podrobné opisy polí pre štruktúrovanú extrakciu, ako sú zmluvné strany NDA alebo celková suma na faktúre.

NER a PII vyhodnocujeme pomocou metriky F1 pre presné úseky (exact-span F1), ktorá vyžaduje, aby sa predpovedané úseky presne zhodovali s hranicami referencie. Extraktívne QA využíva F1 na úrovni znakov, ktoré udeľuje čiastočné body za prekrývajúci sa text odpovede, zatiaľ čo štruktúrovaná extrakcia využíva presnosť polí, teda podiel správne extrahovaných polí. Pri parsovaní životopisov spriemerujeme skóre exact-span F1 pre NER a PII.

Naše modely porovnávame s univerzálnymi extrakčnými modelmi rôznych veľkostí: GLiNER large v2.5 (0,5B), Liquid d1 (2B) a Clairic od spoločnosti Cloudflare (nezverejnená veľkosť). Decider v1.3 dosahuje priemerné skóre 69,0 (s použitím primárnej metriky každej úlohy) a Decider Flash v1.3 dosahuje 63,6, v porovnaní so 43,3 pre Liquid d1, 41,5 pre Clairic a 33,6 pre GLiNER large v2.5. Oba modely Decider vedú v každej kategórii.

Zväčšiť

Klasifikácia obrázkov

Decider natívne podporuje vizuálne úlohy už od verzie v1. Na vyhodnotenie jeho výkonu mimo textu sme zostavili sadu benchmarkov s piatimi úlohami s osobitným zameraním na klasifikáciu dokumentov vrátane faktúr, listov a životopisov. Sada pokrýva aj klasifikáciu satelitných snímok, klasifikáciu textúr, klasifikáciu plemien domácich zvierat a počítanie zvierat.

Decider v1.3 dosahuje v piatich vizuálnych úlohách priemernú presnosť 76,99 % a prekonáva Jev 1.14 o 1,47 percentuálneho bodu. Decider Flash v1.3 dosahuje 72,77 %, čím preukazuje schopnosti vizuálnej klasifikácie aj v menšom modeli.

Zväčšiť

Reálne rozhodovacie požiadavky

Vybrali sme vzorku jedného milióna deduplikovaných požiadaviek s maskovanými PII, ktoré boli odoslané do Perplexity Decision API počas prvých 18 dní jeho dostupnosti. Keďže každá požiadavka môže obsahovať viacero otázok o tom istom stave, vzorka obsahuje 2 318 887 jednotlivých otázok. Všetky požiadavky boli zahrnuté s výslovným súhlasom používateľov na výskumné účely.

Produkčné požiadavky neprichádzajú s referenčnými označeniami (ground truth), preto používame špičkové LLM ako hodnotiteľov na generovanie referenčných odpovedí a meriame mieru zhody každého modelu s nimi. Požiadavky tiež zoskupujeme do 10 kategórií úloh vrátane extrakcie informácií, doménovej klasifikácie, analýzy sentimentu, zámeru a smerovania, zoraďovania podľa relevantnosti, moderovania obsahu, kontroly kvality a súladu, párovania entít, obchodnej analýzy a kategórie „Iné“. Toto rozdelenie ukazuje, ako sa výkon líši v rôznych reálnych prípadoch použitia.

Zastúpenie úloh je nerovnomerné: na extrakciu informácií pripadá 425 402 otázok, na doménovú klasifikáciu 409 564 a na analýzu sentimentu 344 158. Spolu tieto tri kategórie tvoria 50,8 % otázok vo vzorke.

Decider v1.3 dosahuje najvyššiu zhodu s hodnotiteľmi, a to 93,98 %, v porovnaní s 93,68 % pri Decider v1.2 a 93,35 % pri Jev 1.14. Decider v1.3 a Jev 1.14 sú si veľmi blízko v doménovej klasifikácii a analýze sentimentu s rozdielmi 0,34, resp. 0,07 percentuálneho bodu. Jev vedie o 0,69 bodu v zoraďovaní podľa relevantnosti, zatiaľ čo Decider v1.3 vedie o 0,93 bodu v extrakcii informácií (najčastejšej úlohe vo vzorke) a o 1,21 bodu v zámere a smerovaní.

Zväčšiť

Graf nižšie porovnáva vykázané náklady na spracovanie toho istého jedného milióna produkčných požiadaviek. Každá požiadavka môže obsahovať viacero otázok, takže jednotkou sú tu požiadavky, nie jednotlivé otázky.

Zväčšiť

Robustnosť

Citlivosť na označenia sme vyhodnotili na 372 otázkach s výberom odpovede, pričom sme na každý model odoslali 4 788 požiadaviek. Menili sme poradie možností, priraďovali označenia k iným textom odpovedí a premenúvali označenia pri zachovaní významu každej otázky a potom sme kontrolovali, či sa sémantická odpoveď modelu zmenila. Nižšia miera zmien odpovedí znamená vyššiu stabilitu.

Decider v1.3 pri každej transformácii zmenil svoju odpoveď len pri 0,27 % otázok, v porovnaní s 2,69 – 4,84 % pri Jev 1.14. Opakovali sme aj identické vstupy, aby sme zmerali variabilitu pri obsluhe: Decider v1.3 nevykázal žiadne zmeny, zatiaľ čo Jev 1.14 zmenil odpoveď pri 1,88 % otázok.

Zväčšiť

Ako používame Decider

Decider je určený pre pracovné postupy, ktoré si vyžadujú rýchle a štruktúrované rozhodnutia. V tejto časti skúmame, ako ich využiť na dosiahnutie zmysluplného vplyvu na spôsob, akým pracujeme. Tu sú niektoré, ktoré vynikli.

Samozlepšujúce sa bezpečnostné pravidlá

Interne už Decider využívame na zlepšovanie našich bezpečnostných politík.

Aktivita našich agentov sa zaznamenáva a vykonáva sa séria kontrol založených na pravidlách s cieľom odhaliť akékoľvek problematické správanie. Prístup založený na pravidlách znamená, že môžeme našich agentov monitorovať v reálnom čase so zanedbateľnou pridanou latenciou. Offline používame Decider na skúmanie vzoriek z týchto zaznamenaných logov agentov. Ak nebolo označené žiadne problematické správanie, Decider skontroluje, či naša sada pravidiel niečo neprehliadla; a ak bol vyvolaný poplach, Decider overí, či nešlo o falošný poplach. Všetky záznamy, pri ktorých naša sada pravidiel v ktoromkoľvek z týchto prípadov zlyhá, sa odošlú agentovi na triáž a navrhne sa oprava pravidiel, ktorú musí schváliť člen nášho bezpečnostného tímu.

Za jeden deň Decider prečítal 1 miliardu tokenov naprieč 7 000 reláciami agentov a identifikoval nedostatky, ktoré viedli k 14 opravám pravidiel, z ktorých 6 bolo schválených a nasadených do dvoch dní. Pri opätovnom prehratí týždňa logov opravy znížili objem nášho najvyťaženejšieho pravidla o 52 % a rozšírené pravidlá zachytili približne o 40 % viac legitímnych akcií na prešetrenie.

Zväčšiť

Monitorovanie RL rolloutov

Keď modely dotrénovávame pomocou posilňovaného učenia, agregované metriky, ako je konečná odmena, nevysvetľujú, prečo rollout (jednotlivý pokus o úlohu) uspel alebo zlyhal. Rollout môže neprávom prísť o odmenu, pretože zlyhala služba nástroja alebo sandbox, alebo môže dostať nezaslúženú odmenu, ak hodnotiteľ prehliadne nepodložené tvrdenie, napríklad vymyslenú hodnotu, ktorú nevrátil žiadny nástroj.

Decider používame na monitorovanie rolloutov v týchto prípadoch. Kód najprv identifikuje časti rolloutu, ktoré si vyžadujú bližšiu kontrolu: neúspešné volanie nástroja a súvisiace uvažovanie, kód, ktorý prebehol bez chýb, alebo konečnú odpoveď. Decider potom odpovedá na otázky s výberom odpovede o každej časti, napríklad čo v danom kroku zlyhalo (služba nástroja, externá stránka, sandbox, harness alebo vlastný kód agenta) a či agent výsledok správne interpretoval. Všetky otázky o danej časti zoskupujeme do jednej požiadavky a ukladáme pravdepodobnosti namiesto verdiktu, takže prahové hodnoty môžeme neskôr upraviť bez opätovného dopytovania modelu Decider. Monitor iba pozoruje a diagnostikuje: nikdy nemení odmenu ani nezastavuje beh.

Zväčšiť

Filtrovanie stránok podľa kvality

Pri prehľadávaní webových stránok na indexovanie a poskytovanie používateľom je mnoho stránok príliš nekvalitných na to, aby boli na niečo užitočné. Patria sem steny proti botom, CAPTCHA a chybové stránky, ako aj správne načítané webové stránky, ktoré jednoducho neobsahujú žiadne užitočné informácie, napríklad spam, SEO výplň alebo stránky obsahujúce iba navigáciu. Tieto nekvalitné stránky je potrebné identifikovať a vyfiltrovať z nášho indexu.

Pomocou modelu Decider dokážeme posudzovať kvalitu stránok už počas ich prehľadávania (crawlingu). V tom istom doprednom prechode vykonávame aj sadu ďalších klasifikačných úloh, napríklad identifikáciu domény a cieľového publika obsahu a určenie, či obsahuje škodlivé, nelegálne alebo osobne identifikovateľné informácie. V porovnaní s použitím LLM ako hodnotiteľa je Decider výrazne rýchlejší a lacnejší.

Zväčšiť

Okrem týchto interných použití sa Decider hodí aj do pracovných postupov, ako sú nasledujúce.

Vizuálne QA

Keďže Decider číta obrázky, funguje aj ako vizuálny kontrolór, ktorý kontroluje zmeny štýlu webových stránok alebo aplikácií a identifikuje chyby. Ešte pred nasadením zmeny dokáže skontrolovať snímky obrazovky stránok, či neobsahujú orezaný text, prekrývajúce sa prvky alebo rozbité rozloženia, prípadne označiť grafy, ktorých dizajn by mohol čitateľa zavádzať alebo porušovať pravidlá značky.

Zväčšiť

Navigácia v prehliadači

Agenti môžu Decider používať na malé rozhodnutia v rámci väčších úloh. Agent prehliadača môže v každom kroku odoslať snímku obrazovky a dostať podrobné informácie o stave stránky a očakávanom výsledku každej možnej akcie.

Zväčšiť

Plánovanie výskumných úloh

Otázky používateľov sa môžu výrazne líšiť zložitosťou, rovnako ako hĺbka vyhľadávania potrebná na nájdenie odpovede. Decider to dokáže odhadnúť ešte pred začatím vyhľadávania, vďaka čomu sa na jednoduché otázky vynaloží menej zdrojov.

Zväčšiť

Začíname

Decider vracia pravdepodobnosti. Vhodný rozhodovací prah závisí od aplikácie. Frekvencie označení a relatívne náklady falošne pozitívnych a falošne negatívnych výsledkov sa v jednotlivých prípadoch použitia líšia. Preto odporúčame, aby používatelia ladili prahové hodnoty na malej, reprezentatívnej označenej vývojovej množine a nepredpokladali, že pevne stanovená hranica bude rovnako dobre fungovať naprieč úlohami.

Decider v1.3 odporúčame na nuansované posudzovanie, podrobné hodnotiace kritériá a pracovné postupy, v ktorých sú chyby nákladné. Decider Flash v1.3 zvoľte na veľkoobjemové smerovanie, označovanie a filtrovanie, kde sú hlavnými obmedzeniami latencia a náklady. Oba modely vyhodnoťte na reprezentatívnych príkladoch zo svojej pracovnej záťaže a potom vyberte model, ktorý spĺňa vaše požiadavky na kvalitu, latenciu a rozpočet.

Oba modely sú dostupné ako stiahnuteľné váhy na Hugging Face pod licenciou Apache, prostredníctvom OpenRouter a cez Perplexity Decisions API.

Citácia

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