Forbedringer av alle innsatsnivåer i Agent API

Innsatsnivåene i Perplexity Agent API lar utviklere velge balansen mellom kostnad, hastighet og forskningsdybde for hver oppgave. Fra i dag koster hvert innsatsnivå mindre per spørring, med forskningskvalitet som er høyere eller uendret. Et nytt ultra-nivå er tilgjengelig for den mest omfattende og grundige forskningen. Alle forespørsler som velger nivået ved navn, for eksempel effort="fast", får den oppdaterte konfigurasjonen automatisk.

Å bygge en forskningsagent betyr å velge riktig balanse mellom kostnad, hastighet og dybde for hver oppgave. Innsatsnivåene i Agent API tar denne avgjørelsen for brukeren. Hvert nivå er en samlet konfigurasjon som definerer modell, stegbudsjett, søkeinnstillinger og verktøy for en bestemt oppgavetype. Perplexity evaluerer og oppdaterer hvert nivå over tid for å levere den beste forskningen til nivåets nåværende kostnad eller lavere.

Disse gevinstene kom fra to typer endringer. Budsjetter, konteksthåndtering og uttrekking senket kostnaden for hver kjøring, mens skills, modellvalg og parallelle agenter økte eller opprettholdt kvaliteten på svaret.

Ytelsen for medium økte fra 55 % til 77 % på BrowseComp og DSQA, mens kostnadene sank med nesten 90 %. BrowseComp og DSQA er offentlige forskningsbenchmarker; WANDR er Perplexitys benchmark for lange forskningsoppgaver med mange entiteter. xhigh utfører agentisk arbeid, som å kjøre kode i en sandbox, opprettholde lange løkker med verktøybruk og arbeide på tvers av mange kilder samtidig. xhigh holdt WANDR-poengsummen sin på 76,5 % mens det kjørte til omtrent 25 % av kostnaden for konfigurasjonen fra august 2026.

En forespørsel om dypgående forskning kan kjøre dusinvis av søk, lese hundrevis av sider og kontrollere bevis før den gir et svar. Hver av disse handlingene legger til tokener i konteksten og dollar på regningen. Uten begrensninger fortsetter en agent å utføre handlinger som øker kostnaden og fyller opp konteksten uten å forbedre svaret. Fem faktorer står for det meste av denne kostnaden:

Budsjettfordeling. Agenter med et fastsatt budsjett kan gå tom for steg og avslutte kjøringen for tidlig, før de har fullført oppgaven. Omvendt kan agenter uten fast budsjett fortsette å kjøre og pådra seg kostnader uten å forbedre det endelige svaret.
Kontekstbelastning. Søkeresultater og hentede sider inneholder bevisene, men uten kontroll kan kontekstvinduet raskt fylles med irrelevant informasjon. Kontekstvinduer fører kostnader med seg fra steg til steg, og overbelastede vinduer kan redusere agentens ytelse.
Valg av arbeidsflyt. Ulike oppgaver krever ulike tilnærminger. Et enkelt faktaoppslag, et spørsmål med flere ledd og en bred gjennomgang av kilder krever hver sin arbeidsflyt. Når en modell får velge selv, velger den ofte en ineffektiv arbeidsflyt. Å beskrive alle tilgjengelige strategier i agentens prompt løser ikke dette. De ekstra instruksjonene følger med som tokener i hvert steg, og modellen følger hver av dem mindre pålitelig over tid.
Modellvalg. Å bytte til en større modell gir ikke nødvendigvis en ytelsesforbedring som står i forhold til den ekstra kostnaden. Nye modeller lanseres med overskrifter og publiserte benchmarkresultater. Gevinster i benchmarker kan imidlertid være kontaminert eller skyldes overtilpasning av modellen. Uten evaluering på reelle oppgaver kan et modellbytte øke kostnadene uten å øke kvaliteten.
Skalering med flere agenter. En enkelt agent kan søke i, lese og resonnere gjennom et begrenset antall kilder per kjøring. Å kjøre flere agenter parallelt forbedrer kvaliteten på de mest krevende oppgavene, men øker også kostnadene og gir økt kompleksitet hvis det ikke håndteres riktig.

Ved å løse hver av disse utfordringene ble kostnadene redusert for hvert innsatsnivå uten at ytelsen ble dårligere.

Hvert innsatsnivå har et fast forskningsbudsjett med tre komponenter:

Steggrenser: antallet runder agenten kan ta
Verktøykall: en grense for det totale antallet verktøykall i en forespørsel. Ett enkelt steg kan utføre flere kall på tvers av flere verktøy samtidig, så en steggrense alene styrer ikke hvor mange handlinger som skjer innenfor et steg.
Budsjettpåminnelser: jevnlige varsler om hvor mange steg som gjenstår, slik at agenten kan prioritere og sette av plass til å skrive svaret i stedet for å gå tom for budsjett midt i oppgaven.

Budsjettet er den sentrale avveiningen: Flere steg gir bedre svar, og hvert steg medfører kostnader. Med openai/gpt-6-luna øker nøyaktigheten på BrowseComp + DSQA fra 41 % til 80 % når steggrensen heves fra 1 til 15, mens kostnaden per spørring stiger fra 0,0017 dollar til 0,0152 dollar – omtrent 9 ganger kostnaden for omtrent 2 ganger poengsummen.

En steggrense alene styrer ikke forskningskostnaden. Med det samme budsjettet på fem steg gjør openai/gpt-6.1-terra flere verktøykall enn openai/gpt-6-luna, fordi mer avanserte modeller ofte utfører flere kall i ett enkelt steg. Innsatsnivåene begrenser både verktøykall og steg. For disse modellene er grensen for verktøykall like viktig som steggrensen.

Hvert innsatsnivå justerer disse grensene, men agenten må også vite hvor mange steg og handlinger den har igjen for å fullføre forespørselen. Uten den informasjonen kan den gå tom for steg eller handlinger og bli tvunget til å svare før forskningen er ferdig. Budsjettet oppgis ved starten av kjøringen, og påminnelser kommer når agenten nærmer seg grensene, slik at det er rom for å verifisere og levere resultatene. For high dekker påminnelsene både stegbudsjettet og budsjettet for verktøykall.

To agenter, én med budsjettpåminnelse og én uten, ble testet på en BrowseComp-oppgave der de skulle identifisere en TV-serie fra 1990-tallet ut fra tre skuespillerbiografier. Agenten med påminnelse fant riktig svar ved å bruke 13 av de 40 stegene i budsjettet. Agenten uten budsjettpåminnelse brukte alle de 40 stegene og fant ikke riktig svar. Løkken til denne agenten ble avsluttet uventet, og modellen var ikke klar over det gjenværende forskningsbudsjettet. Påminnelser holder agentene fokuserte og hjelper dem med å prioritere de gjenværende ressursene effektivt.

Langvarige forskningsoppgaver fyller modellens kontekstvindu med søkeresultater, hentede sider og mellomliggende notater. Når vinduet er fullt, må agenten slutte å arbeide.

Komprimering gjør at lange kjøringer kan fortsette uten å fylle kontekstvinduet. Når konteksten overskrider en terskel, erstatter agenten arbeidet så langt med et kortere sammendrag av hva den har funnet og hva som gjenstår, og fortsetter deretter.

Komprimering beholder alltid tre ting i konteksten: systemprompten, den opprinnelige forespørselen og alle skills agenten allerede har lastet inn. Etter hver komprimering mottar agenten to korte instruksjoner. Den første instruksjonen er: «Fortsett å jobbe til oppgaven er fullført.» Dette hindrer agenten i å behandle sammendraget som et stoppunkt. Den andre instruksjonen forteller agenten hvor mange komprimeringer som har skjedd, slik at den kan planlegge de gjenværende forskningsoppgavene. Lange kjøringer holder det opprinnelige målet og planen i sikte, og kostnaden for lange løkker synker uten at kvaliteten blir dårligere.

Hver side agenten leser, legges til konteksten, og agenten bærer den med seg i hvert påfølgende steg. En nettside inneholder informasjon som ikke er relevant for spørsmålet, for eksempel navigasjon, standardtekst og annet innhold.

I stedet for å gi agenten en hel side kjører fetch_url først en uttrekkingsrunde. Sideteksten sendes til en mindre modell sammen med agentens nåværende oppgave. Modellen returnerer bare de relevante avsnittene, ordrett sitert slik at agenten kan henvise til dem. Under en evaluering ble en side på 5561 tokener redusert til 293 tokener, noe som frigjorde plass til mer relevant kontekst.

Bruk av fetch_url med uttrekking på innsatsnivået high reduserte antall input-tokener per spørring med omtrent 50 %. Uttrekking forbedret også benchmarkytelsen og oppnådde 88,0 % til 0,073 dollar per spørring, sammenlignet med 83,5 % til 0,094 dollar uten uttrekking.

