Améliorations de tous les niveaux d’effort de l’Agent API

Les niveaux d’effort de l’Agent API de Perplexity permettent aux développeurs de choisir l’équilibre entre coût, vitesse et profondeur de recherche pour chaque tâche. Dès aujourd’hui, chaque niveau d’effort coûte moins cher par requête, avec une qualité de recherche supérieure ou inchangée. Un nouveau niveau ultra est disponible pour les recherches les plus vastes et les plus complètes. Toute requête qui sélectionne le niveau par son nom, par exemple effort="fast", obtient automatiquement la configuration mise à jour.

Concevoir un agent de recherche implique de trouver le bon équilibre entre coût, vitesse et profondeur pour chaque tâche. Les niveaux d’effort de l’Agent API prennent cette décision à la place de l’utilisateur. Chaque niveau est une configuration groupée qui définit le modèle, le budget d’étapes, les paramètres de recherche et les outils pour un type de tâche donné. Perplexity évalue et met à jour chaque niveau au fil du temps afin de fournir la meilleure recherche possible pour un coût égal ou inférieur à son coût actuel.

Ces gains proviennent de deux types de changements. Les budgets, la gestion du contexte et l’extraction ont réduit le coût de chaque exécution, tandis que les Skills, la sélection des modèles et les agents parallèles ont amélioré ou maintenu la qualité de la réponse.

Les performances de medium sont passées de 55 % à 77 % sur BrowseComp et DSQA, tandis que les coûts ont baissé de près de 90 %. BrowseComp et DSQA sont des benchmarks de recherche publics ; WANDR est le benchmark de Perplexity consacré aux tâches de recherche longues portant sur plusieurs entités. xhigh effectue des tâches agentiques telles que l’exécution de code dans un bac à sable, le maintien de longues boucles d’utilisation d’outils et le travail sur de nombreuses sources simultanément. xhigh a maintenu son score WANDR à 76,5 % pour environ 25 % du coût de la configuration d’août 2026.

Le coût de la recherche

Une requête de Recherche approfondie peut lancer des dizaines de recherches, lire des centaines de pages et vérifier des éléments probants avant de répondre. Chacune de ces actions ajoute des tokens au contexte et des dollars à la facture. Sans limites, un agent continue d’effectuer des actions qui augmentent le coût et encombrent le contexte sans améliorer la réponse. Cinq facteurs expliquent l’essentiel de ce coût :

• Allocation du budget. Les agents disposant d’un budget défini peuvent se retrouver à court d’étapes et terminer leur exécution prématurément, avant d’avoir finalisé leur tâche. À l’inverse, les agents sans budget fixe peuvent continuer à s’exécuter, générant des coûts sans améliorer la réponse finale.
• Surcharge de contexte. Les résultats de recherche et les pages récupérées contiennent les éléments probants, mais, sans contrôle, la fenêtre de contexte peut rapidement se remplir d’informations non pertinentes. Les fenêtres de contexte entraînent des coûts d’une étape à l’autre, et des fenêtres surchargées peuvent réduire les performances de l’agent.
• Sélection du flux de travail. Des tâches différentes nécessitent des approches différentes. La recherche d’un fait isolé, une question à plusieurs étapes et un large tour d’horizon des sources requièrent chacun un flux de travail différent. Livré à lui-même, un modèle choisit souvent un flux de travail inefficace. Détailler toutes les stratégies disponibles dans le prompt de l’agent ne résout pas le problème. Les instructions supplémentaires sont transportées sous forme de tokens à chaque étape, et le modèle suit chacune d’elles de moins en moins fidèlement au fil du temps.
• Sélection du modèle. Passer à un modèle plus grand n’apporte pas forcément une amélioration des performances à la hauteur du surcoût. Les nouveaux modèles arrivent accompagnés de gros titres et de scores de benchmarks publiés. Cependant, les gains sur les benchmarks peuvent être faussés par une contamination ou refléter un surapprentissage du modèle. Sans évaluation sur des tâches réelles, un changement de modèle peut augmenter les coûts sans améliorer la qualité.
• Mise à l’échelle multi-agents. Un agent seul peut rechercher, lire et raisonner sur un nombre limité de sources par exécution. Exécuter plusieurs agents en parallèle améliore la qualité sur les tâches les plus exigeantes, mais augmente aussi les coûts et introduit de la complexité si ce n’est pas géré correctement.

La résolution de chacun de ces défis a permis de réduire les coûts de chaque niveau d’effort sans diminuer les performances.

Maîtriser le budget de recherche

Chaque niveau d’effort dispose d’un budget de recherche fixe composé de trois éléments :

