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

Les niveaux d’effort de la Perplexity Agent API 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 offert pour les recherches les plus vastes et les plus exhaustives. Toute requête qui sélectionne le niveau par son nom, comme effort="fast", reçoit automatiquement la configuration mise à jour.

Créer un agent de recherche, c’est trouver le juste équilibre entre coût, vitesse et profondeur pour chaque tâche. Les niveaux d’effort de l’Agent API prennent cette décision pour 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 précis. Perplexity évalue et met à jour chaque niveau au fil du temps afin d’offrir la meilleure recherche possible à son coût actuel ou à un coût inférieur.

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 diminué de près de 90 %. BrowseComp et DSQA sont des bancs d’essai de recherche publics; WANDR est le banc d’essai de Perplexity composé de longues tâches de recherche portant sur plusieurs entités. xhigh effectue un travail agentique, comme 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 à la fois. xhigh a maintenu son score WANDR à 76,5 % tout en fonctionnant à environ 25 % du coût de la configuration d’août 2026.

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 jetons 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 :

Répartition du budget. Les agents dotés d’un budget fixe peuvent manquer 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 de s’exécuter et engendrer 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 transportent leurs 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 exigent des approches différentes. La recherche d’un fait unique, une question à sauts multiples et un vaste survol des sources exigent chacun un flux de travail différent. Laissé à lui-même, un modèle en choisit souvent un inefficace. Détailler chaque stratégie disponible dans le prompt de l’agent ne règle pas ce problème. Les instructions supplémentaires sont transportées sous forme de jetons à chaque étape, et le modèle suit chacune d’elles de manière de moins en moins fiable au fil du temps.
Sélection du modèle. Passer à un modèle plus grand n’apporte pas nécessairement une amélioration des performances à la hauteur du coût supplémentaire. Les nouveaux modèles arrivent accompagnés de gros titres et de scores publiés aux bancs d’essai. Cependant, les gains aux bancs d’essai peuvent être contaminés ou refléter un surajustement 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 multiagent. Un seul agent peut rechercher, lire et analyser un nombre limité de sources par exécution. L’exécution de plusieurs agents en parallèle améliore la qualité sur les tâches les plus exigeantes, mais elle augmente aussi les coûts et ajoute de la complexité si elle n’est pas bien gérée.

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

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 du nombre total d’appels d’outils dans une requête. Une seule étape peut émettre 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 avis périodiques indiquant le nombre d’étapes restantes, afin que l’agent puisse établir des priorités et garder de la marge pour rédiger la réponse plutôt que d’épuiser son budget en cours de tâche.

Le budget est le compromis central : plus d’étapes donnent 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 augmente 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 à émettre 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 répondre à la requête. Sans cette information, il peut manquer d’étapes ou d’actions et être forcé 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 couvrent à la fois le budget d’étapes et 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 de membres de la distribution. L’agent avec 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 sans trouver la bonne réponse. La boucle de cet agent s’est terminée de façon inattendue, et le modèle n’était pas conscient du budget de recherche restant. Les rappels aident les agents à rester concentrés et à prioriser efficacement les ressources restantes.

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.

La compaction permet aux longues exécutions de se poursuivre sans remplir la fenêtre de contexte. Lorsque le contexte dépasse un seuil, l’agent remplace le travail accompli jusqu’ici par un résumé plus court de ce qu’il a trouvé et de ce qui reste à faire, puis il poursuit.

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

Chaque page que lit 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 remettre 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 avec la tâche en cours de l’agent. Le modèle ne renvoie que les passages pertinents, reproduits textuellement afin que l’agent puisse les citer. Lors d’une évaluation, une page de 5 561 jetons a été réduite à 293 jetons, ce qui a libéré de l’espace pour d’autres éléments de contexte pertinents.

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

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 jetons de résultats au lieu de 2 000. L’agent trouve plus rapidement ce dont il a besoin, ce qui se traduit par moins de recherches et un coût moindre.

