Perplexity Decider

Udostępniamy Decider v1.3 i Decider Flash v1.3 — następców naszych wcześniejszych modeli decyzyjnych: v1, v1.1, v1.2 i Flash v1.2.

Decider Flash v1.3 to mniejszy model destylowany z modelu Decider v1.3. Oba modele są dostępne w serwisie Hugging Face na licencji Apache, przez OpenRouter oraz w Perplexity Decisions API.

Perplexity Decider jest inspirowany modelem Jev — System One Model firmy TypeSafe AI. Obsługuje klasyfikację binarną i wieloklasową z etykietami uporządkowanymi lub nieuporządkowanymi, zwracając prawdopodobieństwa, które aplikacje mogą wykorzystywać do klasyfikowania, kierowania, rangowania i oceniania danych wejściowych.

Oba modele v1.3 poprawiają wydajność i odporność w szerokim zakresie zadań tekstowych i wizualnych dzięki dwukierunkowej uwadze, lepiej dobranym danym treningowym i dopracowanej recepturze treningu. Wprowadzamy też locate — nową funkcję wskazującą wybrane fragmenty treści w zadaniach rozpoznawania nazwanych encji, identyfikacji danych osobowych i ekstrakcyjnego odpowiadania na pytania.

W tym wpisie wyjaśniamy, jak trenujemy i ewaluujemy model Decider, oraz pokazujemy, jak używamy go wewnętrznie w Perplexity.

Czym jest model decyzyjny?

Model decyzyjny to klasyfikator ogólnego przeznaczenia. Podajesz mu dane wejściowe i zestaw pytań, z których każde ma możliwe odpowiedzi. Dla każdego pytania zwraca rozkład prawdopodobieństwa na odpowiedziach. Obsługuje 3 typy pytań:

• Tak / Nie: decyzje binarne.
• Wielokrotny wybór: niestandardowe etykiety wieloklasowe.
• Ocena: uporządkowane poziomy.

Modele decyzyjne obsługują szeroki zakres zadań klasyfikacji i oceniania:

• Ocena wygenerowanych odpowiedzi: sprawdzanie wierności, jakości i bezpieczeństwa.
• Routing: kierowanie zapytań do mniejszych lub większych modeli w zależności od stopnia trudności.
• Moderacja i bezpieczeństwo: wykrywanie szkodliwych treści, phishingu i wstrzykiwania promptów w wynikach narzędzi.
• Filtrowanie i tagowanie: porządkowanie dużych zbiorów treści.
• Wyszukiwanie i ponowne rangowanie: ocenianie wyników wyszukiwania pod kątem trafności.

Wiele z tych zadań było wcześniej obsługiwanych przez modele generatywne, takie jak LLM, mimo że nie wymagają one generowania swobodnego tekstu. Modele decyzyjne plasują się pomiędzy LLM a klasyfikatorami przeznaczonymi do konkretnych zadań. Zwracają prawdopodobieństwa dla wielu pytań dotyczących tych samych danych wejściowych w jednym przebiegu w przód, co pozwala uniknąć generowania odpowiedzi token po tokenie i współdzielić obliczenia między pytaniami. W przeciwieństwie do klasyfikatorów przeznaczonych do konkretnych zadań potrafią obsługiwać nowe zadania na podstawie promptów w języku naturalnym – tę elastyczność zawdzięczają treningowi na zróżnicowanych zadaniach we wspólnym formacie pytań i odpowiedzi.

Trening

Przekształcanie generatywnego LLM w model decyzyjny

Model Decider budujemy, adaptując wydajne generatywne modele LLM jako modele szkieletowe. Aby wyjaśnić tę adaptację, najpierw opiszemy, jak reprezentowane jest żądanie. Jak pokazano poniżej, żądanie składa się ze wspólnego kontekstu (stanu) i pewnej liczby pytań. Stan będzie ponownie wykorzystywany przez wszystkie pytania.

Na przykład, mając dokument i jego streszczenie, jedno zapytanie może zapytać, czy streszczenie wiernie oddaje dokument i czy jest przeznaczone dla eksperta, czy dla szerokiego grona odbiorców. Po stanie każdy blok pytania zawiera pytanie i możliwe odpowiedzi, z których każdej przypisano predefiniowany token etykiety, np. A, B lub C. Specjalny token <|marker|> wskazuje, gdzie odczytać predykcję modelu. W tej pozycji wyuczona liniowa warstwa wyjściowa (głowica decyzyjna) mapuje stan ukryty na wyniki dla opcji odpowiedzi na pytanie, które są następnie przekształcane w prawdopodobieństwa.

