Fejlesztések az Agent API minden ráfordítási szintjén

A Perplexity Agent API ráfordítási szintjeivel a fejlesztők minden feladathoz kiválaszthatják a költség, a sebesség és a kutatási mélység egyensúlyát. Mostantól minden ráfordítási szint olcsóbb lekérdezésenként, a kutatás minősége pedig jobb vagy változatlan. Elérhető egy új ultra szint is a legszélesebb körű és legátfogóbb kutatásokhoz. Minden kérés, amely név szerint választja ki a szintet, például effort="fast", automatikusan megkapja a frissített konfigurációt.

Egy kutatóügynök felépítésekor minden feladathoz meg kell találni a költség, a sebesség és a mélység megfelelő egyensúlyát. Az Agent API ráfordítási szintjei a felhasználó helyett hozzák meg ezt a döntést. Minden szint egy előre összeállított konfiguráció, amely egy adott feladattípushoz meghatározza a modellt, a lépéskeretet, a keresési beállításokat és az eszközöket. A Perplexity folyamatosan értékeli és frissíti az egyes szinteket, hogy a jelenlegi költségen vagy annál olcsóbban a lehető legjobb kutatást nyújtsa.

Ezek a javulások kétféle változtatásból adódtak. A keretek, a kontextuskezelés és a kinyerés csökkentette az egyes futások költségét, a skillek, a modellválasztás és a párhuzamos ügynökök pedig javították vagy megőrizték a válasz minőségét.

A medium teljesítménye 55%-ról 77%-ra javult a BrowseComp és a DSQA teszteken, miközben a költségek közel 90%-kal csökkentek. A BrowseComp és a DSQA nyilvános kutatási benchmarkok; a WANDR a Perplexity benchmarkja hosszú, több entitást érintő kutatási feladatokhoz. Az xhigh ügynöki munkát végez, például kódot futtat sandboxban, hosszú eszközhasználati ciklusokat tart fenn, és egyszerre számos forrással dolgozik. Az xhigh megtartotta 76,5%-os WANDR-pontszámát, miközben a 2026. augusztusi konfiguráció költségének nagyjából 25%-áért futott.

Egy mélyreható kutatási kérés a válasz előtt több tucat keresést futtathat, több száz oldalt olvashat el, és ellenőrizheti a bizonyítékokat. Mindegyik művelet tokenekkel bővíti a kontextust, és dollárokkal a számlát. Korlátok nélkül az ügynök olyan műveleteket is végez, amelyek növelik a költséget és telítik a kontextust, a választ viszont nem javítják. A költség nagy részét öt tényező határozza meg:

A keret elosztása. A meghatározott kerettel rendelkező ügynökök kifogyhatnak a lépésekből, és a feladatuk véglegesítése előtt idő előtt befejezhetik a futást. Ezzel szemben a rögzített keret nélküli ügynökök tovább futhatnak, és költségeket generálnak anélkül, hogy a végső válasz javulna.
Kontextusterhelés. A keresési találatok és a lekért oldalak hordozzák a bizonyítékokat, de ellenőrzés nélkül a kontextusablak gyorsan megtelhet irreleváns információkkal. A kontextusablakok költsége lépésről lépésre halmozódik, a túlterhelt ablakok pedig ronthatják az ügynök teljesítményét.
A munkafolyamat kiválasztása. A különböző feladatok különböző megközelítést igényelnek. Egyetlen tény kikeresése, egy többlépéses (multi-hop) kérdés és a források széles körű áttekintése egyaránt más-más munkafolyamatot kíván. Ha a modell maga választhat, gyakran nem hatékony megoldást választ. Ezen az sem segít, ha az ügynök promptja minden elérhető stratégiát részletez. A többletutasítások tokenként minden lépésben a kontextusban maradnak, és a modell idővel egyre kevésbé megbízhatóan követi őket.
Modellválasztás. Egy nagyobb modellre való váltás nem feltétlenül hoz a többletköltséggel arányos teljesítményjavulást. Az új modellek nagy felhajtással és közzétett benchmarkpontszámokkal érkeznek. A benchmarkokon elért javulás azonban adatszennyezésből eredhet, vagy a modell túlillesztését tükrözheti. Valós feladatokon végzett kiértékelés nélkül egy modellváltás a minőség javulása nélkül is növelheti a költségeket.
Több ügynökös skálázás. Egyetlen ügynök futásonként csak véges számú forrást tud átkutatni, elolvasni és végiggondolni. Több ügynök párhuzamos futtatása javítja a minőséget a legigényesebb feladatokon, de a költségeket is növeli, és helytelen kezelés esetén bonyolultabbá teszi a rendszert.

