Forbedringer af alle indsatsniveauer i Agent API

Indsatsniveauer i Perplexity Agent API giver udviklere mulighed for at vælge balancen mellem omkostninger, hastighed og forskningsdybde for hver opgave. Fra i dag koster hvert indsatsniveau mindre pr. forespørgsel, med en forskningskvalitet, der er højere eller uændret. Et nyt ultra-niveau er tilgængeligt til den mest vidtrækkende og omfattende forskning. Enhver anmodning, der vælger niveauet ved navn, såsom effort="fast", får automatisk den opdaterede konfiguration.

At bygge en forskningsagent betyder at vælge den rette balance mellem omkostninger, hastighed og dybde for hver opgave. Indsatsniveauer i Agent API træffer den beslutning for brugeren. Hvert niveau er en samlet konfiguration, der definerer model, trinbudget, søgeindstillinger og værktøjer for en bestemt opgavetype. Perplexity evaluerer og opdaterer hvert niveau løbende for at levere den bedste forskning til niveauets nuværende omkostning eller derunder.

Disse gevinster kom fra to slags ændringer. Budgetter, kontekststyring og udtrækning sænkede omkostningerne for hver kørsel, og Skills, modelvalg og parallelle agenter hævede eller fastholdt kvaliteten af svaret.

Ydeevnen for medium blev forbedret fra 55 % til 77 % på BrowseComp og DSQA, mens omkostningerne faldt med næsten 90 %. BrowseComp og DSQA er offentlige forskningsbenchmarks; WANDR er Perplexitys benchmark for lange forskningsopgaver med mange enheder. xhigh udfører agentisk arbejde såsom at køre kode i en sandbox, opretholde lange loops med værktøjsbrug og arbejde på tværs af mange kilder på én gang. xhigh fastholdt sin WANDR-score på 76,5 %, mens det kørte til ca. 25 % af omkostningerne ved konfigurationen fra august 2026.

En anmodning om Dybtgående forskning kan køre dusinvis af søgninger, læse hundredvis af sider og kontrollere evidens, før den giver et svar. Hver eneste af disse handlinger tilføjer tokens til konteksten og dollars til regningen. Uden begrænsninger bliver en agent ved med at udføre handlinger, der øger omkostningerne og fylder konteksten uden at forbedre svaret. Fem faktorer driver størstedelen af disse omkostninger:

Budgetfordeling. Agenter med et fastsat budget kan løbe tør for trin og afslutte deres kørsel for tidligt, før de har færdiggjort deres opgave. Omvendt kan agenter uden et fast budget blive ved med at køre og pådrage sig omkostninger uden at forbedre det endelige svar.
Kontekst-overhead. Søgeresultater og hentede sider indeholder evidensen, men uden kontrol kan kontekstvinduet hurtigt fyldes med irrelevant information. Kontekstvinduer fører omkostninger med fra trin til trin, og overbelastede vinduer kan reducere agentens ydeevne.
Valg af arbejdsproces. Forskellige opgaver kræver forskellige tilgange. Et opslag af en enkelt kendsgerning, et spørgsmål med flere led og en bred gennemgang af kilder kræver hver sin arbejdsproces. Hvis en model selv skal vælge, vælger den ofte en ineffektiv arbejdsproces. Det løser ikke problemet at beskrive alle tilgængelige strategier i agentens prompt. De ekstra instruktioner føres med som tokens i hvert trin, og modellen følger hver af dem mindre pålideligt over tid.
Modelvalg. Et skift til en større model giver ikke nødvendigvis en forbedret ydeevne, der står mål med de ekstra omkostninger. Nye modeller lanceres med store overskrifter og offentliggjorte benchmarkscorer. Benchmarkgevinster kan dog være forurenede eller afspejle overfitting af modellen. Uden evaluering på reelle opgaver kan et modelskift øge omkostningerne uden at øge kvaliteten.
Skalering med flere agenter. En enkelt agent kan søge i, læse og ræsonnere over et begrænset antal kilder pr. kørsel. At køre flere agenter parallelt forbedrer kvaliteten på de mest krævende opgaver, men øger også omkostningerne og skaber kompleksitet, hvis det ikke håndteres korrekt.

Løsningen af hver af disse udfordringer reducerede omkostningerne for hvert indsatsniveau uden at reducere ydeevnen.

Hvert indsatsniveau har et fast forskningsbudget med tre komponenter:

