Perplexity Decider

Wir veröffentlichen Decider v1.3 und Decider Flash v1.3, die Nachfolger unserer früheren Entscheidungsmodelle v1, v1.1, v1.2 und Flash v1.2.

Decider Flash v1.3 ist ein kleineres Modell, das aus Decider v1.3 destilliert wurde. Beide Modelle sind auf Hugging Face unter Apache-Lizenz, über OpenRouter und über die Perplexity Decisions API verfügbar.

Perplexity Decider ist von Jev inspiriert, dem System One Model von TypeSafe AI. Es unterstützt binäre und Multi-Class-Klassifizierung mit geordneten oder ungeordneten Labels und gibt Wahrscheinlichkeiten zurück, die Anwendungen zum Klassifizieren, Routen, Ranken und Bewerten von Eingaben nutzen können.

Beide v1.3-Modelle verbessern Leistung und Robustheit bei einem breiten Spektrum an Text- und Vision-Aufgaben – durch bidirektionale Attention, sorgfältiger kuratierte Trainingsdaten und ein verfeinertes Trainingsrezept. Außerdem führen wir locate ein, eine neue Funktion, die die ausgewählten Inhalte für Named Entity Recognition, die Erkennung personenbezogener Daten und extraktive Frage-Antwort-Aufgaben hervorhebt.

In diesem Beitrag erklären wir, wie wir Decider trainieren und evaluieren, und zeigen, wie wir es intern bei Perplexity einsetzen.

Was ist ein Entscheidungsmodell?

Ein Entscheidungsmodell ist ein universeller Klassifikator. Sie geben ihm eine Eingabe und eine Reihe von Fragen mit den jeweils möglichen Antworten. Für jede Frage gibt es eine Wahrscheinlichkeitsverteilung über die Antworten zurück. Es unterstützt 3 Fragetypen:

• Ja / Nein: binäre Entscheidungen.
• Multiple Choice: benutzerdefinierte Multi-Class-Labels.
• Score: geordnete Stufen.

Entscheidungsmodelle unterstützen ein breites Spektrum an Klassifizierungs- und Bewertungsaufgaben:

• Bewertung von Ausgaben: Beurteilung von Faktentreue, Qualität und Sicherheit.
• Routing: Weiterleitung von Anfragen je nach Schwierigkeit an kleinere oder größere Modelle.
• Moderation und Sicherheit: Erkennung von schädlichen Inhalten, Phishing und Prompt Injection in Tool-Ausgaben.
• Filtern und Taggen: Organisieren großer Inhaltssammlungen.
• Retrieval und Reranking: Bewertung von Suchergebnissen nach Relevanz.

Viele dieser Aufgaben wurden bisher von generativen Modellen wie LLMs übernommen, obwohl sie keine frei formulierte Textgenerierung erfordern. Entscheidungsmodelle liegen zwischen LLMs und aufgabenspezifischen Klassifikatoren. Sie liefern in einem einzigen Forward-Pass Wahrscheinlichkeiten für mehrere Fragen zur selben Eingabe, vermeiden so die Token-für-Token-Generierung von Antworten und teilen die Berechnung über die Fragen hinweg. Anders als aufgabenspezifische Klassifikatoren können sie neue Aufgaben über Prompts in natürlicher Sprache bewältigen – eine Flexibilität, die sie durch das Training über vielfältige Aufgaben hinweg in einem gemeinsamen Frage-Antwort-Format erlernen.

Training

Wie aus einem generativen LLM ein Entscheidungsmodell wird

Wir entwickeln Decider, indem wir leistungsstarke generative LLM-Backbones anpassen. Um diese Anpassung zu erläutern, beschreiben wir zunächst, wie eine Anfrage dargestellt wird. Wie unten veranschaulicht, besteht eine Anfrage aus einem gemeinsamen Kontext (dem Zustand) und einer Reihe von Fragen. Der Zustand wird von allen Fragen wiederverwendet.

Bei einem Dokument und seiner Zusammenfassung kann eine einzige Anfrage zum Beispiel fragen, ob die Zusammenfassung das Dokument getreu wiedergibt und ob sie sich an Fachleute oder an ein allgemeines Publikum richtet. Nach dem State enthält jeder Frageblock eine Frage und ihre möglichen Antworten, denen jeweils ein vordefiniertes Label-Token wie A, B oder C zugewiesen ist. Ein spezielles <|marker|>-Token gibt an, wo die Vorhersage des Modells ausgelesen wird. An dieser Position bildet eine gelernte lineare Ausgabeschicht (ein Decision-Head) den Hidden State auf Scores für die Antwortoptionen der Frage ab, die anschließend in Wahrscheinlichkeiten umgewandelt werden.

