Perplexity ajoute l’ancrage au Web en temps réel à son API de décisions

Perplexity a annoncé le 4 novembre 2026 que l’ancrage au Web était immédiatement disponible pour son API de décisions, avec la possibilité d’effectuer des recherches en direct sur le Web avant que le modèle ne renvoie ses probabilités. Cette fonctionnalité vise les décisions dont les réponses peuvent changer après l’entraînement, par exemple le poste de direction occupé par une personne, la dernière version d’un logiciel ou le maintien d’un événement au calendrier.

L’API Decisions accepte du contenu sous forme de state et renvoie des réponses numériques structurées plutôt que du texte suivi. Une question fermée appelle une probabilité de réponse affirmative ; une question à choix produit une probabilité pour chaque option définie ; et une question de notation produit des probabilités réparties sur une grille ordonnée, ainsi qu’un score attendu. Les développeurs peuvent utiliser ces valeurs comme seuils pour la classification, le routage et d’autres décisions automatisées. L’état peut contenir du texte, du JSON ou des images, et le lancement permet également de fournir une URL qui dirige le modèle vers une page précise.

Recherche en direct avant la réponse du modèle

Le réglage mode sur web_grounding active Fast Search dans la passerelle API de Perplexity avant l’appel au modèle. La passerelle crée une requête par question à partir de la question et du début du texte de l’état, lance les recherches en parallèle, regroupe les résultats et supprime les URL en double. Les questions qui produisent la même requête partagent une recherche. La passerelle ajoute ensuite à l’état les titres des pages, les URL et leur texte à titre de preuves. Les réponses restent fondées sur des probabilités, tandis qu’un search_results champ permet aux développeurs d’examiner ce que le modèle a vu.

Les recherches sont soumises à des limites précises. Jusqu’à 10 peuvent être exécutées en parallèle, avec une limite d’une seconde par recherche et de trois secondes au total. Les images ne font pas l’objet de recherches. Les requêtes sont envoyées à l’API Perplexity Search et peuvent contenir à la fois le texte de la question et le début de l’état, ce qui fait des données transmises pour la recherche un élément à prendre en compte dans les considérations de confidentialité liées à l’intégration.

Les échecs de recherche n’interrompent pas nécessairement la réponse à une décision. Si seules certaines recherches aboutissent, le modèle utilise les résultats reçus. Si aucune n’aboutit, il répond à partir de l’état initial et renvoie un tableau search_results vide. Une réponse peut donc conserver sa structure habituelle même si aucune preuve en temps réel n’a contribué à son élaboration.

Gains de précision et différences de mesure

Perplexity a indiqué avoir testé le même modèle de décision sur 328 affirmations à vérifier par vrai ou faux, tirées de l’actualité d’octobre 2026 et de faits rares issus de Wikipédia. Chaque affirmation vraie était accompagnée d’une version fausse qui ne différait que sur un détail, et aucune preuve n’était fournie dans l’état. La précision était de 56,4 % sans ancrage et de 97,3 % avec ancrage, tandis que le nombre d’erreurs passait de 143 à neuf. La latence médiane a augmenté, passant de 139 ms à 366 ms, et celle au 95e percentile, de 514 ms à 742 ms : le gain de précision s’accompagne donc d’un coût mesurable en vitesse.

Parallel Web Systems a indiqué que son benchmark PWS-Decisions comprend 300 questions fermées : 100 publiques avec des réponses de référence et 200 privées. L’évaluation repose sur une correspondance exacte, et le jeu de questions a été constitué pour sa difficulté, plutôt que pour estimer la précision sur le trafic moyen. Le classement de Parallel indique la précision moyenne et l’écart-type de l’échantillon sur trois séries d’évaluations menées le 29 octobre 2026 ; Perplexity Decisions y affiche une précision de 51,00 % sur le jeu public.

Perplexity a indiqué que pplx-decider-v1.2 sa version avec ancrage au Web avait répondu correctement à 86 des 100 questions publiques lors d’une série d’évaluations menée le 4 novembre 2026, ce que l’entreprise a présenté comme la meilleure précision sur le jeu public parmi les résultats publiés dans ce classement. Son client a mesuré une latence médiane de 370 ms et une latence au 95e percentile de 685 ms sur ces 100 questions. Les mesures de latence distinctes de Parallel portent sur les réponses complètes obtenues au cours de trois séries d’évaluations couvrant l’ensemble des 300 questions ; les deux séries de chiffres de latence portent donc sur des périmètres différents.

Tarification et intégration

Une requête avec ancrage peut comprendre jusqu’à 100 questions. Chaque recherche menée à terme coûte 0,001 $, ce qui plafonne les frais de recherche à 0,10 $ pour une requête de 100 questions. Les preuves récupérées sont toutefois également facturées comme jetons d’entrée et comptabilisées dans la limite de 256 K jetons d’entrée. Le modèle standard pplx-decider-v1.2 coûte 0,02 $ par million de jetons d’entrée et pplx-decider-flash-v1.2 coûte 0,01 $ par million ; les jetons de sortie sont gratuits.

Le regroupement des questions influe sur le montant final facturé en jetons. Avec le modèle standard, les preuves sont comptabilisées de nouveau lorsque les limites d’entrée obligent à répartir les questions en groupes distincts. Flash évalue chaque question indépendamment et facture de nouveau l’état et les preuves à chaque fois. Le coût de l’ancrage dépend donc du nombre de recherches, du volume de texte récupéré et de la manière dont le modèle sélectionné regroupe les questions.

L’intégration présente actuellement une réserve concernant le typage. La bibliothèque Python 0.44.0 ou ultérieure de Perplexity et son SDK TypeScript 0.39.0 ou ultérieur prennent en charge l’API, mais leurs types n’exposent pas encore mode ni search_resultsPython transmet le mode via extra_bodytandis que TypeScript l’envoie dans le corps de la requête.

Les cas d’usage suggérés par Perplexity comprennent la vérification que des comptes ont levé des fonds au cours des 90 derniers jours, le suivi des dépendances afin de repérer les versions stables plus récentes qu’une version épinglée, ainsi que la confirmation qu’un événement est toujours prévu avant qu’un agent ne le réserve. Dans ces processus, l’ancrage ajoute des éléments probants actuels et vérifiables à une probabilité que le logiciel peut comparer à un seuil ou examiner. Le compromis ne concerne pas seulement la précision : la latence, l’utilisation de jetons, les frais de recherche et tout élément probant manquant dans search_results tous ces éléments façonnent ce que représente la probabilité renvoyée.