Powiększ

Warstwę wyjściową inicjalizujemy na podstawie modelu bazowego, który zwykle ocenia następny token w obrębie całego słownika, i zachowujemy tylko wiersze odpowiadające predefiniowanym tokenom opcji, np. A, B lub C. Tak przycięta warstwa jest następnie trenowana, aby przekształcać stan ukryty tokenu <|marker|> w wyniki odpowiedzi. To podejście obejmuje wszystkie pytania klasyfikacyjne, ponieważ każde z nich można sformułować jako pytanie wielokrotnego wyboru.

Do treningu bierzemy setki publicznych zbiorów danych obejmujących różnorodne zadania (sentyment, wnioskowanie w języku naturalnym, wykrywanie intencji, dopasowywanie encji, moderacja, weryfikacja faktów, oceny itp.) i przekształcamy każdy przykład do opisanego wyżej ujednoliconego formatu: stan, jedno lub więcej pytań, ich opcje i cel. Celem może być pojedyncza poprawna opcja, jeśli mamy etykiety wzorcowe, lub rozkład prawdopodobieństwa na opcjach.

W wersji v1.3 wprowadzamy locate — funkcję, która wyodrębnia tekst ze stanu zamiast wybierać spośród predefiniowanych opcji. Pytanie locate opisuje, co należy znaleźć, za pomocą krótkiej etykiety, np. „lokalizacja”, lub instrukcji, np. „Wyodrębnij nazwę miasta, w którym znajduje się miejsce pracy”. Model zwraca dokładnie pasujący tekst ze stanu wraz z pozycjami jego początkowego i końcowego znaku. Jeśli nie znajdzie żadnych dopasowań, zwraca pustą listę.

Powiększ

Dzięki współdzielonemu stanowi jedno zapytanie może łączyć pytania typu locate, klasyfikacyjne i oceniające dotyczące tych samych danych wejściowych. Może na przykład zapytać, czy oferta pracy wymaga doświadczenia na poziomie seniora, i wyodrębnić wymagane umiejętności.

Dwukierunkowa uwaga: pozwalamy modelowi czytać w obu kierunkach

Nasze modele wychodzą od silnych, wstępnie wytrenowanych generatywnych modeli bazowych (backbone), których przyczynowa uwaga pozwala każdemu tokenowi uwzględniać wyłącznie siebie i tokeny poprzedzające. Nasze badania ablacyjne wykazały, że uczynienie warstw pełnej uwagi w modelu bazowym dwukierunkowymi poprawia wydajność, dlatego przyjmujemy tę konstrukcję, aby każdy token mógł uwzględniać kontekst z całego wejścia.

Dwukierunkowa uwaga wymaga podjęcia kolejnej decyzji projektowej: jak stan i pytania powinny ze sobą oddziaływać? Rozważyliśmy trzy wzorce uwagi o różnych konsekwencjach dla wydajności, stabilności odpowiedzi i ponownego wykorzystania pamięci podręcznej:

• Wszystko widzi wszystko (v1.2): Stan i wszystkie pytania są przetwarzane razem z pełną dwukierunkową uwagą. Obliczenia na stanie są współdzielone, ale odpowiedź na jedno pytanie może się zmienić w zależności od tego, o co jeszcze zapytano.
• Izolowane pytania (v1.3): Stan zwraca uwagę na wszystkie pytania, a każde pytanie — tylko na stan i własne tokeny. Pytania mogą nadal wpływać na siebie pośrednio przez współdzielony stan, ale wyniki są bardziej stabilne.
• Pełna buforowalność: Stan stosuje mechanizm uwagi wyłącznie do samego siebie, a każde pytanie – do stanu i własnych tokenów. Stan jest niezależny od pytań i można go ponownie wykorzystywać w wielu żądaniach, co pozwala korzystać z buforowania promptów. Domyślnie nie stosujemy tego trybu, ponieważ to, że stan widzi pytania, ma duże znaczenie w przypadku kilku zadań, ale niewielkie dostrajanie pozwala przełączyć na niego model.

Ostatecznie wybraliśmy izolowane pytania ze względu na ich wysoką wydajność i stabilność.