Vergrößern

Wir initialisieren die Ausgabeschicht aus dem Basismodell, das normalerweise das nächste Token aus dem gesamten Vokabular bewertet, und behalten nur die Zeilen, die den vordefinierten Options-Tokens wie A, B oder C entsprechen. Diese reduzierte Schicht wird dann darauf trainiert, den Hidden State von <|marker|> in Antwort-Scores umzuwandeln. Dieser Ansatz deckt alle Klassifizierungsfragen ab, da sie sich alle als Multiple Choice formulieren lassen.

Für das Training nehmen wir Hunderte öffentlicher Datensätze, die vielfältige Aufgaben abdecken (Sentiment, Natural Language Inference, Intent-Erkennung, Entity Matching, Moderation, Faktenprüfung, Bewertungen usw.), und wandeln jedes Beispiel in das oben beschriebene einheitliche Format um: einen State, eine oder mehrere Fragen, deren Optionen und ein Ziel. Das Ziel kann die einzige richtige Option sein, wenn Gold-Labels vorliegen, oder eine Wahrscheinlichkeitsverteilung über die Optionen.

In v1.3 führen wir locate ein, das Text aus dem State extrahiert, statt aus vordefinierten Optionen auszuwählen. Eine locate-Frage beschreibt, was gefunden werden soll – entweder mit einem kurzen Label wie „Ort“ oder mit einer Anweisung wie „Extrahiere den Namen der Stadt, in der sich die Stelle befindet.“ Das Modell gibt den exakt passenden Text aus dem State zusammen mit seiner Start- und Endposition auf Zeichenebene zurück. Findet es keine Treffer, gibt es eine leere Liste zurück.

Vergrößern

Dank des gemeinsamen States kann eine einzige Anfrage locate-, Klassifizierungs- und Bewertungsfragen zur selben Eingabe kombinieren. Sie kann zum Beispiel fragen, ob eine Stelle Erfahrung auf Senior-Niveau erfordert, und die erforderlichen Fähigkeiten extrahieren.

Bidirektionale Attention: Das Modell liest in beide Richtungen

Unsere Modelle basieren auf leistungsstarken vortrainierten generativen Backbones, deren kausale Attention es jedem Token erlaubt, nur sich selbst und vorangehende Tokens zu berücksichtigen. Unsere Ablationsstudien haben gezeigt, dass es die Leistung verbessert, die Full-Attention-Layer des Backbones bidirektional zu machen. Deshalb übernehmen wir dieses Design, damit jedes Token Kontext aus der gesamten Eingabe einbeziehen kann.

Bidirektionale Attention bringt eine weitere Designentscheidung mit sich: Wie sollen State und Fragen interagieren? Wir haben drei Attention-Muster mit unterschiedlichen Auswirkungen auf Leistung, Antwortstabilität und Cache-Wiederverwendung betrachtet:

• Alles sieht alles (v1.2): Der State und alle Fragen werden gemeinsam mit vollständiger bidirektionaler Attention verarbeitet. Die Berechnung über den State wird geteilt, aber die Antwort auf eine Frage kann sich je nachdem ändern, was sonst noch gefragt wird.
• Isolierte Fragen (v1.3): Der State berücksichtigt alle Fragen, während jede Frage nur den State und ihre eigenen Tokens berücksichtigt. Fragen können sich über den gemeinsamen State zwar weiterhin indirekt gegenseitig beeinflussen, die Ergebnisse sind aber stabiler.
• Vollständig cachefähig: Der Zustand richtet die Attention nur auf sich selbst, während jede Frage die Attention auf den Zustand und ihre eigenen Token richtet. Der Zustand ist unabhängig von den Fragen und lässt sich über Anfragen hinweg wiederverwenden, um Prompt-Caching zu nutzen. Wir verwenden diesen Modus nicht standardmäßig, weil es für mehrere Aufgaben sehr wichtig ist, dass der Zustand die Fragen sehen kann. Ein kurzes Fine-Tuning genügt jedoch, um ein Modell darauf umzustellen.

Letztlich haben wir uns wegen ihrer starken Leistung und Stabilität für isolierte Fragen entschieden.

Vergrößern

Trainingsrezept