Un nouveau moteur d’extraits : les résultats de recherche reçoivent des extraits mieux adaptés à la requête, de sorte que l’agent n’est pas submergé de texte non pertinent.
Recherche rapide : à 1,00 $ par 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 continuellement la qualité de la récupération pour un large éventail de tâches. Les récentes mises à jour ont apporté des gains pour le code, la documentation pour développeurs, les pages de référence ainsi que le contenu juridique et réglementaire.

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

Cependant, charger chaque flux de travail dans le prompt système de l’agent alourdit le contexte et peut nuire aux performances du modèle sur des tâches simples. Les skills sont plutôt organisés en arborescence avec divulgation progressive. Le modèle charge les skills et les instructions pertinents au fil de son travail, en laissant les informations sans rapport hors de son contexte. Chaque skill ne coûte que son nom et sa description jusqu’à ce que le modèle décide qu’il convient à 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, on retire les skills 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 banc d’essai WANDR ci-dessous montrent des agents qui choisissent les bons flux de travail pour des tâches précises. Les directives wide-search et fanout ont été chargées pour chaque tâche, ce qui reflète la nécessité d’examiner plusieurs entités. Le skill people-search n’a été chargé que pour 6 % des tâches, et uniquement lorsque les questions portaient sur des personnes.

Lors d’une autre tâche WANDR, l’agent a chargé le skill people-search avec un motif 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 de la première passe 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 indicatif.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

Les points de contrôle constituent un autre flux de travail qui aide les agents dans les tâches de longue durée. Le motif des points de contrôle provient 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, plutôt que 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 qui ont échoué.

Dans une autre tâche WANDR, l’agent devait examiner les profils de 188 ingénieurs. Il a chargé le motif de point de contrôle pour enregistrer chaque résultat au fil de son travail. La première passe 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 relancé que les 28 restants. Sans le point de contrôle, un seul enregistrement défectueux aurait obligé à récupérer de nouveau les 188 profils.Extrait Python adapté; les pages d’entrée, l’instruction de sélection, le schéma et les importations sont omis; les noms des fonctions utilitaires sont donnés à titre indicatif.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

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

Les tests n’ont pas tous entraîné des 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 jetons d’entrée, le préchargement réduit aussi les scores. Ces résultats ont justifié le maintien de la divulgation progressive.

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

Lorsqu’un nouveau modèle est lancé, 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 selon la qualité et le coût par rapport aux niveaux d’effort actuels. Lorsqu’une exécution régresse, l’agent en cherche la cause, ajuste les paramètres et relance l’évaluation. Un candidat ne remplace le modèle actuel que s’il l’emporte sur le plan de la qualité à un coût égal ou inférieur.

Les bancs d’essai publics sont utiles, mais leurs scores ne se reflètent pas toujours dans les tâches concrètes. 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 internes de recherche en entreprise, en droit et en finance.

Un seul agent ne peut couvrir qu’un nombre limité de sources dans une même boucle. Pour les tâches complexes, plusieurs agents travaillent en parallèle et se coordonnent, chacun s’occupant d’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 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 enfants transmettent leurs résultats au parent, qui peut confier une tâche de suivi à un enfant ou vérifier sa progression. L’orchestrateur et ses enfants échangent des messages pour partager des éléments probants, signaler les obstacles et ajuster les prochaines étapes. À mesure que de nouvelles informations arrivent, l’orchestrateur affine les tâches confiées et, une fois le travail terminé, combine les résultats en une seule réponse.

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 tâche. Chaque agent explore indépendamment l’ensemble 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 % à 21,71 $ par tâche. Il s’agit du score le plus élevé parmi les configurations testées.

Les niveaux d’effort sont évalués et améliorés en continu. Le niveau choisi par l’utilisateur 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. La compaction, 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 élargissent 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 intègre automatiquement 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. Consultez les détails sur les niveaux d’effort dans notre documentation sur les niveaux d’effort de l’Agent API.

Le coût de la recherche

Contrôler le budget de recherche

Gérer le contexte

Compaction

Ne récupérer que l’essentiel

Recherche Web ciblée

Choisir le bon flux de travail

Sélection du modèle

Mise à l’échelle multiagent

La suite