Kiekvieno Agent API pastangų lygio patobulinimai

Perplexity Agent API pastangų lygiai leidžia kūrėjams kiekvienai užduočiai pasirinkti kainos, greičio ir tyrimo gylio pusiausvyrą. Nuo šiandien kiekvienas pastangų lygis kainuoja mažiau už užklausą, o tyrimo kokybė yra aukštesnė arba nepakitusi. Naujas ultra lygis skirtas plačiausiems ir išsamiausiems tyrimams. Bet kuri užklausa, kuri lygį pasirenka pagal pavadinimą, pavyzdžiui, effort="fast", atnaujintą konfigūraciją gauna automatiškai.

Kuriant tyrimų agentą reikia kiekvienai užduočiai parinkti tinkamą kainos, greičio ir gylio pusiausvyrą. Agent API pastangų lygiai šį sprendimą priima už naudotoją. Kiekvienas lygis yra paruošta konfigūracija, apibrėžianti modelį, žingsnių biudžetą, paieškos nustatymus ir įrankius konkrečiam užduoties tipui. Perplexity laikui bėgant vertina ir atnaujina kiekvieną lygį, kad užtikrintų geriausią tyrimą už dabartinę ar mažesnę kainą.

Šie patobulinimai atsirado dėl dviejų rūšių pokyčių. Biudžetai, konteksto valdymas ir ištraukimas sumažino kiekvieno vykdymo kainą, o Skill, modelio pasirinkimas ir lygiagretūs agentai pagerino arba išlaikė atsakymo kokybę.

medium našumas BrowseComp ir DSQA testuose pagerėjo nuo 55 % iki 77 %, o išlaidos sumažėjo beveik 90 %. BrowseComp ir DSQA yra vieši tyrimų lyginamieji testai; WANDR – tai Perplexity lyginamasis testas, skirtas ilgoms, daug objektų apimančioms tyrimų užduotims. xhigh atlieka agentinį darbą, pavyzdžiui, vykdo kodą Sandbox aplinkoje, palaiko ilgus įrankių naudojimo ciklus ir vienu metu dirba su daugybe šaltinių. xhigh išlaikė 76,5 % WANDR rezultatą, o jo veikimo kaina sudarė apie 25 % 2026 m. rugpjūčio konfigūracijos kainos.

Giluminio tyrimo užklausa prieš pateikdama atsakymą gali atlikti dešimtis paieškų, perskaityti šimtus puslapių ir patikrinti įrodymus. Kiekvienas iš šių veiksmų prideda žetonų į kontekstą ir dolerių į sąskaitą. Be apribojimų agentas ir toliau atlieka veiksmus, kurie didina išlaidas ir perpildo kontekstą, bet nepagerina atsakymo. Didžiąją šių išlaidų dalį lemia penki veiksniai:

Biudžeto paskirstymas. Agentams su nustatytu biudžetu gali pritrūkti žingsnių, ir jie gali anksčiau laiko baigti vykdymą neužbaigę užduoties. Ir atvirkščiai, agentai be fiksuoto biudžeto gali toliau veikti ir didinti išlaidas, nepagerindami galutinio atsakymo.
Konteksto perkrova. Paieškos rezultatuose ir gautuose puslapiuose yra įrodymų, tačiau nekontroliuojamas konteksto langas gali greitai prisipildyti nereikšmingos informacijos. Konteksto langų kaina perkeliama iš žingsnio į žingsnį, o perkrauti langai gali sumažinti agento našumą.
Darbo eigos pasirinkimas. Skirtingoms užduotims reikia skirtingų metodų. Vieno fakto paieškai, kelių etapų klausimui ir plačiai šaltinių apžvalgai reikia skirtingų darbo eigų. Palikus modeliui rinktis pačiam, jis dažnai pasirenka neefektyvią. Visų galimų strategijų aprašymas agento raginime šios problemos neišsprendžia. Papildomos instrukcijos kiekviename žingsnyje perduodamos kaip žetonai, o laikui bėgant modelis kiekvienos jų laikosi vis mažiau patikimai.
Modelio pasirinkimas. Perėjus prie didesnio modelio, našumas gali pagerėti ne tiek, kiek pateisintų papildomos išlaidos. Nauji modeliai pasirodo lydimi skambių antraščių ir paskelbtų lyginamųjų testų rezultatų. Tačiau lyginamųjų testų rezultatų pagerėjimas gali būti iškreiptas duomenų užteršimo arba atspindėti modelio persimokymą. Neįvertinus realiose užduotyse, modelio pakeitimas gali padidinti išlaidas nepagerinęs kokybės.
Kelių agentų mastelio didinimas. Vienas agentas per vieną vykdymą gali ieškoti, skaityti ir analizuoti ribotą šaltinių skaičių. Lygiagrečiai vykdant kelis agentus pagerėja sudėtingiausių užduočių kokybė, tačiau išauga ir išlaidos, o netinkamai valdant atsiranda papildomo sudėtingumo.