Nettsøk er sentralt i alle forskningsforespørsler fra agenter. Det ble gjort tre endringer i hvordan agentene søker:

Mer kontekst per søk: Hvert søk returnerer nå opptil 4K tokener med resultater i stedet for 2K. Agenten finner det den trenger raskere, noe som gir færre søk og lavere kostnad.

En ny utdragsmotor: Søkeresultatene får utdrag som samsvarer bedre med spørringen, slik at agenten ikke overbelastes med irrelevant tekst.
Fast Search: Til 1,00 dollar per 1000 forespørsler reduserer Fast Search både kostnad og ventetid for hvert søkekall.

Perplexity Search-teamet forbedrer kontinuerlig gjenfinningskvaliteten på tvers av et bredt spekter av oppgaver. Nylige oppdateringer har gitt forbedringer for kode, utviklerdokumentasjon, referansesider samt juridisk og regulatorisk innhold.

Noen oppgaver krever mange søk som kjøres parallelt; andre krever nøye lesing av noen få lange dokumenter.

Å laste inn alle arbeidsflyter i agentens systemprompt gir imidlertid økt kontekstbelastning og kan føre til at modellen presterer dårligere på enkle oppgaver. I stedet er skills organisert i et tre med progressiv avsløring. Modellen laster inn relevante skills og instruksjoner mens den arbeider, og holder urelatert informasjon utenfor konteksten. Hver skill koster bare navnet og beskrivelsen sin helt til modellen avgjør at den passer til oppgaven og laster den inn. Da legges de fullstendige instruksjonene til i konteksten, og modellen følger den foreskrevne arbeidsflyten.

For å måle hvordan de enkelte skills bidrar, fjernes hver skill én om gangen for å sammenligne kvalitet og kostnad på oppgaver der grunnagenten lastet inn den aktuelle skillen. Disse ablasjonene viser hvilke arbeidsflyter som hjelper agenten, og hvordan de påvirker forskningseffektiviteten.

WANDR-benchmarkkjøringene nedenfor viser agenter som velger riktige arbeidsflyter for bestemte oppgaver. Veiledning for wide-search og fanout ble lastet inn for alle oppgaver, noe som gjenspeiler behovet for å undersøke flere entiteter. People-search ble bare lastet inn for 6 % av oppgavene, og bare når spørsmålene handlet om personer.

Under testing av en annen WANDR-oppgave lastet agenten inn skillen people-search med et fanout-mønster for å finne inferensingeniører i London. Den utvidet 39 rollebetegnelser til 117 spørringer og slo deretter sammen resultatene fra første runde til 43 unike profiler for videre screening. Skillen people-search veiledet agenten gjennom denne utvidelsen uten å legge til irrelevant kontekst. Utdraget nedenfor er tilpasset fra agentens skript; navnene på hjelpefunksjonene er illustrerende.

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

Sjekkpunkter er en annen arbeidsflyt som hjelper agenter med langvarige oppgaver. Sjekkpunktmønsteret kommer fra batchprogrammering. Når et skript behandler en lang liste, skriver det hvert resultat til disk så snart det foreligger, i stedet for å holde alt i minnet til slutt. Hvis skriptet krasjer eller støter på feil underveis, går ingenting tapt: Neste kjøring leser det som allerede er lagret, fortsetter der den slapp og prøver bare på nytt for elementene som mislyktes.

I en annen WANDR-oppgave måtte agenten screene profilene til 188 ingeniører. Den lastet inn sjekkpunktmønsteret for å registrere hvert resultat underveis. Første runde hentet ut 160 profiler, men mislyktes for 28. Da agenten kjørte skriptet på nytt, hoppet den over profilene som allerede var registrert, og prøvde bare de resterende 28 på nytt. Uten sjekkpunktet ville én enkelt feilaktig post bety at alle 188 måtte hentes på nytt.Tilpasset Python-utdrag; inndatasider, screeninginstruksjon, skjema og importer er utelatt; navnene på hjelpefunksjonene er illustrerende.

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

Sjekkpunktet registrerer vellykkede resultater; det starter ikke nye forsøk. Ved å inkludere instruksjonen og skjemaet i nøkkelen sikrer man at endrede screeningkriterier utløser ny behandling.

