Perplexity Decider

Пускаме Decider v1.3 и Decider Flash v1.3 – наследниците на нашите по-ранни модели за вземане на решения: v1, v1.1, v1.2 и Flash v1.2.

Decider Flash v1.3 е по-малък модел, дестилиран от Decider v1.3. И двата модела са достъпни в Hugging Face под лиценз Apache, чрез OpenRouter и чрез Perplexity Decisions API.

Perplexity Decider е вдъхновен от Jev – System One Model на TypeSafe AI. Поддържа бинарна и многокласова класификация с подредени или неподредени етикети и връща вероятности, които приложенията могат да използват, за да класифицират, маршрутизират, класират и оценяват входни данни.

И двата модела v1.3 подобряват представянето и устойчивостта в широк набор от текстови и визуални задачи благодарение на двупосочното внимание, по-добре подбраните данни за обучение и усъвършенстваната рецепта за обучение. Представяме и locate – нова функция, която маркира избраното съдържание при задачи за разпознаване на именувани обекти, идентифициране на лична информация и извличащо отговаряне на въпроси.

В тази публикация обясняваме как обучаваме и оценяваме Decider и споделяме как го използваме вътрешно в Perplexity.

Какво е модел за вземане на решения?

Моделът за вземане на решения е класификатор с общо предназначение. Подавате му вход и набор от въпроси, всеки с възможните си отговори. За всеки въпрос той връща вероятностно разпределение върху отговорите. Поддържа 3 типа въпроси:

• Да / Не: бинарни решения.
• Избираем отговор: персонализирани етикети за множество класове.
• Оценка: подредени нива.

Моделите за вземане на решения поддържат широк набор от задачи за класификация и оценяване:

• Оценяване на резултати: оценка на вярността, качеството и безопасността.
• Маршрутизиране: насочване на заявките към по-малки или по-големи модели според трудността.
• Модериране и сигурност: откриване на вредно съдържание, фишинг и инжектиране на промпт в изходните данни от инструменти.
• Филтриране и тагване: организиране на големи колекции от съдържание.
• Извличане и повторно класиране: оценяване на резултатите от търсенето според релевантността.

Много от тези задачи досега се изпълняваха от генеративни модели като LLM, въпреки че не изискват генериране на свободен текст. Моделите за вземане на решения заемат място между LLM и класификаторите за конкретни задачи. Те връщат вероятности за множество въпроси относно един и същ вход в рамките на едно изчисление напред, като избягват генерирането на отговора токен по токен и споделят изчисленията между въпросите. За разлика от класификаторите за конкретни задачи, те могат да се справят с нови задачи чрез промптове на естествен език – гъвкавост, придобита чрез обучение върху разнообразни задачи в общ формат „въпрос–отговор“.

Обучение

Превръщане на генеративен LLM в модел за вземане на решения

Изграждаме Decider, като адаптираме мощни генеративни LLM като основни модели. За да обясним адаптацията, първо описваме как се представя една заявка. Както е показано по-долу, заявката се състои от споделен контекст (състоянието) и определен брой въпроси. Състоянието се използва повторно от всички въпроси.

Например при даден документ и неговото резюме една заявка може да попита дали резюмето вярно представя документа и дали е предназначено за експерти, или за широка аудитория. След състоянието всеки блок с въпрос съдържа въпрос и възможните отговори, като на всеки е присвоен предварително зададен токен за етикет, например A, B или C. Специален токен <|marker|> указва откъде да се отчете прогнозата на модела. В тази позиция научен линеен изходен слой (глава за решения) преобразува скритото състояние в оценки за вариантите на отговор на въпроса, които след това се превръщат във вероятности.

Уголеми

Инициализираме изходния слой от базовия модел, който обикновено оценява следващия токен спрямо целия речник, и запазваме само редовете, съответстващи на предварително зададените токени за опции, като A, B или C. След това този орязан слой се обучава да преобразува скритото състояние на <|marker|> в оценки за отговорите. Този подход обхваща всички въпроси за класификация, тъй като всички те могат да бъдат формулирани като въпроси с избираем отговор.

