Perplexity Decider

Hogyan tanítjuk, értékeljük és használjuk.

SzerzőkPerplexity Research

Közzétesszük a Decider v1.3 és a Decider Flash v1.3 modellt, korábbi döntési modelljeink utódait: v1, v1.1, v1.2 és Flash v1.2.

A Decider Flash v1.3 egy kisebb modell, amelyet a Decider v1.3-ból desztilláltunk. Mindkét modell elérhető a Hugging Face platformon Apache-licenc alatt, valamint az OpenRouter szolgáltatáson és a Perplexity Decisions API felületén keresztül.

A Perplexity Decidert a TypeSafe AI System One modellje, a Jev ihlette. Támogatja a bináris és többosztályos osztályozást rendezett vagy rendezetlen címkékkel, és olyan valószínűségeket ad vissza, amelyeket az alkalmazások bemenetek osztályozására, irányítására, rangsorolására és értékelésére használhatnak.

Mindkét v1.3-as modell jobb teljesítményt és robusztusságot nyújt a szöveges és vizuális feladatok széles körében a kétirányú figyelemnek, a gondosabban válogatott tanítóadatoknak és a továbbfejlesztett tanítási receptnek köszönhetően. Bemutatjuk a locate nevű új funkciót is, amely kiemeli a kiválasztott tartalmat névelem-felismerési, személyesadat-azonosítási és kinyerő kérdés-megválaszolási feladatokban.

Ebben a bejegyzésben bemutatjuk, hogyan tanítjuk és értékeljük a Decidert, és azt is, hogyan használjuk belsőleg a Perplexitynél.

Mi az a döntési modell?

A döntési modell egy általános célú osztályozó. Megadunk neki egy bemenetet és kérdések egy halmazát, mindegyiket a lehetséges válaszaival. A modell minden kérdésre valószínűségi eloszlást ad vissza a válaszok felett. 3 kérdéstípust támogat:

  • Igen / Nem: bináris döntések.
  • Feleletválasztós: egyéni, többosztályos címkék.
  • Pontszám: rendezett szintek.

A döntési modellek osztályozási és pontozási feladatok széles körét támogatják:

  • Kimenetek értékelése: a forráshűség, a minőség és a biztonság felmérése.
  • Irányítás: a kérések kisebb vagy nagyobb modellekhez irányítása a nehézségük alapján.
  • Moderálás és biztonság: káros tartalmak, adathalászat és promptinjektálás felismerése az eszközkimenetekben.
  • Szűrés és címkézés: nagy tartalomgyűjtemények rendszerezése.
  • Visszakeresés és újrarangsorolás: keresési találatok pontozása relevancia szerint.

Ezen feladatok közül sokat korábban generatív modellek, például LLM-ek kezeltek, holott nem igényelnek kötetlen szöveggenerálást. A döntési modellek az LLM-ek és a feladatspecifikus osztályozók között helyezkednek el. Egyetlen előre irányú futtatásban adnak vissza valószínűségeket több, ugyanarra a bemenetre vonatkozó kérdésre, így elkerülik a tokenenkénti válaszgenerálást, és a számítást megosztják a kérdések között. A feladatspecifikus osztályozókkal ellentétben természetes nyelvű promptokkal új feladatokat is képesek kezelni – ezt a rugalmasságot a sokféle feladaton, közös kérdés-válasz formátumban végzett tanítás során sajátítják el.

Tanítás

Generatív LLM átalakítása döntési modellé

A Decidert erős generatív LLM-gerincmodellek adaptálásával építjük. Az adaptáció magyarázatához először bemutatjuk, hogyan épül fel egy kérés. Ahogy alább látható, egy kérés egy közös kontextusból (az állapotból) és több kérdésből áll. Az állapotot minden kérdés újrahasznosítja.

Például egy dokumentum és annak összefoglalója esetén egyetlen kérés megkérdezheti, hogy az összefoglaló hűen tükrözi-e a dokumentumot, és hogy szakértőknek vagy a szélesebb közönségnek szól-e. Az állapot után minden kérdésblokk egy kérdést és annak lehetséges válaszait tartalmazza; mindegyik válasz egy előre meghatározott címketokent kap, például A, B vagy C. Egy speciális <|marker|> token jelzi, hol kell kiolvasni a modell előrejelzését. Ezen a pozíción egy tanult lineáris kimeneti réteg (döntési fej) a rejtett állapotot a kérdés válaszlehetőségeire vonatkozó pontszámokká képezi le, amelyeket aztán valószínűségekké alakítunk.