Išsprendus kiekvieną iš šių iššūkių, kiekvieno pastangų lygio išlaidos sumažėjo nesumažinant našumo.

Kiekvienas pastangų lygis turi fiksuotą tyrimo biudžetą, kurį sudaro trys komponentai:

Žingsnių ribos: ėjimų, kuriuos agentas gali atlikti, skaičius
Įrankių iškvietimai: bendro įrankių iškvietimų skaičiaus vienoje užklausoje riba. Vienu žingsniu galima vienu metu atlikti kelis iškvietimus keliais įrankiais, todėl vien žingsnių riba nekontroliuoja, kiek veiksmų įvyksta per vieną žingsnį.
Biudžeto priminimai: periodiniai pranešimai apie tai, kiek liko žingsnių, kad agentas galėtų nustatyti prioritetus ir palikti vietos atsakymui parašyti, užuot išnaudojęs biudžetą neužbaigęs užduoties.

Biudžetas yra pagrindinis kompromisas: daugiau žingsnių reiškia geresnius atsakymus, o kiekvienas žingsnis kainuoja. Naudojant openai/gpt-6-luna, padidinus žingsnių ribą nuo 1 iki 15, tikslumas BrowseComp + DSQA testuose pakyla nuo 41 % iki 80 %, o vienos užklausos kaina išauga nuo 0,0017 $ iki 0,0152 $ – maždaug 9 kartus didesnė kaina už maždaug 2 kartus geresnį rezultatą.

Vien žingsnių riba nekontroliuoja tyrimo kainos. Esant tam pačiam penkių žingsnių biudžetui, openai/gpt-6.1-terra atlieka daugiau įrankių iškvietimų nei openai/gpt-6-luna, nes pajėgesni modeliai linkę per vieną žingsnį atlikti kelis iškvietimus. Pastangų lygiai riboja ir įrankių iškvietimus, ir žingsnius. Šiems modeliams įrankių iškvietimų riba yra tokia pat svarbi kaip ir žingsnių riba.

Kiekvienas pastangų lygis sureguliuoja šiuos apribojimus, tačiau agentas taip pat turi žinoti, kiek žingsnių ir veiksmų jam liko užklausai įvykdyti. Be šios informacijos jam gali pritrūkti žingsnių ar veiksmų ir jis bus priverstas atsakyti dar nebaigęs tyrimo. Biudžetas nurodomas vykdymo pradžioje, o priminimai gaunami agentui artėjant prie ribų, todėl lieka laiko patikrinti ir pateikti rezultatus. Lygio high atveju priminimai apima ir žingsnių biudžetą, ir įrankių iškvietimų biudžetą.

Du agentai – vienas su biudžeto priminimu, kitas be jo – buvo išbandyti BrowseComp užduotyje, kurioje pagal tris aktorių biografijas reikėjo nustatyti 1990-ųjų metų televizijos serialą. Agentas su priminimu rado teisingą atsakymą, panaudojęs 13 iš 40 biudžete numatytų žingsnių. Agentas be biudžeto priminimo išnaudojo visus 40 žingsnių ir teisingo atsakymo nerado. Šio agento ciklas nutrūko netikėtai, o modelis nežinojo, kiek tyrimo biudžeto liko. Priminimai padeda agentams išlikti susitelkusiems ir veiksmingai paskirstyti likusius išteklius.

Ilgai trunkančios tyrimo užduotys užpildo modelio konteksto langą paieškos rezultatais, gautais puslapiais ir tarpiniais užrašais. Jam prisipildžius, agentas turi nutraukti darbą.