За обучението вземаме стотици публични набори от данни, обхващащи разнообразни задачи (анализ на настроения, извод на естествен език, разпознаване на намерения, съпоставяне на обекти, модериране, проверка на факти, рейтинги и др.), и преобразуваме всеки пример в описания по-горе унифициран формат: състояние, един или повече въпроси, техните опции и цел. Целта може да бъде единствената правилна опция, ако разполагаме с еталонни етикети, или вероятностно разпределение върху опциите.

Във v1.3 представяме функцията locate, която извлича текст от състоянието, вместо да избира от предварително зададени опции. Въпросът за locate описва какво да се намери – чрез кратък етикет като „местоположение“ или чрез инструкция като „Извлечи името на града, в който се намира работното място.“ Моделът връща точния съвпадащ текст от състоянието заедно с началната и крайната му позиция в символи. Ако не открие съвпадения, връща празен списък.

Уголеми

Благодарение на споделеното състояние една заявка може да съчетава въпроси за locate, класификация и оценяване за един и същ вход. Например може да попита дали дадена позиция изисква опит на старши ниво и да извлече необходимите умения.

Двупосочно внимание: моделът чете и в двете посоки

Нашите модели започват от мощни предварително обучени генеративни основи (backbones), чието каузално внимание позволява на всеки токен да обръща внимание само на себе си и на предходните токени. Нашите аблационни изследвания показаха, че превръщането на слоевете с пълно внимание в основата в двупосочни подобрява представянето, затова възприемаме този дизайн, за да позволим на всеки токен да включва контекст от целия вход.

Двупосочното внимание поражда още един избор при дизайна: как трябва да взаимодействат състоянието и въпросите? Разгледахме три модела на внимание с различни последици за представянето, стабилността на отговорите и повторното използване на кеша:

• Всичко вижда всичко (v1.2): Състоянието и всички въпроси се обработват заедно с пълно двупосочно внимание. Изчисленията върху състоянието са споделени, но отговорът на един въпрос може да се промени в зависимост от това какво друго е попитано.
• Изолирани въпроси (v1.3): Състоянието обръща внимание на всички въпроси, а всеки въпрос – само на състоянието и на собствените си токени. Въпросите все още могат да си влияят косвено чрез споделеното състояние, но резултатите са по-стабилни.
• Напълно кешируемо: Състоянието насочва вниманието само към себе си, а всеки въпрос – към състоянието и към собствените си токени. Състоянието не зависи от въпросите и може да се използва повторно между заявките, за да се възползва от кеширането на промптове. Не го използваме по подразбиране, защото възможността състоянието да вижда въпросите е много важна за редица задачи, но с малко дообучение моделът може да бъде превключен към този режим.

В крайна сметка избрахме изолираните въпроси заради силното им представяне и стабилност.

Уголеми

Рецепта за обучение

И при двата размера модели обучението протича на три етапа. Първо обучаваме по-големия модел, базиран на Qwen3.8-27B, с крос-ентропия върху големи набори от данни, след което го дестилираме в по-малкия модел Qwen3.5-4B.

Първият етап е обучение с общо предназначение, при което изцяло дообучаваме модела върху мащабни корпуси. В този етап приемаме само данни, които помагат на модела във всички направления и не са специфични за конкретен бенчмарк; затова изключваме всички обучителни дялове на бенчмаркове.

След като този универсален модел бъде обучен, провеждаме втори, по-прецизен етап с помощта на LoRA. Данните в този етап са насочени към конкретни области и задачи. Добавяме данни във втория етап, а не в първия, ако наблюдаваме само тесни подобрения или регресии при други задачи. Използваме LoRA, за да не се отклоним твърде много от универсалния модел и да не рискуваме спад в производителността заради напасването към тези конкретни области. Целта е да подобрим производителността, като запазим общите знания на основния модел. При сливането на LoRA обратно в базовия модел използваме и тегло, за да контролираме отклонението по-прецизно и да даваме предимство на метриките върху отделените данни пред всякакви подобрения в рамките на областта.