Das Training verläuft für beide Modellgrößen in drei Phasen. Zuerst trainieren wir das größere Modell auf Basis von Qwen3.8-27B mit Kreuzentropie auf großen Datensätzen und destillieren es anschließend in das kleinere Modell Qwen3.5-4B.

Die erste Phase ist ein generalistisches Training, bei dem wir das Modell vollständig auf großen Korpora feintunen. In dieser Phase akzeptieren wir nur Daten, die dem Modell auf ganzer Linie helfen und nicht auf einen bestimmten Benchmark zugeschnitten sind; daher schließen wir sämtliche Benchmark-Trainingssplits aus.

Nachdem dieses Generalistenmodell trainiert ist, führen wir mit LoRA eine zweite, feinere Phase durch. Die Daten in dieser Phase zielen auf bestimmte Domänen und Aufgaben ab. Wir fügen Daten in der zweiten statt in der ersten Phase hinzu, wenn wir nur eng begrenzte Verbesserungen oder Regressionen bei anderen Aufgaben beobachten. Mit LoRA vermeiden wir, uns zu weit vom Generalistenmodell zu entfernen und Leistung einzubüßen, nur um diese spezifischen Domänen abzudecken. Ziel ist es, die Leistung zu verbessern und gleichzeitig das allgemeine Wissen des Backbones zu erhalten. Beim Zusammenführen der LoRA-Gewichte mit dem Basismodell verwenden wir außerdem eine Gewichtung, um die Abweichung genauer zu steuern und Metriken auf zurückgehaltenen Daten gegenüber domäneninternen Verbesserungen zu priorisieren.

Abschließend fügen wir einen Vision-spezifischen Schritt hinzu. Ähnlich wie die zweite Phase wird der Vision-Schritt als weiterer feinkörniger Spezialisierungsschritt behandelt, bei dem ein LoRA-Adapter verwendet wird, der mit einer Gewichtung wieder mit dem Basismodell zusammengeführt wird. Manche Vision-Fähigkeiten können auf Kosten der Textleistung gehen. Da wir eine deutlich stärkere Nutzung der Modelle für Text beobachten, priorisieren wir Textmetriken gegenüber Vision-Metriken.

Für beide Textphasen verwenden wir die gemittelten Gewichte aus drei Durchläufen mit jeweils unterschiedlichem Zufalls-Seed. Wir haben festgestellt, dass dies die Leistung und Robustheit des aggregierten Modells verbessert.

Sobald das finale große Modell vorliegt, wenden wir dasselbe dreistufige Trainingsverfahren auf das kleinere Modell an. Dabei fungiert das große Modell als Lehrermodell: Seine vorhergesagte Ausgabeverteilung ersetzt die Gold-Labels, und das kleinere Modell wird darauf trainiert, die KL-Divergenz zwischen seinen Vorhersagen und denen des Lehrermodells zu minimieren. Dieses Destillationsziel übertrifft Kreuzentropie auf denselben Trainingsdaten. Kreuzentropie schneidet zwar bei Benchmarks mit eigenen Trainingsdaten besser ab, generalisiert aber schlechter auf zurückgehaltene Daten. Wir vermuten, dass Destillation die Ausgabeverteilung des Lehrermodells besser überträgt, einschließlich seiner Konfidenz in Alternativen jenseits des Gold-Labels, während Kreuzentropie eine Überanpassung an die benchmarkspezifische Trainingsverteilung fördert. Daher setzen wir auf das KL-basierte Destillationsziel.

Um eine Kontamination zwischen Trainings- und Testdaten zu verringern, entfernen wir alle Trainingsbeispiele, die sich mit einer unserer Evaluierungen überschneiden könnten. Das ist wichtig, weil einige öffentliche Trainingsdatensätze große Teile mancher Evaluierungsdatensätze enthalten. Außerdem führen wir umfangreiche Bias-Audits und -Bereinigungen durch, um sicherzustellen, dass unsere Verbesserungen belastbar sind und nicht bloß auf erlernten Verzerrungen beruhen.

Erweiterung um Informationsextraktion

Die Funktion locate extrahiert Informationen wie benannte Entitäten aus Text, ohne zu verändern, wie gewöhnliche Anfragen beantwortet werden. Dazu führen wir eine zusätzliche Trainingsphase ein: Wir fügen Decider ein neues Spezialtoken, <|locate|>, einen Span-Head und einen LoRA-Adapter hinzu.

