Perplexity Decider

Nous lançons Decider v1.3 et Decider Flash v1.3, les successeurs de nos modèles de décision précédents : v1, v1.1, v1.2 et Flash v1.2.

Decider Flash v1.3 est un modèle plus petit distillé à partir de Decider v1.3. Les deux modèles sont offerts sur Hugging Face sous licence Apache, par l’intermédiaire d’OpenRouter et de la Perplexity Decisions API.

Perplexity Decider s’inspire de Jev, le System One Model de TypeSafe AI. Il prend en charge la classification binaire et multiclasse avec des étiquettes ordonnées ou non, et renvoie des probabilités que les applications peuvent utiliser pour classer, acheminer, ordonner et évaluer des entrées.

Les deux modèles v1.3 améliorent la performance et la robustesse sur un large éventail de tâches textuelles et visuelles grâce à l’attention bidirectionnelle, à des données d’entraînement mieux sélectionnées et à une recette d’entraînement peaufinée. Nous lançons également locate, une nouvelle fonctionnalité qui met en évidence le contenu sélectionné pour les tâches de reconnaissance d’entités nommées, d’identification de renseignements personnels et de questions-réponses extractives.

Dans ce billet, nous expliquons comment nous entraînons et évaluons Decider, et comment nous l’utilisons à l’interne chez Perplexity.

Qu’est-ce qu’un modèle de décision?

Un modèle de décision est un classificateur polyvalent. Vous lui fournissez une entrée et un ensemble de questions, chacune accompagnée de ses réponses possibles. Pour chaque question, il renvoie une distribution de probabilité sur les réponses. Il prend en charge 3 types de questions :

• Oui / Non : décisions binaires.
• Choix multiples : étiquettes multiclasses personnalisées.
• Score : niveaux ordonnés.

Les modèles de décision prennent en charge un vaste éventail de tâches de classification et de notation :

• Évaluation des sorties : appréciation de la fidélité, de la qualité et de la sécurité.
• Routage : acheminement des requêtes vers des modèles plus petits ou plus grands selon leur difficulté.
• Modération et sécurité : détection de contenu préjudiciable, d’hameçonnage et d’injection d’invites dans les sorties d’outils.
• Filtrage et étiquetage : organisation de grandes collections de contenu.
• Récupération et reclassement : notation des résultats de recherche selon leur pertinence.

Bon nombre de ces tâches étaient auparavant traitées par des modèles génératifs comme les LLM, même si elles ne nécessitent pas de génération de texte libre. Les modèles de décision se situent entre les LLM et les classificateurs propres à une tâche. Ils renvoient des probabilités pour plusieurs questions portant sur une même entrée en une seule passe avant, ce qui évite de générer les réponses jeton par jeton et permet de partager le calcul entre les questions. Contrairement aux classificateurs propres à une tâche, ils peuvent prendre en charge de nouvelles tâches au moyen d'invites en langage naturel, une flexibilité acquise grâce à un entraînement sur des tâches variées dans un format commun de questions-réponses.

Entraînement

Transformer un LLM génératif en modèle de décision