Powiększ

Receptura treningu

W przypadku obu rozmiarów modelu trening przebiega w trzech etapach. Najpierw trenujemy większy model, oparty na Qwen3.8-27B, z użyciem entropii krzyżowej na dużych zbiorach danych, a następnie destylujemy go do mniejszego modelu Qwen3.5-4B.

Pierwszym etapem jest trening ogólny, w którym w pełni dostrajamy model na dużych korpusach. Na tym etapie akceptujemy wyłącznie dane, które pomagają modelowi we wszystkich obszarach i nie są specyficzne dla żadnego benchmarku; wykluczamy więc wszelkie treningowe podziały benchmarków.

Po wytrenowaniu tego modelu ogólnego przeprowadzamy drugi, bardziej szczegółowy etap z użyciem LoRA. Dane używane na tym etapie są ukierunkowane na konkretne domeny i zadania. Dane dodajemy na drugim etapie zamiast na pierwszym, jeśli obserwujemy wąskie zyski lub regresje w innych zadaniach. Używamy LoRA, aby nie oddalić się zbytnio od modelu ogólnego i nie ryzykować utraty wydajności w wyniku dopasowania do tych konkretnych domen. Celem jest poprawa wydajności przy zachowaniu ogólnej wiedzy modelu szkieletowego. Podczas scalania LoRA z powrotem z modelem bazowym stosujemy również wagę, aby precyzyjniej kontrolować dryf i przedkładać metryki na danych odłożonych nad wszelkie zyski w obrębie domeny.

Na koniec dodajemy etap specyficzny dla wizji. Podobnie jak drugi etap, etap wizyjny jest traktowany jako kolejny etap precyzyjnej specjalizacji z użyciem adaptera LoRA, który jest następnie scalany z modelem bazowym z określoną wagą. Niektóre możliwości wizyjne mogą odbywać się kosztem wydajności na tekście. Ponieważ obserwujemy znacznie większe wykorzystanie modeli do zadań tekstowych, przedkładamy metryki tekstowe nad wizyjne.

W obu etapach tekstowych używamy uśrednionych wag z trzech przebiegów, z których każdy korzysta z innego ziarna losowego. Stwierdziliśmy, że poprawia to wydajność i odporność zagregowanego modelu.

Po uzyskaniu ostatecznego dużego modelu stosujemy tę samą trzyetapową procedurę treningu do mniejszego modelu. Tutaj duży model pełni rolę nauczyciela: przewidywany przez niego rozkład wyjściowy zastępuje etykiety referencyjne, a mniejszy model jest trenowany tak, aby minimalizować dywergencję KL między swoimi predykcjami a predykcjami nauczyciela. Ten cel destylacji daje lepsze wyniki niż entropia krzyżowa na tych samych danych treningowych. Choć entropia krzyżowa sprawdza się lepiej na benchmarkach z dedykowanymi danymi treningowymi, gorzej generalizuje na dane odłożone. Stawiamy hipotezę, że destylacja lepiej przenosi rozkład wyjściowy nauczyciela, w tym jego pewność co do alternatyw innych niż referencyjne, podczas gdy entropia krzyżowa sprzyja nadmiernemu dopasowaniu do rozkładu treningowego specyficznego dla danego benchmarku. Dlatego przyjmujemy cel destylacji oparty na dywergencji KL.

Aby ograniczyć kontaminację danych treningowych danymi testowymi, usuwamy wszystkie próbki treningowe, które mogłyby pokrywać się z którąkolwiek z używanych przez nas ewaluacji. Jest to ważne, ponieważ niektóre publiczne zbiory danych treningowych zawierają duże części niektórych zbiorów ewaluacyjnych. Przeprowadzamy również szeroko zakrojone audyty pod kątem błędów systematycznych i je eliminujemy, aby mieć pewność, że nasze zyski są wiarygodne, a nie wynikają jedynie z wyuczonych błędów systematycznych.

Dodawanie możliwości wyodrębniania informacji

Funkcja locate wyodrębnia z tekstu informacje, takie jak nazwane encje, bez zmiany sposobu odpowiadania na zwykłe zapytania. W tym celu wprowadzamy dodatkowy etap treningu: dodajemy do modelu Decider nowy token specjalny <|locate|>, głowicę zakresów (span head) oraz adapter LoRA.

