Millores en tots els nivells d'esforç de l'Agent API

Els nivells d'esforç de la Perplexity Agent API permeten als desenvolupadors triar l'equilibri entre cost, velocitat i profunditat d'investigació per a cada tasca. Des d'avui, tots els nivells d'esforç costen menys per consulta, amb una qualitat d'investigació superior o igual. Hi ha disponible un nou nivell ultra per a la investigació més àmplia i exhaustiva. Qualsevol sol·licitud que seleccioni el nivell pel nom, com ara effort="fast", obté automàticament la configuració actualitzada.

Crear un agent d'investigació implica triar l'equilibri adequat entre cost, velocitat i profunditat per a cada tasca. Els nivells d'esforç de l'Agent API prenen aquesta decisió per l'usuari. Cada nivell és una configuració agrupada que defineix el model, el pressupost de passos, la configuració de cerca i les eines per a un tipus de tasca concret. Perplexity avalua i actualitza cada nivell al llarg del temps per oferir la millor investigació amb el seu cost actual o per sota d'aquest.

Aquestes millores van venir de dos tipus de canvis. Els pressupostos, la gestió del context i l'extracció van reduir el cost de cada execució, i les Skills, la selecció de models i els agents en paral·lel van augmentar o mantenir la qualitat de la resposta.

El rendiment de medium va millorar del 55 % al 77 % a BrowseComp i DSQA, mentre que els costos es van reduir gairebé un 90 %. BrowseComp i DSQA són benchmarks públics d'investigació; WANDR és el benchmark de Perplexity amb tasques d'investigació llargues i amb múltiples entitats. xhigh duu a terme treball agèntic, com ara executar codi en un entorn de proves, mantenir bucles llargs d'ús d'eines i treballar amb moltes fonts alhora. xhigh va mantenir la seva puntuació a WANDR en el 76,5 % amb un cost d'aproximadament el 25 % del de la configuració d'agost de 2026.

Una sol·licitud d'investigació profunda pot executar desenes de cerques, llegir centenars de pàgines i verificar proves abans de respondre. Cadascuna d'aquestes accions afegeix tokens al context i dòlars a la factura. Sense límits, un agent continua fent accions que augmenten el cost i saturen el context sense millorar la resposta. Cinc factors expliquen la major part d'aquest cost:

Assignació del pressupost. Els agents amb un pressupost establert es poden quedar sense passos i acabar l'execució abans d'enllestir la tasca. En canvi, els agents sense un pressupost fix poden continuar executant-se i generar costos sense millorar la resposta final.
Sobrecàrrega de context. Els resultats de cerca i les pàgines obtingudes aporten les proves, però, si no es controla, la finestra de context es pot omplir ràpidament d'informació irrellevant. Les finestres de context arrosseguen costos d'un pas a l'altre, i les finestres sobrecarregades poden reduir el rendiment de l'agent.
Selecció del flux de treball. Cada tasca necessita un enfocament diferent. Una consulta d'un sol fet, una pregunta de múltiples salts i una revisió àmplia de fonts requereixen cadascuna un flux de treball diferent. Si el model ha de triar pel seu compte, sovint n'escull un d'ineficient. Detallar totes les estratègies disponibles al prompt de l'agent no ho resol. Les instruccions addicionals es transporten com a tokens a cada pas, i amb el temps el model segueix cadascuna amb menys fiabilitat.
Selecció del model. Canviar a un model més gran pot no oferir una millora de rendiment proporcional al cost addicional. Els models nous arriben amb titulars i puntuacions de benchmarks publicades. Tanmateix, les millores en els benchmarks poden estar contaminades o reflectir un sobreajustament del model. Sense avaluar-los en tasques reals, un canvi de model pot augmentar els costos sense millorar la qualitat.
Escalat multiagent. Un sol agent pot cercar, llegir i raonar amb un nombre finit de fonts per execució. Executar diversos agents en paral·lel millora la qualitat en les tasques més exigents, però també augmenta els costos i introdueix complexitat si no es gestiona correctament.

Resoldre cadascun d'aquests reptes va reduir els costos de cada nivell d'esforç sense reduir-ne el rendiment.

Cada nivell d'esforç té un pressupost d'investigació fix amb tres components:

Límits de passos: el nombre de torns que pot fer l'agent
Crides a eines: un límit del nombre total de crides a eines en una sol·licitud. Un sol pas pot fer diverses crides a diverses eines alhora, de manera que un límit de passos per si sol no controla quantes accions es produeixen dins d'un pas.
Recordatoris de pressupost: avisos periòdics de quants passos queden, perquè l'agent pugui prioritzar i deixar marge per redactar la resposta en lloc de quedar-se sense pressupost a mitja tasca.

El pressupost és l'equilibri central: més passos signifiquen millors respostes, i cada pas genera costos. Amb openai/gpt-6-luna, augmentar el límit de passos d'1 a 15 eleva la precisió a BrowseComp + DSQA del 41 % al 80 %, mentre que el cost per consulta passa de 0,0017 $ a 0,0152 $: aproximadament 9 vegades el cost per aproximadament el doble de puntuació.

Un límit de passos per si sol no controla el cost de la investigació. Amb el mateix pressupost de cinc passos, openai/gpt-6.1-terra fa més crides a eines que openai/gpt-6-luna, perquè els models més capaços tendeixen a fer diverses crides en un sol pas. Els nivells d'esforç limiten tant les crides a eines com els passos. Per a aquests models, el límit de crides a eines és tan important com el límit de passos.

Cada nivell d'esforç ajusta aquests límits, però l'agent també ha de saber quants passos i accions li queden per completar la sol·licitud. Sense aquesta informació, es pot quedar sense passos o accions i veure's obligat a respondre abans que la investigació s'hagi completat. El pressupost s'indica al començament de l'execució, i els recordatoris arriben quan l'agent s'acosta als seus límits, de manera que queda marge per verificar i lliurar els resultats. En el nivell high, els recordatoris cobreixen tant el pressupost de passos com el de crides a eines.

Es van provar dos agents, un amb un recordatori de pressupost i un altre sense, en una tasca de BrowseComp que consistia a identificar una sèrie de televisió dels anys noranta a partir de tres biografies del repartiment. L'agent amb recordatori va trobar la resposta correcta fent servir 13 dels 40 passos del pressupost. L'agent sense recordatori de pressupost va utilitzar els 40 passos i no va trobar la resposta correcta. El bucle d'aquest agent va acabar de manera inesperada, i el model no era conscient del pressupost d'investigació que li quedava. Els recordatoris mantenen els agents centrats i els ajuden a prioritzar de manera eficaç els recursos restants.

Les tasques d'investigació de llarga durada omplen la finestra de context del model amb resultats de cerca, pàgines obtingudes i notes intermèdies. Un cop plena, l'agent ha de deixar de treballar.

La compactació permet que les execucions llargues continuïn funcionant sense omplir la finestra de context. Quan el context supera un llindar, l'agent substitueix la feina feta fins aleshores per un resum més breu del que ha trobat i del que queda per fer, i després continua.

La compactació sempre conserva tres elements en el context: el prompt del sistema, la sol·licitud original i qualsevol Skill que l'agent ja hagi carregat. Després de cada compactació, l'agent rep dues instruccions breus. La primera instrucció és «Continua treballant fins que la tasca estigui acabada». Això evita que l'agent tracti el resum com un punt d'aturada. La segona instrucció indica a l'agent quantes compactacions s'han produït, perquè pugui planificar les tasques d'investigació que li queden. Les execucions llargues mantenen a la vista l'objectiu i el pla originals, i el cost dels bucles llargs disminueix sense que la qualitat se'n ressenti.

Cada pàgina que llegeix l'agent s'afegeix al seu context, i l'agent la porta a cada pas posterior. Una pàgina web inclou informació no relacionada amb la pregunta, com ara la navegació, text estàndard i altres continguts.

En lloc de passar a l'agent una pàgina sencera, fetch_url primer fa una passada d'extracció. El text de la pàgina s'envia a un model més petit juntament amb la tasca actual de l'agent. El model només retorna els fragments rellevants, reproduïts literalment perquè l'agent els pugui citar. Durant una avaluació, una pàgina de 5.561 tokens es va reduir a 293 tokens, cosa que va alliberar espai per a més context rellevant.

