Förbättringar av alla insatsnivåer i Agent API

Med insatsnivåerna i Perplexity Agent API kan utvecklare välja balansen mellan kostnad, hastighet och forskningsdjup för varje uppgift. Från och med i dag kostar varje insatsnivå mindre per fråga, med en forskningskvalitet som är högre eller oförändrad. En ny nivå, ultra, finns tillgänglig för den mest omfattande och djupgående forskningen. Alla förfrågningar som väljer nivån med namn, till exempel effort="fast", får den uppdaterade konfigurationen automatiskt.

Att bygga en forskningsagent innebär att hitta rätt balans mellan kostnad, hastighet och djup för varje uppgift. Insatsnivåerna i Agent API fattar det beslutet åt användaren. Varje nivå är en paketerad konfiguration som definierar modell, stegbudget, sökinställningar och verktyg för en specifik typ av uppgift. Perplexity utvärderar och uppdaterar varje nivå över tid för att leverera den bästa forskningen till samma eller lägre kostnad än i dag.

Dessa vinster kom från två typer av förändringar. Budgetar, kontexthantering och extrahering sänkte kostnaden för varje körning, medan Skills, modellval och parallella agenter höjde eller bibehöll svarets kvalitet.

Prestandan för medium förbättrades från 55 % till 77 % på BrowseComp och DSQA, samtidigt som kostnaderna minskade med nästan 90 %. BrowseComp och DSQA är offentliga forskningsbenchmarks; WANDR är Perplexitys benchmark för långa forskningsuppgifter med flera entiteter. xhigh utför agentiskt arbete som att köra kod i en sandlåda, upprätthålla långa loopar av verktygsanvändning och arbeta med många källor samtidigt. xhigh behöll sitt WANDR-resultat på 76,5 % till ungefär 25 % av kostnaden för konfigurationen från augusti 2026.

En förfrågan om Djupgående forskning kan köra dussintals sökningar, läsa hundratals sidor och kontrollera belägg innan den svarar. Varje sådan åtgärd lägger till token i kontexten och dollar på notan. Utan begränsningar fortsätter en agent att vidta åtgärder som höjer kostnaden och fyller kontexten utan att förbättra svaret. Fem faktorer driver största delen av den kostnaden:

Budgetfördelning. Agenter med en fast budget kan få slut på steg och avsluta sin körning i förtid innan de har slutfört uppgiften. Omvänt kan agenter utan fast budget fortsätta att köra och dra på sig kostnader utan att förbättra det slutliga svaret.
Kontextbelastning. Sökresultat och hämtade sidor innehåller beläggen, men om inget görs kan kontextfönstret snabbt fyllas med irrelevant information. Kontextfönster för med sig kostnader från steg till steg, och överbelastade fönster kan försämra agentens prestanda.
Val av arbetsflöde. Olika uppgifter kräver olika tillvägagångssätt. En enkel faktasökning, en fråga i flera led och en bred genomgång av källor kräver var och en ett eget arbetsflöde. Om en modell får välja på egen hand väljer den ofta ett ineffektivt arbetsflöde. Att beskriva varje tillgänglig strategi i agentens prompt löser inte detta. De extra instruktionerna följer med som token i varje steg, och modellen följer var och en av dem mindre tillförlitligt med tiden.
Modellval. Att byta till en större modell ger inte nödvändigtvis en prestandaförbättring som motsvarar den extra kostnaden. Nya modeller lanseras med stora rubriker och publicerade benchmarkresultat. Benchmarkvinster kan dock vara kontaminerade eller spegla överanpassning av modellen. Utan utvärdering på verkliga uppgifter kan ett modellbyte höja kostnaderna utan att höja kvaliteten.
Skalning med flera agenter. En enskild agent kan söka igenom, läsa och resonera kring ett begränsat antal källor per körning. Att köra flera agenter parallellt förbättrar kvaliteten på de mest krävande uppgifterna, men ökar också kostnaderna och medför komplexitet om det inte hanteras korrekt.

Genom att lösa var och en av dessa utmaningar minskade kostnaderna för varje insatsnivå utan att prestandan försämrades.

Varje insatsnivå har en fast forskningsbudget med tre komponenter:

Stegbegränsningar: antalet turer som agenten kan genomföra
Verktygsanrop: ett tak för det totala antalet verktygsanrop i en förfrågan. Ett enda steg kan göra flera anrop till flera verktyg samtidigt, så en stegbegränsning ensam styr inte hur många åtgärder som sker inom ett steg.
Budgetpåminnelser: regelbundna meddelanden om hur många steg som återstår, så att agenten kan prioritera och lämna utrymme för att skriva svaret i stället för att få slut på budget mitt i uppgiften.

Budgeten är den centrala avvägningen: fler steg ger bättre svar, och varje steg medför kostnader. Med openai/gpt-6-luna höjer en ökning av stegbegränsningen från 1 till 15 träffsäkerheten på BrowseComp + DSQA från 41 % till 80 %, medan kostnaden per fråga stiger från 0,0017 USD till 0,0152 USD – ungefär 9 gånger kostnaden för ungefär 2 gånger resultatet.

En stegbegränsning ensam styr inte forskningskostnaden. Med samma budget på fem steg gör openai/gpt-6.1-terra fler verktygsanrop än openai/gpt-6-luna, eftersom mer kapabla modeller tenderar att göra flera anrop i ett enda steg. Insatsnivåerna begränsar både verktygsanrop och steg. För dessa modeller är taket för verktygsanrop lika viktigt som stegbegränsningen.

Varje insatsnivå justerar dessa gränser, men agenten måste också veta hur många steg och åtgärder den har kvar för att slutföra förfrågan. Utan den informationen kan stegen eller åtgärderna ta slut, och agenten tvingas svara innan forskningen är klar. Budgeten anges i början av körningen, och påminnelser kommer när agenten närmar sig sina gränser, så att det finns utrymme att verifiera och leverera resultaten. För high omfattar påminnelserna både stegbudgeten och budgeten för verktygsanrop.

Två agenter, en med budgetpåminnelse och en utan, testades på en BrowseComp-uppgift där de skulle identifiera en tv-serie från 1990-talet utifrån tre biografier över skådespelare i rollistan. Agenten med påminnelse hittade rätt svar med 13 av budgetens 40 steg. Agenten utan budgetpåminnelse använde alla 40 steg och hittade inte rätt svar. Den agentens loop avslutades oväntat, och modellen var inte medveten om den återstående budgeten för efterforskningar. Påminnelser håller agenterna fokuserade och hjälper dem att prioritera återstående resurser effektivt.

Långvariga forskningsuppgifter fyller modellens kontextfönster med sökresultat, hämtade sidor och anteckningar under arbetets gång. När det är fullt måste agenten sluta arbeta.

Komprimering gör att långa körningar kan fortsätta utan att kontextfönstret fylls. När kontexten överskrider ett tröskelvärde ersätter agenten arbetet hittills med en kortare sammanfattning av vad den har hittat och vad som återstår, och fortsätter sedan.

Komprimering behåller alltid tre saker i kontexten: systemprompten, den ursprungliga förfrågan och alla Skills som agenten redan har laddat. Efter varje komprimering får agenten två korta instruktioner. Den första instruktionen är ”Fortsätt arbeta tills uppgiften är klar.” Det hindrar agenten från att behandla sammanfattningen som en slutpunkt. Den andra instruktionen talar om för agenten hur många komprimeringar som har skett, så att den kan planera sina återstående forskningsuppgifter. Långa körningar behåller det ursprungliga målet och planen i sikte, och kostnaden för långa loopar minskar utan att kvaliteten försämras.

Varje sida som agenten läser läggs till i dess kontext, och agenten bär med sig den i varje efterföljande steg. En webbsida innehåller information som inte har med frågan att göra, till exempel navigering, standardtext och annat innehåll.

I stället för att ge agenten en hel sida kör fetch_url först ett extraheringssteg. Sidtexten skickas till en mindre modell tillsammans med agentens aktuella uppgift. Modellen returnerar bara de relevanta avsnitten, citerade ordagrant så att agenten kan hänvisa till dem. Under en utvärdering reducerades en sida på 5 561 token till 293 token, vilket frigjorde utrymme för ytterligare relevant kontext.

