Vylepšení všech úrovní úsilí v Agent API

Úrovně úsilí v Perplexity Agent API umožňují vývojářům zvolit pro každou úlohu rovnováhu mezi náklady, rychlostí a hloubkou výzkumu. Nyní je každá úroveň úsilí levnější na dotaz a kvalita výzkumu je vyšší nebo stejná. Pro nejrozsáhlejší a nejkomplexnější výzkum je k dispozici nová úroveň ultra. Každý požadavek, který zvolí úroveň jménem, například effort="fast", automaticky získá aktualizovanou konfiguraci.

Vytvoření výzkumného agenta znamená zvolit pro každou úlohu správnou rovnováhu mezi náklady, rychlostí a hloubkou. Úrovně úsilí v Agent API toto rozhodnutí dělají za uživatele. Každá úroveň je ucelená konfigurace, která pro konkrétní typ úlohy definuje model, rozpočet kroků, nastavení vyhledávání a nástroje. Perplexity každou úroveň průběžně vyhodnocuje a aktualizuje, aby poskytovala nejlepší výzkum za současnou cenu nebo levněji.

Tato zlepšení přinesly dva druhy změn. Rozpočty, práce s kontextem a extrakce snížily náklady na každý běh, zatímco skilly, výběr modelu a paralelní agenti zvýšili nebo udrželi kvalitu odpovědi.

Výkon úrovně medium se v BrowseComp a DSQA zlepšil z 55 % na 77 %, zatímco náklady klesly téměř o 90 %. BrowseComp a DSQA jsou veřejné výzkumné benchmarky; WANDR je benchmark společnosti Perplexity zaměřený na dlouhé výzkumné úlohy s mnoha entitami. Úroveň xhigh vykonává agentní práci, jako je spouštění kódu v sandboxu, udržování dlouhých smyček používání nástrojů a práce s mnoha zdroji současně. Úroveň xhigh si udržela skóre WANDR na 76,5 % a přitom běžela za zhruba 25 % nákladů konfigurace ze srpna 2026.

Požadavek na hloubkový výzkum může spustit desítky vyhledávání, přečíst stovky stránek a ověřit důkazy, než odpoví. Každá z těchto akcí přidává tokeny do kontextu a dolary do účtu. Bez omezení agent dál provádí akce, které zvyšují náklady a zahlcují kontext, aniž by zlepšily odpověď. Většinu těchto nákladů určuje pět faktorů:

Přidělení rozpočtu. Agentům s pevně stanoveným rozpočtem mohou dojít kroky a jejich běh může skončit předčasně, ještě než úlohu dokončí. Naopak agenti bez pevného rozpočtu mohou běžet dál a vytvářet náklady, aniž by zlepšili konečnou odpověď.
Režie kontextu. Výsledky vyhledávání a načtené stránky nesou důkazy, ale bez kontroly se kontextové okno může rychle zaplnit irelevantními informacemi. Kontextová okna přenášejí náklady z kroku na krok a přeplněná okna mohou snížit výkon agenta.
Výběr pracovního postupu. Různé úlohy vyžadují různé přístupy. Vyhledání jediného faktu, otázka vyžadující více navazujících kroků a široký průzkum zdrojů vyžadují každá jiný pracovní postup. Pokud model volí sám, často vybere neefektivní postup. Popsat v promptu agenta každou dostupnou strategii tento problém neřeší. Dodatečné pokyny se v podobě tokenů přenášejí v každém kroku a model se každým z nich časem řídí méně spolehlivě.
Výběr modelu. Přechod na větší model nemusí přinést zlepšení výkonu úměrné vyšším nákladům. Nové modely přicházejí s velkými titulky a zveřejněnými výsledky v benchmarcích. Zlepšení v benchmarcích však mohou být zkreslena kontaminací dat nebo odrážet přeučení modelu. Bez vyhodnocení na reálných úlohách může změna modelu zvýšit náklady, aniž by zvýšila kvalitu.
Škálování pomocí více agentů. Jeden agent dokáže během jednoho běhu prohledat, přečíst a promyslet jen omezený počet zdrojů. Paralelní běh více agentů zlepšuje kvalitu u nejnáročnějších úloh, ale zároveň zvyšuje náklady a při nesprávném řízení přináší složitost.

Vyřešení každé z těchto výzev snížilo náklady u každé úrovně úsilí bez snížení výkonu.

Každá úroveň úsilí má pevný rozpočet na výzkum, který se skládá ze tří složek:

Limity kroků: počet tahů, které agent může provést
Volání nástrojů: limit celkového počtu volání nástrojů v rámci požadavku. Jeden krok může najednou vyvolat více volání napříč více nástroji, takže samotný limit kroků neurčuje, kolik akcí v rámci kroku proběhne.
Připomínky rozpočtu: pravidelná upozornění na to, kolik kroků zbývá, aby agent mohl stanovit priority a ponechat si prostor na napsání odpovědi, místo aby mu rozpočet došel uprostřed úlohy.

Rozpočet je ústředním kompromisem: více kroků znamená lepší odpovědi a každý krok něco stojí. U openai/gpt-6-luna zvýšení limitu kroků z 1 na 15 zvedne přesnost v BrowseComp + DSQA ze 41 % na 80 %, zatímco náklady na dotaz vzrostou z 0,0017 $ na 0,0152 $, tedy zhruba 9× vyšší náklady za zhruba 2× vyšší skóre.

Samotný limit kroků náklady na výzkum neurčuje. Při stejném rozpočtu pěti kroků provede openai/gpt-6.1-terra více volání nástrojů než openai/gpt-6-luna, protože schopnější modely mají tendenci vyvolat v jednom kroku několik volání. Úrovně úsilí omezují jak volání nástrojů, tak kroky. U těchto modelů je limit volání nástrojů stejně důležitý jako limit kroků.

Každá úroveň úsilí tyto limity ladí, ale agent také musí vědět, kolik kroků a akcí mu ke splnění požadavku zbývá. Bez této informace mu mohou kroky nebo akce dojít a bude nucen odpovědět dřív, než je výzkum dokončen. Rozpočet se uvádí na začátku běhu a připomínky přicházejí, když se agent blíží svým limitům, takže zbývá prostor na ověření a předání výsledků. U úrovně high se připomínky týkají rozpočtu kroků i rozpočtu volání nástrojů.

Dva agenti, jeden s připomínkou rozpočtu a druhý bez ní, byli otestováni na úloze z BrowseComp, v níž měli na základě tří životopisů herců identifikovat televizní seriál z 90. let. Agent s připomínkou našel správnou odpověď a využil k tomu 13 ze 40 kroků v rozpočtu. Agent bez připomínky rozpočtu spotřeboval všech 40 kroků a správnou odpověď nenašel. Smyčka tohoto agenta skončila neočekávaně a model si nebyl vědom zbývajícího rozpočtu na výzkum. Připomínky pomáhají agentům udržet pozornost a efektivně upřednostnit zbývající zdroje.

Dlouho běžící výzkumné úlohy zaplňují kontextové okno modelu výsledky vyhledávání, načtenými stránkami a průběžnými poznámkami. Jakmile se zaplní, agent musí přestat pracovat.

Kompaktace umožňuje, aby dlouhé běhy pokračovaly, aniž by zaplnily kontextové okno. Když kontext překročí určitou mez, agent nahradí dosavadní práci kratším shrnutím toho, co zjistil a co zbývá, a pak pokračuje.

Kompaktace v kontextu vždy zachovává tři věci: systémový prompt, původní požadavek a všechny skilly, které agent již načetl. Po každé kompaktaci agent obdrží dva krátké pokyny. První pokyn zní: „Pokračuj v práci, dokud nebude úloha hotová.“ Díky tomu agent nepovažuje shrnutí za bod, kde má skončit. Druhý pokyn agentovi sděluje, kolik kompaktací již proběhlo, aby mohl naplánovat zbývající výzkumné úlohy. Dlouhé běhy tak mají stále na očích původní cíl a plán a náklady na dlouhé smyčky klesají bez snížení kvality.

Každá stránka, kterou agent přečte, se přidá do jeho kontextu a agent ji nese v každém dalším kroku. Webová stránka obsahuje informace, které s otázkou nesouvisejí, například navigaci, šablonový text a další obsah.

Místo aby agentovi předal celou stránku, fetch_url nejprve provede extrakční průchod. Text stránky se spolu s aktuální úlohou agenta odešle menšímu modelu. Model vrátí pouze relevantní pasáže, citované doslovně, aby je agent mohl uvést jako zdroj. Během jednoho vyhodnocení se stránka o 5 561 tokenech zmenšila na 293 tokenů, čímž se uvolnilo místo pro další relevantní kontext.

Použití fetch_url s extrakcí na úrovni úsilí high snížilo počet vstupních tokenů na dotaz přibližně o 50 %. Extrakce také zlepšila výsledky v benchmarku – dosáhla 88,0 % při ceně 0,073 $ za dotaz oproti 83,5 % při 0,094 $ bez extrakce.