Накрая добавяме стъпка, специфична за визуалните задачи. Подобно на втория етап, визуалната стъпка се третира като още една стъпка на фина специализация, като се използва LoRA адаптер, който се слива обратно с базовия модел с определено тегло. Някои визуални способности могат да бъдат за сметка на представянето при текст. Тъй като наблюдаваме много по-голямо използване на моделите за текст, даваме приоритет на текстовите метрики пред визуалните.

За двата текстови етапа използваме усреднените тегла от три обучения, всяко с различно случайно начално число (seed). Установихме, че това подобрява представянето и устойчивостта на обединения модел.

След като получим окончателния голям модел, прилагаме същата триетапна процедура на обучение към по-малкия модел. Тук големият модел играе ролята на учител: предсказаното от него разпределение на изхода замества еталонните етикети, а по-малкият модел се обучава да минимизира KL дивергенцията между своите предсказания и тези на учителя. При едни и същи данни за обучение тази цел на дестилация превъзхожда крос-ентропията. Макар крос-ентропията да се представя по-добре при бенчмаркове със специално предназначени данни за обучение, тя генерализира по-слабо към отделени данни. Предполагаме, че дестилацията пренася по-добре разпределението на изхода на учителя, включително неговата увереност в алтернативите, различни от еталонните, докато крос-ентропията насърчава пренапасване към специфичното за бенчмарка разпределение на данните за обучение. Затова възприемаме цел на дестилация, базирана на KL.

За да ограничим замърсяването между данните за обучение и за тестване, премахваме всички обучителни примери, които биха могли да се припокриват с някоя от използваните от нас оценки. Това е важно, защото някои публични набори от данни за обучение съдържат големи части от определени набори за оценка. Освен това провеждаме обстойни одити за пристрастия и ги отстраняваме, за да сме сигурни, че подобренията ни са надеждни, а не се дължат просто на заучени пристрастия.

Добавяне на възможност за извличане на информация

Функцията locate извлича информация, като например именувани обекти, от текст, без да променя начина, по който моделът отговаря на обикновени заявки. За целта въвеждаме допълнителен етап на обучение: добавяме към Decider нов специален токен <|locate|>, глава за откъси (span head) и LoRA адаптер.

Инициализираме ембединга на <|locate|> от <|marker|>, научен в предходните етапи на обучение. Обучаваме само този нов ембединг, главата за откъси (span head) и LoRA адаптерите, като запазваме оригиналните тегла на основата и главата за решения замразени. Всяко заявено поле получава собствен токен <|locate|>.

Главата за фрагменти използва представянето на <|locate|> заедно с представянията на токените на състоянието, за да оцени къде започват и къде завършват съответстващите фрагменти и кои двойки начало–край си принадлежат. Тя използва и представянето на токена <|locate|>, за да предскаже специфични за всяко поле прагове за тези оценки. Избраните фрагменти се връщат като позиции на символи в оригиналния текст.

Обучаваме главата за фрагменти с адаптирана функция на загуба InfoNCE, която избутва всеки еталонен фрагмент над прага, а прага – над всеки друг фрагмент. Загубата има два члена: първият избутва оценките на правилните фрагменти над прага и над грешните фрагменти. Вторият член избутва прага над оценките на грешните фрагменти. Полетата без отговор получават само втория член, което учи модела да връща празен списък.

Обучаваме върху комбинация от задачи за извличане на откъси, включително разпознаване на именувани обекти, откриване на лични данни (PII) и извличащо отговаряне на въпроси. Варираме описанията на полетата от кратки етикети до подробни инструкции, така че моделът да се научи да следва заявката, вместо да запаметява фиксиран набор от етикети.