Inicjalizujemy embedding tokenu <|locate|> na podstawie tokenu <|marker|> wyuczonego w poprzednich etapach treningu. Trenujemy tylko ten nowy embedding, głowicę zakresów i adaptery LoRA, zachowując zamrożone oryginalne wagi modelu bazowego i głowicę decyzyjną. Każde żądane pole otrzymuje własny token <|locate|>.

Głowica fragmentów wykorzystuje reprezentację tokenu <|locate|> wraz z reprezentacjami tokenów stanu, aby ocenić, gdzie zaczynają się i kończą pasujące fragmenty oraz które pary początek–koniec do siebie należą. Wykorzystuje też reprezentację tokenu <|locate|> do przewidywania progów tych wyników dla poszczególnych pól. Wybrane fragmenty są zwracane jako pozycje znaków w oryginalnym tekście.

Głowicę fragmentów trenujemy za pomocą zaadaptowanej funkcji straty InfoNCE, która przesuwa każdy referencyjny fragment powyżej progu, a próg – powyżej każdego innego fragmentu. Funkcja straty ma dwa składniki: pierwszy przesuwa wyniki poprawnych fragmentów powyżej progu i błędnych fragmentów. Drugi składnik przesuwa próg powyżej wyników błędnych fragmentów. Pola bez odpowiedzi otrzymują tylko drugi składnik, który uczy model zwracania pustej listy.

Trenujemy na zestawie zadań ekstrakcji fragmentów tekstu, w tym rozpoznawania nazwanych encji, wykrywania danych PII i ekstrakcyjnego odpowiadania na pytania. Opisy pól różnicujemy od krótkich etykiet po szczegółowe instrukcje, aby model uczył się wykonywać polecenie, a nie zapamiętywać stały zestaw etykiet.

Locate uczy model strukturalnie innego zadania, a my chcemy je dodać, nie tracąc tego, co model już robi dobrze. Scalenie adapterów locate z modelem szkieletowym powoduje pewną regresję w przypadku żądań decyzyjnych. Aby to ograniczyć, badamy takie rozwiązania jak większa ilość danych do odtwarzania z wcześniejszych etapów oraz cele pomocnicze, które utrzymują wyniki modelu dla żądań decyzyjnych blisko wyników oryginalnego modelu. Stwierdzamy jednak, że scalanie wciąż nie jest bezstratne, dlatego pozostawiamy adaptery niescalone i aktywujemy je tylko dla żądań locate.

Ewaluacja

Modele Decider v1.3 i Decider Flash v1.3 oceniamy na zewnętrznych benchmarkach z Hugging Face Decision Index, ClaimBench od Vals AI oraz Artificial Analysis Decision Index.

We wszystkich tych ewaluacjach nasze modele osiągają wysoką wydajność. Choć rankingi te obejmują zadania utrzymywane jako prywatne, nadal można nimi manipulować poprzez wielokrotne zgłoszenia i iteracyjne dostrajanie na podstawie informacji zwrotnych z rankingu. Aby uzupełnić te rankingi, oceniamy modele na wewnętrznym zestawie łączącym prywatne zadania produkcyjne z ewaluacjami na danych odłożonych, pochodzących z publicznych zbiorów danych niebędących benchmarkami. Te ewaluacje stanowią dodatkowy sprawdzian zdolności generalizacji wykraczający poza publiczne benchmarki i pomagają nam odróżnić szersze ulepszenia od zysków charakterystycznych dla dobrze znanych zestawów ewaluacyjnych.

Wewnętrznie zbudowaliśmy zestaw ponad 200 zadań z różnych dziedzin, obejmujących m.in. klasyfikację, ocenianie, ponowne rangowanie i ekstrakcję encji. Aby rzetelnie ocenić rzeczywistą skuteczność modelu Decider, wszystkie ewaluacje przeprowadzamy w trybie zero-shot, bez dostrajania pod konkretne zadania, co daje nam jasny sygnał, gdzie należy ulepszyć model.

Klasyfikacja zapytań

W Perplexity do przetwarzania każdego zapytania użytkownika używamy systemu klasyfikacji z wieloma głowicami. Każde zapytanie najpierw trafia do modelu embeddingów, który pełni funkcję ekstraktora cech. Uzyskany embedding jest następnie przekazywany do wielu oddzielnych głowic klasyfikacyjnych, w tym klasyfikatorów binarnych i wieloetykietowych. Na przykład jedna z głowic określa, czy zapytanie użytkownika powinno uruchomić wyszukiwanie w sieci.

