Perplexity Decider

Nous publions Decider v1.3 et Decider Flash v1.3, les successeurs de nos précédents modèles de décision : 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 disponibles sur Hugging Face sous licence Apache, via OpenRouter et via 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 ordonnées, et renvoie des probabilités que les applications peuvent utiliser pour classer, router, ordonner et évaluer des entrées.

Les deux modèles v1.3 améliorent les performances 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 affinée. Nous introduisons é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 d’informations personnelles et de questions-réponses extractives.

Dans cet article, nous expliquons comment nous entraînons et évaluons Decider, et comment nous l’utilisons en interne chez Perplexity.

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

Un modèle de décision est un classifieur généraliste. 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 multiple : étiquettes multiclasses personnalisées.
• Score : niveaux ordonnés.

Les modèles de décision prennent en charge un large é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 : orientation des requêtes vers des modèles plus petits ou plus grands selon leur difficulté.
• Modération et sécurité : détection de contenus préjudiciables, d’hameçonnage et d’injections de prompt dans les sorties d’outils.
• Filtrage et étiquetage : organisation de grandes collections de contenus.
• Récupération et reclassement : notation des résultats de recherche selon leur pertinence.

Bon nombre de ces tâches étaient auparavant prises en charge 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 spécialisés. 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 token par token et permet de partager les calculs entre les questions. Contrairement aux classificateurs spécialisés, ils peuvent gérer de nouvelles tâches au moyen de prompts en langage naturel, une flexibilité acquise grâce à un entraînement sur des tâches variées dans un format de questions-réponses commun.

Entraînement

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

Nous construisons Decider en adaptant de solides backbones de LLM génératifs. Pour expliquer cette adaptation, nous décrivons d’abord la manière 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 token d’étiquette prédéfini comme A, B ou C. Un token 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, qui sont ensuite convertis en probabilités.

Agrandir

Nous initialisons la couche de sortie à partir du modèle de base, qui attribue normalement un score au token suivant sur l’ensemble du vocabulaire, et ne conservons que les lignes correspondant aux tokens d’options 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, car elles peuvent toutes être formulées sous forme de choix multiple.

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, mise en correspondance d’entités, modération, vérification des faits, notations, etc.) et convertissons chaque exemple au format unifié décrit ci-dessus : un état, une ou plusieurs questions, leurs options et une cible. La cible peut être l’unique option correcte si nous disposons d’étiquettes de référence, ou une distribution de probabilité sur les options.

Dans la v1.3, nous introduisons locate, qui extrait du texte 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 instruction comme « Extraire le nom de la ville où se situe le poste. » Le modèle renvoie le texte exact correspondant dans 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 poste exige une expérience de niveau senior et extraire les compétences requises.

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

Nos modèles reposent sur de solides backbones génératifs préentraînés, dont l’attention causale ne permet à chaque token de prêter attention qu’à lui-même et aux tokens qui le précèdent. Nos études d’ablation ont montré que rendre bidirectionnelles les couches à attention complète du backbone améliore les performances ; nous adoptons donc cette conception pour permettre à chaque token d’intégrer le contexte de l’ensemble de l’entrée.

L’attention bidirectionnelle introduit un autre choix de conception : comment l’état et les questions doivent-ils interagir ? Nous avons envisagé trois schémas d’attention, aux implications différentes en matière de performances, de stabilité des réponses et de 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 varier selon les autres questions posées.
• Questions isolées (v1.3) : l’état prête attention à toutes les questions, tandis que chaque question ne prête attention qu’à l’état et à ses propres tokens. Les questions peuvent toujours s’influencer indirectement via l’état partagé, mais les résultats sont plus stables.
• Mise en cache complète : l’état ne porte son attention que sur lui-même, tandis que chaque question porte son attention sur l’état et sur ses propres tokens. L’état est indépendant des questions et réutilisable d’une requête à l’autre, ce qui permet de tirer parti de la mise en cache des prompts. Nous ne l’utilisons pas par défaut, car permettre à l’état de voir les questions compte beaucoup pour plusieurs tâches, mais un léger fine-tuning suffit pour faire basculer un modèle vers ce mode.