Wir initialisieren das Embedding von <|locate|> aus dem Embedding von <|marker|>, das in den vorherigen Trainingsphasen gelernt wurde. Wir trainieren nur dieses neue Embedding, den Span-Head und die LoRA-Adapter, während die ursprünglichen Backbone-Gewichte und der Decision-Head eingefroren bleiben. Jedes angeforderte Feld erhält sein eigenes <|locate|>-Token.

Der Span-Head nutzt die Repräsentation von <|locate|> zusammen mit den Repräsentationen der Zustands-Token, um zu bewerten, wo passende Spans beginnen und enden und welche Start-End-Paare zusammengehören. Außerdem nutzt er die Repräsentation des Tokens <|locate|>, um feldspezifische Schwellenwerte für diese Scores vorherzusagen. Ausgewählte Spans werden als Zeichenpositionen im Originaltext zurückgegeben.

Wir trainieren den Span-Head mit einem angepassten InfoNCE-Loss, der jeden Gold-Span über den Schwellenwert und den Schwellenwert über jeden anderen Span hebt. Der Loss besteht aus zwei Termen: Der erste hebt die Scores korrekter Spans über den Schwellenwert und die falschen Spans. Der zweite Term hebt den Schwellenwert über die Scores falscher Spans. Felder ohne Antwort erhalten nur den zweiten Term, wodurch das Modell lernt, eine leere Liste zurückzugeben.

Wir trainieren auf einer Mischung von Span-Extraktionsaufgaben, darunter Named Entity Recognition, PII-Erkennung und extraktives Question Answering. Wir variieren die Feldbeschreibungen von kurzen Labels bis hin zu detaillierten Anweisungen, damit das Modell lernt, der Anfrage zu folgen, statt sich einen festen Label-Satz einzuprägen.

Locate bringt dem Modell eine strukturell andere Aufgabe bei, und wir möchten sie hinzufügen, ohne zu verlieren, was das Modell bereits gut kann. Werden die Locate-Adapter in das Backbone integriert, kommt es bei Entscheidungsanfragen zu gewissen Regressionen. Um das zu begrenzen, untersuchen wir derzeit Ansätze wie mehr Replay-Daten aus früheren Phasen und Hilfsziele, die die Ausgaben des Modells bei Entscheidungsanfragen nahe an denen des ursprünglichen Modells halten. Wir stellen jedoch fest, dass das Zusammenführen derzeit noch nicht verlustfrei ist. Deshalb lassen wir die Adapter getrennt und aktivieren sie nur für Locate-Anfragen.

Evaluierung

Wir evaluieren Decider v1.3 und Decider Flash v1.3 anhand externer Benchmarks aus dem Hugging Face Decision Index, ClaimBench von Vals AI und dem Artificial Analysis Decision Index.

In diesen Evaluierungen zeigen unsere Modelle eine starke Leistung. Auch wenn diese Leaderboards nicht öffentliche Aufgaben enthalten, lassen sie sich durch wiederholte Einreichungen und iteratives Tuning anhand des Leaderboard-Feedbacks dennoch manipulieren. Ergänzend zu diesen Leaderboards evaluieren wir die Modelle mit einer internen Suite, die nicht öffentliche Produktionsaufgaben mit zurückgehaltenen Evaluierungen aus öffentlichen Datensätzen kombiniert, die keine Benchmarks sind. Diese Evaluierungen bieten eine zusätzliche Prüfung der Generalisierung über öffentliche Benchmarks hinaus und helfen uns, breitere Verbesserungen von Zuwächsen zu unterscheiden, die nur bei bekannten Evaluierungssuites auftreten.

Intern haben wir eine Suite aus mehr als 200 Aufgaben aus verschiedenen Domänen aufgebaut, die Aufgabentypen wie Klassifizierung, Bewertung, Reranking und Entitätsextraktion abdecken. Um die Leistung von Decider in der Praxis ehrlich zu beurteilen, werden alle Evaluierungen zero-shot durchgeführt, ohne aufgabenspezifisches Fine-Tuning. So erhalten wir ein klares Signal dafür, wo wir das Modell verbessern können.

Klassifizierung von Anfragen

Bei Perplexity verwenden wir ein Multi-Head-Klassifizierungssystem, um jede Nutzeranfrage zu verarbeiten. Jede Anfrage durchläuft zunächst ein Embedding-Modell, das als Feature-Extraktor dient. Das resultierende Embedding wird dann in mehrere separate Klassifizierungs-Heads eingespeist, darunter sowohl binäre als auch Multi-Label-Klassifikatoren. Ein Head bestimmt zum Beispiel, ob eine Nutzeranfrage eine Websuche auslösen soll.