W 63 zadaniach klasyfikacyjnych z odpowiedziami referencyjnymi niezależnie ponownie oznaczonymi przez czołowy model LLM Decider v1.3 osiąga średnią dokładność 91,6%, przewyższając nasze klasyfikatory produkcyjne o 6,54 punktu procentowego. Decider Flash v1.3 również przewyższa produkcyjny model bazowy, a Decider v1.3 przewyższa Jev 1.14.

Powiększ

Klasyfikacja w dziedzinach specjalistycznych

Zebraliśmy z publicznych zbiorów danych dziedzinowy zestaw ewaluacyjny, aby ocenić skuteczność klasyfikacji modeli decyzyjnych w siedmiu dziedzinach: weryfikacja twierdzeń (6 zadań), opieka zdrowotna (7), cyberbezpieczeństwo (8), programowanie (16), administracja publiczna (7), prawo (9) i finanse (9).

Na przykład „oceń złożoność czasową programu w języku Python” lub „na podstawie rocznego raportu finansowego ustal, czy nieobciążone środki pieniężne spółki pokrywają kapitał zadłużenia przypadający do spłaty w ciągu najbliższych dwunastu miesięcy”. Decider v1.3 prowadzi we wszystkich siedmiu dziedzinach, przewyższając Jev 1.14 o maksymalnie 12,9 punktu procentowego w finansach i 9,3 punktu w prawie. Decider Flash v1.3 ustępuje Jev 1.14 w finansach, programowaniu i prawie, a w pozostałych dziedzinach osiąga podobne wyniki.

Powiększ

Wyszukiwanie i ponowne rangowanie

Wyszukiwanie jest podstawą Perplexity. Utrzymujemy szeroki zestaw zadań wyszukiwania, aby oceniać skuteczność naszych modeli w ponownym rangowaniu. W każdym zadaniu najpierw używamy puli modeli embeddingów, aby pobrać z każdego korpusu 50 najlepszych dokumentów kandydujących. Następnie ponownie rangujemy tych kandydatów za pomocą modelu Decider i porównujemy jego wydajność z silnym modelem bazowym do ponownego rangowania — Qwen3-Reranker-8B.

Ewaluujemy model Decider w trybie zero-shot i punktowym (pointwise): model bezpośrednio i niezależnie ocenia każdą parę zapytanie–dokument, a dokumenty są szeregowane według trafności. W 72 zadaniach wyszukiwania Decider v1.3 osiąga średni wynik nDCG@10 równy 83,99, przewyższając Qwen3-Reranker-8B o 1,81 punktu i Jev 1.14 o 2,24 punktu.

W benchmarku BEIR oba modele przewyższają Qwen3-Reranker-8B o odpowiednio 8,78 i 7,05 punktu nDCG@10. W porównaniu z Jev 1.14 Decider v1.3 uzyskuje wynik wyższy o 1,33 punktu, a wersja Flash — niższy o 0,4 punktu.

Powiększ

Klasyfikacja wielojęzyczna

Aby ocenić modele decyzyjne poza językiem angielskim, zebraliśmy wielojęzyczny benchmark klasyfikacyjny obejmujący 19 zadań specyficznych dla poszczególnych języków z 8 publicznych zbiorów danych, z 46 484 przykładami w ośmiu językach: niemieckim, hiszpańskim, francuskim, włoskim, rosyjskim, japońskim, koreańskim i chińskim. Benchmark obejmuje wykrywanie intencji, klasyfikację tematów, analizę sentymentu, wnioskowanie w języku naturalnym, wykrywanie parafraz, wykrywanie obraźliwego języka i poprawność gramatyczną.

Podajemy średnią dokładność w zadaniach dla każdego języka, przypisując każdemu zadaniu jednakową wagę. Decider v1.3 przewyższa Jev 1.14 we wszystkich ośmiu językach, a Decider Flash v1.3 — w sześciu; średnia dokładność w zadaniach wynosi 88,16% dla Decider v1.3 i 86,50% dla Decider Flash v1.3 wobec 85,41% dla Jev 1.14.

Powiększ

NER, PII i ekstrakcyjne QA