Trinbegrænsninger: antallet af omgange, agenten kan tage
Værktøjskald: en grænse for det samlede antal værktøjskald i en anmodning. Et enkelt trin kan foretage flere kald på tværs af flere værktøjer på én gang, så en trinbegrænsning alene styrer ikke, hvor mange handlinger der sker inden for et trin.
Budgetpåmindelser: regelmæssige meddelelser om, hvor mange trin der er tilbage, så agenten kan prioritere og give plads til at skrive svaret i stedet for at løbe tør for budget midt i opgaven.

Budgettet er den centrale afvejning: Flere trin giver bedre svar, og hvert trin medfører omkostninger. Med openai/gpt-6-luna løfter en øgning af trinbegrænsningen fra 1 til 15 nøjagtigheden på BrowseComp + DSQA fra 41 % til 80 %, mens omkostningerne pr. forespørgsel stiger fra 0,0017 $ til 0,0152 $ – omkring 9 gange omkostningerne for omkring 2 gange scoren.

En trinbegrænsning alene styrer ikke forskningsomkostningerne. Med det samme budget på fem trin foretager openai/gpt-6.1-terra flere værktøjskald end openai/gpt-6-luna, fordi mere kapable modeller har tendens til at foretage flere kald i et enkelt trin. Indsatsniveauer begrænser både værktøjskald og trin. For disse modeller betyder grænsen for værktøjskald lige så meget som trinbegrænsningen.

Hvert indsatsniveau justerer disse grænser, men agenten skal også vide, hvor mange trin og handlinger den har tilbage til at opfylde anmodningen. Uden den information kan den løbe tør for trin eller handlinger og blive tvunget til at svare, før forskningen er færdig. Budgettet oplyses i starten af kørslen, og påmindelser kommer, når agenten nærmer sig sine grænser, så der er plads til at verificere og levere resultaterne. For high dækker påmindelserne både trinbudgettet og budgettet for værktøjskald.

To agenter, den ene med en budgetpåmindelse og den anden uden, blev testet på en BrowseComp-opgave, hvor de skulle identificere en tv-serie fra 1990’erne ud fra tre biografier af medvirkende. Agenten med påmindelse fandt det rigtige svar og brugte kun 13 af budgettets 40 trin. Agenten uden budgetpåmindelse brugte alle 40 trin og fandt ikke det rigtige svar. Agentens loop sluttede uventet, og modellen var ikke klar over det resterende researchbudget. Påmindelser holder agenter fokuserede og hjælper dem med at prioritere de resterende ressourcer effektivt.

Langvarige forskningsopgaver fylder modellens kontekstvindue med søgeresultater, hentede sider og mellemliggende noter. Når det er fuldt, må agenten stoppe med at arbejde.

Komprimering holder lange kørsler i gang uden at fylde kontekstvinduet. Når konteksten overskrider en tærskel, erstatter agenten det hidtidige arbejde med et kortere resumé af, hvad den har fundet, og hvad der mangler, og fortsætter derefter.

Komprimering bevarer altid tre ting i konteksten: systemprompten, den oprindelige anmodning og alle Skills, som agenten allerede har indlæst. Efter hver komprimering modtager agenten to korte instruktioner. Den første instruktion er: »Fortsæt med at arbejde, indtil opgaven er færdig.« Det forhindrer agenten i at betragte resuméet som et stoppunkt. Den anden instruktion fortæller agenten, hvor mange komprimeringer der har fundet sted, så den kan planlægge sine resterende forskningsopgaver. Lange kørsler bevarer det oprindelige mål og den oprindelige plan i syne, og omkostningerne ved lange loops falder, uden at det går ud over kvaliteten.

Hver side, agenten læser, føjes til dens kontekst, og agenten bærer den med sig i hvert efterfølgende trin. En webside indeholder information, der ikke har med spørgsmålet at gøre, såsom navigation, standardtekst og andet indhold.

I stedet for at give agenten en hel side kører fetch_url først et udtrækningstrin. Sidens tekst sendes til en mindre model sammen med agentens aktuelle opgave. Modellen returnerer kun de relevante passager, citeret ordret, så agenten kan henvise til dem. Under en evaluering blev en side på 5.561 tokens reduceret til 293 tokens, hvilket frigjorde plads til yderligere relevant kontekst.

Brug af fetch_url med udtrækning på indsatsniveauet high reducerede antallet af input-tokens pr. forespørgsel med ca. 50 %. Udtrækning forbedrede også benchmarkresultaterne og opnåede 88,0 % til 0,073 $ pr. forespørgsel sammenlignet med 83,5 % til 0,094 $ uden udtrækning.