L'ús de fetch_url amb extracció al nivell d'esforç high va reduir aproximadament un 50 % els tokens d'entrada per consulta. L'extracció també va millorar el rendiment en els benchmarks, amb un 88,0 % a 0,073 $ per consulta, en comparació amb el 83,5 % a 0,094 $ sense extracció.

La cerca web és fonamental en totes les sol·licituds d'investigació dels agents. Es van fer tres canvis en la manera com cerquen els agents:

Més context per cerca: Ara cada cerca retorna fins a 4K tokens de resultats en lloc de 2K. L'agent troba abans el que necessita, cosa que comporta menys cerques i un cost més baix.

Un nou motor de fragments: Els resultats de cerca reben fragments que s'ajusten millor a la consulta, de manera que l'agent no se sobrecarrega amb text irrellevant.
Fast Search: A 1,00 $ per cada 1.000 sol·licituds, Fast Search redueix tant el cost com la latència de cada crida de cerca.

L'equip de Perplexity Search millora contínuament la qualitat de la recuperació en una àmplia varietat de tasques. Les actualitzacions recents han aportat millores en codi, documentació per a desenvolupadors, pàgines de referència i contingut jurídic i normatiu.

Algunes tasques requereixen executar moltes cerques en paral·lel; d'altres necessiten una lectura atenta d'uns quants documents llargs.

Tanmateix, carregar tots els fluxos de treball al prompt del sistema de l'agent afegeix sobrecàrrega de context i pot fer que el model tingui un rendiment inferior en tasques senzilles. En canvi, les Skills s'organitzen en un arbre amb divulgació progressiva. El model carrega les Skills i les instruccions rellevants a mesura que treballa i deixa fora del context la informació no relacionada. Cada Skill només costa el seu nom i la seva descripció fins que el model decideix que s'adequa a la tasca i la carrega; en aquell moment, les instruccions completes s'afegeixen al context i el model segueix el flux de treball prescrit.

Per mesurar la contribució de cada Skill, se'n retira una cada vegada per comparar la qualitat i el cost en les tasques en què l'agent de referència havia carregat aquella Skill. Aquestes ablacions mostren quins fluxos de treball ajuden l'agent i com afecten l'eficiència de la investigació.

Les execucions del benchmark WANDR següents mostren agents que trien els fluxos de treball correctes per a tasques específiques. Les indicacions de wide-search i fanout es van carregar en totes les tasques, cosa que reflecteix la necessitat d'investigar múltiples entitats. People-search només es va carregar en el 6 % de les tasques, i només quan les preguntes feien referència a persones.

En provar una altra tasca de WANDR, l'agent va carregar la Skill people-search amb un patró de fanout per trobar enginyers d'inferència a Londres. Va ampliar 39 termes de rols a 117 consultes i després va fusionar els resultats de la primera passada en 43 perfils únics per filtrar-los més endavant. La Skill people-search va guiar l'agent en aquesta ampliació sense afegir context irrellevant. El fragment següent està adaptat de l'script de l'agent; els noms de les funcions auxiliars són il·lustratius.

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,
            }

Els punts de control són un altre flux de treball que ajuda els agents en tasques de llarga durada. El patró de punts de control prové de la programació per lots. Quan un script processa una llista llarga, escriu cada resultat al disc tan bon punt el té, en lloc de mantenir-ho tot a la memòria fins al final. Si l'script falla o troba errors a mig camí, no es perd res: la següent execució llegeix el que ja s'havia desat i continua des d'on ho havia deixat, i només torna a provar els elements que han fallat.

En una altra tasca de WANDR, l'agent havia de filtrar els perfils de 188 enginyers. Va carregar el patró de punts de control per registrar cada resultat a mesura que treballava. La primera passada va extreure 160 perfils, però en va fallar 28. Quan l'agent va tornar a executar l'script, va ometre els perfils que ja s'havien registrat i només va tornar a provar els 28 restants. Sense el punt de control, un sol registre erroni hauria obligat a tornar a obtenir els 188.Fragment de Python adaptat; s'han omès les pàgines d'entrada, la instrucció de filtratge, l'esquema i les importacions; els noms de les funcions auxiliars són il·lustratius.

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}],
        )

El punt de control registra els resultats correctes; no inicia reintents. Incloure la instrucció i l'esquema a la clau garanteix que, si canvien els criteris de filtratge, es torni a fer el processament.