Locate учи модела на структурно различна задача и искаме да я добавим, без да губим това, което моделът вече прави добре. Сливането на адаптерите за Locate с основния модел води до известна регресия при заявките за решения. За да ограничим това, изследваме подходи като повече данни за повторение от по-ранните етапи и спомагателни цели, които поддържат изходите на модела при заявки за решения близки до тези на оригиналния модел. Установяваме обаче, че засега сливането все още не е без загуби, затова оставяме адаптерите несляти и ги активираме само за заявки за Locate.

Оценка

Оценяваме Decider v1.3 и Decider Flash v1.3 с външни бенчмаркове от Hugging Face Decision Index, ClaimBench на Vals AI и Artificial Analysis Decision Index.

В тези оценки нашите модели показват силни резултати. Въпреки че класациите включват непублични задачи, те все пак могат да бъдат манипулирани чрез многократно подаване на резултати и итеративна настройка въз основа на обратната връзка от класацията. За да допълним тези класации, оценяваме моделите с вътрешен набор, който съчетава частни производствени задачи с оценки върху отделени данни от публични набори от данни, които не са бенчмаркове. Тези оценки осигуряват допълнителна проверка на генерализацията отвъд публичните бенчмаркове и ни помагат да разграничим по-широките подобрения от подобренията, специфични за познатите набори за оценка.

Вътрешно създадохме набор от над 200 задачи в различни области и от различни типове, като класификация, оценяване, повторно класиране и извличане на обекти. За да оценим честно реалното представяне на Decider, всички оценки се извършват в режим zero-shot, без фино настройване за конкретни задачи, което ни дава ясен сигнал къде да подобрим модела.

Класификация на заявки

В Perplexity използваме система за класификация с множество глави, за да обработваме всяка потребителска заявка. Всяка заявка първо преминава през модел за ембединги, който действа като извличащ признаци компонент. Полученият ембединг след това се подава към няколко отделни класификационни глави, включително бинарни класификатори и класификатори с множество етикети. Например една от главите определя дали потребителската заявка трябва да задейства търсене в мрежата.

В 63 задачи за класификация с референции, независимо преетикетирани от водещ LLM, Decider v1.3 постига средна точност от 91,6%, като надвишава нашите продукционни класификатори с 6,54 процентни пункта. Decider Flash v1.3 също превъзхожда продукционния базов модел, а Decider v1.3 превъзхожда Jev 1.14.

Уголеми

Класификация в специализирани области

Съставихме специализиран набор за оценка от публични набори от данни, за да оценим представянето на моделите за вземане на решения при класификация в седем области: проверка на твърдения (6 задачи), здравеопазване (7), киберсигурност (8), програмиране (16), държавно управление (7), право (9) и финанси (9).

Например „оцени времевата сложност на програма на Python“ или „използвай годишен финансов отчет, за да определиш дали неограничените парични средства на дадена компания покриват главницата по дълга, дължима през следващите дванадесет месеца“. Decider v1.3 води във всичките седем области, като превъзхожда Jev 1.14 с до 12,9 процентни пункта във финансите и с 9,3 пункта в правото. Decider Flash v1.3 изостава от Jev 1.14 във финансите, програмирането и правото и се представя сходно в останалите области.

Уголеми

Извличане и повторно класиране

Търсенето е в основата на Perplexity. Поддържаме широк набор от задачи за извличане, за да оценяваме представянето на нашите модели при повторно класиране. За всяка задача първо използваме набор от модели за ембединги, за да извлечем 50-те най-подходящи кандидат-документа от всеки корпус. След това класираме повторно тези кандидати с Decider и сравняваме представянето му със силен базов модел за повторно класиране – Qwen3-Reranker-8B.

Оценяваме Decider в режим zero-shot с поточково (pointwise) оценяване, като използваме модела, за да оцени директно и независимо всяка двойка заявка–документ и да класира документите по релевантност. В 72 задачи за извличане Decider v1.3 постига средна стойност на nDCG@10 от 83,99, като превъзхожда Qwen3-Reranker-8B с 1,81 пункта и Jev 1.14 с 2,24 пункта.

