Uzlabojumi visos Agent API piepūles līmeņos

Perplexity Agent API piepūles līmeņi tagad maksā mazāk, nodrošinot tādu pašu vai labāku izpētes kvalitāti, un dziļākai izpētei ir pieejams jauns līmenis ultra.

Ascending glass panels reflecting a landscape and warm light.

Perplexity Agent API piepūles līmeņi ļauj izstrādātājiem katram uzdevumam izvēlēties līdzsvaru starp izmaksām, ātrumu un izpētes dziļumu. Šodien katrs piepūles līmenis maksā mazāk par vaicājumu, un izpētes kvalitāte ir augstāka vai nemainīga. Visplašākajai un visaptverošākajai izpētei ir pieejams jauns līmenis ultra. Jebkurš pieprasījums, kas izvēlas līmeni pēc nosaukuma, piemēram, effort="fast", automātiski saņem atjaunināto konfigurāciju.

Izpētes aģenta izveide nozīmē katram uzdevumam izvēlēties pareizo līdzsvaru starp izmaksām, ātrumu un dziļumu. Agent API piepūles līmeņi šo lēmumu pieņem lietotāja vietā. Katrs līmenis ir komplektēta konfigurācija, kas konkrētam uzdevuma veidam nosaka modeli, soļu budžetu, meklēšanas iestatījumus un rīkus. Perplexity laika gaitā novērtē un atjaunina katru līmeni, lai nodrošinātu labāko izpēti par pašreizējām izmaksām vai lētāk.

Šie uzlabojumi radās no divu veidu izmaiņām. Budžeti, konteksta apstrāde un ekstrakcija samazināja katras darbības izmaksas, savukārt Skill, modeļu izvēle un paralēli aģenti uzlaboja vai saglabāja atbildes kvalitāti.

medium veiktspēja BrowseComp un DSQA testos uzlabojās no 55% līdz 77%, savukārt izmaksas samazinājās gandrīz par 90%. BrowseComp un DSQA ir publiski izpētes etalontesti; WANDR ir Perplexity etalontests ar ilgiem izpētes uzdevumiem par vairākām entītijām. xhigh veic aģentisku darbu, piemēram, izpilda kodu smilšu kastē, uztur ilgus rīku izmantošanas ciklus un vienlaikus strādā ar daudziem avotiem. xhigh saglabāja savu WANDR rezultātu 76,5% līmenī, darbojoties par aptuveni 25% no 2026. gada augusta konfigurācijas izmaksām.

Izpētes izmaksas

Padziļinātas izpētes pieprasījums pirms atbildes sniegšanas var veikt desmitiem meklēšanu, izlasīt simtiem lapu un pārbaudīt pierādījumus. Katra no šīm darbībām pievieno kontekstam marķierus un rēķinam — dolārus. Bez ierobežojumiem aģents turpina veikt darbības, kas palielina izmaksas un pārblīvē kontekstu, neuzlabojot atbildi. Lielāko daļu šo izmaksu nosaka pieci faktori:

  • Budžeta sadale. Aģentiem ar noteiktu budžetu var pietrūkt soļu, un tie var priekšlaicīgi beigt darbību, pirms uzdevums ir pabeigts. Savukārt aģenti bez fiksēta budžeta var turpināt darbību, radot izmaksas, bet neuzlabojot galīgo atbildi.
  • Konteksta papildslodze. Meklēšanas rezultāti un iegūtās lapas satur pierādījumus, taču bez kontroles konteksta logs var ātri piepildīties ar nebūtisku informāciju. Konteksta logi rada izmaksas katrā solī, un pārslogoti logi var pasliktināt aģenta veiktspēju.
  • Darbplūsmas izvēle. Dažādiem uzdevumiem nepieciešamas dažādas pieejas. Viena fakta uzmeklēšanai, vairākposmu jautājumam un plašam avotu apskatam katram nepieciešama cita darbplūsma. Ja modelim ļauj izvēlēties pašam, tas bieži izvēlas neefektīvu darbplūsmu. Sīks katras pieejamās stratēģijas apraksts aģenta uzvednē šo problēmu neatrisina. Papildu instrukcijas katrā solī tiek nestas līdzi kā marķieri, un laika gaitā modelis katrai no tām seko arvien mazāk uzticami.
  • Modeļa izvēle. Pāreja uz lielāku modeli var nesniegt veiktspējas uzlabojumu, kas atbilstu papildu izmaksām. Jauni modeļi parādās ar skaļiem virsrakstiem un publicētiem etalontestu rezultātiem. Tomēr etalontestu uzlabojumi var būt piesārņoti vai atspoguļot modeļa pārmērīgu pielāgošanos. Bez novērtēšanas reālos uzdevumos modeļa maiņa var palielināt izmaksas, neuzlabojot kvalitāti.
  • Mērogošana ar vairākiem aģentiem. Viens aģents vienā darbībā var meklēt, lasīt un analizēt ierobežotu skaitu avotu. Vairāku aģentu paralēla darbināšana uzlabo kvalitāti vissarežģītākajos uzdevumos, taču arī palielina izmaksas un, ja to nepārvalda pareizi, rada papildu sarežģītību.