Über 63 Klassifizierungsaufgaben mit Referenzen, die von einem Frontier-LLM unabhängig neu gelabelt wurden, erreicht Decider v1.3 eine mittlere Genauigkeit von 91,6 % und übertrifft unsere Produktionsklassifikatoren damit um 6,54 Prozentpunkte. Auch Decider Flash v1.3 übertrifft die Produktions-Baseline, während Decider v1.3 zudem Jev 1.14 übertrifft.

Vergrößern

Domänenspezifische Klassifizierung

Wir haben aus öffentlichen Datensätzen eine domänenspezifische Evaluierungssuite zusammengestellt, um die Klassifizierungsleistung von Entscheidungsmodellen in sieben Domänen zu bewerten: Überprüfung von Behauptungen (6 Aufgaben), Gesundheitswesen (7), Cybersicherheit (8), Programmierung (16), öffentliche Verwaltung (7), Recht (9) und Finanzen (9).

Zum Beispiel „die Zeitkomplexität eines Python-Programms beurteilen“ oder „anhand eines Geschäftsberichts feststellen, ob die frei verfügbaren Barmittel eines Unternehmens die in den nächsten zwölf Monaten fälligen Tilgungszahlungen decken“. Decider v1.3 liegt in allen sieben Domänen vorn und übertrifft Jev 1.14 um bis zu 12,9 Prozentpunkte im Bereich Finanzen und um 9,3 Punkte im Bereich Recht. Decider Flash v1.3 liegt in den Bereichen Finanzen, Programmierung und Recht hinter Jev 1.14 und erzielt in den anderen Domänen ähnliche Ergebnisse.

Vergrößern

Retrieval und Reranking

Suche ist der Kern von Perplexity. Wir pflegen eine breite Suite von Retrieval-Aufgaben, um die Reranking-Leistung unserer Modelle zu evaluieren. Für jede Aufgabe verwenden wir zunächst einen Pool von Embedding-Modellen, um aus jedem Korpus die 50 besten Kandidatendokumente abzurufen. Anschließend führen wir mit Decider ein Reranking dieser Kandidaten durch und vergleichen seine Leistung mit einer starken Reranker-Baseline, Qwen3-Reranker-8B.

Wir evaluieren Decider in einem punktweisen Zero-Shot-Setting: Das Modell bewertet jedes Query-Dokument-Paar direkt und unabhängig, und die Dokumente werden nach Relevanz gerankt. Über 72 Retrieval-Aufgaben hinweg erreicht Decider v1.3 einen mittleren nDCG@10 von 83,99 und übertrifft damit Qwen3-Reranker-8B um 1,81 Punkte und Jev 1.14 um 2,24 Punkte.

Im BEIR-Benchmark übertreffen beide Modelle Qwen3-Reranker-8B um 8,78 bzw. 7,05 nDCG@10. Gegenüber Jev 1.14 liegt Decider v1.3 um 1,33 Punkte höher, während die Flash-Version 0,4 Punkte niedriger abschneidet.

Vergrößern

Mehrsprachige Klassifizierung

Um Entscheidungsmodelle über das Englische hinaus zu evaluieren, haben wir einen mehrsprachigen Klassifizierungs-Benchmark zusammengestellt, der 19 sprachspezifische Aufgaben aus 8 öffentlichen Datensätzen mit 46.484 Beispielen in acht Sprachen umfasst: Deutsch, Spanisch, Französisch, Italienisch, Russisch, Japanisch, Koreanisch und Chinesisch. Der Benchmark deckt Intent-Erkennung, Themenklassifizierung, Sentimentanalyse, Natural Language Inference, Paraphrasenerkennung, Erkennung beleidigender Sprache und grammatische Akzeptabilität ab.

Wir geben die mittlere Genauigkeit über die Aufgaben jeder Sprache an, wobei jede Aufgabe gleich gewichtet wird. Decider v1.3 übertrifft Jev 1.14 in allen acht Sprachen und Decider Flash v1.3 in sechs, mit mittleren Aufgabengenauigkeiten von 88,16 % für Decider v1.3 und 86,50 % für Decider Flash v1.3 gegenüber 85,41 % für Jev 1.14.

Vergrößern

NER, PII und extraktives QA