В бенчмарка BEIR двата модела превъзхождат Qwen3-Reranker-8B съответно с 8,78 и 7,05 nDCG@10. Спрямо Jev 1.14 Decider v1.3 е с 1,33 пункта по-високо, докато версията Flash постига с 0,4 по-нисък резултат.

Уголеми

Многоезична класификация

За да оценим моделите за вземане на решения отвъд английския език, съставихме многоезичен бенчмарк за класификация, включващ 19 езиково специфични задачи от 8 публични набора от данни, с 46 484 примера на осем езика: немски, испански, френски, италиански, руски, японски, корейски и китайски. Бенчмаркът обхваща разпознаване на намерения, класификация по теми, анализ на настроения, извод на естествен език, разпознаване на перифрази, разпознаване на обиден език и граматична приемливост.

Отчитаме средната точност за задачите във всеки език, като всяка задача има еднаква тежест. Decider v1.3 превъзхожда Jev 1.14 и на осемте езика, а Decider Flash v1.3 – на шест, със средна точност по задачи от 88,16% за Decider v1.3 и 86,50% за Decider Flash v1.3 в сравнение с 85,41% за Jev 1.14.

Уголеми

NER, PII и извличащо отговаряне на въпроси

Оценяваме функцията locate върху 17 задачи извън домейна на обучение, които тестват извличането в различни области, входни формати (текст, таблици, структурирани документи) и инструкции (кратки етикети, въпроси и подробни описания). Областите варират от Wikipedia до научни статии, доклади за киберзаплахи, техническа поддръжка, политики за поверителност, автобиографии и правни договори. Заявките варират от кратки имена на етикети като „лице“ или „имейл адрес“, през въпроси за таблица или заявка за поддръжка, до подробни описания на полета за структурирано извличане, като например страните по NDA или общата сума във фактура.

Оценяваме NER и PII с F1 за точни фрагменти, което изисква предсказаните фрагменти да съвпадат точно с референтните граници. При извличащите въпроси и отговори използваме F1 на ниво символи, който частично зачита припокриващия се текст на отговора, а при структурираното извличане – точност по полета, т.е. дела на правилно извлечените полета. За анализа на автобиографии осредняваме резултатите F1 за точни фрагменти при NER и PII.

Сравняваме нашите модели с модели за извличане с общо предназначение с различни размери: GLiNER large v2.5 (0,5B), Liquid d1 (2B) и Clairic на Cloudflare (неоповестен размер). Decider v1.3 достига среден резултат от 69,0 (по основната метрика на всяка задача), а Decider Flash v1.3 – 63,6, в сравнение с 43,3 за Liquid d1, 41,5 за Clairic и 33,6 за GLiNER large v2.5. И двата модела Decider водят във всяка категория.

Уголеми

Класификация на изображения

Decider поддържа нативно визуални задачи още от v1. За да оценим представянето му отвъд текста, съставихме бенчмарк набор от пет задачи с особен фокус върху класификацията на документи, включително фактури, писма и автобиографии. Наборът обхваща също класификация на сателитни изображения, класификация на текстури, класификация на породи домашни любимци и преброяване на животни.

Decider v1.3 постига средна точност от 76,99% в петте визуални задачи, като превъзхожда Jev 1.14 с 1,47 процентни пункта. Decider Flash v1.3 постига 72,77%, което демонстрира възможности за визуална класификация в по-малък модел.

Уголеми

Реални заявки за решения

Взехме извадка от един милион заявки без дубликати и с маскирани лични данни (PII), подадени към Perplexity Decision API през първите 18 дни от наличността му. Тъй като всяка заявка може да съдържа няколко въпроса за едно и също състояние, извадката включва 2 318 887 отделни въпроса. Всички заявки са включени с изрично разрешение на потребителите за изследователски цели.

