Perplexity Decider

Як ми її навчаємо, оцінюємо та використовуємо.

АвториPerplexity Research

Ми випускаємо 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, класифікації та оцінювання щодо тих самих вхідних даних. Наприклад, він може запитати, чи потребує вакансія досвіду старшого рівня, і видобути необхідні навички.

Двонаправлена увага: модель читає в обох напрямках

Наші моделі починаються з потужних попередньо навчених генеративних базових моделей, чия каузальна увага дозволяє кожному токену звертати увагу лише на себе та попередні токени. Наші абляційні дослідження показали, що перетворення шарів повної уваги базової моделі на двонаправлені покращує продуктивність, тож ми застосовуємо цей підхід, щоб кожен токен міг враховувати контекст усіх вхідних даних.

Двонаправлена увага ставить перед нами ще один вибір дизайну: як мають взаємодіяти стан і запитання? Ми розглянули три шаблони уваги з різними наслідками для продуктивності, стабільності відповідей і повторного використання кешу:

  • Усе бачить усе (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|>, навченого на попередніх етапах тренування. Ми навчаємо лише цей новий ембединг, голову спанів та адаптери LoRA, залишаючи вихідні ваги базової моделі та голову рішень замороженими. Кожне запитуване поле отримує власний токен <|locate|>.

Голова виділення фрагментів використовує представлення <|locate|> разом із представленнями токенів стану, щоб оцінювати, де починаються й закінчуються відповідні фрагменти та які пари початку й кінця пов’язані між собою. Вона також використовує представлення токена <|locate|>, щоб прогнозувати пороги для цих оцінок, специфічні для кожного поля. Вибрані фрагменти повертаються як позиції символів в оригінальному тексті.

Ми навчаємо голову виділення фрагментів за допомогою адаптованої функції втрат InfoNCE, яка підносить оцінку кожного еталонного фрагмента вище за поріг, а поріг — вище за оцінки всіх інших фрагментів. Функція втрат має два доданки: перший підносить оцінки правильних фрагментів вище за поріг і за оцінки хибних фрагментів. Другий доданок підносить поріг вище за оцінки хибних фрагментів. Для полів без відповіді застосовується лише другий доданок, що навчає модель повертати порожній список.

Ми навчаємо модель на суміші завдань видобування спанів, зокрема розпізнавання іменованих сутностей, виявлення PII та екстрактивних відповідей на запитання. Ми варіюємо описи полів від коротких міток до детальних інструкцій, щоб модель навчилася виконувати запит, а не запам’ятовувати фіксований набір міток.

Locate навчає модель структурно іншого завдання, і ми хочемо додати його, не втрачаючи того, що модель уже робить добре. Злиття адаптерів locate з базовою моделлю спричиняє певну регресію на запитах ухвалення рішень. Щоб обмежити її, ми проводимо дослідження, як-от використання більшого обсягу даних повторного відтворення (replay) з попередніх етапів і допоміжних цільових функцій, які утримують виходи моделі на запитах ухвалення рішень близькими до виходів початкової моделі. Однак ми з’ясували, що наразі злиття все ще не відбувається без втрат, тож ми залишаємо адаптери незлитими й активуємо їх лише для запитів 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 у поточковому (pointwise) режимі zero-shot, використовуючи модель для безпосереднього й незалежного оцінювання кожної пари «запит–документ» і ранжування документів за релевантністю. У 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 позадоменних завданнях, які перевіряють видобування в різних доменах, форматах вхідних даних (текст, таблиці, структуровані документи) та інструкціях (короткі мітки, запитання та детальні описи). Домени охоплюють усе — від Вікіпедії до наукових статей, звітів про кіберзагрози, технічної підтримки, політик конфіденційності, резюме та юридичних договорів. Запити варіюються від коротких назв міток, як-от «особа» чи «адреса електронної пошти», через запитання про таблицю чи звернення до служби підтримки, до детальних описів полів для структурованого видобування, як-от сторони NDA чи загальна сума в рахунку-фактурі.

Ми оцінюємо NER і PII за метрикою F1 з точним збігом фрагментів, яка вимагає, щоб межі передбачених фрагментів точно збігалися з еталонними. Для екстрактивних питань-відповідей (QA) використовується 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 пункту в намірах і маршрутизації.

На діаграмі нижче порівнюється заявлена вартість обробки того самого мільйона продакшн-запитів. Кожен запит може містити кілька запитань, тому одиницею тут є запити, а не окремі запитання.

Decider працював локально; GLM і DeepSeek використовували llm-api; Jev — OpenRouter. Наведені витрати залежать від конкретного робочого навантаження; облік вартості локального обладнання не уточнено, а порівняння за зіставної затримки не проводилося.

Стійкість

Ми оцінили чутливість до міток на 372 запитаннях із вибором відповіді, надіславши 4 788 запитів для кожної моделі. Ми змінювали порядок варіантів, перепризначали мітки текстам відповідей і перейменовували мітки, зберігаючи зміст кожного запитання, а потім перевіряли, чи змінилася семантична відповідь моделі. Нижча частота зміни відповідей означає більшу стабільність.

Decider v1.3 змінював відповідь лише на 0,27 % запитань за кожного перетворення, тоді як Jev 1.14 — на 2,69–4,84 %. Ми також повторювали ідентичні вхідні дані, щоб виміряти варіативність обслуговування: у Decider v1.3 змін не було, тоді як Jev 1.14 змінював відповідь на 1,88 % запитань.

Як ми використовуємо Decider

Decider створено для робочих процесів, яким потрібні швидкі та структуровані рішення. У цьому розділі ми розглядаємо, як застосовувати їх, щоб суттєво вплинути на те, як ми працюємо. Ось кілька прикладів, що вирізнилися.

Правила безпеки, що самовдосконалюються

Усередині компанії ми вже використовуємо Decider, щоб удосконалювати наші політики безпеки.

Активність наших агентів записується, і виконується низка перевірок на основі правил, щоб виявити будь-яку проблемну поведінку. Підхід на основі правил дає змогу відстежувати агентів у реальному часі з незначною додатковою затримкою. В офлайн-режимі ми використовуємо Decider для аналізу вибірок із цих записаних журналів агентів. Якщо жодної проблемної поведінки не позначено, Decider перевіряє, чи не пропустив чогось наш набір правил; а якщо було піднято тривогу, Decider перевіряє, чи не була вона хибною. Усі записи, на яких наш набір правил дає збій у будь-якому з цих випадків, надсилаються агенту для тріажу, і пропонується виправлення правил, яке має затвердити співробітник нашої команди безпеки.

За один день Decider прочитав 1 мільярд токенів у 7 000 сеансах агентів і виявив недоліки, що привели до 14 виправлень правил, 6 з яких було затверджено й випущено протягом двох днів. Під час повторного прогону на журналах за тиждень виправлення скоротили обсяг спрацювань нашого найнавантаженішого правила на 52 %, а розширені правила виявили приблизно на 40 % більше легітимних дій для розслідування.

Моніторинг прогонів RL

Коли ми проводимо пост-навчання моделей за допомогою навчання з підкріпленням, агреговані метрики, як-от фінальна винагорода, не пояснюють, чому прогін (окрема спроба виконати завдання) був успішним чи невдалим. Він може несправедливо втратити винагороду через збій сервісу інструментів або пісочниці чи отримати незаслужену винагороду, якщо оцінювач не помітив необґрунтованого твердження, наприклад вигаданого значення, якого не повертав жоден інструмент.

Ми використовуємо Decider для моніторингу прогонів у таких випадках. Спочатку код визначає частини прогону, які заслуговують на ретельнішу перевірку: невдалий виклик інструмента й міркування навколо нього, код, що виконався без помилок, або фінальну відповідь. Потім Decider відповідає на запитання з вибором відповіді щодо кожної частини, наприклад, що саме дало збій на кроці (сервіс інструментів, зовнішній сайт, пісочниця, 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.

Цитування

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