Funkcję locate ewaluujemy na 17 zadaniach spoza domeny treningowej, które sprawdzają ekstrakcję w różnych dziedzinach, formatach wejściowych (tekst, tabele, dokumenty ustrukturyzowane) i rodzajach instrukcji (krótkie etykiety, pytania i szczegółowe opisy). Dziedziny sięgają od Wikipedii po artykuły naukowe, raporty o cyberzagrożeniach, wsparcie techniczne, polityki prywatności, CV i umowy prawne. Zapytania sięgają od krótkich nazw etykiet, takich jak „osoba” czy „adres e-mail”, przez pytania dotyczące tabeli lub zgłoszenia do pomocy technicznej, po szczegółowe opisy pól do ekstrakcji ustrukturyzowanej, np. stron umowy NDA czy kwoty łącznej na fakturze.

NER i PII oceniamy za pomocą miary F1 dla dokładnych fragmentów, która wymaga, aby przewidziane fragmenty dokładnie pokrywały się z granicami referencyjnymi. W ekstrakcyjnym QA stosujemy F1 na poziomie znaków, która przyznaje częściowe punkty za nakładający się tekst odpowiedzi, a w ekstrakcji ustrukturyzowanej – dokładność pól, czyli odsetek poprawnie wyodrębnionych pól. W przypadku parsowania CV uśredniamy wyniki F1 dla dokładnych fragmentów z NER i PII.

Porównujemy nasze modele z ogólnymi modelami ekstrakcyjnymi różnej wielkości: GLiNER large v2.5 (0,5B), Liquid d1 (2B) i Clairic firmy Cloudflare (rozmiar nieujawniony). Decider v1.3 osiąga średni wynik 69,0 (według głównej metryki każdego zadania), a Decider Flash v1.3 — 63,6, wobec 43,3 dla Liquid d1, 41,5 dla Clairic i 33,6 dla GLiNER large v2.5. Oba modele Decider prowadzą w każdej kategorii.

Powiększ

Klasyfikacja obrazów

Decider natywnie obsługuje zadania wizualne od wersji v1. Aby ocenić jego wydajność poza tekstem, zebraliśmy zestaw benchmarków złożony z pięciu zadań, ze szczególnym naciskiem na klasyfikację dokumentów, w tym faktur, listów i CV. Zestaw obejmuje też klasyfikację zdjęć satelitarnych, klasyfikację tekstur, klasyfikację ras zwierząt domowych i liczenie zwierząt.

Decider v1.3 osiąga średnią dokładność 76,99% w pięciu zadaniach wizualnych, przewyższając Jev 1.14 o 1,47 punktu procentowego. Decider Flash v1.3 osiąga 72,77%, co pokazuje możliwości klasyfikacji wizualnej w mniejszym modelu.

Powiększ

Rzeczywiste zapytania decyzyjne

Pobraliśmy próbę miliona zdeduplikowanych zapytań z zamaskowanymi danymi PII, przesłanych do Perplexity Decision API w ciągu pierwszych 18 dni jego dostępności. Ponieważ każde zapytanie może zawierać wiele pytań dotyczących tego samego stanu, próba obejmuje 2 318 887 pojedynczych pytań. Wszystkie zapytania zostały uwzględnione za wyraźną zgodą użytkowników na wykorzystanie w badaniach.

Zapytania produkcyjne nie mają etykiet referencyjnych (ground truth), dlatego używamy czołowych modeli LLM w roli sędziów do generowania odpowiedzi referencyjnych i mierzymy zgodność każdego modelu z nimi. Grupujemy też zapytania w 10 kategorii zadań, obejmujących ekstrakcję informacji, klasyfikację dziedzin, analizę sentymentu, intencje i routing, rangowanie trafności, moderację treści, przegląd jakości i zgodności, dopasowywanie encji, analizę biznesową oraz kategorię „Inne”. Ten podział pokazuje, jak wydajność różni się w zależności od rzeczywistych zastosowań.

Rozkład zadań jest nierówny: ekstrakcja informacji odpowiada za 425 402 pytania, klasyfikacja dziedzin za 409 564, a analiza sentymentu za 344 158. Łącznie te trzy kategorie stanowią 50,8% pytań w próbie.

Decider v1.3 osiąga najwyższą zgodność z sędziami — 93,98% — wobec 93,68% dla Decider v1.2 i 93,35% dla Jev 1.14. Decider v1.3 i Jev 1.14 są bardzo wyrównane w klasyfikacji dziedzin i analizie sentymentu, z różnicami odpowiednio 0,34 i 0,07 punktu procentowego. Jev prowadzi o 0,69 punktu w rangowaniu trafności, natomiast Decider v1.3 prowadzi o 0,93 punktu w ekstrakcji informacji (najczęstszym zadaniu w próbie) i o 1,21 punktu w kategorii intencje i routing.