Glaudinimas leidžia ilgiems vykdymams tęstis neužpildant konteksto lango. Kai kontekstas viršija nustatytą ribą, agentas iki tol atliktą darbą pakeičia trumpesne santrauka apie tai, ką rado ir kas dar liko, ir tęsia darbą.

Glaudinimo metu kontekste visada išlieka trys dalykai: sistemos raginimas, pradinė užklausa ir visi Skill, kuriuos agentas jau įkėlė. Po kiekvieno glaudinimo agentas gauna dvi trumpas instrukcijas. Pirmoji instrukcija: „Tęsk darbą, kol užduotis bus atlikta.“ Tai neleidžia agentui santraukos laikyti sustojimo tašku. Antroji instrukcija nurodo agentui, kiek kartų buvo atliktas glaudinimas, kad jis galėtų suplanuoti likusias tyrimo užduotis. Ilgų vykdymų metu pradinis tikslas ir planas išlieka matomi, o ilgų ciklų kaina sumažėja neprarandant kokybės.

Kiekvienas agento perskaitytas puslapis papildo jo kontekstą, ir agentas jį perneša į kiekvieną paskesnį žingsnį. Tinklalapyje yra su klausimu nesusijusios informacijos, pavyzdžiui, navigacijos, šabloninio teksto ir kito turinio.

Užuot pateikęs agentui visą puslapį, fetch_url pirmiausia atlieka ištraukimo etapą. Puslapio tekstas kartu su dabartine agento užduotimi siunčiamas mažesniam modeliui. Modelis grąžina tik susijusias ištraukas, cituojamas pažodžiui, kad agentas galėtų jas nurodyti kaip šaltinius. Vertinimo metu 5 561 žetono puslapis buvo sutrumpintas iki 293 žetonų, todėl atsilaisvino vietos papildomam svarbiam kontekstui.

Naudojant fetch_url su ištraukimu esant high pastangų lygiui, įvesties žetonų vienai užklausai sumažėjo maždaug 50 %. Ištraukimas taip pat pagerino lyginamojo testo rezultatus: pasiektas 88,0 % rezultatas už 0,073 $ vienai užklausai, palyginti su 83,5 % už 0,094 $ be ištraukimo.

Žiniatinklio paieška yra kiekvienos agento tyrimo užklausos pagrindas. Agentų paieškos būdas pakeistas trimis aspektais:

Daugiau konteksto vienai paieškai: kiekviena paieška dabar grąžina iki 4 tūkst. žetonų rezultatų vietoj 2 tūkst. Agentas greičiau randa tai, ko reikia, todėl atliekama mažiau paieškų ir sumažėja išlaidos.

Naujas fragmentų variklis: paieškos rezultatams parenkami užklausą geriau atitinkantys fragmentai, todėl agentas neapkraunamas nereikšmingu tekstu.
Greita paieška: Fast Search, kainuojanti 1,00 $ už 1 tūkst. užklausų, sumažina kiekvieno paieškos iškvietimo kainą ir delsą.

Perplexity Search komanda nuolat gerina paieškos kokybę įvairiausiose užduotyse. Naujausi atnaujinimai pagerino rezultatus kodo, kūrėjų dokumentacijos, žinyno puslapių, teisinio ir reguliavimo turinio srityse.

Kai kurioms užduotims reikia lygiagrečiai atlikti daug paieškų; kitoms – atidžiai perskaityti kelis ilgus dokumentus.

Tačiau visų darbo eigų įkėlimas į agento sistemos raginimą padidina konteksto perkrovą ir gali lemti prastesnį modelio veikimą atliekant paprastas užduotis. Todėl Skill suskirstyti į medį taikant laipsnišką atskleidimą. Dirbdamas modelis įkelia susijusius Skill ir instrukcijas, o nesusijusios informacijos į kontekstą neįtraukia. Kiekvienas Skill kainuoja tik savo pavadinimą ir aprašymą, kol modelis nusprendžia, kad jis tinka užduočiai, ir jį įkelia – tada į kontekstą įtraukiamos visos instrukcijos, o modelis vykdo nustatytą darbo eigą.