Vyhledávání na webu je základem každého výzkumného požadavku agenta. Ve způsobu, jakým agenti vyhledávají, proběhly tři změny:

Více kontextu na vyhledávání: Každé vyhledávání nyní vrací až 4K tokenů výsledků místo 2K. Agent najde, co potřebuje, rychleji, takže stačí méně vyhledávání a náklady jsou nižší.

Nový systém generování úryvků: K výsledkům vyhledávání se generují úryvky, které lépe odpovídají dotazu, takže agent není zahlcován nerelevantním textem.
Rychlé vyhledávání: Za 1,00 $ za 1 000 požadavků snižuje Fast Search náklady i latenci každého volání vyhledávání.

Tým Perplexity Search neustále zlepšuje kvalitu vyhledávání informací napříč širokou škálou úloh. Nedávné aktualizace přinesly zlepšení u kódu, vývojářské dokumentace, referenčních stránek a právního i regulatorního obsahu.

Některé úlohy vyžadují mnoho paralelně spuštěných vyhledávání, jiné pečlivé přečtení několika dlouhých dokumentů.

Načtení všech pracovních postupů do systémového promptu agenta však zvyšuje režii kontextu a může vést k tomu, že model bude u jednoduchých úloh podávat horší výkon. Skilly jsou proto uspořádány do stromu s postupným odhalováním. Model během práce načítá relevantní skilly a pokyny a nesouvisející informace do svého kontextu nezahrnuje. Každý skill stojí jen svůj název a popis, dokud model nerozhodne, že se pro úlohu hodí, a nenačte ho; v tu chvíli se do kontextu přidají úplné pokyny a model postupuje podle předepsaného pracovního postupu.

Aby bylo možné změřit přínos jednotlivých skillů, odebírá se vždy jeden skill a porovnává se kvalita a náklady u úloh, při nichž výchozí agent tento skill načetl. Tyto ablace ukazují, které pracovní postupy agentovi pomáhají a jak ovlivňují efektivitu výzkumu.

Níže uvedené běhy benchmarku WANDR ukazují, jak agenti volí správné pracovní postupy pro konkrétní úlohy. Pokyny pro wide-search a fanout byly načteny u každé úlohy, což odráží potřebu zkoumat více entit. Skill people-search byl načten jen u 6 % úloh, a to pouze tehdy, když se otázky týkaly lidí.

Při testování další úlohy WANDR načetl agent skill people-search se vzorem fanout, aby našel inženýry pro inferenci v Londýně. Rozšířil 39 výrazů pro role na 117 dotazů a výsledky prvního průchodu pak sloučil do 43 jedinečných profilů k dalšímu prověření. Skill people-search agenta touto expanzí provedl, aniž by přidal irelevantní kontext. Níže uvedená ukázka je upravena podle skriptu agenta; názvy pomocných funkcí jsou ilustrativní.

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

Kontrolní body jsou dalším pracovním postupem, který agentům pomáhá u dlouho běžících úloh. Vzor kontrolních bodů pochází z dávkového programování. Když skript zpracovává dlouhý seznam, zapíše každý výsledek na disk, jakmile ho má, místo aby vše držel v paměti až do konce. Pokud skript v průběhu spadne nebo narazí na chyby, nic se neztratí: další běh načte, co už bylo uloženo, a pokračuje tam, kde předchozí skončil, přičemž opakuje jen položky, které selhaly.

V další úloze WANDR musel agent prověřit profily 188 inženýrů. Načetl vzor kontrolních bodů, aby během práce zaznamenával každý výsledek. První průchod extrahoval 160 profilů, ale u 28 selhal. Když agent skript spustil znovu, přeskočil již zaznamenané profily a zopakoval pouze zbývajících 28. Bez kontrolního bodu by jediný chybný záznam znamenal načítat znovu všech 188.Upravená ukázka v Pythonu; vstupní stránky, pokyn pro prověřování, schéma a importy jsou vynechány; názvy pomocných funkcí jsou ilustrativní.

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

Kontrolní bod zaznamenává úspěšné výsledky; opakované pokusy nespouští. Zahrnutí pokynu a schématu do klíče zajišťuje, že změna kritérií prověřování vyvolá opětovné zpracování.

