Perplexity lance les modèles Decider V1.3 avec extraction de segments de texte

Perplexity a lancé Decider v1.3 et Decider Flash v1.3 le 12 novembre 2026, avec l’ajout de l’extraction verbatim de segments de texte et de poids téléchargeables sous licence Apache-2.0. L’entreprise fait état d’une précision moyenne de 91,6 % pour le modèle le plus grand sur 63 tâches de classification de requêtes, dont les références ont été réétiquetées indépendamment par un grand modèle de langage de pointe, soit 6,54 points de pourcentage de plus que ses classificateurs en production.

La nouvelle fonctionnalité Locate renvoie le texte correspondant exact, avec les positions de début et de fin des caractères, pour la reconnaissance d’entités nommées, la détection d’informations personnelles et la réponse extractive aux questions ; en l’absence de correspondance, elle renvoie une liste vide. Les deux modèles sont également disponibles via OpenRouter et l’API de décisions de Perplexity.

Decider renvoie des probabilités pour des questions fermées (oui/non), des choix personnalisés ou des scores ordonnés, au lieu de générer du texte. Une application peut poser plusieurs questions sur le même texte, fichier JSON ou ensemble d’images, puis utiliser les nombres obtenus pour la classification, le routage des requêtes, la modération, le filtrage, l’évaluation des résultats et le reclassement. Ces tâches nécessitent souvent un seuil de décision plutôt qu’une génération libre.

Changements apportés à l’architecture et à l’entraînement

Decider adapte les modèles génératifs de base en remplaçant la prédiction du prochain jeton par une tête de décision lue au niveau d’un jeton marqueur. Cette tête est initialisée uniquement à partir des lignes du modèle de base associées aux jetons correspondant aux options de réponse. Dans v1.3, Perplexity rend bidirectionnelles les couches à attention complète et empêche les questions de porter directement attention les unes aux autres, tout en permettant à l’état d’entrée partagé de porter attention aux questions. Cette approche remplace celle de v1.2, dans laquelle une réponse pouvait varier en fonction des autres questions posées, et vise à stabiliser les réponses.

L’entraînement convertit des centaines de jeux de données publics dans un format commun comprenant un état, une question, des options et une cible. Le réglage fin généraliste exclut les partitions d’entraînement des benchmarks et, selon Perplexity, écarte également les échantillons susceptibles de chevaucher ses évaluations. Les spécialisations ultérieures par domaine et pour la vision utilisent LoRA, une méthode qui gèle les poids préentraînés tout en entraînant des matrices de décomposition de rang ajoutées au modèle. Perplexity utilise des fusions pondérées d’adaptateurs pour limiter la dérive et fait la moyenne des poids issus de trois exécutions pour les étapes consacrées au texte.

Flash est ensuite distillé à partir du modèle le plus grand. La divergence KL permet de réduire l’écart entre ses probabilités de sortie et celles du modèle enseignant, plutôt que de l’entraîner uniquement à partir d’étiquettes de référence. La fiche du modèle Decider v1.3 indique une architecture de base Qwen3.8-27B et environ 49 GiB de poids BF16 ; la fiche de Decider Flash v1.3 indique Qwen3.5-4B et environ 8,5 GiB. L’hébergement autonome de l’un ou l’autre modèle nécessite un GPU CUDA et de la mémoire vive supplémentaire au-delà de celle occupée par les poids, ce qui réduit l’empreinte matérielle de Flash.

Limites d’utilisation de Locate

Locate ne traite que le texte et accepte au maximum 128 questions par requête. Les requêtes combinant Locate et des questions de décision nécessitent une passe avant distincte pour chaque type, ce qui augmente la latence par rapport aux requêtes ne contenant qu’un seul type de question.