A kimeneti réteget az alapmodellből inicializáljuk, amely általában a teljes szókészletből pontozza a következő tokent, és csak az előre meghatározott opciótokeneknek (például A, B vagy C) megfelelő sorokat tartjuk meg. Ezt a megmetszett réteget ezután arra tanítjuk, hogy a <|marker|> rejtett állapotát válaszpontszámokká alakítsa. Ez a megközelítés minden osztályozási kérdést lefed, mivel mindegyik megfogalmazható feleletválasztós kérdésként.

A tanításhoz több száz nyilvános adatkészletet használunk, amelyek sokféle feladatot fednek le (hangulat, természetes nyelvi következtetés, szándékfelismerés, entitásegyeztetés, moderálás, tényellenőrzés, értékelések stb.), és minden példát a fent leírt egységes formátumra alakítunk: egy állapot, egy vagy több kérdés, ezek válaszlehetőségei és egy célérték. A célérték lehet az egyetlen helyes opció, ha rendelkezünk ellenőrzött (gold) címkékkel, vagy egy valószínűségi eloszlás az opciók felett.

A v1.3-ban bemutatjuk a locate funkciót, amely előre meghatározott opciók közüli választás helyett szöveget nyer ki az állapotból. Egy locate-kérdés leírja, mit kell megtalálni, akár egy rövid címkével, például „helyszín”, akár egy utasítással, például „Nyerd ki annak a városnak a nevét, ahol az állás található.” A modell visszaadja az állapotból a pontosan egyező szöveget a kezdő és záró karakterpozíciójával együtt. Ha nem talál egyezést, üres listát ad vissza.

A megosztott állapotnak köszönhetően egyetlen kérés kombinálhat locate-, osztályozási és pontozási kérdéseket ugyanarról a bemenetről. Megkérdezheti például, hogy egy állás megkövetel-e senior szintű tapasztalatot, és egyúttal kinyerheti a szükséges készségeket.

Kétirányú figyelem: hogy a modell mindkét irányba olvashasson

Modelljeink erős, előtanított generatív alapmodellekből indulnak ki, amelyek kauzális figyelme révén minden token csak önmagára és az előtte álló tokenekre figyelhet. Ablációs vizsgálataink kimutatták, hogy ha az alapmodell teljes figyelmű rétegeit kétirányúvá tesszük, javul a teljesítmény, ezért ezt a kialakítást alkalmazzuk, hogy minden token a teljes bemenet kontextusát figyelembe vehesse.

A kétirányú figyelem egy újabb tervezési döntést vet fel: hogyan hasson egymásra az állapot és a kérdések? Három figyelmi mintát vizsgáltunk, amelyek eltérő hatással vannak a teljesítményre, a válaszok stabilitására és a gyorsítótár újrafelhasználására:

  • Minden mindent lát (v1.2): Az állapotot és az összes kérdést együtt dolgozzuk fel, teljes kétirányú figyelemmel. Az állapoton végzett számítás megosztott, de egy kérdésre adott válasz attól függően változhat, hogy mi mást kérdezünk még.
  • Izolált kérdések (v1.3): Az állapot az összes kérdésre figyel, míg minden kérdés csak az állapotra és a saját tokenjeire. A kérdések a megosztott állapoton keresztül közvetve továbbra is hathatnak egymásra, de az eredmények stabilabbak.
  • Teljesen gyorsítótárazható: Az állapot csak önmagára figyel, míg minden kérdés az állapotra és a saját tokenjeire figyel. Az állapot független a kérdésektől, és több kérésen át újrahasznosítható, így kihasználható a promptgyorsítótárazás. Alapértelmezés szerint nem ezt használjuk, mert számos feladatnál sokat számít, hogy az állapot lássa a kérdéseket, de egy kisebb finomhangolással a modell átállítható erre a módra.

Végül az izolált kérdések mellett döntöttünk erős teljesítményük és stabilitásuk miatt.

Tanítási recept

A tanítás mindkét modellméretnél három szakaszban zajlik. Először a nagyobb, Qwen3.8-27B alapú modellt tanítjuk nagy adathalmazokon keresztentrópiával, majd ezt desztilláljuk a kisebb, Qwen3.5-4B modellbe.