Nous avons finalement choisi les questions isolées pour leurs bonnes performances 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, avec l’entropie croisée sur de vastes jeux de données, puis nous le distillons dans le modèle plus petit Qwen3.5-4B.

La première étape est un entraînement généraliste, au cours duquel nous effectuons un fine-tuning complet du modèle sur des corpus à grande échelle. À cette étape, nous n’acceptons que des données qui aident le modèle de manière générale et qui ne sont propres à aucun benchmark ; nous excluons donc toutes les partitions d’entraînement des benchmarks.

Une fois ce modèle généraliste entraîné, nous procédons à une deuxième étape, plus fine, à l’aide de LoRA. Les données utilisées lors de cette étape ciblent des domaines et des tâches spécifiques. Nous ajoutons des données lors de la deuxième étape plutôt que lors de 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 spécifiques. L’objectif est d’améliorer les performances tout en conservant les connaissances générales du backbone. Nous appliquons également une pondération lors de la fusion de LoRA dans le modèle de base, afin de contrôler plus précisément la dérive et de privilégier les métriques sur données réservées plutôt que les gains intra-domaine.

Enfin, nous ajoutons une étape spécifique à la vision. Comme la deuxième étape, l’étape de vision est traitée comme une étape de spécialisation fine supplémentaire, à l’aide d’un adaptateur LoRA réintégré au modèle de base avec une pondération. Certaines capacités visuelles peuvent se faire au détriment des performances textuelles. Comme nous observons une utilisation bien plus importante des modèles sur du texte, nous privilégions les métriques textuelles par rapport aux métriques visuelles.

Pour les deux étapes textuelles, nous utilisons la moyenne des poids issus de trois exécutions, chacune avec une graine aléatoire différente. Nous avons constaté que cela améliore les performances 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. Si l’entropie croisée obtient de meilleurs résultats sur les benchmarks disposant de données d’entraînement dédiées, elle 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 alternatives autres que la référence, tandis que l’entropie croisée favorise le surapprentissage de la distribution d’entraînement propre à chaque benchmark. Nous adoptons donc l’objectif de distillation fondé sur la divergence KL.

Pour limiter la contamination entre entraînement et test, nous supprimons tous les échantillons d’entraînement susceptibles de recouper l’une des évaluations que nous utilisons. C’est important, car certains jeux de données d’entraînement publics contiennent de larges portions de certains jeux de données d’évaluation. Nous menons également des audits approfondis des biais et procédons à leur élimination afin de nous assurer que nos gains sont fiables et ne résultent pas simplement de biais appris.

Ajout de la capacité d’extraire des informations

La fonctionnalité locate extrait des informations telles que des entités nommées à partir d’un texte, sans modifier 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 token spécial, <|locate|>, une tête de span et un adaptateur LoRA.

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

La tête de segments utilise la représentation de <|locate|> conjointement avec les représentations des tokens d’état pour évaluer où commencent et se terminent les segments correspondants, et quelles paires début-fin vont ensemble. Elle utilise également la représentation du token <|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 d’origine.

Nous entraînons la tête de segments avec une perte InfoNCE adaptée qui place 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 ensemble de tâches d’extraction de spans, notamment la reconnaissance d’entités nommées, la détection de PII et les questions-réponses extractives. Nous faisons varier les descriptions de champs, des étiquettes courtes aux instructions 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 backbone entraîne une certaine régression sur les requêtes de décision. Pour la limiter, nous menons des recherches, notamment sur l’ajout de données de rejeu issues des étapes précédentes 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 d’origine. Cependant, nous constatons que la fusion n’est toujours pas sans perte à ce stade ; nous conservons 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 benchmarks externes issus du Hugging Face Decision Index, du ClaimBench de Vals AI et de l’Artificial Analysis Decision Index.

Sur l’ensemble de ces évaluations, nos modèles affichent de solides performances. Bien que ces classements incluent des tâches privées, ils peuvent tout de même être manipulés par des soumissions répétées et un ajustement itératif fondé sur les retours 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 sur données réservées issues de jeux de données publics hors benchmarks. Ces évaluations offrent une vérification supplémentaire de la généralisation au-delà des benchmarks publics, ce qui nous aide à distinguer les améliorations plus générales des gains propres à des suites d’évaluation familières.