Att använda fetch_url med extrahering på insatsnivån high minskade antalet indatatoken per fråga med cirka 50 %. Extraheringen förbättrade också benchmarkresultaten och nådde 88,0 % till 0,073 USD per fråga, jämfört med 83,5 % till 0,094 USD utan extrahering.

Webbsökning är central för varje forskningsförfrågan som agenter hanterar. Tre ändringar gjordes i hur agenter söker:

Mer kontext per sökning: Varje sökning returnerar nu upp till 4K token med resultat i stället för 2K. Agenten hittar det den behöver snabbare, vilket leder till färre sökningar och lägre kostnad.

En ny motor för utdrag: Sökresultaten får utdrag som bättre matchar frågan, så att agenten inte överbelastas med irrelevant text.
Snabb sökning: För 1,00 USD per 1 000 förfrågningar minskar Fast Search både kostnad och latens för varje sökanrop.

Perplexity Search-teamet förbättrar kontinuerligt hämtningskvaliteten för ett brett spektrum av uppgifter. De senaste uppdateringarna gav förbättringar för kod, utvecklardokumentation, referenssidor samt juridiskt och regulatoriskt innehåll.

Vissa uppgifter kräver att många sökningar körs parallellt; andra kräver en noggrann läsning av några få långa dokument.

Att ladda varje arbetsflöde i agentens systemprompt ökar dock kontextbelastningen och kan få modellen att prestera sämre på enkla uppgifter. I stället organiseras Skills i ett träd med progressiv exponering. Modellen laddar relevanta Skills och instruktioner medan den arbetar och håller orelaterad information utanför sin kontext. Varje Skill kostar bara sitt namn och sin beskrivning tills modellen bedömer att den passar uppgiften och laddar den. Då läggs de fullständiga instruktionerna till i kontexten, och modellen följer det föreskrivna arbetsflödet.

För att mäta hur enskilda Skills bidrar tas varje Skill bort en i taget, och kvalitet och kostnad jämförs på uppgifter där basagenten hade laddat denna Skill. Dessa ablationer visar vilka arbetsflöden som hjälper agenten och hur de påverkar forskningens effektivitet.

Körningarna i WANDR-benchmarken nedan visar hur agenter väljer rätt arbetsflöden för specifika uppgifter. Vägledning för wide-search och fanout laddades för varje uppgift, vilket speglar behovet av att undersöka flera entiteter. People-search laddades bara för 6 % av uppgifterna, och bara när frågorna gällde personer.

Vid testning av en annan WANDR-uppgift laddade agenten Skill people-search med ett fanout-mönster för att hitta inferensingenjörer i London. Den utökade 39 rolltermer till 117 frågor och slog sedan samman resultaten från den första omgången till 43 unika profiler för vidare granskning. Skill people-search vägledde agenten genom denna utökning utan att lägga till irrelevant kontext. Utdraget nedan är anpassat från agentens skript; namnen på hjälpfunktionerna är illustrativa.

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

Kontrollpunkter är ett annat arbetsflöde som hjälper agenter med långvariga uppgifter. Mönstret med kontrollpunkter kommer från batchprogrammering. När ett skript bearbetar en lång lista skriver det varje resultat till disk så snart det finns, i stället för att hålla allt i minnet till slutet. Om skriptet kraschar eller stöter på fel halvvägs går ingenting förlorat: nästa körning läser det som redan har sparats och fortsätter där den slutade, och gör bara om de poster som misslyckades.

I en annan WANDR-uppgift behövde agenten granska profilerna för 188 ingenjörer. Den laddade kontrollpunktsmönstret för att registrera varje resultat medan den arbetade. Den första omgången extraherade 160 profiler men misslyckades med 28. När agenten körde skriptet igen hoppade den över de profiler som redan hade registrerats och försökte bara igen med de återstående 28. Utan kontrollpunkten skulle en enda felaktig post innebära att alla 188 måste hämtas igen.Anpassat Python-utdrag; indatasidor, granskningsinstruktion, schema och importer har utelämnats; namnen på hjälpfunktionerna är illustrativa.

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

Kontrollpunkten registrerar lyckade resultat; den startar inga nya försök. Eftersom instruktionen och schemat ingår i nyckeln utlöser ändrade urvalskriterier en ny bearbetning.