Powiększ

Poniższy wykres porównuje zgłoszony koszt obsługi tego samego miliona zapytań produkcyjnych. Każde zapytanie może zawierać wiele pytań, dlatego jednostką są tu zapytania, a nie pojedyncze pytania.

Powiększ

Odporność

Wrażliwość na etykiety oceniliśmy na 372 pytaniach wielokrotnego wyboru, wysyłając 4788 zapytań na model. Zmienialiśmy kolejność opcji, przypisywaliśmy etykiety do innych treści odpowiedzi i zmienialiśmy nazwy etykiet, zachowując znaczenie każdego pytania, a następnie sprawdzaliśmy, czy zmieniła się semantyczna odpowiedź modelu. Niższy odsetek zmian odpowiedzi oznacza większą stabilność.

Decider v1.3 zmienił odpowiedź w zaledwie 0,27% pytań przy każdej transformacji, w porównaniu z 2,69–4,84% w przypadku Jev 1.14. Powtarzaliśmy też identyczne dane wejściowe, aby zmierzyć zmienność podczas serwowania: Decider v1.3 nie wykazał żadnych zmian, podczas gdy Jev 1.14 zmienił odpowiedź w 1,88% pytań.

Powiększ

Jak używamy modelu Decider

Decider powstał z myślą o przepływach pracy, które wymagają szybkich i ustrukturyzowanych decyzji. W tej sekcji pokazujemy, jak go wykorzystać, by realnie wpłynąć na sposób naszej pracy. Oto przykłady, które się wyróżniły.

Samodoskonalące się reguły bezpieczeństwa

Wewnętrznie już korzystamy z modelu Decider, aby ulepszać nasze zasady bezpieczeństwa.

Aktywność naszych agentów jest rejestrowana, a seria kontroli opartych na regułach pozwala wykryć wszelkie problematyczne zachowania. Podejście oparte na regułach oznacza, że możemy monitorować agentów w czasie rzeczywistym przy znikomym dodatkowym opóźnieniu. Offline używamy modelu Decider do analizy próbek z zarejestrowanych logów agentów. Jeśli nie oznaczono żadnego problematycznego zachowania, Decider sprawdza, czy nasz zestaw reguł czegoś nie przeoczył, a jeśli podniesiono alarm — czy nie był to fałszywy alarm. Wszystkie rekordy, w których nasz zestaw reguł zawodzi w którymkolwiek z tych przypadków, trafiają do agenta w celu oceny, a ten proponuje poprawkę reguł, którą musi zatwierdzić członek naszego zespołu ds. bezpieczeństwa.

W ciągu jednego dnia Decider przeczytał 1 mld tokenów z 7000 sesji agentów i wykrył usterki, które doprowadziły do 14 poprawek reguł, z których 6 zatwierdzono i wdrożono w ciągu dwóch dni. Po odtworzeniu na logach z jednego tygodnia poprawki zmniejszyły liczbę zdarzeń najbardziej obciążonej reguły o 52%, a poszerzone reguły wychwyciły o około 40% więcej działań faktycznie wymagających zbadania.

Powiększ

Monitorowanie przebiegów RL

Gdy dotrenowujemy modele za pomocą uczenia przez wzmacnianie, zagregowane metryki, takie jak nagroda końcowa, nie wyjaśniają, dlaczego dany przebieg (pojedyncza próba wykonania zadania) zakończył się sukcesem lub porażką. Przebieg może niesłusznie stracić nagrodę, ponieważ zawiodła usługa narzędzia lub piaskownica, albo otrzymać niezasłużoną nagrodę, jeśli ewaluator przeoczy niepoparte twierdzenie, np. zmyśloną wartość, której nie zwróciło żadne narzędzie.