Ezeknek a kihívásoknak a megoldása minden ráfordítási szinten csökkentette a költségeket a teljesítmény romlása nélkül.

Minden ráfordítási szinthez rögzített kutatási keret tartozik, amely három összetevőből áll:

Lépéskorlátok: az ügynök által megtehető körök száma
Eszközhívások: egy kérésen belüli eszközhívások teljes számának felső korlátja. Egyetlen lépés egyszerre több eszközön keresztül is több hívást indíthat, ezért a lépéskorlát önmagában nem szabályozza, hány művelet történik egy lépésen belül.
Keretemlékeztetők: rendszeres értesítések arról, hány lépés van még hátra, így az ügynök rangsorolhat, és helyet hagyhat a válasz megírására ahelyett, hogy a feladat közepén kifogyna a keretből.

A keret a központi kompromisszum: több lépés jobb válaszokat jelent, de minden lépés költséggel jár. Az openai/gpt-6-luna esetében a lépéskorlát 1-ről 15-re emelése 41%-ról 80%-ra növeli a pontosságot a BrowseComp + DSQA teszteken, miközben a lekérdezésenkénti költség 0,0017 dollárról 0,0152 dollárra emelkedik: nagyjából 9-szeres költségért nagyjából 2-szeres pontszám.

A lépéskorlát önmagában nem szabályozza a kutatás költségét. Ugyanazon ötlépéses keret mellett az openai/gpt-6.1-terra több eszközhívást indít, mint az openai/gpt-6-luna, mert a fejlettebb modellek hajlamosak egyetlen lépésben több hívást kiadni. A ráfordítási szintek az eszközhívások és a lépések számát is korlátozzák. Ezeknél a modelleknél az eszközhívási korlát ugyanolyan fontos, mint a lépéskorlát.

Minden ráfordítási szint a saját értékeire hangolja ezeket a korlátokat, de az ügynöknek azt is tudnia kell, hány lépése és művelete maradt a kérés teljesítéséhez. Ennek ismerete nélkül kifogyhat a lépésekből vagy a műveletekből, és kénytelen lehet a kutatás befejezése előtt válaszolni. A keretet a futás elején közlik az ügynökkel, az emlékeztetők pedig akkor érkeznek, amikor az ügynök a korlátaihoz közeledik, így marad idő az eredmények ellenőrzésére és átadására. A high szinten az emlékeztetők a lépéskeretre és az eszközhívási keretre is kiterjednek.

Két ügynököt – az egyiket keretemlékeztetővel, a másikat anélkül – egy BrowseComp-feladaton teszteltek, amelyben három szereplő életrajza alapján kellett azonosítani egy 1990-es évekbeli tévésorozatot. Az emlékeztetővel rendelkező ügynök a keretben szereplő 40 lépésből 13 felhasználásával megtalálta a helyes választ. Az emlékeztető nélküli ügynök mind a 40 lépést felhasználta, és nem találta meg a helyes választ. Ennek az ügynöknek a ciklusa váratlanul véget ért, és a modell nem tudott a hátralévő kutatási keretről. Az emlékeztetők segítik az ügynököket abban, hogy fókuszáltak maradjanak, és hatékonyan rangsorolják a fennmaradó erőforrásokat.

A hosszan futó kutatási feladatok megtöltik a modell kontextusablakát keresési találatokkal, lekért oldalakkal és köztes jegyzetekkel. Ha a kontextusablak megtelik, az ügynöknek abba kell hagynia a munkát.