Ne každý test přinesl zlepšení kvality a efektivity. Vyhodnocovalo se také předběžné načtení všech skillů do agenta ještě před zahájením úlohy. V BrowseComp a DSQA zvýšilo předběžné načtení náklady o 13 %. Ve WANDR, kde kvůli delším výzkumným trajektoriím tvoří načtený obsah větší podíl vstupních tokenů, předběžné načtení také snižuje skóre. Tyto výsledky podpořily další používání postupného odhalování.

S rozvojem schopností modelů se mění i nejlepší model pro každou úroveň úsilí. Perplexity využívá automatizovanou výzkumnou smyčku, která sleduje oznámení nových modelů a jejich dostupnost. Vyhodnocení se spouští, jakmile je model dostupný.

Když vyjde nový model, automatizovaný agent ho prověří ve vyhodnocovacím harnessu. Projde různá nastavení míry uvažování, rozpočtů kroků a volání nástrojů i konfigurace nástrojů a každý běh ohodnotí z hlediska kvality a nákladů ve srovnání se současnými úrovněmi úsilí. Pokud se některý běh zhorší, agent zjistí proč, upraví nastavení a vyhodnocení spustí znovu. Kandidát nahradí současný model, pouze pokud zvítězí v kvalitě při stejných nebo nižších nákladech.

Veřejné benchmarky jsou užitečné, ale jejich skóre ne vždy odpovídá výkonu v reálných úlohách. Například níže uvedený graf ukazuje kandidátní model, který v BrowseComp dosáhl skóre o 13,3 bodu nad referenční hodnotou, ale v interních podnikových, právních a finančních výzkumných úlohách zůstal výrazně pod příslušnými referenčními hodnotami.

Jeden agent dokáže v jedné smyčce pokrýt jen omezený počet zdrojů. U složitých úloh pracuje paralelně několik agentů a každý se věnuje jiné části problému.

Primární agent je orchestrátor. Volá spawn_agent, aby vytvořil podřízené agenty, a každému přidělí konkrétní, úzce zaměřenou úlohu. Každý podřízený agent spouští vlastní výzkumnou smyčku se samostatným kontextem a používá vlastní model, nástroje a rozpočet kroků. Podřízení agenti hlásí výsledky nadřazenému agentovi, který jim může zadat navazující úkol nebo zkontrolovat jejich postup. Orchestrátor a jeho podřízení agenti si vyměňují zprávy, aby sdíleli důkazy, upozorňovali na překážky a upravovali další kroky. S příchodem nových informací orchestrátor zpřesňuje zadání, a když je práce hotová, spojí výsledky do jediné odpovědi.

Agent API podporuje předdefinované role agentů a orchestrátor může vytvářet podřízené agenty s vlastními pokyny.

Úroveň úsilí ultra spouští na jedné úloze paralelně tři agenty. Každý agent nezávisle zkoumá celou úlohu, takže získá jiné důkazy. Čtvrtý agent jejich zjištění sloučí, odstraní duplicity a napíše konečnou odpověď.

Ve WANDR dosahuje úroveň ultra skóre 85,9 % při ceně 21,71 $ za úlohu. Jde o nejvyšší skóre mezi testovanými konfiguracemi.

Úrovně úsilí se průběžně vyhodnocují a zlepšují. Úroveň, kterou uživatel zvolí, určuje, kolik výzkumu úloha dostane a kolik bude stát. Rozpočty kroků a volání nástrojů spolu s připomínkami, když se blíží jejich vyčerpání, udržují požadavky v rámci rozpočtu. Kompaktace, extrakce a lepší úryvky udržují kontext zaměřený na důkazy. Skilly přizpůsobují pracovní postup úloze a paralelní agenti rozšiřují, co dokáže pokrýt jedna smyčka. Automatizovaná vyhodnocovací smyčka přijme nový model, pouze pokud zlepší kvalitu výzkumu při stejných nákladech.

Každá úroveň úsilí se bude dál vyvíjet, jak se nové modely a konfigurace osvědčí při vyhodnocení. Volání úrovně jménem tato zlepšení automaticky převezme; připnutí verze konfiguraci zafixuje.

Vyzkoušejte Agent API a porovnejte úrovně úsilí na vlastních úlohách. Podrobnosti o úrovních úsilí najdete v naší dokumentaci k úrovním úsilí v Agent API.

Náklady na výzkum

Řízení rozpočtu na výzkum

Správa kontextu

Kompaktace

Načítání jen toho podstatného

Cílené vyhledávání na webu

Výběr správného pracovního postupu

Výběr modelu

Škálování pomocí více agentů

Co bude dál