Az első szakasz az általános tanítás, amelynek során a modellt nagy méretű korpuszokon teljes egészében finomhangoljuk. Ebben a szakaszban csak olyan adatokat fogadunk el, amelyek minden téren segítik a modellt, és nem specifikusak egyetlen benchmarkra sem; ezért kizárjuk a benchmarkok tanítási részhalmazait.

Miután ez az általános célú modell betanult, egy második, részletesebb szakaszt futtatunk LoRA segítségével. Az ebben a szakaszban használt adatok konkrét szakterületekre és feladatokra irányulnak. Akkor adunk hozzá adatokat a második szakaszban az első helyett, ha csak szűk körű javulást, vagy más feladatokon visszaesést tapasztalunk. A LoRA-t azért használjuk, hogy ne távolodjunk el túlságosan az általános célú modelltől, és ne kockáztassuk a teljesítmény romlását az adott szakterületekhez való illesztés kedvéért. A cél a teljesítmény javítása úgy, hogy közben megmaradjon a gerincmodell általános tudása. A LoRA alapmodellbe való visszaolvasztásakor súlyozást is alkalmazunk, hogy pontosabban szabályozzuk az eltolódást, és a visszatartott adatokon mért metrikákat előnyben részesítsük a szakterületen belüli javulásokkal szemben.

Végül egy vizuális feladatokra specializált lépést adunk hozzá. A második szakaszhoz hasonlóan ezt a lépést is egy további finomhangolt specializációs lépésként kezeljük, egy LoRA-adapterrel, amelyet egy súllyal visszaolvasztunk az alapmodellbe. Egyes vizuális képességek a szöveges teljesítmény rovására mehetnek. Mivel a modelleket sokkal inkább szöveges feladatokra használják, a szöveges metrikákat előnyben részesítjük a vizuálisakkal szemben.

Mindkét szöveges szakaszban három futtatás átlagolt súlyait használjuk, mindegyiket eltérő véletlen kezdőértékkel (seed). Azt tapasztaltuk, hogy ez javítja az aggregált modell teljesítményét és robusztusságát.

Miután megkaptuk a végleges nagy modellt, ugyanezt a háromszakaszos tanítási eljárást alkalmazzuk a kisebb modellre. Itt a nagy modell tanárként működik: a jósolt kimeneti eloszlása váltja fel a referenciacímkéket, a kisebb modellt pedig arra tanítjuk, hogy minimalizálja a saját előrejelzései és a tanár előrejelzései közötti KL-divergenciát. Ez a desztillációs célfüggvény ugyanazon tanítóadatokon felülmúlja a keresztentrópiát. Bár a keresztentrópia jobban teljesít azokon a benchmarkokon, amelyekhez dedikált tanítóadatok tartoznak, kevésbé jól általánosít a visszatartott adatokra. Feltételezésünk szerint a desztilláció jobban átadja a tanár kimeneti eloszlását, beleértve a referenciacímkén kívüli alternatívákra vonatkozó magabiztosságát is, míg a keresztentrópia a benchmarkspecifikus tanítási eloszlásra való túlilleszkedést ösztönzi. Ezért a KL-alapú desztillációs célfüggvényt alkalmazzuk.

A tanító- és tesztadatok közötti szennyeződés mérséklése érdekében eltávolítunk minden olyan tanítómintát, amely átfedésben lehet bármelyik általunk használt kiértékeléssel. Ez azért fontos, mert egyes nyilvános tanítóadat-halmazok bizonyos kiértékelési adathalmazok nagy részét tartalmazzák. Kiterjedt torzításvizsgálatokat és torzításeltávolítást is végzünk, hogy megbizonyosodjunk róla: az eredményeink megbízhatók, és nem csupán a megtanult torzítások okozzák őket.

Az információkinyerés képességének hozzáadása

A locate funkció információkat, például névelemeket nyer ki a szövegből anélkül, hogy megváltoztatná, hogyan válaszol a szokásos kérésekre. Ehhez egy további tanítási szakaszt vezetünk be: a Deciderhez hozzáadunk egy új speciális tokent, a <|locate|>, egy span-fejet és egy LoRA-adaptert.

A <|locate|> beágyazását a korábbi tanítási szakaszokban megtanult <|marker|> alapján inicializáljuk. Csak ezt az új beágyazást, a span-fejet és a LoRA-adaptereket tanítjuk, miközben az eredeti alapmodell súlyait és a döntési fejet befagyasztva hagyjuk. Minden kért mező saját <|locate|> tokent kap.