Nous concevons Decider en adaptant de solides LLM génératifs comme modèles sous-jacents. Pour expliquer cette adaptation, nous décrivons d'abord la façon dont une requête est représentée. Comme illustré ci-dessous, une requête se compose d'un contexte partagé (l'état) et d'un certain nombre de questions. L'état sera réutilisé par toutes les questions.

Par exemple, à partir d’un document et de son résumé, une seule requête peut demander si le résumé représente fidèlement le document et s’il s’adresse à un expert ou au grand public. Après l’état, chaque bloc de question contient une question et ses réponses possibles, chacune associée à un jeton d’étiquette prédéfini comme A, B ou C. Un jeton spécial <|marker|> indique où lire la prédiction du modèle. À cette position, une couche de sortie linéaire apprise (une tête de décision) projette l’état caché vers des scores pour les options de réponse de la question, lesquels sont ensuite convertis en probabilités.

Agrandir

Nous initialisons la couche de sortie à partir du modèle de base, qui note normalement le jeton suivant sur l’ensemble du vocabulaire, et ne conservons que les lignes correspondant aux jetons d’option prédéfinis comme A, B ou C. Cette couche élaguée est ensuite entraînée à transformer l’état caché de <|marker|> en scores de réponse. Cette approche couvre toutes les questions de classification, puisqu’elles peuvent toutes être formulées sous forme de choix multiples.

Pour l’entraînement, nous utilisons des centaines de jeux de données publics couvrant des tâches variées (sentiment, inférence en langage naturel, détection d’intention, appariement d’entités, modération, vérification des faits, évaluations, etc.) et convertissons chaque exemple dans le format unifié décrit ci-dessus : un état, une ou plusieurs questions, leurs options et une cible. La cible peut être l’option correcte unique si nous disposons d’étiquettes de référence, ou une distribution de probabilité sur les options.

Dans la v1.3, nous lançons locate, qui extrait du texte à partir de l’état au lieu de choisir parmi des options prédéfinies. Une question locate décrit ce qu’il faut trouver, à l’aide d’une courte étiquette comme « lieu » ou d’une consigne comme « Extrais le nom de la ville où se trouve l’emploi. » Le modèle renvoie le texte correspondant exact tiré de l’état, ainsi que ses positions de caractère de début et de fin. S’il ne trouve aucune correspondance, il renvoie une liste vide.

Agrandir

Grâce à l’état partagé, une seule requête peut combiner des questions locate, de classification et de notation portant sur la même entrée. Par exemple, elle peut demander si un emploi exige une expérience de niveau sénior et extraire les compétences requises.

Attention bidirectionnelle : permettre au modèle de lire dans les deux sens

Nos modèles partent de solides architectures génératives préentraînées, dont l’attention causale permet à chaque jeton de ne porter attention qu’à lui-même et aux jetons précédents. Nos études d’ablation ont montré que rendre bidirectionnelles les couches à attention complète de l’architecture améliore la performance; nous adoptons donc cette conception pour permettre à chaque jeton d’intégrer le contexte de l’ensemble de l’entrée.

L’attention bidirectionnelle entraîne un autre choix de conception : comment l’état et les questions devraient-ils interagir? Nous avons envisagé trois schémas d’attention, aux conséquences différentes sur la performance, la stabilité des réponses et la réutilisation du cache :

• Tout voit tout (v1.2) : L’état et toutes les questions sont traités ensemble avec une attention bidirectionnelle complète. Le calcul sur l’état est partagé, mais la réponse à une question peut changer selon les autres questions posées.
• Questions isolées (v1.3) : L’état porte attention à toutes les questions, tandis que chaque question ne porte attention qu’à l’état et à ses propres jetons. Les questions peuvent encore s’influencer indirectement par l’intermédiaire de l’état partagé, mais les résultats sont plus stables.
• Entièrement compatible avec la mise en cache : L'état ne prête attention qu'à lui-même, tandis que chaque question prête attention à l'état et à ses propres jetons. L'état est indépendant des questions et réutilisable d'une requête à l'autre afin de tirer parti de la mise en cache des invites. Nous ne l'utilisons pas par défaut, car permettre à l'état de voir les questions est très important pour plusieurs tâches, mais un léger ajustement fin suffit pour faire passer un modèle à ce mode.

Nous avons finalement choisi les questions isolées pour leur bonne performance et leur stabilité.

Agrandir

Recette d’entraînement

L'entraînement se déroule en trois étapes pour les deux tailles de modèle. Nous entraînons d'abord le plus grand modèle, basé sur Qwen3.8-27B, au moyen de l'entropie croisée sur de grands jeux de données, puis nous le distillons dans le modèle plus petit Qwen3.5-4B.

La première étape est l’entraînement généraliste, au cours duquel nous effectuons un réglage fin complet du modèle sur des corpus à grande échelle. À cette étape, nous n’acceptons que des données qui aident le modèle de façon générale et qui ne sont propres à aucun banc d’essai; nous excluons donc toute partition d’entraînement des bancs d’essai.

Une fois ce modèle généraliste entraîné, nous effectuons une deuxième étape, plus fine, à l'aide de LoRA. Les données utilisées à cette étape ciblent des domaines et des tâches précis. Nous ajoutons des données à la deuxième étape plutôt qu'à la première si nous observons des gains limités ou certaines régressions sur d'autres tâches. Nous utilisons LoRA pour éviter de trop nous éloigner du modèle généraliste et de risquer de perdre en performance pour nous adapter à ces domaines précis. L'objectif est d'améliorer la performance tout en conservant les connaissances générales du modèle sous-jacent. Nous appliquons également une pondération lors de la fusion de LoRA dans le modèle de base, afin de contrôler la dérive plus précisément et de privilégier les métriques sur les données réservées plutôt que les gains propres au domaine.

Enfin, nous ajoutons une étape propre à la vision. Comme pour la deuxième étape, l’étape de vision est traitée comme une autre étape de spécialisation fine, à l’aide d’un adaptateur LoRA qui est fusionné au modèle de base avec une pondération. Certaines capacités visuelles peuvent se faire au détriment de la performance textuelle. Comme nous observons une utilisation beaucoup plus importante des modèles sur du texte, nous accordons la priorité aux métriques textuelles plutôt qu’aux métriques visuelles.

Pour les deux étapes textuelles, nous utilisons la moyenne des poids de trois exécutions, chacune avec une graine aléatoire différente. Nous avons constaté que cela améliore la performance et la robustesse du modèle agrégé.

Une fois le grand modèle final obtenu, nous appliquons la même procédure d'entraînement en trois étapes au modèle plus petit. Ici, le grand modèle joue le rôle d'enseignant : sa distribution de sortie prédite remplace les étiquettes de référence, et le modèle plus petit est entraîné à minimiser la divergence KL entre ses prédictions et celles de l'enseignant. Cet objectif de distillation surpasse l'entropie croisée sur les mêmes données d'entraînement. Bien que l'entropie croisée donne de meilleurs résultats sur les bancs d'essai disposant de données d'entraînement dédiées, elle se généralise moins bien aux données réservées. Nous émettons l'hypothèse que la distillation transfère mieux la distribution de sortie de l'enseignant, y compris sa confiance envers les solutions de rechange autres que la référence, alors que l'entropie croisée favorise le surajustement à la distribution d'entraînement propre au banc d'essai. Nous adoptons donc l'objectif de distillation fondé sur la divergence KL.

Pour atténuer la contamination entre l'entraînement et les tests, nous retirons tout échantillon d'entraînement susceptible de recouper l'une ou l'autre des évaluations que nous utilisons. C'est important, car certains jeux de données d'entraînement publics contiennent de grandes parties de certains jeux de données d'évaluation. Nous menons également des audits approfondis des biais et les éliminons afin de nous assurer que nos gains sont fiables et ne découlent pas simplement de biais appris.

Ajouter la capacité d'extraire de l'information

La fonctionnalité locate extrait des informations, comme des entités nommées, à partir du texte, sans changer la façon dont le modèle répond aux requêtes ordinaires. Pour ce faire, nous introduisons une étape d’entraînement supplémentaire : nous ajoutons à Decider un nouveau jeton spécial, <|locate|>, une tête d’empan et un adaptateur LoRA.

Nous initialisons le plongement de <|locate|> à partir de celui de <|marker|> appris lors des étapes d’entraînement précédentes. Nous n’entraînons que ce nouveau plongement, la tête d’empan et les adaptateurs LoRA, tout en gardant figés les poids d’origine de l’architecture de base et la tête de décision. Chaque champ demandé reçoit son propre jeton <|locate|>.

La tête de segments utilise la représentation de <|locate|> conjointement avec les représentations des jetons d'état pour évaluer où les segments correspondants commencent et se terminent, et quelles paires début-fin vont ensemble. Elle utilise également la représentation du jeton <|locate|> pour prédire des seuils propres à chaque champ pour ces scores. Les segments sélectionnés sont renvoyés sous forme de positions de caractères dans le texte original.

Nous entraînons la tête de segments avec une perte InfoNCE adaptée qui pousse chaque segment de référence au-dessus du seuil, et le seuil au-dessus de tous les autres segments. La perte comporte deux termes : le premier pousse les scores des segments corrects au-dessus du seuil et des segments incorrects. Le second pousse le seuil au-dessus des scores des segments incorrects. Les champs sans réponse ne reçoivent que le second terme, ce qui apprend au modèle à renvoyer une liste vide.

Nous entraînons le modèle sur un mélange de tâches d’extraction d’empans, dont la reconnaissance d’entités nommées, la détection des PII et les questions-réponses extractives. Nous varions les descriptions de champs, des étiquettes courtes aux consignes détaillées, afin que le modèle apprenne à suivre la requête plutôt qu’à mémoriser un ensemble fixe d’étiquettes.

Locate enseigne au modèle une tâche structurellement différente, et nous voulons l'ajouter sans perdre ce que le modèle fait déjà bien. La fusion des adaptateurs Locate dans le modèle sous-jacent entraîne une certaine régression sur les requêtes de décision. Pour la limiter, nous menons des recherches, par exemple sur l'ajout de données de rejeu provenant d'étapes antérieures et sur des objectifs auxiliaires qui maintiennent les sorties du modèle sur les requêtes de décision proches de celles du modèle original. Toutefois, nous constatons que la fusion n'est toujours pas sans perte; nous gardons donc les adaptateurs non fusionnés et ne les activons que pour les requêtes Locate.

Évaluation

Nous évaluons Decider v1.3 et Decider Flash v1.3 sur des bancs d'essai externes tirés du Hugging Face Decision Index, de ClaimBench de Vals AI et de l'Artificial Analysis Decision Index.

Dans l'ensemble de ces évaluations, nos modèles affichent d'excellentes performances. Même si ces classements comprennent des tâches privées, ils peuvent tout de même être manipulés au moyen de soumissions répétées et d'ajustements itératifs fondés sur les résultats du classement. Pour compléter ces classements, nous évaluons les modèles sur une suite interne combinant des tâches de production privées et des évaluations réservées tirées de jeux de données publics qui ne sont pas des bancs d'essai. Ces évaluations offrent une vérification supplémentaire de la généralisation au-delà des bancs d'essai publics, ce qui nous aide à distinguer les améliorations plus larges des gains propres à des suites d'évaluation familières.

À l’interne, nous avons conçu une suite de plus de 200 tâches couvrant divers domaines et types de tâches, comme la classification, la notation, le reclassement et l’extraction d’entités. Pour évaluer honnêtement la performance réelle de Decider, toutes les évaluations sont effectuées en mode zero-shot, sans réglage fin propre à une tâche, ce qui nous indique clairement où améliorer le modèle.

Classification des requêtes

Chez Perplexity, nous utilisons un système de classification à têtes multiples pour traiter chaque requête d’utilisateur. Chaque requête passe d’abord par un modèle de plongement qui joue le rôle d’extracteur de caractéristiques. Le plongement obtenu est ensuite transmis à plusieurs têtes de classification distinctes, dont des classificateurs binaires et multiétiquettes. Par exemple, une tête détermine si une requête d’utilisateur doit déclencher une recherche sur le Web.

Sur 63 tâches de classification dont les références ont été réétiquetées de façon indépendante par un LLM de pointe, Decider v1.3 atteint une exactitude moyenne de 91,6 %, dépassant nos classificateurs de production de 6,54 points de pourcentage. Decider Flash v1.3 surpasse aussi la référence de production, tandis que Decider v1.3 surpasse Jev 1.14.

Agrandir

Classification spécialisée par domaine

Nous avons constitué, à partir de jeux de données publics, une suite d’évaluation spécialisée par domaine pour mesurer la performance de classification des modèles de décision dans sept domaines : vérification d’affirmations (6 tâches), soins de santé (7), cybersécurité (8), programmation (16), administration publique (7), droit (9) et finance (9).

Par exemple, « juger la complexité temporelle d’un programme Python » ou « utiliser un rapport financier annuel pour déterminer si la trésorerie non affectée d’une entreprise couvre le capital de la dette exigible au cours des douze prochains mois ». Decider v1.3 arrive en tête dans les sept domaines et surpasse Jev 1.14 avec un écart allant jusqu’à 12,9 points de pourcentage en finance et 9,3 points en droit. Decider Flash v1.3 se classe derrière Jev 1.14 en finance, en programmation et en droit, et obtient des résultats semblables dans les autres domaines.

Agrandir

Récupération et reclassement

La recherche est au cœur de Perplexity. Nous maintenons une vaste suite de tâches de récupération pour évaluer la performance de reclassement de nos modèles. Pour chaque tâche, nous utilisons d’abord un ensemble de modèles de plongement pour récupérer les 50 meilleurs documents candidats de chaque corpus. Nous reclassons ensuite ces candidats à l’aide de Decider et comparons sa performance à celle d’un solide modèle de reclassement de référence, Qwen3-Reranker-8B.

Nous évaluons Decider en mode zero-shot et ponctuel (pointwise), en utilisant le modèle pour noter directement et indépendamment chaque paire requête–document, puis classer les documents selon leur pertinence. Sur 72 tâches de récupération, Decider v1.3 obtient un nDCG@10 moyen de 83,99, surpassant Qwen3-Reranker-8B de 1,81 point et Jev 1.14 de 2,24 points.

Sur le banc d’essai BEIR, les deux modèles surpassent Qwen3-Reranker-8B de 8,78 et 7,05 points de nDCG@10 respectivement. Face à Jev 1.14, Decider v1.3 obtient 1,33 point de plus, tandis que la version Flash obtient 0,4 point de moins.

Agrandir

Classification multilingue

Pour évaluer les modèles de décision au-delà de l’anglais, nous avons constitué un banc d’essai de classification multilingue comprenant 19 tâches propres à une langue, issues de 8 jeux de données publics, avec 46 484 exemples dans huit langues : allemand, espagnol, français, italien, russe, japonais, coréen et chinois. Le banc d’essai couvre la détection d’intention, la classification thématique, l’analyse des sentiments, l’inférence en langage naturel, la détection de paraphrases, la détection de langage offensant et l’acceptabilité grammaticale.

Nous indiquons l’exactitude moyenne des tâches dans chaque langue, en accordant le même poids à chaque tâche. Decider v1.3 surpasse Jev 1.14 dans les huit langues, et Decider Flash v1.3 en fait autant dans six d’entre elles, avec des exactitudes moyennes par tâche de 88,16 % pour Decider v1.3 et de 86,50 % pour Decider Flash v1.3, contre 85,41 % pour Jev 1.14.

Agrandir

Reconnaissance d’entités nommées, PII et questions-réponses extractives

Nous évaluons la fonctionnalité locate sur 17 tâches hors domaine qui testent ses capacités d’extraction dans divers domaines, formats d’entrée (texte, tableaux, documents structurés) et types de consignes (étiquettes courtes, questions et descriptions détaillées). Les domaines vont de Wikipédia aux articles scientifiques, en passant par les rapports sur les cybermenaces, le soutien technique, les politiques de confidentialité, les CV et les contrats juridiques. Les requêtes vont de courts noms d’étiquettes comme « personne » ou « adresse courriel » à des descriptions de champs détaillées pour l’extraction structurée, comme les parties à une entente de confidentialité ou le total d’une facture, en passant par des questions sur un tableau ou un billet de soutien.

Nous évaluons la reconnaissance d'entités nommées (NER) et la détection des renseignements personnels (PII) à l'aide du score F1 sur segments exacts, qui exige que les segments prédits correspondent exactement aux limites de référence. Les questions-réponses extractives utilisent le score F1 au niveau des caractères, qui accorde un crédit partiel au texte de réponse qui se chevauche, tandis que l'extraction structurée utilise l'exactitude par champ, soit la proportion de champs extraits correctement. Pour l'analyse de CV, nous faisons la moyenne des scores F1 sur segments exacts de NER et de PII.

Nous comparons nos modèles à des modèles d’extraction polyvalents de différentes tailles : GLiNER large v2.5 (0,5 milliard de paramètres), Liquid d1 (2 milliards) et Clairic de Cloudflare (taille non divulguée). Decider v1.3 atteint un score moyen de 69,0 (selon la métrique principale de chaque tâche) et Decider Flash v1.3 atteint 63,6, contre 43,3 pour Liquid d1, 41,5 pour Clairic et 33,6 pour GLiNER large v2.5. Les deux modèles Decider arrivent en tête dans chaque catégorie.

Agrandir

Classification d'images

Decider prend en charge nativement les tâches visuelles depuis la v1. Pour évaluer sa performance au-delà du texte, nous avons constitué une suite de bancs d’essai de cinq tâches, axée en particulier sur la classification de documents, dont des factures, des lettres et des CV. La suite couvre aussi la classification d’images satellites, la classification de textures, la classification de races d’animaux de compagnie et le dénombrement d’animaux.

Decider v1.3 atteint une exactitude moyenne de 76,99 % sur les cinq tâches visuelles, surpassant Jev 1.14 de 1,47 point de pourcentage. Decider Flash v1.3 atteint 72,77 %, ce qui démontre des capacités de classification visuelle dans un modèle plus petit.

Agrandir

Requêtes de décision réelles

Nous avons échantillonné un million de requêtes dédupliquées, dont les PII avaient été masquées, soumises à la Perplexity Decision API au cours de ses 18 premiers jours de disponibilité. Comme chaque requête peut contenir plusieurs questions sur le même état, l’échantillon compte 2 318 887 questions individuelles. Toutes les requêtes ont été incluses avec l’autorisation explicite des utilisateurs à des fins de recherche.

Les requêtes de production ne sont pas accompagnées d’étiquettes de vérité terrain; nous utilisons donc des LLM de pointe comme juges pour générer des réponses de référence et mesurer le degré d’accord de chaque modèle avec celles-ci. Nous regroupons également les requêtes en 10 catégories de tâches, dont l’extraction d’informations, la classification par domaine, l’analyse des sentiments, l’intention et le routage, le classement par pertinence, la modération de contenu, l’examen de la qualité et de la conformité, l’appariement d’entités, l’analyse d’affaires et une catégorie « Autre ». Cette répartition montre comment la performance varie selon les cas d’utilisation réels.

La répartition des tâches est inégale : l’extraction d’informations représente 425 402 questions, la classification par domaine 409 564 et l’analyse des sentiments 344 158. Ensemble, ces trois catégories constituent 50,8 % des questions échantillonnées.

Decider v1.3 obtient le plus haut taux d’accord avec les juges, soit 93,98 %, contre 93,68 % pour Decider v1.2 et 93,35 % pour Jev 1.14. Decider v1.3 et Jev 1.14 sont au coude-à-coude en classification par domaine et en analyse des sentiments, avec des écarts respectifs de 0,34 et 0,07 point de pourcentage. Jev devance de 0,69 point en classement par pertinence, tandis que Decider v1.3 devance de 0,93 point en extraction d’informations (la tâche la plus courante de l’échantillon) et de 1,21 point en intention et routage.

Agrandir

Le graphique ci-dessous compare le coût déclaré de l’exécution du même million de requêtes de production. Chaque requête pouvant contenir plusieurs questions, l’unité utilisée ici est la requête, et non la question individuelle.

Agrandir

Robustesse

Nous avons évalué la sensibilité aux étiquettes sur 372 questions à choix multiples, en envoyant 4 788 requêtes par modèle. Nous avons réordonné les options, réattribué les étiquettes aux textes de réponse et renommé les étiquettes tout en préservant le sens de chaque question, puis vérifié si la réponse sémantique du modèle changeait. Des taux de bascule plus faibles indiquent une plus grande stabilité.

Decider v1.3 n’a modifié sa réponse que pour 0,27 % des questions sous chaque transformation, contre 2,69 à 4,84 % pour Jev 1.14. Nous avons aussi répété des entrées identiques pour mesurer la variabilité du service : Decider v1.3 n’a montré aucun changement, tandis que Jev 1.14 a changé de réponse pour 1,88 % des questions.

Agrandir

Comment nous utilisons Decider

Decider est conçu pour les flux de travail qui exigent des décisions rapides et structurées. Dans cette section, nous examinons comment en tirer parti pour avoir un effet concret sur notre façon de travailler. Voici quelques cas qui se démarquent.

Règles de sécurité qui s’améliorent d’elles-mêmes

À l'interne, nous utilisons déjà Decider pour améliorer nos politiques de sécurité.

L’activité de nos agents est enregistrée et une série de vérifications fondées sur des règles est effectuée afin de repérer tout comportement problématique. Une approche fondée sur des règles nous permet de surveiller nos agents en temps réel en n’ajoutant qu’une latence négligeable. Hors ligne, nous utilisons Decider pour examiner des échantillons de ces journaux d’agents. Si aucun comportement problématique n’a été signalé, Decider vérifie si notre ensemble de règles a manqué quelque chose; si une alerte a été déclenchée, Decider vérifie s’il s’agissait d’une fausse alerte. Tout enregistrement pour lequel notre ensemble de règles échoue, dans l’un ou l’autre cas, est envoyé à un agent pour triage, et une correction des règles est proposée, puis soumise à l’approbation d’un membre de notre équipe de sécurité.

En une journée, Decider a lu 1 milliard de jetons dans 7 000 sessions d’agents et relevé des failles qui ont mené à 14 corrections de règles, dont 6 ont été approuvées et déployées en deux jours. Rejouées sur une semaine de journaux, les corrections ont réduit de 52 % le volume de notre règle la plus sollicitée, et les règles élargies ont détecté environ 40 % d’actions légitimes de plus à examiner.

Agrandir

Surveillance des trajectoires d’apprentissage par renforcement

Lorsque nous post-entraînons des modèles par apprentissage par renforcement, les métriques agrégées comme une récompense finale n’expliquent pas pourquoi une trajectoire (ou rollout, c’est-à-dire une tentative individuelle d’accomplir une tâche) a réussi ou échoué. Elle peut perdre injustement une récompense parce qu’un service d’outil ou le bac à sable a échoué, ou recevoir une récompense imméritée si l’évaluateur laisse passer une affirmation non étayée, comme une valeur inventée qu’aucun outil n’a renvoyée.

Nous utilisons Decider pour surveiller les trajectoires dans ces cas. Du code repère d’abord les parties d’une trajectoire qui méritent un examen plus attentif : un appel d’outil échoué et le raisonnement qui l’entoure, du code exécuté sans erreur ou la réponse finale. Decider répond ensuite à des questions à choix multiples sur chaque partie, par exemple ce qui a échoué lors d’une étape (un service d’outil, un site externe, le bac à sable, le harness ou le code de l’agent lui-même) et si l’agent a correctement interprété le résultat. Nous regroupons toutes les questions portant sur une partie donnée dans une seule requête et stockons les probabilités plutôt qu’un verdict, ce qui nous permet d’ajuster les seuils plus tard sans interroger Decider de nouveau. Le moniteur ne fait qu’observer et diagnostiquer : il ne modifie jamais une récompense et n’interrompt jamais une exécution.

Agrandir

Filtrage selon la qualité des pages

Lorsque nous explorons des pages Web pour les indexer et les présenter aux utilisateurs, beaucoup d’entre elles sont de trop faible qualité pour être utiles. Cela comprend les barrières antirobots, les CAPTCHA et les pages d’erreur, ainsi que des pages Web correctement chargées qui ne contiennent tout simplement aucune information utile, comme le contenu indésirable, le remplissage pour le référencement (SEO) ou les pages qui ne servent qu’à la navigation. Ces pages de faible qualité doivent être repérées et filtrées de notre index.

Grâce à Decider, nous pouvons juger de la qualité des pages au fur et à mesure que nous les explorons. Dans la même passe avant, nous effectuons une série d'autres tâches de classification, comme l'identification du domaine et du public cible du contenu, et la détection de renseignements préjudiciables, illégaux ou permettant d'identifier une personne. Comparativement à un LLM utilisé comme juge, Decider est considérablement plus rapide et moins coûteux.

Agrandir

Au-delà de ces usages internes, Decider convient aussi à des flux de travail comme les suivants.

Assurance qualité visuelle

Comme Decider lit les images, il sert aussi de vérificateur visuel, en examinant les changements de style apportés aux pages Web ou aux applications et en repérant les défauts. Il peut examiner des captures d’écran de pages pour y déceler du texte tronqué, des éléments qui se chevauchent ou des mises en page brisées avant le déploiement d’un changement, ou encore signaler les graphiques dont la conception pourrait induire un lecteur en erreur ou enfreindre une charte graphique.

Agrandir

Navigation dans le navigateur

Les agents peuvent utiliser Decider pour les petites décisions au sein de tâches plus vastes. Un agent de navigateur peut envoyer une capture d’écran à chaque étape et recevoir des informations détaillées sur l’état de la page et le résultat attendu de chaque action possible.

Agrandir

Planification des tâches de recherche

La complexité des questions des utilisateurs peut varier considérablement, tout comme la profondeur de la recherche nécessaire pour trouver une réponse. Decider peut l'estimer avant le début de la recherche, ce qui permet de consacrer moins de ressources aux questions simples.

Agrandir

Pour commencer

Decider renvoie des probabilités. Le seuil de décision approprié dépend de l’application. La fréquence des étiquettes et les coûts relatifs des faux positifs et des faux négatifs varient selon les cas d’utilisation. Nous encourageons donc les utilisateurs à ajuster les seuils sur un petit ensemble de développement étiqueté et représentatif plutôt que de supposer qu’un seuil fixe fonctionnera aussi bien pour toutes les tâches.

Nous recommandons d'utiliser Decider v1.3 pour les jugements nuancés, les grilles d'évaluation détaillées et les flux de travail où les erreurs coûtent cher. Choisissez Decider Flash v1.3 pour le routage, l'étiquetage et le filtrage à grand volume, lorsque la latence et le coût sont les principales contraintes. Évaluez les deux modèles sur des exemples représentatifs de votre charge de travail, puis choisissez celui qui répond à vos exigences en matière de qualité, de latence et de budget.

Les deux modèles sont offerts sous forme de poids téléchargeables sur Hugging Face sous licence Apache, par l’intermédiaire d’OpenRouter et de la Perplexity Decisions API.

Citation

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