En interne, nous avons constitué 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 les performances de Decider en conditions réelles, toutes les évaluations sont réalisées en zero-shot, sans fine-tuning spécifique à la 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 multi-têtes pour traiter chaque requête utilisateur. Chaque requête passe d’abord par un modèle d’embedding qui sert d’extracteur de caractéristiques. L’embedding obtenu est ensuite transmis à plusieurs têtes de classification distinctes, comprenant à la fois des classifieurs binaires et multi-étiquettes. Par exemple, une tête détermine si une requête utilisateur doit déclencher une recherche web.

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

Agrandir

Classification spécifique à un domaine

Nous avons constitué, à partir de jeux de données publics, une suite d’évaluation spécifique aux domaines afin de mesurer les performances de classification des modèles de décision dans sept domaines : vérification des affirmations (6 tâches), 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 principal de la dette exigible dans les douze prochains mois ». Decider v1.3 arrive en tête dans les sept domaines, avec une avance sur Jev 1.14 pouvant atteindre 12,9 points de pourcentage en finance et 9,3 points en droit. Decider Flash v1.3 se situe derrière Jev 1.14 en finance, en programmation et en droit, et obtient des performances similaires 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 les performances de reclassement de nos modèles. Pour chaque tâche, nous utilisons d’abord un ensemble de modèles d’embedding pour récupérer les 50 meilleurs documents candidats de chaque corpus. Nous reclassons ensuite ces candidats avec Decider et comparons ses performances à celles d’un reranker de référence performant, Qwen3-Reranker-8B.

Nous évaluons Decider en zero-shot et en mode pointwise, en utilisant le modèle pour noter directement et indépendamment chaque paire requête–document, puis classer les documents par pertinence. Sur 72 tâches de récupération, Decider v1.3 atteint 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 benchmark BEIR, les deux modèles surpassent Qwen3-Reranker-8B de respectivement 8,78 et 7,05 points de nDCG@10. 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 benchmark de classification multilingue comprenant 19 tâches propres à une langue, issues de 8 jeux de données publics, avec 46 484 exemples répartis sur huit langues : allemand, espagnol, français, italien, russe, japonais, coréen et chinois. Le benchmark 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 sur les tâches de 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 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