Wir evaluieren die locate-Funktion anhand von 17 Out-of-Domain-Aufgaben, die ihre Extraktionsfähigkeit über verschiedene Domänen, Eingabeformate (Text, Tabellen, strukturierte Dokumente) und Anweisungen (kurze Labels, Fragen und detaillierte Beschreibungen) hinweg testen. Die Domänen reichen von Wikipedia über wissenschaftliche Paper, Berichte zu Cyberbedrohungen, technischen Support und Datenschutzrichtlinien bis hin zu Lebensläufen und juristischen Verträgen. Die Anfragen reichen von kurzen Label-Namen wie „Person“ oder „E-Mail-Adresse“ über Fragen zu einer Tabelle oder einem Support-Ticket bis hin zu detaillierten Feldbeschreibungen für die strukturierte Extraktion, etwa für die Parteien eines NDA oder den Gesamtbetrag einer Rechnung.

Wir bewerten NER und PII anhand des Exact-Span-F1, bei dem vorhergesagte Spans exakt mit den Grenzen der Referenz übereinstimmen müssen. Extraktive QA verwendet einen F1-Wert auf Zeichenebene, der überlappenden Antworttext teilweise anrechnet, während die strukturierte Extraktion die Feldgenauigkeit verwendet, also den Anteil korrekt extrahierter Felder. Für das Parsen von Lebensläufen mitteln wir die Exact-Span-F1-Werte von NER und PII.

Wir vergleichen unsere Modelle mit universellen Extraktionsmodellen unterschiedlicher Größe: GLiNER large v2.5 (0,5B), Liquid d1 (2B) und Clairic von Cloudflare (Größe nicht veröffentlicht). Decider v1.3 erreicht einen durchschnittlichen Score von 69,0 (gemessen an der primären Metrik der jeweiligen Aufgabe) und Decider Flash v1.3 63,6, verglichen mit 43,3 für Liquid d1, 41,5 für Clairic und 33,6 für GLiNER large v2.5. Beide Decider-Modelle liegen in jeder Kategorie vorn.

Vergrößern

Bildklassifizierung

Decider unterstützt Vision-Aufgaben seit v1 nativ. Um seine Leistung über Text hinaus zu evaluieren, haben wir eine Benchmark-Suite aus fünf Aufgaben zusammengestellt, mit besonderem Fokus auf Dokumentklassifizierung, darunter Rechnungen, Briefe und Lebensläufe. Die Suite umfasst außerdem Satellitenbildklassifizierung, Texturklassifizierung, Klassifizierung von Haustierrassen und das Zählen von Tieren.

Decider v1.3 erreicht über die fünf visuellen Aufgaben hinweg eine mittlere Genauigkeit von 76,99 % und übertrifft Jev 1.14 um 1,47 Prozentpunkte. Decider Flash v1.3 erreicht 72,77 % und zeigt damit visuelle Klassifizierungsfähigkeiten in einem kleineren Modell.

Vergrößern

Entscheidungsanfragen aus der Praxis

Wir haben eine Stichprobe von einer Million deduplizierten, PII-maskierten Anfragen gezogen, die in den ersten 18 Tagen ihrer Verfügbarkeit an die Perplexity Decision API gesendet wurden. Da jede Anfrage mehrere Fragen zum selben Zustand enthalten kann, umfasst die Stichprobe 2.318.887 einzelne Fragen. Alle Anfragen wurden mit ausdrücklicher Zustimmung der Nutzer zu Forschungszwecken einbezogen.

Produktionsanfragen enthalten keine Ground-Truth-Labels. Deshalb verwenden wir Frontier-LLMs als Judges, um Referenzantworten zu erzeugen, und messen die Übereinstimmung jedes Modells mit ihnen. Außerdem gruppieren wir die Anfragen in 10 Aufgabenkategorien, darunter Informationsextraktion, Domänenklassifizierung, Sentimentanalyse, Intent und Routing, Relevanz-Ranking, Content-Moderation, Qualitäts- und Compliance-Prüfung, Entity Matching, Geschäftsanalyse sowie eine Kategorie „Sonstiges“. Diese Aufschlüsselung zeigt, wie die Leistung je nach Anwendungsfall in der Praxis variiert.

Die Aufgabenverteilung ist ungleichmäßig: Auf Informationsextraktion entfallen 425.402 Fragen, auf Domänenklassifizierung 409.564 und auf Sentimentanalyse 344.158. Zusammen machen diese drei Kategorien 50,8 % der Fragen in der Stichprobe aus.