Atrisinot katru no šīm problēmām, izmaksas katram piepūles līmenim samazinājās, nesamazinot veiktspēju.

Izpētes budžeta kontrole

Katram piepūles līmenim ir fiksēts izpētes budžets, kas sastāv no trim komponentiem:

  • Soļu ierobežojumi: gājienu skaits, ko aģents var veikt
  • Rīku izsaukumi: kopējā rīku izsaukumu skaita ierobežojums vienā pieprasījumā. Viens solis var vienlaikus veikt vairākus izsaukumus vairākiem rīkiem, tāpēc ar soļu ierobežojumu vien nevar kontrolēt, cik darbību notiek viena soļa ietvaros.
  • Budžeta atgādinājumi: periodiski paziņojumi par to, cik soļu vēl atlicis, lai aģents varētu noteikt prioritātes un atstāt vietu atbildes uzrakstīšanai, nevis iztērēt budžetu uzdevuma vidū.

Budžets ir galvenais kompromiss: vairāk soļu nozīmē labākas atbildes, taču katrs solis rada izmaksas. Ar openai/gpt-6-luna, palielinot soļu ierobežojumu no 1 līdz 15, precizitāte BrowseComp + DSQA testos pieaug no 41% līdz 80%, savukārt izmaksas par vaicājumu pieaug no 0,0017 USD līdz 0,0152 USD — aptuveni 9 reizes lielākas izmaksas par aptuveni 2 reizes augstāku rezultātu.

Ar soļu ierobežojumu vien nevar kontrolēt izpētes izmaksas. Ar tādu pašu piecu soļu budžetu openai/gpt-6.1-terra veic vairāk rīku izsaukumu nekā openai/gpt-6-luna, jo spējīgāki modeļi mēdz vienā solī veikt vairākus izsaukumus. Piepūles līmeņi ierobežo gan rīku izsaukumus, gan soļus. Šiem modeļiem rīku izsaukumu ierobežojums ir tikpat svarīgs kā soļu ierobežojums.

Katrs piepūles līmenis pielāgo šos ierobežojumus, taču aģentam ir arī jāzina, cik soļu un darbību tam atlicis pieprasījuma izpildei. Bez šīs informācijas tam var pietrūkt soļu vai darbību, un tas var būt spiests atbildēt, pirms izpēte ir pabeigta. Budžets tiek norādīts darbības sākumā, un, aģentam tuvojoties ierobežojumiem, tiek saņemti atgādinājumi, tāpēc atliek vieta rezultātu pārbaudei un sniegšanai. Līmenim high atgādinājumi attiecas gan uz soļu budžetu, gan uz rīku izsaukumu budžetu.

Divi aģenti — viens ar budžeta atgādinājumu un otrs bez tā — tika pārbaudīti BrowseComp uzdevumā, kurā pēc trīs aktieru biogrāfijām bija jānosaka 20. gadsimta 90. gadu televīzijas seriāls. Aģents ar atgādinājumu atrada pareizo atbildi, izmantojot 13 no budžetā paredzētajiem 40 soļiem. Aģents bez budžeta atgādinājuma izmantoja visus 40 soļus un pareizo atbildi neatrada. Šī aģenta cikls beidzās negaidīti, un modelis nezināja, cik liels izpētes budžets vēl atlicis. Atgādinājumi palīdz aģentiem saglabāt fokusu un efektīvi noteikt atlikušo resursu prioritātes.

Konteksta pārvaldība

Saspiešana