A tömörítés lehetővé teszi, hogy a hosszú futások a kontextusablak megtelése nélkül folytatódjanak. Amikor a kontextus túllép egy küszöbértéket, az ügynök az addigi munkát egy rövidebb összefoglalóra cseréli arról, amit talált, és arról, ami még hátravan, majd folytatja a munkát.

A tömörítés során három dolog mindig a kontextusban marad: a rendszerprompt, az eredeti kérés és az ügynök által már betöltött skillek. Minden tömörítés után az ügynök két rövid utasítást kap. Az első utasítás: „Folytasd a munkát, amíg a feladat el nem készül.” Ez megakadályozza, hogy az ügynök az összefoglalót megállási pontnak tekintse. A második utasítás közli az ügynökkel, hány tömörítés történt eddig, így megtervezheti a hátralévő kutatási feladatait. A hosszú futások során szem előtt marad az eredeti cél és terv, a hosszú ciklusok költsége pedig a minőség romlása nélkül csökken.

Minden oldal, amelyet az ügynök elolvas, bővíti a kontextusát, és az ügynök azt minden további lépésben magával viszi. Egy weboldal a kérdéshez nem kapcsolódó információkat is tartalmaz, például navigációt, sablonszöveget és egyéb tartalmakat.

Ahelyett, hogy egy teljes oldalt adna át az ügynöknek, a fetch_url először egy kinyerési lépést futtat. Az oldal szövegét az ügynök aktuális feladatával együtt egy kisebb modellnek küldi el. A modell csak a releváns részeket adja vissza, szó szerint idézve, hogy az ügynök hivatkozhasson rájuk. Egy kiértékelés során egy 5561 tokenes oldal 293 tokenre csökkent, így hely szabadult fel további releváns kontextus számára.

A fetch_url kinyeréssel történő használata a high ráfordítási szinten nagyjából 50%-kal csökkentette a lekérdezésenkénti bemeneti tokenek számát. A kinyerés a benchmarkteljesítményt is javította: lekérdezésenként 0,073 dolláros költség mellett 88,0%-ot ért el, szemben a kinyerés nélküli, 0,094 dolláros költséggel elért 83,5%-kal.

A webes keresés minden ügynöki kutatási kérés középpontjában áll. Három változtatás történt abban, ahogyan az ügynökök keresnek:

Több kontextus keresésenként: Minden keresés mostantól 2K helyett legfeljebb 4K tokennyi találatot ad vissza. Az ügynök hamarabb megtalálja, amire szüksége van, így kevesebb keresésre van szükség, és alacsonyabb a költség.

Új szövegrészlet-motor: A keresési találatokhoz a lekérdezéshez jobban illeszkedő szövegrészletek tartoznak, így az ügynököt nem terheli túl a nem releváns szöveg.
Gyors keresés: 1000 kérésenként 1,00 dolláros árával a Fast Search minden keresési hívásnál csökkenti a költséget és a késleltetést is.

A Perplexity Search csapata folyamatosan javítja a visszakeresés minőségét a feladatok széles körében. A legutóbbi frissítések javulást hoztak a kód, a fejlesztői dokumentációk, a referenciaoldalak, valamint a jogi és szabályozási tartalmak terén.

Egyes feladatokhoz sok párhuzamosan futó keresésre van szükség, másokhoz néhány hosszú dokumentum alapos elolvasására.

Ha azonban minden munkafolyamatot betöltenének az ügynök rendszerpromptjába, az növelné a kontextusterhelést, és a modell gyengébben teljesíthetne az egyszerű feladatokon. Ehelyett a skillek fastruktúrába vannak rendezve, fokozatos feltárással. A modell munka közben tölti be a releváns skilleket és utasításokat, a nem kapcsolódó információkat pedig kihagyja a kontextusából. Minden skill csak a nevével és a leírásával terheli a kontextust, amíg a modell el nem dönti, hogy illik a feladathoz, és be nem tölti; ekkor a teljes utasítások bekerülnek a kontextusba, és a modell követi az előírt munkafolyamatot.