Inte alla tester gav vinster i kvalitet och effektivitet. Att förladda alla Skills i agenten innan den påbörjade sin uppgift utvärderades. På BrowseComp och DSQA ökade förladdningen kostnaden med 13 %. På WANDR, där längre forskningsförlopp gör att hämtat innehåll utgör en större andel av indatatoken, sänker förladdning dessutom resultaten. Dessa resultat talade för att fortsätta använda progressiv exponering.

I takt med att modellernas förmågor utvecklas förändras även vilken modell som är bäst för varje insatsnivå. Perplexity använder en automatiserad forskningsloop som bevakar nya modellannonseringar och tillgänglighet. Utvärderingar startas så snart en modell blir tillgänglig.

När en ny modell släpps kör en automatiserad agent den genom utvärderingens harness. Den går igenom olika nivåer av resonemangsinsats, budgetar för steg och verktygsanrop samt verktygskonfigurationer, och poängsätter varje körning efter kvalitet och kostnad jämfört med de nuvarande insatsnivåerna. Där en körning försämras undersöker agenten varför, justerar inställningarna och kör utvärderingen igen. En kandidat ersätter den nuvarande modellen endast när den vinner på kvalitet till samma eller lägre kostnad.

Offentliga benchmarks är användbara, men deras resultat speglar inte alltid verkliga uppgifter. Diagrammet nedan visar till exempel en kandidatmodell som fick 13,3 poäng mer än baslinjen på BrowseComp men låg långt under motsvarande baslinjer för interna forskningsuppgifter inom företag, juridik och finans.

En enskild agent kan bara täcka ett begränsat antal källor i en loop. För komplexa uppgifter arbetar flera agenter parallellt, och var och en samordnar arbetet med en annan del av problemet.

Den primära agenten är orkestreraren. Den anropar spawn_agent för att skapa underagenter och tilldelar var och en en specifik, avgränsad uppgift. Varje underagent kör sin egen forskningsloop med en separat kontext och använder sin egen modell, sina egna verktyg och sin egen stegbudget. Underagenterna rapporterar sina resultat till den överordnade agenten, som kan ge en underagent ett uppföljande uppdrag eller kontrollera hur arbetet fortskrider. Orkestreraren och dess underagenter utbyter meddelanden för att dela belägg, flagga hinder och justera nästa steg. När ny information kommer in förfinar orkestreraren uppdragen och sammanställer, när arbetet är klart, resultaten till ett enda svar.

Agent API stöder fördefinierade agentroller, och orkestreraren kan skapa underagenter med anpassade instruktioner.

Insatsnivån ultra kör tre agenter parallellt på en uppgift. Varje agent undersöker hela uppgiften på egen hand, vilket ger olika belägg. En fjärde agent sammanför deras resultat, tar bort dubbletter och skriver det slutliga svaret.

På WANDR får ultra 85,9 % till 21,71 USD per uppgift. Det är det högsta resultatet bland de testade konfigurationerna.

Insatsnivåerna utvärderas och förbättras kontinuerligt. Den nivå som användarna väljer avgör hur mycket forskning en uppgift får och hur mycket den kommer att kosta. Budgetar för steg och verktygsanrop, med påminnelser när de börjar ta slut, håller förfrågningarna inom budget. Komprimering, extrahering och bättre utdrag håller kontexten fokuserad på belägg. Skills anpassar arbetsflödet efter uppgiften, och parallella agenter utökar vad en enda loop kan täcka. En automatiserad utvärderingsloop godkänner en ny modell endast när den förbättrar forskningskvaliteten till samma kostnad.

Varje insatsnivå kommer att fortsätta utvecklas i takt med att nya modeller och konfigurationer bevisar sitt värde i utvärderingar. Om du anropar en nivå med namn får du automatiskt dessa förbättringar; om du fäster en version hålls konfigurationen oförändrad.

Testa Agent API och jämför insatsnivåerna på dina egna arbetsbelastningar. Mer information om insatsnivåerna finns i vår dokumentation om insatsnivåer i Agent API.

Kostnaden för forskning

Styra forskningsbudgeten

Hantera kontext

Komprimering

Hämta bara det som är viktigt

Fokuserad webbsökning

Välja rätt arbetsflöde

Modellval

Skalning med flera agenter

Vad händer härnäst