Websøgning er central for hver forskningsanmodning fra en agent. Der blev foretaget tre ændringer i, hvordan agenter søger:

Mere kontekst pr. søgning: Hver søgning returnerer nu op til 4.000 tokens med resultater i stedet for 2.000. Agenten finder hurtigere det, den har brug for, hvilket giver færre søgninger og lavere omkostninger.

En ny uddragsmotor: Søgeresultater får uddrag, der bedre matcher forespørgslen, så agenten ikke overbelastes med irrelevant tekst.
Fast Search: Til 1,00 $ pr. 1.000 anmodninger reducerer Fast Search både omkostninger og latenstid for hvert søgekald.

Perplexity Search-teamet forbedrer løbende genfindingskvaliteten på tværs af en bred vifte af opgaver. Nylige opdateringer har givet forbedringer inden for kode, udviklerdokumentation, referencesider samt juridisk og regulatorisk indhold.

Nogle opgaver kræver mange søgninger, der kører parallelt; andre kræver en grundig læsning af nogle få lange dokumenter.

Men hvis alle arbejdsprocesser indlæses i agentens systemprompt, øger det kontekst-overheadet og kan få modellen til at præstere dårligere på simple opgaver. I stedet er Skills organiseret i et træ med gradvis afsløring. Modellen indlæser relevante Skills og instruktioner, mens den arbejder, og holder uvedkommende information ude af sin kontekst. Hver Skill koster kun sit navn og sin beskrivelse, indtil modellen beslutter, at den passer til opgaven, og indlæser den. Derefter føjes de fulde instruktioner til konteksten, og modellen følger den foreskrevne arbejdsproces.

For at måle, hvordan de enkelte Skills bidrager, fjernes hver Skill én ad gangen for at sammenligne kvalitet og omkostninger på opgaver, hvor baseline-agenten indlæste den pågældende Skill. Disse ablationer viser, hvilke arbejdsprocesser der hjælper agenten, og hvordan de påvirker forskningseffektiviteten.

WANDR-benchmarkkørslerne nedenfor viser agenter, der vælger de rette arbejdsprocesser til specifikke opgaver. Vejledning til bred søgning og fanout blev indlæst for alle opgaver, hvilket afspejler behovet for at undersøge flere enheder. People-search blev kun indlæst for 6 % af opgaverne og kun, når spørgsmålene handlede om personer.

Under test af en anden WANDR-opgave indlæste agenten Skillen people-search med et fanout-mønster for at finde inferensingeniører i London. Den udvidede 39 rollebetegnelser til 117 forespørgsler og flettede derefter resultaterne fra første gennemløb sammen til 43 unikke profiler til videre screening. Skillen people-search guidede agenten gennem denne udvidelse uden at tilføje irrelevant kontekst. Uddraget nedenfor er tilpasset fra agentens script; navnene på hjælpefunktioner er illustrative.

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

Checkpointing er en anden arbejdsproces, der hjælper agenter med langvarige opgaver. Checkpointing-mønsteret stammer fra batchprogrammering. Når et script behandler en lang liste, skriver det hvert resultat til disken, så snart det har det, i stedet for at holde alt i hukommelsen indtil slutningen. Hvis scriptet går ned eller støder på fejl undervejs, går intet tabt: Næste kørsel læser det, der allerede er gemt, fortsætter, hvor den forrige slap, og prøver kun de elementer igen, der mislykkedes.

I en anden WANDR-opgave skulle agenten screene 188 ingeniørers profiler. Den indlæste checkpoint-mønsteret for at registrere hvert resultat undervejs. Det første gennemløb udtrak 160 profiler, men mislykkedes for 28. Da agenten kørte scriptet igen, sprang den de profiler over, der allerede var registreret, og prøvede kun de resterende 28 igen. Uden checkpointet ville en enkelt dårlig post betyde, at alle 188 skulle hentes igen.Tilpasset Python-uddrag; inputsider, screeningsinstruktion, skema og imports er udeladt; navnene på hjælpefunktioner er illustrative.

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

Checkpointet registrerer vellykkede resultater; det starter ikke nye forsøg. Når instruktionen og skemaet indgår i nøglen, sikrer det, at ændrede screeningskriterier udløser ny behandling.