Siekiant įvertinti atskirų Skill indėlį, kiekvienas Skill pašalinamas po vieną ir palyginama kokybė bei kaina tose užduotyse, kuriose bazinis agentas tą Skill buvo įkėlęs. Šios abliacijos parodo, kurios darbo eigos padeda agentui ir kaip jos veikia tyrimo efektyvumą.

Toliau pateikti WANDR lyginamojo testo vykdymai rodo, kaip agentai pasirenka tinkamas darbo eigas konkrečioms užduotims. Wide-search ir fanout gairės buvo įkeltos kiekvienai užduočiai, nes reikėjo tirti daug objektų. People-search buvo įkeltas tik 6 % užduočių ir tik tada, kai klausimai buvo susiję su žmonėmis.

Testuojant kitą WANDR užduotį, agentas įkėlė people-search Skill su išsišakojimo (fanout) šablonu, kad surastų inferencijos inžinierius Londone. Jis išplėtė 39 pareigybių pavadinimus į 117 užklausų, tada sujungė pirmojo etapo rezultatus į 43 unikalius profilius tolesnei atrankai. Šis people-search Skill padėjo agentui atlikti išplėtimą nepridedant nereikšmingo konteksto. Toliau pateikta ištrauka parengta pagal agento scenarijų; pagalbinių funkcijų pavadinimai yra iliustraciniai.

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

Kontrolinių taškų naudojimas – dar viena darbo eiga, padedanti agentams atliekant ilgai trunkančias užduotis. Kontrolinių taškų šablonas kilęs iš paketinio programavimo. Kai scenarijus apdoroja ilgą sąrašą, kiekvieną rezultatą jis įrašo į diską vos jį gavęs, užuot laikęs viską atmintyje iki pabaigos. Jei scenarijus įpusėjęs sutrinka arba susiduria su klaidomis, niekas neprarandama: kitas vykdymas nuskaito tai, kas jau išsaugota, ir tęsia nuo ten, kur sustota, iš naujo bandydamas tik nepavykusius elementus.

Kitoje WANDR užduotyje agentui reikėjo atrinkti 188 inžinierių profilius. Jis įkėlė kontrolinio taško šabloną, kad darbo metu įrašytų kiekvieną rezultatą. Per pirmąjį etapą buvo išgauta 160 profilių, tačiau 28 nepavyko. Kai agentas paleido scenarijų dar kartą, jis praleido jau įrašytus profilius ir iš naujo bandė apdoroti tik likusius 28. Be kontrolinio taško dėl vieno sugadinto įrašo tektų vėl gauti visus 188.Pritaikyta Python ištrauka; įvesties puslapiai, atrankos instrukcija, schema ir importai praleisti; pagalbinių funkcijų pavadinimai yra pavyzdiniai.

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

Kontrolinis taškas įrašo sėkmingus rezultatus; jis nepaleidžia pakartotinių bandymų. Į raktą įtraukus instrukciją ir schemą užtikrinama, kad pakeitus atrankos kriterijus duomenys būtų apdorojami iš naujo.

Ne kiekvienas bandymas pagerino kokybę ir efektyvumą. Buvo įvertintas visų Skill įkėlimas į agentą iš anksto, prieš jam pradedant užduotį. BrowseComp ir DSQA testuose išankstinis įkėlimas padidino išlaidas 13 %. WANDR teste, kur dėl ilgesnių tyrimo trajektorijų gautas turinys sudaro didesnę įvesties žetonų dalį, išankstinis įkėlimas taip pat sumažina rezultatus. Šie rezultatai pagrindė tolesnį laipsniško atskleidimo naudojimą.

Tobulėjant modelių galimybėms, keičiasi ir geriausias modelis kiekvienam pastangų lygiui. Perplexity naudoja automatizuotą tyrimo ciklą, kuris stebi naujų modelių pristatymus ir prieinamumą. Vertinimai pradedami vos tik modelis tampa prieinamas.