A span-fej a <|locate|> reprezentációját az állapottokenek reprezentációival együtt használja annak pontozására, hogy hol kezdődnek és hol végződnek az illeszkedő szövegszakaszok, és mely kezdő–záró párok tartoznak össze. A <|locate|> token reprezentációját arra is felhasználja, hogy mezőspecifikus küszöbértékeket jósoljon ezekhez a pontszámokhoz. A kiválasztott szakaszokat az eredeti szöveg karakterpozícióiként adja vissza.

A span-fejet egy adaptált InfoNCE-veszteséggel tanítjuk, amely minden referenciaszakaszt a küszöbérték fölé, a küszöbértéket pedig minden más szakasz fölé tolja. A veszteség két tagból áll: az első a helyes szakaszok pontszámait a küszöbérték és a hibás szakaszok fölé tolja. A második tag a küszöbértéket a hibás szakaszok pontszámai fölé tolja. A válasz nélküli mezők csak a második tagot kapják, ami megtanítja a modellt arra, hogy üres listát adjon vissza.

Szakaszkinyerési feladatok keverékén tanítunk, beleértve a névelem-felismerést, a személyes adatok (PII) felismerését és a kinyerő kérdés-megválaszolást. A mezőleírásokat a rövid címkéktől a részletes utasításokig változtatjuk, hogy a modell a kérés követését tanulja meg, ne pedig egy rögzített címkekészlet memorizálását.

A Locate szerkezetileg eltérő feladatra tanítja a modellt, és ezt úgy szeretnénk hozzáadni, hogy közben ne veszítsük el azt, amiben a modell már most is jó. A locate-adapterek gerincmodellbe olvasztása némi visszaesést okoz a döntési kéréseknél. Ennek korlátozására vizsgálatokat folytatunk, például a korábbi szakaszokból származó több visszajátszott adattal és olyan segédcélfüggvényekkel, amelyek a modell döntési kérésekre adott kimeneteit közel tartják az eredeti modell kimeneteihez. Ugyanakkor azt tapasztaljuk, hogy az összeolvasztás jelenleg még nem veszteségmentes, ezért az adaptereket nem olvasztjuk be, és csak locate-kérések esetén aktiváljuk őket.

Értékelés

A Decider v1.3 és a Decider Flash v1.3 modellt a Hugging Face Decision Index, a Vals AI ClaimBench és az Artificial Analysis Decision Index külső benchmarkjain értékeljük.

Ezeken a kiértékeléseken modelljeink erős teljesítményt mutatnak. Bár ezek a ranglisták nem nyilvános feladatokat is tartalmaznak, ismételt beküldéssel és a ranglista visszajelzésein alapuló iteratív hangolással továbbra is kijátszhatók. A ranglisták kiegészítéseként a modelleket egy belső tesztsorozaton is kiértékeljük, amely nem nyilvános éles feladatokat kombinál nyilvános, nem benchmark jellegű adathalmazokból vett visszatartott kiértékelésekkel. Ezek a kiértékelések a nyilvános benchmarkokon túl további ellenőrzést nyújtanak az általánosítóképességről, és segítenek megkülönböztetni a szélesebb körű fejlődést az ismert kiértékelési csomagokra jellemző javulásoktól.

Belsőleg egy több mint 200 feladatból álló készletet állítottunk össze, amely különböző területeket és feladattípusokat fed le, például osztályozást, pontozást, újrarangsorolást és entitáskinyerést. Hogy a Decider valós teljesítményét őszintén felmérjük, minden értékelést zero-shot módon, feladatspecifikus finomhangolás nélkül végzünk, így egyértelmű képet kapunk arról, hol kell fejleszteni a modellt.

Lekérdezés-osztályozás

A Perplexitynél többfejes osztályozórendszert használunk minden felhasználói lekérdezés feldolgozására. Minden lekérdezés először egy beágyazási modellen halad át, amely jellemzőkinyerőként működik. Az így kapott beágyazást ezután több különálló osztályozófejbe tápláljuk, köztük bináris és többcímkés osztályozókba is. Az egyik fej például azt határozza meg, hogy egy felhasználói lekérdezésnek el kell-e indítania egy webes keresést.