Ilgstoši izpētes uzdevumi piepilda modeļa konteksta logu ar meklēšanas rezultātiem, iegūtajām lapām un starpposma piezīmēm. Kad logs ir pilns, aģentam jāpārtrauc darbs.

Saspiešana ļauj ilgām darbībām turpināties, nepārpildot konteksta logu. Kad konteksts pārsniedz noteiktu slieksni, aģents līdzšinējo darbu aizstāj ar īsāku kopsavilkumu par to, ko tas ir atradis un kas vēl jāpaveic, un pēc tam turpina darbu.

Saspiešanas laikā kontekstā vienmēr tiek saglabātas trīs lietas: sistēmas uzvedne, sākotnējais pieprasījums un visas Skill, ko aģents jau ir ielādējis. Pēc katras saspiešanas aģents saņem divas īsas instrukcijas. Pirmā instrukcija ir: „Turpini darbu, līdz uzdevums ir paveikts.” Tas neļauj aģentam uztvert kopsavilkumu kā apstāšanās punktu. Otrā instrukcija norāda aģentam, cik saspiešanu jau ir notikušas, lai tas varētu plānot atlikušos izpētes uzdevumus. Ilgās darbībās sākotnējais mērķis un plāns paliek redzeslokā, un ilgu ciklu izmaksas samazinās, nesamazinot kvalitāti.

Iegūt tikai būtisko

Katra lapa, ko aģents izlasa, papildina tā kontekstu, un aģents to nes līdzi katrā nākamajā solī. Tīmekļa lapā ir informācija, kas nav saistīta ar jautājumu, piemēram, navigācija, šablona teksts un cits saturs.

Tā vietā, lai aģentam nodotu visu lapu, fetch_url vispirms veic ekstrakcijas piegājienu. Lapas teksts kopā ar aģenta pašreizējo uzdevumu tiek nosūtīts mazākam modelim. Modelis atgriež tikai būtiskos fragmentus, citējot tos burtiski, lai aģents varētu uz tiem atsaukties. Novērtēšanas laikā lapa ar 5561 marķieri tika samazināta līdz 293 marķieriem, atbrīvojot vietu papildu būtiskam kontekstam.

Izmantojot fetch_url ar ekstrakciju high piepūles līmenī, ievades marķieru skaits vienam vaicājumam samazinājās aptuveni par 50%. Ekstrakcija arī uzlaboja etalontestu rezultātus, sasniedzot 88,0% ar izmaksām 0,073 USD par vaicājumu, salīdzinot ar 83,5% ar izmaksām 0,094 USD bez ekstrakcijas.

Fokusēta tīmekļa meklēšana

Tīmekļa meklēšana ir katra aģenta izpētes pieprasījuma pamatā. Aģentu meklēšanas veidā tika veiktas trīs izmaiņas:

  • Vairāk konteksta katrā meklēšanā: Katra meklēšana tagad atgriež līdz 4 tūkst. marķieru rezultātu 2 tūkst. vietā. Aģents ātrāk atrod nepieciešamo, tāpēc meklēšanu ir mazāk un izmaksas ir zemākas.
  • Jauns fragmentu dzinējs: Meklēšanas rezultāti saņem fragmentus, kas labāk atbilst vaicājumam, tāpēc aģents netiek pārslogots ar nebūtisku tekstu.
  • Ātrā meklēšana: Ar cenu 1,00 USD par 1000 pieprasījumiem Fast Search samazina gan izmaksas, gan latentumu katram meklēšanas izsaukumam.

Perplexity Search komanda nepārtraukti uzlabo izguves kvalitāti dažādos uzdevumos. Jaunākie atjauninājumi nodrošināja uzlabojumus koda, izstrādātāju dokumentācijas, uzziņu lapu, juridiskā un regulatīvā satura jomā.

Pareizās darbplūsmas izvēle

Dažiem uzdevumiem nepieciešams paralēli veikt daudzas meklēšanas; citiem — rūpīgi izlasīt dažus garus dokumentus.

Tomēr, ielādējot katru darbplūsmu aģenta sistēmas uzvednē, palielinās konteksta papildslodze, un modeļa veiktspēja vienkāršos uzdevumos var pasliktināties. Tā vietā Skill ir sakārtotas kokā ar pakāpenisku atklāšanu. Modelis darba gaitā ielādē būtiskās Skill un instrukcijas, neiekļaujot savā kontekstā nesaistītu informāciju. Katra Skill aizņem tikai savu nosaukumu un aprakstu, līdz modelis nolemj, ka tā atbilst uzdevumam, un to ielādē — tad kontekstam tiek pievienotas pilnās instrukcijas, un modelis seko noteiktajai darbplūsmai.