Az egyes skillek hozzájárulásának méréséhez a skilleket egyenként eltávolítják, és összehasonlítják a minőséget és a költséget azokon a feladatokon, amelyeken a kiindulási ügynök betöltötte az adott skillt. Ezek az ablációs vizsgálatok megmutatják, mely munkafolyamatok segítik az ügynököt, és hogyan befolyásolják a kutatás hatékonyságát.

Az alábbi WANDR benchmarkfuttatások azt mutatják, hogyan választják ki az ügynökök az adott feladatokhoz megfelelő munkafolyamatokat. A wide-search és a fanout útmutató minden feladatnál betöltődött, mivel több entitás vizsgálatára volt szükség. A people-search csak a feladatok 6%-ánál töltődött be, és csak akkor, ha a kérdések személyekre vonatkoztak.

Egy másik WANDR-feladat tesztelésekor az ügynök betöltötte a people-search skillt, és egy fanout mintával londoni inferenciamérnököket keresett. A 39 szerepkör-kifejezést 117 lekérdezéssé bővítette, majd az első kör eredményeit 43 egyedi profillá vonta össze további szűrés céljából. A people-search skill úgy vezette végig az ügynököt ezen a bővítésen, hogy nem adott hozzá irreleváns kontextust. Az alábbi részlet az ügynök szkriptjének átdolgozott változata; a segédfüggvények nevei szemléltető jellegűek.

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

Az ellenőrzőpontok használata egy másik munkafolyamat, amely a hosszan futó feladatokon segíti az ügynököket. Az ellenőrzőpont-minta a kötegelt programozásból származik. Amikor egy szkript hosszú listát dolgoz fel, minden eredményt azonnal lemezre ír, amint elkészül, ahelyett hogy a végéig mindent a memóriában tartana. Ha a szkript menet közben összeomlik vagy hibákba ütközik, semmi sem vész el: a következő futás beolvassa a már elmentett adatokat, és onnan folytatja, ahol az előző abbamaradt, csak a sikertelen elemeket próbálva újra.

Egy másik WANDR-feladatban az ügynöknek 188 mérnök profilját kellett átszűrnie. Betöltötte az ellenőrzőpont-mintát, hogy munka közben minden eredményt rögzítsen. Az első kör 160 profilt nyert ki, 28-nál azonban sikertelen volt. Amikor az ügynök újra lefuttatta a szkriptet, kihagyta a már rögzített profilokat, és csak a fennmaradó 28-at próbálta újra. Ellenőrzőpont nélkül egyetlen hibás rekord miatt is újra le kellett volna kérni mind a 188 profilt.Átdolgozott Python-részlet; a bemeneti oldalak, a szűrési utasítás, a séma és az importok kihagyva; a segédfüggvények nevei szemléltető jellegűek.

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

Az ellenőrzőpont a sikeres eredményeket rögzíti; újrapróbálkozásokat nem indít. Mivel az utasítás és a séma is része a kulcsnak, a szűrési feltételek módosítása újrafeldolgozást vált ki.

Nem minden teszt hozott javulást a minőségben és a hatékonyságban. Megvizsgálták azt is, mi történik, ha az ügynökbe a feladat megkezdése előtt minden skillt előre betöltenek. A BrowseComp és a DSQA teszteken az előzetes betöltés 13%-kal növelte a költséget. A WANDR benchmarkon, ahol a hosszabb kutatási útvonalak miatt a lekért tartalom a bemeneti tokenek nagyobb részét teszi ki, az előzetes betöltés a pontszámokat is rontja. Ezek az eredmények a fokozatos feltárás további alkalmazását támasztották alá.

Ahogy a modellek képességei fejlődnek, úgy változik az is, melyik modell a legjobb az egyes ráfordítási szintekhez. A Perplexity automatizált kutatási ciklust alkalmaz, amely figyeli az új modellek bejelentését és elérhetőségét. A kiértékelések azonnal elindulnak, amint egy modell elérhetővé válik.