63 osztályozási feladaton, amelyek referenciáit egy élvonalbeli LLM egymástól függetlenül újracímkézte, a Decider v1.3 91,6%-os átlagos pontosságot ér el, ezzel 6,54 százalékponttal felülmúlja éles osztályozóinkat. A Decider Flash v1.3 szintén felülmúlja az éles alapvonalat, a Decider v1.3 pedig a Jev 1.14-et is felülmúlja.

Területspecifikus osztályozás

Nyilvános adatkészletekből területspecifikus értékelőkészletet állítottunk össze, hogy felmérjük a döntési modellek osztályozási teljesítményét hét területen: állításellenőrzés (6 feladat), egészségügy (7), kiberbiztonság (8), programozás (16), közigazgatás (7), jog (9) és pénzügy (9).

Például: „ítéld meg egy Python-program időbonyolultságát”, vagy „egy éves pénzügyi jelentés alapján állapítsd meg, hogy a vállalat szabad készpénze fedezi-e a következő tizenkét hónapban esedékes adósság tőkeösszegét”. A Decider v1.3 mind a hét területen az élen jár: pénzügyben akár 12,9, jogban 9,3 százalékponttal múlja felül a Jev 1.14-et. A Decider Flash v1.3 pénzügyben, programozásban és jogban elmarad a Jev 1.14-től, a többi területen pedig hasonlóan teljesít.

Visszakeresés és újrarangsorolás

A keresés a Perplexity alapja. A visszakeresési feladatok széles készletét tartjuk fenn modelljeink újrarangsorolási teljesítményének értékelésére. Minden feladatnál először beágyazási modellek egy csoportjával lekérjük az egyes korpuszokból az 50 legjobb jelölt dokumentumot. Ezután ezeket a jelölteket a Deciderrel újrarangsoroljuk, és teljesítményét egy erős újrarangsoroló alapmodellel, a Qwen3-Reranker-8B-vel vetjük össze.

A Decidert zero-shot, pontonkénti (pointwise) beállításban értékeljük: a modell minden lekérdezés–dokumentum párt közvetlenül és egymástól függetlenül pontoz, a dokumentumokat pedig relevancia szerint rangsoroljuk. 72 visszakeresési feladaton a Decider v1.3 átlagosan 83,99-es nDCG@10 értéket ér el, ezzel 1,81 ponttal felülmúlja a Qwen3-Reranker-8B-t, és 2,24 ponttal a Jev 1.14-et.

A BEIR benchmarkon mindkét modell felülmúlja a Qwen3-Reranker-8B-t, 8,78, illetve 7,05 nDCG@10 ponttal. A Jev 1.14-hez képest a Decider v1.3 1,33 ponttal magasabb, míg a Flash verzió 0,4 ponttal alacsonyabb pontszámot ér el.

Többnyelvű osztályozás

Hogy az angolon túl is értékeljük a döntési modelleket, összeállítottunk egy többnyelvű osztályozási benchmarkot, amely 8 nyilvános adatkészletből származó 19 nyelvspecifikus feladatot tartalmaz, összesen 46 484 példával nyolc nyelven: német, spanyol, francia, olasz, orosz, japán, koreai és kínai. A benchmark lefedi a szándékfelismerést, a témaosztályozást, a hangulatelemzést, a természetes nyelvi következtetést, a parafrázisfelismerést, a sértő nyelvezet felismerését és a nyelvtani elfogadhatóságot.

Minden nyelven a feladatok átlagos pontosságát közöljük, az egyes feladatokat azonos súllyal figyelembe véve. A Decider v1.3 mind a nyolc nyelven, a Decider Flash v1.3 pedig hat nyelven felülmúlja a Jev 1.14-et; az átlagos feladatpontosság a Decider v1.3 esetében 88,16%, a Decider Flash v1.3 esetében 86,50%, a Jev 1.14 esetében pedig 85,41%.

NER, PII és kinyerő kérdés-válasz

A locate funkciót 17 tartományon kívüli (out-of-domain) feladaton értékeljük, amelyek a kinyerést különböző területeken, bemeneti formátumokon (szöveg, táblázatok, strukturált dokumentumok) és utasítástípusokon (rövid címkék, kérdések és részletes leírások) tesztelik. A területek a Wikipédiától a tudományos cikkeken, kiberfenyegetési jelentéseken, műszaki támogatáson, adatvédelmi szabályzatokon és önéletrajzokon át a jogi szerződésekig terjednek. A kérések a rövid címkenevektől, például „személy” vagy „e-mail-cím”, a táblázatra vagy támogatási jegyre vonatkozó kérdéseken át a strukturált kinyeréshez használt részletes mezőleírásokig terjednek, mint például egy titoktartási megállapodás (NDA) felei vagy egy számla végösszege.