• Limites d’étapes : le nombre de tours que l’agent peut effectuer
• Appels d’outils : un plafond sur le nombre total d’appels d’outils dans une requête. Une seule étape peut lancer plusieurs appels vers plusieurs outils à la fois ; une limite d’étapes ne suffit donc pas à contrôler le nombre d’actions effectuées au sein d’une étape.
• Rappels de budget : des notifications périodiques indiquant combien d’étapes il reste, afin que l’agent puisse établir des priorités et se réserver de quoi rédiger la réponse au lieu d’épuiser son budget en pleine tâche.

Le budget est le compromis central : davantage d’étapes signifie de meilleures réponses, et chaque étape engendre des coûts. Avec openai/gpt-6-luna, faire passer la limite d’étapes de 1 à 15 porte la précision sur BrowseComp + DSQA de 41 % à 80 %, tandis que le coût par requête passe de 0,0017 $ à 0,0152 $, soit environ 9 fois le coût pour environ 2 fois le score.

Une limite d’étapes ne suffit pas à elle seule à contrôler le coût de la recherche. Avec le même budget de cinq étapes, openai/gpt-6.1-terra effectue plus d’appels d’outils que openai/gpt-6-luna, car les modèles plus performants ont tendance à lancer plusieurs appels en une seule étape. Les niveaux d’effort plafonnent à la fois les appels d’outils et les étapes. Pour ces modèles, le plafond d’appels d’outils compte autant que la limite d’étapes.

Chaque niveau d’effort ajuste ces limites, mais l’agent doit aussi savoir combien d’étapes et d’actions il lui reste pour traiter la requête. Sans cette information, il peut se retrouver à court d’étapes ou d’actions et être contraint de répondre avant la fin de la recherche. Le budget est indiqué au début de l’exécution, et des rappels arrivent à mesure que l’agent approche de ses limites, ce qui laisse le temps de vérifier et de livrer les résultats. Pour high, les rappels portent à la fois sur le budget d’étapes et sur le budget d’appels d’outils.

Deux agents, l’un avec un rappel de budget et l’autre sans, ont été testés sur une tâche BrowseComp consistant à identifier une série télévisée des années 1990 à partir de trois biographies d’acteurs. L’agent disposant d’un rappel a trouvé la bonne réponse en utilisant 13 des 40 étapes du budget. L’agent sans rappel de budget a utilisé les 40 étapes et n’a pas trouvé la bonne réponse. La boucle de cet agent s’est terminée de manière inattendue, et le modèle n’avait pas connaissance du budget de recherche restant. Les rappels aident les agents à rester concentrés et à hiérarchiser efficacement les ressources restantes.

Gestion du contexte

Compactage

Les tâches de recherche de longue durée remplissent la fenêtre de contexte du modèle de résultats de recherche, de pages récupérées et de notes intermédiaires. Une fois cette fenêtre pleine, l’agent doit cesser de travailler.

Le compactage permet aux longues exécutions de se poursuivre sans saturer la fenêtre de contexte. Lorsque le contexte dépasse un seuil, l’agent remplace le travail effectué jusque-là par un résumé plus court de ce qu’il a trouvé et de ce qu’il reste à faire, puis poursuit.

Le compactage conserve toujours trois éléments dans le contexte : le prompt système, la requête initiale et les Skills que l’agent a déjà chargés. Après chaque compactage, l’agent reçoit deux courtes instructions. La première est : « Continuez à travailler jusqu’à ce que la tâche soit terminée. » Elle empêche l’agent de considérer le résumé comme un point d’arrêt. La seconde indique à l’agent combien de compactages ont eu lieu, afin qu’il puisse planifier ses tâches de recherche restantes. Les longues exécutions gardent ainsi en vue l’objectif et le plan initiaux, et le coût des longues boucles diminue sans perte de qualité.

Ne récupérer que l’essentiel

Chaque page lue par l’agent s’ajoute à son contexte, et l’agent la transporte à chaque étape suivante. Une page web contient des informations sans rapport avec la question, comme la navigation, le texte standard et d’autres contenus.

Au lieu de transmettre une page entière à l’agent, fetch_url effectue d’abord une passe d’extraction. Le texte de la page est envoyé à un modèle plus petit, accompagné de la tâche en cours de l’agent. Le modèle ne renvoie que les passages pertinents, cités mot pour mot afin que l’agent puisse les référencer. Lors d’une évaluation, une page de 5 561 tokens a été réduite à 293 tokens, libérant de l’espace pour d’autres éléments de contexte pertinents.