Ikke alle test gav gevinster i kvalitet og effektivitet. Forhåndsindlæsning af alle Skills i agenten, før den gik i gang med sin opgave, blev evalueret. På BrowseComp og DSQA øgede forhåndsindlæsning omkostningerne med 13 %. På WANDR, hvor længere forskningsforløb gør hentet indhold til en større andel af input-tokens, reducerer forhåndsindlæsning også scorerne. Disse resultater understøttede den fortsatte brug af gradvis afsløring.

Efterhånden som modellernes evner udvikler sig, ændrer den bedste model for hvert indsatsniveau sig også. Perplexity bruger et automatiseret forskningsloop, der overvåger annonceringer og tilgængelighed af nye modeller. Evalueringer udløses, så snart en model bliver tilgængelig.

Når en ny model bliver udgivet, kører en automatiseret agent den igennem evalueringens harness. Den afprøver forskellige niveauer af Ræsonnering, budgetter for trin og værktøjskald samt værktøjskonfigurationer og vurderer hver kørsel på kvalitet og omkostninger i forhold til de nuværende indsatsniveauer. Hvor en kørsel klarer sig dårligere, undersøger agenten årsagen, justerer indstillingerne og kører evalueringen igen. En kandidat erstatter kun den nuværende model, når den vinder på kvalitet til samme eller lavere omkostning.

Offentlige benchmarks er nyttige, men deres scorer kan ikke altid overføres til opgaver i den virkelige verden. Diagrammet nedenfor viser for eksempel en kandidatmodel, der scorede 13,3 point over baselinen på BrowseComp, men et godt stykke under de tilsvarende baselines på interne researchopgaver inden for virksomhed, jura og finans.

En enkelt agent kan kun dække et begrænset antal kilder i ét loop. Ved komplekse opgaver arbejder flere agenter parallelt, og hver af dem koordinerer arbejdet med sin egen del af problemet.

Den primære agent er orkestratoren. Den kalder spawn_agent for at oprette underagenter og tildeler hver af dem en specifik, fokuseret opgave. Hver underagent kører sit eget forskningsloop med en separat kontekst og bruger sin egen model, sine egne værktøjer og sit eget trinbudget. Underagenterne rapporterer deres resultater til den overordnede agent, som kan sende en underagent en opfølgende opgave eller tjekke dens fremskridt. Orkestratoren og dens underagenter udveksler beskeder for at dele evidens, markere forhindringer og justere de næste trin. Efterhånden som ny information kommer ind, finjusterer orkestratoren opgaverne og samler, når arbejdet er færdigt, resultaterne i ét samlet svar.

Agent API understøtter foruddefinerede agentroller, og orkestratoren kan oprette underagenter med brugerdefinerede instruktioner.

Indsatsniveauet ultra kører tre agenter parallelt på en opgave. Hver agent undersøger uafhængigt hele opgaven, hvilket giver forskellig evidens. En fjerde agent fletter deres resultater sammen, fjerner dubletter og skriver det endelige svar.

På WANDR scorer ultra 85,9 % til 21,71 $ pr. opgave. Det opnår den højeste score blandt de testede konfigurationer.

Indsatsniveauer evalueres og forbedres løbende. Det niveau, brugerne vælger, afgør, hvor meget forskning en opgave får, og hvad den kommer til at koste. Budgetter for trin og værktøjskald, med påmindelser efterhånden som de bliver opbrugt, holder anmodninger inden for budgettet. Komprimering, udtrækning og bedre uddrag holder konteksten fokuseret på evidens. Skills tilpasser arbejdsprocessen til opgaven, og parallelle agenter udvider, hvad ét loop kan dække. Et automatiseret evalueringsloop godkender kun en ny model, når den forbedrer forskningskvaliteten til samme omkostning.

Hvert indsatsniveau vil fortsætte med at udvikle sig, efterhånden som nye modeller og konfigurationer viser deres værd i evalueringen. Når et niveau kaldes ved navn, får det automatisk disse forbedringer; når en version fastlåses, holdes konfigurationen uændret.

Prøv Agent API, og sammenlign indsatsniveauer på dine egne arbejdsbelastninger. Find oplysninger om indsatsniveauer i vores dokumentation om indsats i Agent API.

Omkostningerne ved forskning

Styring af forskningsbudgettet

Styring af kontekst

Komprimering

Hent kun det, der betyder noget

Fokuseret websøgning

Valg af den rette arbejdsproces

Modelvalg

Skalering med flere agenter

Næste skridt