No totes les proves van comportar millores de qualitat i eficiència. Es va avaluar la càrrega prèvia de totes les Skills a l'agent abans que comencés la tasca. A BrowseComp i DSQA, la càrrega prèvia va augmentar el cost un 13 %. A WANDR, on les trajectòries d'investigació més llargues fan que el contingut recuperat representi una part més gran dels tokens d'entrada, la càrrega prèvia també redueix les puntuacions. Aquests resultats van avalar que es continués utilitzant la divulgació progressiva.

A mesura que avancen les capacitats dels models, també canvia el millor model per a cada nivell d'esforç. Perplexity fa servir un bucle d'investigació automatitzat que supervisa els anuncis i la disponibilitat de models nous. Les avaluacions s'activen tan aviat com un model està disponible.

Quan es publica un model nou, un agent automatitzat el sotmet a l'harness d'avaluació. Prova diferents valors d'esforç de raonament, pressupostos de passos i de crides a eines i configuracions d'eines, i puntua cada execució segons la qualitat i el cost en comparació amb els nivells d'esforç actuals. Quan una execució empitjora, l'agent n'investiga el motiu, ajusta la configuració i torna a executar l'avaluació. Un candidat només substitueix el model actual quan el supera en qualitat amb el mateix cost o un de més baix.

Els benchmarks públics són útils, però les seves puntuacions no sempre es reflecteixen en les tasques del món real. Per exemple, el gràfic següent mostra un model candidat que va obtenir 13,3 punts per sobre de la referència a BrowseComp, però molt per sota de les referències corresponents en tasques internes d'investigació empresarial, jurídica i financera.

Un sol agent només pot abastar un nombre limitat de fonts en un bucle. Per a les tasques complexes, diversos agents treballen en paral·lel i cadascun es coordina en una part diferent del problema.

L'agent principal és l'orquestrador. Crida spawn_agent per crear agents fills i assigna a cadascun una tasca específica i concreta. Cada fill executa el seu propi bucle d'investigació amb un context separat i fa servir el seu propi model, les seves eines i el seu pressupost de passos. Els fills informen dels resultats al pare, que pot enviar a un fill una assignació de seguiment o comprovar-ne el progrés. L'orquestrador i els seus fills intercanvien missatges per compartir proves, assenyalar bloquejos i ajustar els passos següents. A mesura que arriba informació nova, l'orquestrador perfecciona les assignacions i, quan la feina està feta, combina els resultats en una única resposta.

L'Agent API admet rols d'agent predefinits, i l'orquestrador pot crear agents fills amb instruccions personalitzades.

El nivell d'esforç ultra executa tres agents en paral·lel en una tasca. Cada agent investiga de manera independent tota la tasca, cosa que dona lloc a proves diferents. Un quart agent fusiona les seves troballes, elimina els duplicats i redacta la resposta final.

A WANDR, ultra obté un 85,9 % amb un cost de 21,71 $ per tasca. És la puntuació més alta entre les configuracions provades.

Els nivells d'esforç s'avaluen i es milloren contínuament. El nivell que seleccionen els usuaris determina quanta investigació rep una tasca i quant costarà. Els pressupostos de passos i de crides a eines, amb recordatoris a mesura que s'esgoten, mantenen les sol·licituds dins del pressupost. La compactació, l'extracció i uns fragments millors mantenen el context centrat en les proves. Les Skills adapten el flux de treball a la tasca, i els agents en paral·lel amplien el que pot abastar un sol bucle. Un bucle d'avaluació automatitzat només admet un model nou quan millora la qualitat de la investigació amb el mateix cost.

Cada nivell d'esforç continuarà evolucionant a mesura que nous models i configuracions demostrin el seu valor en l'avaluació. Si crides un nivell pel nom, obtens automàticament aquestes millores; si fixes una versió, la configuració es manté inalterada.

Prova l'Agent API i compara els nivells d'esforç amb les teves pròpies càrregues de treball. Consulta els detalls dels nivells d'esforç a la nostra documentació sobre l'esforç de l'Agent API.

El cost de la investigació

Control del pressupost d'investigació

Gestió del context

Compactació

Obtenir només el que importa

Cerca web focalitzada

Selecció del flux de treball correcte

Selecció del model

Escalat multiagent

Què ve ara