Perplexity ne fusionne pas les adaptateurs Locate, car leur fusion a entraîné une baisse des performances sur les requêtes de décision classiques ; ils ne sont activés que pour les requêtes Locate. Cette conception préserve le comportement décisionnel existant, mais les charges de travail mixtes ne peuvent pas partager entièrement les mêmes calculs.

Évaluation et utilisation en production

La suite d’évaluation interne de Perplexity comprend plus de 200 tâches et est exécutée en mode zéro-shot, sans réglage fin propre à chaque tâche. Elle complète les classements publics par des tâches privées issues de la production et des évaluations sur des jeux de données publics non utilisés comme benchmarks et mis de côté, afin de vérifier la capacité de généralisation au-delà des suites d’évaluation familières.

Sur 72 tâches de recherche d’information, l’entreprise fait état d’un nDCG@10 moyen de 83,99 pour le reclassement zéro-shot point par point, où chaque paire requête-document est évaluée indépendamment, soit 1,81 point de plus que Qwen3-Reranker-8B.

Pour un contrôle en production, Perplexity a échantillonné un million de requêtes API dédupliquées, après masquage des informations personnelles, parmi celles reçues pendant les 18 premiers jours de disponibilité de l’API. L’échantillon couvrait 2 318 887 questions individuelles, toutes incluses avec l’autorisation explicite des utilisateurs à des fins de recherche. Des modèles de langage de pointe ont servi de juges pour fournir les réponses de référence, car les requêtes de production ne disposent pas d’étiquettes de vérité terrain.

Perplexity indique que v1.3 concorde avec ces juges dans 93,98 % des cas, contre 93,68 % pour v1.2. L’écart est modeste, et cette mesure établit la concordance avec des références générées par des modèles plutôt que la précision par rapport à des étiquettes de vérité terrain.

Pour le même échantillon de requêtes, Perplexity fait état de coûts de 26,47 $ pour Decider v1.3 et de 13,24 $ pour Flash. Decider a été exécuté en local ; la comparaison ne précise pas la prise en compte du coût du matériel local et ne fournit pas de résultats de latence comparables. Ces chiffres décrivent donc cette charge de travail, et non un avantage universel en matière de coût ou de vitesse.

Perplexity utilise également Decider hors ligne pour examiner les journaux de sécurité des agents afin de repérer les problèmes non détectés et les fausses alertes. En une journée, selon un bilan publié, le système a traité 1 milliard de jetons sur 7 000 sessions d’agents et repéré des failles ayant conduit à proposer 14 modifications de règles, dont six ont été approuvées et déployées en deux jours. La relecture d’une semaine de journaux avec ces modifications a réduit de 52 % le volume de la règle la plus sollicitée, tandis que des règles élargies ont permis de détecter environ 40 % d’actions légitimes supplémentaires à examiner.

Un deuxième système interne stocke des probabilités concernant les échecs de l’apprentissage par renforcement et les interprétations des agents, ce qui permet de modifier les seuils sans envoyer de nouvelles requêtes à Decider. Il se contente d’observer et de diagnostiquer, sans jamais modifier les récompenses ni interrompre les exécutions. Decider filtre également les pages de faible qualité collectées par exploration, tout en évaluant, au cours de la même passe, le public visé, le domaine, la présence de contenu préjudiciable ou illégal et les informations personnelles.

Perplexity recommande de calibrer les seuils de décision à partir d’exemples représentatifs étiquetés, car la fréquence des étiquettes ainsi que le coût des faux positifs et des faux négatifs varient selon les applications. L’entreprise préconise le modèle complet pour les jugements nuancés où les erreurs coûtent cher, et Flash pour les tâches à grand volume soumises à des contraintes de latence et de coût.

La polyvalence de Decider implique donc des exigences supplémentaires pour son déploiement : les mêmes probabilités qui le rendent réutilisable pour différentes tâches nécessitent toujours des seuils propres à chaque application, et la capacité d’extraction supplémentaire de Locate entraîne un surcroît de calcul pour les requêtes mixtes.