Decider v1.3 erreicht mit 93,98 % die höchste Übereinstimmung mit den Judges, verglichen mit 93,68 % für Decider v1.2 und 93,35 % für Jev 1.14. Bei Domänenklassifizierung und Sentimentanalyse liegen Decider v1.3 und Jev 1.14 mit Abständen von 0,34 bzw. 0,07 Prozentpunkten nah beieinander. Jev liegt beim Relevanz-Ranking um 0,69 Punkte vorn, während Decider v1.3 bei der Informationsextraktion (der häufigsten Aufgabe in der Stichprobe) um 0,93 Punkte und bei Intent und Routing um 1,21 Punkte führt.

Vergrößern

Das folgende Diagramm vergleicht die angegebenen Kosten für die Ausführung derselben Million Produktionsanfragen. Da jede Anfrage mehrere Fragen enthalten kann, bezieht sich die Einheit hier auf Anfragen, nicht auf einzelne Fragen.

Vergrößern

Robustheit

Wir haben die Label-Sensitivität anhand von 372 Multiple-Choice-Fragen evaluiert und dabei 4.788 Anfragen pro Modell gestellt. Wir haben Optionen umsortiert, Labels neu den Antworttexten zugeordnet und Labels umbenannt, wobei die Bedeutung jeder Frage erhalten blieb, und dann geprüft, ob sich die semantische Antwort des Modells änderte. Niedrigere Flip-Raten bedeuten höhere Stabilität.

Decider v1.3 änderte seine Antwort bei jeder Transformation bei nur 0,27 % der Fragen, verglichen mit 2,69–4,84 % bei Jev 1.14. Außerdem haben wir identische Eingaben wiederholt, um die Variabilität beim Serving zu messen: Decider v1.3 zeigte keine Änderungen, während Jev 1.14 bei 1,88 % der Fragen abwich.

Vergrößern

Wie wir Decider einsetzen

Decider wurde für Workflows entwickelt, die schnelle und strukturierte Entscheidungen erfordern. In diesem Abschnitt zeigen wir, wie wir es einsetzen, um unsere Arbeitsweise spürbar zu verbessern. Hier sind einige Beispiele, die besonders herausstechen.

Selbstverbessernde Sicherheitsregeln

Intern nutzen wir Decider bereits, um unsere Sicherheitsrichtlinien zu verbessern.

Die Aktivität unserer Agenten wird aufgezeichnet, und eine Reihe regelbasierter Prüfungen wird durchgeführt, um problematisches Verhalten zu erkennen. Dank des regelbasierten Ansatzes können wir unsere Agenten in Echtzeit mit vernachlässigbarer zusätzlicher Latenz überwachen. Offline verwenden wir Decider, um Stichproben aus diesen aufgezeichneten Agent-Logs zu untersuchen. Wurde kein problematisches Verhalten gemeldet, prüft Decider, ob unseren Regeln etwas entgangen ist; wurde ein Alarm ausgelöst, prüft Decider, ob es sich um einen Fehlalarm handelt. Alle Einträge, bei denen unser Regelwerk in einem der beiden Fälle versagt, werden zur Triage an einen Agenten gesendet, der eine Korrektur der Regeln vorschlägt, die von einem Mitglied unseres Sicherheitsteams genehmigt werden muss.

An einem Tag las Decider 1 Milliarde Tokens aus 7.000 Agent-Sitzungen und identifizierte Schwachstellen, die zu 14 Regelkorrekturen führten, von denen 6 innerhalb von zwei Tagen genehmigt und ausgerollt wurden. Bei der erneuten Ausführung auf den Logs einer Woche senkten die Korrekturen das Volumen unserer meistausgelösten Regel um 52 %, und die erweiterten Regeln erfassten rund 40 % mehr legitime Aktionen zur Untersuchung.

Vergrößern

Überwachung von RL-Rollouts

Wenn wir Modelle mit Reinforcement Learning nachtrainieren, erklären aggregierte Metriken wie ein finaler Reward nicht, warum ein Rollout (ein einzelner Versuch, eine Aufgabe zu lösen) erfolgreich war oder fehlgeschlagen ist. Ein Rollout kann zu Unrecht Reward verlieren, weil ein Tool-Dienst oder die Sandbox ausgefallen ist, oder unverdient Reward erhalten, wenn der Evaluator eine unbelegte Behauptung übersieht, etwa einen erfundenen Wert, den kein Tool zurückgegeben hat.