L’utilisation de fetch_url avec extraction au niveau d’effort high a réduit d’environ 50 % le nombre de tokens d’entrée par requête. L’extraction a également amélioré les performances sur les benchmarks, atteignant 88,0 % pour 0,073 $ par requête, contre 83,5 % pour 0,094 $ sans extraction.

Recherche web ciblée

La recherche sur le web est au cœur de chaque requête de recherche d’un agent. Trois changements ont été apportés à la façon dont les agents effectuent leurs recherches :

• Plus de contexte par recherche : chaque recherche renvoie désormais jusqu’à 4 000 tokens de résultats, contre 2 000 auparavant. L’agent trouve plus vite ce dont il a besoin, ce qui réduit le nombre de recherches et le coût.

• Un nouveau moteur d’extraits : les résultats de recherche reçoivent des extraits mieux adaptés à la requête, afin que l’agent ne soit pas submergé de texte non pertinent.
• Fast Search : à 1,00 $ pour 1 000 requêtes, Fast Search réduit à la fois le coût et la latence de chaque appel de recherche.

L’équipe Perplexity Search améliore en continu la qualité de la récupération sur un large éventail de tâches. Les mises à jour récentes ont apporté des gains sur le code, la documentation pour les développeurs, les pages de référence, ainsi que les contenus juridiques et réglementaires.

Choisir le bon flux de travail

Certaines tâches nécessitent de nombreuses recherches exécutées en parallèle ; d’autres requièrent une lecture attentive de quelques longs documents.

Cependant, charger tous les flux de travail dans le prompt système de l’agent alourdit le contexte et peut faire baisser les performances du modèle sur des tâches simples. Les Skills sont donc organisés en arborescence avec divulgation progressive. Le modèle charge les Skills et instructions pertinents au fil de son travail, en laissant les informations sans rapport en dehors de son contexte. Chaque Skill ne coûte que son nom et sa description jusqu’à ce que le modèle décide qu’il correspond à la tâche et le charge ; les instructions complètes sont alors ajoutées au contexte, et le modèle suit le flux de travail prescrit.

Pour mesurer la contribution de chaque Skill, les Skills sont retirés un par un afin de comparer la qualité et le coût sur les tâches pour lesquelles l’agent de référence avait chargé ce Skill. Ces ablations montrent quels flux de travail aident l’agent et comment ils influent sur l’efficacité de la recherche.

Les exécutions du benchmark WANDR ci-dessous montrent des agents qui choisissent les bons flux de travail pour des tâches spécifiques. Les consignes wide-search et fanout ont été chargées pour chaque tâche, reflétant la nécessité d’examiner plusieurs entités. People-search n’a été chargé que pour 6 % des tâches, et uniquement lorsque les questions portaient sur des personnes.

Lors du test d’une autre tâche WANDR, l’agent a chargé le Skill people-search avec un modèle de fanout pour trouver des ingénieurs en inférence à Londres. Il a décliné 39 intitulés de poste en 117 requêtes, puis a fusionné les résultats du premier passage en 43 profils uniques à examiner plus en détail. Le Skill people-search a guidé l’agent tout au long de cette expansion sans ajouter de contexte non pertinent. L’extrait ci-dessous est adapté du script de l’agent ; les noms des fonctions utilitaires sont donnés à titre d’illustration.

La sauvegarde par points de contrôle est un autre flux de travail qui aide les agents sur les tâches de longue durée. Ce modèle est issu de la programmation par lots. Lorsqu’un script traite une longue liste, il écrit chaque résultat sur le disque dès qu’il l’obtient, au lieu de tout garder en mémoire jusqu’à la fin. Si le script plante ou rencontre des erreurs en cours de route, rien n’est perdu : l’exécution suivante lit ce qui a déjà été enregistré et reprend là où elle s’était arrêtée, en ne relançant que les éléments ayant échoué.

Dans une autre tâche WANDR, l’agent devait examiner les profils de 188 ingénieurs. Il a chargé le modèle de point de contrôle pour enregistrer chaque résultat au fur et à mesure. Le premier passage a extrait 160 profils mais a échoué sur 28. Lorsque l’agent a relancé le script, il a ignoré les profils déjà enregistrés et n’a retraité que les 28 restants. Sans le point de contrôle, un seul enregistrement défectueux aurait imposé de récupérer à nouveau les 188 profils.Extrait Python adapté ; pages d’entrée, instruction de sélection, schéma et imports omis ; les noms des fonctions utilitaires sont donnés à titre d’illustration.