Ikke alle tester ga gevinster i kvalitet og effektivitet. Det ble evaluert å forhåndslaste alle skills i agenten før den startet oppgaven. På BrowseComp og DSQA økte forhåndslasting kostnaden med 13 %. På WANDR, der lengre forskningsforløp gjør at hentet innhold utgjør en større andel av input-tokenene, reduserer forhåndslasting også poengsummene. Disse resultatene støttet fortsatt bruk av progressiv avsløring.

Etter hvert som modellenes evner utvikler seg, endres også den beste modellen for hvert innsatsnivå. Perplexity bruker en automatisert forskningsløkke som overvåker kunngjøringer og tilgjengelighet for nye modeller. Evalueringer startes så snart en modell blir tilgjengelig.

Når en ny modell lanseres, kjører en automatisert agent den gjennom evalueringsharnesset. Den tester ulike nivåer av resonneringsinnsats, budsjetter for steg og verktøykall samt verktøykonfigurasjoner, og vurderer hver kjøring på kvalitet og kostnad opp mot de nåværende innsatsnivåene. Der en kjøring gir dårligere resultater, undersøker agenten hvorfor, justerer innstillingene og kjører evalueringen på nytt. En kandidat erstatter den nåværende modellen bare når den vinner på kvalitet til samme eller lavere kostnad.

Offentlige benchmarker er nyttige, men poengsummene deres gjenspeiler ikke alltid virkelige oppgaver. Diagrammet nedenfor viser for eksempel en kandidatmodell som fikk 13,3 poeng over referansen på BrowseComp, men som lå godt under de tilsvarende referansene på interne forskningsoppgaver innen bedrift, juss og finans.

En enkelt agent kan bare dekke et visst antall kilder i én løkke. For komplekse oppgaver jobber flere agenter parallelt, og hver av dem koordinerer en ulik del av problemet.

Den primære agenten er orkestratoren. Den kaller spawn_agent for å opprette underagenter og gir hver av dem en spesifikk, avgrenset oppgave. Hver underagent kjører sin egen forskningsløkke med separat kontekst, med egen modell, egne verktøy og eget stegbudsjett. Underagentene rapporterer resultatene sine til den overordnede agenten, som kan gi en underagent et oppfølgingsoppdrag eller sjekke fremdriften. Orkestratoren og underagentene utveksler meldinger for å dele bevis, flagge hindringer og justere neste steg. Etter hvert som ny informasjon kommer inn, finjusterer orkestratoren oppdragene, og når arbeidet er ferdig, slår den sammen resultatene til ett samlet svar.

Agent API støtter forhåndsdefinerte agentroller, og orkestratoren kan opprette underagenter med egendefinerte instruksjoner.

Innsatsnivået ultra kjører tre agenter parallelt på en oppgave. Hver agent undersøker hele oppgaven uavhengig, noe som gir ulike bevis. En fjerde agent slår sammen funnene deres, fjerner duplikater og skriver det endelige svaret.

På WANDR oppnår ultra 85,9 % til 21,71 dollar per oppgave. Det er den høyeste poengsummen blant de testede konfigurasjonene.

Innsatsnivåene evalueres og forbedres kontinuerlig. Nivået brukerne velger, avgjør hvor mye forskning en oppgave får og hvor mye den vil koste. Budsjetter for steg og verktøykall, med påminnelser etter hvert som de brukes opp, holder forespørslene innenfor budsjettet. Komprimering, uttrekking og bedre utdrag holder konteksten fokusert på bevis. Skills tilpasser arbeidsflyten til oppgaven, og parallelle agenter utvider det én løkke kan dekke. En automatisert evalueringsløkke tar bare i bruk en ny modell når den forbedrer forskningskvaliteten til samme kostnad.

Hvert innsatsnivå vil fortsette å utvikle seg etter hvert som nye modeller og konfigurasjoner viser seg verdige i evalueringer. Når du kaller et nivå ved navn, får du automatisk med disse forbedringene; ved å låse en versjon holdes konfigurasjonen uendret.

Prøv Agent API og sammenlign innsatsnivåene på dine egne arbeidsbelastninger. Finn detaljer om innsatsnivåene i dokumentasjonen for innsatsnivåer i Agent API.

Kostnaden ved forskning

Styring av forskningsbudsjettet

Håndtering av kontekst

Komprimering

Hente bare det som betyr noe

Fokusert nettsøk

Velge riktig arbeidsflyt

Modellvalg

Skalering med flere agenter

Hva skjer videre