Wir verwenden Decider, um Rollouts auf solche Fälle hin zu überwachen. Zunächst identifiziert Code die Teile eines Rollouts, die eine genauere Prüfung verdienen: einen fehlgeschlagenen Tool-Aufruf und das umgebende Reasoning, Code, der fehlerfrei lief, oder die finale Antwort. Decider beantwortet dann Multiple-Choice-Fragen zu jedem Teil, etwa was in einem Schritt fehlgeschlagen ist (ein Tool-Dienst, eine externe Website, die Sandbox, der harness oder der eigene Code des Agenten) und ob der Agent das Ergebnis richtig interpretiert hat. Wir bündeln alle Fragen zu einem bestimmten Teil in einer einzigen Anfrage und speichern die Wahrscheinlichkeiten statt eines Urteils, sodass wir Schwellenwerte später anpassen können, ohne Decider erneut abzufragen. Der Monitor beobachtet und diagnostiziert nur: Er ändert nie einen Reward und stoppt nie einen Durchlauf.

Vergrößern

Filterung nach Seitenqualität

Beim Crawlen von Webseiten, die indexiert und Nutzern bereitgestellt werden sollen, ist die Qualität vieler Seiten zu gering, um von Nutzen zu sein. Dazu gehören Anti-Bot-Sperren, CAPTCHAs und Fehlerseiten, aber auch korrekt geladene Webseiten, die schlicht keine hilfreichen Informationen enthalten, etwa Spam, SEO-Fülltext oder reine Navigationsseiten. Diese minderwertigen Seiten müssen erkannt und aus unserem Index herausgefiltert werden.

Mit Decider können wir die Qualität von Seiten bereits beim Crawlen bewerten. Im selben Forward-Pass führen wir eine Reihe weiterer Klassifizierungsaufgaben aus, etwa die Bestimmung der Domäne und der Zielgruppe der Inhalte sowie die Prüfung, ob sie schädliche, illegale oder personenbezogene Informationen enthalten. Im Vergleich zum Einsatz eines LLM als Bewerter ist Decider deutlich schneller und günstiger.

Vergrößern

Über diese internen Anwendungen hinaus eignet sich Decider auch für Workflows wie die folgenden.

Visual QA

Da Decider Bilder lesen kann, eignet es sich auch als visueller Prüfer, der Stiländerungen an Webseiten oder Apps überprüft und Fehler erkennt. Es kann Screenshots von Seiten auf abgeschnittenen Text, überlappende Elemente und fehlerhafte Layouts prüfen, bevor eine Änderung ausgeliefert wird, oder Diagramme markieren, deren Gestaltung Leser in die Irre führen oder gegen einen Markenleitfaden verstoßen könnte.

Vergrößern

Browsernavigation

Agenten können Decider für die kleinen Entscheidungen innerhalb größerer Aufgaben nutzen. Ein Browser-Agent kann bei jedem Schritt einen Screenshot senden und erhält detaillierte Informationen über den Zustand der Seite und das erwartete Ergebnis jeder möglichen Aktion.

Vergrößern

Rechercheaufgaben planen

Die Fragen von Nutzern können sich in ihrer Komplexität stark unterscheiden – ebenso wie die Tiefe der Suche, die nötig ist, um eine Antwort zu finden. Decider kann dies vor Beginn der Suche einschätzen, sodass für einfache Fragen weniger Ressourcen aufgewendet werden müssen.

Vergrößern

Erste Schritte

Decider gibt Wahrscheinlichkeiten zurück. Der passende Entscheidungsschwellenwert hängt von der Anwendung ab. Label-Häufigkeiten und die relativen Kosten von False Positives und False Negatives variieren je nach Anwendungsfall. Wir empfehlen daher, Schwellenwerte auf einem kleinen, repräsentativen gelabelten Entwicklungsdatensatz abzustimmen, statt davon auszugehen, dass ein fester Grenzwert für alle Aufgaben gleich gut funktioniert.

Wir empfehlen Decider v1.3 für differenzierte Urteile, detaillierte Bewertungsraster und Workflows, in denen Fehler kostspielig sind. Wählen Sie Decider Flash v1.3 für Routing, Labeling und Filterung in großem Umfang, wenn Latenz und Kosten die wichtigsten Einschränkungen sind. Evaluieren Sie beide Modelle anhand repräsentativer Beispiele aus Ihrem Workload und wählen Sie dann das Modell, das Ihre Anforderungen an Qualität, Latenz und Budget erfüllt.

Beide Modelle sind als herunterladbare Gewichte auf Hugging Face unter Apache-Lizenz, über OpenRouter und über die Perplexity Decisions API verfügbar.

Zitation

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