Заявките от продукционна среда не идват с еталонни етикети, затова използваме водещи LLM модели като съдии, за да генерираме референтни отговори и да измерим съгласието на всеки модел с тях. Групираме заявките и в 10 категории задачи, включително извличане на информация, класификация по област, анализ на настроения, намерение и маршрутизиране, класиране по релевантност, модериране на съдържание, преглед на качество и съответствие, съпоставяне на обекти, бизнес анализ и категория „Други“. Тази разбивка показва как представянето варира при различните реални случаи на употреба.

Разпределението на задачите е неравномерно: извличането на информация обхваща 425 402 въпроса, класификацията по област – 409 564, а анализът на настроения – 344 158. Заедно тези три категории съставляват 50,8% от въпросите в извадката.

Decider v1.3 постига най-високо съгласие със съдиите – 93,98%, в сравнение с 93,68% за Decider v1.2 и 93,35% за Jev 1.14. Decider v1.3 и Jev 1.14 са почти равни при класификацията по област и анализа на настроения, с разлики съответно от 0,34 и 0,07 процентни пункта. Jev води с 0,69 пункта при класирането по релевантност, докато Decider v1.3 води с 0,93 пункта при извличането на информация (най-честата задача в извадката) и с 1,21 пункта при намерението и маршрутизирането.

Уголеми

Графиката по-долу сравнява отчетените разходи за изпълнение на едни и същи един милион продукционни заявки. Всяка заявка може да съдържа няколко въпроса, така че единицата тук са заявките, а не отделните въпроси.

Уголеми

Устойчивост

Оценихме чувствителността към етикетите върху 372 въпроса с избираем отговор, като направихме по 4788 заявки за всеки модел. Разместихме опциите, преназначихме етикетите към текстовете на отговорите и преименувахме етикетите, като запазихме смисъла на всеки въпрос, след което проверихме дали семантичният отговор на модела се променя. По-ниската честота на промяна на отговора означава по-голяма стабилност.

Decider v1.3 промени отговора си само при 0,27% от въпросите при всяка трансформация, в сравнение с 2,69–4,84% за Jev 1.14. Повторихме и идентични входни данни, за да измерим вариативността при обслужване: Decider v1.3 не показа промени, докато Jev 1.14 се промени при 1,88% от въпросите.

Уголеми

Как използваме Decider

Decider е създаден за работни процеси, които изискват бързи и структурирани решения. В този раздел разглеждаме как да ги използваме, за да постигнем значимо въздействие върху начина, по който работим. Ето някои, които се откроиха.

Самоусъвършенстващи се правила за сигурност

Вътрешно вече използваме Decider, за да подобряваме политиките си за сигурност.

Активността на нашите агенти се записва и се извършват поредица от проверки, базирани на правила, за да се открие проблемно поведение. Подходът, базиран на правила, ни позволява да наблюдаваме агентите си в реално време с пренебрежимо малко допълнително забавяне. Офлайн използваме Decider, за да преглеждаме извадки от тези записани логове на агентите. Ако не е отбелязано проблемно поведение, Decider проверява дали нещо не е убегнало на нашия набор от правила; а ако е подаден сигнал за тревога, Decider проверява дали тя не е фалшива. Всички записи, при които наборът ни от правила се проваля в един от двата случая, се изпращат на агент за триаж и се предлага корекция на правилата, която трябва да бъде одобрена от член на нашия екип по сигурността.

За един ден Decider прочете 1 милиард токена в 7000 сесии на агенти и откри недостатъци, довели до 14 корекции на правила, 6 от които бяха одобрени и внедрени в рамките на два дни. При повторно прилагане върху логове от една седмица корекциите намалиха обема на най-натоварваното ни правило с 52%, а разширените правила уловиха около 40% повече легитимни действия за проучване.

Уголеми

Мониторинг на RL rollout-и

Когато дообучаваме модели (post-training) с обучение с подсилване, обобщените метрики, като крайната награда, не обясняват защо даден rollout (отделен опит за изпълнение на задача) е успял или се е провалил. Той може несправедливо да загуби награда, защото услуга за инструменти или sandbox са се провалили, или да получи незаслужена награда, ако оценителят пропусне необосновано твърдение, като например измислена стойност, която нито един инструмент не е върнал.