Le point de contrôle enregistre les résultats réussis ; il ne lance pas de nouvelles tentatives. Inclure l’instruction et le schéma dans la clé garantit qu’une modification des critères de sélection déclenche un nouveau traitement.

Tous les tests n’ont pas entraîné de gains de qualité et d’efficacité. Le préchargement de tous les Skills dans l’agent avant le début de sa tâche a été évalué. Sur BrowseComp et DSQA, le préchargement a augmenté le coût de 13 %. Sur WANDR, où des trajectoires de recherche plus longues font du contenu récupéré une part plus importante des tokens d’entrée, le préchargement réduit également les scores. Ces résultats ont conforté le maintien de la divulgation progressive.

Sélection du modèle

À mesure que les capacités des modèles progressent, le meilleur modèle pour chaque niveau d’effort évolue également. Perplexity utilise une boucle de recherche automatisée qui surveille les annonces de nouveaux modèles et leur disponibilité. Les évaluations sont déclenchées dès qu’un modèle devient accessible.

Lorsqu’un nouveau modèle est publié, un agent automatisé le soumet au harness d’évaluation. Il fait varier l’effort de raisonnement, les budgets d’étapes et d’appels d’outils ainsi que les configurations d’outils, et note chaque exécution en termes de qualité et de coût par rapport aux niveaux d’effort actuels. Lorsqu’une exécution régresse, l’agent en recherche la cause, ajuste les paramètres et relance l’évaluation. Un candidat ne remplace le modèle actuel que s’il l’emporte en qualité pour un coût égal ou inférieur.

Les benchmarks publics sont utiles, mais leurs scores ne se vérifient pas toujours sur des tâches réelles. Par exemple, le graphique ci-dessous montre un modèle candidat qui a obtenu 13,3 points de plus que la référence sur BrowseComp, mais des résultats bien inférieurs aux références correspondantes sur des tâches de recherche internes en entreprise, juridiques et financières.

Mise à l’échelle multi-agents

Un agent seul ne peut couvrir qu’un nombre limité de sources en une seule boucle. Pour les tâches complexes, plusieurs agents travaillent en parallèle et se coordonnent, chacun prenant en charge une partie différente du problème.

L’agent principal est l’orchestrateur. Il appelle spawn_agent pour créer des agents enfants et confie à chacun une tâche précise et ciblée. Chaque agent enfant exécute sa propre boucle de recherche avec un contexte distinct, en utilisant son propre modèle, ses propres outils et son propre budget d’étapes. Les agents enfants transmettent leurs résultats au parent, qui peut confier à un enfant une nouvelle mission ou vérifier où il en est. L’orchestrateur et ses agents enfants échangent des messages pour partager des éléments probants, signaler les blocages et ajuster les prochaines étapes. À mesure que de nouvelles informations arrivent, l’orchestrateur affine les missions et, une fois le travail terminé, combine les résultats en une réponse unique.

L’Agent API prend en charge des rôles d’agent prédéfinis, et l’orchestrateur peut créer des agents enfants avec des instructions personnalisées.

Le niveau d’effort ultra exécute trois agents en parallèle sur une même tâche. Chaque agent étudie indépendamment l’intégralité de la tâche, ce qui produit des éléments probants différents. Un quatrième agent fusionne leurs conclusions, élimine les doublons et rédige la réponse finale.

Sur WANDR, ultra obtient un score de 85,9 % pour 21,71 $ par tâche. Il s’agit du score le plus élevé parmi les configurations testées.

Et ensuite ?

Les niveaux d’effort sont évalués et améliorés en continu. Le niveau choisi par les utilisateurs détermine la quantité de recherche consacrée à une tâche et son coût. Les budgets d’étapes et d’appels d’outils, accompagnés de rappels à mesure qu’ils s’épuisent, maintiennent les requêtes dans les limites du budget. Le compactage, l’extraction et de meilleurs extraits gardent le contexte centré sur les éléments probants. Les Skills adaptent le flux de travail à la tâche, et les agents parallèles étendent ce qu’une seule boucle peut couvrir. Une boucle d’évaluation automatisée n’adopte un nouveau modèle que s’il améliore la qualité de la recherche à coût égal.

Chaque niveau d’effort continuera d’évoluer à mesure que de nouveaux modèles et de nouvelles configurations feront leurs preuves lors des évaluations. Appeler un niveau par son nom permet de bénéficier automatiquement de ces améliorations ; épingler une version fige une configuration.

Essayez l’Agent API et comparez les niveaux d’effort sur vos propres charges de travail. Retrouvez le détail des niveaux d’effort dans notre documentation sur l’effort de l’Agent API.