Amikor új modell jelenik meg, egy automatizált ügynök végigfuttatja a kiértékelési harnessen. Végigpróbálja az érvelési ráfordítás, a lépés- és eszközhívási keretek, valamint az eszközkonfigurációk különböző értékeit, és minden futást minőség és költség szempontjából pontoz a jelenlegi ráfordítási szintekhez képest. Ha egy futás visszaesést mutat, az ügynök kideríti az okát, módosítja a beállításokat, és újra lefuttatja a kiértékelést. Egy jelölt csak akkor váltja le a jelenlegi modellt, ha azonos vagy alacsonyabb költség mellett jobb minőséget nyújt.

A nyilvános benchmarkok hasznosak, de a pontszámaik nem mindig tükrözik a valós feladatokon nyújtott teljesítményt. Az alábbi diagram például egy olyan jelölt modellt mutat, amely a BrowseComp teszten 13,3 ponttal az alapszint felett teljesített, a belső vállalati, jogi és pénzügyi kutatási feladatokon azonban jóval elmaradt a megfelelő alapszintektől.

Egyetlen ügynök egy ciklusban csak korlátozott számú forrást tud lefedni. Összetett feladatoknál több ügynök dolgozik párhuzamosan, mindegyik összehangoltan a probléma más-más részén.

Az elsődleges ügynök az orkesztrátor. A spawn_agent meghívásával gyermekügynököket hoz létre, és mindegyiknek konkrét, célzott feladatot ad. Minden gyermekügynök saját kutatási ciklust futtat külön kontextussal, saját modellel, eszközökkel és lépéskerettel. A gyermekügynökök a szülőnek jelentik az eredményeiket, a szülő pedig további feladatot küldhet egy gyermekügynöknek, vagy ellenőrizheti annak előrehaladását. Az orkesztrátor és a gyermekügynökei üzeneteket váltanak, hogy megosszák a bizonyítékokat, jelezzék az akadályokat, és módosítsák a következő lépéseket. Ahogy új információk érkeznek, az orkesztrátor finomítja a feladatokat, és amikor a munka elkészült, az eredményeket egyetlen válaszba egyesíti.

Az Agent API előre definiált ügynökszerepköröket támogat, az orkesztrátor pedig egyéni utasításokkal rendelkező gyermekügynököket is létrehozhat.

Az ultra ráfordítási szint három ügynököt futtat párhuzamosan egy feladaton. Mindegyik ügynök önállóan kutatja végig a teljes feladatot, így eltérő bizonyítékokat gyűjtenek. Egy negyedik ügynök egyesíti az eredményeiket, kiszűri az ismétlődéseket, és megírja a végső választ.

A WANDR benchmarkon az ultra 85,9%-os pontszámot ér el feladatonként 21,71 dolláros költséggel. Ez a legmagasabb pontszám a tesztelt konfigurációk közül.

A ráfordítási szintek folyamatos értékelésen és fejlesztésen mennek keresztül. A felhasználó által kiválasztott szint határozza meg, mennyi kutatást kap egy feladat, és mennyibe fog kerülni. A lépés- és eszközhívási keretek, valamint a keret fogyásával érkező emlékeztetők a kéréseket a kereten belül tartják. A tömörítés, a kinyerés és a jobb szövegrészletek a bizonyítékokra összpontosítják a kontextust. A skillek a feladathoz igazítják a munkafolyamatot, a párhuzamosan futó ügynökök pedig kiterjesztik azt, amit egyetlen ciklus lefedhet. Egy automatizált kiértékelési ciklus csak akkor enged be új modellt, ha az azonos költség mellett javítja a kutatás minőségét.

Az egyes ráfordítási szintek tovább fejlődnek, ahogy új modellek és konfigurációk bizonyítanak a kiértékelés során. Egy szint név szerinti meghívása automatikusan átveszi ezeket a fejlesztéseket; egy verzió rögzítése változatlanul tartja a konfigurációt.

Próbáld ki az Agent API-t, és hasonlítsd össze a ráfordítási szinteket a saját munkaterheléseiden. A ráfordítási szintek részleteit az Agent API ráfordítási dokumentációjában találod.

A kutatás költsége

A kutatási keret szabályozása

A kontextus kezelése

Tömörítés

Csak a lényeges tartalom lekérése

Célzott webes keresés

A megfelelő munkafolyamat kiválasztása

Modellválasztás

Több ügynökös skálázás

Mi következik?