Lai noteiktu atsevišķu Skill ieguldījumu, katra Skill pa vienai tiek noņemta, lai salīdzinātu kvalitāti un izmaksas uzdevumos, kuros bāzes aģents šo Skill ielādēja. Šie ablācijas testi parāda, kuras darbplūsmas palīdz aģentam un kā tās ietekmē izpētes efektivitāti.

Tālāk redzamās WANDR etalontesta darbības parāda, kā aģenti izvēlas pareizās darbplūsmas konkrētiem uzdevumiem. Plašās meklēšanas un izvēršanas (fanout) norādījumi tika ielādēti katram uzdevumam, jo bija jāizpēta vairākas entītijas. Cilvēku meklēšana tika ielādēta tikai 6% uzdevumu un tikai tad, ja jautājumi bija saistīti ar cilvēkiem.

Pārbaudot citu WANDR uzdevumu, aģents ielādēja cilvēku meklēšanas Skill ar izvēršanas (fanout) shēmu, lai atrastu secināšanas inženierus Londonā. Tas izvērsa 39 amatu nosaukumus 117 vaicājumos un pēc tam apvienoja pirmās kārtas rezultātus 43 unikālos profilos turpmākai atlasei. Cilvēku meklēšanas Skill vadīja aģentu šīs izvēršanas gaitā, nepievienojot nebūtisku kontekstu. Tālāk redzamais fragments ir pielāgots pēc aģenta skripta; palīgfunkciju nosaukumi ir ilustratīvi.

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

Kontrolpunktu izmantošana ir vēl viena darbplūsma, kas palīdz aģentiem ilgstošos uzdevumos. Kontrolpunktu modelis nāk no pakešapstrādes programmēšanas. Kad skripts apstrādā garu sarakstu, tas katru rezultātu ieraksta diskā, tiklīdz to iegūst, nevis glabā visu atmiņā līdz beigām. Ja skripts darba vidū avarē vai saskaras ar kļūdām, nekas netiek zaudēts: nākamā palaišana nolasa jau saglabāto un turpina no vietas, kur darbs tika pārtraukts, atkārtoti mēģinot apstrādāt tikai neizdevušos vienumus.

Citā WANDR uzdevumā aģentam bija jāizvērtē 188 inženieru profili. Tas ielādēja kontrolpunktu modeli, lai darba gaitā reģistrētu katru rezultātu. Pirmajā piegājienā tika iegūti 160 profili, bet 28 profilu apstrāde neizdevās. Kad aģents palaida skriptu vēlreiz, tas izlaida jau reģistrētos profilus un atkārtoti mēģināja apstrādāt tikai atlikušos 28. Bez kontrolpunkta viena kļūdaina ieraksta dēļ būtu atkal jāiegūst visi 188.Pielāgots Python fragments; ievades lapas, atlases instrukcija, shēma un importi izlaisti; palīgfunkciju nosaukumi ir ilustratīvi.

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

Kontrolpunkts reģistrē veiksmīgos rezultātus; tas neuzsāk atkārtotus mēģinājumus. Instrukcijas un shēmas iekļaušana atslēgā nodrošina, ka mainīti atlases kritēriji izraisa atkārtotu apstrādi.

Ne katrs tests uzlaboja kvalitāti un efektivitāti. Tika novērtēta visu Skill iepriekšēja ielāde aģentā pirms uzdevuma sākšanas. BrowseComp un DSQA testos iepriekšēja ielāde palielināja izmaksas par 13%. WANDR testā, kur garākas izpētes trajektorijas padara iegūto saturu par lielāku ievades marķieru daļu, iepriekšēja ielāde arī samazina rezultātus. Šie rezultāti apstiprināja, ka jāturpina izmantot pakāpenisku atklāšanu.

Modeļa izvēle

Attīstoties modeļu iespējām, mainās arī labākais modelis katram piepūles līmenim. Perplexity izmanto automatizētu izpētes ciklu, kas uzrauga jaunu modeļu paziņojumus un pieejamību. Novērtēšana tiek palaista, tiklīdz modelis kļūst pieejams.