NER, PII et QA extractive

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 d’instructions (é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 support technique, les politiques de confidentialité, les CV et les contrats juridiques. Les requêtes vont de noms d’étiquettes courts comme « personne » ou « adresse e-mail » à des descriptions de champs détaillées pour l’extraction structurée, comme les parties à un accord de confidentialité (NDA) ou le total d’une facture, en passant par des questions sur un tableau ou un ticket de support.

Nous évaluons la NER et les PII à l’aide du F1 sur segment exact, qui exige que les segments prédits correspondent exactement aux limites de référence. Les questions-réponses extractives utilisent le F1 au niveau des caractères, qui accorde un crédit partiel lorsque le texte de la réponse se chevauche, tandis que l’extraction structurée utilise la précision par champ, c’est-à-dire la proportion de champs correctement extraits. Pour l’analyse de CV, nous faisons la moyenne des scores F1 sur segment exact de la NER et des PII.

Nous comparons nos modèles à des modèles d’extraction généralistes de différentes tailles : GLiNER large v2.5 (0,5 Md de paramètres), Liquid d1 (2 Md) et Clairic de Cloudflare (taille non communiqué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 toutes les catégories.

Agrandir

Classification d’images

Decider prend en charge nativement les tâches visuelles depuis la v1. Pour évaluer ses performances au-delà du texte, nous avons constitué une suite de benchmarks de cinq tâches, avec un accent particulier sur la classification de documents, notamment des factures, des lettres et des CV. La suite couvre également la classification d’images satellite, la classification de textures, la classification de races d’animaux de compagnie et le comptage 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 en conditions réelles

Nous avons échantillonné un million de requêtes dédupliquées, dont les PII ont été masquées, soumises à la Perplexity Decision API au cours de ses 18 premiers jours de disponibilité. Chaque requête pouvant contenir plusieurs questions sur le même état, l’échantillon comprend 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 taux d’accord de chaque modèle avec celles-ci. Nous regroupons également les requêtes en 10 catégories de tâches : extraction d’informations, classification par domaine, analyse des sentiments, intention et routage, classement par pertinence, modération de contenu, contrôle de qualité et de conformité, mise en correspondance d’entités, analyse commerciale et une catégorie « Autre ». Cette répartition montre comment les performances varient selon les cas d’usage 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 représentent 50,8 % des questions échantillonnées.

Decider v1.3 obtient le taux d’accord le plus élevé avec les juges, à 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 mène de 0,69 point en classement par pertinence, tandis que Decider v1.3 mène 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é du traitement 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, soit 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 également répété des entrées identiques pour mesurer la variabilité du service : Decider v1.3 n’a présenté 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 nécessitent des décisions rapides et structurées. Dans cette section, nous voyons comment en tirer parti pour transformer concrètement notre façon de travailler. Voici quelques cas qui se distinguent.

Règles de sécurité auto-améliorantes

En 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 contrôles fondés sur des règles est effectuée pour repérer tout comportement problématique. Une approche fondée sur des règles nous permet de surveiller nos agents en temps réel avec une latence supplémentaire négligeable. Hors ligne, nous utilisons Decider pour examiner des échantillons de ces journaux d’agents enregistrés. Si aucun comportement problématique n’a été signalé, Decider vérifie si quelque chose a échappé à nos règles ; si une alerte a été déclenchée, Decider vérifie s’il s’agissait d’une fausse alerte. Tous les enregistrements pour lesquels notre ensemble de règles échoue, dans l’un ou l’autre cas, sont transmis à 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 tokens issus de 7 000 sessions d’agents et identifié des failles ayant donné lieu à 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, ces corrections ont réduit de 52 % le volume de notre règle la plus sollicitée, et les règles élargies ont repéré environ 40 % d’actions légitimes supplémentaires à examiner.

Agrandir

Surveillance des rollouts de RL

Lorsque nous post-entraînons des modèles par apprentissage par renforcement, les métriques agrégées comme une récompense terminale n’expliquent pas pourquoi un rollout (une tentative individuelle de réalisation d’une tâche) a réussi ou échoué. Il peut perdre de la récompense injustement 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 rollouts dans ces cas. Du code identifie d’abord les parties d’un rollout qui méritent un examen plus attentif : un appel d’outil ayant échoué et le raisonnement qui l’entoure, du code qui s’est 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 propre code de l’agent) 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 ultérieurement sans interroger à nouveau Decider. Le moniteur se contente d’observer et de diagnostiquer : il ne modifie jamais une récompense et n’interrompt jamais une exécution.

Agrandir

Filtrage de la qualité des pages

Lorsque nous explorons des pages web pour les indexer et les proposer aux utilisateurs, beaucoup sont de trop faible qualité pour être utiles. Cela inclut les murs anti-bots, les CAPTCHA et les pages d’erreur, mais aussi des pages correctement chargées qui ne contiennent simplement aucune information utile, comme le spam, le remplissage SEO ou les pages de navigation pure. Ces pages de faible qualité doivent être identifiées et exclues de notre index.

Grâce à Decider, nous pouvons juger de la qualité des pages au fur et à mesure que nous les explorons. Au cours de la même passe avant, nous effectuons une série d’autres tâches de classification, comme l’identification du domaine et du public visé par le contenu, ou encore la détection d’informations préjudiciables, illégales ou permettant d’identifier une personne. Par rapport à l’utilisation d’un LLM comme juge, Decider est considérablement plus rapide et moins coûteux.

Agrandir

Au-delà de ces usages internes, Decider convient également à des flux de travail comme ceux qui suivent.

Questions-réponses visuelles

Comme Decider lit les images, il sert aussi de vérificateur visuel : il examine les modifications de style apportées à des pages web ou à des applications et identifie les défauts. Il peut analyser des captures d’écran de pages pour repérer du texte tronqué, des éléments qui se chevauchent ou des mises en page cassées avant la mise en production d’une modification, ou signaler des graphiques dont la conception pourrait induire le lecteur en erreur ou enfreindre une charte graphique.

Agrandir

Navigation web

Les agents peuvent utiliser Decider pour les petites décisions au sein de tâches plus vastes. Un agent de navigation 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’usage. 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 disponibles sous forme de poids téléchargeables sur Hugging Face sous licence Apache, via OpenRouter et via 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}
}