A NER- és PII-feladatokat pontos szakaszegyezésen alapuló F1-gyel (exact-span F1) értékeljük, amely megköveteli, hogy a jósolt szakaszok határai pontosan egyezzenek a referenciával. A kivonatoló kérdés-válasz (extractive QA) karakterszintű F1-et használ, amely az átfedő válaszszövegre részleges pontot ad, míg a strukturált kinyerés a mezőpontosságot, vagyis a helyesen kinyert mezők arányát méri. Az önéletrajz-elemzésnél a NER és a PII exact-span F1 pontszámainak átlagát vesszük.

Modelljeinket különböző méretű, általános célú kinyerő modellekkel hasonlítjuk össze: GLiNER large v2.5 (0,5B), Liquid d1 (2B) és a Cloudflare-féle Clairic (nem nyilvános méretű). A Decider v1.3 69,0-es átlagpontszámot ér el (az egyes feladatok elsődleges metrikája alapján), a Decider Flash v1.3 pedig 63,6-ot, szemben a Liquid d1 43,3-as, a Clairic 41,5-ös és a GLiNER large v2.5 33,6-os eredményével. Mindkét Decider-modell minden kategóriában vezet.

Képosztályozás

A Decider a v1 óta natívan támogatja a vizuális feladatokat. A szövegen túli teljesítményének értékelésére egy ötfeladatos benchmarkkészletet állítottunk össze, különös hangsúllyal a dokumentumosztályozásra, beleértve a számlákat, leveleket és önéletrajzokat. A készlet emellett lefedi a műholdkép-osztályozást, a textúraosztályozást, a háziállatfajta-osztályozást és az állatszámlálást.

A Decider v1.3 az öt vizuális feladaton 76,99%-os átlagos pontosságot ér el, ezzel 1,47 százalékponttal felülmúlja a Jev 1.14-et. A Decider Flash v1.3 72,77%-ot ér el, ami azt mutatja, hogy egy kisebb modell is képes vizuális osztályozásra.

Valós döntési kérések

Egymillió deduplikált, PII-maszkolt kérésből vettünk mintát, amelyeket a Perplexity Decision API elérhetőségének első 18 napjában küldtek be. Mivel minden kérés több kérdést is tartalmazhat ugyanarról az állapotról, a minta 2 318 887 egyedi kérdést foglal magában. Minden kérést a felhasználók kifejezett, kutatási célú engedélyével vontunk be.

Az éles kérésekhez nem tartoznak valós (ground-truth) címkék, ezért élvonalbeli LLM-bírákkal generálunk referenciaválaszokat, és mérjük, mennyire egyeznek velük az egyes modellek válaszai. A kéréseket emellett 10 feladatkategóriába soroljuk: információkinyerés, témaköri osztályozás, hangulatelemzés, szándék és irányítás, relevancia szerinti rangsorolás, tartalommoderálás, minőségi és megfelelőségi ellenőrzés, entitásegyeztetés, üzleti elemzés, valamint egy „Egyéb” kategória. Ez a bontás megmutatja, hogyan változik a teljesítmény a valós felhasználási esetek között.

A feladatok megoszlása egyenetlen: az információkinyerés 425 402, a témaköri osztályozás 409 564, a hangulatelemzés pedig 344 158 kérdést tesz ki. Ez a három kategória együtt a mintában szereplő kérdések 50,8%-át adja.

A Decider v1.3 éri el a legnagyobb egyezést a bírákkal, 93,98%-kal, szemben a Decider v1.2 93,68%-ával és a Jev 1.14 93,35%-ával. A Decider v1.3 és a Jev 1.14 fej fej mellett halad a témaköri osztályozásban és a hangulatelemzésben, 0,34, illetve 0,07 százalékpontos különbséggel. A Jev 0,69 ponttal vezet a relevancia szerinti rangsorolásban, míg a Decider v1.3 0,93 ponttal vezet az információkinyerésben (ez a minta leggyakoribb feladata), és 1,21 ponttal a szándék és irányítás kategóriában.

Az alábbi diagram ugyanannak az egymillió éles kérésnek a futtatására jelentett költségeket hasonlítja össze. Minden kérés több kérdést is tartalmazhat, ezért itt az egység a kérés, nem az egyes kérdések.