Używamy modelu Decider do monitorowania przebiegów pod kątem takich przypadków. Kod najpierw identyfikuje fragmenty przebiegu wymagające dokładniejszej analizy: nieudane wywołanie narzędzia wraz z otaczającym je rozumowaniem, kod, który wykonał się bez błędów, lub ostateczną odpowiedź. Następnie Decider odpowiada na pytania wielokrotnego wyboru dotyczące każdego fragmentu, np. co zawiodło w danym kroku (usługa narzędzia, zewnętrzna witryna, piaskownica, harness czy własny kod agenta) i czy agent poprawnie zinterpretował wynik. Wszystkie pytania dotyczące danego fragmentu łączymy w jedno zapytanie i zapisujemy prawdopodobieństwa zamiast werdyktu, dzięki czemu możemy później dostosować progi bez ponownego odpytywania modelu Decider. Monitor jedynie obserwuje i diagnozuje: nigdy nie zmienia nagrody ani nie zatrzymuje przebiegu.

Powiększ

Filtrowanie stron według jakości

Podczas indeksowania stron internetowych, które mają być udostępniane użytkownikom, okazuje się, że wiele z nich ma zbyt niską jakość, by do czegokolwiek się przydać. Należą do nich blokady antybotowe, CAPTCHA i strony błędów, a także poprawnie załadowane strony, które po prostu nie zawierają żadnych przydatnych informacji, np. spam, wypełniacze SEO czy strony zawierające wyłącznie nawigację. Takie strony niskiej jakości trzeba zidentyfikować i odfiltrować z naszego indeksu.

Za pomocą modelu Decider możemy oceniać jakość stron już podczas ich pobierania przez crawler. W tym samym przebiegu w przód wykonujemy szereg innych zadań klasyfikacji, takich jak określanie dziedziny i docelowych odbiorców treści oraz tego, czy zawiera ona informacje szkodliwe, nielegalne lub umożliwiające identyfikację osób. W porównaniu z wykorzystaniem LLM w roli sędziego Decider jest znacznie szybszy i tańszy.

Powiększ

Poza tymi zastosowaniami wewnętrznymi Decider sprawdza się także w przepływach pracy takich jak poniższe.

Wizualne odpowiadanie na pytania

Ponieważ Decider odczytuje obrazy, sprawdza się też jako narzędzie do weryfikacji wizualnej: przegląda zmiany stylu stron internetowych lub aplikacji i wykrywa usterki. Może przeglądać zrzuty ekranu stron w poszukiwaniu uciętego tekstu, nakładających się elementów i zepsutych układów, zanim zmiana zostanie wdrożona, lub oznaczać wykresy, których projekt mógłby wprowadzić czytelnika w błąd albo naruszyć wytyczne marki.

Powiększ

Nawigacja w przeglądarce

Agenci mogą używać modelu Decider do drobnych decyzji w ramach większych zadań. Agent przeglądarki może wysyłać zrzut ekranu na każdym kroku i otrzymywać szczegółowe informacje o stanie strony oraz oczekiwanym wyniku każdej możliwej akcji.

Powiększ

Planowanie zadań badawczych

Pytania użytkowników mogą znacznie różnić się złożonością, podobnie jak głębokość wyszukiwania potrzebnego do znalezienia odpowiedzi. Decider potrafi to oszacować przed rozpoczęciem wyszukiwania, dzięki czemu na proste pytania można przeznaczyć mniej zasobów.

Powiększ

Pierwsze kroki

Decider zwraca prawdopodobieństwa. Odpowiedni próg decyzyjny zależy od zastosowania. Częstość etykiet oraz względne koszty wyników fałszywie dodatnich i fałszywie ujemnych różnią się w zależności od przypadku użycia. Dlatego zachęcamy użytkowników do dostrajania progów na małym, reprezentatywnym, oznaczonym zbiorze deweloperskim, zamiast zakładać, że stały próg odcięcia sprawdzi się równie dobrze we wszystkich zadaniach.

Zalecamy korzystanie z modelu Decider v1.3 w przypadku zniuansowanych ocen, szczegółowych kryteriów oceny i przepływów pracy, w których błędy są kosztowne. Wybierz Decider Flash v1.3 do obsługi dużych wolumenów routingu, etykietowania i filtrowania, gdy głównymi ograniczeniami są opóźnienie i koszt. Oceń oba modele na reprezentatywnych przykładach ze swojego obciążenia roboczego, a następnie wybierz model, który spełnia Twoje wymagania dotyczące jakości, opóźnienia i budżetu.

Oba modele są dostępne jako wagi do pobrania w serwisie Hugging Face na licencji Apache, przez OpenRouter oraz w Perplexity Decisions API.

Cytowanie

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