Išleidus naują modelį, automatizuotas agentas jį patikrina vertinimo harness aplinkoje. Jis išbando įvairias protavimo pastangų, žingsnių ir įrankių iškvietimų biudžetų bei įrankių konfigūracijų reikšmes ir kiekvieną vykdymą įvertina pagal kokybę ir kainą, palygindamas su dabartiniais pastangų lygiais. Jei vykdymo rezultatai suprastėja, agentas ištiria priežastis, pakoreguoja nustatymus ir vertinimą paleidžia iš naujo. Kandidatas pakeičia dabartinį modelį tik tada, kai pranoksta jį kokybe už tą pačią arba mažesnę kainą.

Vieši lyginamieji testai naudingi, tačiau jų rezultatai ne visada atspindi realias užduotis. Pavyzdžiui, toliau pateiktoje diagramoje parodytas kandidatinis modelis, kuris BrowseComp teste surinko 13,3 punkto daugiau nei bazinis modelis, tačiau vidinėse įmonių, teisės ir finansų tyrimų užduotyse gerokai atsiliko nuo atitinkamų bazinių rezultatų.

Vienas agentas per vieną ciklą gali aprėpti tik ribotą šaltinių skaičių. Sudėtingoms užduotims keli agentai dirba lygiagrečiai, kiekvienas koordinuodamas skirtingą problemos dalį.

Pagrindinis agentas yra orkestratorius. Jis iškviečia spawn_agent, kad sukurtų antrinius agentus, ir kiekvienam paskiria konkrečią, aiškiai apibrėžtą užduotį. Kiekvienas antrinis agentas vykdo savo tyrimo ciklą su atskiru kontekstu, naudodamas savo modelį, įrankius ir žingsnių biudžetą. Antriniai agentai praneša rezultatus pagrindiniam agentui, kuris gali duoti antriniam agentui papildomą užduotį arba patikrinti jo pažangą. Orkestratorius ir antriniai agentai keičiasi pranešimais, kad pasidalytų įrodymais, praneštų apie kliūtis ir pakoreguotų tolesnius veiksmus. Gaunant naujos informacijos, orkestratorius patikslina užduotis, o darbą užbaigus sujungia rezultatus į vieną atsakymą.

Agent API palaiko iš anksto apibrėžtus agentų vaidmenis, o orkestratorius gali kurti antrinius agentus su pasirinktinėmis instrukcijomis.

Pastangų lygis ultra vienai užduočiai lygiagrečiai vykdo tris agentus. Kiekvienas agentas savarankiškai tiria visą užduotį, todėl surenka skirtingų įrodymų. Ketvirtasis agentas sujungia jų išvadas, pašalina dublikatus ir parašo galutinį atsakymą.

WANDR teste ultra pasiekia 85,9 % rezultatą už 21,71 $ vienai užduočiai. Tai aukščiausias rezultatas tarp išbandytų konfigūracijų.

Pastangų lygiai nuolat vertinami ir tobulinami. Naudotojų pasirinktas lygis lemia, kiek tyrimo skiriama užduočiai ir kiek ji kainuos. Žingsnių ir įrankių iškvietimų biudžetai kartu su priminimais jiems senkant užtikrina, kad užklausos neviršytų biudžeto. Glaudinimas, ištraukimas ir geresni fragmentai išlaiko kontekstą sutelktą į įrodymus. Skill pritaiko darbo eigą prie užduoties, o lygiagrečiai veikiantys agentai išplečia tai, ką gali aprėpti vienas ciklas. Automatizuotas vertinimo ciklas naują modelį įtraukia tik tada, kai jis pagerina tyrimo kokybę už tą pačią kainą.

Kiekvienas pastangų lygis toliau tobulės, kai nauji modeliai ir konfigūracijos įrodys savo vertę vertinimuose. Kreipiantis į lygį pagal pavadinimą, šie patobulinimai pritaikomi automatiškai; užfiksavus versiją, konfigūracija lieka nepakitusi.

Išbandykite Agent API ir palyginkite pastangų lygius su savo darbo krūviais. Išsamią informaciją apie pastangų lygius rasite mūsų Agent API pastangų lygių dokumentacijoje.

Tyrimo kaina

Tyrimo biudžeto valdymas

Konteksto valdymas

Glaudinimas

Gauti tik tai, kas svarbu

Tikslinė žiniatinklio paieška

Tinkamos darbo eigos pasirinkimas

Modelio pasirinkimas

Kelių agentų mastelio didinimas

Kas toliau