A Decider helyben futott; a GLM és a DeepSeek az llm-api-t, a Jev az OpenRoutert használta. A jelentett költségek az adott munkaterhelésre vonatkoznak, a helyi hardverköltségek elszámolása nincs meghatározva, és nem készült azonos késleltetési feltételek melletti összehasonlítás.

Robusztusság

A címkeérzékenységet 372 feleletválasztós kérdésen értékeltük, modellenként 4788 kéréssel. Átrendeztük a válaszlehetőségeket, a címkéket más válaszszövegekhez rendeltük, és átneveztük a címkéket, miközben minden kérdés jelentése változatlan maradt, majd ellenőriztük, hogy megváltozott-e a modell szemantikai válasza. Az alacsonyabb átfordulási arány nagyobb stabilitást jelez.

A Decider v1.3 az egyes transzformációk mellett a kérdéseknek mindössze 0,27%-ánál változtatta meg a válaszát, szemben a Jev 1.14 2,69–4,84%-os értékével. Azonos bemeneteket is megismételtünk a kiszolgálási változékonyság mérésére: a Decider v1.3 esetében nem volt változás, míg a Jev 1.14 a kérdések 1,88%-ánál változtatott.

Hogyan használjuk a Decidert

A Decidert olyan munkafolyamatokhoz terveztük, amelyek gyors és strukturált döntéseket igényelnek. Ebben a részben bemutatjuk, hogyan használhatjuk ki úgy, hogy érdemben formálja a munkavégzésünket. Íme néhány kiemelkedő példa.

Önmagukat fejlesztő biztonsági szabályok

Belső használatban már most is a Decidert alkalmazzuk biztonsági szabályzataink fejlesztésére.

Ügynökeink tevékenységét rögzítjük, és szabályalapú ellenőrzések sorozatával azonosítjuk az esetleges problémás viselkedést. A szabályalapú megközelítésnek köszönhetően ügynökeinket valós időben, elhanyagolható többletkésleltetéssel figyelhetjük. Offline a Decider segítségével mintákat vizsgálunk ezekből a rögzített ügynöknaplókból. Ha nem jeleztek problémás viselkedést, a Decider ellenőrzi, nem hagyott-e ki valamit a szabálykészletünk; ha pedig riasztás történt, a Decider megvizsgálja, hogy téves riasztásról van-e szó. Azokat a rekordokat, amelyeknél a szabálykészletünk bármelyik esetben hibázik, egy ügynökhöz továbbítjuk kivizsgálásra, amely javaslatot tesz a szabályok javítására; a javítást biztonsági csapatunk egyik tagja hagyja jóvá.

A Decider egyetlen nap alatt 1 milliárd tokent olvasott be 7000 ügynök-munkamenetből, és olyan hibákat azonosított, amelyek 14 szabályjavításhoz vezettek; ezek közül 6-ot két napon belül jóváhagytak és élesítettek. Egyheti naplón visszajátszva a javítások 52%-kal csökkentették a legforgalmasabb szabályunk által kiváltott jelzések számát, a kibővített szabályok pedig körülbelül 40%-kal több, valóban kivizsgálást érdemlő műveletet szűrtek ki.

RL-rolloutok monitorozása

Amikor a modelleket megerősítéses tanulással utótanítjuk, az összesített metrikák, például a végső jutalom, nem magyarázzák meg, miért sikerült vagy bukott el egy rollout (egy feladat egyedi végrehajtási kísérlete). Egy rollout igazságtalanul veszíthet jutalmat, mert egy eszközszolgáltatás vagy a sandbox meghibásodott, vagy érdemtelen jutalmat kaphat, ha az értékelő figyelmen kívül hagy egy alátámasztatlan állítást, például egy kitalált értéket, amelyet egyetlen eszköz sem adott vissza.

A Decidert arra használjuk, hogy a rolloutokat ezekre az esetekre figyeljük. Először kód azonosítja a rollout azon részeit, amelyek közelebbi vizsgálatot igényelnek: egy sikertelen eszközhívást és a körülötte zajló érvelést, a hiba nélkül lefutott kódot vagy a végső választ. Ezután a Decider feleletválasztós kérdésekre válaszol az egyes részekről, például arról, hogy mi hibásodott meg egy lépésben (egy eszközszolgáltatás, egy külső webhely, a sandbox, a harness vagy az ügynök saját kódja), és hogy az ügynök helyesen értelmezte-e az eredményt. Egy adott részre vonatkozó összes kérdést egyetlen kérésbe csomagoljuk, és ítélet helyett a valószínűségeket tároljuk, így később a Decider újbóli lekérdezése nélkül módosíthatjuk a küszöbértékeket. A monitor csak megfigyel és diagnosztizál: soha nem változtat a jutalmon, és soha nem állít le egy futtatást.