Използваме Decider, за да наблюдаваме rollout-ите в тези случаи. Първо кодът идентифицира частите от rollout-а, които заслужават по-внимателна проверка: неуспешно извикване на инструмент и съпътстващите го разсъждения, код, който се е изпълнил без грешки, или крайния отговор. След това Decider отговаря на въпроси с избор между няколко отговора за всяка част, например какво се е провалило в дадена стъпка (услуга за инструменти, външен сайт, sandbox, harness или собственият код на агента) и дали агентът е интерпретирал резултата правилно. Обединяваме всички въпроси за дадена част в една заявка и съхраняваме вероятностите вместо вердикт, така че да можем да коригираме праговете по-късно, без да изпращаме отново заявки към Decider. Мониторът само наблюдава и диагностицира: никога не променя наградата и не спира изпълнението.

Уголеми

Филтриране по качество на страниците

При обхождането на уеб страници за индексиране и предоставяне на потребителите много страници са с твърде ниско качество, за да бъдат от полза. Това включва защити срещу ботове, CAPTCHA и страници за грешки, както и правилно заредени уеб страници, които просто не съдържат полезна информация, като спам, SEO пълнеж или страници само с навигация. Тези нискокачествени страници трябва да бъдат идентифицирани и филтрирани от нашия индекс.

С помощта на Decider можем да оценяваме качеството на страниците още докато ги обхождаме. В рамките на същото изчисление напред изпълняваме и редица други класификационни задачи, например определяне на тематичната област и целевата аудитория на съдържанието, както и дали то съдържа вредна, незаконна или лична информация, позволяваща идентифициране. В сравнение с използването на LLM като оценител Decider е значително по-бърз и по-евтин.

Уголеми

Освен за тези вътрешни цели, Decider е подходящ и за работни процеси като следните.

Визуални въпроси и отговори

Тъй като Decider чете изображения, той работи и като визуален проверяващ – преглежда промени в стила на уеб страници или приложения и открива дефекти. Може да преглежда екранни снимки на страници за отрязан текст, припокриващи се елементи и счупени оформления, преди дадена промяна да бъде пусната, или да отбелязва графики, чийто дизайн може да подведе читателя или да наруши ръководството за марката.

Уголеми

Навигация в браузъра

Агентите могат да използват Decider за малките решения в рамките на по-големи задачи. Браузърен агент може да изпраща екранна снимка на всяка стъпка и да получава подробна информация за състоянието на страницата и очаквания резултат от всяко възможно действие.

Уголеми

Планиране на задачи за проучване

Въпросите на потребителите могат да се различават значително по сложност, както и по дълбочината на търсенето, необходимо за намиране на отговор. Decider може да оцени това още преди началото на търсенето, което позволява да се изразходват по-малко ресурси за простите въпроси.

Уголеми

Първи стъпки

Decider връща вероятности. Подходящият праг за решение зависи от приложението. Честотата на етикетите и относителната цена на фалшиво положителните и фалшиво отрицателните резултати варират в различните случаи на употреба. Затова препоръчваме на потребителите да настройват праговете върху малък, представителен, етикетиран набор за разработка, вместо да приемат, че фиксиран праг ще работи еднакво добре за всички задачи.

Препоръчваме Decider v1.3 за нюансирани преценки, подробни критерии за оценяване и работни процеси, при които грешките струват скъпо. Изберете Decider Flash v1.3 за маршрутизиране, етикетиране и филтриране в голям обем, когато латентността и цената са основните ограничения. Оценете и двата модела с представителни примери от вашето работно натоварване, след което изберете модела, който отговаря на изискванията ви за качество, латентност и бюджет.

И двата модела са достъпни като тегла за изтегляне в Hugging Face под лиценз Apache, чрез OpenRouter и чрез Perplexity Decisions API.

Цитиране

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