Kad tiek izlaists jauns modelis, automatizēts aģents to pārbauda novērtēšanas harness. Tas izmēģina dažādus spriestspējas piepūles līmeņus, soļu un rīku izsaukumu budžetus un rīku konfigurācijas un katrai darbībai novērtē kvalitāti un izmaksas salīdzinājumā ar pašreizējiem piepūles līmeņiem. Ja kādas darbības rezultāti pasliktinās, aģents izpēta cēloni, pielāgo iestatījumus un atkārto novērtēšanu. Kandidāts aizstāj pašreizējo modeli tikai tad, ja tas uzvar kvalitātē par tādām pašām vai zemākām izmaksām.

Publiskie etalontesti ir noderīgi, taču to rezultāti ne vienmēr atspoguļo sniegumu reālos uzdevumos. Piemēram, tālāk redzamajā diagrammā parādīts kandidātmodelis, kas BrowseComp testā ieguva par 13,3 punktiem vairāk nekā bāzlīnija, taču iekšējos korporatīvās, juridiskās un finanšu izpētes uzdevumos tā rezultāti bija krietni zem attiecīgajām bāzlīnijām.

Mērogošana ar vairākiem aģentiem

Viens aģents vienā ciklā var aptvert tikai ierobežotu skaitu avotu. Sarežģītos uzdevumos vairāki aģenti strādā paralēli, katrs koordinējot darbu pie citas problēmas daļas.

Primārais aģents ir orķestrētājs. Tas izsauc spawn_agent, lai izveidotu pakārtotos aģentus, un katram piešķir konkrētu, fokusētu uzdevumu. Katrs pakārtotais aģents veic savu izpētes ciklu ar atsevišķu kontekstu, izmantojot savu modeli, rīkus un soļu budžetu. Pakārtotie aģenti ziņo par saviem rezultātiem vecākaģentam, kas var nosūtīt pakārtotajam aģentam papildu uzdevumu vai pārbaudīt tā progresu. Orķestrētājs un tā pakārtotie aģenti apmainās ar ziņojumiem, lai dalītos ar pierādījumiem, norādītu uz šķēršļiem un pielāgotu nākamos soļus. Saņemot jaunu informāciju, orķestrētājs precizē uzdevumus un, kad darbs ir paveikts, apvieno rezultātus vienā atbildē.

Agent API atbalsta iepriekš definētas aģentu lomas, un orķestrētājs var izveidot pakārtotos aģentus ar pielāgotām instrukcijām.

Piepūles līmenis ultra vienā uzdevumā paralēli darbina trīs aģentus. Katrs aģents neatkarīgi izpēta visu uzdevumu, tāpēc tiek iegūti atšķirīgi pierādījumi. Ceturtais aģents apvieno to atradumus, novērš dublikātus un uzraksta galīgo atbildi.

WANDR testā ultra sasniedz 85,9% ar izmaksām 21,71 USD par uzdevumu. Tas ir augstākais rezultāts starp pārbaudītajām konfigurācijām.

Kas tālāk

Piepūles līmeņi tiek nepārtraukti novērtēti un uzlaboti. Lietotāja izvēlētais līmenis nosaka, cik daudz izpētes uzdevums saņem un cik tas izmaksās. Soļu un rīku izsaukumu budžeti kopā ar atgādinājumiem, kad budžets tuvojas beigām, palīdz pieprasījumiem iekļauties budžetā. Saspiešana, ekstrakcija un labāki fragmenti palīdz kontekstam koncentrēties uz pierādījumiem. Skill pielāgo darbplūsmu uzdevumam, un paralēli aģenti paplašina to, ko spēj aptvert viens cikls. Automatizēts novērtēšanas cikls pieņem jaunu modeli tikai tad, ja tas uzlabo izpētes kvalitāti par tādām pašām izmaksām.

Katrs piepūles līmenis turpinās attīstīties, jauniem modeļiem un konfigurācijām pierādot sevi novērtēšanā. Izsaucot līmeni pēc nosaukuma, šie uzlabojumi tiek iegūti automātiski; piesaistot versiju, konfigurācija paliek nemainīga.

Izmēģiniet Agent API un salīdziniet piepūles līmeņus ar savām darba slodzēm. Sīkāka informācija par piepūles līmeņiem ir pieejama mūsu Agent API piepūles līmeņu dokumentācijā.