Perplexity Decider
Kaip jį mokome, vertiname ir naudojame.
Pristatome Decider v1.3 ir Decider Flash v1.3 – ankstesnių mūsų sprendimų modelių v1, v1.1, v1.2 ir Flash v1.2 įpėdinius.
Decider Flash v1.3 – mažesnis modelis, distiliuotas iš Decider v1.3. Abu modeliai pagal Apache licenciją prieinami Hugging Face platformoje, per OpenRouter ir Perplexity Decisions API.
Perplexity Decider įkvėptas Jev – TypeSafe AI sukurto System One Model. Jis palaiko dvejetainį ir kelių klasių klasifikavimą su eiliškumą turinčiomis arba neturinčiomis žymėmis ir grąžina tikimybes, kurias programos gali naudoti įvestims klasifikuoti, nukreipti, reitinguoti ir vertinti.
Abu v1.3 modeliai pagerina našumą ir patikimumą įvairiose teksto ir vaizdo užduotyse dėl dvikrypčio dėmesio, geriau atrinktų mokymo duomenų ir patobulinto mokymo recepto. Taip pat pristatome locate – naują funkciją, kuri pažymi pasirinktą turinį įvardytųjų esybių atpažinimo, asmeninės informacijos identifikavimo ir ištraukiamojo atsakymo į klausimus užduotyse.
Šiame įraše paaiškiname, kaip mokome ir vertiname Decider, ir pasakojame, kaip jį naudojame Perplexity viduje.
Kas yra sprendimų modelis?
Sprendimų modelis yra bendrosios paskirties klasifikatorius. Pateikiate jam įvestį ir klausimų rinkinį, kurių kiekvienas turi galimus atsakymus. Kiekvienam klausimui jis grąžina tikimybių pasiskirstymą tarp atsakymų. Jis palaiko 3 klausimų tipus:
- Taip / Ne: dvejetainiai sprendimai.
- Keli atsakymų variantai: pasirinktinės kelių klasių žymės.
- Balas: surikiuoti lygiai.
Sprendimų modeliai palaiko įvairias klasifikavimo ir vertinimo užduotis:
- Išvesčių vertinimas: atitikties šaltiniui, kokybės ir saugos įvertinimas.
- Maršrutizavimas: užklausų nukreipimas į mažesnius ar didesnius modelius pagal sudėtingumą.
- Moderavimas ir saugumas: žalingo turinio, sukčiavimo (phishing) ir raginimų injekcijų (prompt injection) aptikimas įrankių išvestyse.
- Filtravimas ir žymėjimas: didelių turinio rinkinių tvarkymas.
- Paieška ir pakartotinis reitingavimas: paieškos rezultatų vertinimas pagal aktualumą.
Daugelį šių užduočių anksčiau atlikdavo generatyvieji modeliai, pavyzdžiui, LLM, nors joms nereikia laisvos formos teksto generavimo. Sprendimų modeliai yra tarpinis variantas tarp LLM ir konkrečioms užduotims skirtų klasifikatorių. Jie per vieną tiesioginį perėjimą grąžina tikimybes keliems klausimams apie tą pačią įvestį, todėl nereikia generuoti atsakymo žetonas po žetono, o skaičiavimai bendrinami tarp klausimų. Skirtingai nei konkrečioms užduotims skirti klasifikatoriai, jie gali atlikti naujas užduotis pagal raginimus natūralia kalba – šio lankstumo jie išmoksta mokydamiesi atlikti įvairias užduotis bendru klausimų ir atsakymų formatu.
Mokymas
Kaip generatyvinį LLM paversti sprendimų modeliu
Decider kuriame pritaikydami galingus generatyviųjų LLM pagrindinius modelius. Kad paaiškintume šį pritaikymą, pirmiausia aprašome, kaip pateikiama užklausa. Kaip parodyta toliau, užklausą sudaro bendras kontekstas (būsena) ir tam tikras skaičius klausimų. Būseną pakartotinai naudos visi klausimai.
Pavyzdžiui, turint dokumentą ir jo santrauką, vienoje užklausoje galima paklausti, ar santrauka tiksliai atspindi dokumentą ir ar ji skirta ekspertui, ar plačiajai auditorijai. Po būsenos kiekviename klausimų bloke pateikiamas klausimas ir galimi jo atsakymai, kurių kiekvienam priskiriamas iš anksto apibrėžtas žymės žetonas, pavyzdžiui, A, B arba C. Specialus <|marker|> žetonas nurodo, kur nuskaityti modelio prognozę. Šioje pozicijoje išmoktas tiesinis išvesties sluoksnis (sprendimų galvutė) paslėptąją būseną susieja su klausimo atsakymų variantų įverčiais, kurie tada konvertuojami į tikimybes.
Išvesties sluoksnį inicializuojame iš bazinio modelio, kuris įprastai įvertina kitą žetoną iš viso žodyno, ir paliekame tik eilutes, atitinkančias iš anksto apibrėžtus parinkčių žetonus, pavyzdžiui, A, B arba C. Tada šis apkarpytas sluoksnis mokomas paversti žetono <|marker|> paslėptąją būseną atsakymų įverčiais. Šis metodas apima visus klasifikavimo klausimus, nes juos visus galima suformuluoti kaip klausimus su keliais atsakymų variantais.
Mokymui naudojame šimtus viešų duomenų rinkinių, apimančių įvairias užduotis (nuotaikų analizę, natūraliosios kalbos išvadų darymą, ketinimų nustatymą, esybių susiejimą, moderavimą, faktų tikrinimą, įvertinimus ir kt.), ir kiekvieną pavyzdį konvertuojame į anksčiau aprašytą vieningą formatą: būseną, vieną ar daugiau klausimų, jų parinktis ir tikslą. Tikslas gali būti vienintelė teisinga parinktis, jei turime etalonines žymes, arba tikimybių pasiskirstymas tarp parinkčių.
Versijoje v1.3 pristatome locate – funkciją, kuri ne renkasi iš iš anksto apibrėžtų parinkčių, o išgauna tekstą iš būsenos. Locate klausime aprašoma, ką reikia rasti, naudojant trumpą žymę, pavyzdžiui, „vieta“, arba instrukciją, pavyzdžiui, „Išgauk miesto, kuriame yra darbo vieta, pavadinimą“. Modelis grąžina tiksliai sutampantį tekstą iš būsenos kartu su jo pradžios ir pabaigos simbolių pozicijomis. Jei atitikmenų neranda, grąžina tuščią sąrašą.
Dėl bendros būsenos vienoje užklausoje galima sujungti locate, klasifikavimo ir vertinimo klausimus apie tą pačią įvestį. Pavyzdžiui, galima paklausti, ar darbui reikia vyresniojo specialisto lygio patirties, ir išgauti reikalingus įgūdžius.
Dvikryptis dėmesys: modelis skaito į abi puses
Mūsų modeliai kuriami remiantis stipriais iš anksto apmokytais generatyviniais pagrindiniais modeliais (backbone), kurių priežastinis dėmesys leidžia kiekvienam žetonui atsižvelgti tik į save ir ankstesnius žetonus. Mūsų abliacijos tyrimai parodė, kad pagrindinio modelio visiško dėmesio sluoksnius padarius dvikrypčiais našumas pagerėja, todėl taikome šį sprendimą, kad kiekvienas žetonas galėtų įtraukti visos įvesties kontekstą.
Dvikryptis dėmesys kelia dar vieną projektavimo klausimą: kaip turėtų sąveikauti būsena ir klausimai? Apsvarstėme tris dėmesio schemas, turinčias skirtingą poveikį našumui, atsakymų stabilumui ir pakartotiniam talpyklos naudojimui:
- Viskas mato viską (v1.2): Būsena ir visi klausimai apdorojami kartu, taikant visišką dvikryptį dėmesį. Skaičiavimai su būsena bendri, tačiau atsakymas į vieną klausimą gali keistis priklausomai nuo to, ko dar klausiama.
- Izoliuoti klausimai (v1.3): Būsena skiria dėmesį visiems klausimams, o kiekvienas klausimas – tik būsenai ir savo žetonams. Klausimai vis tiek gali netiesiogiai paveikti vienas kitą per bendrą būseną, tačiau rezultatai stabilesni.
- Visiškai talpinama į podėlį: būsena kreipia dėmesį tik į save, o kiekvienas klausimas kreipia dėmesį į būseną ir savo paties žetonus. Būsena nepriklauso nuo klausimų ir gali būti pakartotinai naudojama skirtingose užklausose, kad būtų išnaudotas raginimų talpinimas podėlyje. Pagal numatytuosius nustatymus šio režimo nenaudojame, nes kelioms užduotims labai svarbu, kad būsena matytų klausimus, tačiau nedidelis papildomas derinimas gali perjungti modelį į šį režimą.
Galiausiai pasirinkome izoliuotus klausimus dėl jų gero našumo ir stabilumo.
Mokymo receptas
Abiejų dydžių modeliai mokomi trimis etapais. Pirmiausia, naudodami kryžminę entropiją dideliuose duomenų rinkiniuose, mokome didesnį modelį, paremtą Qwen3.8-27B, o tada distiliuojame jį į mažesnį Qwen3.5-4B modelį.
Pirmasis etapas – bendrasis mokymas, kurio metu modelį visiškai papildomai apmokome (fine-tune) su didelės apimties tekstynais. Šiame etape priimame tik tuos duomenis, kurie padeda modeliui visapusiškai ir nėra skirti jokiam konkrečiam lyginamajam testui; todėl neįtraukiame jokių lyginamųjų testų mokymo duomenų dalių.
Ištreniravę šį bendrosios paskirties modelį, vykdome antrą, smulkesnį etapą naudodami LoRA. Šiame etape naudojami duomenys skirti konkrečioms sritims ir užduotims. Duomenis įtraukiame į antrąjį etapą, o ne į pirmąjį, jei pastebime tik siaurą naudą arba tam tikrą regresiją kitose užduotyse. LoRA naudojame tam, kad per daug nenutoltume nuo bendrosios paskirties modelio ir nerizikuotume prarasti našumo prisitaikydami prie tų konkrečių sričių. Tikslas – pagerinti našumą išlaikant bendrąsias pagrindinio modelio žinias. Suliedami LoRA atgal į bazinį modelį taip pat taikome svorį, kad tiksliau kontroliuotume nuokrypį ir teiktume pirmenybę atidėtųjų duomenų metrikoms, o ne bet kokiai naudai pačioje srityje.
Galiausiai pridedame vaizdams skirtą žingsnį. Panašiai kaip antrasis etapas, vaizdo žingsnis laikomas dar vienu smulkesnės specializacijos žingsniu, naudojant LoRA adapterį, kuris su tam tikru svoriu vėl sujungiamas su baziniu modeliu. Kai kurie vaizdo gebėjimai gali būti įgyjami teksto našumo sąskaita. Kadangi pastebime, kad modeliai daug dažniau naudojami tekstui, teksto metrikoms teikiame pirmenybę prieš vaizdo metrikas.
Abiem tekstinio mokymo etapams naudojame trijų paleidimų, kurių kiekviename naudota vis kita atsitiktinė sėkla, vidutinius svorius. Nustatėme, kad tai pagerina sujungto modelio našumą ir patikimumą.
Gavę galutinį didįjį modelį, tą pačią trijų etapų mokymo procedūrą taikome mažesniam modeliui. Čia didysis modelis veikia kaip mokytojas: jo numatytas išvesties skirstinys pakeičia etalonines žymas, o mažesnis modelis mokomas minimizuoti KL divergenciją tarp savo ir mokytojo prognozių. Ši distiliavimo tikslo funkcija su tais pačiais mokymo duomenimis pranoksta kryžminę entropiją. Nors kryžminė entropija geriau veikia su lyginamaisiais testais, turinčiais specialius mokymo duomenis, ji prasčiau apibendrina atidėtuosius duomenis. Keliame hipotezę, kad distiliavimas geriau perduoda mokytojo išvesties skirstinį, įskaitant jo pasitikėjimą ne etaloninėmis alternatyvomis, o kryžminė entropija skatina per daug prisitaikyti prie konkrečiam lyginamajam testui būdingo mokymo duomenų skirstinio. Todėl pasirenkame KL pagrįstą distiliavimo tikslo funkciją.
Kad sumažintume mokymo ir testavimo duomenų užterštumą, pašaliname visus mokymo pavyzdžius, kurie galėtų sutapti su bet kuriuo mūsų naudojamu vertinimu. Tai svarbu, nes kai kuriuose viešuose mokymo duomenų rinkiniuose yra didelės kai kurių vertinimo duomenų rinkinių dalys. Taip pat atliekame išsamius šališkumo auditus ir šališkumą šaliname, kad įsitikintume, jog mūsų pasiekimai yra patikimi, o ne nulemti vien išmoktų šališkumų.
Informacijos išgavimo galimybės pridėjimas
Funkcija locate išgauna iš teksto informaciją, pavyzdžiui, įvardytąsias esybes, nekeisdama to, kaip atsako į įprastas užklausas. Tam pristatome papildomą mokymo etapą: prie Decider pridedame naują specialųjį žetoną <|locate|>, intervalų galvutę (span head) ir LoRA adapterį.
Žetono <|locate|> įterpinį inicializuojame iš ankstesniuose mokymo etapuose išmokto <|marker|>. Mokome tik šį naują įterpinį, intervalų galvutę ir LoRA adapterius, o pradinio pagrindinio modelio svorius ir sprendimų galvutę paliekame užšaldytus. Kiekvienas prašomas laukas gauna savo <|locate|> žetoną.
Atkarpų galva naudoja <|locate|> reprezentaciją kartu su būsenos žetonų reprezentacijomis, kad įvertintų, kur prasideda ir baigiasi atitinkančios atkarpos ir kurios pradžios ir pabaigos poros priklauso viena kitai. Ji taip pat naudoja žetono <|locate|> reprezentaciją, kad numatytų šių įverčių slenksčius, būdingus konkretiems laukams. Pasirinktos atkarpos grąžinamos kaip simbolių pozicijos pradiniame tekste.
Atkarpų galvą mokome taikydami pritaikytą InfoNCE nuostolių funkciją, kuri kiekvieną etaloninę atkarpą pakelia virš slenksčio, o slenkstį – virš visų kitų atkarpų. Nuostolių funkciją sudaro du nariai: pirmasis pakelia teisingų atkarpų įverčius virš slenksčio ir neteisingų atkarpų įverčių. Antrasis narys pakelia slenkstį virš neteisingų atkarpų įverčių. Laukams, kuriems nėra atsakymo, taikomas tik antrasis narys, todėl modelis išmoksta grąžinti tuščią sąrašą.
Mokome taikydami įvairias intervalų išgavimo užduotis, įskaitant įvardytųjų esybių atpažinimą, PII aptikimą ir ištraukiamąjį atsakymą į klausimus. Laukų aprašymus keičiame nuo trumpų žymių iki išsamių instrukcijų, kad modelis išmoktų vykdyti užklausą, o ne įsiminti fiksuotą žymių rinkinį.
Locate moko modelį struktūriškai kitokios užduoties, ir norime ją pridėti neprarasdami to, ką modelis jau daro gerai. Sujungus locate adapterius su pagrindiniu modeliu, sprendimų užklausų rezultatai šiek tiek suprastėja. Kad tai apribotume, atliekame tyrimus, pavyzdžiui, naudojame daugiau pakartotinio mokymo duomenų iš ankstesnių etapų ir pagalbines tikslo funkcijas, kurios išlaiko modelio išvestis sprendimų užklausoms artimas pradinio modelio išvestims. Vis dėlto pastebime, kad sujungimas kol kas vis dar nėra be nuostolių, todėl adapterių nesujungiame ir aktyvuojame juos tik locate užklausoms.
Vertinimas
Decider v1.3 ir Decider Flash v1.3 vertiname naudodami išorinius lyginamuosius testus iš Hugging Face Decision Index, Vals AI ClaimBench ir Artificial Analysis Decision Index.
Šiuose vertinimuose mūsų modeliai pasiekia puikių rezultatų. Nors į šias reitingų lenteles įtrauktos privačios užduotys, jomis vis tiek galima manipuliuoti kartotinai teikiant rezultatus ir iteratyviai derinant modelius pagal reitingų lentelės grįžtamąjį ryšį. Siekdami papildyti šias reitingų lenteles, modelius vertiname vidiniu rinkiniu, kuriame derinamos privačios produkcinės užduotys ir atidėtieji vertinimai, sudaryti iš viešų duomenų rinkinių, kurie nėra lyginamieji testai. Šie vertinimai suteikia papildomą apibendrinimo patikrą už viešųjų lyginamųjų testų ribų ir padeda mums atskirti platesnius patobulinimus nuo laimėjimų, būdingų tik gerai žinomiems vertinimų rinkiniams.
Viduje sukūrėme daugiau nei 200 užduočių rinkinį, apimantį įvairias sritis ir užduotis, tokias kaip klasifikavimas, vertinimas, pakartotinis reitingavimas ir esybių išgavimas. Kad sąžiningai įvertintume Decider našumą realiomis sąlygomis, visi vertinimai atliekami be pavyzdžių (zero-shot) ir be konkrečiai užduočiai pritaikyto papildomo mokymo, todėl aiškiai matome, kur modelį reikia tobulinti.
Užklausų klasifikavimas
Bendrovėje Perplexity kiekvienai naudotojo užklausai apdoroti naudojame kelių galvučių klasifikavimo sistemą. Kiekviena užklausa pirmiausia perduodama įterpinių modeliui, kuris veikia kaip požymių išgavimo priemonė. Gautas įterpinys tada perduodamas kelioms atskiroms klasifikavimo galvutėms, įskaitant ir dvejetainius, ir kelių žymių klasifikatorius. Pavyzdžiui, viena galvutė nustato, ar naudotojo užklausa turėtų paleisti paiešką žiniatinklyje.
Atliekant 63 klasifikavimo užduotis, kurių etalonus nepriklausomai iš naujo pažymėjo pažangiausias LLM, Decider v1.3 pasiekia 91,6 % vidutinį tikslumą ir 6,54 procentinio punkto lenkia mūsų gamybinius klasifikatorius. Decider Flash v1.3 taip pat lenkia gamybinį bazinį modelį, o Decider v1.3 lenkia Jev 1.14.
Konkrečių sričių klasifikavimas
Iš viešų duomenų rinkinių sudarėme konkrečioms sritims skirtą vertinimo rinkinį, kad įvertintume sprendimų modelių klasifikavimo našumą septyniose srityse: teiginių tikrinimo (6 užduotys), sveikatos priežiūros (7), kibernetinio saugumo (8), programavimo (16), viešojo valdymo (7), teisės (9) ir finansų (9).
Pavyzdžiui, „įvertink Python programos laiko sudėtingumą“ arba „pagal metinę finansinę ataskaitą nustatyk, ar įmonės laisvai disponuojami grynieji pinigai padengia per ateinančius dvylika mėnesių grąžintiną skolos pagrindinę sumą“. Decider v1.3 pirmauja visose septyniose srityse ir lenkia Jev 1.14 iki 12,9 procentinio punkto finansų ir 9,3 punkto teisės srityje. Decider Flash v1.3 finansų, programavimo ir teisės srityse atsilieka nuo Jev 1.14, o kitose srityse veikia panašiai.
Paieška ir pakartotinis reitingavimas
Paieška yra Perplexity pagrindas. Palaikome platų paieškos užduočių rinkinį, kad įvertintume savo modelių pakartotinio reitingavimo našumą. Kiekvienai užduočiai pirmiausia naudojame įterpinių modelių rinkinį, kad iš kiekvieno korpuso atrinktume 50 geriausių kandidatinių dokumentų. Tada šiuos kandidatus iš naujo reitinguojame naudodami Decider ir lyginame jo našumą su stipriu baziniu pakartotinio reitingavimo modeliu Qwen3-Reranker-8B.
Decider vertiname be pavyzdžių (zero-shot), taškiniu (pointwise) režimu: modelis tiesiogiai ir nepriklausomai įvertina kiekvieną užklausos ir dokumento porą, o dokumentai reitinguojami pagal aktualumą. Atliekant 72 paieškos užduotis, Decider v1.3 pasiekia vidutinį 83,99 nDCG@10 rodiklį ir lenkia Qwen3-Reranker-8B 1,81 punkto, o Jev 1.14 – 2,24 punkto.
BEIR lyginamajame teste abu modeliai lenkia Qwen3-Reranker-8B atitinkamai 8,78 ir 7,05 nDCG@10 punkto. Palyginti su Jev 1.14, Decider v1.3 rezultatas 1,33 punkto aukštesnis, o Flash versijos – 0,4 punkto žemesnis.
Daugiakalbis klasifikavimas
Kad įvertintume sprendimų modelius ne tik anglų kalba, sudarėme daugiakalbį klasifikavimo lyginamąjį testą, kurį sudaro 19 konkrečiai kalbai skirtų užduočių iš 8 viešų duomenų rinkinių, su 46 484 pavyzdžiais aštuoniomis kalbomis: vokiečių, ispanų, prancūzų, italų, rusų, japonų, korėjiečių ir kinų. Lyginamasis testas apima ketinimų nustatymą, temų klasifikavimą, nuotaikų analizę, natūraliosios kalbos išvadų darymą, perfrazavimo aptikimą, įžeidžios kalbos aptikimą ir gramatinio priimtinumo vertinimą.
Pateikiame vidutinį kiekvienos kalbos užduočių tikslumą, kiekvienai užduočiai suteikdami vienodą svorį. Decider v1.3 lenkia Jev 1.14 visomis aštuoniomis kalbomis, o Decider Flash v1.3 – šešiomis; vidutinis užduočių tikslumas siekia 88,16 % Decider v1.3 ir 86,50 % Decider Flash v1.3, palyginti su 85,41 % Jev 1.14.
NER, PII ir ištraukiamasis atsakymas į klausimus
Funkciją locate vertiname atlikdami 17 užduočių už mokymo sričių ribų, kurios tikrina išgavimą įvairiose srityse, įvesties formatuose (tekstas, lentelės, struktūrizuoti dokumentai) ir pagal įvairias instrukcijas (trumpos žymės, klausimai ir išsamūs aprašymai). Sritys – nuo Vikipedijos iki mokslinių straipsnių, kibernetinių grėsmių ataskaitų, techninės pagalbos, privatumo politikų, gyvenimo aprašymų ir teisinių sutarčių. Užklausos – nuo trumpų žymių pavadinimų, pavyzdžiui, „asmuo“ ar „el. pašto adresas“, per klausimus apie lentelę ar pagalbos užklausą iki išsamių laukų aprašymų struktūrizuotam išgavimui, pavyzdžiui, konfidencialumo sutarties (NDA) šalių ar sąskaitos faktūros bendros sumos.
NER ir PII vertiname naudodami tikslios atkarpos F1, pagal kurį numatytos atkarpos turi tiksliai sutapti su etaloninėmis ribomis. Ekstraktyviajam QA naudojamas simbolių lygmens F1, suteikiantis dalinį įvertinimą už persidengiantį atsakymo tekstą, o struktūrizuotam išgavimui – laukų tikslumas, t. y. teisingai išgautų laukų dalis. Gyvenimo aprašymų (CV) analizei apskaičiuojame NER ir PII tikslios atkarpos F1 balų vidurkį.
Savo modelius lyginame su įvairaus dydžio bendrosios paskirties išgavimo modeliais: GLiNER large v2.5 (0,5B), Liquid d1 (2B) ir Cloudflare Clairic (dydis neatskleistas). Decider v1.3 pasiekia vidutinį 69,0 balo rezultatą (naudojant kiekvienos užduoties pagrindinį rodiklį), o Decider Flash v1.3 – 63,6, palyginti su 43,3 Liquid d1, 41,5 Clairic ir 33,6 GLiNER large v2.5 atveju. Abu Decider modeliai pirmauja visose kategorijose.
Vaizdų klasifikavimas
Decider natūraliai palaiko vaizdo užduotis nuo v1 versijos. Kad įvertintume jo našumą ne tik su tekstu, sudarėme penkių užduočių lyginamųjų testų rinkinį, ypač daug dėmesio skirdami dokumentų klasifikavimui, įskaitant sąskaitas faktūras, laiškus ir gyvenimo aprašymus. Rinkinys taip pat apima palydovinių vaizdų klasifikavimą, tekstūrų klasifikavimą, augintinių veislių klasifikavimą ir gyvūnų skaičiavimą.
Decider v1.3 pasiekia 76,99 % vidutinį tikslumą penkiose vizualinėse užduotyse ir lenkia Jev 1.14 1,47 procentinio punkto. Decider Flash v1.3 pasiekia 72,77 % ir parodo, kad vaizdų klasifikavimo gebėjimai įmanomi ir mažesniame modelyje.
Realios sprendimų užklausos
Atrinkome vieną milijoną užklausų (pašalinę dublikatus ir užmaskavę PII), pateiktų Perplexity Decision API per pirmąsias 18 jo prieinamumo dienų. Kadangi kiekvienoje užklausoje gali būti keli klausimai apie tą pačią būseną, imtį sudaro 2 318 887 atskiri klausimai. Visos užklausos įtrauktos gavus aiškų naudotojų leidimą naudoti jas tyrimams.
Gamybinės užklausos neturi tikrųjų (ground-truth) žymių, todėl etaloniniams atsakymams generuoti naudojame pažangiausius LLM vertintojus ir matuojame, kiek kiekvieno modelio atsakymai su jais sutampa. Užklausas taip pat suskirstome į 10 užduočių kategorijų, įskaitant informacijos išgavimą, srities klasifikavimą, nuotaikų analizę, ketinimų nustatymą ir maršrutizavimą, aktualumo reitingavimą, turinio moderavimą, kokybės ir atitikties peržiūrą, esybių susiejimą, verslo analizę ir kategoriją „Kita“. Šis suskirstymas parodo, kaip našumas skiriasi įvairiais realiais naudojimo atvejais.
Užduočių pasiskirstymas netolygus: informacijos išgavimas sudaro 425 402 klausimus, srities klasifikavimas – 409 564, o nuotaikų analizė – 344 158. Kartu šios trys kategorijos sudaro 50,8 % imties klausimų.
Decider v1.3 pasiekia didžiausią sutapimą su vertintojais – 93,98 %, palyginti su 93,68 % Decider v1.2 ir 93,35 % Jev 1.14 atveju. Decider v1.3 ir Jev 1.14 rezultatai labai panašūs srities klasifikavimo ir nuotaikų analizės užduotyse – skirtumai atitinkamai 0,34 ir 0,07 procentinio punkto. Jev pirmauja 0,69 punkto aktualumo reitingavimo užduotyse, o Decider v1.3 pirmauja 0,93 punkto informacijos išgavimo užduotyse (dažniausia užduotis imtyje) ir 1,21 punkto ketinimų nustatymo ir maršrutizavimo užduotyse.
Toliau pateiktoje diagramoje palyginamos nurodytos to paties vieno milijono gamybinių užklausų vykdymo išlaidos. Kiekvienoje užklausoje gali būti keli klausimai, todėl čia matavimo vienetas yra užklausos, o ne atskiri klausimai.
Patikimumas
Jautrumą žymėms vertinome su 372 klausimais su keliais atsakymų variantais, kiekvienam modeliui pateikdami 4 788 užklausas. Keitėme parinkčių tvarką, iš naujo priskyrėme žymes atsakymų tekstams ir pervadinome žymes, išlaikydami kiekvieno klausimo prasmę, o tada tikrinome, ar pasikeitė modelio semantinis atsakymas. Mažesni atsakymų pasikeitimo rodikliai reiškia didesnį stabilumą.
Taikant kiekvieną transformaciją, Decider v1.3 pakeitė atsakymą tik 0,27 % klausimų, o Jev 1.14 – 2,69–4,84 % klausimų. Taip pat kartojome identiškas įvestis, kad išmatuotume pateikimo kintamumą: Decider v1.3 atsakymai nepasikeitė, o Jev 1.14 atsakymai pasikeitė 1,88 % klausimų.
Kaip naudojame Decider
Decider sukurtas darbo eigoms, kurioms reikia greitų ir struktūrizuotų sprendimų. Šiame skyriuje apžvelgiame, kaip juos panaudoti, kad būtų pasiektas reikšmingas poveikis mūsų darbui. Štai keletas labiausiai išsiskyrusių pavyzdžių.
Savaime tobulėjančios saugumo taisyklės
Savo viduje jau naudojame Decider saugumo politikoms tobulinti.
Mūsų agentų veikla įrašoma, o probleminiam elgesiui nustatyti atliekama taisyklėmis pagrįstų patikrų serija. Taisyklėmis pagrįstas metodas leidžia stebėti agentus realiuoju laiku, pridedant tik nereikšmingą delsą. Ne realiuoju laiku naudojame Decider šių įrašytų agentų žurnalų pavyzdžiams peržiūrėti. Jei probleminis elgesys nebuvo pažymėtas, Decider tikrina, ar mūsų taisyklių rinkinys ko nors nepraleido; o jei buvo sukeltas aliarmas, Decider tikrina, ar jis nebuvo klaidingas. Visi įrašai, kuriuose mūsų taisyklių rinkinys bet kuriuo iš šių atvejų suklysta, siunčiami agentui įvertinti, ir pasiūlomas taisyklių pataisymas, kurį turi patvirtinti mūsų saugumo komandos narys.
Per vieną dieną Decider perskaitė 1 milijardą žetonų iš 7 000 agentų sesijų ir nustatė trūkumus, kurie lėmė 14 taisyklių pataisymų; 6 iš jų buvo patvirtinti ir įdiegti per dvi dienas. Pakartotinai pritaikius savaitės žurnalams, pataisymai 52 % sumažino mūsų dažniausiai suveikiančios taisyklės apimtį, o išplėstos taisyklės aptiko maždaug 40 % daugiau teisėtų veiksmų, kuriuos verta ištirti.
RL bandymų stebėsena
Kai modelius papildomai mokome taikydami skatinamąjį mokymąsi, suvestiniai rodikliai, pavyzdžiui, galutinis atlygis, nepaaiškina, kodėl bandymas (atskiras mėginimas atlikti užduotį) pavyko ar nepavyko. Bandymas gali nepelnytai prarasti atlygį, nes sutriko įrankio paslauga arba Sandbox, arba gauti nepelnytą atlygį, jei vertintojas nepastebi nepagrįsto teiginio, pavyzdžiui, išgalvotos reikšmės, kurios negrąžino joks įrankis.
Naudodami Decider stebime, ar bandymuose pasitaiko šių atvejų. Pirmiausia kodas nustato bandymo dalis, kurias verta patikrinti atidžiau: nepavykusį įrankio iškvietimą ir su juo susijusį protavimą, be klaidų įvykdytą kodą arba galutinį atsakymą. Tada Decider atsako į klausimus su keliais atsakymų variantais apie kiekvieną dalį, pavyzdžiui, kas nepavyko tam tikrame žingsnyje (įrankio paslauga, išorinė svetainė, Sandbox, harness ar paties agento kodas) ir ar agentas teisingai interpretavo rezultatą. Visus klausimus apie konkrečią dalį sujungiame į vieną užklausą ir saugome tikimybes, o ne verdiktą, kad vėliau galėtume koreguoti slenksčius dar kartą nesiųsdami užklausų Decider. Stebėsenos sistema tik stebi ir diagnozuoja: ji niekada nekeičia atlygio ir nesustabdo vykdymo.
Puslapių kokybės filtravimas
Kai nuskaitome tinklalapius, kad juos indeksuotume ir pateiktume naudotojams, daugelis puslapių būna per prastos kokybės, kad būtų kuo nors naudingi. Tai apima apsaugos nuo botų sienas, CAPTCHA ir klaidų puslapius, taip pat tinkamai įkeltus tinklalapius, kuriuose tiesiog nėra jokios naudingos informacijos, pavyzdžiui, šlamštą, SEO užpildą ar vien naršymui skirtus puslapius. Šiuos žemos kokybės puslapius reikia nustatyti ir išfiltruoti iš mūsų indekso.
Naudodami Decider galime įvertinti puslapių kokybę juos nuskaitydami. Per tą patį tiesioginį perėjimą atliekame ir kitas klasifikavimo užduotis, pavyzdžiui, nustatome turinio sritį ir tikslinę auditoriją bei tai, ar jame yra žalingos, neteisėtos ar asmenį identifikuojančios informacijos. Palyginti su LLM vertintoju, Decider yra gerokai greitesnis ir pigesnis.
Be šių vidinių panaudojimo atvejų, Decider tinka ir toliau nurodytoms darbo eigoms.
Vizualiniai klausimai ir atsakymai
Kadangi Decider skaito vaizdus, jis veikia ir kaip vizualinis tikrintojas: peržiūri tinklalapių ar programėlių stiliaus pakeitimus ir nustato klaidas. Prieš išleidžiant pakeitimą, jis gali peržiūrėti puslapių ekrano kopijas ir aptikti nukirptą tekstą, persidengiančius elementus, sugadintą išdėstymą arba pažymėti diagramas, kurių dizainas gali suklaidinti skaitytoją ar pažeisti prekės ženklo gaires.
Naršymas naršyklėje
Agentai gali naudoti Decider smulkiems sprendimams didesnių užduočių viduje. Naršyklės agentas gali kiekviename žingsnyje siųsti ekrano kopiją ir gauti išsamią informaciją apie puslapio būseną bei numatomą kiekvieno galimo veiksmo rezultatą.
Tyrimo užduočių planavimas
Naudotojų klausimų sudėtingumas gali labai skirtis, kaip ir paieškos gylis, reikalingas atsakymui rasti. Decider gali tai įvertinti dar prieš pradedant paiešką, todėl paprastiems klausimams sunaudojama mažiau išteklių.
Darbo pradžia
Decider grąžina tikimybes. Tinkamas sprendimo slenkstis priklauso nuo taikymo srities. Žymių dažnumas ir santykinės klaidingai teigiamų bei klaidingai neigiamų rezultatų kainos skiriasi priklausomai nuo naudojimo atvejo. Todėl raginame naudotojus derinti slenksčius naudojant nedidelį, reprezentatyvų, pažymėtą kūrimo duomenų rinkinį, o ne manyti, kad fiksuota riba vienodai gerai veiks visose užduotyse.
Decider v1.3 rekomenduojame naudoti subtiliems vertinimams, išsamioms vertinimo rubrikoms ir darbo eigoms, kuriose klaidos brangiai kainuoja. Rinkitės Decider Flash v1.3 didelės apimties maršrutizavimui, žymėjimui ir filtravimui, kai pagrindiniai apribojimai yra delsa ir kaina. Įvertinkite abu modelius naudodami reprezentatyvius savo darbo krūvio pavyzdžius, tada pasirinkite modelį, atitinkantį jūsų kokybės, delsos ir biudžeto reikalavimus.
Abu modeliai pagal Apache licenciją prieinami kaip atsisiunčiami svoriai Hugging Face platformoje, per OpenRouter ir Perplexity Decisions API.
Citavimas
@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}
}