Oldalminőség-szűrés

Amikor weboldalakat térképezünk fel, hogy indexeljük és a felhasználók elé tárjuk őket, sok oldal túl gyenge minőségű ahhoz, hogy bármi haszna legyen. Ide tartoznak a botellenes falak, a CAPTCHA-k és a hibaoldalak, valamint azok a helyesen betöltött weboldalak is, amelyek egyszerűen nem tartalmaznak hasznos információt, például a spam, a SEO-töltelék vagy a csak navigációt tartalmazó oldalak. Ezeket a gyenge minőségű oldalakat azonosítani kell, és ki kell szűrni az indexünkből.

A Decider segítségével már a webhelyek bejárása közben meg tudjuk ítélni az oldalak minőségét. Ugyanazon előre irányú futtatás (forward pass) során egy sor más osztályozási feladatot is elvégzünk, például azonosítjuk a tartalom szakterületét és célközönségét, valamint azt, hogy tartalmaz-e káros, illegális vagy személyazonosításra alkalmas információt. Egy LLM-alapú értékelőhöz képest a Decider jelentősen gyorsabb és olcsóbb.

Szemléltető oldalminőség-kérés: a hasznos információt, a célközönséget, a káros vagy illegális tartalmat és a személyazonosításra alkalmas adatokat ugyanazon oldal alapján értékeljük.

A belső felhasználásokon túl a Decider például az alábbi munkafolyamatokba is jól illeszkedik.

Vizuális kérdés-válasz

Mivel a Decider képeket is olvas, vizuális ellenőrként is működik: átnézi a weboldalak vagy alkalmazások stílusváltozásait, és azonosítja a hibákat. Egy változtatás élesítése előtt képes átnézni az oldalak képernyőképeit levágott szöveg, egymást átfedő elemek vagy hibás elrendezések után kutatva, illetve megjelölheti azokat a diagramokat, amelyek kialakítása félrevezetheti az olvasót vagy sértheti a márkairányelveket.

Böngészőnavigáció

Az ügynökök a Decidert a nagyobb feladatokon belüli kisebb döntésekhez használhatják. Egy böngészőügynök minden lépésben küldhet egy képernyőképet, és részletes információt kaphat az oldal állapotáról, valamint az egyes lehetséges műveletek várható kimeneteléről.

Kutatási feladatok tervezése

A felhasználók kérdései összetettségükben nagyon eltérőek lehetnek, ahogy a válasz megtalálásához szükséges keresés mélysége is. A Decider ezt még a keresés megkezdése előtt képes megbecsülni, így az egyszerű kérdésekre kevesebb erőforrást kell fordítani.

Első lépések

A Decider valószínűségeket ad vissza. A megfelelő döntési küszöb az alkalmazástól függ. A címkék gyakorisága, valamint a hamis pozitív és hamis negatív eredmények relatív költsége felhasználási esetenként eltérő. Ezért azt javasoljuk, hogy a felhasználók egy kis, reprezentatív, címkézett fejlesztési adatkészleten hangolják a küszöbértékeket, ahelyett hogy azt feltételeznék, hogy egy rögzített határérték minden feladaton egyformán jól működik.

Árnyalt döntésekhez, részletes értékelési szempontrendszerekhez és olyan munkafolyamatokhoz, ahol a hibák költségesek, a Decider v1.3 használatát javasoljuk. Nagy volumenű útválasztáshoz, címkézéshez és szűréshez, ahol a késleltetés és a költség a fő korlát, a Decider Flash v1.3 a jobb választás. Mindkét modellt érdemes a saját munkaterhelésből vett reprezentatív példákon kiértékelni, majd azt választani, amelyik megfelel a minőségi, késleltetési és költségvetési követelményeknek.

Mindkét modell letölthető súlyokként elérhető a Hugging Face platformon Apache-licenc alatt, valamint az OpenRouter szolgáltatáson és a Perplexity Decisions API felületén keresztül.

Hivatkozás

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